• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

design ideas for a SD-card floppy emulator

Status
Not open for further replies.

Gorgonops

Moderator
Staff member
It seems like it'd be an awful lot of work to re-implement something that has been done well, several times, already...
There are a few "quirks" of the Mac floppy drive that would make it somewhat nontrivial to adapt the exact device you linked to (although probably doable almost solely with software changes) yes, this has been done before. (The reason the HxC emulator *has* been adapted to so many hardware platforms is that it implements the standard Shugart floppy drive interface and control protocols. Which the Mac does not use, but yes, with software changes and *possibly* a small hardware change the device could probably handle it.) The closest match with an existing device is probably the "SVD":

http://www.thesvd.com/SVD/

which already supports the Apple II with an adapter. With more memory and some software changes to understand the "statefulness" of Macintosh disk drives this device would probably already work. The reason this doesn't already exist in the Mac community has been far more a lack of "interested expertise" than any inherent difficulty in interfacing with the IWM. Yes, it's proprietary, but it's also simple and for an Apple-proprietary device extensively documented.

The "oddness" of the Mac drive probably does justify making a new device (which could also work on Apple II computers), but it does all come down to someone actually *doing* it. (Which I'm sure "Bigmessowires" is capable of, should he choose to do so.)

(EDIT: Beaten to the punch by the interested party. Oh well.)

 

Mk.558

Well-known member
My main motivation is to provide some way to bootstrap Macs with an 800K floppy drive when the owner has no 800K floppies. / Then hopefully someone with more Mac software-development experience could write a custom "large disk" INIT
If said individual has a 512K, I'm guessing they have some sort of auxiliary Mac to support it. I would not own a slew of PCs and a single 512K -- PCs can't read 800KB floppies and networking will be a real drag.

Said Mac could be like a IIsi, which has a built in floppy drive and thusly can read & write 800KB and 1440KB floppies. And run PC Exchange, so there. And run a Ethernet cable, although file transfer will most likely be through FTP.

I wouldn't cater to a market that can't sustain itself. A 512K these days is a lone, lone fella. No SCSI, so no hard drive. Nobody else except old Macs can read 800KB floppies. HD20? Yeah, but you're not going to be file transferring with that. There's one on eBay but it's 490$, so there -- you may have the money for that, but why not just get like a IIcx or Quadra? Cheaper and gets the job done.

Best? A model that has a built-in floppy drive and can run OS X, so you can network with Windows with SMB. Like a Power Macintosh G3 333MHz -- toss 10.2.8 and Mac OS 9 on it (The Internal drive might take 800KB floppies, I have no idea.) Besides you can just put tape over the left rear hole on a 1.44MB floppy and reformat it, and bam. There's your 800KB disk. Next?

There. :)

 

MapGuy42

Well-known member
Besides you can just put tape over the left rear hole on a 1.44MB floppy and reformat it, and bam. There's your 800KB disk. Next?
Welllll, except for the part about the 800k drive in your compact not liking to write reliably to such a disk, as I understand it. But that's the thinking I've come around to. If and when I get my hands on a compact, just having the 8100 right next door for sharing over the wire or swapping floppies will have to do.

 

Bunsen

Admin-Witchfinder-General
Getting pretty tired of armchair quarterbacks raining on this parade tbh. Just google bigmessofwires - heck, search on these forums - to get an idea who you're messing with. BMOW has solid reasons for this project, and a more than adequate track record to pull it off.

Now, if anyone has any helpful suggestions ...

 

bigmessowires

Well-known member
Hehe, that's fine if people have other ideas about how the floppy emulator ought to work, I don't have any monopoly on good ideas. :) My motivation is to build something cool that interests me, and would be personally useful, and also dovetails with my other Mac project. From a practical/business standpoint it may well make more sense to repurpose an emulator from another platform, or do a SCSI emulator instead. But in the final account, those projects don't really interest me and this one does.

Life is full of coincidences, because I had actually just started some real work on this project yesterday, before I even saw that the thread here had been revived. Here's a short progress report.

floppyemu-steup.jpg

Using one of the DB-19 connectors that I purchased a few weeks back, I rigged up a cable to connect the Mac's external floppy port to a breadboard. Then I dug out an old CPLD board I built for another long-forgotten project, and wired all the floppy lines to the board's I/O connector. The board is powered by the +5V from the floppy port.

This particular board has an Altera EPM7128S CPLD, which is so old that it actually runs at 5V (newer CPLDs run at 3.3V or below). That's great for this purpose, because 5V is what the Mac provides and is also the voltage level on the Mac floppy data lines.

So far, I've built a successful blank disk emulator. It identifies itself as an 800K drive to the Mac, initially with no disk. Reading and writing of the interval drive registers works, as well as stepping the drive head. The PWM signal that tells the Mac the current drive motor RPM speed also works. By pushing a button on the board, you can "insert" a disk into the drive, but the disk is blank (it contains all 1's).

If you push the button while the Mac is waiting for a boot disk, it thinks about it for a minute, then "ejects" the disk and shows the X-disk icon on the screen. If you boot from a regular floppy disk in the internal drive, then push the button to insert an external disk, the Mac asks "This disk is unreadable. Do you want to initialize it?" If you say yes, the Mac responds "Initialization failed! The disk is write-protected!"

As you can see it's not very exciting yet, but it's a good start.

 

bigmessowires

Well-known member
I think I need some MacsBug help. I've implemented more of the floppy emulator hardware, but to debug it as it's running, I need MacsBug on my Mac Plus.

I installed MacsBug 6.5.3, and when I boot (using System 6.0. 8) it says "MacsBug Installed". The first two or three times I tried it, pressing the debugger switch popped me into MacsBug, and I viewed the command help and set a breakpoint. But ever since then, pressing the debugger switch just locks up the Mac. I've rebooted half a dozen times, done a full power off/on cold boot, and reinstalled MacsBug again, but I've never been able to get it to work again after those first few times.

Anyone know where I can get an older version of MacsBug, preferably one that's from about the same time at the Mac Plus (1986)? The MacsBug 6.5.3 I have is from the PowerPC era, and maybe it's support for System 6 and the Mac Plus isn't so great. I checked all the usual download sites, but couldn't find anything except versions 6.5 and 6.6.

 

bigmessowires

Well-known member
Ugh. Things have taken a major turn for the worse, and it's not looking good for this project.

For MacsBug, I discovered that whenever it's first invoked, or maybe whenever I first set a breakpoint, it actually modifies the System file. I don't know what it's doing, but I can see the timestamp on the file changed. Thereafter, whenever I push the debugger switch, the Mac just freezes up. If I replace the System file with another (good) one, then I can enter MacsBug again with the debugger switch.

Even if I could find a solution for that, the bigger problem is that breakpoints in ROM routines basically don't work. MacsBug will let you set them, but it warns you it will be slow. I would estimate the Mac runs at least 1000 times slower (not an exaggeration) with a ROM breakpoint enabled. It took more than 10 minutes to draw a dialog box. This is because the 68000 CPU doesn't have hardware breakpoints-- breakpoints in RAM can be achieved by patching the code in memory, but breakpoints in ROM require the debugger to single step through the code, checking the address after every instruction, and that's S-L-O-W.

It also seems that even if you can wait 10 minutes, breakpoints in ROM routines don't even get hit. I set a breakpoint on one of the ROM floppy routines I'm pretty certain must be called when I insert my emulated disk, but it went all the way to the "do you want to initialize?" dialog box without ever hitting my breakpoint.

This leaves me without any way to debug what's going wrong with my floppy emulator, and why the Mac doesn't load sector data from it. So... I'm not sure how I can go forward from here. :(

 

bigmessowires

Well-known member
Thanks, 6.2.2 does seem to work much more reliably on the Mac Plus. It's still crazy slow when debugging ROM code, but I was able to hit some ROM floppy driver breakpoints. I'm having a hell of a time making any sense of it-- it seems like maybe the super-slow execution in the debugger is throwing all the time-sensitive floppy routines out of whack, or maybe the system patches over some of the ROM routines so they're never actually called. It's definitely better than nothing though!

 

bigmessowires

Well-known member
YAHOOOO!!!!! I was literally jumping up and down and shouting a minute ago, because I got something working!!!!

When the Mac Plus is waiting for a boot disk, I can now push a button to insert the virtual floppy disk image, and produce a Happy Mac on the screen! Because only the first two sectors of the floppy image are loaded, it can't actually boot, but it proves that the right data is traveling from my Rube Goldberg CPLD+MCU setup to the Mac, and the Mac likes it. YES!!!

Luckily my first attempt wasn't far off, because this thing is near impossible to debug. The first problem I found was that the disk RPM speed feedback I thought was working correctly actually wasn't. I was able to use MacsBug to see that the floppy driver was returning error -79 "can't correctly adjust disk speed", but I had to blindly experiment with different speed values until I hit on one that worked. Then the floppy driver was returning error -67 "can't find an address mark", which basically means it can't make any sense of the data to determine where a sector begins. With zero other info to help troubleshoot that, I methodically went through all my design assumptions one-by-one again looking for mistakes, and found a place in the IWM specification where I might have misinterpreted what Woz meant by a transition on the read sense line. I changed it so that a logical 1 produces a falling transition, instead of just any transition, and holy #$%*& it worked.

There's still a bunch more work to do with getting an entire disk image off an SD card, and reading data a track at a time, and disk side 0/1 stuff, but I'm optimistic about those pieces now that the initial task of getting bytes into the Mac is working.

Time for a beer.

 

napabar

Well-known member
Amazing, Bigmessowires, Amazing!!!

Just a thought....has anyone thought about emailing Tim Cook and see if Apple would be interested in turning over some of the early Mac hardware schematics to the hobbyist community? One thing that made Steve Jobs great was his relentless pursuit of the next best thing, but that came with a price of not being nostalgic about his older creations. Perhaps Tm would find our kind of interest amusing, and having no business or financial reason to hang onto these ROMS and schematics and such, make them freeware.

 

LCGuy

LC Doctor/Hot Rodder
That is incredible :O

re: emailing Tim Cook...somehow I don't like your chances, but it certainly is a good idea...don't ask don't get. :)

 
Status
Not open for further replies.
Top