Mac68k Forums


Welcome, Guest
Guest Settings

Mac68k Forums » Development » Hardware Hacking

Thread: ROM hacking for super-sized floppy support

Reply to this Thread Reply to this Thread Search Forum Search Forum Back to Thread List Back to Thread List

Permlink Replies: 1 - Pages: 1 - Last Post: Nov 23, 2014 8:04 PM Last Post By: bbraun

Posts: 217
Registered: 10/29/13
ROM hacking for super-sized floppy support
Posted: Nov 23, 2014 1:18 PM
Click to report abuse...   Click to reply to this thread Reply
While I was working on HD20 emulation, I had another idea that might be even more useful: add support for super-sized floppy disk images over 800K (or over 1.4MB for HD disks). This would be easy to support in the Floppy Emu firmware, but it would require changes to the .Sony driver in the Macintosh ROM. There are a few spots in ROM that would need to be patched:

1. There's an explicit check to see if the sector number for a read or write is within the range for a 400K, 800K, or 1.4MB disk. I have the location on my other computerů it might be in the call to Prime.

2. There are a couple of tables that map the track number to the expected rotational speed, and the number of sectors per track. For track numbers beyond 80, this code would fail. So all that logic would need to be rewritten.

3. Offhand I don't recall if the current track number is stored in a byte, or in a word. If a byte, than you could only have up to 256 tracks, which would be about 3x the capacity of a regular floppy. Getting more than that would require a bigger change.

I might try my hand at manually patching the 128K Plus ROM image, putting new ROMs in one of my machines, and seeing if I could get it this to work. But to be really interesting, I think the ROM patching would need to be done in software with an Init, instead of an actual modified ROM. And that's where I'm not sure how to proceed.

Is it possible to replace the entire .Sony driver with an Init loaded at startup time? Since the ROM .Sony driver would already be open during the boot process, I can see that causing trouble.

Alternatively, I think many of the .Sony routines are accessed through a RAM-based jump table. So I could theoretically make an Init that allocates some permanent memory, fills it with modified versions of a couple of key routines, and updates the jump table to use those machines.

I'm not sure how difficult it would be to support this across the board for vintage Macs, instead of only with the 128K Plus ROM. Each of the early Macs has a .Sony driver in ROM that does basically the same thing, but they're probably at different addresses in ROM, and may have slight differences between them. So a simple Init patch that stuffs a few keys bytes at some hardcoded address probably wouldn't work - the Init would need to understand all the different ROM versions that exist, and know how to patch each one.

Lastly, I think an Init is a System 6 (and earlier) concept. System 7+ has Extensions, and I'm not sure if that's something new or just a different name for the same thing. But in the worst case, it might be necessary to create a unique Init/Extension for every permutation of ROM version and System version, which would be a pain. But hopefully there are smart ways to avoid that.

Posts: 493
Registered: 7/25/12
Re: ROM hacking for super-sized floppy support
Posted: Nov 23, 2014 8:04 PM   in response to: bigmessowires in response to: bigmessowires
Click to report abuse...   Click to reply to this thread Reply
The .Sony driver is a bit weird, as you've noticed with the RAM based jumptable. Normally, there's a table of drivers, each with their name and a reference number, and each driver has an open/close/prime(read/write)/control/status call. It is possible to replace a driver by just removing it from the driver table, and putting yourself in its spot with the same name. The floppy driver is a bit weird for a couple reasons:
1) it keeps a bunch of state in a structure pointed to by a low memory global
2) Whenever you call a floppy driver routine (the open/close/prime/control/status calls), it jumps through a table in the low memory global.

As best I can tell, that table exists specifically so the OS can patch the driver with a newer version when it boots, and the driver state exists in that structure pointed to by a low memory global, so the patched routines can still preserve the same state, after patching.

With INITs, they were introduced in System 4.2 I think. They're just a resource type that, if located in a place the System looks for such things, will be run at boot time prior to the Finder launching. Prior to System 7, basically all system related things just lived in the System Folder. In System 7, they broke Control Panels (cdevs) and Extensions (INITs) into different folders. Although the System still loads INIT resources that live in Control Panels at boot time, because it frequently makes sense to have some UI to control your extension, and you just put the cdev and INIT resources into your Control Panel rather than breaking it into 2 different files.
My serial disk driver is both a control panel and an extension in one, and it works fine from System 4.2 through 7.6.1 (I haven't tried anything newer). For earlier systems, I just made a little application that, if hasn't been previously loaded, copies the DRVR resource into the system heap, locks it (the mac memory manager thinks it can move memory around in order to reduce fragmentation, so you can 'lock' allocations to tell the allocator not to do that), loads it into the driver table, and opens the driver. Then the application can make calls to the driver's Control routine to manipulate it.
INITs are just run at boot time, and then are unloaded, so anything they want to do persistently, have to do something like what I described for the application. Copy their persistent code into the system heap, install drivers, etc. It's really just a hook to be able to run whatever code you want before the Finder loads.

Point your RSS reader here for a feed of the latest messages in all forums