Thread
HD20 Schematics required
Well, whatever the case, I do enjoy the occasional "thread war." They can become quite exhilarating, and it's always good to knock horns every once in awhile... (we are men, after all. I doubt there are any girls on this forum)
...until we are banned from the site.
I actually like coming here because it's NOT excessively polite or overbearingly moderated. Sometimes posters are naughty here, and sometimes they're nice. Some consider me naughty for speaking so bold about EBAY sellers and the user of the wicked term "rare," but I couldn't care less. I prefer it that people speak their minds and allow me to do the same. It's not like we're talking about selling illegal drugs or making bombs on this site, nor are we using profanity or trying to destroy the reputation of others. We're just talking, and sometimes that gets passionate. So what? If we Mac users are anything, especially we old-timer Apple collectors, we are a diverse crowd. Let's thrive in that diversity. Don't worry so much about the little things. It's sometimes good to overlook posts or even entire threads sometimes. Live and let live, I say.
Now with that said, I think this thread offers a lot of good technical info, and a few stray comments here and there do not detract from that.
And if someone can come up with a flash drive replacement for my HD20's spinning platter drive mechanism, I have my Paypal account ready and waiting. Just make sure it's compatible with System .85 / Finder 1.0. ;-)
Now with that said, I think this thread offers a lot of good technical info, and a few stray comments here and there do not detract from that.
And if someone can come up with a flash drive replacement for my HD20's spinning platter drive mechanism, I have my Paypal account ready and waiting. Just make sure it's compatible with System .85 / Finder 1.0. ;-)
Yes, and we'll have that USB interface for your Mac 128K ready a few days later. ;-)
Although, honestly, it should be very straightforward to hook some of the USB chipsets to a 68000. The hard part would be writing the software drivers for the thing.
It's impossible to write device drivers for Macs. Ask anybody.
I must say that I am more interested in working on the IWM side than the Rodime side. That could easily change, but the IWM bus has the potential to allow more versatility and works for people who don't have an HD-20 to begin with.
I must say that I don't fully-understand the UART theory. From what I understand of what you're saying, you think that the IWM in the Mac may encode data into IWM signals, and the IWM in the HD-20 basically decodes them back to the original signals. Is this correct?
I can see how you would cross the serial transmit and receive lines, but the control signals must either be bi-directional or not used, because they are both the same IWM chip (presumably). i.e. Normally, with a floppy drive, the Mac's IWM sends out control signals, sends out serial data, and receives serial data. I'm not aware of the Mac's IWM ever receiving control signals from a drive, maybe I'm wrong. I have more reading to do on these things. Bi-directional control signals would complicate matters because it's difficult, but not impossible, to rig something up that can analyze which direction data is going on a bidirectional bus if we don't have an obvious data direction line.
To analyze an unknown bidirectional bus, for each line you need two schottky diodes, opposite directions wired in parallel, inserted in series with the line. The diodes cause a slight voltage drop on the receiving end when the data = 1, which can be detected with a comparator in parallel with the diodes. However, when the data = 0, the voltage is higher on the receiving end. So you XOR the comparator output with the data to conclude if data is sent or received. That's the only way I can fathom determining a completely unknown data direction, and it takes quite a few parts per line.
I must say that I don't fully-understand the UART theory. From what I understand of what you're saying, you think that the IWM in the Mac may encode data into IWM signals, and the IWM in the HD-20 basically decodes them back to the original signals. Is this correct?
I can see how you would cross the serial transmit and receive lines, but the control signals must either be bi-directional or not used, because they are both the same IWM chip (presumably). i.e. Normally, with a floppy drive, the Mac's IWM sends out control signals, sends out serial data, and receives serial data. I'm not aware of the Mac's IWM ever receiving control signals from a drive, maybe I'm wrong. I have more reading to do on these things. Bi-directional control signals would complicate matters because it's difficult, but not impossible, to rig something up that can analyze which direction data is going on a bidirectional bus if we don't have an obvious data direction line.
To analyze an unknown bidirectional bus, for each line you need two schottky diodes, opposite directions wired in parallel, inserted in series with the line. The diodes cause a slight voltage drop on the receiving end when the data = 1, which can be detected with a comparator in parallel with the diodes. However, when the data = 0, the voltage is higher on the receiving end. So you XOR the comparator output with the data to conclude if data is sent or received. That's the only way I can fathom determining a completely unknown data direction, and it takes quite a few parts per line.
I can agree with that, especially for System 7 and older. Another major problem would be multitasking. You don't want the whole Mac to lock up every time it has to wait for some USB thing to happen. You may have better luck with a Unix OS, though.
So... obviously I can't know for sure, but I'd be willing to bet a nice shiny nickel on the read/write lines being crossed so the two IWMs act like a pair of UARTs, yes. If you look at that page about programming the IWM (on the Apple IIGS) the IWM essentially acts just like a UART (or at least a parallel-in-serial-out shift register... it's a pretty dumb UART) so there really shouldn't be a barrier to wiring two together, and if you did that a data byte fed into one side *should* be clocked out the other...
Before continuing it's worth noting that the IWM is *the* prime example of Apple's use of clever software to compensate for a lack of discrete hardware, thus resulting in a fairly incomprehensible design despite being electrically "simple". Google for the PDF "Beneath Apple Dos" and read it. You'll see in graphic, horrid detail how the IWM (which is essentially a slightly-enhanced single-chip implementation of the Apple ][ disk controller) requires *software* to imbed the synchronization bits into the data stream bytes. (This document is mentioned in that IIgs IWM programming page.) When you're writing a disk buffer you don't just throw the data at the IWM and it writes it, automatically padding it with sync bits like a "real" disk controller does. No, you get to rewrite the data yourself, aka, "nibble-ize-ing" it, and throw those modified bytes at the controller. Also note there's no interrupts indicating when it has a valid byte/needs the next one. You loop and poll until you're done, period.
(One question that this raises is if communication to the HD-20 likewise has to be nibble-ized, or if they just throw raw bytes at each other. I suppose it has to get clocking information somehow so there's probably *some* massaging of data...)
Anyway, yes, you have a valid point about handshaking/flow control. Because of the "load-select-read" way the IWM communicates with the "smart" 400/800k drive registers there doesn't seem to be a simple way you could just raise and lower a line and have it detectable on the far end. (If it were a pair of PC-style floppy controllers perhaps you could use a status line... do something skanky like tie "motor on" to "write protect" in both directions? Here we don't have that option.) My guess is what Apple did is tie the control register lines from the Mac to an input/output port on the Z8. That would let the Mac twiddle the control lines in whatever way is necessary to get the HD-20's attention, and then the Mac would send a control byte out through the IWM's UART once the Z8 has indicated it's ready. (As indicated through a read of a "control register" in the drive similar to the floppy drive mediated by the Z8. Note that the control lines on the HD-20's IWM aren't connected to anything in this scenario.) When the HD-20 sends something back through its own IWM/UART there won't be any flow control, but... there's no flow control when a spinning disk is shoving bytes at the host computer anyway. You'd work around this by again using a twiddle of the control lines to ensure that the HD-20 doesn't send any data until the Mac indicates it's ready for it. (At which point it would start running an appropriate tightly-coded polling loop.)
Again, this is all 100% speculation. I'm just trying to think like a demented 1985 Apple engineer here.
Well, I am happy to report that my HD20 came in the mail today, and much to my great surprise, it works! The system file was corrupted, so I had to load a new system onto it. (Maybe it was too new and required a Mac Plus instead of the 512k I'm using? I don't know.) Right now I'm running the 15 minute test so we'll see how that goes, but at least I should have enough functionality to get some good information from it.
[edit]
It passed the test!
Schematics and cable connections come next.
[edit]
It passed the test!
Schematics and cable connections come next.
I have now confirmed, as we all expected, that the 400k drive cable is identical from end to end to the HD-20 cable.
The 20-Pin header has been labeled from the well-known pin numbers of the D-Sub connector. Pin 10 appears to be in the wrong place, but that is the way it is.
Code:
19-Pin D-Sub Connector, looking at the pins of the male connector:
______________________________________
\ 1 2 3 4 5 6 7 8 9 10 /
\ 11 12 13 14 15 16 17 18 19 /
\____________________________/
20-Pin header connector, looking at the holes of the female connector:
_____
_______________| |_______________
| 1 2 3 4 nc 6 7 8 nc nc |
| 11 12 13 14 15 16 17 18 19 10 |
|_________________________________|Thanks for the confirmation on the cable. I'll hook mine up as soon as I can, replacing the callously butchered one on my HD20.
Also congratulations on your HD20 being operational, a great find for such a "rare"
device, especially for the price you got it for. Hopefully mine will be similarly inspired to become operational.
Here is a ROM dump of the 2764 ROM chip inside of the HD20:
http://www.d.umn.edu/~bold0070/projects/hd20/hd20.bin
I don't know of any way to verify how good the dump is. All attempts to locate a hard drive icon failed. The information in that document may be wrong, though. Maybe the icon actually comes from the HD20 code in the Mac's ROM or HD 20 extension.
There does appear to be a LITTLE bit of ASCII in there:
http://www.d.umn.edu/~bold0070/projects/hd20/hd20.bin
I don't know of any way to verify how good the dump is. All attempts to locate a hard drive icon failed. The information in that document may be wrong, though. Maybe the icon actually comes from the HD20 code in the Mac's ROM or HD 20 extension.
There does appear to be a LITTLE bit of ASCII in there:
Code:
iRene-1 RM MH
It would appear that all pins are continuous from the main cord to the daisy chain port except for /Enbl2. This includes all serial and control lines. Daisy-chaining should be easy on the hardware side of things.
Pins 21-28 of the Z8 correspond with the data bus D0-D7, connected to IWM, RAM, and ROM. Address lines are interconnected between IWM, RAM, and ROM as well, but they are not connected directly to the Z8 as far as I can tell. They are connected to the big square chip though! (NOT GOOD) My continuity tester is not the very best. I need to find my one that beeps.
Given that addressing goes through the mystery chip, the data may be in a strange order in the ROM dump I provided. It could be that the mystery chip just buffers the address lines, though. 3 TTL inputs off of one Z8 output doesn't seem too bad though, so I'm a little confused why they did that. Maybe just to make it hard to reverse engineer!!
I guess when you think about it, there are lots of address lines. 4 (IWM) + 13 (ROM) + 11 (RAM) = 28 address inputs. Hmmm... Data has to be I/O, maybe that's why they didn't buffer that.
Since inverting buffers are faster and easier to make than noninverting buffers, we could have reverse addressing, i.e., the ROM dump could have to be flipped backwards to be normal Z8 code. Seems unlikely, but something to consider if we have trouble disassembling.
I guess when you think about it, there are lots of address lines. 4 (IWM) + 13 (ROM) + 11 (RAM) = 28 address inputs. Hmmm... Data has to be I/O, maybe that's why they didn't buffer that.
Since inverting buffers are faster and easier to make than noninverting buffers, we could have reverse addressing, i.e., the ROM dump could have to be flipped backwards to be normal Z8 code. Seems unlikely, but something to consider if we have trouble disassembling.
I think this may be some credits. If you go into the HD20 Test and open the about window, it credits Rodger Mohme with the HD20 Test program. RM could be his initials. This drive is from a time when people ALWAYS hid their names and initials in things. Interesting trivia if it's true, but it also makes me feel a little better about the validity of the ROM dump.
[edit]
Apparently the HD 20 device driver's name is 'RENE':
http://www.vintagemacworld.com/hd20/hd20tool.txt
its possible that big square chip is an address/data multiplexer? The Z8 has to communicate to the rodime somehow. your RAM/ROM/IWM is connected to the Z8, at the same time its connected through that square chip, probably to address the RODIME. maybe.
I guess one thing to do would be to reverse engineer that controller board into a schematic. labeling the square chip as a ?
then using a couple of logic analyzers, you could just about map out the math function of the glue logic inside that IC
I guess one thing to do would be to reverse engineer that controller board into a schematic. labeling the square chip as a ?
then using a couple of logic analyzers, you could just about map out the math function of the glue logic inside that IC
You make a good point. It's tough to tell if the mystery chip is sending or receiving address data through those lines. The Z8 is not sending the address data directly, but the address data must originate from the Z8. One possibility is that the mystery chip takes address data from the Z8 and spits it out onto the main address lines like I mentioned, but maybe something else is spitting out addresses and the mystery chip is actually taking IN addresses from these lines for use with addressing the Rodime. Interesting perspective.
It seems to me that the mystery chip is involved mostly with things between the Z8 and the Rodime, as it seems to you as well. I haven't mapped out much schematic data yet because I have to go find my beeping continuity tester to do it properly.
The PAL chip is actually another mystery chip. I'm not sure how to tell how it was burned. WR, common to the main cord and the daisy chain port, connects directly to Pin 2 of the PAL. I have been unsuccessful thus far to spot where RD goes, but again, that falls back to the other tester that I still need to find.
-----
I'm starting to like Gorgonops' UART idea better and better. The IWM is definitely NOT there to run the daisy chain port.
It seems to me that the mystery chip is involved mostly with things between the Z8 and the Rodime, as it seems to you as well. I haven't mapped out much schematic data yet because I have to go find my beeping continuity tester to do it properly.
The PAL chip is actually another mystery chip. I'm not sure how to tell how it was burned. WR, common to the main cord and the daisy chain port, connects directly to Pin 2 of the PAL. I have been unsuccessful thus far to spot where RD goes, but again, that falls back to the other tester that I still need to find.
-----
I'm starting to like Gorgonops' UART idea better and better. The IWM is definitely NOT there to run the daisy chain port.
Here's the ROM disassembled to a list file with IDA Pro. I'm betting the dump is okay at this point. Open the LST as a text file.
http://www.d.umn.edu/~bold0070/projects/hd20/hd20.lst
We'll have to figure out a bit more hardware before this is particularly useful.
http://www.d.umn.edu/~bold0070/projects/hd20/hd20.lst
We'll have to figure out a bit more hardware before this is particularly useful.
I'd hazard a guess here that one of the functions of that big chip is to act as decoding logic for addressing those peripherals, IE, enabling/disabling the chip select lines as appropriate. (Otherwise you'd have some discrete logic on the board for that.) Perhaps the reason the address lines are run *through* it rather than having it in parallel with the other devices on the Z8's address bus and only providing chip select is that there is some *other* logic in that large chip allows it to act as a bus master and it requires the ability to selectively disable the Z8? (I could see this if, for instance, the controller logic that speaks to the Rodime drive uses DMA to read and write to a sector buffer in that RAM chip, cutting off the Z8 until the transaction is completed.) Only a theory, of course.
If it's possible to detangle the driver program in the Z8 disassembly you should be able to at least determine where in the Z8's address space the RAM and IWM are mapped. However, wading through that *is* going to be a formidable task unless someone here is experienced with Z8 assembly language. (The Z8 is a "weird" chip in some respects.) I'll admit it's completely Greek to me.
The documentation could be wrong, but since it was pretty adamant about it (saying it in two places) I would suggest another theory: Assuming the IWM-UART theory is correct, and assuming the IWM requires that data be encoded to limit the number of consecutive "0" bits it sends/receives across the wire (IE, it requires things to be nibble-encoded) it's possible that the icon is stored pre-encoded so it can just be shoveled straight out the wire when the Mac asks for it. If it were nibble-encoded it would pretty much look like gibberish unless you knew its starting address and even then you'd have to "de-nibble" it.
(I'll admit the whole idea of having to fetch an icon for a device from the device itself seems incredibly over-engineered and clumsy, but it's possible that Apple designed it that way because A: they're anal-retentive and didn't want to use a generic icon fixed in the driver because B: perhaps they hadn't quite committed to using SCSI on subsequent Mac models as the hard disk interface and wanted to be ready for the possibility that they might eventually have a whole line of IWM-interfaced peripherals?)
Speaking of the IWM: this might be really useful.
I am fluent in HC12 assembly language, and this appears at least somewhat similar. I agree it is formidable, it is quite a bit of code and there seems to be quite a bit of interrupt functionality which gets confusing really fast.
I hadn't thought about it like that, but that makes a lot of sense. I was under the impression that the IWM did all of the nibbling and denibbling, and by the time it got to the Z8 it was in normal form, but I really don't know. It will be useful to see exactly where the RD and WR lines go, and exactly where the nibbling/denibbling processes occur.
I mentioned a while ago that the microcontroller prototype board that I want to use for logic analyzing is loaned out. I have decided to order up a faster one that has an SD card slot and let that person keep the one I loaned, so for now I'll just stick with continuity probing. I did manage to wire up a 20-pin header extension cable that will allow me to snoop the floppy port interface. It is a cable that passes straight through and has an area allowing me to tap each line without harming any original hardware. I verified that the HD 20 does work through this cable.
appears to be 8051 based.
What makes you think it's 8051 based? I haven't looked closely at the disassembled file yet, but it seemed to disassemble okay. It says Z8 on the board, but they sure could have used a different one. I'm at a bit of a loss for all the different kinds of old microprocessors out there.
I didn't work on this today until tonight. I mapped out the 2 7400 chips. It makes a very simple state machine, two JK' Flip-flops and 4 schmitt trigger NAND gates. It takes in LSTRB, CA1, and /ENBL2 from the cord and outputs the signal to the PAL /OE pin and /ENBL2 of the daisy chain port. So basically, the Mac takes care of multiplexing the HD 20 with a daisychained floppy drive, and this circuitry makes sure the HD 20 is only active on the floppy port when it is its turn.
I'll make sure I have all of the connections right and come up with a nice state diagram.
I didn't work on this today until tonight. I mapped out the 2 7400 chips. It makes a very simple state machine, two JK' Flip-flops and 4 schmitt trigger NAND gates. It takes in LSTRB, CA1, and /ENBL2 from the cord and outputs the signal to the PAL /OE pin and /ENBL2 of the daisy chain port. So basically, the Mac takes care of multiplexing the HD 20 with a daisychained floppy drive, and this circuitry makes sure the HD 20 is only active on the floppy port when it is its turn.
I'll make sure I have all of the connections right and come up with a nice state diagram.
I would assume since the board says "Z8" it's a Z8, but if you're at all worried you're barking up the wrong tree Googling the part numbers on top of the chip should tell you what it is. I think I was actually able to discern a Zilog "Z" logo on the chip from the Flickr pictures of an HD-20 motherboard, but it wasn't high-res enough to read the actual part numbers. Even if it's obvious that it's a Z8 it might still be worth figuring out *which* Z8 it is. They sold them in various configurations with different onboard peripherals, ROMless and ROM-equipped versions, etc, etc. (There are even ones with embedded Tiny Basic interpreters.) What's in there is probably the plain-vanilla ROMless version, but it would throw a monkey wrench into things if it turned out it was actually a mask-programmed ROM model and the discrete ROM chip only contained *part* of the driver program.
Concidentally, here's a page where someone who's written a Z8 cross-assembler rhapsodizes about the Z8 and in the process explains how it's a very strange CPU design, very little like an 8051 or Motorola 68xx.
(As a side comment, I'm sort of surprised Apple didn't use a 6502 variant in it. Apple was by no means as prolific as Commodore when it came to embedding 6502s into things at the slightest provocation, but they *did* use them in the Lisa and a few Mac models as I/O controllers.)
I see a Z logo on the chip as well. I've played ever so slightly with PIC ASM and OMG, it's very different than I'm used to. You can't, for example, build tables directly. You must encode data tables into instructions. i.e. normally you would have a stash in memory:
03 F2 78
And in PIC, that becomes:
Load A with 03
return from subroutine
load A with F2
return from subroutine
load A with 78
return from subroutine
having a discrete subroutine jump for EACH item. Sheesh.
Anyway, I think I got some daisy chain stuff figured out. It's all asynchronous.
Circuit Diagram:
State Diagram:
English:
State 0,0:
/ENBL2_daisy is disabled. PAL /OE is directly controlled by /ENBL2_cord.
A positive strobe of LSTRB will move to state 1,0. Strobing CA1 or /ENBL2_cord will not change states.
State 1,0:
/ENBL2_daisy is enabled. PAL /OE is directly controlled by /ENBL2_cord, but this coincidentally changes states.
A positive strobe of /ENBL2_cord will move to state 0,0. A positive strobe of CA1 moves to state 1,1. Strobing LSTRB will not change states.
State 1,1:
/ENBL2_daisy is disabled. PAL /OE is disabled.
Strobing /ENBL2_cord will move to state 0,0. Strobing LSTRB or CA1 will not change states.
State 0,1:
This is an invalid state. It can not normally be entered unless by random chance during power up. /ENBL2_daisy is enabled and PAL /OE is disabled.
A positive strobe of LSTRB will move to state 1,0. A positive strobe of /ENBL2_cord will move to state 0,0. Strobing CA1 will not change states.
03 F2 78
And in PIC, that becomes:
Load A with 03
return from subroutine
load A with F2
return from subroutine
load A with 78
return from subroutine
having a discrete subroutine jump for EACH item. Sheesh.
Anyway, I think I got some daisy chain stuff figured out. It's all asynchronous.
Circuit Diagram:
State Diagram:
English:
State 0,0:
/ENBL2_daisy is disabled. PAL /OE is directly controlled by /ENBL2_cord.
A positive strobe of LSTRB will move to state 1,0. Strobing CA1 or /ENBL2_cord will not change states.
State 1,0:
/ENBL2_daisy is enabled. PAL /OE is directly controlled by /ENBL2_cord, but this coincidentally changes states.
A positive strobe of /ENBL2_cord will move to state 0,0. A positive strobe of CA1 moves to state 1,1. Strobing LSTRB will not change states.
State 1,1:
/ENBL2_daisy is disabled. PAL /OE is disabled.
Strobing /ENBL2_cord will move to state 0,0. Strobing LSTRB or CA1 will not change states.
State 0,1:
This is an invalid state. It can not normally be entered unless by random chance during power up. /ENBL2_daisy is enabled and PAL /OE is disabled.
A positive strobe of LSTRB will move to state 1,0. A positive strobe of /ENBL2_cord will move to state 0,0. Strobing CA1 will not change states.
Other incomplete findings (There are most definitely MORE connections than listed):
PAL Pins:
1: Clock signal common to IWM pin 24 (Fclk), and Z8 pin 3.
2: [Floppy Port WR]
3: IWM Pin 8 (WRData)
4: Z8 pin 4
5: [Floppy Port CA2]
6: [Floppy Port CA1]
7: [Floppy Port CA0]
8: (nc?)
9: (nc?)
10: Gnd
11: PAL /OE
12: [Floppy Port RD] via R26. PAL pin 12 connected directly to IWM pin 22 (RDData).
13...19: (?)
20: Vcc
PAL Pins:
1: Clock signal common to IWM pin 24 (Fclk), and Z8 pin 3.
2: [Floppy Port WR]
3: IWM Pin 8 (WRData)
4: Z8 pin 4
5: [Floppy Port CA2]
6: [Floppy Port CA1]
7: [Floppy Port CA0]
8: (nc?)
9: (nc?)
10: Gnd
11: PAL /OE
12: [Floppy Port RD] via R26. PAL pin 12 connected directly to IWM pin 22 (RDData).
13...19: (?)
20: Vcc
I should try taking a picture with a flash, that might make the traces light up better and maybe I can get a picture of the component side too.
All attempts to take a picture with a camera, flash or no flash, have failed. It just isn't made for detailed close-up shots like that. The picture I posted was from placing the board on my scanner, but it won't work on the component side because it doesn't lay flat on the glass.
Next up is more attention to the PAL. This may shed more light on how the floppy port interface controls work. If I can map out the PAL, and map out the IWM, I think that'll be a MAJOR step toward emulating a floppy port HD. From that point, I can snoop the signals and try to make sense of them.
I'm sorry if people have given me suggestions that I seem to be ignoring. I often times gloss over while reading lengthy posts as I begin to think about things that you said toward the beginning. If you have something important that you want to point out, please be concise or put it in bold or something, or give a summary, etc. My attention span diminishes if I'm really excited thinking about something.
Next up is more attention to the PAL. This may shed more light on how the floppy port interface controls work. If I can map out the PAL, and map out the IWM, I think that'll be a MAJOR step toward emulating a floppy port HD. From that point, I can snoop the signals and try to make sense of them.
I'm sorry if people have given me suggestions that I seem to be ignoring. I often times gloss over while reading lengthy posts as I begin to think about things that you said toward the beginning. If you have something important that you want to point out, please be concise or put it in bold or something, or give a summary, etc. My attention span diminishes if I'm really excited thinking about something.
I have nothing to contribute. I just want to say, "Great Work, DN." I am enjoying following along.
WELL I'm a little bit tired of working on all these darned connections. It's fairly tedious and repetitive. This should at least help give us some ideas of how this weird thing works.
The "R" and "F" are used as designators for pin names. R means Rodime header, F refers to "FC", silkscreened above the big mystery chip.
The "R" and "F" are used as designators for pin names. R means Rodime header, F refers to "FC", silkscreened above the big mystery chip.
On a big chip like that 'F' chip, I would expect somewhere between a quarter and half of the pins to be power or ground. Perhaps that was not true back when the HD20 was made. That may have only come about after the geometries got smaller.
Anyway, you might save yourself some time by getting out the ohmmeter and connecting one probe to ground and then run the other probe around the pins of the chip with the audible continuity alert active.
Then connect the stationary probe to the 5V supply and do it again.
When I was working on the pinout of the PowerSurge chipset that's what I did first to eliminate a bunch of pins. Of course, the tedium got me before I finished all of that.... I only ever managed the CPU slot, the ROM slot, Bandit and a little bit of Hammerhead and Grand Central.
Anyway, you might save yourself some time by getting out the ohmmeter and connecting one probe to ground and then run the other probe around the pins of the chip with the audible continuity alert active.
Then connect the stationary probe to the 5V supply and do it again.
When I was working on the pinout of the PowerSurge chipset that's what I did first to eliminate a bunch of pins. Of course, the tedium got me before I finished all of that.... I only ever managed the CPU slot, the ROM slot, Bandit and a little bit of Hammerhead and Grand Central.