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.

 
Feedback

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!