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

[Roger Taylor]

At 05:39 AM 5/29/2007, you wrote:
>Boisy Pitre wrote:
>><snip>
>>Robert Gault is now successfully building ToolShed for Windows using
>>the Borland Turbo C++ product.  It should be a fairly simple exercise
>>to ascertain why rlink isn't working.
>
>Let's clarify that. I can create programs that initially seem 
>alright. However, while os9.exe works when creating NitrOS-9, 
>mamou.exe does not on my WinXP system.

The version of mamou assembler that I have is generating phasing 
errors for some rather simple source code that both CCASM and CASM 
are having no trouble with.  For this reason, I'd like to aquire a 
newer version if available.


>Mamou is failing with the ldq opcode and with values such as 
>#label-*-2 and possibly other opcodes. It would be very helpful if 
>some other WinXP user would try compiling the Toolshed programs with 
>either Turbo C++ or msys so I can eliminate the possibility of 
>system to system problems vs. mamou source code problems.

I know how he feels.  The expression evaluator in CCASM is quite 
powerful, but not necessarily coded in the most efficient way (but it 
works great).  I used high-level compiler-like statements for those 
routines and later converted some of the code to pure 80x86 ML.  The 
parent language HLA is actually part compiler/part assembler, so I 
can have the best of both worlds.  The expression evalulation 
routines took way more time than it took to write the other parts of 
the assembler.

>The rma.exe, rlink.exe, and decb.exe produced by Turbo C++ have not 
>yet been tested on my system.

My copy of decb.exe is corrupting any files copied to the virtual 
disk as type -2 (binary).  For instance, the Projector-3 project 
included in the Rainbow IDE is frequently altered in my tests to use 
various other imaging tools and assemblers, etc. and while 
imgtool.exe does a good job, it can't translate ASCII BASIC to 
tokenized BASIC like decb.exe does, so I have to use decb.exe since 
several of the P-3 components are in ASCII BASIC in the IDE and I'd 
like for them to be tokenized when they are copied to the final 
program disk.  I know it's not necessary, and imgtool.exe can still 
be used to copy the BASIC over as ASCII BASIC, those programs 
obviously load slower.

While I'm on the subject, if anyone knows of a C compiler for 32-bit 
Windows that produces 6809 source code, please e-mail me a copy with 
the linker?  16-bit programs won't work from the IDE unless somebody 
knows of a trick.  I use CreateProcess from the Windows API to launch 
command-line tools.  I really want to do some 6809 
compile/assemble/link testing.

Yesterday I made more improvements to the Rainbow IDE and fixed some 
bugs that have gone unfixed for years now.  Pathnames with spaces 
should work now with all the tools called on, and also the os9.exe 
command now copies to CMDS/program.r, although I had to force that by 
calling my output object file "CMDS/program.r" which is cheating, 
ofcourse.  :)  Eventually I want to be able to target directories 
within any virtual disk capable of receiving files that way.  Right 
now I'm cheating by using "CMDS\main.r" as the object name (notice 
the BACK slash for Windows) because it writes to that Windows folder, 
then all references to that file later are the same, and I do a quick 
\ to / conversion right before calling os9.exe.  So what happens is 
CMDS\main.r is copied to the virtual disk's CMDS/main.r path.


-- 
Roger Taylor