Home Page Forums MAME MAME Requirements?

Vas and crazyc have been discussing the state of the Rainbow driver in the shoutbox and commented that the driver's not booting the operating system because of differences in the interrupt handling between the A and B models.

On the "B" model, a few ROM patches allow the machine to skip hitherto unemulated parts of the Rainbow. Bavarese has furnished me with the equivalents for the "A" model, and I've issued a pull request for them. This allows the emulated Rainbow 100A to boot from disk cpm860mb.td0, it will also allow mdos201.td0 at least boot as far as the system message, but it will hang after loading track 8.
It appears that at least this CP/M-86/80 image is not yet available, I've uploaded an archive with my Rainbow disk collection to the FTP.

I am in touch with a collector who has what he describes as "the usual" Rainbow software "Lotus, Wordstar and learn rainbow and diagnostic disk.". Would it be useful to see if I can get images?

It would be great if you could source those images - while I have Wordstar, there are no disk images, and I seem to be missing Lotus (probably 1-2-3) as well. Any disk image is great, the least we can do is compare them to the ones we have in the softlist and verify them that way.

Thanks!
Robert

Will see what I can do. Also leaving a link here in the forum to this VCFED thread which has recently come to life and includes some links to Rainbow software archives:

http://www.vcfed.org/forum/showthread.php?62912-Rainbow-100-Disk-Image-Files

I've recently acquired a Univation disk controller, but no drivers for it... Does anybody have Univation drivers, distribution disks, etc? The disk that's connected to it is toast.

BTW, I've spent some quality time with the Rainbow 100B schematics and have produced this: https://github.com/bsdimp/v7/blob/main/notes/rb.md which describes all the low-order ports...

So I've tried to get the latest mame going, and I get a message about no image attached to drive C and I can't boot Venix. It boots fine with a July 5th, 2019 mame

I build like so:

I've tried it with and without the workarounds that I used before, forward ported to new ROM_FILL

--- a/src/mame/drivers/rainbow.cpp
+++ b/src/mame/drivers/rainbow.cpp
@@ -3437,6 +3437,16 @@ ROM_START(rainbow)
ROM_FILL(0xf4303, 1, 0x00) // [0xf4000 + 0x0303] disable CRC check [100-B ROM]
ROM_FILL(0xf535e, 1, 0x00) // [0xf4000 + 0x135e] Floppy workaround: in case of Z80 RESPONSE FAILURE ($80 bit set in AL), don't block floppy access

+#if 1
+ ROM_FILL(0xf4000 + 0x198F, 1, 0xeb) // cond.JMP to uncond.JMP (disables error message 60...)
+
+ ROM_FILL(0xf4000 + 0x315D, 1, 0x00) // AND DL,0 (make sure DL is zero before ROM_Initialize7201)
+ ROM_FILL(0xf4000 + 0x315E, 1, 0xe2)
+ ROM_FILL(0xf4000 + 0x315F, 1, 0x02)
+
+ ROM_FILL(0xf4000+0x3d8, 1, 0x00) // unblock BIOS auto boot (1)
+ ROM_FILL(0xf4000+0x8aa, 1, 0x01) // JMP FAR 0000:1000 (could be a BIOS bug or a CPU oddity) (2)
+#endif


Anybody aware of this issue?

It's been too long to just edit the last message, but I've started the long process of bisecting 18 months of changes

Behavior changes with 07d757a2ed72d7793060773f48d6d029b5547ff6, the commit that made Rainbow 100A and 100B able to co-exist. Venix works before this commit (0b0dadd8359a6cb8093bb8892f74477504282a34), but not after. This is with the unlock BIOS auto boot and JMP FAR workarounds applied. I get MHFU without at least the second one applied in 0b0dadd, but get it always when init is run with 07d757a (w/o the workarounds I don't even get that far). So something subtle broke with the Rainbow refactoring. The change is rather large, so it will take some time to sort out the good from the bad.
A quick eyeballing of the change show nothing obviously wrong, but there are a number of things that might not be just code movement. I'll need study in more detail to discover what kills things.

If I had to guess, interrupts are off, and interrupts are different between the two models (well, they boot the same, but asserting DTR on the 8251 moves the hardware interrupts elsewhere). I'll have to see if Venix does that, though I kinda doubt it since DOS is the only one that needs to move the interrupts due to the conflict between the hardware and the soft interrupts DOS uses.

I haven't looked at the exact commit hash, but it sounds like I may be responsible for that change. When I hit a good stopping point on my work with the HP Jornada 720, I'll dig into it and address the issue.