-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
HD20 Schematics required
- Thread starter jongleur
- Start date
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. ;-)
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 MHIt 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.
