3 May
2015
3 May
'15
6:28 a.m.
I'm reverse-engineering the firmware of the IOC board of an Intel MDS
Series II (with the iMDX 511 IOC firmware enhancement kit, so it's the
same as early MDS Series III firmware, but possibly not 100% identical
to firmware of the later MDS Series III using the IOC-III).
The IOC uses an 8257 DMA controller, which was the predecessor of the
8237 as used in PCs. While it is mostly pin-compatible, the 8257
register map is a subset of nor compatible with the 8237. Not a
problem since the 8257 datasheet is readily available.
Except...
The 8257 mode register (output) and status register (input) are
register number 0x8 of 16. The data sheet says that A3 should be 1 and
A2..A0 should be zero to access those registers, as expected, and does
not document what (if anything) registers 0x9 through 0xf do. It's
possible that they simply mirror register 0x8.
In the MDS, the 8257 is I/O ports 0xf0 through 0xff, so mode and
status should be at 0xf8, and indeed sometimes the firmware references
those. However, the firmware also inputs from 0xfd, and writes to
registers 0xfb, 0xfc, and 0xff. The values read and written don't
seem to me to completely make sense if I make the assumption that they
are mirrors of 0xf8, and I can't imagine why the firmware author would
have used 0xf8 in some places and other port addresses in other places
if in fact they are functionally the same.
Intel published the source code of the ROMs for the MDS main processor
(8080 or 8085), but I've never seen source code for the IOC firmware.
Update as I was writing this up:
I just spotted a comment in the MESS driver by fulivi stating that
port 0xfd reads as 0xff and is used to detect whether the chip is an
8237 or 8257. If so, perhaps the 8257 either ignores input requests
from 0xf9 through 0xff, leaving the bus tri-state, or
possibly it
actually drives 0xff, and perhaps it ignores writes to 0xf9 through
0xff. I'll have to go back through the disassembly and study what that
would do; it didn't seem like just the writes to 0xf8 made sense, but
the other writes may have confused me.
Has anyone actually seen a Series II or Series III with an 8237 on the
IOC board? Perhaps the IOC-III uses the 8237?
Eric
4 May
4 May
10:18 a.m.
Hi,
I've been doing some reverse engineering, too. Of the same exact version
of firmware you mention. I had to do it in order to build an accurate
model of IOC hw in MESS emulator.
Anyway, what I understood is that the firmware automatically adapts to
either 8237 or 8257. During initialization (@ address 0084) the IOC CPU
reads from register 0xfd. This register reads as 00 in case a 8237 is
installed (because it's a temporary register that gets reset to 00 at
initialization) or ff in case of 8257 (I understand the 8257 leaves the
bus floating for registers > 0xf8).
The two DMA chips mostly behave the same, apart from different
arrangement of registers. Where they do differ a lot is in the
"autoload" feature that is only available in 8257. Basically the DMA
channel 2 is loaded with data from channel 3 once channel 2 reaches
terminal count. In the IOC this feature is used to implement hw
scrolling of video because the framebuffer is split in two parts. The
second part is actually displayed first whereas the first part is
displayed just after the second. Scrolling of video is achieved by
simply moving down one row the starting point of second part. The trick
is to load channel 2 at raster interrupt with data for second part of
framebuffer and channel 3 with data for first part. The DMA hardware
automatically switches to supplying data for the first part once the
second one ends because of the autoload feature of 8257.
See page 4-5 of hardware reference manual (9800556-02).
But 8237 has no such feature. My understanding is that an hw
modification is needed to IOC board if 8237 is installed (see for
example the wiring around the DMA in this picture:
https://www.flickr.com/photos/22368471 at N04/16932740579/in/album-72157651893890975/
). This rewiring (for which I found no documentation) apparently allows
the 8237 to "emulate" the autoload feature of 8257.
F.Ulivi
10:43 a.m.
F.Ulivi wrote:
My understanding is that an hw
modification is needed to IOC board if 8237 is installed (see for
example the wiring around the DMA in this picture:
https://www.flickr.com/photos/22368471 at N04/16932740579/in/album-72157651893890975/
). This rewiring (for which I found no documentation) apparently allows
the 8237 to "emulate" the autoload feature of 8257.
That's actually my IOC board. I hadn't noticed that it has an 8237A!
Amazing. Thanks for pointing that out. That's definitely proof that
the code can work with the 8237A, now I need to scrounge an 8257 and
determine whether the board w/ the 8237A rework will still work with
the 8257.
IIRC, the 8237A had some improvements over AMD's original 8237 design,
so it's possible that a non-A 8237 might not work. I haven't compared
the A and non-A datasheets yet.
I've been making progress on reverse-engineering the IOC firmware.
They wrote it as four separate 2K ROMs, each of which has a table of
fixed entry point addresses for entry from the other ROMs. (The first
ROM has the entry points interleaved with the RST n vectors.) The
first ROM is startup and diagnostics, and the second is the command
handler and the driver for the intergral single-density floppy. I
haven't yet started on the third and fourth. There are a few input
and output bits they access that are not used in the normal IOC, but
perhaps are used in the IOC-III used in later Series III machines.
In the RAM test, if the back panel mode switch is set to diagnostic
mode, they insert a delay (which I haven't timed) between the write
and verify passes of the diagnostic, presumably to test whether memory
refresh is working.
I was hoping that the floppy driver had support for two drives, but as
far as I can tell so far, it does not. I could be wrong since I
haven't puzzled out all of the details yet.
My IPB is the old version (1001194) without the 20-bit addressing
daughterboard (1002234). I don't have a schematic of the daugherboard,
but all it does is use a 74LS30 and a resistor pack to pull up the
A10/ through A13/ address lines on the Multibus, and disable the
on-board RAM address decode if they aren't all high, in order to
prevent the board from incorrectly responding to RAM addresses from
0x10000 through 0x17fff, 0x20000 through 0x27fff, etc. I can easily
hack that in myself.
I'd really like to replace the IPB with the 8085-based IPC, if anyone
has a spare available. Also looking for an RPA, RPB, or RPC 8086 board
to effectively turn it into a Series III, and the two-board
double-density floppy controller. (This Series II was previously
equipped with the double-density controller, as the I/O cabling is
still present.)
Also it would be nice if anyone has a later rev of the Series III
schematics. The set that Al has kindly provided on Bitsavers is
121642-001A, which appears to be the earliest set Intel printed, and
doesn't cover the RPB or RPC, or the IOC-III.
3927
days inactive
3928
days old
2 comments
2 participants
participants (2)
-
fulivi＠tiscali.it -
spacewar＠gmail.com