Oh #$*&%. I just discovered that the new LCD modules I ordered have a different pinout than the old ones. It's the same LCD as far as I can tell, but on a different backing board, with the pins arranged in a different order. So they're not going to work with the new PCBs I have on the way.
It looks like I can still order LCD modules with the old pin arrangement, but they're not very common, and they cost more. I'm not sure if I should order replacement LCDs, and trash the incompatible PCBs, or order new PCBs and trash the incompatible LCDs. Ugh. Either way I'm stuck with a bunch of parts I can't use.
It's all eight pins on the LCD that have been remapped. I could probably cut all the traces and solder jumper wires for each one, but doing eight cuts and jumpers on every board doesn't sound like much fun. I think I'm going to get more LCDs with the old pin arrangement, and save the LCDs with the new pin arrangement for a possible future board revision, or maybe use them in another future project. Or use them as drink coasters or frisbees or something.
Here's a fix that gets Floppy Emu working on my PowerMac 7100, and hopefully also on those Quadra systems you guys were testing with. It looks like the PowerMac recalibrates the drive by doing 80 steps towards track 0, without checking to see if it reached track 0 along the way. On a real drive this would do nothing (or maybe make the stepper motor unhappy), but on Floppy Emu it was causing the track counter to wrap around to 255. The older ROMs seem smarter in this respect, and won't ever step past track 0.
I can't say what was causing those freezes and resets that bbraun observed. Maybe an unrelated bug. I did fix one issue that could theoretically have caused an infinite number of nested interrupts, though I doubt that was actually happening.
I got the new Floppy Emu boards and LCDs, and built four of them. Three work, and the fourth was working, but I somehow toasted it with a failed CPLD update that shorted out the 3.3V supply and fried something. So new boards, hooray!
I don't like how the backlight looks - it makes the LCD kind of washed out. So I'm leaving the backlight resistor unpopulated, but anybody who gets one of these can add a resistor there to enable the backlight if they want.
But not everything is good. While testing part-way through assembly, I'm seeing a maddening number of weird problems that seem to come and go at random. And two of the three finished boards don't work properly unless I add a second 10uF capacitor across the 3.3V supply (there's already one on the board). Without the extra cap, I see behavior like random resets or failing to even run the AVR program. This is similar to the weirdness I see mid-way through assembly. Several times I've also had the AVR programming verify step fail and somehow corrupt the fuses, and I once got into a state where the bootloader told me the main application was missing, even though it and the bootloader were written and verified during a single pass. Sometimes I see weird corrupted glyphs or text strings on the LCD. I've seen stuff like a board that was worked OK only immediately after programming - once it was unplugged and replugged, it stopped working until the next time it was programmed.
None of this is happening on the finished boards with the extra cap, but I saw so much of it earlier that I'm not sure I trust the end product until I can explain what's going on. I don't recall seeing any issues like this during assembly of the three boards I built with the old design and software.
A lot of things have changed since I last built any of these:
New board design relocated some parts and re-routed some traces
Boards were manufactured by a different fab
I'm using a ATMEGA1284 instead of ATMEGA1284P
I'm using a different brand of 3.3V regulator
Lots of AVR and CPLD software changes, including the way interrupts are used
I can't put my finger on it, but this feels like some kind of power or noise glitch causing problems like spurious interrupts and resets. But that could be caused by any of the changes I mentioned, and I'm not sure how to narrow it down, or if I should even worry about it since the end product seems to be working.
The reason I tried adding the extra cap is that I observed the 5V supply was pretty noisy, with peak-to-peak noise of about 1V. But my old board isn't too much better, and adding the cap didn't actually reduce the supply noise very much - though it does seem to help.
Anyone have any suggestions on what to try next? I think I'm going to put it aside and think on it for a while. I also need to do more thorough testing of the new boards with a few different Macs and SD cards, and make sure they really are working OK.
I did a bunch of measurements with the scope. Bottom line: the 1.1 boards have 3x to 10x more noise in the 5V and 3.3V supplies than the 1.0 boards, unless using the LCD to which I soldered an extra 10uF capacitor between 3.3V and GND. With the extra capacitor, the noise is about the same.
Rev 1.1 board:
with new LCD (with extra 10 uF cap) and Transcend: 80 mV on 5V, 100 mV 3.3V, no freq
with new LCD and San Disk: 80 mV on 5V, 100 mV 3.3V, no freq, works most of the time, but sometimes shows a blank screen after reset
with new LCD and PNY: 100 mV on 5V, 100 mV 3.3V, no freq
with new LCD and no SD card: 60 mV on 5V, 50 mV 3.3V, no freq
with old LCD and Transcend: 380mv on 5V, 100mV on 3.3V, noise freq about 131kHz
with old LCD and San Disk: 840mv on 5V, 280mV on 3.3V, noise freq about 89kHz
with old LCD and PNY: 260mv on 5V, 100mV on 3.3V, noise freq about 135kHz, noise amplitude seems to increase/dec in a slow wave
with old LCD and no SD: 900mv on 5V, 340mv on 3.3V, noise frequency around 80 kHz on both supplies
with no LCD, no SD: 900 mV on 5V, 350 mV 3.3V, noise freq 82 kHz
Rev 1.0 board:
with new LCD and Transcend: 100 mV on 5V, 120 mV 3.3V, no freq
with new LCD and San Disk: 60 mV on 5V, 120 mV 3.3V, no freq
with new LCD and PNY: 100 mV on 5V, 120 mV 3.3V, no freq
with new LCD and no SD: 80 mV on 5V, 120 mV 3.3V, no freq
with old LCD and Transcend: 100 mV on 5V, 120 mV 3.3V, no freq
with old LCD and San Disk: 80 mV on 5V, 120 mV 3.3V, no freq
with old LCD and PNY: 100 mV on 5V, 120 mV 3.3V, no freq
with old LCD and no SD: 80 mV on 5V, 100 mV 3.3V, no freq
with no LCD, no SD: 80 mV on 5V, 100 mV 3.3V, no freq
It's almost like the 10uF capacitor that's present on the board is just doing nothing on the Rev 1.1 boards. But this part of the design is unchanged since Rev 1.0.
OK, I've got a small number of Floppy Emu "DIY kits" ready to go! I'm selling these for $20 if anyone would like one - email me at email@example.com. It contains the three hardest to get parts: the Nokia 5110 LCD, the DB-19 connector, and the revision 1.1 PCB.
The assembly instructions have been updated. One of the capacitors needed to be replaced with a 33uF tantalum to resolve the supply noise problem I mentioned earlier.
Are there any unused commands we could hijack to use to communicate from the host computer to the floppy emu? I'm thinking along the lines of being able to select and re-insert a disk after it has been ejected.
There's obviously problems with doing host side selection that way, like in the case where the machine says "please insert $FOO", and you can't do anything until you do (although possibly macsbug macros?), but I'm just thinking of the common case where I'm done with a disk, but would like to insert another one.
I'm also curious if you've thought about a 3D printable enclosure for it. I've been contemplating the best way to set a floppy emu up for permanent use. Internal mounts have problems due to accessing the display. Connecting the DB19 directly has similar issues with the floppy port on the back of the machine.
The options I can think of are to use a db19 to the IDC cable and have the box sitting on the desk. That gets access to the external floppy, but it'd be neat to be able to use the internal floppies too. That pretty much means running a ribbon cable out the machine, which is fine, but then does it sit in a box on the desk? I'm contemplating ways to mount the thing to the front of the machine.
There's no way to do out-of-band communication with the board, but you could use some kind of magic number sequence. For example, a write to sector 0 that began with a specific 16-byte magic number could be interpreted as a command, and not as literal data. However, this would only work when there was already a disk in the drive, unless you also modified the Sony floppy driver to skip the check for a disk.
You could probably also rig up something with the disk drive registers for the motor, stepping, etc. Like move the drive head through a very specific pattern of track steps, that has virtually zero chance of every occurring during normal data access. It would be cumbersome, but I think it could work for sending a few bytes of data.
The new rev 1.1 board has mounting holes, with the idea of making a case for it, but I haven't done anything specific about making a case. The "box on the desk" was what I was imagining, but maybe you could design something that clips onto the Mac's case somehow, maybe into the original floppy slot.
Could a special disk be created on the fly which creates a fake directory listing showing the images available to the client? When the host accesses the sectors of the fake file, the firmware interprets it as a command and ejects the fake image and mounts appropriate disk image.
Or keeping with the fake disk image idea, a fake image containing an auto-generated disk image listing and special MacOS program to select the disk image and perform the eject, etc.
Yeah, it should be possible in theory to write a program running on the Mac that displays a list of disk images, and lets you choose one to insert, so you don't need to physically push any buttons on the board itself. Exact signaling mechanism TBD. May or may not require modifying the floppy disk driver, I'm not sure.
Regardless of the signaling mechanism, though, there are a couple of problems with this idea, which is why I've never pursued it:
How do you get this disk selection program onto your Mac in the first place? If it comes from a hard drive, then that kind of defeats the point of having a floppy emulator to begin with. But if it comes from a floppy image, then you need to always boot with a special image that contains this program, which seems kind of limiting. You'd also still need to physically push a button to insert the boot floppy, unless you also modified the firmware to auto-insert the first available floppy image or something like that.
The disk selection program can't run when the "Please insert the disk Blah-Blah" modal dialog is on-screen. This is the problem bbraun alluded to. Maybe you could patch the floppy driver or modal dialog ROM routine to work around this.
I don't have any plans to work on this, but if someone else wants to try it, I'm happy to point them to the right parts of the code. You can download the source from the "building your own" page on my web site.
Those HD20 docs are VERY interesting. No, I hadn't seem those before-- was that a recent find? I just kind of glanced through, but it looks like it might be enough detail to turn Floppy Emu into a working HD20 emulator. It also looks like the protocol is not fixed at 20MB in size, so disks larger than 20MB might be possible. It might not be possible to emulate a floppy drive and the HD20 at the same time, though - meaning there'd be no way to load the HD20 Init on a Mac 512K unless you've got two Floppy Emus.