BMOW title
Floppy Emu banner

Archive for the 'Floppy Emu' Category

Missing Pull-up, Sad Trombone


Wah wah wah waaaaaaah. In the battle for 5.25 inch Apple II disk write emulation, it seems I declared victory too soon. While write support works great in many situations, it doesn’t work at all in others. The problem is with the /WRREQ signal from the Apple II, which goes low to indicate when a write is occurring. On old-school disk controller cards, like the Disk 5.25 Controller Card, or the even older Disk II Controller Card, this signal is generated by a 74LS05 hex inverter chip with open collector outputs. It can actively pull the signal low, but it needs an external pull-up resistor to pull the signal high. And Floppy Emu doesn’t have one. On the Apple IIgs (and probably also the IIc), the circuitry can actively drive /WRREQ high, so this isn’t a problem. And on other Apple II models, it’s also not a problem if there’s another real drive connected in the daisy chain, because that drive will have a pull-up, and /WRREQ is shared among all drives. But if Floppy Emu is the only disk drive connected to a Disk 5.25 or Disk II Controller Card, writes won’t work. Ouch.

The logic analyzer trace above shows what happens. /WRREQ is connected directly to an input pin on the Xilinx XC9572XL CPLD. The input has a very weak pull-up that’s active at initialization time, as well as a keeper circuit that actively maintains the input at the last externally-driven level. At power-up, the weak pull-up pulls /WRREQ high, and the keeper circuit keeps it there. Then when a write occurs, the disk controller card actively drives /WRREQ low. At the end of the write operation it releases /WRREQ, but with nothing to pull it high again, the keeper circuit maintains the low value forever. To the Floppy Emu, it looks like a write operation that never ends. You can see the result in the trace. /WRREQ stays low forever, even after the drive enable signal is de-asserted.

Unfortunately, I don’t think there’s any way to fix this other than to add a pull-up resistor. The XC9572XL CPLD chip doesn’t have configurable built-in pull-ups that I can turn on in firmware, as far as I can tell. 5.25 inch read emulation will still work fine, as well as 5.25 write emulation on a IIgs or on any Apple II with another drive present. But for a single-drive Floppy Emu setup on an Apple IIe, write emulation won’t work without a hardware fix.

I already designed an adapter board, which I described in this earlier post. I had hoped that the adapter board would only be needed for certain situations of 3.5 inch Apple II disk emulation, but now it seems certain situations of 5.25 inch emulation will need it too. There’s too much “certain situations” about the whole thing for my comfort, and I’m sure it confuses everyone else just as much. So I’ll probably just rechristen the adapter board as a general purpose “Apple II adapter”, even though it’s not strictly needed for all circumstances of Apple II emulation. That will be easy to understand, and won’t steer anybody wrong. Power users can read the footnotes and discover which Apple II setups can work without the adapter board, if they wish.

Adding a pull-up resistor to the adapter board will be easy, but it does mean I’ll need to have new PCBs made. The only good thing in all of this is that it justifies my decision to postpone manufacturing large numbers of the adapter boards until after the Apple II 5.25 inch and Smartport disk emulation is working. If I had built lots of adapter boards three weeks ago when I thought they were only needed for 3.5 inch Apple II disks, I would now have a lot of angry people who’d bought them, and a pile of additional boards I couldn’t use.

Read 5 comments and join the conversation 

5.25 Inch Disk Write Support


Whew! Floppy Emu write emulation for 5.25 inch Apple II disks is finally working. That was a painful issue to resolve, because writes to the 5.25 inch emulated disk were working fine in my controlled tests, but things went haywire when I tried a simple DOS write operation. Argh! I went a little crazy jotting down notes about possible causes, theories, and doodles – my standard way of organizing my thoughts for problems like these. Not that it seemed to help.

I finally hit upon the idea of starting from a reference DOS disk image, and performing the same file save operation in two different settings: once on a regular Apple II system with Floppy Emu, and once in the AppleWin machine emulator. Then I could use a binary diff tool to compare the resulting modified disk images from each case, and see how they differed.

What I found was that a single byte differed between the two disk images, after performing what should have been an identical file save operation. Oddly, the byte was in a sector that wasn’t even supposed to be modified by the save operation. The diagnostic info I collected from Floppy Emu said that the Apple II never modified that sector, but there it was anyway. In a sector that should have been all zeroes, the second byte was a 1. And the effected sector was immediately after another sector that was modified by the Apple II. Hmm.

You can probably guess what the issue was: buffer overflow. Whenever a sector was written, the first two bytes of the next sector in memory would also get overwritten. This problem was invisible unless the effected sector happened to lie inside a range of two non-contiguous dirty sectors on the same track, in which case the whole range of sectors would get written back to the SD card as a performance optimization. This never happened during my simple single-sector write tests, which is why I could never find a problem there. The issue only occurred during a more complex write operation involving non-contiguous writes on multiple tracks of the disk.

In truth, the buffer overflow was only the last of three separate problems that prevented 5.25 inch writes from working correctly, but it was the largest bug and the others aren’t interesting enough to describe. So now it works – yay! I tested booting from an emulated DOS disk and saving some BASIC programs to it. I also tried booting GS/OS on the IIgs, and using it to delete the contests of an emulated ProDOS 5.25 inch disk, copy a new program file onto it, and run the program.

Try It

Like the Mac and Lisa firmware, this new Apple II firmware supports writing to the data portion of each sector, as occurs during standard file I/O operations. Writing new address headers for the sector is not supported, which means it’s not possible to format the emulated disk or do bit-copy writes with tools like Copy II+. If you find yourself wanting to format the disk to get a new blank image to work with, I’ve included a few different blank disk images with the latest firmware.

Download the new Apple-II-0.1D-F3 firmware, and try it for yourself! As with the earlier Apple II firmware versions, use this firmware only when connected to an Apple II computer. If a Floppy Emu board running the Apple II firmware is connected to a Mac or Lisa, it may cause damage.

Please let me know what Apple systems and disk images you’ve tried, especially if you run into problems. Have fun!

Read 11 comments and join the conversation 

5.25 Inch Disk Firmware


The updated Apple II firmware for Floppy Emu is now available! This update adds 5.25 inch 140K disk image support, and is compatible with any Apple II model, using the standard Floppy Emu hardware. Download apple-II-0.1C-F3 and try it out! I also included a few sample disk images, so you can be running Oregon Trail and a few other classics right away. The firmware supports standard Apple II 140K disk images in .PO, .DO, .DSK, .NIB, or .2MG formats, as well as Apple II 800K (3.5 inch) disk images in .2MG or Disk Copy 4.2 formats. Press the SELECT button from the Emu title screen to switch between 5.25 inch and 3.5 inch disk emulation modes.

Some important notes:

  • I’m having difficulty with 5.25 inch disk write emulation, so this firmware treats 5.25 disk images as read-only. I hope to add full read/write support for 5.25 inch disks in another firmware release soon.
  • The Floppy Emu board can be connected directly to the 19-pin floppy connector on the Apple IIgs or Apple IIc. For the Apple II, II+, and IIe, the Emu board should be connected to your disk controller card: either the Disk 5.25 Controller Card with 19-pin connector, or the classic Disk II Controller Card with two 20-pin connectors. If using the Disk II Controller Card, be careful to orient the cable correctly, since the card’s connector is not keyed and it’s easy to accidentally connect the cable offset or backwards. The red stripe on the cable should go to the pin marked “1” on the Disk II Controller Card.
  • This firmware includes support for 5.25 inch and 3.5 inch Apple II disk emulation. 5.25 inch disk emulation works on a stock Emu board, and does not require any adapter. Full emulation of 3.5 inch disks requires an adapter board that I plan to release soon. Without the adapter board, 3.5 inch disk emulation works on a ROM 01 Apple IIgs when booting from the Floppy Emu, but not on a ROM 03 IIgs or when the Emu is not the boot disk.
  • As with the earlier Apple II firmware versions, use this firmware only when connected to an Apple II computer. If a Floppy Emu board running the Apple II firmware is connected to a Mac or Lisa, it could cause damage.

NIB Images

This firmware introduces support for NIB images, which contain the raw disk bytes stored on a physical floppy disk, instead of the high-level sector data contained in other types of disk images. With NIB images it’s possible to store and emulate many types of copy-protected disks, including disks with non-standard sector headers, custom sector sizes and encoding, and all sorts of other crazy schemes. This is important for the Apple II world, because the use of disk-based copy protection was common among Apple II software. A disk emulator that didn’t support NIB would be limited to only using “cracked” versions of the software in which the copy protection had been removed.

Implementing robust NIB support is challenging. I’m not sure if other Apple II disk emulators also support NIB format, but at least one that I checked does not, so I’m happy that I was able to make it work for Floppy Emu. After digging into the details, I can understand why some designers may have chosen to skip NIB. The NIB format represents a track as 6656 disk bytes, but this is insufficient to represent the full structure of a real floppy disk track. On a real floppy, most disk bytes contain 8 bits, but some disk bytes called sync bytes are actually 10 bits long. Of course a 10-bit quantity isn’t a true byte, but the term “sync byte” is used regardless. The sync bytes are FF (hex) followed by two zero bits, so in binary they look like 1111111100. The problem is that sync bytes are stored in the NIB file as plain 8-bit FF bytes, and the knowledge that a particular FF is a sync byte instead of a standard FF data byte is lost.

I believe the NIB format was developed mainly for use with PC-based Apple II emulators, and not for use with real Apple II hardware. While I’ve never investigated how emulators like AppleWin are designed, I would guess it’s impossible for the emulated disk controller to get out of sync with the emulated disk, so the absence of proper sync bytes in the NIB data is unimportant. But when running on real Apple II hardware, such as with the latest Floppy Emu firmware, the absence of sync bytes is fatal. To solve this problem, I’ve designed the firmware to make an educated guess as to which FF bytes in the NIB are actually sync bytes, and which are just plain data bytes. In practice, this seems to work great most of the time, but copy protection schemes are often designed to intentionally thwart exactly this kind of analysis. In my tests, all the copy-protected NIB images that I tried worked, save for one intermittent problem with Moon Patrol on the Apple IIgs. Yet the Moon Patrol NIB worked fine on my Apple IIe, so maybe it’s some kind of IIgs incompatibility rather than a NIB issue.

Write Support

Support for writing to emulated 5.25 inch disks has proven to be much more troublesome than I’d expected. Single-sector writes appear to be working fine: I can use a sector editor tool to view and modify individual sectors on the emulated disk, and the data gets modified correctly. That means there aren’t any low-level problems involving timing or checksums, which is great. Yet when I try a higher-level write operation, such as copying a file, everything blows up. The exact nature of “blows up” is hard to identify – if I could explain it, I could probably understand how to fix it. In practice it means that the software complains about “write error”, or the Emu displays a buffering-related error.

On the Macintosh, all floppy disk write operations are verified by reading back the newly-written data, unless verification is explicitly disabled. From the point of view of a disk emulator designer, that’s a very nice feature, because any mistakes that occur during writing are caught and reported right away. But for Apple II software, verification of writes doesn’t appear to be the norm. At least in the GS/OS Finder, you can duplicate a file on a floppy disk, and GS/OS will show that everything succeeded regardless of what was actually written to the disk. If there was a problem, you’ll only find out about it later when you try to use the new file.

A second wrinkle is that some Apple II copy software like Copy II+ does something more akin to a single-track format operation than a standard write. The sectors on a disk consist of an address header followed by a data chunk. Normally the address headers are written once when the disk is formatted, and then never touched again – only the data chunks are modified. My experiments show that Copy II+ violates this rule, though, and writes new address headers. Floppy Emu isn’t designed to handle this, so the write operation fails. This isn’t an Apple II issue, but is also true of the Mac and Lisa firmware, and has been the case since the earliest days of Floppy Emu. There may be a way to configure Copy II+ so it doesn’t rewrite the address headers, but if so I haven’t found it yet.

I found more unexpected results when snooping on ProDOS disk writes. ProDOS works in units of 512 byte blocks, which are stored as two separate 256 byte sectors on the floppy disk. Every ProDOS write should therefore look like two successive sector writes, to two different physical sectors. But what I observed was that the same physical sector was written twice in a row. This must be a bug somewhere in my layers and layers of abstractions, but I haven’t been able to locate it. Or maybe the way I’m tracking the write activity is flawed.

In short, write support is a pain. I can see when something went wrong by observing error messages, but I only have a limited ability to look inside and examine each step of the write process to find the cause. I may need to invest some time in creating better debugging tools, before I can get to the bottom of it all.


As always, I welcome your feedback. If you’ve tried this new 5.25 inch disk emulation on your Apple II system, leave me a note in the comments! Even if you have nothing to say beyond “works on my IIc”, that’s still helpful to know. Thanks!

Read 9 comments and join the conversation 

Floppy Emu Has Cholera

20150507_095207_Richtone(HDR)_resized copy

Achievement unlocked! 5.25 inch 140K disk emulation for Apple II is now working for Floppy Emu. I booted up my Apple IIe with an Oregon Trail disk image, lost some oxen, got cholera, and died. The 5.25 inch disk emulation has been tested on a IIgs with the built-in floppy port, on a IIe with the 19-pin Disk 5.25 controller card, and on a IIe with the classic Disk II controller card. Awesome!

This brings the total number of disk formats that Floppy Emu can emulate to eight: Mac 400K, Mac 800K, Mac 1.44MB, Mac hard drive (HD20 compatible), Lisa 400K, Lisa 800K, Apple II 800K (3.5 inch), and Apple II 140K (5.25 inch).

These are early days for the 5.25 inch Apple II disk emulation, so I won’t be posting the new firmware quite yet. There are still a number of issues remaining that I hope to resolve soon. The big one is write support: the current firmware doesn’t yet implement 5.25 inch write emulation, so disks are read-only. The disk image format support also isn’t complete, and raw DOS 3.3 order images (.do files) are the only format that works. I expect to add ProDOS order (.po files) and 140K 2MG images soon – or is 2MG only used for 800K disk images? I’ll have to check.

In my previous post, I mentioned that the raw disk bytes weren’t always being received correctly by the Apple II. It turned out that the width of my “1” pulse was too narrow, and sometimes a 1 would be detected as a 0. Data arrives from the disk at a rate of 4 microseconds per bit, where a logical 0 is sent as 4 microseconds of 0 volts, and a logical 1 is sent as a short pulse to 5V and back within a 4 microsecond window that’s otherwise 0 volts. Initially the width of my pulse was 0.25 microseconds. When I widened it to 0.75 microseconds, it started working reliably. That’s curious – is the disk controller actually doing polling, instead of edge triggering? Why didn’t the narrower pulse work?

It was a headache getting the checksum algorithm working correctly. The checksum is described in the book Beneath Apple DOS, but even after re-reading it several times, I was still confused. The algorithm is tightly coupled to the method the Apple II uses to read and write disk data, where it performs a process called “pre-nibbilization” before writing each sector, separating the upper and lower bits of each data byte and storing them in two different buffers. Floppy Emu works differently, performing nibbilization on the fly, so it was somewhat awkward to transmit data and checksums the same way.

Interleave and Sector Ordering

The other question that I struggled with was sector ordering. If you’ve been around the Apple II emulation world for a while, you’ve probably heard the terms “DOS order” and “ProDOS order” when referring to disk images. You may have also seen some discussion of sector interleaving within a track. The meaning of these terms and the interplay between them took me quite a while to understand.

Some background: each sector on the disk is prefaced with a sector header. The header is not part of the sector itself, and doesn’t count as “data” when you’re totalling up how much data a disk contains. A crucial piece of information contained in the header is the sector number, used by the operating system to identify which sector is which. Typically the sectors aren’t actually stored consecutively on the floppy disk, but are interleaved. A Macintosh 800K floppy track has the sectors interleaved like this:

0 6 1 7 2 8 3 9 4 10 5 11

This is a performance optimization. The floppy disk is always spinning, and without interleaving, a vintage computer would be too slow to finish processing the data from sector 0 before sector 1 spun under the head. By the time it was ready to begin reading sector 1, that sector would have already spun past, so the computer would have to wait for it to spin all the way around again. By staggering the sectors on the floppy disk, the computer gains some extra breathing room and avoids needing a full rotation for the next sector.

Things begin to get confusing when we talk about physical sectors vs logical sectors. Physical sector numbers are the numbers contained in the sector headers on the disk. Logical sector numbers are determined by the OS, and define the data contained in each sector. If you stored a large text file on a floppy disk, the first few sentences would be stored in logical sector 0, the next few in logical sector 1, then logical sector 2, etc.

On the Mac, physical and logical sector numbers are the same. The sector number in the sector header is the same as the number assigned by the Mac OS. If we use A[B] to describe a sector whose sector header number is A and whose data contents are the operating system’s sector number B, then the Mac has a 1:1 relationship:

0[0] 6[6] 1[1] 7[7] 2[2] 8[8] 3[3] 9[9] 4[4] 10[10] 5[5] 11[11]

The Apple II handles interleaving differently. Physical sector numbers aren’t interleaved, and instead they’re just numbered consecutively 1 to N along the track. But the operating system uses so-called “software skewing”, where logical sector N is not necessarily stored in physical sector N. For DOS 3.3, the relationship looks like this:

0[0] 1[7] 2[15] 3[6] 4[14] 5[5] 6[12] 7[4] 8[11] 9[3] 10[10] 11[2] 12[9] 13[1] 14[8] 15[15]

So when a DOS 3.3 Apple II program wants sector 4, it actually fetches physical sector 7 from the floppy disk. For all practical purposes, physical sector 7 is sector 4. My head hurts already.

With ProDOS, logical data is stored in 512 byte blocks instead of 256 byte sectors. Each 512 byte ProDOS block N is stored in two separate 256 byte physical sectors, NA and NB:

0[0A] 1[4A] 2[0B] 3[4B] 4[1A] 5[5A] 6[1B] 7[5B] 8[2A] 9[6A] 10[2B] 11[6B] 12[3A] 13[7A] 14[3B] 15[7B]

Confused yet? A DOS ordered disk image is one in which the physical sectors are stored in ascending order by DOS 3.3 logical sector number. A ProDOS ordered disk image is one in which the physical sectors are stored in ascending order by ProDOS logical block number. While the two orderings are obviously derived from the two different operating systems, they are ultimately just arbitrary ways of grouping data into 256 byte chunks. DOS 3.3 software can be stored in ProDOS ordered disk images, and vice-versa.

20150507_111136_resized copy 20150507_111003_resized copy

Read 11 comments and join the conversation 

5.25 Inch Disk Kickoff


I’ve started working on Apple II 5.25 inch disk emulation for Floppy Emu. It’s still early, and it’s progressing more slowly than I expected, but I think it’ll work. It will be great to have a new mode to emulate the zillions of 5.25 inch Apple II disks out there. I’ve been using the IIgs for my testing, but it should work on any Apple II series machine. No adapters needed either – just plug in the Emu board and go.

The first step was to convince the computer that there was even a 5.25 inch drive connected. That took more effort than I expected, because the 5.25 drive doesn’t have any way of directly telling the computer “I’m here”. After some trial and error, I discovered that the computer just blindly turns on the drive motor and starts reading from it. If it gets valid data or garbage data, either way it knows there’s a drive attached, but if it gets no data at all then it assumes no drive is present. I had assumed an empty drive would send no data, but some investigations with a logic analyzer proved that theory wrong. To make Floppy Emu be detected as an installed drive, I had to change the firmware to send a constant stream of sync bytes even when there’s no disk inserted.

Stepping the drive head to the correct track proved to be a major hassle. The Apple II directly controls a 4-phase stepper motor in the 5.25 disk drive, activating each coil in the correct sequence to move the stepper in or out. I modified the firmware to monitor these control signals, and simulate what would happen to a real stepper motor. This was more difficult than it might sound, because the control signals can be driven in various ways to produce half steps, full steps, or weird combinations of inputs that don’t do anything well-defined. Fortunately I think I’ve got it working now.

Speaking of the stepper controls, I hooked up my logic analyzer to the disk interface signals so I could see what was going on. For all the years I’ve been working on floppy emulation, I can’t believe I’ve never done this before! I normally rely on indirect methods of observation, from the computer or the Emu, and haven’t had a direct window onto the actual disk signals.


The waveform above shows the characteristic chukka-chukka-chukka of an Apple II 5.25 inch drive when the computer recalibrates the track position. During the first section, the phase lines are repeatedly activated one at a time in order, from lowest to highest, which moves the drive head outwards. Then there’s a pause, followed by a second section where the phase lines are activated from highest to lowest, which moves the drive head inward. Eventually the head hits a mechanical stop at track 0, making the familiar rattling sound of a 5.25 inch floppy drive.

For comparison, the waveform below shows what happens on the IIgs, just a brief moment after the power is turned on. Note that the time scale is much smaller, and the phase lines aren’t driven in sequence, but instead each one has an independent behavior. I believe this is the IIgs asking “Hello, are you a SmartPort hard disk? No? OK then.” I’ll find out more when I look further into SmartPort HD emulation.


Copy II Plus, an Apple II disk copy program, has some very nice sector and track diagnostic tools built in. Using these I was able to verify that my track stepping logic is working. I was also able to capture a raw dump of an entire track, showing all the bytes straight off the disk (or the Emu), without any kind of post-processing to try to identify where the sectors are. This will be incredibly valuable as I start to work on actually sending the correct disk data.

In the image below, you can see that it’s already sort of working. This shows a Copy II Plus dump of track 0 of an emulated 5.25 inch disk from Floppy Emu. The data itself is actually from a Macintosh disk, with Macintosh style sector headers, so that part obviously isn’t right. But what’s encouraging is that the raw data is being received correctly by the Apple II – I circled the familiar D5 AA 96 that marks the start of a sector, and D5 AA AD that marks the start of the sector’s data payload.


Unfortunately, some of the data is received incorrectly. The screenshot shows an example that mostly worked, but in many cases, parts of the sector are garbled. The data payload shown above should have contained hundreds of “96” bytes after the D5 AA AD, but it only has 23 of them before something goes wrong. Even the highlighted “FF” sync bytes before the data payload are wrong: some of them show “AA” and other incorrect values. Maybe the bit rate is slightly off? Bad voltage levels? Microcontroller interrupts messing with the bit timing? I’ll figure it out eventually.

Read 3 comments and join the conversation 

ROM 03 Revisited


Good news, Apple II fans! The Apple IIgs ROM 03 mystery has been solved. A few weeks ago I added new support to Floppy Emu, for emulation of 3.5 inch Apple II disks. I used it to boot my Apple IIgs with GS/OS… fun. Then I started hearing from other IIgs owners for whom the new firmware didn’t work, but I couldn’t understand why… not fun. The issue seemed related to differences between IIgs version ROM 01 and ROM 03, but I wasn’t sure what was going on or how to fix it. This prompted the post Apple IIgs ROM 03 Headaches. Now, after a lot of head scratching, I think I’ve finally got it figured out.

A huge “thank you” goes to Steve Palm, who did an extraordinary amount of testing under different conditions with his ROM 03 machine, and to Jason Galarneau, who loaned me a ROM 03 machine to experiment with directly. What I learned was that the ROM 03 problem is caused by incomplete decoding of the disk drive enable signals, causing the Emu to respond at inappropriate times. I had actually diagnosed the problem correctly in this earlier post, and I even provided a potential solution there, but I somehow convinced myself this wasn’t the ROM 03 problem, or wasn’t the main problem. Wrong!

On a Macintosh floppy port, there’s a single active low signal called /ENABLE that tells the drive when to wake up. The earliest Apple II 5.25 inch drives worked the same way. But Apple later complicated things in order to support daisy chained disk drives, and chains containing multiple different types of drives, to where on an Apple IIgs the floppy port has three different enable signals: /DRIVE1, /DRIVE2, and /EN3.5. Floppy Emu was only listening to /DRIVE1, and wasn’t even connected to the other signals. The difficulties are described in much more detail in the earlier post, so I won’t repeat them here.

The final step was to build a prototype of the external adapter described in the earlier post. Since the Emu board lacks connections for /DRIVE2 and /EN3.5, the external adapter is responsible for decoding those signals along with /DRIVE1, and passing the result to Floppy Emu as a single /ENABLE signal. And what do you know, it works! No more ROM 03 problems, and no more limitations on where the Emu can appear in the disk daisy chain.

The adapter prototype also includes a couple of resistors not shown in the diagram. There’s a 10K pull-up resistor for /DRIVE2, because that signal isn’t connected on a Mac or Lisa. And there’s a 470 ohm series resistor on WRPROT, which is the only signal that changes direction between the Mac/Lisa and Apple II firmwares. No more worries about possibly damaging something if you accidentally use the Apple II firmware while connected to a Mac.


A Universal Apple Adapter for Floppy Emu

The original name I gave the adapter is misleading – it’s not an adapter for the Apple II, it’s an adapter for everything including the Apple II! There’s a photo of the adapter prototype at the top of this post, with the current do-nothing adapter also pictured for comparison. The new universal adapter has a switch on it. Set it to “3.5” if you want to emulate an Apple Disk 3.5 for Apple II, or set it to “OFF” if you want to emulate any other type of Apple II, Mac, or Lisa disk.

There’s potential for confusion with this new universal adapter, so I’m trying to choose names and terminology carefully. The adapter is only REQUIRED in a few specific circumstances, but it’s COMPATIBLE with all circumstances, so you can just plug it in and leave it there. Macintosh computers and the Lisa don’t need the adapter, and you can also boot an Apple IIgs ROM 01 machine from the Emu without the adapter. And when Apple II 5.25 inch and SmartPort disk emulation is ready, those shouldn’t need the adapter either. But for 3.5 inch emulation on a IIgs ROM 03 machine, or 3.5 inch emulation on a IIgs ROM 01 machine where the Emu is not the boot disk, this adapter is just what the doctor ordered.

So what’s next? I hope to have some of these adapters available for sale shortly. They’ll be offered as an alternative to the existing “convertible extension cable”, for a few dollars more. People who expect to use Apple II 3.5 inch disk emulation (mainly IIgs owners) along with other emulation modes can use the new cable, while people who don’t care about Apple II 3.5 inch disk emulation can stick with the current cable. Longer term, I hope to build the functionality of the universal adapter into a new Floppy Emu, but that won’t be any time soon.

Crazy idea: with other external adapter boards like this one, with a different external connector, it might be possible to develop Floppy Emu disk emulation firmware for completely different computer platforms. Atari disk emulation, anybody? Amiga? They all operate on the same basic principles as the existing Floppy Emu disk emulation. Yes, there are many differences in the details, but the more emulation modes I implement the better I’m getting at abstracting the drive-specific parts from the shared functionality. Maybe someday…

Read 8 comments and join the conversation 

« Newer PostsOlder Posts »