1 Jan
2025
1 Jan
'25
3:30 a.m.
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-in…
NB I have posted this same message on VCF.
Regards
Rob
From: Warner Losh <imp(a)bsdimp.com>
Sent: 09 December 2024 18:35
To: rob(a)jarratt.me.uk
Cc: General Discussion: On-Topic and Off-Topic Posts <cctalk(a)classiccmp.org>
Subject: Re: [cctalk] Rainbow Z80 firmware
On Sun, Dec 8, 2024 at 11:58 PM Rob Jarratt <robert.jarratt(a)ntlworld.com
<mailto:robert.jarratt@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_2227…
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_Jul… (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 <imp(a)bsdimp.com <mailto:imp@bsdimp.com> >
Sent: 09 December 2024 01:01
To: rob(a)jarratt.me.uk <mailto:rob@jarratt.me.uk> ; General Discussion: On-Topic and
Off-Topic Posts <cctalk(a)classiccmp.org <mailto:cctalk@classiccmp.org> >
Cc: Rob Jarratt <robert.jarratt(a)ntlworld.com <mailto:robert.jarratt@ntlworld.com>
>
Subject: Re: [cctalk] Rainbow Z80 firmware
On Sun, Dec 8, 2024 at 12:39 PM Rob Jarratt via cctalk <cctalk(a)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_DI…
has disassembled 8088 code.
https://github.com/shattered/retro-bios/blob/master/dec-rainbow100b/Z80_DIS…
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
