Floppy Emu Update: GS/OS Errors, Dual-Drive Automount, More
Here’s a new firmware update for the BMOW Floppy Emu disk emulator! This update has several small improvements and fixes for the Emu’s Apple II disk drive emulation modes.
Overrun Errors in GS/OS
The new firmware resolves a problem that could cause a “Fatal Error: Overrun” on the Apple IIGS with GS/OS. This error would appear when using Smartport hard disk emulation mode, with more than one hard disk image mounted, if you repeatedly exited and re-entered GS/OS (by exiting to BASIC or another ProDOS8 application).
I call the issue “resolved” rather than fixed, because the root cause is still not clear. What I found is that when exiting GS/OS for the second time, the computer sends a Control packet to the second hard drive (the non-boot drive) with a control code of $40. I haven’t found any documentation about this particular control code or what it’s intended to do. Other control codes are used for functions like ejecting removable media or resetting the disk drive. This particular Control packet has a very large data payload attached – about 1500 encoded bytes or 1300 real data bytes – which was overflowing the Floppy Emu’s receive buffer. Anyone have a guess what the control code $40 might mean?
Dual 5.25 Inch Drive Automount
In Dual 5.25 Inch Floppy emulation mode, automount of the most-recently-used disk now works for both drive 1 and drive 2. Previously only drive 1 supported automount.
Directories with Hundreds of Files
This firmware also fixes a UI problem that would occur if the current directory on the SD card had more than 212 files. Very large directories would exceed the memory capacity of the Floppy Emu, causing incorrect UI behavior. The new firmware will warn you if there are too many files and then limit the directory listing to the first 212. To avoid this, it’s recommended to use a hierarchical directory structure instead of flat directories containing hundreds of files each.
Get the New Firmware
You can download the latest Floppy Emu firmware from here. As always, I appreciate your feedback on firmware updates, whether it’s a problem report or just a “works great for me” confirmation. Enjoy!
Read 2 comments and join the conversation2 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
The GS/OS thing sounds like a bug. $40 certainly isn’t a standard control code. (The 4 makes me think someone mixed up the control code with an extended command code?)
And 1500 bytes? That’s really odd. The Apple IIGS Firmware Reference specifically warns on pages 136–137 that the Read and Control commands on some devices can’t handle more than 767 bytes. So presumably the generic Smartport driver in GS/OS should never be attempting to transfer that many bytes.
Is this happening with System 6.0.1 or some other version? ROM 01 or ROM3 or both?
I don’t see anything obvious in the 6.0.1 source code (yes, it’s out there if you look for it, but not any other versions that I’ve seen) … but the bug may be hard to track down. Generic Smartport devices use “generated” GS/OS drivers constructed at runtime which use generic code that consults tables to decide what to do, so the problem is most likely due to garbage being written into one of those tables at some point.
This was GS/OS 6.0.1 on a ROM 01 Apple IIgs. I’ve also tried GS/OS 6.0.4 and observed the same outward behavior, though I didn’t log the actual Smartport data packets.
The Control packet has two parts, each with its own packet begin and packet end mark, which I believe is normal. Each one is separately ACK’d using the Smartport handshaking mechanism. The first part (encoded) is:
C3 – packet begin
82 – destination unit 2
80 – source unit 0 (host)
80 – type: command
80 – aux
80 – status: OK
82 – odd byte count: 2
81 – group7 count: 1
80 – odd MSB: 00
84 – odd.1
83 – odd.2
80 – group7 MSB
80 – group7.1
80 – group7.2
80 – group7.3
C0 – group7.4
83 – group7.5
80 – group7.7
80 – group7.7
EF – checksum
EA – checksum
C8 – packet end
When decoded, this is:
04 03 00 00 00 40 03 00 00
04 – Control
03 – parameter list length
00 – unit number
00 – pointer LSB
00 – pointer MSB
40 – control code (unknown code)
03 – transfer count
00
00
The second part with the data payload begins like this:
C3 – packet begin
82 – destination unit 2
80 – source unit 0 (host)
82 – type: data
80 – aux
80 – status: OK
D0 – odd byte count: 80 decimal (this is nonsensical value)
B2 – group7 count
C9
D4
CC
BA
DB
80
80
FF
FF
…continues for about 1516 encoded bytes
This must be a special case or a bug, because the packet is so large. The largest possible Smartport packet with the standard encoding would be 127 groups of 7, plus 6 odd bytes, plus about a dozen extra bytes for headers and checksums. About 907 bytes total.