Quantcast
Channel: Floppy Emu – Big Mess o' Wires
Viewing all 165 articles
Browse latest View live

More Fun with Apple IIgs Disks

0
0

daisy-chain-circuit

Last week I wrote about Apple II 800K disk emulation for Floppy Emu, which I used to boot my Apple IIgs. I posted the new Apple II firmware, so anybody with an Emu board and a IIgs could try it for themselves. Now I need help from anyone with the necessary hardware – could you take a few minutes to try it out, and let me know the results? I need as much information as I can get about compatability with different ROM versions and system configurations.

On my IIgs (ROM01 with 512K RAM and no other cards), I can connect the Floppy Emu to the DB19 port, load its Apple II firmware, and it works fine as Apple 3.5 Drive #1. I can boot the IIgs from it, using either ProDOS or GS/OS disk images. I can read and write to the emulated disk, eject it and insert a different disk image, no problems. The only limitation is that the Emu can’t be daisy-chained behind an Apple 3.5 Drive, making it 3.5 drive #2. This is because the extension cable I use, as well as the Emu itself, lacks two enable signals that are important for daisy-chaining.

Yesterday I heard from somebody for whom the Apple II firmware isn’t working correctly, on a ROM03 IIgs. He’s got the Emu board connected directly to the DB19 port on his IIgs, and is using the Floppy Emu Apple II firmware, just like my setup. But he can’t boot from the Emu: a ProDOS floppy image just hangs, and GS/OS floppy images start to boot, but eventually fail with errors like “Unable to load START.GS.OS file. Error=$002E” or “UNABLE TO LOAD PRODOS”. If he boots GS/OS from a hard drive while the Emu is attached, he sees an error about the “AppleDisk3.5 driver” midway through boot-up. They only thing that works is booting ProDOS from the hard drive, then doing CATALOG,S5,D1 to view the contents of the Floppy Emu disk.

Why does this work so poorly for him, when it works well for me? We’ve stepped through troubleshooting ideas by email, including removing the hard drive and other cards, but nothing seems to help. At this point, I think we’ve narrowed it down to either being a hardware problem with this specific Emu board or IIgs, or else a behavior difference between ROM01 and ROM03. That’s why I need as much info as I can get from other Floppy Emu users who’ve tried this firmware on their IIgs.

 
Apple II Disk Daisy Chaining

Fortunately there’s some good news among all of this. Remember those two enable signals I mentioned, important for daisy-chaining, but not present on the Emu or Emu cable? Yesterday I put together a hand-made DB19 to IDC20 adapter on a breadboard, along with an external logic chip, and got the Floppy Emu working successfully while daisy-chained as 3.5 drive #2. The adapter is the rather unattractive jumble of wires you see in the photo at the top. While it’s of no immediate value to anybody, the fact that this adapter works seems to confirm that my understanding of all these crazy Apple disk enable signals is correct.

Here follows a long boring discussion of enable signals. Refill your coffee now.

EPSON MFP image

On a Macintosh, pin 17 of the DB19 floppy connector is the drive enable signal. When it’s low the drive is enabled, and when it’s high the drive is not enabled. Only one floppy drive can be connected, so there’s only one enable signal.

On an Apple II, things are more complicated. The Apple 5.25 controller card was the first to use a DB19 connector, and it supported two daisy-chained 5.25 inch drives. Pin 17 is /DRIVE1 enable, and pin 9 (unconnected on the Macintosh) is /DRIVE2 enable. Within each drive, internal circuitry routes the signal from input pin 9 to output pin 17 on the daisy-chain connector. Drive #2 doesn’t actually know that it’s drive #2 – it enables itself by observing /DRIVE1 on pin 17, just like the first drive – only the first drive has sneakily rerouted /DRIVE2 to /DRIVE1. This allows for two drives to be daisy chained.

On an Apple IIgs, it’s even more complicated. Its DB19 connector supports daisy-chaining two 3.5 inch drives, and two 5.25 inch drives – as well as even more SmartPort drives, which I won’t discuss now. Pin 4 (GND on the Macintosh) is /EN3.5, a new signal that enables the 3.5 inch drives when it’s low, or the 5.25 inch drives when it’s high. The 3.5 inch drives must appear before any 5.25 inch drives in the daisy chain. When /EN3.5 is low, the 3.5 inch drives use pins 17 and 9 to enable themselves, and when /EN3.5 is high, the 3.5 inch drives pass through the signals on pins 17 and 9 unmodified to the 5.25 drives behind them.

This is getting complicated, but there’s one final kick in the nuts: when the first 3.5 drive is enabled, by the IIgs setting /EN3.5 and /DRIVE1 both low, you would think the drive would disable the next 3.5 drive behind it by setting both /DRIVE1 and /DRIVE2 high at the daisy-chain connector. But no, the first 3.5 drive disables the second 3.5 drive by setting both /DRIVE1 and /DRIVE2 low! This looks like both are enabled at the same time, which would be a definite no-no, but the Apple 3.5 Drive contains circuitry that recognizes this “double enable” as being equivalent to a disable. Why it’s done this way, I don’t know, but I’m sure it has some purpose.

The end result is that for proper behavior in either first or second position, a Floppy Emu trying to emulate a 3.5 drive should respond only if /EN3.5 and /DRIVE1 are low and /DRIVE2 is high. All three signals must be checked.

Floppy Emu doesn’t have connections for /EN3.5 or /DRIVE2, so it responds whenever /DRIVE1 is low. When connected as a second 3.5 drive, that means it’s unable to recognize the “double enable”, and it responds at the same time as the first 3.5 drive, so neither of them work properly. But when connected as the first 3.5 drive, there’s no double enable to worry about, and /DRIVE2 can be safely ignored. Ignoring /EN3.5 does mean the Emu will also respond to attempts to access 5.25 drive #1, but since there is no such drive anyway, that’s not really a problem.

 
Building an Adapter

So how can we solve this mess, without requiring a new version of the Floppy Emu? The solution I’ve used is to combine the /EN3.5, /DRIVE1, and /DRIVE2 signals externally, and feed the result to the Emu’s single /ENABLE input. I used a 74LS138 decoder chip to do this, configured to drive a single output low only when the inputs are 0, 0, and 1 respectively. You could accomplish the same thing with a few OR and NOT gates as well. Here’s a schematic:

EPSON MFP image

At some point in the future, I’ll probably manufacture and sell some adapter boards like these. The best way to put the idea into production isn’t obvious, though. This adapter design has 3.5 inch specific functionality baked directly into its circuitry, and it would be wrong if you were using the Floppy Emu to emulate a 5.25 inch or SmartPort disk, or a Mac disk. It would be annoying if people had to attach and remove an adapter every time they wanted to change what type of disk they were emulating. Maybe I could put a switch on the adapter, to select between 3.5 inch and other emulation modes, but that would be annoying too and would add further to the hardware cost. Nobody wants to flip an external switch – they want to select an emulation mode, and just have it work.

Another uncertainty is what form this adapter would take. Should it be an inline adapter, with an IDC20 connector for input and another for output? That would work, but it would mean Apple II users would need a DB19 to IDC20 extension cable, and an adapter – two different things to connect between the computer and the Emu board. A better solution is probably to make a new version of my DB19 to IDC20 extension cable, that has the adapter circuit and switch built into it. But that would drive up the cost by a few dollars – so would I continue to sell the old cable as well, or encourage everyone to buy this new, more capable but more expensive cable? If I sold both cables, would I get tons of email from people confused about which one to buy, or upset because they didn’t understand they needed a specific cable to enable specific types of emulation?

There’s another matter too – for most purposes the DB19 and IDC20 connectors are interchangeable, and there’s a standard pin mapping between the two, shown above. But the /DRIVE2 signal on DB19 pin 9 was only ever used in DB19 cables, and there is no standard mapping for it on the IDC20 connector. So how can I even physcially route that signal on a 20-pin ribbon cable? I could substitute it for one of the existing signals I’m not currently using, like one of the +12V supply lines. That would be fine for Floppy Emu and my adapter boards, but someday someone would surely use one of my cables to do something strange, like connect a Disk II to an Apple IIgs. Then they’d get +12V from the Disk II feeding backwards into the computer’s /DRIVE2 output, causing it to burst into flames and burn down their house.

Sometimes I think about things too much. :-)


Apple IIgs ROM 03 Headaches

0
0

Apple_IIgs_002

I’m still chasing an explanation for why some Apple IIgs computers won’t play nicely with Floppy Emu’s new 800K 3.5 inch Apple II disk emulation. I described the symptoms in my previous post – ProDOS and GS/OS disk images boot straight up on my IIgs without problems, and on most other IIgs systems, but for a couple of people it just hangs forever in the READ state on track 0. Both people who reported this have the relatively rare ROM 03 version of the IIgs, so I’m assuming it’s a compatibility problem between ROM 03 and the more common ROM 01. But what’s the problem exactly? And how can I fix it?

The biggest obstacle at the moment is lack of information. I don’t have a ROM 03 machine, and I can’t find one anywhere, so I can’t troubleshoot this myself. I’ve exchanged emails with two ROM 03 owners who are willing to help, but so far I’ve only gotten detailed information from one, and one data point isn’t enough to draw any conclusions. What seems like a compatibility problem might just be a hardware issue with one specific computer or Emu board.

Despite working mostly in the dark while trying to solve this, I have some theories about what might be going wrong.

 
Crazy WRPROT Circuits

There are documented incompatibilties between ROM 03 and some real Apple 5.25 inch floppy drives, although the details are fuzzy and sometimes seem contradictory. According to this section of the Apple 2 wiki, ROM 03 is not compatible with the Apple UniDisk 5.25 or DuoDisk. The explanation seems muddy, with two paragraphs that appear to offer two unrelated explanations, but one of them is related to the circuitry behind the drive’s WRPROT (write protect) signal. This is the signal that indicates whether the disk in the drive has the write-protect notch covered – remember those? According to the wiki, “incompatible drives on these models will just spin at startup.” Sounds a lot like what’s happening with Floppy Emu.

There’s also this Apple Tech Info document about ROM 03 and DuoDisk, with a symptom that sounds similar: “The DuoDisk LED for drive #1 will turn on, but the system will not start.” It doesn’t give an explanation, but mentions that booting from a write-protected disk works normally. Again, something about ROM 03 and write protection.

Check out this partial functional diagram of the Disk II 5.25 drive. Notice anything odd about the write protect signal?

DiskII_Functional_Diagram

There’s a tri-state buffer for the WRPROT output, controlled by the drive’s ENABLE input. Behind that is a pull-up resistor, and the switch that senses the notch in the disk. But instead of ultimately terminating at GND, the write protect circuit is connected to the drive’s PHASE1 input. When the computer sets PHASE1 to 0, it can then read the WRPROT state as 1 = write protected, 0 = not write protected. But if the computer sets PHASE1 to 1, it effectively disables the whole write protect circuit, and WRPROT will always be 1.

My theory is that ROM 03 has some 5.25 inch drive detection code that sets PHASE1 to 1 in order to disable the circuit, and then waits for WRPROT to go to 1. But if the disk drive has its write protect circuit terminated directly to GND instead of PHASE1, it won’t be disabled, so WRPROT will never go to 1 and the computer will wait forever, unless the disk is actually write protected. My hunch is that the DuoDisk is built this way, which explains why it doesn’t work with the ROM 03 IIgs.

 
Floppy Emu’s Identity Crisis

Now what does any of this have to do with Floppy Emu’s 800K 3.5 inch Apple II disk emulation? After all, it’s emulating a 3.5 inch disk, where WRPROT behaves completely differently and this issue presumably isn’t relevant. Remember in my last post, when I described how the current design lacks connections for some enable signals used to distinguish between 3.5 inch and 5.25 inch drives? I had sort of dismissed it as not a problem, but my theory is it’s causing Floppy Emu to be identified as a 3.5 inch drive and a 5.25 inch drive. And when it’s identified as a 5.25 inch drive, WRPROT is not going to respond to PHASE1 in the expected way, which may cause a bootup hang on ROM 03 just like with the DuoDisk. My guess is that ROM 01 sees a misbehaving 5.25 drive and ignores it, but ROM 03 sees a misbehaving 5.25 drive and hangs forever, before ever attempting any 3.5 drive access.

The solution is simple, if annoying – use some external circuitry to handle all the enable signals, so Floppy Emu isn’t accidentally detected as a 5.25 inch drive. My last post sketched out a circuit to do this job, and I’m going to build some PCBs to test it. Meanwhile, using the daisy chain board removed from an AppleDisk 3.5 (A9M0106) floppy drive should accomplish the same thing.

SteveP, one of the ROM 03 owners I’ve been corresponding with, tested this theory. He used the A9M0106′s daisy chain board to connect Floppy Emu to his ROM 03 IIgs. And it worked! Sort of. The computer no longer hung at track 0 while attempting to boot. He was able to boot successfully into ProDOS. And he could begin to boot into GS/OS, but then it would fail with errors like “Unable to load START.GS.OS file. Error=$002E” or “UNABLE TO LOAD PRODOS”. So is there another ROM 03 compatibility issue at work here, or does he just have some flakey hardware or some other unrelated problem? With only this one report to go by, I can’t say, but I’ll keep digging.

Circuit Protection: Economics and Electronics

0
0

XC2C32A-6VQG44I

Remember this problem that I analyzed a year ago, with mysterious damage to the CPLD chip? I still haven’t found a permanent solution. It’s rare enough that it’s not much trouble to just repair or replace affected boards, but it’s annoying, and I’d sure like to fix it if I can. I’m not completely certain what causes it, nor how to fix it, but I have a theory I’m going with. The challenge is that the extra cost of parts and assembly to address the problem may actually be more than the cost of making occasional repairs, creating the awkward result that I would lose money by making things more robust.

This type of BMOW post often gets picked up by Hack-a-Day or Hacker News, spawning an off-site discussion thread about how stupid I am. Please be kind and understand that I’m not a professional, and if you think I’m doing it all wrong, I probably am! Leave your feedback in the comments below, and let me know how I could have done it better.

 
Economics

This is a low-volume hobby product, a disk drive emulator, and it’s designed and built by a single person in his spare time – me. In the past year, I estimate I’ve spent about $500 on hardware repairs and replacements for boards that had CPLD damage. That includes direct costs, as well as the cost of my time. $500 may sound like a lot, but I’ve sold about 300 boards during that time, so the amortized cost is only $1.67 per board. There’s also an intangible cost when a product fails and a customer has to return it – they get annoyed, my reputation suffers, and maybe I lose out on some future sales. That’s not good either. Including those intangibles, let’s say the total cost of this issue is an even $2.00 per board.

Assuming I knew exactly what the problem was and exactly what to change in order to fix it, implementing the change would need to cost less than $2.00 per board. Otherwise I would be spending more to prevent the problem than the damage it caused! It would be like buying Monopoly’s “Get out of Jail Free” card for $60, when getting out of jail normally only costs $50. And what if I wasn’t certain the proposed change would fix the problem? Then the cost of the change would have to be even less than $2.00, in order to compensate for this uncertainty. Maybe $1.50 or less, depending on how confident I was in the solution.

The reality is that implementing a change for less than $1.50 or $2.00 may not be easy. I suspect the problem is related to over-voltage on the 12 CPLD I/Os, and if I use a resistor or buffer on each input, it will require a minimum of 24 extra pins/pads on the board. The board assembly cost is around $0.05 per pin, so that’s already $1.20 right there, without even considering the cost of the parts themselves or any other extras. Add in the cost of the new parts, and adjust for any uncertainty in the solution, and the total costs might outweight the benefits. D’oh!

 
Electronics

If you haven’t already, check out last year’s post, especially the many excellent comments from readers. Based on that discussion, and my observations since then, I think last year’s over-voltage input theory is probably correct.

In the normal setup, the CPLD chip on the board is connected via a 3 foot cable to a vintage Macintosh. The Mac has 5V outputs. The CPLD has a 3.3V supply, with 5V tolerant inputs. In normal usage everything is fine, but I suspect there are occasional transients that cause a problem. From the CPLD datasheet: “The 3.3V VCCINT power supply must be at least 1.5V before 5V signals are applied to the I/Os.” In other words, the 5V tolerance of the CPLD’s inputs disappears if the CPLD’s supply voltage is under 1.5V. Could this be happening? What problem would that cause?

The board is powered indirectly from the Mac’s 5V supply, delivered by that 3 foot cable. When it’s first powered on, a 3.3V regulator on the board begins to work, and eventually it will raise the CPLD’s supply voltage to 3.3V. But what happens if the Mac applies 5V I/O signals before the CPLD’s supply voltage has risen above the critical 1.5V threshold mentioned in the datasheet? This might happen at initial power on, if the 3.3V supply is slow to ramp up. It would be even more likely to happen if the board were “hot plugged” while the Mac was already turned on. Or a similar issue might occur long after power-up, if something caused the 3.3V supply to droop back down below 1.5V while 5V I/Os were applied. This might happen during power-down, or because an SD card was hot-swapped in the board, causing a large inrush current to briefly overwhelm the 3.3V supply. In any of these examples, 5V would be applied to the CPLD inputs during a time when they were not 5V tolerant.

What problems might this over-voltage cause? The most likely result is damage to the ESD protection diodes. Most modern chips have some kind of protection circuitry at each pin, to guard against static electricity or a brief voltage overshoot. The exact design of this protection circuitry normally isn’t specified, but the typical example looks like this:

IC_Input-1

image from raspberrypi.org

In a typical chip, both protection diodes probably have a standard 0.6V drop. If the input goes below -0.6V, the bottom diode will begin to conduct, clamping the input voltage and preventing it from going any lower. If the input goes above VCC + 0.6V, then the top diode will begin to conduct, similarly preventing the input voltage from going any higher. When either diode conducts, a large amount of current may flow through the diode, depending on the resistance of the digital input line, and the output impedance of whatever’s driving it. I’ve failed to find any specifics on the CPLD’s diodes, but it seems they’re normally designed to tolerate very high voltages and currents, but only for a very brief time – like a few nanoseconds. Try to pass even a modest DC current through the diodes, like a few milliamps, and they may burn out.

In the case of this CPLD with its 5V tolerant inputs, I’m guessing the top diode actually has a drop of 2.2V instead of 0.6V (or it’s a few diodes in series with a 2.2V total drop). So under normal operation with a 3.3V supply for VCC, that diode wouldn’t begin to conduct until the input voltage exceeds the CPLD’s maximum rating of 5.5V. But despite the difference in voltage drop, the theory should be the same as with a standard ESD diode.

What’s going to happen if VCC is actually much lower than 3.3V, or zero? Then the diode will begin to conduct when the input voltage exceeds 2.2V, and it will keep conducting as long as this condition persists, or until it burns out. So how much current can the diodes tolerate, and for how long? I don’t know, and haven’t been able to find any straight answers, but I’ve seen estimates between 0.1 mA and 50 mA for max ESD diode current, with potential damage from transients that exceed that level for as short as a few milliseconds or even microseconds.

I don’t have any hard data to prove this theory, but it’s consistent with the observations I’ve made and with behavior reported by other people using the same CPLD in other applications. So until a better theory comes along, I’ll assume the problem is blown ESD protection diodes.

 
Possible Solutions

There are 12 I/O lines between the Mac and the CPLD. 10 of these are CPLD inputs: 5V signals from the Mac connected to the CPLD’s 5V tolerant inputs. One is a CPLD output: a 3.3V signal that’s still high enough to exceed the Mac’s 5V Vih threshold for a logical “1″ value. The last can be an input or an output, depending on which kind of disk drive is being emulated. So I need a solution that ameliorates or prevents an over-voltage situation on 11 input pins, while also enabling one of those pins to be used as an output sometimes.

Inline Resistors – The simplest and cheapest solution is to add inline resistors in the signal paths of all 12 signals. Under normal operation, the inputs draw negligible current, so there will be negligible voltage drop across those resistors and the function of the circuit will be unaffected. But in an over-voltage situation where the CPLD’s VCC supply is too low and the ESD diode begins to conduct, the resistor will limit the current to a level that’s safe for the diode.

IC_Input

image from raspberrypi.org

The tricky bit is choosing what resistor value to use. There’s some parasitic capacitance on the cable, the board trace, and the CPLD input itself, and this capacitance combined with an inline resistor forms a classic RC circuit. The input voltage will no longer be able to change as rapidly before, rounding the corners of signal edges, and reducing the maximum signal switching rate that’s possible. So too high of a value for the resistor is bad. Fortunately the disk drive signals are comparatively slow, in the 1 or 2 MHz range at most. I estimate I could use a resistor as large as maybe 3.3K ohms before this RC filtering affect would cause problems, but I may be way off.

But wait! The resistor also needs to protect the ESD diode by limiting the current, and too low a value for the resistor will be ineffective. The minimum resistor size depends on the characteristics of the ESD diode, which are unknown. Let’s assume it has a 2.2V drop, and can tolerate 1 mA max. With a 5V input and the diode terminated to ground, that would leave 2.8V across the resistor, so a 2.8K ohm or larger resistor would be needed in order to limit the current to 1 mA.

Would this solution work? Probably, and it would only cost about $0.12 on top of the ~$1.20 assembly cost. But the overlap of resistor values is uncomfortably narrow between “too high for the circuit to work” and “too low to offer any protection”. And the values themselves are based partly on guesswork rather than any hard numbers from a datasheet. Some people feel that relying on the ESD diodes in any way is bad form, and the absence of real specs for the diodes is one reason why. Anyone with experience who might suggest an appropriate resistor value here that would satisfy both requirements – I’d love to hear from you.

Resistors with External Diodes – What about implementing my own over-voltage solution, external from the CPLD, with an inline resistor and a diode up to 3.3V for each signal? This would essentially do the same thing as the ESD diode, but with a beefier diode capable of handling more current, and for which I would know the actual specs. With a beefier diode, I could also get away with a smaller inline resistor, so the RC filtering effects would be reduced.

Standard silicon diodes with a 0.6V drop probably wouldn’t work. When the CPLD’s power supply is below the magic 1.5V threshold, its inputs aren’t 5V tolerant, but it’s not specified exactly what voltage is safe in this situation. If we assume 3.6V is the highest safe voltage, then the diode would need a voltage drop less than 0.3V.

The biggest problem with this approach is the number of parts required, and resulting cost. With a separate resistor and diode on all 12 signal lines, that would be 4 new pins/pads per signal line, or 48 new pins total. The assembly cost alone would be almost $2.00, without even considering the cost of diodes, pushing this solution to the point where it would cost more to implement than it would save. Maybe there’s some kind of single-chip ESD circuit solution I could use, that has a bunch of appropriate resistors and clamp diodes built into it? That might help bring the pin count down to a more manageable level.

Voltage Dividers – Another approach is to use a pair of resistors in series for each signal line to form a voltage divider. Something like this:

0J1423.1200

image from pololu.com

As long as the resistor values were in the proper ratio, and the 3.3V input itself drew minimal current, this would work OK as a level converter. It would prevent 5V signals from ever reaching the CPLD. The downside of a voltage divider is that when the 5V input is high, there’s current constantly flowing to ground. The IWM chip in the Mac is only able to source a paltry 0.32 mA for a high-level output, and to limit the current to that level, the combined resistance of the two resistors would have to be at least 15.6K ohms. That’s an awfully large resistance, and would probably create the types of unwanted RC filtering effects I feared would interfere with normal circuit operation. Using voltage dividers would also double the total number of components required for circuit protection, relative to inline resistors.

Level Shifter – The last solution I’m considering is a few level shifter chips. Any kind of chip would do, as long as it had non-inverting buffer outputs at 3.3V, with fully 5V-tolerant inputs. Candidates are the 74LVC244, or the 4050B. This would prevent any signal voltage above 3.3V from ever reaching the CPLD. With one input and one output pin per I/O signal, the number of pins and the assembly cost should be about the same as with passive resistors. A quick look at the 4050B shows I could buy a pair of them, enough to buffer 12 signals, for about $0.35 in quantity. That might work.

The problem with using level shifters is that they’re unidirectional. What about that one signal that’s either an input or an output, depending on the type of disk drive being emulated? This solution wouldn’t work for that, so I would need some additional bidirectional protection circuitry just for that one signal. I’m not sure what that might be or how complex it would become.

The other drawback of using level shifting chips is that they’re comparatively big, and it might be difficult to find space for them on the board without relocating everything and re-routing the whole thing from scratch. Resistors and diodes, even in multi-element packages, tend to be smaller and easier to squeeze into tight spaces.

 
Suggestions?

Have I analyzed the economics or the electronics wrong? Any other good solutions that I overlooked? Please leave your suggestions in the comments.

ROM 03 Revisited

0
0

20150425_154032_Richtone(HDR)_resized

Good news, Apple II fans! The Apple IIgs ROM 03 mystery has been solved. A few weeks ago I added new support to Floppy Emu, for emulation of 3.5 inch Apple II disks. I used it to boot my Apple IIgs with GS/OS… fun. Then I started hearing from other IIgs owners for whom the new firmware didn’t work, but I couldn’t understand why… not fun. The issue seemed related to differences between IIgs version ROM 01 and ROM 03, but I wasn’t sure what was going on or how to fix it. This prompted the post Apple IIgs ROM 03 Headaches. Now, after a lot of head scratching, I think I’ve finally got it figured out.

A huge “thank you” goes to Steve Palm, who did an extraordinary amount of testing under different conditions with his ROM 03 machine, and to Jason Galarneau, who loaned me a ROM 03 machine to experiment with directly. What I learned was that the ROM 03 problem is caused by incomplete decoding of the disk drive enable signals, causing the Emu to respond at inappropriate times. I had actually diagnosed the problem correctly in this earlier post, and I even provided a potential solution there, but I somehow convinced myself this wasn’t the ROM 03 problem, or wasn’t the main problem. Wrong!

On a Macintosh floppy port, there’s a single active low signal called /ENABLE that tells the drive when to wake up. The earliest Apple II 5.25 inch drives worked the same way. But Apple later complicated things in order to support daisy chained disk drives, and chains containing multiple different types of drives, to where on an Apple IIgs the floppy port has three different enable signals: /DRIVE1, /DRIVE2, and /EN3.5. Floppy Emu was only listening to /DRIVE1, and wasn’t even connected to the other signals. The difficulties are described in much more detail in the earlier post, so I won’t repeat them here.

The final step was to build a prototype of the external adapter described in the earlier post. Since the Emu board lacks connections for /DRIVE2 and /EN3.5, the external adapter is responsible for decoding those signals along with /DRIVE1, and passing the result to Floppy Emu as a single /ENABLE signal. And what do you know, it works! No more ROM 03 problems, and no more limitations on where the Emu can appear in the disk daisy chain.

The adapter prototype also includes a couple of resistors not shown in the diagram. There’s a 10K pull-up resistor for /DRIVE2, because that signal isn’t connected on a Mac or Lisa. And there’s a 470 ohm series resistor on WRPROT, which is the only signal that changes direction between the Mac/Lisa and Apple II firmwares. No more worries about possibly damaging something if you accidentally use the Apple II firmware while connected to a Mac.

EPSON MFP image

 
A Universal Apple Adapter for Floppy Emu

The original name I gave the adapter is misleading – it’s not an adapter for the Apple II, it’s an adapter for everything including the Apple II! There’s a photo of the adapter prototype at the top of this post, with the current do-nothing adapter also pictured for comparison. The new universal adapter has a switch on it. Set it to “3.5″ if you want to emulate an Apple Disk 3.5 for Apple II, or set it to “OFF” if you want to emulate any other type of Apple II, Mac, or Lisa disk.

There’s potential for confusion with this new universal adapter, so I’m trying to choose names and terminology carefully. The adapter is only REQUIRED in a few specific circumstances, but it’s COMPATIBLE with all circumstances, so you can just plug it in and leave it there. Macintosh computers and the Lisa don’t need the adapter, and you can also boot an Apple IIgs ROM 01 machine from the Emu without the adapter. And when Apple II 5.25 inch and SmartPort disk emulation is ready, those shouldn’t need the adapter either. But for 3.5 inch emulation on a IIgs ROM 03 machine, or 3.5 inch emulation on a IIgs ROM 01 machine where the Emu is not the boot disk, this adapter is just what the doctor ordered.

So what’s next? I hope to have some of these adapters available for sale shortly. They’ll be offered as an alternative to the existing “convertible extension cable”, for a few dollars more. People who expect to use Apple II 3.5 inch disk emulation (mainly IIgs owners) along with other emulation modes can use the new cable, while people who don’t care about Apple II 3.5 inch disk emulation can stick with the current cable. Longer term, I hope to build the functionality of the universal adapter into a new Floppy Emu, but that won’t be any time soon.

Crazy idea: with other external adapter boards like this one, with a different external connector, it might be possible to develop Floppy Emu disk emulation firmware for completely different computer platforms. Atari disk emulation, anybody? Amiga? They all operate on the same basic principles as the existing Floppy Emu disk emulation. Yes, there are many differences in the details, but the more emulation modes I implement the better I’m getting at abstracting the drive-specific parts from the shared functionality. Maybe someday…

5.25 Inch Disk Kickoff

0
0

20150430_172935_resized

I’ve started working on Apple II 5.25 inch disk emulation for Floppy Emu. It’s still early, and it’s progressing more slowly than I expected, but I think it’ll work. It will be great to have a new mode to emulate the zillions of 5.25 inch Apple II disks out there. I’ve been using the IIgs for my testing, but it should work on any Apple II series machine. No adapters needed either – just plug in the Emu board and go.

The first step was to convince the computer that there was even a 5.25 inch drive connected. That took more effort than I expected, because the 5.25 drive doesn’t have any way of directly telling the computer “I’m here”. After some trial and error, I discovered that the computer just blindly turns on the drive motor and starts reading from it. If it gets valid data or garbage data, either way it knows there’s a drive attached, but if it gets no data at all then it assumes no drive is present. I had assumed an empty drive would send no data, but some investigations with a logic analyzer proved that theory wrong. To make Floppy Emu be detected as an installed drive, I had to change the firmware to send a constant stream of sync bytes even when there’s no disk inserted.

Stepping the drive head to the correct track proved to be a major hassle. The Apple II directly controls a 4-phase stepper motor in the 5.25 disk drive, activating each coil in the correct sequence to move the stepper in or out. I modified the firmware to monitor these control signals, and simulate what would happen to a real stepper motor. This was more difficult than it might sound, because the control signals can be driven in various ways to produce half steps, full steps, or weird combinations of inputs that don’t do anything well-defined. Fortunately I think I’ve got it working now.

Speaking of the stepper controls, I hooked up my logic analyzer to the disk interface signals so I could see what was going on. For all the years I’ve been working on floppy emulation, I can’t believe I’ve never done this before! I normally rely on indirect methods of observation, from the computer or the Emu, and haven’t had a direct window onto the actual disk signals.

diskii-mount

The waveform above shows the characteristic chukka-chukka-chukka of an Apple II 5.25 inch drive when the computer recalibrates the track position. During the first section, the phase lines are repeatedly activated one at a time in order, from lowest to highest, which moves the drive head outwards. Then there’s a pause, followed by a second section where the phase lines are activated from highest to lowest, which moves the drive head inward. Eventually the head hits a mechanical stop at track 0, making the familiar rattling sound of a 5.25 inch floppy drive.

For comparison, the waveform below shows what happens on the IIgs, just a brief moment after the power is turned on. Note that the time scale is much smaller, and the phase lines aren’t driven in sequence, but instead each one has an independent behavior. I believe this is the IIgs asking “Hello, are you a SmartPort hard disk? No? OK then.” I’ll find out more when I look further into SmartPort HD emulation.

diskii-startup

Copy II Plus, an Apple II disk copy program, has some very nice sector and track diagnostic tools built in. Using these I was able to verify that my track stepping logic is working. I was also able to capture a raw dump of an entire track, showing all the bytes straight off the disk (or the Emu), without any kind of post-processing to try to identify where the sectors are. This will be incredibly valuable as I start to work on actually sending the correct disk data.

In the image below, you can see that it’s already sort of working. This shows a Copy II Plus dump of track 0 of an emulated 5.25 inch disk from Floppy Emu. The data itself is actually from a Macintosh disk, with Macintosh style sector headers, so that part obviously isn’t right. But what’s encouraging is that the raw data is being received correctly by the Apple II – I circled the familiar D5 AA 96 that marks the start of a sector, and D5 AA AD that marks the start of the sector’s data payload.

20150430_174014_resized

Unfortunately, some of the data is received incorrectly. The screenshot shows an example that mostly worked, but in many cases, parts of the sector are garbled. The data payload shown above should have contained hundreds of “96″ bytes after the D5 AA AD, but it only has 23 of them before something goes wrong. Even the highlighted “FF” sync bytes before the data payload are wrong: some of them show “AA” and other incorrect values. Maybe the bit rate is slightly off? Bad voltage levels? Microcontroller interrupts messing with the bit timing? I’ll figure it out eventually.

Floppy Emu Has Cholera

0
0

20150507_095207_Richtone(HDR)_resized copy

Achievement unlocked! 5.25 inch 140K disk emulation for Apple II is now working for Floppy Emu. I booted up my Apple IIe with an Oregon Trail disk image, lost some oxen, got cholera, and died. The 5.25 inch disk emulation has been tested on a IIgs with the built-in floppy port, on a IIe with the 19-pin Disk 5.25 controller card, and on a IIe with the classic Disk II controller card. Awesome!

This brings the total number of disk formats that Floppy Emu can emulate to eight: Mac 400K, Mac 800K, Mac 1.44MB, Mac hard drive (HD20 compatible), Lisa 400K, Lisa 800K, Apple II 800K (3.5 inch), and Apple II 140K (5.25 inch).

These are early days for the 5.25 inch Apple II disk emulation, so I won’t be posting the new firmware quite yet. There are still a number of issues remaining that I hope to resolve soon. The big one is write support: the current firmware doesn’t yet implement 5.25 inch write emulation, so disks are read-only. The disk image format support also isn’t complete, and raw DOS 3.3 order images (.do files) are the only format that works. I expect to add ProDOS order (.po files) and 140K 2MG images soon – or is 2MG only used for 800K disk images? I’ll have to check.

In my previous post, I mentioned that the raw disk bytes weren’t always being received correctly by the Apple II. It turned out that the width of my “1″ pulse was too narrow, and sometimes a 1 would be detected as a 0. Data arrives from the disk at a rate of 4 microseconds per bit, where a logical 0 is sent as 4 microseconds of 0 volts, and a logical 1 is sent as a short pulse to 5V and back within a 4 microsecond window that’s otherwise 0 volts. Initially the width of my pulse was 0.25 microseconds. When I widened it to 0.75 microseconds, it started working reliably. That’s curious – is the disk controller actually doing polling, instead of edge triggering? Why didn’t the narrower pulse work?

It was a headache getting the checksum algorithm working correctly. The checksum is described in the book Beneath Apple DOS, but even after re-reading it several times, I was still confused. The algorithm is tightly coupled to the method the Apple II uses to read and write disk data, where it performs a process called “pre-nibbilization” before writing each sector, separating the upper and lower bits of each data byte and storing them in two different buffers. Floppy Emu works differently, performing nibbilization on the fly, so it was somewhat awkward to transmit data and checksums the same way.

 
Interleave and Sector Ordering

The other question that I struggled with was sector ordering. If you’ve been around the Apple II emulation world for a while, you’ve probably heard the terms “DOS order” and “ProDOS order” when referring to disk images. You may have also seen some discussion of sector interleaving within a track. The meaning of these terms and the interplay between them took me quite a while to understand.

Some background: each sector on the disk is prefaced with a sector header. The header is not part of the sector itself, and doesn’t count as “data” when you’re totalling up how much data a disk contains. A crucial piece of information contained in the header is the sector number, used by the operating system to identify which sector is which. Typically the sectors aren’t actually stored consecutively on the floppy disk, but are interleaved. A Macintosh 800K floppy track has the sectors interleaved like this:

0 6 1 7 2 8 3 9 4 10 5 11

This is a performance optimization. The floppy disk is always spinning, and without interleaving, a vintage computer would be too slow to finish processing the data from sector 0 before sector 1 spun under the head. By the time it was ready to begin reading sector 1, that sector would have already spun past, so the computer would have to wait for it to spin all the way around again. By staggering the sectors on the floppy disk, the computer gains some extra breathing room and avoids needing a full rotation for the next sector.

Things begin to get confusing when we talk about physical sectors vs logical sectors. Physical sector numbers are the numbers contained in the sector headers on the disk. Logical sector numbers are determined by the OS, and define the data contained in each sector. If you stored a large text file on a floppy disk, the first few sentences would be stored in logical sector 0, the next few in logical sector 1, then logical sector 2, etc.

On the Mac, physical and logical sector numbers are the same. The sector number in the sector header is the same as the number assigned by the Mac OS. If we use A[B] to describe a sector whose sector header number is A and whose data contents are the operating system’s sector number B, then the Mac has a 1:1 relationship:

0[0] 6[6] 1[1] 7[7] 2[2] 8[8] 3[3] 9[9] 4[4] 10[10] 5[5] 11[11]

The Apple II handles interleaving differently. Physical sector numbers aren’t interleaved, and instead they’re just numbered consecutively 1 to N along the track. But the operating system uses so-called “software skewing”, where logical sector N is not necessarily stored in physical sector N. For DOS 3.3, the relationship looks like this:

0[0] 1[7] 2[15] 3[6] 4[14] 5[5] 6[12] 7[4] 8[11] 9[3] 10[10] 11[2] 12[9] 13[1] 14[8] 15[15]

So when a DOS 3.3 Apple II program wants sector 4, it actually fetches physical sector 7 from the floppy disk. For all practical purposes, physical sector 7 is sector 4. My head hurts already.

With ProDOS, logical data is stored in 512 byte blocks instead of 256 byte sectors. Each 512 byte ProDOS block N is stored in two separate 256 byte physical sectors, NA and NB:

0[0A] 1[4A] 2[0B] 3[4B] 4[1A] 5[5A] 6[1B] 7[5B] 8[2A] 9[6A] 10[2B] 11[6B] 12[3A] 13[7A] 14[3B] 15[7B]

Confused yet? A DOS ordered disk image is one in which the physical sectors are stored in ascending order by DOS 3.3 logical sector number. A ProDOS ordered disk image is one in which the physical sectors are stored in ascending order by ProDOS logical block number. While the two orderings are obviously derived from the two different operating systems, they are ultimately just arbitrary ways of grouping data into 256 byte chunks. DOS 3.3 software can be stored in ProDOS ordered disk images, and vice-versa.

20150507_111136_resized copy 20150507_111003_resized copy

5.25 Inch Disk Firmware

0
0

525-disk

The updated Apple II firmware for Floppy Emu is now available! This update adds 5.25 inch 140K disk image support, and is compatible with any Apple II model, using the standard Floppy Emu hardware. Download apple-II-0.1C-F3 and try it out! I also included a few sample disk images, so you can be running Oregon Trail and a few other classics right away. The firmware supports standard Apple II 140K disk images in .PO, .DO, .DSK, .NIB, or .2MG formats, as well as Apple II 800K (3.5 inch) disk images in .2MG or Disk Copy 4.2 formats. Press the SELECT button from the Emu title screen to switch between 5.25 inch and 3.5 inch disk emulation modes.

Some important notes:

  • I’m having difficulty with 5.25 inch disk write emulation, so this firmware treats 5.25 disk images as read-only. I hope to add full read/write support for 5.25 inch disks in another firmware release soon.

  • The Floppy Emu board can be connected directly to the 19-pin floppy connector on the Apple IIgs or Apple IIc. For the Apple II, II+, and IIe, the Emu board should be connected to your disk controller card: either the Disk 5.25 Controller Card with 19-pin connector, or the classic Disk II Controller Card with two 20-pin connectors. If using the Disk II Controller Card, be careful to orient the cable correctly, since the card’s connector is not keyed and 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 Disk II Controller Card.

  • This firmware includes support for 5.25 inch and 3.5 inch Apple II disk emulation. 5.25 inch disk emulation works on a stock Emu board, and does not require any adapter. Full emulation of 3.5 inch disks requires an adapter board that I plan to release soon. Without the adapter board, 3.5 inch disk emulation works on a ROM 01 Apple IIgs when booting from the Floppy Emu, but not on a ROM 03 IIgs or when the Emu is not the boot disk.

  • 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 could cause damage.

 
NIB Images

This firmware introduces support for NIB images, which contain the raw disk bytes stored on a physical floppy disk, instead of the high-level sector data contained in other types of disk images. With NIB images it’s possible to store and emulate many types of copy-protected disks, including disks with non-standard sector headers, custom sector sizes and encoding, and all sorts of other crazy schemes. This is important for the Apple II world, because the use of disk-based copy protection was common among Apple II software. A disk emulator that didn’t support NIB would be limited to only using “cracked” versions of the software in which the copy protection had been removed.

Implementing robust NIB support is challenging. I’m not sure if other Apple II disk emulators also support NIB format, but at least one that I checked does not, so I’m happy that I was able to make it work for Floppy Emu. After digging into the details, I can understand why some designers may have chosen to skip NIB. The NIB format represents a track as 6656 disk bytes, but this is insufficient to represent the full structure of a real floppy disk track. On a real floppy, most disk bytes contain 8 bits, but some disk bytes called sync bytes are actually 10 bits long. Of course a 10-bit quantity isn’t a true byte, but the term “sync byte” is used regardless. The sync bytes are FF (hex) followed by two zero bits, so in binary they look like 1111111100. The problem is that sync bytes are stored in the NIB file as plain 8-bit FF bytes, and the knowledge that a particular FF is a sync byte instead of a standard FF data byte is lost.

I believe the NIB format was developed mainly for use with PC-based Apple II emulators, and not for use with real Apple II hardware. While I’ve never investigated how emulators like AppleWin are designed, I would guess it’s impossible for the emulated disk controller to get out of sync with the emulated disk, so the absence of proper sync bytes in the NIB data is unimportant. But when running on real Apple II hardware, such as with the latest Floppy Emu firmware, the absence of sync bytes is fatal. To solve this problem, I’ve designed the firmware to make an educated guess as to which FF bytes in the NIB are actually sync bytes, and which are just plain data bytes. In practice, this seems to work great most of the time, but copy protection schemes are often designed to intentionally thwart exactly this kind of analysis. In my tests, all the copy-protected NIB images that I tried worked, save for one intermittent problem with Moon Patrol on the Apple IIgs. Yet the Moon Patrol NIB worked fine on my Apple IIe, so maybe it’s some kind of IIgs incompatibility rather than a NIB issue.

 
Write Support

Support for writing to emulated 5.25 inch disks has proven to be much more troublesome than I’d expected. Single-sector writes appear to be working fine: I can use a sector editor tool to view and modify individual sectors on the emulated disk, and the data gets modified correctly. That means there aren’t any low-level problems involving timing or checksums, which is great. Yet when I try a higher-level write operation, such as copying a file, everything blows up. The exact nature of “blows up” is hard to identify – if I could explain it, I could probably understand how to fix it. In practice it means that the software complains about “write error”, or the Emu displays a buffering-related error.

On the Macintosh, all floppy disk write operations are verified by reading back the newly-written data, unless verification is explicitly disabled. From the point of view of a disk emulator designer, that’s a very nice feature, because any mistakes that occur during writing are caught and reported right away. But for Apple II software, verification of writes doesn’t appear to be the norm. At least in the GS/OS Finder, you can duplicate a file on a floppy disk, and GS/OS will show that everything succeeded regardless of what was actually written to the disk. If there was a problem, you’ll only find out about it later when you try to use the new file.

A second wrinkle is that some Apple II copy software like Copy II+ does something more akin to a single-track format operation than a standard write. The sectors on a disk consist of an address header followed by a data chunk. Normally the address headers are written once when the disk is formatted, and then never touched again – only the data chunks are modified. My experiments show that Copy II+ violates this rule, though, and writes new address headers. Floppy Emu isn’t designed to handle this, so the write operation fails. This isn’t an Apple II issue, but is also true of the Mac and Lisa firmware, and has been the case since the earliest days of Floppy Emu. There may be a way to configure Copy II+ so it doesn’t rewrite the address headers, but if so I haven’t found it yet.

I found more unexpected results when snooping on ProDOS disk writes. ProDOS works in units of 512 byte blocks, which are stored as two separate 256 byte sectors on the floppy disk. Every ProDOS write should therefore look like two successive sector writes, to two different physical sectors. But what I observed was that the same physical sector was written twice in a row. This must be a bug somewhere in my layers and layers of abstractions, but I haven’t been able to locate it. Or maybe the way I’m tracking the write activity is flawed.

In short, write support is a pain. I can see when something went wrong by observing error messages, but I only have a limited ability to look inside and examine each step of the write process to find the cause. I may need to invest some time in creating better debugging tools, before I can get to the bottom of it all.

 
Feedback

As always, I welcome your feedback. If you’ve tried this new 5.25 inch disk emulation on your Apple II system, leave me a note in the comments! Even if you have nothing to say beyond “works on my IIc”, that’s still helpful to know. Thanks!

5.25 Inch Disk Write Support

0
0

EPSON MFP image

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!


Missing Pull-up, Sad Trombone

0
0

wrreq-pullup

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.

Apple II Firmware and Mods

0
0

apple-iie

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.

 
Hardware Connections

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.

 
Hardware Mods

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:

disk35-adapter

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.

 
DIY

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:

pullup-mod-top

pullup-mod-bottom

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!

Smartport Hard Drives for Apple II

0
0

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.

Apple II Hard Disk Emulation

0
0

20150611_095827_resized

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…

20150611_095903_resized

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.

 
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.

Smartport Firmware Release

0
0

20150619_122211_resized

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:

20150619_122331_resized

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).

20150619_113449_resized

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.

20150425_154032_RichtoneHDR_resized

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!

2 GB Smartport Hard Drive for Apple IIGS

0
0

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. :-)

20150702_112447_resized

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!

Floppy Emu – Apple II Demo Video

0
0

11 minutes of unrehearsed video showing off the new Apple II firmware features of Floppy Emu. And you get to see what a mess my desk is.


Smartport Firmware Update

0
0

I’ve posted a new version of the Apple II firmware for Floppy Emu, that addresses some issues with Smartport hard disk emulation on the Apple IIc and IIc+:

  • Fixed a display bug with ProDOS disk names on the LCD
  • All Smartport disks should now be detected during the first cold boot – no warm restart necessary
  • Apple IIc+ can now use the internal 3.5 inch floppy drive simultaneously with external emulated Smartport disks

You can download the new firmware here: apple-II-0.1J3-F6

On the Apple IIc and IIGS, you can have up to four Smartport disks, which will appear as slot 5 drives 1 and 2, and slot 2 drives 1 and 2. On the Apple IIc+, slot 5 drive 1 is the internal 3.5 inch drive, and the computer is limited to using at most three Smartport disks.

New Product: Universal Adapter Extension Cable

0
0

universal-adapter-with-cable-large

Today I’m announcing the Universal Adapter for Floppy Emu, which improves the emulation behavior with certain Apple II system configurations. If you use the Emu exclusively with Macintosh and Lisa computers, then you won’t need this. Apple II users, check the table below to see if your intended usage would benefit from the Universal Adapter:

Emulation Type Standard Adapter Universal Adapter
Macintosh
   3 1/2 inch floppy disk ok-green ok-green
   HD20 hard disk ok-green ok-green
Lisa
   3 1/2 inch floppy disk ok-green ok-green
Apple II, II+, IIe
   5 1/4 inch floppy disk 1437100947_ko-red [1] ok-green
Apple IIc
   5 1/4 inch floppy disk ok-green ok-green
   Smartport hard disk ok-green ok-green
Apple IIc+, IIgs
   5 1/4 inch floppy disk ok-green ok-green
   3 1/2 inch floppy disk 1437100947_ko-red [2] ok-green
   Smartport hard disk ok-green ok-green

[1] Reading the disk works, but writing does not
[2] Apple IIgs with ROM 01 can boot from a 3 1/2 inch disk


The Universal Adapter also contains a protection resistor to guard against accidental damage when switching between the Floppy Emu firmware for Apple II and the firmware for Mac/Lisa. With the Standard Adapter, if a Floppy Emu board running the Apple II firmware is accidentally plugged in to a Mac or Lisa, it could damage the Emu or the computer.

To use the Universal Adapter, set its slide switch to the appropriate position, depending on the selected emulation mode of the Floppy Emu. If the Emu is set to 3 1/2 inch floppy disk mode, then set the switch to the “3.5” position. If the Emu is set to any another mode (5 1/4 inch floppy, HD20 hard disk, Smartport hard disk), then set the switch to the “other” position. Setting the switch to the wrong position won’t harm anything, but it may cause disk-related errors.

universal-adapter-alone

So how does the Universal Adapter work, and how does it differ from the Standard Adapter? The Standard Adapter is a passive device that maps the 19 pins of a male DB-19 connector to the 20 pins of a male 10×2 shrouded header. It rearranges the order of the signals on the pins, but it doesn’t alter them or affect them in any way. In contrast, the Universal Adapter is an active device with an on-board IC that helps with Apple II disk connections. Because the Floppy Emu hardware was originally designed for the Macintosh, it can’t handle some Apple II disk signals correctly, so the Universal Adapter does the necessary interface work. Depending on the switch setting, the disk drive enable signal from the computer may be modified before it’s passed on to the Floppy Emu, and some signals will be forced to different voltages.

It’s OK to use the Universal Adapter with a Mac or Lisa computer, even though it’s not needed for those systems – that’s why it’s called “universal”. People who use a single Floppy Emu board with both Mac and Apple II computers may find this convenient.

The Universal Adapter is available for sale now at the Floppy Emu product page. It includes a detachable three foot extension cable (about 1 meter), just like the Standard Adapter/Cable, and it’s available by itself or bundled with a new Floppy Emu board.

GS/OS 6.0.2 for Floppy Emu

0
0

welcometo602

If you follow the Apple II world, then you probably already know that a group of hobbyists recently released GS/OS 6.0.2 – a new version of the Apple IIGS operating system based upon Apple’s last official version from 1993. This new version includes many bug fixes and added features.

To make life easier for Floppy Emu owners, I’ve created this pre-configured GS/OS 6.0.2 hard disk image. It’s a 32 MB ProDOS disk image with GS/OS 6.0.2 already installed and ready to go. If your Floppy Emu has the Apple II firmware installed and is set for Smartport mode, then all you need to do is copy the smart0.po file onto your SD card, and power up your IIGS to begin exploring 6.0.2. Even if you don’t have a Floppy Emu, this disk image should also work with other Apple II hard disk emulators – it’s just a generic ProDOS disk image.

Some software-based Apple IIGS emulators like Sweet16 don’t like ProDOS disk images that are larger than 800K. For those, I’ve also created a pre-configured GS/OS 6.0.2 hard disk image in 2MG format. This 2MG disk image will also work with Floppy Emu, but I/O performance will be worse than with the PO disk image, so the PO version is preferred.

Oops! Laser Cut Material Thickness

0
0

emu-case-parts

Manufacturing is hard. The thickness of my supplier’s clear acrylic material has magically increased 15%, meaning that the latest batch of Floppy Emu acrylic cases are impossible to assemble. The buttons and light pipes don’t fit in the cut-outs made for them, so this entire batch of product will have to be thrown out. I’m hoping the supplier will agree to re-run my order or provide a refund, but I’m not optimistic since 15% is just within their stated tolerance. An expensive mistake in manufacturing for me!

For the past year, I’ve been offering laser-cut case enclosures as a Floppy Emu accessory, and I’ve sold hundreds of the cases to happy customers. They’re made from 3.0 mm (nominal) clear acrylic. With all of my past orders from the laser cutter, the parts I received had an actual thickness between 2.73 mm and 2.83 mm, and my design accounts for that. A case assembled from the old ~2.75 mm thick material looks like this:

emu-case-assembled

I just received a new delivery of parts yesterday, and the material thickness changed to 3.15 mm! Imagine if you were building a house with 8 foot ceilings, but some of the framing lumber was over 9 feet – it would never work. That’s the same magnitude of change I’m facing now. The buttons and light pipes are cut from the same material as the case body, so now they’re 3.15 mm thick. But the cut-outs in the top of the case are only about 3.05 mm, and the parts won’t fit through. It’s still possible to assemble the six sides of the case, but without the buttons and light pipes it’s useless.

The supplier’s material thickness is rated at +/- 15%, so this is really my fault and not theirs. But +/- 15% is a huge margin. How am I supposed to make that work? If I make cut-outs big enough to accept 3.45 mm (+15%) thick buttons, but the actual material thickness in a future delivery is 2.55 mm (-15%), it’ll be so loose that buttons will just fall out. There’s no way I can see to accommodate a thickness tolerance that large.

Some of you may be thinking that I should never have made a design that relied on the material thickness as a critical parameter, and you’re right. But again, I’m not sure how I could have avoided it – any design where two parts meet at right angles with a tab-and-slot system will suffer from the same problem. For now, I’m faced with either re-cutting all the buttons and light pipes using thinner material if I can find some, or re-cutting all the case tops using bigger cut-outs.

Introducing Floppy Emu Model B

0
0

model-b-750

Today I’m excited to introduce the first significant update to the Floppy Emu disk emulator for Apple II and classic Macintosh computers: Floppy Emu Model B. The new Model B has the same disk emulation functions as the Model A and Universal Adapter, but with several new convenience features:

  • Built-in Apple II Compatibility – Model B is directly compatible with the entire Apple II line, emulating a 5 1/4 inch disk, 3 1/2 inch disk, or Smartport hard disk. While Model A required a separate Universal Adapter for the best Apple II compatibility, Model B has the equivalent functionality built-in. Classic Macintosh and Lisa disk emulation is still supported too.
  • microSD Card Support – The SD card slot is now a push-push microSD type, identical to what’s used in most mobile phones. This will make it easier to find suitable SD card media, since the older full-size SD cards are becoming rare.
  • SD Card Hot-Swap – The SD card can be removed and re-inserted while the Floppy Emu is powered on.
  • Improved Protection Circuitry – Model B features improved protection circuitry on the disk drive interface connector. This circuitry will help protect the Floppy Emu from electrical damage caused by voltage spikes and surges. It also eliminates the risk of potential damage if an Emu board running the Apple II firmware is inadvertently connected to a Mac or Lisa computer.
  • Same Great Emulation Features – All of the time-tested Macintosh, Apple II, and Lisa disk emulation features from Model A are still present. Model B reads and writes emulated 140K, 400K, 800K, or 1.4MB floppy disk images, or hard disk images up to 2GB, if supported by your Apple computer. For full details, see the instruction manual.

If you’re new to Floppy Emu, it’s an external hardware device for vintage Macintosh, Apple II, or Lisa computers. It uses a removable SD memory card to mimic an Apple floppy disk and drive, or an Apple hard drive. The Emu behaves exactly like a real disk drive, requiring no special software or drivers. Floppy Emu is perfect for booting your favorite games, moving files between modern and vintage machines, and troubleshooting a computer without a working OS. Just plug in the Emu board, and you’ll be up and running in seconds.

Floppy Emu Model B is available for sale now. While supplies last, I’m also selling the remaining inventory of Floppy Emu Model A units for a reduced price. It’s disk emulation madness!

Viewing all 165 articles
Browse latest View live




Latest Images