Floppy emu - Emulating HD20 :-)

[Gorgonops]

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?)

 

[bigmessowires]

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.

 

[Gorgonops]

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.

 

[bigmessowires]

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.

 

[uniserver]

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.

 

[Gorgonops]

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.)

 

[bear]

I don't recommend "hot plugging" anything on the floppy port, ever, because in my experience this is an outstanding way to blow out the IWM.

 

[uniserver]

i was thinking of just leaving the floppy emu plugged and just hot swapping the sd card.

 

[Mac128]

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.

I feel like I tried this once upon a time, but I do not recall the outcome.

The HD20 Manual is quite clear on this -- the HD20 Startup disk must be in the internal drive. It goes on to outline procedures for using an external drive without powering up the HD20 -- you must startup from the HD20 disk in the internal drive before an external drive connected to an unpowered HD20 will be recognized.

 

[bigmessowires]

OK, I've started looking at this in earnest, with some help from dougg3. Some good news and bad news.

First the bad news: it looks like it won't be possible to emulate an HD20 and a floppy at the same time (assuming HD20 is even possible at all). The CPLD chip that Floppy Emu uses to interface with the Mac has a very limited amount of resources, and it's already almost full with the stuff needed for floppy emulation. Already I had to lobotimize it by removing support for 800K and 1.4MB floppies, just to do any HD20 testing at all. So if you need HD20 emulation and floppy emulation, you'll either need two hardware units, or you'll need to reflash the firmware every time you want to change from one to the other.

Annoying news: it's hard to get the Mac into a state where the HD20 emulation can even be tested. If you boot up with something that looks like an HD20 attached, but that doesn't respond to driver calls correctly, the Mac goes nuts and repeatedly asks you to initialize the disk. If you click Cancel, the dialog just reappears. So it's impossible to even run any diagnostic programs. But if you connect a HD20 Emu after boot up, the Mac just ignores it. It seems to cache information about what drives are present during boot up, and changing it after that has no effect. This means that uniserver's HD20 hot swapping dream probably can't work. So far, the only way I found to run my diagnostic program was to configure the Mac to run my program after boot up, instead of running the Finder.

Good news: I've implemented the disk daisy-chaining mechanism described in the HD20 doc, and it seems to work. With an emulated 400K drive second in the virtual drive chain, the Mac still sees the floppy and will boot from it. Then it sees *something* at the first position in the chain, and freaks out with the endless requests to initialize it.

Pretty good news: I wrote a test program to read random sectors from the HD20. Initially it was failing with error -64, drive not present. After the daisy-chaining changes to the Floppy Emu CPLD, now it fails with error -17, driver can't respond. Looking at the disassembly of the HD20 ROM routines, this is the error I'd expect to see if the drive doesn't respond with the correct handshake after the Mac tells it to reset. So as far as I can tell, the Mac at least thinks there's an HD20 present and is trying to talk to it, so that's good.

 

[uniserver]

I don't think that is any problem what so ever.

just sell a secondary product, maybe with out a screen... and buttons... and maybe a different color Solder Mask.

maybe even keep the same price point or lower it a little... Awesome progress man.

I just know you have what it takes to make this happen.

thanks man...!

 

[Blinkenlightz]

After the daisy-chaining changes to the Floppy Emu CPLD

On a related tangent... Could this logic be used to get the Floppy Emu to behave as two mounted floppies simultaneously? Or am I dreaming in Technicolor?

 

[CC_333]

If I interpret this correctly, it would require a radical hardware redesign (such as a microprocessor upgrade) to become capable of doing more than what it's doing now without sacrificing existing functionality.

Nonetheless, great job!

Perhaps you can make a program that can switch it between HD20 and floppy modes by automatically writing the respective firmware to the device?

c

 

[bigmessowires]

Barring some clever optimization, it doesn't look possible to support both modes at the same time. It should still be possible to switch between the two modes by flashing different firmware. Not very user-friendly, but possible.

Unfortunately I've run into a wall getting any further than error -17 with the HD20 stuff. Nothing I do changes the behavior, and I can't find any good ways to troubleshoot what's going wrong, so I'm basically stuck until/unless a new idea comes to light.

 

[uniserver]

I'm going to try an get you some help

 

[techknight]

Im sure bbraun or dougg3 could make a control panel to remount an HD20 after boot time. However that still doesnt resolve your issue.

I wonder if not everything is explained or published in that document.

 

[uniserver]

here is some more technical info on the macintosh HD20

http://www.retrotechnology.com/herbs_stuff/m_hd20.html

 

[mac512]

A little off-topic, but a control panel to change disk images on the fly would be really awesome. No need for lcd screen or phisical buttons and the floppy emulator can be installed internally...

This is the kind of functionality that makes de HxC Floppy Emulator so great on Amigas and Atari STs.

If HD20 emulation becomes real, let me tell you that i would be in vintage computer heaven and my macs 128k-512k too :lol:

Keep up with this fantastic work.

 

[Gorgonops]

I wonder if not everything is explained or published in that document.

The stuff on bitsavers has massive holes in it. (A particularly irksome thing that comes from comparing the March and May-dated versions of the protocol documentation is the earlier one specifically suggests that the protocol contains "acks" transmitted through the IWM from the drive to the computer, while a conservative reading of the May document suggests that handshaking is limited to that business of "toggling /HSHK", which is semi-infuriating because it's not entirely clear how /HSHK works.) There may be no way to definitively fill in some of the grey areas without constructing a probe and doing signal capture and analysis on a live and working HD-20. Unfortunately.

 

[uniserver]

just say the word steve and ill send you this HD20… that is the whole reason i traded techknight for it in the first place..

.because if you figure it out… that will be HD20 for all well with a fee to bmow's paypal.