BMOW title
Floppy Emu banner

Archive for the 'Floppy Emu' Category

Atmel-ICE + Floppy Emu. The Taste of Sadness

In all the time I’ve been developing Floppy Emu, can you believe I’ve never had a debugger? I use the Atmel AVRISP mkII to program the Emu’s ATMEGA1284 microcontroller, but the mkII only supports programming and not debugging. I don’t have a serial port or other logging mechanism either, so when I encounter mystery problems, I need to debuga them by displaying one-time error codes or blinking an LED. Not very convenient.

Last week I finally purchased a proper debugger – the Atmel-ICE. It supports both JTAG and debugWIRE debugging, which are the two interfaces used in the ATMEGA family of microcontrollers. The Atmel-ICE also supports Atmel’s SAM family of 32-bit ARM microcontrollers, which will be handy if/when I start working with those.

With excitement, I connected the Atmel-ICE to Floppy Emu’s 6-pin ISP port. I was able to communicate with the ATMEGA1284 chip, view its fuses, and reprogram it. Visions of breakpoints and memory dumps danced in my head – this was going to be awesome. Then I started a debug session, only to encounter this error:

ISP on Atmel-ICE does not support debugging. Device is only programmed.

Use Start Without Debugging to avoid this message.

Wha-wha-what? Does not support debugging??

I searched in vain for a debugWIRE option, but the only interface choices displayed by the software were ISP and JTAG. After a frantic documentation search I discovered the sad truth. I’d thought the ATMEGA1284 had both debugWIRE and JTAG debugging interfaces, but the presence of JTAG actually means the chip doesn’t support debugWIRE. Even though the necessary debugWIRE pins are right there, and debugWIRE is mentioned in the chip’s datasheet, and there’s a debugWIRE enable fuse on the chip. Ugh.

I confirmed that a test project configured for the ATMEGA328P causes the debugWIRE option to appear in the Atmel Studio software. But Floppy Emu doesn’t have a ATMEGA328P. As soon as I change the project’s device type to ATMEGA1284, the debugWIRE option disappears.

Unfortunately I can’t use the JTAG interface, because I didn’t plan for it, and there’s no JTAG connector on the Floppy Emu board. I can’t do micro-soldering surgery to create a JTAG port either, because the ATMEGA1284 JTAG pins are connected to the board’s Xilinx CPLD chip, to support runtime reprogramming of the CPLD.

I’ll continue debugging with a blinking LED. Debuggers are for wimps. 🙂

Read 2 comments and join the conversation 

Thoughts on Floppy Emu Redesign

I’ve been pondering what a redesigned Floppy Emu might look like – what ICs might be involved. So why mess with success? The current design combines a microcontroller with a CPLD, which has proven to be a powerful and flexible combination. But the specific microcontroller and CPLD that I chose have both become a bit outdated, hard to find, and too expensive relative to the alternatives. By replacing them both with more modern parts, I could probably gain better features while simultaneously improving the manufacturing outlook, for a perfect win/win. Or with a sufficiently powerful microcontroller, I might be able to completely eliminate the CPLD.

 
CPLD

The CPLD (complex programmable logic device) is like a miniature FPGA, and is there to handle the timing-critical bit twiddling that the microcontroller can’t. It ensures the data bitstream appears at exactly the right speed, with no jitter, and also functions as a fancy parallel-to-serial shift register. For Apple II disk emulation, it helps make the work easier, and for Macintosh disk emulation it’s essential. The Mac treats floppy drives sort of like a 16×1-bit external memory, and microcontroller software isn’t fast enough to react to the changing address inputs and supply the correct data output.

The specific CPLD used by Floppy Emu is the Xilinx XC9572XL, which I mainly chose for being 5v tolerant. It works, but it can only store a very small amount of logic, which forces me to have separate and independent firmwares for Apple II and Macintosh emulation. With a larger and more capable chip, I could merge those into a single firmware.

The Xilinx XC9572XL is old enough that it’s approaching “legacy” status, and may be in line for discontinuation soon. Xilinx barely mentions it on their web site, and the chip has been sold out at all of their distributors for the past several weeks, which is worrisome. During the years I’ve been building Floppy Emus, the price of the XC9572XL has also steadily climbed to where it’s now more than double its original cost.

There aren’t many great alternatives, because it seems the whole CPLD market is slowly dying in favor of FPGAs, and most of what’s left has even smaller logic storage limits than the XC9572XL. The best option is probably a small FPGA instead, like one of the Lattice MachXO or MachXO2 devices similar to what’s in the Yellowstone disk controller.

A second idea is to replace the CPLD with a small, dedicated microcontroller, like something from the ATTINY series. With only one or two very simple tasks to do, maybe a mini-microcontroller would be able to keep up. I spent half a day pursuing this line of thinking, going as far as writing a first draft of the code for this hypothetical microcontroller, but decided to focus on other solutions first.

 
Microcontroller

Floppy Emu uses an ATMEGA1284 microcontroller, which in 2018 is almost a joke. Its sole advantage is that it’s a close relative of the ATMEGA chip used in Arduinos, so there’s tons of example code available for it. But it’s woefully underpowered compared to basically any other microcontroller out there. Any of the popular 32-bit ARM microcontrollers would have significantly faster clock speeds, more memory, and better peripheral options, and would probably cost less too.

Sadly there are still no common microcontrollers with enough internal RAM to buffer an entire floppy disk image (140K to 1440K depending on the image type). That would vastly simplify the emulation, help fix some occasional emulation hiccups, and possibly lead to better handling of copy-protected disks. But that will have to wait until the 2020’s, it seems.

After looking at a whole range of options, I’ve got my eye on the Atmel SAM4S series of microcontrollers. These boast speeds up to 120 MHz, while remaining relatively inexpensive.

 
Single-Chip Design?

Earlier I mentioned that the CPLD is essential for certain types of disk emulation, where microcontroller software isn’t fast enough to react to changing inputs in real time. That’s true for an older 8-bit microcontroller like the ATMEGA1284 running at 20 MHz, but what about for a modern 32-bit ARM running at 120 MHz? That might be a different story.

The hardest test will be 3.5 inch floppy disk emulation for the Macintosh. When the Mac wants to check some item of drive state, like whether there’s a disk inserted or whether the disk head is at track zero, it sets four IO lines with the right values to select from among the 16 possible state bits. Then it reads the result on a fifth IO line. It works just like an asynchronous SRAM, and the drive (or Floppy Emu emulating a drive) never knows if or when the Mac is reading state info. The drive needs to constantly respond, so whenever one of those four IO lines changes, the value on the fifth IO line must be updated immediately to reflect the newly selected state.

This would be difficult to emulate in a microcontroller, especially if it also needed to do other work besides merely responding to changing address inputs. The microcontroller would need to enable a pin change interrupt on each of the four address lines, and the interrupt service routine would need to read the address lines and set the data line accordingly. In practice it would be even more complicated, because there are other IO lines like /ENABLE that would also need to be considered, and would need their own interrupt handlers.

Would it be fast enough? Maybe. By itself the code in the ISR would almost surely be fast enough. But there’s overhead to consider – the interrupt service latency, and the time needed to set up the ISR context and exit it again (saving and loading all the registers from the stack). Then there’s the complicating factor of other potential interrupts, or other invocations of this same interrupt, creating additional delays before the ISR actually starts running. And the further complication of some critical code sections where interrupts need to be disabled temporarily, creating yet more delays before the ISR runs.

How fast does it need to be, anyway? How much time elapses between when the Mac sets the four IO lines and when it reads the fifth line? Unfortunately I don’t know, and the worst part is there’s really no way to find out. Because there’s no external indication of when a read is occurring, there’s nothing I can measure with an oscilloscope or logic analyzer. But I can make some rough guesses, based upon examination of a disassembly of the floppy disk driver code in the Macintosh ROM. On the Macintosh Plus, there’s a whopping 6750 ns between address and data for most state reads, but some reads have a much narrower window of about 1500 ns, assuming I’ve interpreted the code correctly.

Are there other faster read examples, buried somewhere in the Mac Plus ROM that I missed? And do Macs with a higher clock speed than the Plus have correspondingly faster read behaviors of disk state info, or do they insert delay code to keep the speed constant? I don’t know, but the Mac Plus is likely far from the worst case. I’ll make a wild guess that a 500 ns response time would probably be fast enough. Keep in mind I’m talking about the speed between presentation of the four address IO lines, and reading state info on the fifth IO line, which is entirely different from the speed or data rate of the disk data itself. It’s not something that’s specced or defined in any official source; it’s just something that arises as a side-effect of the code in the Mac’s ROM.

Despite the uncertainty here, I think there’s a decent chance this could work, so I’m going to try some experiments to test my theories.

If even a 120 MHz microcontroller isn’t fast enough to handle this 4-address-1-data mechanism, I’ve sketched out a possible fallback plan that uses a few discrete logic chips – some muxes and latches and buffers. It’s arguable whether that would be preferable to just using a CPLD (or FPGA), and it would certainly be less flexible. But a small handful of discrete logic combined with a much faster microcontroller could still provide some major advantages, and simplify firmware design by reducing the number of programmable chips on the Emu board from two to one.

So there’s a lot to think about. And anything that grows out of all this ruminating won’t see the light of day for a long time. But I can’t resist daydreaming…

Read 15 comments and join the conversation 

Garbage In, Garbage Out

I’m beginning to suspect there’s something subtly wrong with my Apple IIe, which might explain a lot of strange intermittent errors I’ve recently observed with Yellowstone and Floppy Emu development. It’s hard to know what to conclude, but when you can’t trust your test equipment, it’s impossible to trust the validity of your test results.

Recently I used this Apple IIe to test my new Floppy Emu OLED prototype board. When connected to a standard Apple Disk 5.25 controller card, everything worked fine initially. But when I tried doing some ProDOS file copy operations, the Floppy Emu spontaneously reset to the happy face / self-test screen. DOH! I tried it twice, and the Emu reset itself during the copy operation both times. I concluded there must be something wrong with the prototype board.

Then I tried the copy test two more times, and got different results. The Emu prototype didn’t reset itself, but the OLED display went blank several times during the copy operations. Hmmm.

So then I tried a plain vanilla Floppy Emu Model B, the same hardware and firmware that I’ve been using successfully for more than a year. I found that when trying to boot the Apple IIe from a ProDOS v1.9 disk image, the Model B’s LCD went blank several times during booting. Huh? This happened in two consecutive test runs, but then mysteriously stopped happening. I also tried the same file copy operations I’d done with the OLED prototype board, and saw a similar behavior where the LCD went blank a few times during the copy. But as before, after reproducing the bug twice in a row, it stopped happening.

Finally I went back to the OLED prototype board, and this time everything worked fine. No more unexplained resets or display blank-outs.

Maybe there’s something wrong with the Apple IIe’s power supply, or some problem where it needs to warm-up for a while before it works reliably? My first OLED prototype board tests were the first time I’d powered on the Apple IIe in several days, so it was cold. During an hour of testing, the strange Floppy Emu problems I’d observed gradually disappeared. It doesn’t really make sense to me, but it’s the best explanation I can think of. This might also explain some strange unexpected resets of the Floppy Emu last month, when I tested it with the Yellowstone card. In fact, it casts doubt on all of my Yellowstone testing.

Read 9 comments and join the conversation 

Floppy Emu OLED Prototype

Displays, displays! I’ve built a prototype Floppy Emu board that uses a 1.3-inch 128×64 OLED display, instead of the existing 1.4-inch 84×48 LCD. It works, and it looks very nice. So is this the answer to my display worries? Take a look at the photos, and tell me what you think.

Why change displays? The current edition Floppy Emu uses an 84×48 LCD that’s a clone of the Nokia 5110 mobile phone display. It’s a decent module with a nice built-in backlight, but the displays have caused me a lot of headaches over the years due to their iffy quality control. Around 10-15% are dead on arrival and must be discarded during manufacturing and testing. A large fraction of the remainder exhibit flaky behavior until the LCD’s pressure-fit connector is manually fine-tuned. These LCD hassles consume too much of the manufacturer’s time and my time. The supply chain for the 5110 LCDs is also problematic, coming only from small eBay and Aliexpress sellers, instead of a major manufacturer who can provide documentation and support.

Last month I reviewed some potential replacement displays. There weren’t many great options, but after lots of consideration I settled on this 1.3-inch OLED. It’s similar to the 5110 LCD in many ways, being a 1-bit graphical display with an SPI interface. The physical size is a bit smaller than the 5110 LCD, but they’re close. Unfortunately the supply chain situation for the OLED is even worse than the 5110 LCD, and the cost is at least $2 more per unit. But if I can save myself $2 worth of hassle, it will be worth it. A few weeks ago I hacked up a Floppy Emu board to support the OLED, just to prove that it worked, and today I now have a proper OLED Emu prototype.

 
I For One Welcome Our New OLED Overlords

The first thing you’ll notice about the OLED is that the contrast is amazing. The display is bright and very crisp, and the photos can’t do it justice. I never thought the 5110 LCD looked bad, but the OLED looks far superior.

The extra resolution of the OLED helps a lot. Text characters on the 5110 LCD are 3×6, while on the OLED they’re 5×7. This makes possible a more finely-detailed font that’s a nice improvement in legibility.

Text on the OLED is smaller, and at first I was concerned this would make it difficult to read. But with the awesome contrast and better font, my weak eyes find the OLED to be about equally easy to read as the larger text on the 5110 LCD. My wife declared the OLED more readable than the 5110 LCD. The OLED text is also larger than the text on my Backwoods Logger Mini (2011 flashback alert), and is about the same size as this CorelDRAW quick reference card I happened to have sitting out:

The OLED shows eight rows of text, compared to six rows on the 5110 LCD. This is a nice bonus when scrolling through a long list of filenames. With some extra development work and possible resulting display update slowness, future firmware might be able to trade fewer rows for larger text, but the OLED is designed around eight rows in hardware.

 
Fun with Fonts

I tried two different fonts. The first font has most letters being 5×6 pixels, with only the descenders of g, j, p, q, and y dropping below the baseline to make a 5×7 letter. Since each row is 8 pixels tall, the 5×6 letters provide two pixels of whitespace between rows. Here’s a sample:

The second font has most letters being 5×7 pixels. There are no true descenders, so g, j, p, q, and y sit on the same baseline as all the other letters. Because the letters are one pixel taller, this font is slightly more detailed and more readable than 5×6. But with only a single pixel of whitespace between rows, the text looks sort of cramped. I decided I didn’t like it, but maybe you’ll feel differently. Here’s a sample:

For comparison, here is the 3×5 font on the 5110 LCD:

 
Now What?

So it works. Now what? If I want to move forward with this OLED, there’s a lot of work to do. I need to find a supplier who can reliably provide hundreds of these displays. I need to get my updated PCB to my manufacturing partner. Because it’s a new design, I’ll have to pay them a bunch of money for one-time engineering fees. I’ll need to update the manufacturing instructions, and the test procedure, and the firmware that goes with it. And I’ll need to design a new case to fit the new board and OLED. It will all be a lot of work, and when it’s done my costs will have increased by $2 per unit. Is the pain worth it? Probably yes, but I’m still undecided.

I might do some experiments with another display I recently discovered, this COG 12864 LCD. It’s a little bigger than the OLED, which might be helpful, but it lacks the OLED’s excellent contrast and crispness. Its resolution is the same as the OLED, and it’s roughly the same price, and the manufacturing work needed to change displays would still be the same. I’m not sure there’s a compelling reason to choose the COG 12864 LCD over the OLED, but it’s a similar contender. Hmmm.

Of course the best option might still be to do nothing, and keep the 5110 LCD. Yes it’s a headache, but it’s a headache I’m familiar with and have dealt with successfully for four years. A new display would bring its own set of headaches through required manufacturing changes and case redesign, so I’m going to have headaches no matter what! But when I think about the best long-term solution, I’m drawn to the idea of a more reliable, better looking OLED.

Enjoy some gratuitous unnecessary zoom:

Read 14 comments and join the conversation 

Floppy Emu Display Experiments

Last week I wrote about my troubles with the Nokia 5110 LCD used by Floppy Emu, with a discussion of possible replacements. There was no clearly obvious alternative, as most of the options were too big, too small, too expensive, not available from a reliable supplier, or had some other shortcoming. After some thought, I settled on the 1.3 inch OLED as the most likely alternative. And now, after hacking away on the Emu’s firmware, I have a working example of a Floppy Emu with this 1.3 inch OLED display.

Nokia 5110 Clone LCD: 1.4 inch diagonal display, mounted on a carrier PCB, 84×48 pixels, SPI interface, 1-bit graphics

No-name OLED: 1.3 inch diagonal display, mounted on a carrier PCB, 128×64 pixels, SPI interface, 1-bit graphics

The photo shows a head-to-head comparison between the old and new displays. The picture doesn’t do the OLED justice – although it looks blurry here, it’s actually very crisp and pleasant to look at. The only significant problem is the tiny pixels, which makes the text a bit difficult to read. Although the display diagonal isn’t much smaller than the Nokia LCD (1.3 inch vs 1.4 inch), the aspect ratio is different, and the OLED’s height is only 2/3 the Nokia’s height. Then the OLED packs 1.33x as many vertical pixels as the Nokia, so the OLED actually has 2x as many dots per inch. You can see in the photo, when drawn with the same number of pixels, the OLED text is only half as tall as the Nokia text. Get out your reading glasses.

It’s not too bad, and I could probably live with text this size, but it’s not ideal. It would be great if I could simply make all the text 1.33x taller to take advantage of the OLED’s extra resolution, but unfortunately it’s not that simple. Text needs to be a whole number of pixels tall, and with the Nokia LCD there are six rows of 8 pixel tall text. The most I could increase this with the OLED would be 10 pixel text, 1.25x taller, for 60 pixels total, leaving 4 pixels wasted. But 10 pixel text is an awkward number, because the OLED’s command interface is built around the concept of “pages” that are 8 pixels tall. If text spans a fractional number of pages, I’ll need to completely redo the way display updates are performed, and maintain a framebuffer of the whole display area. Unless I get really fancy (dirty rectangles anyone?), that will require re-sending all 128×64 pixels of the framebuffer to the display every time I draw anything. That will be noticeably slow, which is one of the things I wanted to avoid.

So instead of making the text taller, I’ll probably make it wider. That should help a lot with readability. With 6×8 pixel characters, I’ll get 8 rows of 21 characters each, compared to 6 rows of 21 4×8 pixel characters on the Nokia LCD. Two extra rows of text will be nice.

I still need to look at the power consumption of the OLED as compared to the Nokia LCD. When I have two Floppy Emus powered by a single 5V USB supply, the one with the OLED glitches and resets whenever I turn on the one with the Nokia LCD. I’m not sure what’s causing that, but it doesn’t happen with two Nokia LCDs.

The final hardware headache will be modifying the Floppy Emu PCB layout. In order to keep the OLED centered, I need to relocate the LCD header into a spot that’s currently packed with traces and chips. I’ll also need to move the header from the bottom section of the board to the top (unless I mount the OLED upside-down), which means running several new traces across the full height of the PCB, or just redoing the entire board layout, which doesn’t sound fun. I’ll probably want some kind of mechanical support for the bottom end of the OLED too, since the OLED only has pins along its top, and it tends to hinge downward from those pins by force of gravity. That’s not a deal-breaker, but it looks a bit unattractive.

There will be some software challenges to address as well. I can’t just replace all the Nokia 5110 code with OLED code, because then future versions of the Floppy Emu firmware won’t work on all the Emus out in the world now with Nokia LCDs. I don’t want to maintain two different versions of the firmware either, one for each display type. Ideally I’ll find a way to create a single firmware that knows how to control both types of displays, and can dynamically detect which one is present.

The OLED display costs about twice as much as the Nokia LCD, but it’ll be worth it if it eliminates the headaches I’ve had with the Nokias. Right now I don’t expect I’ll need to change the price of the Floppy Emu. I’ll see how things look once everything is finalized.

Read 7 comments and join the conversation 

Quest for a Decent LCD

Floppy Emu uses an 84×48 graphical LCD display. It’s just a low-resolution 1-bit display, but it’s fast and easy to use, and has a nice built-in backlight. The display is actually a clone of the old Nokia 5110 phone display, and it’s made by semi-mysterious third-party factories in Shenzhen. It can be purchased in bulk for about $2.50 apiece. Photo from RH Electronics.

The big problem with these Nokia 5110 displays is that their reliability stinks. The actual LCD module (the glass and metal bit) is clipped onto a supporting PCB with some passive electronics, and it’s only a pressure-fit holding the two together. If it’s not clipped in just right, the display will exhibit contrast problems, or glitchy behavior, or just won’t work at all. Gently pushing on the LCD frame sometimes changes the pressure-fit enough to make these problems appear and disappear. Adjusting and tightening the LCD clips, as described in the Floppy Emu manual, is the only thing I’ve found that helps.

The electronics assembler that builds Floppy Emus must go through every LCD to check for problems. They usually end up discarding about 10% of all the LCDs, because they don’t work no matter how the clips are adjusted. Once the boards are finished, I do a second check of each LCD immediately before it’s shipped to the customer. This often requires more fiddling with the clips, or manual contrast adjustments, and a further 5% of LCDs are discarded. It’s very time-consuming, but despite all this effort, some troublesome LCDs still reach customers who must then make further adjustments.

In the most recent batch of LCDs, the pressure-fit contact design changed slightly, and it now appears to be even more troublesome than before. At the same time, the LCD bezel was unexpectedly enlarged by 2mm, forcing me to redesign the Floppy Emu acrylic case to match. This is a risk of buying generic parts from eBay and Alibaba, with no manufacturer to stand behind them or datasheet to document them.

 
Surely There Must Be Something Better?

It would be very nice to replace the 5110 displays with something similar but more stable. A replacement would need to handle about 84 x 48 1-bit pixels (equivalent to 21 x 6 text characters), with a diagonal size about 1.5 inches, and ideally use an SPI interface. Unfortunately, I’ve found nothing that even comes close. The alternatives are either much too large/small, lack graphical capabilities, are too slow, or are much too expensive.

Character and numeric displays aren’t appropriate, since they can’t do graphics or six rows of text. So looking at Digikey’s Display Modules – LCD, OLED, Graphic category, and sorting by unit price quantity 100 purchasing, and including only those results that have at least a few hundred units in stock, I found these:

128×128 RGB LCD, 1.44 inch diagonal, $4.23 – This could almost work, except I believe it’s a 24-bit color display, so the microcontroller would need to move 24x as much data to draw on it. And because it’s a much higher resolution, the amount of data to moved must be still higher to maintain the same font sizes as the old display. And it’s a slow I2C interface, instead of fast SPI. And there’s no datasheet.

128×32 LCD, $8.01 – This is an odd shape, doesn’t have enough vertical resolution, and uses a parallel 8-bit interface.

Another 128×32 LCD, $8.69 – Also an odd shape, and not enough vertical resolution.

128×160 RGB LCD, 1.8 inch diagonal, $8.83 – This is another color, higher-resolution display like the $4.23 one, but it uses a parallel interface.

128×64 LCD, 2 inch diagonal, $9.52 – Too big, too expensive, uses a parallel interface.

 
Non-Branded Options

Nothing from DigiKey looks suitable. What about other options from eBay or Alibaba?

128×64 OLED, 0.96 inch diagonal, $2.91 – This could sort of work, and I have one of these modules already. But it’s tiny, smaller than a postage stamp, which isn’t really suitable. It’s also I2C which means the interface is comparatively slow. Coming from a random non-branded eBay seller, it’s also not clear it would be any more reliable than the LCD display I have now.

128×128 RGB LCD, 1.44 inch diagonal, $3.04 – This is basically the same as the $4.23 module from DigiKey. Although this one says it has an SPI interface. Maybe this is the best option from a list of not-so-great alternatives.

Read 11 comments and join the conversation 

« Newer PostsOlder Posts »