[Coco] Rainbow IDE is building to OS-9 virtual disks

[Roger Taylor]

Some news on Rainbow...

Tonight I have a simple OS-9 project that launches an OS-9 boot disk 
in M.E.S.S. with my object file sitting in the root directory.  When 
OS-9 boots up, I hit ENTER to get past the clock setup, then type 
DIR, and there's my object file.  Tee hee.  If I go back to my source 
and change the output object name to another name and rebuild, the 
new OS-9 disk will only show the new filename since a template disk 
is used (I used a boot disk image).

A new "add template disk" button is in the left sidebar now that lets 
you browse to an existing virtual disk of any kind compatible with 
imgtool.exe, decb.exe, or os9.exe, then that disk is copied into your 
project folder.  The IDE remembers that it's a disk not to be created 
or formatted, then you can send output objects to that disk quite 
easily by selecting the disk name for the current source code 
file.  Names of these kinds of disks will start with "~ " like "~ 
nitros9.os9" in the list to show you they are template disks that are 
copied to a new temporary disk instead of creating a blank disk.

In other words, when you build your project, the template disks are 
copied to temporary disks for receiving your project objects.  This 
keeps os9.exe from generating Error #216, etc. if your output object 
filenames already exist on the disk(s).  Since you're starting with a 
fresh disk on each build, and as long as you don't try to send a file 
to the disk that overwrites an existing file, os9.exe does the job 
and stocks your disk with whatever objects you want.  However, I 
can't seem to write a file such as "CMDS/main.r" "./CMDS/main.r" 
"/CMDS/main.r", etc.  Boisy, can os9.exe follow paths?

RMA is used in this test project, which is currently just sending the 
ROF (.r) file to the OS-9 disk, so I've got to work on the Linker 
support in the IDE now and get this working like it should.  That is, 
after all of the .asm files are assembled, a Linker pass would do 
it's job.  I'm not really sure how this will work right now but the 
idea is to tag each file with dependency on another file, and the IDE 
would do the job without any makefile.

Linker support in the Rainbow IDE will take a lot of work, but not 
much more than what I've already put in for the recent overhauls and 
improvements.  So far, I think a 3-pass system should do the trick 
(Compilers, Assemblers, Linkers).  When you add a builder to the 
system you tag it was one of those types and the IDE should do the rest.

A "BASIC Compiler" builder has been added which currently has 2 
object types of "+TOKENIZED", and "+COPY" which are psuedo builders 
that the IDE does instead of calling a real 
compiler/assembler/linker.  If your source file is in TEXT, you can 
choose to tokenize it as a binary BASIC program, or just send it over 
to your disk as an ASCII BASIC program.  This builder is limited 
right now with no true abilities to create a machine-language version 
of a BASIC listing, but that should come sooner or later.  When it 
does, that .exe file will be placed in that builder's folder, and it 
will be part of the system.  Also, all builders automatically get the 
+COPY object type added to their object capabilities, as a 
convenience to easily choose to copy any source file over to the 
destination media as-is.  A "INTERNAL" builder is also added to the 
IDE that has "+COPY" as one of the object types.  So, there's plenty 
of ways to copy files from your project right onto your destination 
disks, no matter what builder you've got selected.

In other tests, I did add the Borland C++ compiler as an assembler 
which worked, but since no library or includes are possible at this 
time, the readout obviously wasn't pretty.  :)  But Rainbow did TRY 
to compile a sample source file and output the specified object based 
on what all it new about the compiler (from it's rainbowconfig.ini file).

It's getting very interesting now, and the IDE is getting more 
powerful.  If anyone knows of a 32-bit Windows console compatible 
6809 C compiler, please let me know so I can do some testing.  Right 
now I have a 16-bit MS-DOS version that won't run when called from the IDE.

-- 
Roger Taylor