Apple II Hard Disk Emulation
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 conversation11 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
Making a ProDOS image is easy, even with a IIgs emulator.
1. Make a blank image in Ciderpress.
2. Mount in IIgs emulator, run the format command on the drive in GS/OS Finder. This writes the boot blocks to the drive.
3. Mount a copy of the 8-bit Apple II System Disk 3.2, copy over the “PRODOS” and BASIC.SYSTEM files
4. You should be able to boot off the image and be taken to an Applesoft BASIC prompt.
The repeated status command and ghost 5.25″ drive may be related to bus handling. The host computer may think multiple Smartport devices are connected to the machine and is trying to query them on a bus reset. It may also think a 5.25″ drive is connected by the responses its getting.
Pay close attention to Chapter 7 of the Apple IIgs Firmware Reference as it goes over the bus handshake procedures. The source of the Apple IIc Smartport firmware may also have some clues. Links to both are on the 68kmla FloppyEmu thread. The IIgs ROM disassembly is out there, I think The Mac GUI has a copy of it. There is also the SmartportCFA source, but I don’t know how well that works on a real machine in practice.
The drive size and status appear to be OK after all – see update above.
Thanks for the info Chris. So basically you have to use a IIGS emulator to make a bootable hard disk image for the //c. That makes sense… I was hung up trying to do it with a standard Apple II emulator, but didn’t see how to mount anything but a 140K floppy disk image.
I’ve been reading through the IIgs firmware reference and related source code. It’s very helpful, but also a little difficult to digest. I don’t think the piles of status commands are because the computer believes there are multiple devices connected, though I could be wrong. Each Smartport command has a destination unit number that identifies who its for, and I’m only logging and responding to commands for my unit number.
Yes, using an Apple IIgs is OK for disk images, its ProDOS all around. You could use AppleWin or any other Apple II emulator to make a boot image in conjunction with the System Utilities too. Most of them support hard drive images by creating a “dummy” Smartport compatible storage device in a slot. (see harddisk.cpp in AppleWin and smartport.c in KEGS/GSport)
The IIgs actually uses the same boot blocks for GS/OS, the “PRODOS” file in the root directory of GS/OS installs is actually a stub file to kickstart the GS/OS loader. The real ProDOS 8 kernel is stored in the System Folder as “P8.SYSTEM”.
I don’t know if its the case with ProDOS, but I know GS/OS constantly polls Apple 3.5″ drives too, just enough to barely light the activity LED. Its good to know that Smartport supports removable devices, that means hot swapping images is possible 😛 Of course getting write support working would be a plus.
Is it status cmds or init cmds that it keeps sending?
The Smartport allows for multiple devices connected in the chain. After the bus reset, then the first device waits for the init cmd. The Destination Id sent in the init cmd is then used and stored by the first device, which it should then only listen to from that point on. It then replys back with status=0, which then signals to the host to look for the next device. The init cmd is sent again with the destid incremented. This way many devices can exist on the bus, with their IDs dynamically set. The last device must send back a status of non zero to indicate its the last device in the bus init sequence.
/Rob
It is status commands. The init command is only sent once, and I reply with a non-zero result to indicate that there are no further devices. That part seems to work fine.
With my latest tests, I’m getting no more than 4 consecutive status commands during boot-up on the IIGS, but I get many sets of 4 status commands interleaved with other block reads. I still get one extended status command too (id 40). I haven’t checked to see if the IIc is doing the same thing. This is down from the 14 consecutive status commands I was seeing earlier on the GS. I think that was partly due to the disk image I was using, which included a control panel (is that the right term for Apple II?) for some kind of drive card that seemed to be causing additional status queries.
No problems, maybe its a GS thing, I don’t remember the //c sending extra status requests.
Related: per page 25 of this doc, the status command has a “status code” parameter. Depending on the value of this parameter, the device is supposed to either return the device status (status code 0), the device information block (DIB, status code 3), or some other stuff that seems irrelevant here. But I’m not sure how to pull that parameter out of the command. When I look at the byte where I think the parameter should be, I see values like A0, which isn’t a valid status code. But there’s another byte in the command that always seems to be 0 or 3, so that’s what I’m using to determine which type of status reply to make.
I found a couple of other Smartport examples online. One ignores the status code, and always acts as if it were 0, so it never returns the DIB. The other has logic to return either the device status or the DIB, but it checks if some unrelated byte is 0x20 to decide what to do. Which really makes no sense to me.
Looking further at the unexpectedly large number of status requests, it seems to be something specific to GS/OS. On the Apple //c, I only get a single request for basic device status (status code 0). On the IIgs when using the same disk image as the //c, I also get just one request for basic device status. But on the IIgs when using a GS/OS 6.0.1 disk image, I get dozens of requests for basic device status, at least 3 requests for the DIB (status code 3), and one extended status request. I’m not really sure what it’s doing, but it doesn’t seem like it’s a problem on my end. So… on to the other bugs.
GS/OS may be querying the FloppyEmu to determine if it has a matching device driver to load for it. Otherwise it switches to a “generated” driver, similar to if Windows 9x can’t find a driver for a disk drive and relies on Int 13h BIOS access. In theory disk access with a native GS/OS driver should be faster, but who knows if it makes much of a difference with SmartPort drives (it does for cards). Apple provides a native driver for the Unidisk 3.5″ for example.
Steve, Really happy with Femu and my apple iic i have upgraded to rom 4. ib boots also smrtport hdd disks.