BMOW title
Floppy Emu banner

Archive for the 'Floppy Emu' Category

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 7 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 6 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 6 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 

Floppy Emu Back in Stock

BMOW’s Floppy Emu disk emulator for vintage Apple computers is back in stock. Get yours now at the BMOW store.

Read 9 comments and join the conversation 

Yellowstone JTAG Debugging

After a month of inactivity, I finally returned to my unfinished Yellowstone disk controller project to investigate the JTAG programming problems. Yellowstone is an FPGA-based disk controller card for the Apple II family, that aims to emulate a Liron disk controller or other models of vintage disk controller. It’s still a work in progress.

Last month I discovered some JTAG problems. With the Yellowstone card naked on my desk, and powered from an external 5V supply, JTAG programming works fine. I can program the FPGA to blink an on-board LED. And when I insert the already-programmed card into my Apple IIe and power it from the slot, it works – the LED blinks. But if I try to do JTAG programming while the card is inserted in the IIe, it always fails with a communication error. I’ve run through several theories why:

  • It might be some kind of noise or poor signal integrity on the JTAG traces. But the traces are quite short and don’t cross any other signal traces that might carry interfering signals.
  • Maybe I have power problems, and the IIe’s 5V supply is drooping briefly when I try to program the FPGA via JTAG. But I measured the 5V and 3.3V supply voltages during JTAG programming, and they look fine.
  • There might be a ground loop, due to the Apple IIe and JTAG programming having different ground potentials. But I measured the difference in grounds, and it’s only 4.3 millivolts.

To help solve this mystery, I used the analog mode of my Saleae Pro 8 Logic analyzer. In analog mode, it functions like a simple 8-channel 12.5 Ms/sec oscilloscope. I recorded the 3.3V supply for the FPGA, as well as all the JTAG signals. First, here’s what the first three seconds of JTAG traffic look like when programmed externally:

There’s about 1 second of preamble communication, and the rest is the FPGA configuration data arriving at high speed. The 3.3V supply for the FPGA remains at about 3.28V through the whole process. The JTAG signals TMS, TDI, and TDO span the voltage range from 0.17V to 3.2V, which seems fine. But the the TCK signal never goes higher than 1.86V. Uh oh, what’s happening there? Let’s zoom in a little:

Zooming in, things are even worse than they appeared initially. TCK never climbs above 1.86V, but many TCK pulses only get half that high, stopping at 0.97V. TMS and TDI show some runts too. Zooming in even further on one of the problem areas:

Here you can see a couple of the 1.86V TCK pulses, followed by a whole mess of the runtier 0.97V pulses. Ugh. These should all be using the full range 0 to 3.3V, or something close to it. With a clock signal this bad, it’s amazing the JTAG programming still works.

Do these graphs really reflect what’s happening? I’m a little suspicious that I’m running into limitations of the Saleae Pro 8’s analog mode. At 12.5 Ms/sec, it’s taking one analog sample every 0.08 microseconds or 80 nanoseconds. That’s pretty poor as scopes go, but the period of the JTAG clock is slow: about 1 microsecond (1 MHz operation). There should be 12.5 samples per clock period, more than enough to get a decent reading for the min and max voltage of each clock period. Therefore I think the graphs are accurate.

My conclusion is that although external JTAG program succeeds, the JTAG signals look terrible. The fact that JTAG programming fails when the card is in the Apple IIe slot likely has little to do with the IIe, and everything to do with some other basic signal quality problem.

Next I put the Yellowstone card into the Apple IIe, and repeated my test. Here’s the first three seconds of JTAG traffic again:

There’s a short bit of preamble communication, then nothing. Something must go wrong at the beginning, and the rest of the communication is aborted. The voltage levels all look about the same as when programming externally. The 3.3V supply is about 3.28V, TCK never goes higher than 1.86V, but the other JTAG signals use the full voltage range. Zooming in, we observe the same extra-runty TCK pulses as with external JTAG programming:

It’s not obvious to me why external JTAG programming succeeds, but programming in the Apple IIe slot fails. Both cases look equally bad. The only real difference I noticed is the TDO signal. In the case of external programming, the TDO high voltage is very steady at about 3.268 volts, and never varies by more than 0.01V. It also drops low at many points during the JTAG communication. But in the case of in-slot programming, the TDO signal is always high and the voltage is noisier. It’s a subtle difference, but you can see the minor noise here:

The TDO high voltage ranges from 3.187V to 3.314V, so it’s about 10x noisier than during external programming. It’s still within an acceptable range though, so maybe this isn’t important.

Finding the Culprit

Now that I know I have poor quality JTAG signals, where do I look for the cause? Poor quality JTAG programmer? Bad PCB design? Here’s a section of the PCB, showing the path of the JTAG signals from the connector to the FPGA:

There’s not much opportunity for interference. The only PCB tracks that are crossed by the JTAG signals are voltage supplies and the disk I/O signals, which were unconnected during this test.

The prime suspect is R3, a 4.7K pulldown resistor on TCK. This was recommended by Lattice, as a precaution to prevent spurious TCK pulses causing unwanted JTAG activity when no JTAG programmer is present. Lattice technote TN1208 for the MachXO2 family says on page 12-2 “TCK: Recommended 4.7kOhm pull down.” The other JTAG signals discussed here all have internal pull-ups. 4.7K isn’t much, but maybe the JTAG programmer has an anemic drive strength and is unable to drive TCK fully to 3.3V with the pulldown present? I could try removing R3, but that wouldn’t explain why there are also some runt pulses seen on TMS and TDI. I double-checked to confirm I didn’t accidentally use the wrong value resistor for R3, but no: it’s 4.7K as intended. I also measured the resistance between TCK and GND, to see if there’s some other unintended low-resistance path to GND that’s screwing up everything, but it measured 4.7K exactly.

Read 31 comments and join the conversation 

Older Posts »