Wudsn now supports Apple //

http://www.wudsn.com/

What is it?

(from the site)
WUDSN IDE combines the powerful capabilities of Eclipse with the speed of native 6502 cross compilers.

(my assessment)
It is an incredible combination of tools for developing 8-bit 6502 programs, all wrapped together using Eclipse. You can compile and execute your programs against the target platform all in one pass! Target platforms include Atari, NES, C64 and now Apple ][!

I'm excited to see this release come out because, well, it's why I added the commandline options to Jace a little while ago. Now, thanks to help from several different projects like AppleCommander, AppleWin, Jace to name a few, Jac has really done an amazing job with his IDE, making it easy to go from source and have that translate into a disk image that boots directly at the click of a button!

I've not tried it out yet, but it goes without saying that I cannot wait to do so!!

-B

And don't forget, the latest build of AppleCommander is now invokable as
an Ant task:
http://applecommander.sourceforge.net/acant.html

Hmmm... I can't get Eclipse to change the default HW platform from C64 to AppleII (ie. the C64 icon on the toolbar). So whenever I "compile" (why not assemble?) it uses this cmd line:

Compiling for hardware C64 on 13/08/12 23:02: C:\Program Files\eclipse\WUDSN_Compilers\ASM\ACME\acme.exe -f cbm -o C:\Users\Tom\AppData\Local\Temp\test.prg C:\Users\Tom\workspace\Apple2\test.a

In 'Preferences > Assembler > Apple II Compilers' I changed the Parameters to "-o ${outputFilePath} ${sourceFilePath}" (ie. removed the '-f cbm'), but clearly it's still using the C64 Compiler options as the default.

Any idea how to change this?

I added this line to the source (.a) file:
;@com.wudsn.ide.asm.hardware=APPLE2

Close the .a, then reopen it, and now the green Apple icon is in the toolbar.

Tom

...but I can't figure out how to get Eclipse to use AppleCommander to create a .dsk image.

Thanks for posting this-- This is very interesting.
I've never worked out a toolset/workflow for cross developing for the Apple II from osx that wasn't incredibly tedious. This looks very promising.

Please share any details on how/if you get this working.

Currently, I've got the base Eclipse 3.6.2 installed. Yes, it's an older version that what's available, but I opted to use this based on some posts by the WUDSN author that I had read somewhere. From there it was a straightforward process of installing the WUDSN plugin through Eclipse itself. There's a nice step-by-step example on the WUDSN web site.

On that same site, there are suggestions on different 6502 assemblers to use for different platforms (atari, c64, etc) but no suggestion for Apple II. I ended up selecting and installing Kickass (Kick Assembler). What is the author using in his testing? Any other suggestions here. For the Emulator platform, I am using JACE.

So the next question is how to set up the disk image into the project, and have the binary copied into it. Are there any docs that have been posted, or has anyone figured this part out? Also, is there support for DOS 3.3 and ProDOS disks?

I remember talking to him via email and recommending that he use AppleCommander to add files to a template disk image since it won't create a bootable disk from scratch. I don't know if he shipped a bootable dos3.3 or prodos image with his plugin so that might be worth investigating. Also it is possible to use Acme with Wudsn, I saw it in some of his screenshots. Acme is pretty easy to compile for Mac and Linux too, but beware that the current copy in Sourceforge has trouble with local (.1, .2, etc) labels whereas older copies from the smorboard software website didn't exhibit any issues.

-B

Ok, it appears that .dsk image format is automatically supported inside the WUDSN plug-in.
I picked up ACME and compiled it on the mac, and set it up inside Eclipse. By default, files in the project with a ".a" extension will be assembled with ACME. What I couldn't figure out was how to get the project to compile as an Apple2 type. TomCh filled that in with a previous post in this thread (thanks Tom!), by putting in:
;@com.wudsn.ide.asm.hardware=APPLE2

at the beginning of the source file. Close and reopen the source file, and now the project will compile as an Apple2 file.

I set up JACE as the default Apple2 program, and when I compiled, a .dsk image appeared in my project, JACE was automatically launched, and the program attempted to run. Double clicking the .dsk image in the project opened up an internal browser that shows 2 files in the DOS 3.3 disk:
HELLO (Basic program that runs first)
WORLD (Binary file that runs from the HELLO file. This is your assembled executable).

My first program actually crashed, but I figured out why. For whatever reason, during the linking/dsk merging process, the 4 bytes used for ADDRESS/LENGTH in DOS 3.3 Binary files aren't set up right, so you need to make room for them in your src file.

Here's a quick program that I managed to get assembled and run automatically in JACE:
--------
; ACME text conversion table I created for Apple ASCII
!ct "a2txt.bin"

; Origin has to be 4 bytes less, to make room for DOS 3.3 ADDRESS and LENGTH (4 bytes total)
; appended to the BIN file
*=$2000-4

; Add in the header manually for DOS 3.3. Make sure the Origin matches above, but the
; LENGTH is filled in automatically, probably during the copy to dsk image
header !byte $00,$20,$ff,$ff

; Equates here
cout=$fded

ldx #$00
loop
lda message,x
beq quit
inx
jsr cout
jmp loop
quit
jmp $3d0

message !tx "HELLO WORLD!",$8D,"hello world?",00
-------

Also, for ACME to find the a2txt.bin file, used for text conversion, it also needs to be in the project's main folder/directory (where the source files are as well). As soon as I copied it into that folder, it also got added to the Project.

Hope that helps others get it up and running. I believe the author was using the MADS assembler. I pulled the source down to compile it, but it appears to be in Pascal, which threw me for a loop. I figured it would take me too long to figure out how to get a working Pascal dev environment going, so I tried ACME instead, based on Blurry's recommendation. It compiled cleanly the first time.

In article <f52a78fe-6f39-434f...@googlegroups.com>,
I use the command line interface from make:

<http://applecommander.sourceforge.net/acguide.html>
<http://home.roadrunner.com/~jbmatthews/a2/cross.html>

David Schmidt recently added ant support (Thanks, David!):

<http://applecommander.sourceforge.net/acant.html>

Within the AppleCommander source, DiskWriterTest shows how to create,
write and save disk images:

test/com/webcodepro/applecommander/storage/DiskWriterTest.java

<http://applecommander.cvs.sourceforge.net/viewvc/applecommander/AppleCommander>

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

One last critical element that I inadvertently left out--

You have to change the binary type that ACME outputs from cbm (default) to plain. The cbm binary puts an additional 2 byte header on the file automatically that will ruin a perfectly good apple executable.

To take care of that, go to Eclipse Preferences then under Assembler->Apple II Computers and click on the ACME tab. In the Parameters text box, it will have this by default:
-f cbm -o ${outputFilePath} ${sourceFilePath}

Change it to:
-f plain -o ${outputFilePath} ${sourceFilePath}

I also changed the next parameter "Output Folder" to use the Source Folder instead of a Temporary one, which caused also caused some errors for me.

Hi everybody,

So after failing to find a proper forum for contacting Apple II coders, it seems I finally found it. Let's see I've I remeber how to use news groups (it about 18 years since I last posted something :-)

Cheers, Peter/JAC!

Damn! You found our hiding spot! :-D

Thank you very much for Wudsn! Your support has inspired me to add some things to Jace that I've been putting off for way too long. This week: RamFactor emulation. Next week: Shooting for 100% mockingboard emulation. After: Overhaul of the UI, addition of indicators for hard drives, floppy drives, serial ports, etc.

It will be my goal after that to get out the first Apple // MegaDemo unless one of you awesome folks beats me to it. ;-)

-B

Hmm, I posted this some 20 minutes ago but it does no appear. So maybe this becomes my first double post ...

What assembler are you recommending?
====================================
I recommend MADS because it supports ".PROC/ENDP" and ".LOCAL/ENDL" and I heavily use them to structure my code. And is the best tested compiler for the IDE because I use it myself for everything. In addition I have binaries for MADS provided for Linux & Mac in the "compilers.zip" download on my web-site.

How to associate my .a file as an APPLE2 type?
==============================================
How to associate the file extension with the editor via the preferences is described in this video tutorial
http://www.youtube.com/watch?v=QgQOle36hRA.
I also recommend the other tutorials of course.
Especially the tutorial 6 will show the power of using MADS with WUDSN when it comes to structing source.

Why do I have to put ;@com.wudsn.ide.asm.hardware=APPLE2 in the source file?
============================================================================
This does not assicate the file type with the editor (that is done in the preferences, see before)
This is used to tell the compiler which is the target platform.
Every compiler has a default platform (see the online help in the IDE) but can also be used to every other platform.
Therefore you have to specifc the target platform in the source.
It is used to fine the correct compiler and emulator setting, which can be different per platform.


How do you get disk images working?
===================================
Apple II is the first platform for which the IDE directly creates a bootable disk image and puts the executable file (which was created by the compiler) onto the disk. Internally AppleCommander is used for this. Disk images are always in DOS 3.3 format (the IDE copies an bootable image to the output folder and then adds the executable file there). Support doe other DOS version is currentl not there/planned because I want to keep the number of configuration options small.

The IDE needs to know the load address of an excutable file in order to store this information in the directory entry. In order to detect the load address from the excutable file, the IDE evaluate the file extension. Supported extensions are ".b", ".prg" and ".xex".

// // AppleDos 3.3 binary file:
// start-lo,start-hi,length-lo,length-hi,data
address = getWord(outputFileContent, 0);
length = length - 4;
content = getData(outputFileContent, 4);
} else if (fileName.endsWith(".prg") && length > 2) {
// C64 program file
// start-lo,start-hi,data
address = getWord(outputFileContent, 0);
length = length - 2;
content = getData(outputFileContent, 2);
} else if (fileName.endsWith(".xex") && length > 6
&& ((getWord(outputFileContent, 0) & 0xffff) == 0xffff)) {
// AtariDOS 2.5 binary file:
// $ff,$ff,start-lo,start-hi,end-lo,end-hi,data
address = getWord(outputFileContent, 2);
length = length - 6;
content = getData(outputFileContent, 6);

So when using the different assemblers, make sure the executable file name and content match this rule. if you used MADS and configure ".xex" as file extension, everything will work out of the box.

How can I use other emulators?
==============================
You can "re-use" the existing tabs and simply specify another emulators' executable.
If you use "User Defined Application", you can specify whatever you want.
Note: When using "User Defined Application", no disk image is created or updated.
You can use this setting to have you own script which put the executable file onto a disk image of your choice using AppleCommander for example. Again, beware of the file content/load/run address.

What about VirtuII?
===================
Configuration will be included by default in the next update.

This does not assicate the file type with the editor (that is done in the preferences, see before). This is used to tell the compiler which is the target platform. Every compiler has a default platform (see the online help in the IDE) but can also be used to every other platform. Therefore you have to specifc the target platform in the source. It is used to find the correct compiler and emulator settings, which can be different per platform.
Apple II is the first platform for which the IDE directly creates a bootable disk image and puts the executable file (which was created by the compiler) onto the disk. Internally AppleCommander is used for this. Disk images are always in DOS 3.3 format (the IDE copies an bootable image to the output folder and then adds the executable file there). Support for other DOS versions is currently
I'll add it in the next update if Rich provides me the correct full command line :-)

Welcome Jac/Peter. Glad that I caught up with you on AtariAge, and thanks for integrating Apple II support into WUDSN. This helps a lot.

Maybe someone will get motivated and code a native HGR/DHGR graphics editor to use in Eclipse/WUDSN? I nominate Mr. BluRry!

Let's see, Eclipse is Java. Apple Game Server is Java. Ok. AGS already has the image conversion logic for all Apple 8-bit formats, including the 131-color "flicker mode" images where you take two different images and flip between them on each VBL interval. Since the Apple // is 60fps it doesn't look as bad as you might think. :-D

So I guess all that is missing is to clean up the source a little and hand it over to Peter ;-) Soon... soon... First I need to get this darned RamFactor to work. Stupid evil undocumented i/o registers...

-B

Is there a demo of this I could see? Are you just page flipping? How
does it create 131 colors? Thanks.

Technically, it doesn't create 131 colors. But your brain perceives them to be greater than 16 at least. I have a demo of it on my older site, which is completely broken and needs to be migrated over:

https://sites.google.com/site/brendanrobert2/pseudo-colorexperiment

Anyway, I confirmed that the disk image is still available there. Give it a shot! :-)

I want!

and your more than welcome to some space on my domain if you dont mind a redirect

Oh, it's not a space thing really -- it's really more a time constraint thing. :-) It will come together in its own good time, but making a fully functional emulator was a higher priority for me. Must be some sort of sadistic thing I must want to do to myself. :-D

-B

what about your fake color code? I have been thinking about doing the same thing for a long while now ... but ya know ... its a time thing

>"and replaced it with a photo of a hot chick"
That's the spirit! :-)

I've watched too many demos. ;-)

:-) The code is part of the Apple Game Server codebase. I never made a polished conversion tool, but the program to convert images does exist in some form. You have to change the path of the image being converted in the source code and then run program. It's very crude but it gets the job done.

-B

I have been wanting to do this with the debugger in Applewin for a while..

I use Merlin8, because I know how to use it. You have to tell Merlin to output the assembly text to a file (using printfiler program on the Merlin disk). Then go into ciderpress, grab the file that merlin created, and then tell the debugger to use that text file for source level debugging.

Would be really nice if this was automated.


Rich

Hello!

I am having issues configuring the MADS compiler to choose APPLE II as the output target. I am using Eclipse version 3.7.2. The only icon I see for the compile and run is for teh Atari. I beleive I have MADS configured correctly for Apple II. The output file extension is .b The associated application is Applewin. However, when I attempt to compile and run, it targets the Atari, the file has .xex extension. I am confused.

Tim

Hi BLuRry, any specific reason you wanted Ramfactor emu vs Apple 1 MB memory expansion card? ... which is documented.

Great question. Yes, for totally selfish reasons: I have a RamFactor card in my real //e. A RamWorks-style card would probably be easier to implement, but the slinky-style ram was particularly attractive because you can read the memory from start to finish without bank-switching. The apple memory card is well-documented but I liked the partitioning support of the RamFactor, plus it can go up to 16 megs.

I spent quite long time on Apple Game Server, which is essentially a serial-based streaming protocol supporting compression and allows for both graphics output and hooks to call external commands via JSR or JMP. For producing a demo, this translates quite nicely: I can test the demo over a serial port with the Apple Game Server code. For a final production, all I have to do is change the serial reads to read bytes from the slinky ram. So there would be a loader stage to populate the data into the ram card and then the playback part would just pull data back out and handle it accordingly. My initial experiments show that some level of full motion video (lo-res or double lo-res) might be possible if the scene changes are low -- or double-hires if there is very little complexity

-B

Hi Tim

You need to put the following line at the beginning of the file, close the file and open it again.
; @com.wudsn.ide.asm.hardware=APPLE2
Then you should see the Apple icon in the toolbar instead of the Atari icon

I'm having an interesting time with Wudsn!
Using the MADS compiler.. I can compile, disk is created..etc.

I'm lost with the whole 'org $2000-4' stuff and the 4 byte header. I understand it, but it's not working like I think it should. it always throws two bytes before my code no matter what. So when I BLOAD my code at say $2000.. I get two bytes, the 4 byte header, then my start code.. so really my ORG should be $2000+6. Strange!

So as of right now, I took out the 4 bytes and made my ORG $2000+2..or else my JMPs are 2 bytes off now all my JMPs are going where they're supposed to go! I'm sure I'm missing something obvious, right? At least for now, I can bload the code and $2002G and it works!

Jim

I am also using the MADS assembler. What works for me is to include the " ; @com.wudsn.ide.asm.hardware=APPLE2 "as the first line. Use the correct ORG address and do not try to add bytes for the DOS header. The other fix is on tghe MADS assembler preferences, change the output extension from ".b" to ".xex" and let the magic happen!

Tim

ps. Though I am of Polish descent, I cannot read Polish! Does anyone know of an English translation of the MADS documentation??

Not sure, but if you want to use a different assembler Acme works really well also. You will need to let it save files with the .prg extension and the @com.wudsn.ide... line is also equally important.

There is one additional thing I would like to mention, and it's pretty significant. If you set up Jace to point the mass storage device drive at a physical directory (you will need to type in the path, it currently doesn't let you select folders in the picker) then a virtual read-only volume will be created. There are bugs in the implementation that prevent copying files with Copy ][ Plus, but you can at least BRUN files in there and so on.

I changed my ACME preferences to save the file in raw/plain format and append the suffix .bin#6000 to the name of the files. With this, Jace will pick up the extension .bin and set the prodos type to bin ($06) and the load address as $6000. I also changed its save path from a temp folder to the folder that Jace is pointing to. Now I can just hit "compile" or ctrl+shif+9 and flip over to jace to brun the program. This speeds up development immensely.

If you are working on a single-load program that is too big to play nicely with Prodos, you can change the extension to #06xxxx where xxxx is the load address and then use F5 to start the program directly sans operating system in Jace. I know this is inconsistent with the prodos virtual drive format (.bin#xxxx) but I will make it a point to work on this in the near future.

-B

** YAY!!!!
I don't understand how the .xex is different, but it's perfect! Thank you!!

Jim

I think if've already posted it earlier but since I cannot find it myself.. again some explanation:
The routine which puts the compiler output file onto the disk needs to know which executable format the file has. This is determined based on the file extension. 3 different formats are currently supported.

if (fileName.endsWith(".b") && length > 4) {

Denis informed my that there is an issue with the generated HELLO in some cases.
It's due to the bug in BRUN which causes crashes if COUT is used.
http://www.textfiles.com/apple/ANATOMY/cmd.brun.bload.txt

His suggestion was changing the HELLO from

10 PRINT CHR$(4);"BRUN WORLD"

to

10 PRINT CHR$(4);"BLOAD WORLD" : CALL <address>

While this is possible (and mostly works already), I see the problem that the HELLO is loaded to $800 and if BLOAD overwrites this ares, the CALL <address> will be overwritten too, causing a crash. BRUN does not have this issue by nature.

I am not familiar with the Apple II memory map and conventions.
Does the HELLO have to start at $800?
Is there something like the "normal" load address for BLOAD programs?
...

Not really. A lot of stuff loads at $07FD, actually.

You can make HELLO reload itself elsewhere, but it requires a few pokes.

Usually BRUN is fine - especially with stuff that loads low.

-uso.

If HELLO is always a BASIC program, you'd better keep it at $800 for
simplicity.

As for BLOAD programs, the normal load address depends on program length,
data storage requirements, and whether or not the high-res graphics screens
will be used. Most ProDOS programs start at $2000.

--
]DF$
Apple II Book: http://macgui.com/newa2guide/
Mac GUI Vault: http://macgui.com/vault/
Usenet Archive: http://macgui.com/usenet/

Thanks. Had a look at the Applesoft file header etc. again and found that I cannot even influence it, so it loads to $800. And considering what was stated above, I'll keep the new "BLOAD...:CALL" sequence and will document that "Thou shalt not Bload to $800" :-)

I've' had a good time at this year's Fujiama Party again and had the possibility to present WUDSN IDE to a lot of people. All of the are now happy "customers" with an environment where they can play around with assembler so easily. When I installed the previous version of the IDE, I found a bug in recent versions of Eclipse which is due to an incompatible change "plugin.xml" file handling. The bug causes the toolbar button to be invisible and locks up the "Customize Perspective" dialog. Therefore I decided to release a new version which contains all the fixes and round offs I have implemented in the past 12 months. There are in particular many Apple related fixes.

Editor
- Auto completion for ".PROC" now adds "RTS" before ".ENDP" in MADS
- Auto completion for ".LOCAL" now adds ".ENDL" in MADS
- Clicking on the link to a non existent file now asks for creating the file. This simplifies creation of includes during refactoring.

Assemblers
- Error message assignment to include files now normalizes the file separator before comparison, making it more robust in case of compiler bugs (e.g. MADS 1.9.4)

Emulators
- Virtual ][ emulator added for Apple ][

Installation
- Screen shots and descriptions updated to reflect the lasted version

FAQ
- How do I compile into ROM images? added
- How do I compile into disk images? added
- How to run a makefile script instead of an emulator? updated

Site
- Section "Further information on assembler programming" added to the installation section of the IDE. The new section contains links to readily formatted source code includes and examples.

Fixes
- The toolbar icons now work correctly with newer Eclipse versions
- Atari 8-bit Graphics 12 Converter works again
- Graphics editor now properly closes input stream for image files
- Empty selection and too large number no longer lead to exceptions when opening the context menu for "Convert..."
- Pressing refresh in the graphics converter now always updates the image pane correctly and not only if the size has changed
- Inline repeats like ":64" in MADS are no longer detected as labels
- Hex Editor now correctly detects erroneous COM files in case the segment length exceeds the file length (by one)
- Disk images (for Apple II) are now updated also if only "Compile" instead of "Compile and Run" is used
- Apple Commander integration is now part of the installation, as it should have been with 1.6.3
- The HELLO program generated for the auto-start disk images of Apple II now displays a title and uses "BLOAD/CALL" instead of "BRUN" because of this bug in Apple DOS

10 PRINT "Loading <title>" : PRINT CHR$(4);"BRUN WORLD" : CALL <address>

Thank you for keeping Wudsn alive with this release! Great work as always!!

I have started on a JavaFX-based game editor for an Apple game called Outlaw Editor. Please feel free to use any of that code to add image editing for the Apple platform as well! I also have image dithering routines that allow you to copy-paste images, performing automatic conversion from any raster-based image format to Apple hires and Apple double-hires graphics. The dithering is designed to take advantage of NTSC artifacting to produce the smoothest possible line art conversion!

https://github.com/badvision/lawless-legends/tree/master/OutlawEditor

I have been unable to get Wudsn to create a disk image when I select compile and run from the assembler menu. Just assembling completes without errors, and I get a .b file in my project directory. Is there anything I need to do to get the disk image creation process working? I am running Kepler Service Release 1 using ACME 0.91 as the assembler. I have tried using JACE and Virtual][ for the emulator, and while both emulators work fine when not run from Wudsn, neither of them start from within Wudsn. I would guess this is due to the fact that a disk image is never created.

Thanks.

Hi Brad,

Please post the output of the console window and the first part (16 bytes) from the ".b" file. Have you added the "@com.wudsn.ide.asm.hardware=APPLE2" in the source annotation because only then Apple Disk images will be generated.

I also update the FAQ section http://wudsn.com / WUDSN IE / FAQ / How do I compile into disk images?

- Peter/JAC!

Here is the source I am trying to work with:

;@com.wudsn.ide.asm.hardware=APPLE2

*=800

LDX #12
LOOP LDA MSG,X
JSR $FDED
DEX
BPL LOOP
RTS
MSG !text "!DLROW ,OLLEH"


Here is the output of the console window:



Compiling for hardware APPLE2 on 10/14/13 7:43 PM: /usr/local/bin/acme -f plain -o /Users/8bitbrad/Documents/workspace/hello1/hello1.b /Users/8bitbrad/Documents/workspace/hello1/hello1.a

Compiler 'ACME' output:


I'm not sure how to give you just the first 16 bytes of the '.b' file (I'm not really a programmer). If I 'cat' the '.b' file I get this:

8bit:hello1 8bitbrad$ cat hello1.b

?
?, ????`!DLROW ,OLLEH

Try:
head -c 16 hello1.b | od -t x1

Cheers,
Nick.

Using -plain will generate a binary without any address or length information but that's what is expected at the begin of a ".b" file. If you want to use ACME, my suggestion would be the following:
- use "-cbm" instead of "-plain" in the compiler options.
- use ".prg" as file extension instead of ".b"

Then it'll work (just tested here and yes, the letters are flashing :-) because the compiler does the job together with the IDE. Alternatively you can create the ".b" header manually, but I don't know how to write that in short in ACME.

In MADS it would be

opt h-f+

org $300-4
.word main
.word .len main

.proc main
...
.endp

But as said above, just used CBM mode and you'll be fine.

I tried this, but it still didn't work. I used -cbm instead of plain and .prg as the file extension. Compile completes and outputs a .prg file, but no disk image is created.

I didn't see any 'flashing' letters.

https://www.dropbox.com/s/atjketzwr5655jx/Screenshot%202013-12-29%2021.08.49.png

I am using MADS and have having the same issue. it will create the .b output but never runs AppleWin.

I would love to get this up and running.

Testing Google groups again after quite some time. Do you still have any issues?

On a virtualbox Windows 7 machine, changing to output extension to .xex solved the problem, but on a real Win 7 machine, it still doesn't work.

Is there a chance to include this in the default configuration? I kept the WUDSN installation unused for years because some acme code I was trying did not work because of this. I finally decided to take the time and see why it happened and this was the solution. But why in heaven isn't this the default ACME configuration for the Apple II???

Hi,
I'm not using ACME myself, so I'm happy for all input and examples. When I check the current WUDSN version "-cbm" is the default for ACME. The ".b" is coming as the default for executables on "APPLEII", so it is not ACME specific. Of course you can change it, but ".b" is used by the IDE to detect that conversion to .dsk is required.
Please contact me in case if further questions also directly as jac at wudsn.com