Archive for the 'Floppy Emu' Category
Fancy a 2 GB mass storage solution for your Apple IIGS? Last week I released new Smartport-capable firmware for the Floppy Emu disk emulator. It can emulate up to four simultaneous Smartport hard drives, which I thought were limited to 32 MB each, but it turns out that’s not true! As Ken Buchholz of Apple2Online.com explained to me, 32 MB is the maximum size of a ProDOS volume, but the underlying Smartport protocol supports drive sizes up to 8 GB. By using a filesystem other than ProDOS that supports larger volume sizes, you can take advantage of that extra potential.
So what filesystem should you use? On the Apple IIGS, the computer must boot from a ProDOS volume, but under GS/OS 6.0.1 it can mount secondary volumes in HFS format – the same filesystem format used by vintage Macintosh computers. Of course you won’t be storing Macintosh files in that volume, but Apple II files. HFS supports volume sizes up to 2 GB, so if you combine a 32 MB primary ProDOS volume for booting with a 2 GB secondary HFS volume for all your warez, you’ll be good to go! On a IIGS with the Floppy Emu under Smartport emulation mode, this is as easy as putting two files on your SD card: a 32 MB smart0.PO containing GS/OS 6.0.1, and a larger (up to 2 GB) smart1.PO formatted as an HFS volume, containing whatever other files you want. Apple2Online has some blank HFS disk images of various sizes in their CFFA3000 area, which are perfect for Apple II usage.
The screenshot below shows a 512 MB HFS volume, with a few Apple II files stored on it. I got impatient and didn’t want to wait for a 2 GB disk image to copy to my SD card.
There’s one extra wrinkle to watch out for when using very large disk images like these. Due to the way it works, Floppy Emu requires all disk images to be contiguous on the SD card. A 500 sector image must occupy the contiguous range from sector N to sector N+499, or else Floppy Emu will display an “image not contiguous” error when it mounts the image. For smaller disk images this is rarely a problem, but for a large disk image on an SD card with some fragmentation, it’s more likely to be an issue. If necessary, you can reformat your SD card, then copy the large disk image to it first, in order to guarantee it will be contiguous.
New Apple II firmware apple-II-0.1G-F4 adds support for parsing the HFS volume name of a large disk image, so it’s displayed correctly on the Floppy Emu’s LCD. Have fun!Read 2 comments and join the conversation
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.
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.
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 2 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 0×40), 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.
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 10 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!
Judging from the Apple II questions I’ve received, my commentary has left a lot of people confused. Sorry everyone! Here’s a recap of Apple II disk support for Floppy Emu. I’ll try to clarify the current status of Floppy Emu disk emulation, and the plans for the future.
As of today, there are two separate firmwares available. One supports the Macintosh and Lisa (floppy and hard disk), and the other supports the Apple II. Both will work on any Floppy Emu board, and can be downloaded from the product description page. Installing new firmware only takes a few minutes – just copy two files to the SD card, and press a few buttons. You can switch between the two firmwares as often as you’d like.
The Apple II firmware will eventually emulate three kinds of disks:
- 5 1/4 inch (140K) disks, for any Apple II machine
- 3 1/2 inch (800K) disks, primarily for the Apple IIGS
- Smartport hard disks (32MB), primarily for the Apple IIGS and some models of Apple IIc
5 1/4 and 3 1/2 inch disk emulation is finished and working in the current Apple II firmware. Download it now and go crazy! Work on Smartport hard disk emulation hasn’t started yet, but it’s next on my “to do” list.
The Floppy Emu board can be connected to an Apple II system in two different ways, depending on your needs. Most people will use the 19-pin disk port. The Apple IIGS and IIc have built-in disk controller circuitry, with a 19-pin disk port on the back of the machine. The Apple 5.25 Drive controller card has the same 19-pin disk port, and will fit in any model of Apple II with slots. The Floppy Emu board can connect to this 19-pin disk port. If you have the Emu with built-in floppy connector, then the board will plug directly into the disk port, and hang off the back of the machine. Or if you have the Emu with convertible extension cable, the adapter at the end of the cable will plug into the 19-pin disk port.
If you have an older Apple II with the Disk II controller card instead of a 19-pin disk port, you can also connect the Emu to one of the 20-pin headers on the Disk II controller card. Use the ribbon cable that came with the Emu convertible extension cable, or borrow a ribbon cable from a Disk II drive. All Emu boards have a 20-pin shrouded header where the cable will plug in. Be careful to orient the other end of the cable correctly, since the controller card’s 20-pin header isn’t keyed or shrouded, so 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 20-pin header.
During development of the firmware for 5 1/4 inch and 3 1/2 inch Apple II disk emulation, I discovered that some Apple II setups can’t be supported through firmware changes alone. In addition to new firmware, these setups also require some external hardware modifications for the Floppy Emu board. The easiest way to handle this is with an Apple II adapter board that connects inline between the Floppy Emu and the Apple II computer. Something that looks roughly like this:
I plan to offer an Apple II adapter board as a new product, probably beginning this summer. I’m intentionally going slowly, postponing manufacturing of the adapter boards until the Smartport hard disk work is finished, and I’ve done enough testing to be confident there are no other issues that require hardware modifications. Once it’s ready, the Apple II adapter will be available as a separate item, or bundled with an Emu board for new customers.
As pictured above, the Apple II adapter board is a 19-pin to 20-pin adapter. This will be fine for most Apple II customers, but will be useless for customers using the Disk II controller card, since it doesn’t have a 19-pin disk port. I’m undecided whether to add a second 20-pin header to the existing adapter board design (increasing the size and cost for everyone), or make a different version of the adapter board (more product fragmentation), or something else.
Not every Apple II user needs an adapter board – only the “some setups” that I mentioned. But for those who want a simple and fool-proof path to Apple II disk emulation, the adapter board will be the way to go. For power users willing to read the fine print, they may find that an adapter board isn’t necessary for them. The current landscape looks like this:
5 1/4 disk emulation – Reading from a disk image works without the adapter. Writing to the disk image also works without the adapter on the IIGS and IIc with built-in disk controller. The adapter is required when writing to the disk image using a separate disk controller card, like the Disk 5.25 or Disk II controller cards.
3 1/2 disk emulation – Reading and writing to a disk image works without the adapter, on the IIGS ROM version 1 (the most common version), when the computer is booted from the emulated disk. The adapter is required for the IIGS ROM version 3, or for any Apple II model when the computer is booted from a different floppy or hard disk.
Rather than wait for an adapter board, some people may want to make hardware modifications themselves. There are two separate modifications: one for 5 1/4 disk emulation and one for 3 1/2. The 5 1/4 inch modification is relatively easy for anyone who’s comfortable with a soldering iron, but the 3 1/2 modification is a bigger challenge.
The 5 1/4 inch modification requires only a single 10K ohm pull-up resistor, connected between /WRREQ and +5V. This won’t interfere with 3 1/2 disk emulation, or Mac/Lisa disk emulation, so it’s fine to leave permanently installed. You can make this connection anywhere on the board that’s convenient. The easiest spot is on the bottom of the board, near the disk connector. But a resistor added here will add a little bump that prevents the board from fitting properly in the standard case. If that’s a concern, the pull-up resistor can also be added on the top of the board, using 30 AWG patch wire to reach the finely-spaced pins of the CPLD chip. Using these photos as a guide, connect a 10K resistor between any pair of /WRREQ and +5V pads:
The 3 1/2 inch modification requires adding additional chips, inserted inline between the Floppy Emu board and the Apple II. A schematic is shown here. Unlike the 5 1/4 inch modification, this change is only appropriate for emulation of 3 1/2 inch Apple II disks. You’ll probably want to add a switch to disable the additional circuitry when emulating other types of Apple II disks, or Macintosh/Lisa disks.
Don’t Forget to RTFM
Remember, many Apple II setups don’t require any hardware modifications at the Emu board – they’re just plug and go. Before you heat up your soldering iron, or cry over the wait for an Apple II adapter board, read the details above and see if you actually need one. If in doubt, try it first and see. You won’t hurt anything, and the worst case is that it simply won’t work. If 5 1/4 inch writes cause the Emu to freeze, or 3 1/2 inch I/O causes the Apple II to freeze while booting or report strange boot-up errors, then you’ll know it didn’t work. Everyone should at least be able to do 5 1/4 inch disk read emulation, which means you can boot up your favorite games like Castle Wolfenstein straight from the SD card. Have fun!Be the first to comment!
Wah wah wah waaaaaaah. In the battle for 5.25 inch Apple II disk write emulation, it seems I declared victory too soon. While write support works great in many situations, it doesn’t work at all in others. The problem is with the /WRREQ signal from the Apple II, which goes low to indicate when a write is occurring. On old-school disk controller cards, like the Disk 5.25 Controller Card, or the even older Disk II Controller Card, this signal is generated by a 74LS05 hex inverter chip with open collector outputs. It can actively pull the signal low, but it needs an external pull-up resistor to pull the signal high. And Floppy Emu doesn’t have one. On the Apple IIgs (and probably also the IIc), the circuitry can actively drive /WRREQ high, so this isn’t a problem. And on other Apple II models, it’s also not a problem if there’s another real drive connected in the daisy chain, because that drive will have a pull-up, and /WRREQ is shared among all drives. But if Floppy Emu is the only disk drive connected to a Disk 5.25 or Disk II Controller Card, writes won’t work. Ouch.
The logic analyzer trace above shows what happens. /WRREQ is connected directly to an input pin on the Xilinx XC9572XL CPLD. The input has a very weak pull-up that’s active at initialization time, as well as a keeper circuit that actively maintains the input at the last externally-driven level. At power-up, the weak pull-up pulls /WRREQ high, and the keeper circuit keeps it there. Then when a write occurs, the disk controller card actively drives /WRREQ low. At the end of the write operation it releases /WRREQ, but with nothing to pull it high again, the keeper circuit maintains the low value forever. To the Floppy Emu, it looks like a write operation that never ends. You can see the result in the trace. /WRREQ stays low forever, even after the drive enable signal is de-asserted.
Unfortunately, I don’t think there’s any way to fix this other than to add a pull-up resistor. The XC9572XL CPLD chip doesn’t have configurable built-in pull-ups that I can turn on in firmware, as far as I can tell. 5.25 inch read emulation will still work fine, as well as 5.25 write emulation on a IIgs or on any Apple II with another drive present. But for a single-drive Floppy Emu setup on an Apple IIe, write emulation won’t work without a hardware fix.
I already designed an adapter board, which I described in this earlier post. I had hoped that the adapter board would only be needed for certain situations of 3.5 inch Apple II disk emulation, but now it seems certain situations of 5.25 inch emulation will need it too. There’s too much “certain situations” about the whole thing for my comfort, and I’m sure it confuses everyone else just as much. So I’ll probably just rechristen the adapter board as a general purpose “Apple II adapter”, even though it’s not strictly needed for all circumstances of Apple II emulation. That will be easy to understand, and won’t steer anybody wrong. Power users can read the footnotes and discover which Apple II setups can work without the adapter board, if they wish.
Adding a pull-up resistor to the adapter board will be easy, but it does mean I’ll need to have new PCBs made. The only good thing in all of this is that it justifies my decision to postpone manufacturing large numbers of the adapter boards until after the Apple II 5.25 inch and Smartport disk emulation is working. If I had built lots of adapter boards three weeks ago when I thought they were only needed for 3.5 inch Apple II disks, I would now have a lot of angry people who’d bought them, and a pile of additional boards I couldn’t use.Read 5 comments and join the conversation