Floppy emu - Emulating HD20 :-)

After the daisy-chaining changes to the Floppy Emu CPLD

Click to expand...

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?

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

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.

I'm going to try an get you some help

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.

here is some more technical info on the macintosh HD20

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

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.

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

Click to expand...

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.

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.

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.

Click to expand...

Yeah, it's pretty incomplete, and I think things have changed since the May version too.

For example: the May version claims that if the computer needs to hold the drive off from transmitting (so it can handle a pending serial interrupt) during an 8 byte group of data, it changes to state 0 and ignores the rest of the group in progress. Then when it signals to the drive that it's ready again, the drive will continue by repeating the group that was interrupted.

I've been disassembling the HD-20 driver in the Mac Plus ROM and it looks to me like now the behavior is that the drive finishes transmitting the interrupted group, and then when the computer says it's ready, the drive continues where it left off with the next group. My complete guess is the behavior probably changed because this note was considered unacceptable behavior:

If interrupts are occuring with high frequency, then it is possible for the Macintosh to do a hold-off in the middle of the same (restarted) group over and over again, potentially forever.

Click to expand...

I also think that more aspects of the hold-off behavior have changed too. We may be able to figure out the behavior based on the ROM disassembly and what it tells the IWM to do, but it'll take some time to digest.

I decided to look at the problem from the other end, and made a little progress there. While the Mac still returns error -17 for everything, I'm now able to receive HD20 commands on the Floppy Emu and display them on its screen. It looks like the Mac keeps sending an HD20 status command, and because it gets no reply, it shows error -17.

The format of the status command mostly matches what's described in the HD20 doc, but with the inclusion of two extra "mystery bytes". With help from dougg3, we studied the ROM routines to determine that those bytes are probably the size of the output data and the size of the expected reply. Those were likely added as some kind of future-proofing feature, so drives could gracefully handle commands they don't know about, if the Mac and the drive are using different version of the API.

If I can figure out how to construct and send a proper status reply, I'm hoping it will be enough to get past error -17.