Jump to content

Floppy emu - Emulating HD20 :-)


Recommended Posts

http://bitsavers.trailing-edge.com/pdf/apple/disk/hd20/

 

This information was already talked about some what… and has already been seen by Mr. BMOW him self…

https://mac68k.info/forums/thread.jspa?threadID=252&start=60&tstart=0

 

All i can say is MY GOD WHAT A MASSIVELY COMPLEX/PROPRIETARY WAY TO ATTACH A HD TO YOUR MAC!

(look at doc's) Everything is special… Special HD-PCB, Special interface Board, Special Software in rom….

 

If anyone has any info they would like to add about this please feel free.

 

From BMOW:

HD20 is a totally different thing, and other than using the same DB-19 connector it has nothing at all in common with the floppy drive, so it might need a total re-write to do it.

 

He's done a boat load of work on this asis!

 

Also :

According to http://www.mac512.com/macwebpages/hd20.htm, there are only six Macs with HD20 support in ROM - the Mac Portable was the last. Too bad it's not compatible with more models.

 

With only 6 macs with support for this… might not even be worth the time?

i dunno it would be a great option for the mac portable!!!!!!!!!!!!!!!!! :) Something other then making one of those annoying 34 pin to 50 pin adaptors…

there is 2 floppy ports in there too :-)

Link to post
Share on other sites

Wholy crap, I didnt know that was out there. There was a thread by dennis nedry that was discussing the HD20 and reverse engineering it. Maybe thats his site? info? I dunno.

 

Regardless, looking over the docs the protocol is actually really simple. Yea it was extremely complex back in the day though. I noticed it takes FULL Advantage of the state machine of the IWM, and it uses a dedicated PAL to break down the states into a workable addressing for the on board microcontroller.

Link to post
Share on other sites

so you are feeling that it maybe possible?

 

you looked at those docs and have sort of an understanding of how you might make it work?

Sounds like the IWM is kind of a nifty chip :)

 

the 128k / 512k would still need to be booted from floppy /w init as you said… but would be worth it to have 2 gigs of SD HD :)

any mac w/o scsi would greatly benefit from this…bus powered!! no need for stupid power bricks.

 

maybe sell it as a separate product… with a angled external floppy connector… no need for screen, heddars, buttons

just plug in… pop in floppy and boom … insta FDD SDD :) lol sell it for same price. i'm thinking there is a market for it.

 

or pop out 128k/512k roms and pop in plus roms… and install internally.

heck i bet most peoples 400k fdd in there is gum'd up anyways. :)

 

HD20 EMU 89.00 !! :)

Link to post
Share on other sites
Wholy (@rp, I didnt know that was out there. There was a thread by dennis nedry that was discussing the HD20 and reverse engineering it. Maybe thats his site? info? I dunno.

 

During the last long thread about this I threw in some links to bitsavers (where this is) and the *important* parts of the HD20 directory, the two .pdf files which discuss the command format and the directory with the firmware listing, definitely weren't there at the time. (The dates on said files/directories are September/October this year.) Those .pdf files are the missing piece that in theory should make emulating an HD-20 "not that hard" once you have a device (like the Floppy Emu) that can "arbitrarily" communicate over the IWM connector. It's fair to say that the mechanics of the data transfer (IE, using the IWM as a UART, etc.) had been pretty much sussed out but lacking the command set information was a big black spot. Pretty much the only way to figure that out would have been to:

 

A: Accurately disassemble the driver, and from there step backwards through the other parts of the OS which makes calls to it, and/or:

 

B: Put together a test program which bangs on a working HD-20 and log/analyze everything the signal lines are doing when the drive is commanded to do "X", "Y", or "Z".

 

The .PDFs are awfully short on detail and the expected return codes from some of the operations (like all the diagnostic ops) aren't really specified, but it's still a huge leap forward.

 

Honestly if you can work out the details (which, again, should be much easier now) emulating an HD20 could be easier than a floppy drive. The protocol is "packet based", IE, it sends discrete groups of 7-bit encoded bytes, and it appears to allow for the drive to take (within reasonable limits) arbitrary time to complete the request when executing sector read/write commands. (You're not actually having to emulate the mechanics of real "spinning disk", the HD-20 is an abstracted "storage device" like a SCSI drive.) That implies at least that some of the SD Card latency issues that BMoW runs into when emulating floppies won't matter anywhere near as much. And, again, the protocol appears to allow arbitrary device sizes (within reason), so a device set up as an HD-20 emulator should be able to, for instance, make direct use of vMac or BasiliskII disk volumes by just checking the size of the file and reporting it to the Mac at boot time.

 

Anyway, nice that these docs *finally* cropped up. They've been wanted positively forever.

Link to post
Share on other sites

Well that is very promising information.

 

It would be great if BMOW had some more time.

I know he is a busy dude going forward with Floppy emu right now.

 

(Witch i have been using the heck outta, and cannot find one single issue with it)

viewtopic.php?f=4&t=22539

5a1d054d7aea4_ScreenShot2013-12-18at2_33_44AM.png.0dca58e051d432e97e17f70a0b2c2372.png

 

HD20 emu to me sounds exciting, and useful.

I know its not speedy, i just see a unit like this, and people breaking out their 128k's 512k's 512ke's and now getting some serious use outta them. Just think of the mess of software you could put on one of these. and the Slow 500kb data rate is no problem… all the apps you would be running on 128k/512k/512ke would be smaller in size anyways.

 

I also I do see a use for this to maybe supplement booting from ROM in your HDLESS Classic?

 

and the portable with its proprietary hard drive, I could see this used to copy valuable old data from these conners!

if you are someone with no external scsi hd or zip, just gives you more purpose for your HD20 EMU!

Maybe Dougg3 could add HD20 support into the his rom? then you could also use this with the II/IIx/IIcx/IIsi - SE/30 -- the Iici still has HD20 support for some reason.

 

http://www.mac512.com/macwebpages/hd20.htm

HD20 Supported machines.

The following Macintosh models have support for the serial (non-SCSI) HD-20 built into ROMHD20 under a Macintosh

* Macintosh 512Ke

* Macintosh Plus

* Macintosh SE

* Macintosh Classic

* Macintosh IIci

* Macintosh Portable

Download the HD20 INIT (28K file)- This lets your old Macintosh 128K or 512K use 800K disks and the HD20 hard disk.

Add it to an existing boot disk (System .97 - System 3.3) from the System Software Download Section.

(Thanks to the pickle for the idea to add it to this page)

 

 

The following Macintosh models do NOT have this support built in:

* Macintosh SE/30

* Macintosh II

* Macintosh IIx

* Macintosh IIcx

* Macintosh IIsi

* Macintosh IIfx

* Macintosh LC

Link to post
Share on other sites
  • 1 month later...

I looked at this a bit more, and I think it's probably not going to happen. At least I think it doesn't really make sense to pursue, given the difficulty that looks to be involved, when mmcmaster already has a working solution for an SD SCSI disk emulator that would accomplish almost the same thing. I did identify a few interesting notes in the docs, though, and a whole bunch of questions that need answering.

 

The two main docs of interest are the specifications for Directly Connected Disks, one from March 1985 and one from May 1985.

 

The good news is that the communication protocol allows for several daisy-chained HD20's, with a floppy drive at the end of the chain. Block addresses are three bytes, implying a maximum disk size of 8 GB if 512 byte blocks are used. The protocol uses handshaking for the drive to signal when it's ready, which should avoid the problems I had with floppy emulation where some SD cards aren't fast enough to keep up with the Mac.

 

Bad news: First off, the handshake method described in the doc doesn't make sense to me. For drive-to-Mac transfers, the doc says the drive should continue sending data until the handshake signal is de-asserted (May '85 doc, bottom of page 4). But the handshake signal and the drive data are sent on the same pin, and just interpreted differently depending on what state the transfer is in. Once an open-ended data transfer has begun, and it's using that pin for data, I don't see how the same pin could be used to indicate the end of the transfer. I must be misunderstanding something, but the provided examples don't go into enough detail to explain it.

 

The March and May versions of the spec have *major* differences. That would be OK if we knew for sure that the May document was the final version, but if the spec changed that much in two months between March and May, I'm guessing that it continued to change after that. So the May doc is probably not entirely correct or complete, and using it as the starting point for emulation would be problematic.

 

The size of a block is not mentioned anywhere in the May doc. The March doc says it's 532 bytes, which is a little baffling, and I strongly suspect that includes some extra metadata that's never described. A floppy sector (block) is 524 bytes, of which 12 is tags and 512 is the actual data. Does HD20 use tags? Does it include some other, or additional per-block metadata? The doc doesn't say.

 

The HD20 checksum algorithm is not defined or described anywhere. It's a one byte checksum, so it can't be the same algorithm that's used for floppy checksumming.

 

In addition to read, write, and status commands, the May doc also lists about a dozen other commands and their parameters, but it never says what those commands do or what response the drive should make. These include device id, seek, park, format, servo status, diagnostic stuff, and others.

 

I spent a while digging through a disassembly of the Mac Plus ROM looking for help, but I couldn't even identify where the HD20-relevant routines were, so it was a dead end.

 

Lastly, I realized I don't know how I would go about testing this. I don't have any disk images of an HD20 drive, and I'm not sure what one would look like, if they truly have 532 byte sectors. And unlike a floppy, I can't plug in an HD20 after the Mac has already booted, and then ping it with a test program. It has to be present when the Mac first boots, which means I can't easily observe what's happening as it queries the drive.

 

TL;DNR - Lots of questions and undefined details from the docs, probably all solvable with enough time and effort (especially with a disassembly of the HD20 ROM routines), but probably not worth the headaches given that a nice SD hard disk solution already exists.

Link to post
Share on other sites

It's a shame the HD20 is still such a Black Box type of device, even after those docs were posted. I know if I had one of those few Mac models that had a floppy port but no SCSI, I'd be doing a "The Scream" to the tune of "NOOOOOOO!" at the fact that BMOW's floppy-emu will not support this any time soon.

 

There's also the consideration that, given that such emulation would at some point need to be checked against the real deal, the window of opportunity for some Impressively Stubborn Researcher to figure it all out is rapidly closing as the world's supply of working HD20s evaporates due to age-related hardware failures.

Link to post
Share on other sites

As noted, the *one* place where an HD-20 emulator would provide a unique value proposition is as a storage device for the original SCSI-less Fat Macs; an SD->SCSI device is of no help there. Outside of that it's basically a waste of time. But I totally understand why it's a daunting proposition and you wouldn't want to take it on; the lack of good documentation for the devices is positively infuriating.

 

(I suspect it's to no minor degree intentional obfuscation in order to make the HD-20 difficult to clone. Apple broke their own rules with that device, having told 3rd party developers since the Mac's introduction to use the serial ports for any hard-disk like devices.)

 

The "DV 17" tech note and several other sources back up that "532 byte" block size, but likewise they're not at all forthcoming about what the extra bytes are actually used for. And, yeah, the rest of those docs on Bitsavers basically raise more questions than they answer. There's no sample return values for basically any of the function calls.

 

The good news is that the communication protocol allows for several daisy-chained HD20's, with a floppy drive at the end of the chain.

 

Just for the record, I think that daisy-chain mechanism it describes is the same used for "smartport" floppy drives as used on later Apple II family drives. I *think*.

 

Bad news: First off, the handshake method described in the doc doesn't make sense to me. For drive-to-Mac transfers, the doc says the drive should continue sending data until the handshake signal is de-asserted (May '85 doc, bottom of page 4). But the handshake signal and the drive data are sent on the same pin, and just interpreted differently depending on what state the transfer is in. Once an open-ended data transfer has begun, and it's using that pin for data, I don't see how the same pin could be used to indicate the end of the transfer. I must be misunderstanding something, but the provided examples don't go into enough detail to explain it.

 

So... I can't claim I really understand it myself, but I *think* what's really poorly explained in that section (or just sort of implied) is that the handshake is really only semi-bidirectional. IE, the way I interpret it is:

 

A: If the Mac needs to interrupt data transmission (which is of a fixed standard size... probably a "block", but there's also references to "groups" so it could be either) TO the drive it can tell the drive it's stopping by fiddling the phase lines.

 

B: If the Mac needs to interrupt reception of data FROM the drive it can fiddle with the phase lines to tell the HD-20 it's not listening anymore, and then simply ignore any data that comes from the drive in the period between the Mac saying it's not listening and the drive acknowledging the stop.

 

C: I don't actually see a mechanism for the HD-20 to halt transmission from the Mac. The annotations on the diagram on page 9 say that the drive needs to respond within X amount of time to the Mac asserting a holdoff, but it doesn't say anything about the drive being able to tell the Mac to back off.

 

With that in mind there must be some pretty strict cadence that's observed in the driver to ensure that the HD-20 isn't overrun by data during multiblock transfers, and I think that's *partially* described in the protocol layout; after each data block there's 70ms of "silence", after which there's another 14ms for the HD-20 to say it's ready for the next sync block. Assuming the Rodime drive had typical-of-the-era rotational speed and track-to-track stepping time that 80ms-ish window is probably sufficient to allow the drive to keep up in real time for consecutively-addressed blocks even if it has to step. (The drive has a buffer big enough for a couple of blocks, that also undoubtedly helps.) I do sort of wonder how the system handled, say, bad blocks (were those tracked by the drive transparently or at the file-system level?) or if extra time was hardcoded into the driver to allow the disk to seek when the next read/write transaction was non-contiguous with the last...

 

Anyway, yeah, documentation is *bad*. Reverse engineering this is a job for someone that *really* wants it, there's no shame in not being that person.

Link to post
Share on other sites

I wouldn't call this dead quite yet. Just after my last post, I finally located some of the HD20 routines in the Plus ROM. It appears to begin with the Sony_SendCmd routine at $196AC, and I think $19756 is the beginning of a routine to read from the HD20. I'm happy to share more notes with anyone who's interested and might want to help reverse engineer what it's doing.

 

While I don't understand most of it, it looks like the 532 byte sectors are 512 bytes of data and 20 bytes of tags. 12 bytes are the same tags as used on floppies, and the other 8 are two longwords called BufTgHD20 and BufTgHD20.1. No idea what those do, but there's a good chance they're not used at all, since the other tags aren't used by the Mac and are some kind of hold-over from the Lisa days. So ignoring those 20 bytes and filling them with zeroes has a good chance of working.

 

I also found this list of HD20 driver error codes (thank you Apple!), which helped me locate the location in ROM where the "checksum error" determination is made for HD20. It's at $19A0C. I have no idea what the associated code is doing, but now that it's been located, it should be possible to figure it out eventually.

 

Thanks for the info, Gorgonops. As to ending a transfer from drive to Mac, I was referring to normal transfers, not interrupted ones. I am confused by the sentence "Following reception of a sync byte (which is always $AA) actual data is received until /HSHK is de-asserted." But since /HSHK is physically sent on the ReadData line, and the actual data is also sent on that line, I don't understand what that really means. Basically I'd like to see a detailed timing diagram that shows exactly what happens for a normal transfer from the drive to the Mac.

Link to post
Share on other sites
I am confused by the sentence "Following reception of a sync byte (which is always $AA) actual data is received until /HSHK is de-asserted." But since /HSHK is physically sent on the ReadData line, and the actual data is also sent on that line, I don't understand what that really means. Basically I'd like to see a detailed timing diagram that shows exactly what happens for a normal transfer from the drive to the Mac.

 

Basically, the way I read that sentence, I interpret it as this:

 

Handshake is sent

Sync byte it sent

data is sent

Handshake is checked.

send next byte

check handshake

send next byte

 

on and on it goes. This is my guess.... But ive been wrong lots of times before

 

This is where the uncertainty sets in for me, maybe the handshake signal is of specific timing, and thats how the drive knows if its data, or if its a handshake.

Link to post
Share on other sites

I don't see it as useless… i see its as a very fast way to access

- access to large amounts of archived data on the fly

- interface your vintage mac with your modern mac

- useful with many machines!

- supplement, addition to SCSI2SD or Normal HD already Installed

- any machine with HD20 support in rom, maybe with a bad hd.

- Can Pop on and use.. no monkeying around… no hunting for power bricks… or cracking the machine open.

 

- if we can get this HD 20 emu figured out.. This means with the Floppy emu and its SD card… you can go from modern machine to vintage machine about as easy as a thumb drive

 

it not really to take over as main boot device.. its to supplement, addition to.

 

all though, 128k - 512k - plus -- would be able to easily boot from it.

likes wise any machine with HD20 support in rom, maybe with a bad hd.

 

so wether you have have SCSI2SD already… you can main boot that.. cool.

 

but the HD20 emu… pop on your floppy emu, and BOOM access to 2gb plus of data on sd card… no need to reboot or anything.

I suppose you could argue, then get 2 SCSI2SD adaptors… but having a floppy emu installed, the sd card is pretty much hot swappable.

Again you can Pop on and use.. no monkeying around… no hunting for power bricks… or cracking the machine open.

 

again machines that would be supported.

 

128

512k

512ke

plus

SE

portable

Classic I

Classic II

IIci/

IIsi/

 

Machines supported with a dougg3 rom.

II/ - maybe? / internal or floppy port to nubus blank

IIx/ / internal or floppy port to nubus blank

IIfx/ / internal or floppy port to nubus blank

IIcx/

SE30/

 

maybe more!?

Link to post
Share on other sites
Thanks for the info, Gorgonops. As to ending a transfer from drive to Mac, I was referring to normal transfers, not interrupted ones. I am confused by the sentence "Following reception of a sync byte (which is always $AA) actual data is received until /HSHK is de-asserted." But since /HSHK is physically sent on the ReadData line, and the actual data is also sent on that line, I don't understand what that really means. Basically I'd like to see a detailed timing diagram that shows exactly what happens for a normal transfer from the drive to the Mac.

 

That is indeed really confusing. My best interpretation off-the-cuff is that perhaps /HSHK signals are differentiated from "normal" data signals by the line being pulled either up or down for a duration longer than a single byte window? (IE, the IWM raises an error condition if it doesn't get at least X many 0-1 transitions within a certain window, the /HSHK transmission is accomplished by leveraging that? IE, if what the Mac is getting from the HD-20 looks like "data" it is "data", but if the line's held up or down solid for more than x many microseconds, thereby triggering an "error", it's a handshake?)

 

I don't know if anyone's sat down and compared these fragments of HD-20 documentation to the protocol documentation for SmartPort Apple II hard drives, but might that be worth doing? I know at least one person out there in Internetland makes a replica Smartport drive and I believe they communicate broadly the same way (using an IWM as a UART, etc) with the host as the HD-20, is it really likely they're that much different?(*)

 

(*Edit: Well, maybe they are. I haven't chased down the manual yet, but at first glance it at least looks to me based on the cable pin details here here that the SmartPort uses the "WRPROT" line as a separate "ACK" signal. I guess I'll put it on my list to download the Apple IIgs firmware reference/poke through the source code and see if the SmartPort handshaking is more straightforward than the phase line state-dance the HD-20 uses. There still might be something useful there. Perhaps they use the same checksum algorithm?)

Link to post
Share on other sites
but the HD20 emu… pop on your floppy emu, and BOOM access to 2gb plus of data on sd card… no need to reboot or anything.

 

Unfortunately I don't think the HD20 can be hot swapped or plugged in after booting, but you've got one so you can try it. I thought it acted pretty much like a SCSI hard drive, and needs to be present when the Mac first boots, or else it doesn't work? So really "HD20 Emu" would provide the exact same functionality as SCSI2SD, no more and no less, except it could also work on the SCSI-less fat Macs, but couldn't work on newer Macs that lack the HD20 Init.

 

My best interpretation off-the-cuff is that perhaps /HSHK signals are differentiated from "normal" data signals by the line being pulled either up or down for a duration longer than a single byte window? (IE, the IWM raises an error condition if it doesn't get at least X many 0-1 transitions within a certain window, the /HSHK transmission is accomplished by leveraging that? IE, if what the Mac is getting from the HD-20 looks like "data" it is "data", but if the line's held up or down solid for more than x many microseconds, thereby triggering an "error", it's a handshake?)

 

Yeah, after mulling it over, I reached the same conclusion. Seems kind of strange, but I guess it could work.

 

I thought of another issue last night. The main advantage of a HD20 Emu over SCSI2SD is that it would work on the Mac 512k and 512ke, right? But the Mac 512k lacks the HD20 Init in ROM, and the only way to load it is from a floppy, and that's probably going to require a real floppy in the internal drive, or two Floppy Emus. I don't think the hardware can act as an HD20 and a floppy at the same time, and if it can, it could only act as a chain with the emulated floppy at the end, and the ROM routines in the Mac 512k don't know how to talk to drives other than the first one in the chain.

 

All this talk about why it's not going to work has got me thinking more about it, so when I've got some free time maybe I'll try putting together a simple test using my best guess about how this stuff is supposed to function. If I run into major problems I probably won't pursue it further, but maybe I'll get lucky.

Link to post
Share on other sites
I thought of another issue last night. The main advantage of a HD20 Emu over SCSI2SD is that it would work on the Mac 512k and 512ke, right? But the Mac 512k lacks the HD20 Init in ROM, and the only way to load it is from a floppy, and that's probably going to require a real floppy in the internal drive, or two Floppy Emus. I don't think the hardware can act as an HD20 and a floppy at the same time, and if it can, it could only act as a chain with the emulated floppy at the end, and the ROM routines in the Mac 512k don't know how to talk to drives other than the first one in the chain.

 

I don't have an HD-20 to test, but can a 64k ROM 512k boot from an external floppy drive hanging off the daisy-chain port of the HD-20? A 512k *can* boot from an external floppy otherwise. Perhaps the HD-20 on power-on comes up with the crossover circuit initialized so the floppy is the thing the Mac "sees" and only becomes UN-transparent after the HD-20 init fires off the the drive discovery routine in its modified version of the .sony driver. *If* that were the case then if you could make the FloppyEmu able to "multitask" being both an HD-20 and a floppy (You'd have to teach the hardware to recognize the phase line dance that switches the crossover circuitry but other than that it seems it should be doable... said by someone who didn't build it, of course. The two emulations don't really have to run at the same time, as long as you have enough memory to store state when the Mac switches drives it should be doable? The Smartport emulator I linked earlier actually emulates four separate Smartport HDs, each hardcoded to point to a 32MB partition on the CF drive, by watching the drive select signals.) you could boot a 512k diskless simply by having an HD-20 boot system image pointed to by the floppy emulation side of the house.

Link to post
Share on other sites
I don't have an HD-20 to test, but can a 64k ROM 512k boot from an external floppy drive hanging off the daisy-chain port of the HD-20?

 

Right, that would be ideal, but I think the answer is no. The mechanism for selecting multiple drives is described on page 3 of this doc. But with some kind of clever trickery, maybe there's a way.

Link to post
Share on other sites

I think mostly, I like how you can just plug right into the port and have everything you need Bus + Power.

 

i never tried to eject a HD20 to see what happens, when booted up from something else.

 

I was thinking, I could leave the floppy emu plugged in… eject the HD/20/emu… pop the sd card out. pop it into a modern machine… put files on there etc.. then pop it back in the floppy emu , hit a button and see it re-mount. and go.

Link to post
Share on other sites
Right, that would be ideal, but I think the answer is no. The mechanism for selecting multiple drives is described on page 3 of this doc. But with some kind of clever trickery, maybe there's a way.

 

I'd love for someone to do the empirical test to see whether booting from the end-of-the-chain external Sony drive works or not, but it may well not. (I honestly just don't know.) Perhaps it said so in boldface letters in the original manual, but the first attempt at Googling for a copy of the HD-20's user manual came up empty. The only hit I found was this page, where the person does say:

 

"Although you can daisy chain another external 400K drive off the HD20, you still need to boot from the internal drive. Which stinks if your internal drive is out of order."

 

They then attempt to anyway, because the internal drive in their 512k is shot, but coincidentally their 512k decides right at that moment to blow up completely so there's no resolution of the question.

 

Even if it doesn't work then being able to do HD-20 *and* 400k floppy emulation would still be useful assuming you can make your internal drive work, IE, if you have a 512k with no boot floppies you simply boot from a floppy image with the device in floppy mode, format a real disk and drag a system over, and from that point use it to boot with the HD-20 emulation. And of course the other option is to toss Plus ROMs into the machine and solve the problem that way. (Yes, then it's not completely original, but if you intend to actually use the machine it's a solution that's easily reversed.)

 

Ah well. I've discussed this in some earlier threads, but something I've mused about tackling if I thought I had even the *slightest* chance of writing the device driver (either as a custom INIT or patching it into a custom ROM) would be interfacing a CF card to a Mac via the ROM sockets. Floating around out in Internetland there's an article/schematic describing an early Pre-Plus SCSI adapter that was interfaced via that route, and there were also Mac Plus ROM-compatible SCSI cards interfaced the same way. (The Mac Plus' SCSI implementation is *very* similar to the ROM socket hack. Eerily so, actually.) A CF card in minimal 8-bit mode has very similar interface requirements to the NCR 5380 and the command sets for dealing with the block device are broadly similar. (Assuming you use LBA and not CHS mode on the CF card.) The interface would only need three or four chips on a daughterboard and someone with actual programming talent could probably make that go pretty easily...

 

(On my "to do" list next time I'm fiddling with repairing my not-perfect Commodore PETs is hanging a CF card off its expansion bus and seeing if I can make that work in some useful fashion. The thing is, of course, a brain-dead driver for a PET is a lot simpler than a Mac OS driver... or at least it seems that way to me. I looked at the driver code for that ROM-socket SCSI card and just sort of glazed over.)

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...