Hello Warner,
Thanks for the reply below. I have spent the whole Christmas holiday poring over the disassembled ROM and using a logic analyser to try to find the fault shown in the image above. I am at a bit of a loss now and would like to ask for any advice/help. From what I can see using my logic analyser, all the RAM, Screen RAM and Attribute RAM seems to be working fine. There are multiple places in the ROM where the diagnostic code for this error is used. The diagnostic LEDs do not appear to have the mapping you would expect, the error I am seeing seems to write 0x6F to the diagnostic port. The points in the ROM where this status is written are: * 0x0496. Followed by two that write 0x3F and 0x4F. * 0x057A. Followed by one that writes 0x0F * 0x05B7. Followed by one that writes 0x0F * 0x069B. * 0x06C7. Other locations write the status (as 0x016F) to a memory location for later use in writing to the LEDs. I think it is the test at 0x7F8 that is causing this to happen and I think this is where it decides there is a problem. But I can't work out why or what this particular test means. I think some of the later writes of the 0x6F value happen after it has already decided there is a problem. I have posted some information about the memory map and the disassembled ROM here: https://robs-old-computers.com/collection/rainbow-100a/#repair-reference-information NB I have posted this same message on VCF. Regards Rob From: Warner Losh <i...@bsdimp.com> Sent: 09 December 2024 18:35 To: r...@jarratt.me.uk Cc: General Discussion: On-Topic and Off-Topic Posts <cctalk@classiccmp.org> Subject: Re: [cctalk] Rainbow Z80 firmware On Sun, Dec 8, 2024 at 11:58 PM Rob Jarratt <robert.jarr...@ntlworld.com <mailto:robert.jarr...@ntlworld.com> > wrote: Hello Warner, Thanks for your detailed reply. I forgot to mention that I do get a display of sorts, it looks like this: https://robs-old-computers.com/wp-content/uploads/2024/11/img_20241127_222706.jpg I had assumed that this would mean the DC011 and DC012 were OK, otherwise it wouldn’t seem possible for it to be able to display this message. Do you still think it could be one of those two chips? Given that the video attribute for the S is messed up and the T has both the video attribute and the character messed up, and the anomaly runs the full height of the screen, I'd say something is wrong with the character generation or the video ram that it uses (which I think is dual ported to the 8088). So maybe not the chips, per se, but there's clearly something wonky in that area. I've not read through the 8088 BIOS in a while to see what tests it does to come to this conclusion, however. However, you originally said 011 0101. The upper 3 bits of the diag code is controlled by the Z80. I think this is Z80 controlled parts of the fail code... but I'm not entirely sure, but that's what I get from reading the 100B schematic at https://bitsavers.org/pdf/dec/rainbow/MP01722_PC100-B_Rainbow_Schematic_Jul84.pdf (The SH8 ZDx data is routed to E28 on sheet 10, so this may also be the data when E28 is latched on sheet 10 when SH8 ZDIAG WR L is active). Warner Thanks Rob From: Warner Losh <i...@bsdimp.com <mailto:i...@bsdimp.com> > Sent: 09 December 2024 01:01 To: r...@jarratt.me.uk <mailto:r...@jarratt.me.uk> ; General Discussion: On-Topic and Off-Topic Posts <cctalk@classiccmp.org <mailto:cctalk@classiccmp.org> > Cc: Rob Jarratt <robert.jarr...@ntlworld.com <mailto:robert.jarr...@ntlworld.com> > Subject: Re: [cctalk] Rainbow Z80 firmware On Sun, Dec 8, 2024 at 12:39 PM Rob Jarratt via cctalk <cctalk@classiccmp.org <mailto:cctalk@classiccmp.org> > wrote: Hello everyone, I am working on a Rainbow 100A which is showing a diagnostic code on the lights at the back of 0110101. This is supposed to be Message 1 "Main Board Video". OK That's likely a failure of the main VT100 chips that's are buried inside the Rainbow. I have disassembled the 8088 firmware and checked address traces with a logic analyser and my suspicion is that actually this is something to do with the interaction with the Z80 because it is reading a status from the shared memory and then using that to set the status lights. The video controller is connected directly to the 8088 side of the world. The Z80 has to make calls to the 8088 to output to the screen. I have been unable so far to work out where in the ROMs the Z80 code lives or where in the 8088 code it transfers it to the shared memory to allow the Z80 to run. https://github.com/shattered/retro-bios/blob/master/dec-rainbow100b/8086_DISASSEMBLY_from_23-020e5-00 has disassembled 8088 code. https://github.com/shattered/retro-bios/blob/master/dec-rainbow100b/Z80_DISASSEMBLY_from_23-020e5-00 has the Z80 code (so both are in the ROMs). This may be the 100B code, but the two models are quite similar in this detail. You can look through the 8086 assembly, I think to find where this error code is generated. I looked at this stuff ages ago when I was getting Venix to run under emulation, but that was 5 years ago now I think. Can anyone tell me where the Z80 firmware is in the ROMs? And does anyone have any insight into the above error or have details of the interaction between the Z80 and the 8088? The Technical Manual only goes so far unfortunately. You might look at the mame emulation of the Rainbow. It does a decent job of things. There's a 2k shared memory area between the Z80 and 8088 that they use to do I/O. The floppy is connected to the Z80, while the hard disk, keyboard and video are connected to the 8088. The 8088 loads the Z80 code by writing a magic value that 'flips' the mapping. It then writes to the 'flipped' RAM and flips things back and restarts the Z80. bitsavers also has the schematics for both the 100A and 100B models. You really need them because they have the only documentation (or best documentation) for the I/O ports that are mapped. There is some registers documented in the TRM, but it's incomplete in some details at least if you are trying to write an emulator. It's a bit of a shame that the MAME efforts have run into personality issues that I'm not close enough to to positively affect. As such, all rainbow efforts have stalled for a couple of years now and the port uses older interfaces that have proven resistant to recoding in the new APIs. Warner
