After a couple of days away from my Retrochallenge, I decided to dive back into trying to get that damn Z80 CPU to listen to me from MS-DOS. A few days back, I actually stopped in frustration when I realized that I would definitely need to do some x86 assembly language programming to get things moving forwards.
I had posted a scanned page from the Rainbow 100′s CP/M technical documentation that seemed to outline how to pass a message to the Z80 properly:
The page outlined the values for the registers of the 8088 when trying to pass arbitrary code to the Z80. To be honest, I have some serious doubts about the above scheme working when in MS-DOS; I can’t seem to see where anything similar is done in the MS-DOS BIOS code to trigger the Z80 to perform disk access. There is a good chance that the CP/M BIOS is performing some extra work behind the scenes after the above call is made. However, the method above is easy enough to try.
I foolishly assumed, though, that I would be able to first set the values of the 8088 registers and then signal the 8088 output port from C. This idea is, of course, nonsense because C is too “high-level” to hope that any particular register would persist between being set and my calling a C outport() function. I needed to use assembly, which annoyed me enough to stop for a bit.
Yesterday I decided to dive back in. However, I did run into some speed bumps. Normally on the Rainbow I work with Turbo C as opposed to Microsoft C. This preference is based on:
- Turbo C’s MAKE utility actually works (unlike Microsoft’s lobotomized MAKE)
- Turbo C’s directory layout is considerably simpler
For an assembler, things became a bit trickier. I do also have Turbo Assembler, but, when I ran it yesterday, I found that it did not work on the Rainbow at all. It wouldn’t even run under Code Blue. And why is doesn’t it work?
Borland is mildly famous in DEC Rainbow circles (is that a thing?) for being complete jerks. Borland produced a number of compilers and applications for the Rainbow as native programs, both under MS-DOS and CP/M. However, when Turbo C 2.0 was released, things went bad. Rainbow users who bough the software were horrified to find that this “MS-DOS compatible” compiler didn’t run at all, while previous versions ran just fine. Borland was completely silent on the issue, too.
One enterprising Rainbow user was able to determine what was actually happening. Internally, the Borland compilers were unexpectedly using MS-DOS interrupt 0×18. This interrupt is relatively harmless on an IBM PC, but it is used for communications ports on a Rainbow. There was no reason for Borland to choose 0×18 in the first place; it is entirely arbitrary, which makes Borland’s choice so frustrating. This helpful Rainbow user, though, was able to generate a set of patches for the Turbo C executables, the compiler and preprocessor specifically, that changed their internal interrupt calls to use 0×60 instead. The same user went on to generate patches for a number of other Borland tools as they continued to use interrupt 0×18 all over their development tools, including Turbo Assembler..
My copy of Turbo C is obviously already patched. However, I never did take the time to patch Turbo Assembler, apparently. Additionally, I have no hard-copy documentation for any Borland tools. The unpatched assembler and the lack of immediately available documentation convinced me that it was time to move on to Microsoft’s tooling.
I spent yesterday transferring Microsoft’s Macro Assembler and C Optimizing Compiler onto my Rainbow 190. All these packages do add up to a considerable amount of disk space relative to its 20MB disk. However, my 190 is not one of my long-held Rainbows, so it started the Retrochallenge with a relatively empty disk, only containing my essentials:
- MS-DOS 3.10b
- Borland Turbo C 2.0
- BinkleyTerm 2.40
The transfer of MASM to the Rainbow was simple and fast. Although the archive was about 680KB in size, it goes relatively fast transferring it from a GNU/Linux server via ZModem at 19200 bps. On the other hand, my stripped-down MSC 5.1 distribution, weighing in at about 900KB, was sitting on another Rainbow with a notoriously (in my house) slow hard disk. I couldn’t transfer between the two Rainbows using ZModem because the receiving Rainbow would time out prior to the “slow hard disk” Rainbow even accessing the file to transfer.
Whenever serial transfers become problematic, it’s time to pull out old, slow, and reliable Kermit. If ZModem were a sports car, Kermit would be a car that won’t start and is being pushed manually up a steep hill. In contrast, though, Kermit provides drastically more reliable error checking than ZModem to the point of overkill. Back in the BBS days, I rarely had any issues with ZModem, but occasionally the speed of disks can become an issue, requiring a slower transfer rate. I started the transfer and left the two Rainbows to talk it out.
In summary, I now have a fully function Microsoft C and MASM environment all set up and functioning. Hopefully I can get on with my work.