[Coco] Rainbow IDE update (kinda lengthy, but interesting)

[Roger Taylor]

As of tonight,  You probably have already heard me talking about some 
of these options... but some are working better now and there's some 
new options:

Source filenames with spaces in them are legal now.  Quotes are added 
around the filename before calling the assembler, compiler, etc. for 
that file.  This was already done for some files in some of the tools 
used by the IDE, but CCASM lacked this feature in the past, like:

cm my game.bin

This was formerly perceived as:

"my" was seen as the source code file, and "game.bin" was seen as a 
command switch/option that was not recognized.  When quotes are added 
around the file, CCASM knows that it's one option, the first option, 
which is always the source file.  In addition, the output object 
switch like -o=destination object file (which is an illegal switch 
for the same reason I mentioned), will allow quotes now and work just 
fine:  -o="my game.bin".  Some people use spaces, but when the IDE or 
CCASM previously griped or aborted out without giving the reason or a 
fix, it was confusing and I got lots of bug reports.  I hope this 
cures a lot of filename and path issues.  So far, my tests are 
working pretty good when I use spaces in pathnames.

So, to sum this up, the following is possible now with CCASM:

cm "some source code with spaces in it.asm" -o="the output object.bin"

Other tools like decb.exe, os9.exe, imgtool.exe already handle quoted 
filenames well, but CCASM couldn't do this previously because the 
language that it's written in doesn't have that feature in the 
arg.v() function which parses the command-line string.  It took me 
all these years to discover this bug!

Rainbow's new "Builder" add-in support allows any kind of source code 
processor like an assembler, compiler, linker, etc. to be added to 
the IDE by copying the builder's folder to a subfolder in Rainbow 
IDE\Builders\.  When the IDE starts up, it catalogs the Builders 
folder and adds them all to the IDE panel, along with custom object 
types, modes/switches, etc. for those builders.  In other words, each 
builder can have it's own small or large list of options that appear 
in the panel when you change between builders for any source file in 
the project.

Several "psuedo objects" are also available that appear for all 
builders.  In the left sidebar, you'll see those object types in 
addition to the normal object types for each builder.  These object 
names begin with "+" to mean that the IDE doesn't really tell the 
builder to output the object type, but rather other tools are used to 
fake a build of the object.

+COPY :  On a build, the source file outputting the +COPY object type 
is just copied into the build folder as if the assembler did it, and 
possibly with ASCII CR/LF adjustments.  This can also be used for 
writing BASIC programs that you WANT to be written onto your virtual 
disk as ASCII BASIC.  This would be good for programs written that 
will run on a CoCo, Dragon, or other CoCo clone that doesn't use the 
same BASIC program compression.

+BASIC : On a build, the source file is copied into the build folder 
as-is, THEN the disk imager used for the project knows to attempt a 
copy onto the virtual disk using its built-in ASCII-to-BASIC 
tokenizer.  Since imgtool.exe doesn't do this yet, decb.exe must be 
used for those kinds of projects.  I tested this tonight and it works 
great.  DECB.EXE uses the -t option for this feature.  I didn't use 
+COCOBASIC because we want the IDE to eventually be able to tokenize 
BASIC programs for any vintage computer OS that imgtool.exe might 
support one day.  That is, if imgtool.exe ever supports this like 
decb.exe does, you'll be able to write binary BASIC programs for 
other computers than just the CoCo or Dragon, and the IDE will do a 
psuedo build to that object type.

Assemblers (a builder TYPE) can define their own target CPUs.  Since 
TASM can assemble for many 8-bit platforms, lots of CPUs will appear 
in the panel when you select that assembler.  Some of the CoCo 
assemblers that do 6809 and 6309 will show both of those CPUs.  This 
is useful for those who want to make absolutely sure their CoCo ML 
programs don't contain any 6309 code by mistake in the final 
build.  Ofcourse, the assembler used is in control of the actual 
enforcement.  CCASM currently doesn't deny 6309 codes, so it doesn't 
matter what CPU type you select for a given source file.  I'll do 
some work with CCASM eventually for handling this issue.

Switches and Modes are separately defined for any kind of 
builder.  For instance, CCASM's .ini file defines -l for Listing On, 
-d for Debug On, -s for Symbols Output, -sa for All Symbols Output, 
etc., so those options will appear in the panel when you select 
CCASM.  CASM and MAMOU or any other builder may not show the same 
switches or even the formal names for those switches.  For instance, 
CCASM allows ROM builds of a given size like 1K, 4K, 8K, and even 
256K for huge EPROM projects.  The resulting .ROM image will be 
padded to that size.  As far as I know, CASM and MAMOU just does a 
ROM-like build but you have to force the size from within your source 
code using FCB's or another way of padding.  So, CCASM is probably 
the preferred assembler for creating ROM images with less hassle.

What if you want that ROM image to not launch and run, but instead 
get copied onto a virtual disk in the project.  No problem!  Just add 
a virtual disk to the project by clicking the + buttom in the panel, 
then select one of the disks using the drop-down listbox.  That's 
it.  When M.E.S.S. launches, the ROM will not run, and you can type 
DIR from Disk BASIC and see that it's right there on the disk.  Now 
you can write that virtual disk to a real CoCo floppy and use the ROM 
file with one of the CoCo EPROM burning programs.

*** What's the best part of all the above to keep it from being 
confusing?  Rainbow handles all of the logic as if it knows what 
you're thinking by letting you select a few options in the left 
sidebar.  The listboxes all work in harmony to do all the work for 
you and create the commands for the tools used by the IDE, whether 
it's an assembler, compilers, disk imager, etc.  The seamless 
one-click build is still the goal, even though you originally do need 
to set up each source file in the project with a few parameters.  ***

I have received some suggestions for Rainbow and CCASM and will be 
acting on these the best I can in the coming days and I hope to get 
Rainbow IDE 2.0 released before the end of June.  A beta version will 
be available first for a few weeks to some key testers.

Now, we need compilers, linkers, BASIC compilers?, and other neat 
tools I can test out.  Any ideas???



-- 
Roger Taylor