HD20 Schematics required

[Dennis Nedry]

Thanks for the summary. I will go back and read your entire post from before, I just can't focus on it all at once.

[Dennis Nedry]

Dennis Nedry potentially sacrifices his HD20 controller board for the army...

This is a progress image, NOT COMPLETE. I have removed a large number of items from my HD20's controller board in order to visually get the circuits copied. That's the only reliable way that I'm aware of, and I have absolutely found traces that split off into multiple traces beneath chips and connectors, things that I would not have found any other way. This data will be an invaluable tool to learn more about this drive, and I believe that it will lead to the emulation of this drive some day, even if it is beyond my abilities and/or patience. I am okay at de-soldering but not a pro, unfortunately... There are several lifted pads.

This was a FUNCTIONAL HD 20. I think I'll get it to work again, but if not I still think that it's worth it. If anyone has a seized up HD 20, maybe we could work a deal. I don't really want to put this board back together because it's a great reference for us. Also, I will not touch my Rodime drive, I won't even risk removing the board from it. If I can get one that's seized up solid, I would be able to take the board off and chart it out like this controller board, and that could help us figure out some pins. I did some very limited continuity testing on my Rodime and found 2 pins that feed directly to schmitt trigger inverter inputs, so already we know that those 2 pins are input-only on the drive. Taking the board off of the drive and removing the chips could tell us a lot more. I have no idea where most of the pins connect on the Rodime.

Anyway, when I'm satisfied with this graphic, I will then begin to verify some things stated earlier in this thread and post my findings in a useful way, possibly on the wiki and/or my website.

Red = front
Blue = back
Seen from front.

[Dennis Nedry]

This image is complete but requires verification. I don't doubt that I missed a few lines. Some are very hard to see, for example, under a component I didn't remove or exactly under text/lines/etc. About half-way through, I discovered that if I put it up against my screen, the light shining through made the traces WAAAAY easier to see.

I am doing this in Osmond. It seems like an okay app for basically being free for this purpose. It's definitely not pro-quality, but it looks like it does okay. I'm open to suggestion if you know of some cooler PCB software on the freeware/shareware level. I've run into a few crashes and a few glitches after saving with this program, but nothing that I couldn't go back and touch up easily.

[trag]

Is that a two layer board? I ask because it looks like the Gnd and Pwr busses are made of traces, so I'm guessing there are no separate Pwr and Gnd layers.

[Bunsen]

Dennis Nedry potentially sacrifices his HD20 controller board for the army...

I'm in awe.

I hereby nominate your HD20 for a citation for the MLA Purple Heart with full bars & clusters.

[Dennis Nedry]

Trag: Yes this is a 2-layer board. Holding the board up to a light source reveals no additional layers.

Bunsen: I totally agree, and that's the only reason that I could justify it. It also makes it more important to get something useful from this, so I'll be hard at work.

[Dennis Nedry]

Important discovery:
The Z8 processor is not on the main address bus, and consequently does not directly control the address of the RAM or ROM chips. And the large chip contains all of the possible address and data lines.

The Z8, IWM, and PAL share a common 7.5 MHz clock. This clock is not shared with the large chip.

7 of the Rodime pins are connected exclusively to the large chip, and 9 Rodime pins are connected to the Z8. Some of the Rodime/Z8 pins are also connected to the large chip. Many of these Rodime pins have pull-ups or series resistors.

The plot thickens...... How could the Z8 execute from ROM without direct access? If the Z8 does indeed execute from the ROM chip, there must be combinational logic contained in the large chip that allows the Z8 to look through it to the ROM. The alternative is that the Z8 isn't in fact ROM-less, and the ROM chip is used for some other purpose. It did disassemble into code that seems to make sense, so I still believe that it does execute from the ROM chip.

[Gorgonops]

Poor HD-20. I assume the ultimate goal is to lay this out into a 2D schematic? (With the IC's labelled and pin 1 marked?)

Completely off-topic, I happened to stumble upon a vintage computer mailing list post that mentioned in passing how the original Apple Profile drives worked: The short version is that conceptually the Profile drives were very similar to the Disk ][ drives, in that instead of buying "complete" drives from the manufacturer and using their specifications for the digital electronics Apple just bought bare mechanisms and "rolled their own" interface starting from analog up. (In the Profile's case said mechanisms were Seagate ST-506s and 412s.) Anyway, the post mentioned that there is a fair amount of documentation regarding the Profile drive on Bitsavers.org. Look here:

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

The "Profile Level II Service Manual" goes into gruesome detail about how the Profile drive works, but... here are the bits that are interesting:

1: The Profile digital board used a Z8 CPU to implement the "high-level command set". That's an interesting coincidence, given the Z8 is also used in the HD-20 controller. And:

2: The names of the signals present on the connector between the Profile's digital and "Analog" boards almost exactly match the signals that are named on the patent document describing the Rodime 552 drive. Like... spookily the same. Reading the theory sections makes it sound as if the "division of labor" between the two boards is the essentially the same; In both systems there is a low-level MFM or RLL encoder on the "drive board" (MFM in the case of the Profile Analog board, RLL on the Rodime's board) that accepts serialized data from the "controller board" (via "READ DATA" and "WRITE DATA" lines for "/NRZ serial data"), both have "sys clock" lines (10Mhz for the Profile, 15Mhz for the Rodime, which makes sense for MFM vs. RLL")...

There are differences: In a spooky parallel to the difference between a Disk ][ floppy drive and a Macintosh floppy drive it *appears* to me that the Profile interface breaks out the raw stepper motor connections to the analog/digital interface, while the Rodime, with its own onboard Z8, accepts high-level commands for head positioning. (It says so much in the patent document.) But other than that I'd say with 90%+ confidence that the Rodime drive, for all its "specialness", is in fact just a slightly evolved version of the Profile (At least the mechanism+analog board portion of the Profile.).

As noted, there's substantial documentation for the Profile on Bitsavers; the parallel host protocol is well documented enough that More than one re-creation of it exists. The firmware files for the Profile's Z8 are on Bitsavers; it might be *very interesting* to dive into them and see if there are any matching blocks of code compared to the HD20's ROM dump. (Unfortunately there may *not* be that much similarity because of the differing head positioning protocols, but it still might be worth a look if you're really interested in the "Rodime" side of the code.) Complications with the IWM in place of the parallel interface aside I wonder if they might even use the same command set on the host side. (That's a Hail Mary, but you can always hope. The idea there would be is there's some jump table that vaguely matches between the two.) In any case, *somewhere* in the code is the command parser; if you can find it and can work backwards from that point to how it *receives* the command (IE, what torturous things happen between a byte erupting from the IWM's I/O port to that byte making sense to the command parser) you'll almost be at the goal posts.

Oh... Re: "Important discovery":

I would bet you a shiny new nickel that the biggest job that mystery chip does is serializing and deserializing data from/to a buffer in the RAM chip. (This job was mostly discrete hardware on the Profile, which means that chip is probably at least in part a single-chip condensation of the Profile's digital board.) Data will be spewing back and forth from the Rodime at 15Mhz and there's no way the Z8's going to handle that in software. The mystery chip undoubtedly has to put the Z8 on hold and use DMA to cram that data in and out of the RAM at warp speed. Meanwhile, the pins which are connected exclusively to the Z8 are almost certainly the control lines.

The patent doc has some signal names and partial schematics; it's *totally* unclear to me looking at any given partial schematic what the "P" numbers that show signals running off the page refer to. (It almost seems as if the schematics were intentionally partially obfuscated.) Does the (Rodime) board have any labels like "P1" next to its host connector? If it does, you could try matching those pins up to the the schematic fragments and see if, for instance, the serial read/write lines are indeed among those connected solely to Mr. Big Chip.

(EDIT: Profile Level II Service Manual, page 3.36. There's a block diagram. The top 1/3rd and right 1/2 of the diagram, including the shift registers, CRC generator, and Data MUXs... that's probably what's inside that big chip.)

[Dennis Nedry]

Here is the Osmond file (will open as text if you just click it normally, so save the link):

http://www.d.umn.edu/~bold0070/projects ... ematic.osm

Thanks for the info Gorgonops.

I was honestly looking for a clearer distinction between Rodime-related parts and Floppy Bus-related parts, but it seems that everything critical has its fingers in that big mystery chip. I think that from this, we know how the daisy chain port works and how I/O is managed through the PAL. Beyond the IWM, a lot of assumptions have to be made, and I'm not sure if that's the easiest approach anymore.

I didn't label pin 1 or draw part outlines or any of that. Please use a photograph as a part reference at least for now. I'll probably put this board back together at some point. It might take an extra wire here or there but I'm pretty sure it'll be okay. I did not destroy the board by any means, and actually I have a couple sockets on order so that I can easily take the PAL and IWM chips back out as needed.

In one of the photos in the link you posted, Gorgonops, the controller board has a socket for the Z8 and PAL. This makes me wonder if the Z8 isn't ROMless - I can't imagine any reason to be pulling the Z8 out frequently. Also, underneath my Z8, it has "820-0157-A" printed on the board. None of the other chips have this.

Anyway, at this point with the mystery chip sitting squarely in the way, a Mac Plus HD 20 ROM hack might be a more appealing approach. We are basically dealing with serial data, an encoding scheme, and control lines. We have some idea of the function of the control lines from the HD 20 board. It seems reasonable that a great deal of information about the encoding can be learned from disassembling the Mac ROM.

[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/nis ... isha_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]

What a lot of great info Gorgonops! Wow!

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

Code: Select all

; 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):

Code: Select all

/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! 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.