It is done! Floppy Emu Smartport hard disk emulation for the Apple IIgs and Apple IIc is now working nicely, after way too many headaches, mysteries, and assorted debugging adventures. I’m very excited, because this completes the grand slam of Apple disk drive emulation. With appropriate firmware, a Floppy Emu board can now emulate every type of drive that Apple ever made for a DB-19 disk connector or 20-pin ribbon connector, for Apple II and Macintosh and Lisa. Hard drives, floppy drives, different sizes, densities… it does them all. That’s nine different drive types in total.

Download the new Smartport-capable Apple II firmware now: apple-II-0.1E-F4
Hard disk image #1, 6 MB software collection compatible with IIgs and IIc: smartporthd.zip
Hard disk image #2, 32 MB GS/OS 6.0.1 volume for IIgs: gsosdisk.zip

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. This firmware can emulate a Smartport hard drive, 3 1/2 inch 800K drive, or 5 1/4 inch 140K drive (for any model of Apple II). For best results with 3 1/2 inch and 5 1/4 drive emulation, some systems may require an intelligent adapter board (coming soon, more info below). To switch emulation modes, press the Emu’s SELECT button during the display of version info on the LCD during startup.

 
Smartport

The Emu can emulate as many as four simultaneous Smartport hard drives, and the size of each disk image can be up to 32 MB. Here’s a pic of a IIgs with four different Smartport volumes mounted:

On your SD card, the four disk image files should be named SMART0.*, SMART1.*, SMART2.*, and SMART3.*, where * is either PO, HDV, or 2MG. These seem to be the only formats in common use for Apple II hard disk images. If there’s another format you’d like to see supported, let me know and I’ll see what I can do.

On the IIgs under GS/OS, all four Smartport disks appear on the desktop. On the IIc there’s no GUI desktop, and my ProDOS skills are too weak to understand how to access disks other than the boot volume, but from looking at the disk I/O the IIc hardware definitely sees all four disks. I did try the Apple II Desktop GUI (MouseDesk) on the IIc, and it only showed the boot disk, so maybe it’s a software thing. The pic below shows a IIc booted from a 16 MB Smartport disk, with 32767 total blocks reported by the CATALOG command.

It’s important to note that not every Apple IIc supports Smartport disks. The original IIc ROM version 255 lacks Smartport support, but later ROM versions 0, 3, 4, and 5 all have it. The Apple IIc+ also has Smartport support. You can find the IIc ROM version by doing PRINT PEEK(64447).

So what’s changed since the previous update?

• Increased max number of Smartport disks to 4.
• Implemented disk writes. Read-only is boring.
• Eliminated the “phantom 5 1/4 inch drive” that was appearing on the desktop
• Optimized the startup behavior, so it’s fast enough for a cold boot (initial power on)
• Added 2MG support
• Made the status LED blink during Smartport activity
• Implemented handlers for the CONTROL and FORMAT commands
• Lots of hardware testing and error handling cleanup

The previous issues surrounding the STATUS command and disk size reporting turned out to be non-issues. Nothing to see here, move along.

I wasted lots of time troubleshooting a problem I’d seen before: with certain SD cards, the Emu would sometimes fail to recognize the card at startup. Minor additions or modifications to the code seemed to make this problem disappear, and it only happened with specific SD cards, and then it was intermittent. I finally discovered that the problem was related to my AVRISP mkII programmer that I use for flashing new AVR firmware. During development I would often leave the programmer connected to the Emu while running tests. I found that if I disconnected the programmer before performing any tests, the problem disappeared. I don’t have any solid explanation why that helped, but I’ll take it anyway.

 
The Intelligent Adapter Board. Converter. Thing.

Some months ago, I learned that 3 1/2 and 5 1/4 inch drive emulation doesn’t work 100% with certain Apple II systems, and these systems will require an adapter board with active electronics. 5 1/4 inch read emulation works fine on all systems without any adapter, but 5 1/4 writes don’t work correctly on the Apple II, II+, or IIe. 3 1/2 inch emulation works on a IIgs with ROM 01 if you boot from the emulated disk, but not if you boot from another disk, and not on a IIgs with ROM 03. Yeah, it’s complicated. Fortunately the Smartport hard disk emulation works without any adapter. For Apple II users with one of the mentioned systems, who expect to use 3 1/2 or 5 1/4 inch drive emulation, they’ll want to get one of these adapter boards. The board has a switch to select between 3 1/2 inch emulation and all other modes. The adapter isn’t necessary for the Macintosh and Lisa, though it’s still compatible with them, so you can use it everywhere if you wish.

The pic above shows a prototype of the adapter board. Initially I’d planned to call this something like “Apple II adapter board for Floppy Emu”, but that’s misleading. That name would make it sound like the board is required for all Apple II usage (it’s not), and that it only works on the Apple II (it also works on the Macintosh and Lisa). Instead, I’ll probably go with a name like “Intelligent Adapter Board”, with some footnote on the Floppy Emu page explaining who might want one and why. I had intentionally postponed manufacturing any adapter boards until I had all the emulation firmware working, to ensure I knew all the cases the board needed to support. Now that that’s done, I can start the wheels turning and should have adapter boards available for sale in about four weeks.

 
Beta Testing

I’ve done my best to find all the bugs in the new Smartport firmware, and test it on many different Apple II systems, under many different software programs. While I think it’s pretty solid, there’s a big difference between a single-person test and a wider release. If you have a stable of Apple II systems at your disposal, please help me out by testing Smartport emulation on as many different systems as you can. If it works, or doesn’t work, either way that’s helpful information.

Happy retro-computing!

Read 6 comments and join the conversation 

Smartport hard disk emulation is now working on Floppy Emu, with my latest firmware! This mounts an SD memory card as an external 32 MB hard disk, on Apple II machines with Smartport support: the GS, or //c with ROM version 0 or later. It provides solid state storage similar to the CFFA 3000, Focus Drive, etc. I’ve tested it on both the GS and the //c, and it works without any special adapters, using the connector and cable I’ve already been selling for Macintosh use. While there are still many wrinkles to iron out, the basic functionality is there, so I’m excited.

I’m not releasing the new firmware just yet, because it’s still so full of holes that it’s probably not useful to anyone. Here’s where things stand at the moment:

• Emulates a single hard disk, using a disk image stored on the SD card named “smart.hdv”. This is just a plain ProDOS-ordered disk image file. While Smartport technically supports disks up to 8 GB, I believe ProDOS and GS/OS are limited to 32 MB maximum.
• Disk images are mounted read-only. Write emulation coming soon!
• The disk won’t “cold boot” when you turn on the power. Instead, you have to turn on the Apple II, wait a moment, then press CTRL+Open Apple+RESET. This is because the emulator doesn’t initialize itself fast enough at first power-up in order to be ready when Apple II first checks the disk. I hope to have a fix for this soon.
• Under GS/OS, when using Floppy Emu as a Smartport hard disk, a phantom 5.25 inch drive also appears on the desktop. I’m not sure what’s happening there…

The current version of the firmware spews a lot of text to the LCD to help troubleshoot what’s happening. R for a block read, S for a status request, I for an init command, etc. If necessary, it can also display the block number for the read commands, and other details. But it’s a lot of information to cram onto a 21 x 6 character LCD, especially when it all scrolls by so fast you can barely read it.

 
ProDOS Hard Disk Images

Beyond those bugs, there are a couple of larger issues that also need sorting out. For the Apple //c, I’m actually not sure how to make a 32 MB hard disk image with ProDOS and a collection of other software. The //c can’t run GS/OS, so I can’t use any of the many GS hard disk images available on the web. There must be some way to use Ciderpress and/or an Apple II emulator to create a blank 32 MB disk image, format it, and fill it with ProDOS and other software, but I can’t seem to figure out how.

The photo shows an Apple //c booted with Floppy Emu’s new Smartport firmware, using a ProDOS disk image that I downloaded from http://www.apple-2.com/vintage-dl/smartporthd.zip. The description of the disk image says it’s 32 MB, but the image file is actually only about 6 MB uncompressed. What’s even stranger, you can see in the photo that it reports 57422 blocks used and 20466 blocks available, which is a total of about 38 MB – larger than either the actual or claimed size of the disk. I believe this info is taken from the disk image’s filesystem data and not from the drive itself, so I’d like to try making another disk image for the //c and see if the size is reported correctly.

 
What’s the Status?

The other issue is the Smartport STATUS command. There are a few different commands that the computer can send to a Smartport device, including init (command 5), read (1), and status (0). In my tests, the computer requests the drive status a crazy number of times, sometimes making 14 consecutive status requests. Since the data returned is just some capabilities flags and the drive’s size, there’s no reason to request it more than once. I strongly suspect that my status reply is somehow not right, or not what was expected, so the computer re-requests status over and over hoping for a different result. Eventually it makes an extended status request (command 0x40), even though I’ve set the drive capability flags to indicate it does not support extended commands. I respond to this with a generic NAK that I’m not sure is a valid response, but it seems to work and the computer eventually boots after making tons of status requests.

I’m not sure how to go about debugging this, or whether it’s even abnormal. I can troubleshoot low-level issues, like checksum errors or data being read incorrectly. But when the problem is at a higher level in the OS software or Smartport ROM routines, it becomes a black box that I can’t see inside. What kind of status response was the software requesting, and why wasn’t my response satisfactory? Or was it? I probably need to find some kind of Smartport utility or diagnostic software, if such a thing exists, to help troubleshoot this one further.

 
But Wait!

Update: it appears the disk image size is being reported correctly, and the status is probably OK too. I was confused because the disk image I tested on the //c does something strange. In its ProDOS header it says it’s 32767 blocks (just under 16 MB), but there’s only 6 MB of data in the image, and the image file itself is only 6 MB. The 10 MB of empty zero space that should be in the image file is just missing. This is fine as long as you treat the image file as a read-only disk, but if the computer ever tried to write new files into the 10 MB of empty space, it would blow up.

Through experimentation, I discovered that Apple II System Utilities (shown in the photo) reports the number of free blocks correctly, but it doesn’t actually know how many used blocks there are. Instead, it takes the total number of blocks on the drive (as reported by the Smartport status command), and subtracts the number of free blocks. In this case, I was using the size of the disk image file to determine the size of the disk drive to report for the status command. So it looked like there was a 6 MB disk drive with about 10 MB of free space, meaning there was -4 MB available! But the negative number was displayed as a positive unsigned count of blocks used, leading to confusion.

Along the way, I found that changing the disk drive size in the status reply caused the expected change in the “blocks used” count of Apple II System Utilities. That means the status reply was actually being received OK by the Apple II. I also found that changing the read-only flag in the status data worked as expected. And I could modify other status values to identify the drive as a removable drive or a fixed drive. When identifying as a removable, the Apple II continued to poll status about once per second after booting up, presumably to check if the media had been removed. But when identifying as a non-removable drive, the Apple II made no more status inquiries after booting up. All of this tells me that the status info is reaching the computer just fine, and is being interpreted as intended. I still don’t know why the computer requests the status so many times during the boot process, but maybe it’s normal. At any rate, it doesn’t cause any problems that I can see.

Read 11 comments and join the conversation 

Some progress at last: Floppy Emu is now partly working as an external Smartport hard drive for the Apple II GS. This should provide functionality similar to the Focus Drive, CFFA 3000, or other solid-state hard drive solutions, for Apple II Smartport-capable machines: the II GS, and the IIc with ROM versions 0 or later. There’s still some weirdness going on, and the new firmware doesn’t yet work on the IIc, and only half-works on one of my two GS machines, but there’s been enough progress that I’m confident I’ll be able to get the rest of it sorted out. It boots my plain vanilla GS machine with no other drives attached, using a 32 MB hard drive image of GS/OS 6.0.1.

Sorry this is a mostly content-free update. I’m still alive and working on this, and that’s about all you need to know for now. I hope to post more details soon once I have something working that’s a bit more robust.

Be the first to comment!