HD20 Schematics required

[Gorgonops]

One note from a software standpoint: According to the Profile manual the Profile drive presented itself to the host machine essentially as an LBA device; I saw a paragraph discussing that the software on the onboard Z8 handled translation from a sector number to head/track positioning. If we jump to the assumption that the HD20 does the same (I'm at this point completely convinced it amounts to a Profile with that IWM nightmare wedged in place of the parallel port) then the Mac driver is probably surprisingly simple. The Mini-vMac website has those tools to produce commented disassembles of several versions of the Mac ROM. Comparing the .Sony driver from a Macintosh 128/512k to that in a Mac Plus would completely be the place to start, as it's implied in several bits of documentation I've seen that the HD-20 driver is at least partially integrated into the floppy driver.

To recap, three things need to be noodled out:

A: How commands are sent to the HD-20, whether it's via bitbanging the control lines, via the IWM's "data pump", or some combination thereof;

B: If A: involves the data pump, what encoding is used? The same GCR used for floppy sector data, the FM encoding used for address marks, or nothing at all? and:

C: How data itself is pumped out and received. (Again, same GCR encoding loop as a floppy, raw bytes fed to the IWM, or something else.)

The HD-20 is clone-able even if the hardware itself remained a completely black box if those items can be determined from the Mac driver. If we had someone around who was really a wiz with 68000 assembly it was probably the better place to start in the beginning. Unfortunately 68000 wizardry isn't my bag. :^(

 

[Dennis Nedry]

I used to be a pro at Motorola HC11/12 assembly code, I'm not sure how it compares to 68k. It's probably a lot different.

I'm with you on the potential simplicity when tackling this form the Mac ROM side of things. They had basically 2 completely different things - a Rodime drive and a serial floppy drive bus - so it's no surprise that there's a huge heap of spaghetti in between. Not having to be constrained to some obscure 20MB drive will probably make this a lot easier for us than it was for the folks at Apple.

 

[Gorgonops]

For a bit more in the "interesting reading" category from that URL I pointed out on Bitsavers:

http://bitsavers.org/pdf/apple/disk/

Poking through the documentation for the "Widget" and "Nisha" drives is most educational. At this point I'd be willing to venture with a fair amount of confidence that what the "Rodime" drive actually amounts to is a cost-reduced/"hurry up" substitute for the prototype "Nisha" mechanism. (Folks here may remember that mysterious clear-plastic Apple drive prototype that showed up on eBay a few months ago; that was a Nisha. It appears to have been an aborted attempt by Apple's ill-fated Disk Drive division to make a viable successor to the Widget.) Both use a 26 pin connector, the pinout functions look very similar to the schematic fragments in the patent document associated with the Rodime drive, they appear to use the same data clock rates, and both have an onboard Z8 to abstract the drive's servo functions. (Which appears to be the major difference between Nisha and the Profile and Widget drives; it looks like both of those have the "host controller" board handle servo functions directly.) However, here's the slam dunk:

http://bitsavers.org/pdf/apple/disk/hd20/HD20_Ctl_f.jpg

http://bitsavers.org/pdf/apple/disk/nisha/iwm_nisha/IWM_Nisha_f.jpg

Apple had a prototype IWM-to-Nisha interface board. It has a big square chip on it. And the chip's part number is the same as the one on the HD-20. The "Rodime" drive isn't a Rodime drive; it's a Rodime mechanism with a slightly hacked Nisha controller board.

More fun... even before the Nisha they'd banged together an IWM controller board for the Widget:

http://bitsavers.org/pdf/apple/disk/widget/IWM_widget/

They even have dumps of the firmware for that. Looking at the pictures the Widget version also has a big ASIC on it, but it's a different part number. (The Widget and Nisha host interfaces are somewhat different, so that makes sense.) I guess IWM-interfaced drives were something they were fooling with for a while. And of course, it's really a shame that the one thing missing from this bitsavers archive is a document describing how the IWM was *used* in these drives. Pictures of the hardware and firmware dumps are great, but just *one* "theory of operation" document would be so, so useful.

As an aside, there's a .JED file for programming a PAL, the header of it says "Part mode PAL16R6A", in the directory that has pictures of the Nisha IWM board. By any chance that's not the same PAL you were trying to figure out earlier, is it? Granted, no guarantee that the contents would be identical. (Honestly, I don't think the contents of that thing *matters* if you're just trying to reproduce the high-level behaviour of a "whole" HD-20 rather than exactly clone it on a hardware level.)

The one thing we might get out of these documents: There's a PDF in the nisha directory that lays out the commands a Nisha+controller should respond to; if the HD-20 uses the same command having that reference might help figure out a disassembly of the Mac's HD-20 driver.

 

[Dennis Nedry]

8-o

What a lot of great info Gorgonops! Wow!

Here is the JED2EQN output from that PAL .JED file:

; JED2EQN -- JEDEC file to Boolean Equations disassembler (Version V063)
; Copyright (c) National Semiconductor Corporation 1990-1993
; Disassembled from IWM.JED. Date: 5-9-112

chip IWM PAL16R6

CLK=1 i2=2 i3=3 i4=4 i5=5 i6=6 i7=7 i8=8 i9=9 GND=10 /OE=11 f12=12 
ro13=13 rf14=14 rf15=15 rf16=16 ro17=17 ro18=18 f19=19 VCC=20 

equations

/f19 = i2 * /i3
   + /i2 * i3
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
f19.oe = vcc
/ro18 := i5
   + i6
   + i7
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
ro18.oe = OE
/ro17 := i5 * /i6 * /i7
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
ro17.oe = OE
/rf16 := /i4 * /i5 * i6
   + /f19 * /i5 * /rf16 * /i6 * rf15 * rf14
   + f19 * /i5 * /rf16 * /i6 * /rf15 * rf14
   + /i5 * rf16 * /i6 * /rf14
   + i5 * /i6 * i7
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
rf16.oe = OE
/rf15 := rf16 * rf15 * /rf14
   + /rf15 * rf14
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
rf15.oe = OE
/rf14 := rf16 * rf14
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
rf14.oe = OE
/ro13 := /i5 * /i6
   + /i5 * i6 * i7
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
ro13.oe = OE
/f12 = /i8 * /i9
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
   + i2 * /i2 * f19 * /f19 * i9 * /i9 * f12 * /f12
f12.oe = vcc

Here it is manually reduced (just removing the extra ORed lines that are set to always be false):

/f19 = i2 * /i3 + /i2 * i3
f19.oe = vcc

/ro18 := i5 + i6 + i7
ro18.oe = OE

/ro17 := i5 * /i6 * /i7
ro17.oe = OE

/rf16 := /i4 * /i5 * i6
   + /f19 * /i5 * /rf16 * /i6 * rf15 * rf14
   + f19 * /i5 * /rf16 * /i6 * /rf15 * rf14
   + /i5 * rf16 * /i6 * /rf14
   + i5 * /i6 * i7
rf16.oe = OE

/rf15 := rf16 * rf15 * /rf14 + /rf15 * rf14
rf15.oe = OE

/rf14 := rf16 * rf14
rf14.oe = OE

/ro13 := /i5 * /i6 + /i5 * i6 * i7
ro13.oe = OE

/f12 = /i8 * /i9
f12.oe = vcc

It looks similar to my equations in a somewhat different order, but the most clear proof that it's different is right in the very last line. On the HD20 PAL, f12.oe = OE = i8, not vcc, I tested this directly. The equations themselves may be more similar than they appear, but they appear to use a lot of previous gated states for gated outputs whereas the HD20 doesn't use any that I'm aware of.

The pinout listed in 062-0287-A_Nisha_Drive_Specification_Apr85.pdf is STRIKINGLY similar. To the point where I'm convinced that we have a Rodime pinout now.

I hereby shall use this terminology:

Mac <-(floppy bus)-> IWM Controller <-(Nisha/Rodime bus)-> Nisha/Rodime Controller <--> Disc Drive

Browsing through this document, it has occurred to me that the Nisha controller has no provision for different capacity other than changing IDs returned from a status/diagnostic call. So actual drive capacity must be equated outside of the drive, if it even happens, or it may be assumed that all IWM drives are 20MB in the Mac ROM or something. But the point is that the drive can not directly, specifically specify its own capacity. This document doesn't detail anything having to do with the protocol between the Mac and the IWM controller, it only explains what happens between the IWM controller and the Nisha controller.

It seems that emulating on the Rodime level and reusing the IWM controller is most likely to result in a single 20 MB drive, whereas emulation including the whole IWM controller has greater potential to tweak in more capacity. At the very least, emulation of multiple HD20s is possible if the IWM controller is emulated. The emulator could just abstract multiple emulation via daisy chain to form extra 20MB "partitions".

There are lots of good reasons to focus on emulating the entire HD20, IWM controller and all, but it's good to know that we have some potentially awesome documentation to fall back on if IWM difficulties point us back toward Rodime emulation.

 

[Dennis Nedry]

I've had the "FDPlus" Mac Plus ROM disassembly kicking around for a while but it doesn't specifically point out HD 20 stuff unfortunately. It's a LOT of code to walk up to. Here's what I was thinking about before the details struck me down. Attach microcontroller inputs to the following lines on a Mac Plus logic board:

Address lines used for ROM

ROM control lines

Data lines used for IWM

IWM control lines

clock

And record the state of all of these lines for each clock pulse where ROM or IWM control is enabled. You could boot up off of an HD20, start recording, save a text file on the Mac, and stop recording when it's done. Then step your way through this data, which will step you through the ROM instructions and IWM control needed for the HD 20.

One major problem with this is the speed of the Mac. At 8MHz, that's 8 million pulses per second, we're talking potentially 10s of MB of data per second, which is doable for a nice microcontroller but that takes a lot of fast memory. Then parsing through that much data could be daunting. You'll have a whole OS worth of interrupts weaving their way though. It seems like a good idea but there's probably just too much going on for it to make much sense.

I suppose you could look for IWM active control and then step backwards to look for what was happening in ROM right beforehand.

Alternatively, you could look specifically for IWM active control (less data to record, fewer lines too) and try to figure that out, not knowing what was previously happening in ROM. Saving a text file containing "AAAAAAAA", then again with "BBBBBBBB" and comparing similarities and differences might reveal something. Whatever happens before the data, encoded or not, it should be the same both times, so that should point out where the text data is and give clues as to the pre-IWM encoding. Then from there, the IWM can be dissected. No use trying to figure it out post-IWM in the Mac all in one go.

This could be compared with post-IWM data in the HD 20. It might be identical!

 

[Dennis Nedry]

It appears that the Z8 multiplexes address and data lines together on Port 1, which is indicated by Z8 pins 8 and 9 (data strobe and address strobe). Port 0 is used for higher address lines A8 - A12 which are used by RAM and ROM.

Part of the function of the large chip is to demultiplex address from data, as pins 8 and 9 run only to this chip. This uses a lot of pins and is fairly simple, so there's less we don't know about the that chip now.

 

[techknight]

ok, I was gonna say that the large ASIC could also provide function as an address/data decoder that sits between ROM/EEP/ and CPU.

might have to get some fuming nitric acid, a good optical scope, camera attachment, etc.. and decap that sucker.

 

[Dennis Nedry]

I'm happy to report that my HD 20 controller board is back together now. I meticulously checked each continuity from each pin that I soldered back together. As expected, on the main input connector where some vias were torn, it required 3 wires. But that's okay. They're on the bottom of the board too.

I powered on the drive and it DID NOT spin. I just about pooped my pants. But power cycling and giving it a bit of a twisting motion, it turned out to be just a bit of stiction... I haven't booted from it yet but all signs point to normal from the sights and sounds.

Just all the more reason that we need to make an HD 20 alternative!

Oh, also, my sockets came so the IWM and PAL chips can easily be removed and tested / intercepted now.

 

[Dennis Nedry]

It won't boot my Mac Plus anymore! xx( Worse, after trying, the question mark on the disk no longer blinks, that's worrysome. I probably bridged something or left an open somewhere. I'll be bummed if I don't find it.

 

[Gorgonops]

I hate to revive zombie threads and all, and I don't know if Dennis Nedry is still working on this project, but...

In looking up some information regarding storage options for the Apple IIc my attention was drawn to the "Smartport" protocol that Apple used to enable various devices, such as the 3.5 inch Unidisk drives and some hard drives, to talk to Apple II's equipped with a suitable IWM-based controller. Digging into it I have to wonder if the HD-20 is really very much different from a Smartport drive. The devices seem eerily similar in execution.

This file on Asimov describes a Compact Flash adapter designed to emulate a Smartport drive, and the documentation contains a few pointers to other places to find more information about the protocol. It might be worth boning up on Smartport a little and see if it helps make sense of whatever data you gathered while sacrificing your HD-20. I seriously wonder if the same hardware used to emulate a Smartport disk could emulate an HD-20 with some relatively trivial software tweaks.

This person is currently refining his own design for a Smartport flash adapter into a sell-able product. It might be worth contacting him to see if he could offer some assistance in tracking down appropriate docs, etc.

 

[krye]

I wouldn't mind having one of those smartport USB adapters. I remember stumbling across that site last year. The guy hasn't updated it since June 2011. It doesn't look like he's actively working on it any more.

 

[Gorgonops]

Yeah, if my pending deal to get a IIc works out I'm totally going to inquire about getting one of the USB Smartport drives, perhaps in kit form. Alternatively I might attempt to build the CompactFlash version detailed in the .zip file on Asimov. (The details in the file are sort of sketchy but it looks like there's enough there to figure it out.)

Back on the topic of the HD-20... I was reading the docs that were in that .zip file, and there's a brief paragraph in there about the communication protocol used for smartport packets. There are more details in the IIgs Firmware Guide (a messy .pdf of the assembly code for the Unidisk driver in the IIgs and IIc ROM is also included in the .zip), but this is the important bit:

"... These have been coded to have the timing correct to support the reading and writing of data via the apple disk interface read and write lines. These need to support sending a bit every 4us with a total time of 32us for 8bits of data. The smartport packet bytes always have the msb set, but the rest of the bits can be either 0 or 1. So the values can be 0x80 to 0xff. This is different to that of the floppy disk drive encoding scheme, which has to ensure that no more than 2 zeros occur consecutively (dos3.3)."

So apparently it *is* possible for the IWM to break the "no more than 2 zeros" rule. Looking through the assembly language code it appears the way the Smartport protocol works is within a (up to) 512 byte packet of data it divides the bytes into groups of seven. Each group has its most significant bit read of each byte and the data combined into one byte (with the MSB already set, since the IWM does require that.) Then the MSB-byte is sent across the wire, followed by the seven source bytes. (all of which have had their MSB set to satisfy the IWM.) At the receiving end, each byte gets is original MSB restored as it comes in, and the resulting "fixed" bytes are written into a buffer, which fills until the end-of-packet signal arrives.

I imagine it's *very* likely that the HD-20 does something similar. So, after all that blather about GCR code... it may turn out that communication with the HD-20 *isn't* GCR coded. Whee?

It might be interesting for someone who's conversant with 68k assembly to look at the Mac Plus code and see if there's an equivalent to the Smartport driver's encoding/decoding loops in there.

 

[bbraun]

FWIW, I contacted the USB smartport dev in April of this year, and he said he was just processing requests from 10months prior. I'd been added to the list and will be contacted when the time comes.

 

[Dennis Nedry]

I know enough 68k to be dangerous, but not without strict reference to the instruction set and lots of head smashing upon the keyboard.

I want to chime in that the Mac Plus that I tested my HD-20 on is not known good, so there is a chance that the drive is still okay, or just a short or open or two away from it. I don't currently have the resources to delve into my Mac collection, but this may change some day soon.

 

[uniserver]

I am hoping to use BMOW floppy EMU as a HD20 emu.

 

[napabar]

Dennis Nedry, any news?