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 conversation11 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
Trying one now
AppleWorks 2.0 Program Disk gets a “SD Write Error” when setting the date. Now AW is just telling me that I need to make sure my Write-protect notch is uncovered.
Is my SD card too large? It’s an 8GB. I was using something smaller, but it died on me.
Even broader scope, DOS 3.3 Master “save test”
FEMU starts to write, then gives me “Fatal Error: SD Write Error”. //c gives me “I/O ERROR”
Do you have an image of the disk you tried? Is “save test” some kind of standard test? Both of those messages suggest an SD card problem, but I wouldn’t rule out a firmware bug either, given that this is brand new.
I just sent you an email with a few images.
save test is literally just me typing “] save test” at a basic prompt which should just create an empty file on the disk called test.
Thanks, I will check those out. Maybe I declared victory too early? Your “save test” sounds identical to the DOS 3.3 test I did, except I saved a two-line BASIC program named STEVE.
I found a 2GB MicroSD + SD Adapter and writes are working OK now. I tested the Wolfenstein image I sent you, it worked on the second try, it might be looking for actual disk timings? But it worked, so huzzah!
I guess the FEmu doesn’t like my 16GB SDHC PNY card. I will stick with the 2gb, as that’s plenty of space.
Thanks for the hard work!
Interesting! I’m glad the second card worked. Normally the card shouldn’t really matter unless its performance is really slow. When it saves a track, you should see a message briefly on the Emu’s LCD like “Saved trk 17 in 5” – that means the SD card took 5 milliseconds to write track 17. What kind of save times did you typically see with your PNY card, and with the new card? Maybe that’s a factor. I’ll try doing some tests with a few other cards here.
I did some more testing with two different Apple II systems, and three different SD cards of various sizes and manufacturers. All the disk images from Matt B worked fine on an Apple IIGS, with all the different SD cards. However, it seems that Appleworks may be incompatible with the IIGS? After saving a couple of tracks, it would display a message about preloading data to the language card, then it would lock up. This happened every time.
Unlike the IIGS, my Apple IIe system had a lot of problems. It seemed to be the same in every case, regardless of what disk or software I tried. When trying to save to the emulated disk, the LCD showed “write” for much longer than normal, and eventually the Apple II program reported an I/O error or crashed. But the Floppy Emu was left in an unresponsive state where I couldn’t eject the disk. Pressing RESET displayed a self-test failure message, saying to check CLKO-L. The only way to fix it was to turn the Apple IIe completely off, then on. I’m not sure if this is the same problem Matt B experienced – it sounds like something completely different – but it’s 100% reproducible on my IIe. I tried two different SD cards, and two different disk controllers (19 pin and 20 pin) on the IIe, with the same results. I’ll look into this more soon – maybe it’s a hardware issue with my IIe.
Good news: it looks like write emulation with all three SD cards works fine on the Apple IIe. Bad news: it looks like both common types of IIe disk controller card require an external pull-up resistor on the /WRREQ line. It works fine if a second disk drive is present, like on the Apple IIc, or as part of a daisy chain. But if Floppy Emu is the only disk drive present while using an old-school disk controller card, writes aren’t going to work. I’ll need to tweak the adapter board that I originally designed for 3.5 inch Apple II disks.
Interesting!
I don’t have my second drive connected on the //c, but perhaps the circuitry is slightly different? Maybe because it’s smartport/disk II. I do have the Emu plugged directly into the main board. Writes are not 100% for me though, but work well enough that it’s manageable.
I don’t have a schematic, but I bet the //c’s integrated disk controller doesn’t use an open collector driver, so a pull-up resistor isn’t needed. Odd that yours still has trouble with writes – aside from the pull-up issue, my IIe seems to be 100% with all the SD cards and software that I tried. Maybe I should keep my eyes peeled for a cheap //c to use for testing, and see if there’s something //c specific happening.