• 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

for years i bought items on ebay

even the ones with: 'Shipping to: United States'

if you realy want an item,

ask sellers if they would send the item to your place

ask the amount for handling and shipping...

you have nothing to lose

 
by applefreak » 29 Nov 2010, 20:44
for years i bought items on ebay

even the ones with: 'Shipping to: United States'

if you realy want an item,

ask sellers if they would send the item to your place

ask the amount for handling and shipping...

you have nothing to lose
Yep, done that, and sometimes they oblige, and sometimes not. What the killer is is the cost of shipping from the USA to Australia. I just don't understand it. Asia to Austrla is cheap - understandably, UK/Europe is not too bad, Canada is not bad either, but for some reason shipping from the good ol' USA is down right criminal at times.

Recently I acquired copies of MS Word and MS Basic Interpreter for 128/512k Macs and it cost US$50 (ish) each to sent to the land down under, but nix, and next to nix for domestic. Similar size and weight packages from the UK only put me back the equivalent of US$20 for it to be sent by Her Majesty's Royal Mail.

Yep, the USA is a treasure trove of ye olde computer goodies, but be prepared to pay heavily for it to be sent down to this end of the planet.

 
What the killer is is the cost of shipping from the USA to... for some reason shipping from the good ol' USA is down right criminal at times.
And cursed be USPS for that. They used to offer Ocean shipping, but no longer. I am so thankful I purchase my compact Macs off EBAY when I did. I would have never even considered bidding on them, had USPS killed off Ocean shipping and I had been stuck with outrageous AIR mail as the only option. I also blame Americans too since they didn't make a stink about it and allowed USPS to do it (and as an American, I have every right to say that too).

Thankfully, Japan Post has retained its sanity, and I can ship virtually anything, anywhere by "reasonably priced" Ocean shipping. Sure it takes a month, but the cost savings is incredible.

 
It's not really that interesting, but that floppy disk for the HD20 is probably worth more than the unit itself.
Actually it is sort of interesting that once a topic becomes hot on this forum, suddenly the item in question begins turning up in spades.

As for the floppy disk, hardly rare. I see at least a dozen or so per year circulating on eBay with and without the drives. Mostly worthless in my opinion, as the drivers are freely available on the web, and more often than not, these floppies have been updated with the latest Systems the user was running at the time they discontinued use, assuming they even work, thus negating their collectability, to thextent they have any such value. I've seen disks, which didn't even have the HD20 software on it - the disk recycled once they stopped using the HD20. And for the record I've never seen an HD20 disk sell for more than a working drive. Nor have I seen a manual sell for more either.

There's rare stuff on eBay, but it is few and far between. Nothing discussed here is rare, and I hate this forum helping to perpetrate this myth in any way.

 
The HD20 is also designed to hold a 5.25" full height drive. The original Macintosh ROM contains a driver for the Apple Widget drive per Inside Macintosh...
Out of curiosity, where does it say that in "Inside Macintosh"? I have searched my PDF copy of volumes I-III and the only reference to a "Hard disk driver" is in reference to the soft-loaded ROM used in the *Macintosh XL* (Aka, the factory Hax0r-ed Lisa), not the "real" 64k ROM in the 128/512k. The Widget connected via an 8 bit parallel port rather than a crazy Rube-Goldberg floppy-UART nightmare thus I'd expect that any similarity between it and the HD-20 on a low-level driver level would be completely coincidental... although I do slightly wonder if the HD-20 software driver reuses the "Hard Disk" device identifier defined for the Macintosh XL Profile/Widget driver when it's loaded. (Apple says in the "writing device drivers" section never to reuse an identifier, but software companies that write the OS regularly break their own rules.)

... I have a Willem ROM programmer that supposedly can dump the 2764 ROM chip inside of the HD 20. Given that it's only 8 kilobytes, disassembly should at least be somewhat feasible and should shed some light on the Rodime and floppy interfaces. Once dumped, I shall certainly share the 8k file for others to poke around in. Theoretically, we can determine where the Z8 starts execution and disassemble from that point. From there we can determine what register is what, which ports correspond with what hardware, and form up all sorts of cool theories...
I really hate to be a skeptical buzzkill, but a number of people have promised at various times to build mass-storage devices to work on the original Mac, and it seems like they lose focus or get in over their heads pretty rapidly.

As I've unfortunately bad-tempered-ly expounded on before the problem with all these schemes people have is that no one seems to actually want to glue their butt to a chair, read *all* the relevant sections of "Inside Macintosh" over and over again until they understand it, and fire up a compiler/assembler capable of producing "period-suitable" balls of code to write a device driver capable of emulating a hard-disk-ish like device through, say, a null-modem cable before running off and playing with the TinkerToys. Sure, disassembling the ROM containing the Z8 code might shed light on a few questions, like explaining in more detail how exactly Apple managed to use the IWM as a UART, and if you *really* want to try reverse-engineering the proprietary Rodime hard-drive connector instead of the IWM interface delving into it might reveal some details on how command flags were sent to the drive and how data was serialized/deserialized. However, well... if you think you're up to groking a disassembler listing *why not read a disassembly of the HD-20 driver*? It just took me all of five minutes to get semi-commented disassemblies of the Mac 128k and Plus ROMs thanks to this pre-assembled kit of tools, so getting that code is a lot less work than actually tearing something apart.

(Of course, I am not a 68000 assembly programmer, and the driver is mixed in with, well, the entire contents of the Mac ROM but... it does appear based on my ignorant reading that the ".sony" floppy driver in the Plus has been extensively modified to support the HD-20 based on a comparison of the 64k ROM. If someone knowledgeable were to spend the time grokking this information they could probably determine exactly how the driver twiddles the bits on the IWM to figure out if an HD-20 is present and how data is transferred to it. Disassembling the stand-alone HD-20 init might also help. My guess is that the INIT probably just replaces the whole of the 64k's .sony driver with one similar to the Plus-es, but even if that's the case it would point out exactly what needs to be patched to replace the floppy driver and add HFS support.

Oh, and BTW, since this has come up in other discussions about making some mass-storage widget that would fit internally via the 68000 socket a disassembly should to answer the question of whether the ROM is extensible. I don't know about *general-case* extensibility, but one of the first things the Mac does on power-up is check a certain memory location to see if it contains a signature indicating "test software", and if so it jumps to an address... it's on the first page of the assembly listing. I would hazard a guess that devices like the Hyperdrive leveraged that hook to hijack the startup process unless finer-grained overrides exist within the individual initialization/boot code blocks.)

Anyway, good luck with your endeavors to be sure, but my position at this point is unless someone were willing to actually spend the time learning how a mass storage device for the Mac *works*, interface details aside, before jumping in they're seriously putting the cart before the horse. You can spend as many man hours as you like logging and oscilloscope-ing the interface to your heart's content, but unless you understand *what it's doing* before you try to figure out how it does it you'll be muddling around in the dark. It seems to me that the entire thought process behind these endeavors is that it's *impossible* for anyone to understand the Mac well enough to write a device driver for it and it would somehow be easier to reverse-engineer some antique and undocumented mass storage device perfectly enough that an existing driver could "just work" with your new hardware. "Wham, bam, thank you Ma'am, I just made myself a flash drive for my 64K ROM Mac without ever having to touch or understand 68k assembly or the Mac system software! Yay, that was easy!"

Color me unconvinced. If the HD-20 wasn't such a "black box" I'd consider it doable, but if the plan is to just haphazardly diddle with it and try to see a pattern in the bits without having the slightest idea what to expect I definitely wouldn't hold my breath waiting for success.

 
Color me unconvinced. If the HD-20 wasn't such a "black box" I'd consider it doable, but if the plan is to just haphazardly diddle with it and try to see a pattern in the bits without having the slightest idea what to expect I definitely wouldn't hold my breath waiting for success.
I understand your mentality Gorgonops. It's very hard to say how complicated this thing is. We have several tools at our disposal:

  • A ROM dump that can be disassembled fairly easily (small in size, performs a dedicated task, simple CPU, much less complicated than a Mac ROM)
  • Existing documentation of floppy drives
  • Observable signals
  • Very very old and presumably not way too complicated


Any of these things may be impossible to use on their own, but combining them and observing correlations is basically what needs to be done. There could be things that we don't understand, for example spin-up procedures and diagnostics, but by simply replicating what we see and telling the Mac what it wants to hear, we can make the Mac think the drive is okay and proceed as normal. This is what I was referring to with the black box. There will be a lot of details that WILL need to be figured out to make any sense of the commands and data.

I feel pretty good about it. I don't promise an immediate solution, but we will definitely make significant progress. There are things that I know that I can do with this drive that haven't been done yet.

The guy who just sold me an HD 20 has another cheap one for sale if anyone's interested, and apparently it works:

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=170572138162

 
Very very old and presumably not way too complicated
I sort of have to take issue with that statement, because you're making the assumption that something "old" and "simple" won't be "complicated". Minimal and "elegant" hardware designs are often some of the *hardest* to wrap your mind around because they offload much of their complexity into the software driver, leaving the hardware as a minimal pile of gates and latches that completely depends on split-second timing and oddball encodings.

I'd also say that looking at a disassembly of the Z8 *may* be less informative than you'd actually like... don't get me wrong, it will undoubtedly provide some insight about how the floppy interface works, but... the thing to keep in mind is it's perfectly possible that the HD-20 itself is a relatively "dumb" device, with the Z8 essentially fully occupied driving the IWM and arbitrating communication with the Mac, while commands actually targeted to the drive mechanism and its associated controller might just pass fairly transparently through it. (IE, the Z8 gets a data byte off the wire and all it does is decode it and based on a header either shoves it into the HD controller as a "step head" command or whatever or shoves the data into the read-write buffer to await a "flush" command.) If that's the case then a disassembly will tell you a lot less about what sort of responses the Mac will be waiting for from it then decoding the Mac driver will.

(Or it may be a very intelligent device and a disassembly will reveal all. Just don't make any assumptions, here.)

I feel pretty good about it. I don't promise an immediate solution, but we will definitely make significant progress. There are things that I know that I can do with this drive that haven't been done yet.
Again, I wish you luck, but I also caution that if you intend to follow through with this it behooves you to learn as *much about the high-level operation of this thing as you can*. I could be completely wrong, but it sort of strikes me at times that you're a little fuzzy about what you should expect to see out the floppy port when it's speaking to a floppy drive, let alone how it might go about encapsulating data for the HD-20.

I hate to bring this up again, since people seem allergic to admitting that it *is* possible to write low-level storage drivers for the Mac, but... Basilisk II has ROM patches that replace the .sony driver. And, from sony.cpp:

Code:
*  SEE ALSO
*    Inside Macintosh: Devices, chapter 1 "Device Manager"
*    Technote DV 05: "Drive Queue Elements"
*    Technote DV 07: "Forcing Floppy Disk Size to be Either 400K or 800K"
*    Technote DV 17: "Sony Driver: What Your Sony Drives For You"
*    Technote DV 23: "Driver Education"
*    Technote FL 24: "Don't Look at ioPosOffset for Devices"
I'm sure they're all good reading, but... just as an example, Technote DV 17, Linked right here, opens with the words: "This Note covers the external (software) interface to the Sony 3.5" floppy disk and Hard Disk 20 driver." It confirms that the HD-20 driver is embedded in the .Sony driver, it explains what drive status codes apply to the HD-20... a *particularly* interesting tidbit is this:

Return Physical Drive Icon (csCode=21)
This call returns a pointer to an icon describing the selected drive's physical location. The supported drive icons are shown in Figure 2. Note that only the icons for a particular machine are included in that version of the driver. The Hard Disk 20 icon is in the drive's ROM, so it is available only when a Hard Disk 20 is connected...
That means at some point during initialization *a high-level call is made to the HD-20 requesting an icon bitmap*. There's something you could focus on. If you can find that icon in the HD-20's ROM and figure out what is sent to trigger the drive to spit it out that could crack a good portion of how the command interface works in one blow...

But, eh, that's just how I might do it if I cared enough. If you want to bootstrap it up from bare bits go for it.

 
From everything I can tell, the page of calls that you linked to are operating system calls. Generic disk icons are stored in the System File, not in a disk drive's hardware, or on each disk! It even mentions that control calls are "opcodes" which seems to refer to A-Line traps, which are strictly 68k OS calls. These would not be passed directly to any hardware. That is the purpose of Mac OS and the Sony driver, to reside in the Mac, use the Mac's processor and memory, receive these OS calls, and finally the sony driver sends low-level controls to the IWM. The IWM then does the appropriate hardware logical functions to disk drives. These are things like stepping the head, writing data, reading data, spinning the disk, checking the write-protect switch, etc. Disk drives are really really stupid, basically more analog than digital.

I appreciate your perspective and your constructive criticism. Because the HD 20 must cleverly use the signals from an IWM, and we know a bit about IWM, this is where my confidence comes from.

 
Oooo I see what you mean now:

while the Hard Disk 20 icon is retrieved from the drive's ROM.
That could be tricky.

That's one of those things that can be figured out by disassembling the HD20's ROM or by just replicating the signals. Whatever command it sends to fetch the icon, followed by a return of the icon data, we don't necessarily even need to know what's happening to pipe it right back through. It could have been resolved with the black box sort of thing. It's very good to be aware of that sort of thing though.

 
From everything I can tell, the page of calls that you linked to are operating system calls...
I was about to post a snippy response to this, but I think you've figured out that I wasn't talking out of my arse. ;^b Much of the Mac's OS *is* in the ROM.. and if you look through a Mac Plus ROM disassembly I think you can actually see where the generic "Mac Floppy" icon is stored. (It's near the end of the block of code under the "P_Sony_RdData:" heading, and I suspect one of the unnamed subroutines within that section is what responds to the documented "Return Physical Drive Icon" system call. Only "known", IE, reverse engineered by the author of vMac for the most part, sections of the code are actually denoted with human-readable labels.)

Anyway, the technote document points to there being some routine buried in there that says "Hello Mr. HD-20, please send me a pretty picture, kthxbye!", and all I was doing was suggesting that it *seems* like an example of a code path that might be relatively easy to find on both ends and which would enlighten how the IWM-as-a-UART things works in a vacuum without the complication of tracing a transfer of real data or looking for hard drive control codes which may not be obvious from a dissection of the Z8 code. (A lot of that depends on how "intelligent" the Rodime drive/host controller combo really is. We just don't know that definitively. The drive has its own Z8 on it after all, and the operating description in the patent application may not cover everything, particularly the possibility that the drive might have some Apple-specific firmware on it.) There may be other tidbits like that scattered around, just waiting to be found....

Which of course, the point I was really trying to make. There's a lot to be learned by reading all the documentation you can find for clues before just diving in. If you really want to tackle this from a low level "Disk drives are really really stupid, basically more analog than digital" (your words) point of view I'd honestly strongly suggest not starting with the HD-20 and instead concentrating on replicating a 400/800k floppy drive. Those *are* (mostly) dumb devices. The HD-20 is not, so starting straight with it leaves you having to figure out both the subtleties of the physical interface (IE, voltage levels, peak-to-peak variances, how to extract syncing/clocking information, how to convert the GCR nibble-encoding back into bytes, etc, etc.) *and* trying to reverse-engineer the high-level commands sent over that interface. (Another hint from that technote suggests that the HD-20 *may* be fairly "smart". The section about "formatting" suggests that the HD-20 uses linear addressing for its 38-thousand-something sectors rather than accepting explicit head/cylinder commands, for instance. It wouldn't surprise me if from a high level it ends up looking fairly SCSI-ish.) What you seem to be planning comes across as being akin to trying to learn how to read and write fancily-formatted ANSI text to/from terminal at the same time you're trying to reverse-engineer the modem it's connected via by tapping the tones on the phone line. If that's where you're starting it might behoove you to concentrate on making the modem first, and only after you have it reliably converting white noise to a serial bitstream *then* you can try sniffing the terminal protocols. (And even then you still might want to look up as much data as you can... starting at *least* with an ASCII chart?)

(I'd also suggest it might be a good idea to state straight-out which interface it is you're trying to crack here. Is it the Rodime interface or the HD-20 floppy interface you're after? If it's the former, forget everything I've said. Read the patent document, hope it's correct, hope there's enough high-level code in the HD-20 Z8 to grok out what commands it responds to, and hope that the ASIC-thing that makes up the host controller isn't particularly intelligent. Everything I'd suggested is with reference to making a device which can emulate an entire HD-20 via the floppy interface. Emulating the Rodime might actually be "easier" electrically, but you're totally on your own when it comes to docs. Which... may be what you want?)

Anyway, just saying that learning to walk before trying to learn to fly might not be a terrible idea. But I'll admit I don't have any formal education in electronics and I'm all thumbs with a soldering iron so perhaps I have *completely* the wrong idea, and with a dead HD-20 in hand it might *totally* be as easy as pie to reverse engineer the whole shebang at once. Keep everyone posted and all.

 
Actually it is sort of interesting that once a topic becomes hot on this forum, suddenly the item in question begins turning up in spades.
I was not referring to the thread. Most threads on the Compact Mac forum are interesting, hence why I read/post most often here.

As for the floppy disk, hardly rare. I see at least a dozen or so per year circulating on eBay with and without the drives.
Interesting. One would figure with age/degradation of the floppies they would become more rare as most are rendered useless.

There's rare stuff on eBay, but it is few and far between. Nothing discussed here is rare, and I hate this forum helping to perpetrate this myth in any way.
Wasn't trying to go in that direction. I realize how irritating it can be when someone posts something as "rare" online when it fact it is not. Regardless of this "inconsistency," collectors still go bananas on eBay.

 
I honestly do not understand why people get so worked up on this forum. I'm a member of several similar sites and they are able to keep everything polite, but here you get a smack across the chops for even mentioning something. Come on, let's try to help, not upset. We all have a common goal, and that is an interest in older computers, especially those made by Apple.

 
I agree, but all in all, the "Compact Mac" forum here is definitely my favourite! This thread in particular has drawn out more information than I could have imagined, unfortunately not what I was after when I started this thread, but very education none the less.

If anything comes of it, great! If not, it has been enjoyable, and thanks!

I'm interested in the Compact Macs because of the impact they had on me when they appeared on the scene bay in '84, even though I stayed with the Apple2 camp for the programming that I was doing after university. I have little to no interest in the desktop Macs that came after the SE, until the arrival of the iMac of '98. I regret that I don't have any skills to offer in the endeavor to get the HD20 nutted out, but I'll support the process (project?) in whatever other ways that I can.

So everybody, let's keep the discussion strong and fruitful, and enjoy the ride.

Michael

 
Well, I'm not going to be discouraged. I'll do what I can with the knowledge I have and we'll just go from there. There are other engineers among us to help where I fall short.

 
I honestly do not understand why people get so worked up on this forum. I'm a member of several similar sites and they are able to keep everything polite, but here you get a smack across the chops for even mentioning something. Come on, let's try to help, not upset.
I'm not upset, JS, or worked up. I just replied to a thread. No vulgarity, nothing. Can't I speak anymore? :-/

We all have a common goal, and that is an interest in older computers, especially those made by Apple.
Although the Amigas during the early-Mac era were far more superior (OK, now bash me for turning to the Dark Side).

 
Definitely the best forum for my interests. I love when people just want to help and pass on their knowledge, and hate it when a handful of people react negatively to everything and expect us to all be experts. We are here to learn from those who know, everyone has to start from somewhere.

 
Nothing personal Concorde, I just keep seeing negativity and the like, which detracts a little from what is a great website. Now just felt like the time to bring it up, so don't read into it too much.

 
Back
Top