BMOW title
Floppy Emu banner

Archive for the 'Floppy Emu' Category

Floppy Emu Update: Apple II Copy-Protection

Good news for Apple II fans: there’s a new Apple II firmware update for the BMOW Floppy Emu Disk Emulator. This update introduces substantial emulation enhancements for copy-protected Apple II software on 5.25 inch floppy disk images. Though Floppy Emu is designed for standard non-protected disks, most copy-protected games and utilities should now work too, including most disks from the WOZ-a-Day collection.

The new firmware is version 0.2N-F26 or 0.2N-F27, depending on the model of your Floppy Emu board. You can download the latest firmware here: firmware

 
Background

Disk images of copy-protected Apple II software normally must use raw bitstreams, rather than using any high-level data representation like sectors. The NIB and WOZ disk image formats are both raw bitstreams, and the WOZ format has grown increasingly popular for this purpose over the past couple of years.

The BMOW Floppy Emu has supported both NIB and WOZ formats for some time. But even when the disk images could be read, the games didn’t necessarily always run correctly, because they sometimes attempted weird non-standard things with the disk drive. The Floppy Emu hardware didn’t always respond to these attempts as the games expected. The focus of this firmware update has been addressing a handful of edge cases and uncommon behaviors to satisfy most copy-protection schemes, enabling more copy-protected games to work with the Floppy Emu.

Thank you to Nick Bauer, who provided me with a carefully-researched list of several dozen copy-protected WOZ games that weren’t working correctly with the previous Floppy Emu firmware. Nick documented the behavior of each game on two different Apple II models, as well as with MAME, which was a tremendous help. After a few weeks of R&D when the new firmware was ready, Nick tested it with 350+ disk images from his collection.

So what changed?

 
SD Card I/O Rate

The most significant change is a doubling of the data rate when communicating with the Floppy Emu’s SD memory card, from 5 Mbps to 10 Mbps – the maximum rate supported by the hardware. The data rate has been 5 Mbps since the earliest days of the Floppy Emu, because 10 Mbps didn’t appear to be necessary, and because higher data rates increase the chances of signal errors due to analog signal effects. But at least one copy-protected game wouldn’t run correctly without the higher data rate – the Floppy Emu simply couldn’t fetch data fast enough from the SD card to keep the game satisfied. So 10 Mbps it is.

The data rate was increased in order to help 5.25 inch floppy disk emulation, but it also affects Apple II 3.5 inch floppy disk and Smartport hard disk emulation. This is the change I’ll be watching most closely for user feedback. If there’s already some source of electrical signal degradation in the system, like a noisy power supply, then the increased data rate may result in an unacceptable number of SD card read/write errors. In my testing, it worked smoothly with three different Apple II computers, five different Floppy Emu boards of various generations, and three different SD cards. But one of my earliest hand-soldered Floppy Emu prototypes did report errors at 10 Mbps, so I’ll be keeping an eye on this.

The SD card data rate can be reduced to the old rate of 5 Mbps by holding down Floppy Emu’s PREV button during power-up. In this case, a small number of copy-protected games including Hard Hat Mack may not run correctly, but most software will be unaffected.

 
Disk Bit Rate

Floppy Emu’s interface with the Apple II computer lies at the opposite end of the data funnel from the SD card. To the computer’s disk controller, the Floppy Emu looks like a standard 5.25 inch floppy drive, with a standard data rate of one bit every 4 microseconds. Except that some copy-protected software violates this standard. The new Floppy Emu firmware changes the bit rate from a fixed rate of 4 microseconds per bit to a variable rate that depends on the disk image, helping games with non-standard bit rates to run correctly.

How does this work? A 5.25 inch floppy disk spins at 300 RPM, which is one rotation every 200 milliseconds. A normal floppy disk has 50000 bits evenly spaced around each circular track, resulting in a rate of one bit per 4 microseconds. But some disks squeeze 51000 or 52000 bits into a track, which produces a bit rate closer to one bit per 3.9 microseconds.

The Floppy Emu’s hardware design makes it difficult to compensate for this, and the previous firmware didn’t even try. The 4 microsecond number is baked into the logic of Floppy Emu’s CPLD chip, ensuring that the rate never wavers even if the microcontroller is servicing an interrupt or is otherwise busy. While this is very helpful for normal disk images, it means that the bit rate can’t be adjusted on the fly. In practice this was rarely a problem, and most games with a 3.9 microsecond bit rate still worked just fine at 4.0 microseconds, but a few did not.

After some experimentation, I settled on a new CPLD design that allows for on-the-fly selection of a few different fixed bit rates. While this isn’t quite as flexible as a fully-adjustable bit rate, it satisfies nearly all of the copy-protected games I tested without requiring any Floppy Emu hardware changes.

 
Cross-Track Synchronization

Some copy-protected games rely on the relative spatial orientations of adjacent tracks on the disk. The WOZ disk image format encodes this information, and the old Floppy Emu firmware was already maintaining this cross-track synchronization. Frogger uses a track synchronization technique called Spriadisc, and it worked nicely on the Floppy Emu. But deeper investigation revealed there were still some cases where cross-track sync wasn’t being handled properly. The details depended on what method the software used to verify the track synchronization: counting disk bytes, measuring time, or some hybrid method.

There are several sources of potential synchronization error. Whenever the CPLD bit rate doesn’t exactly match the original disk’s bit rate, the behavior in the time domain will be slightly off. An entire track’s worth of bytes will be transmitted in slightly less or slightly more than 200 ms. With the old firmware, this type of error was most evident for games using cross-track synchronization and that had a number of bits significantly different from 50000. This error is mostly eliminated now that the bit rate is changeable.

A second source of error appears when games verify track synchronization through byte counting, if the SD card can’t load the track data quickly enough. A game might read sector 0 from track 0, then immediately step to track 1, and then count how many bytes pass by before sector 0 appears on the new track. If track 1’s data isn’t finished loading from the SD card yet, the Floppy Emu will insert a continuous series of special 10-bit timing bytes into the bitstream, until the real track is ready. This results in the software counting a different total number of bytes until sector 0 appears. Increasing the SD card data rate helps, by loading the track data faster, and reducing or eliminating the time period where the game sees 10-bit timing bytes instead of the track’s data bytes.

 
Weak Bits

Another common copy-protection scheme involves regions of the disk where there’s no magnetic flux. Due to the design of the floppy drive hardware, these will appear as random data when read. A new random-looking value will be read each time the empty region of the disk is accessed. Copy-protected software can test for this, and confirm that the data really is changing randomly and isn’t some fixed random-looking pattern, such as would be produced by Copy II+ or other disk copying software.

Floppy Emu already supported weak bits, and automatically substituted random “fake bits” in their place. All of the weak bits examples in the WOZ disk image reference set were working fine. But as with cross-track synchronization, a closer look found there were still some minor problems. It appears that the random fake bits supplied by Floppy Emu weren’t quite random-looking enough for some copy-protected software. This was hard to pin down, and I experimented with longer and shorter random sequences, as well as changing the sequence length. What seemed to help most was changing the distribution of random values, so that 0 bits were more likely to appear than 1 bits. The WOZ reference actually mentions this, but I’d tried it once earlier and it seemed to actually make things worse. It remains something of a mystery, but is working OK now with the disk image test suite.

 
Other Fixes

Aside from the interesting copy-protection stuff, this new firmware update also includes some basic bug fixes. I found two cases where track-to-track stepping movements of the disk were being misidentified or missed altogether, resulting in the Floppy Emu moving to the wrong track of the disk. Neither of these cases ever appeared with normal software, but they sometimes happened with copy-protected games that used custom code to directly control the stepper motors. A small fraction of WOZ disk images were also being misidentified as DSK images, causing errors when attempting to use them.

Oh yeah, one more thing: the new firmware also includes a menu usability enhancement for SD cards with deeply-nested directories of disk images. When exiting a subdirectory and returning to the parent directory, the selected menu item will now be the item for the subdirectory that was just exited, instead of the first menu item. This makes it easier to navigate into and out of subdirectories without getting confused and lost.

Read 3 comments and join the conversation 

Redesigning an Acrylic Case

The acrylic case for BMOW’s Floppy Emu disk emulator is back in stock, along with the deluxe bundle of Floppy Emu with the case and SD card. Get them now at the BMOW store. This is a new version of the laser-cut acrylic case that I’m excited to introduce today.

Eagle-eyed readers may notice that this case looks subtly different from the previous version. I call it a “sandwich style” design because the top and bottom panels overhang the sides, holding the side pieces between them like cheese held between slices of bread. This differs from the previous case, whose six panels with interlocking notches were joined at flush edges with no overhang. The sandwich style ensures that all the side pieces are locked securely in place, and can’t wiggle loose after assembly.

The changes continue inside the case, with the addition of a button guide for the button plungers. The button guide serves several important purposes. During assembly, it makes it possible to stand up the button plungers on the Floppy Emu’s buttons without the plungers falling over, so the top panel can be lowered down over them to finish the case assembly. This is much easier than the old method of suspending the plungers from the top panel with tape. After assembly, the button guide provides a second point of support for each plunger, ensuring that it moves straight up and down without unwanted angles or slippage. This also means the plungers’ functioning is independent of the case screw tightness, without any need to fine-tune the screws.

The last big change for the case is the introduction of top-panel engraved symbols for the power and status LEDs, instead of light pipes. The light pipes were fun, but they made case assembly substantially more difficult, and they’re not necessary when the top panel already functions nicely as an LED diffuser. The engraved symbols with diffuse LEDs give the new case a more minimalist look.

You may be surprised to learn this is something like the 15th version of the Floppy Emu case since I started making them! Most of those earlier revisions were small adjustments to fit or style, so this sandwich style redesign is the first really significant change. I’ve seeded some experienced Floppy Emu beta testers with the new case, and they report it takes about half the time for assembly and is better all-around. I hope you enjoy it!

Read 4 comments and join the conversation 

Retro Puzzle Contest: Solution

On Monday I posted a retro puzzle contest for vintage computing fans. Starting with only a confusing image of jumbled 8-bit characters, I promised that players would proceed through a tricky series of nested challenges, ultimately leading to the name of a person. If you’ve read the book (or seen the movie) Ready Player One, then you’ve seen this type of puzzle chain. I predicted that knowledge of vintage computers, software engineering, and 1980s cultural references would be helpful. And I offered a $100 gift certificate to whoever solved the puzzle and identified the mystery person first.

SPOILER ALERT! The puzzle was solved by the pseudonymous “frogor”, 28 hours after it was first posted. Congratulations! I’m going to describe the solution here, and the several different layers of the puzzle’s challenges. If you’d like to attempt solving the puzzle yourself first, read no further! It’s not an easy puzzle, and you won’t solve it in 5 minutes, maybe not in 5 hours, but you’ll find a retro-techno-challenge that’s worthy of the time you invest in it. See the original puzzle announcement here.

 
Level 1

The puzzle begins with a 39 x 26 grid of random-looking letters, numbers, and symbols. OK, now what? Several people suggested that it was some type of ASCII autostereogram image. Others thought that if they squinted, they could sort of imagine three rows of large letter-type structures, separated by hearts. Interesting theories, but if you could simply stare at the first clue and see the answer, that would hardly be a “series of challenges”. No, that wouldn’t be a puzzle worthy of this audience.

But there are a lot of hearts in the image – what might their significance be? Also diamonds, clubs, and spades. And all the glyphs look conspicuously bitmap-y, like the glory days of 8-bit computers. And then there’s the odd choice of blue-on-blue color scheme. Hmm.

Identifying the font used in the image seems like a good idea. So how can you do that? If you’re lucky, you’ll recognize it immediately, because you were immersed in it for hours every day during your formative years. Otherwise, you will probably have to brainstorm the names of various vintage computers, look for examples of their character set fonts, and see if they look like a match. Some people pointed to code page 437, and others to PETSCII, which both look close but aren’t quite right. Some of their glyphs have slightly different shapes than the clue’s image, and a few glyphs from the clue’s image aren’t present in code page 437 or PETSCII fonts.

The font used here is actually ATASCII, from the Atari 8-bit series of home computers sold between 1979-1991. The blue-on-blue color scheme is a clue. Those are the default text colors used by the Atari 8-bit computers. And all those hearts? The heart is the first entry in the ATASCII character set.

 
Level 2

Atari font, check. Now what? Maybe it’s a clue? “Atari” plus random gibberish symbols equals the name of the mystery person? Maybe not.

A font map is a mapping between numbers and glyphs. In the case of ATASCII, there are 256 different glyphs corresponding to the numbers 0 through 255 – one byte. For example, the heart is ATASCII value 0, and the capital A is ATASCII value 65 (hex 0x41). Converting all the glyphs to the equivalent byte value seems like it could be useful, but how?

If you’re a masochist, you could open two side-by-side windows with the image from the clue and the ATASCII font map, and do the conversion by hand. There are about 1000 glyphs in the image from the level 1 clue, so this would take a long time, and you’d probably make some mistakes.

A better solution might be to write a small program to automate the process. Inspection of the clue’s image shows that each glyph is 8 x 8 pixels. So write a program to compare each 8 x 8 block from the clue’s image with 8 x 8 blocks from the ATASCII map, until it finds a match, and then record which ATASCII entry it was.

Even better, use some existing software to do the conversion for you. Frogor writes “I used ImageMagick with some character tables to break apart the grid into individual characters and automate mapping them to their character set byte values.”

When the conversion is done, you’ll have an array of 1014 bytes.

 
Level 3

Now what can you do with this array of bytes? What is it? It seems to have some kind of structure: there are a large number of 0 bytes, and other values like 17 (hex 0x11) appear very frequently. It’s definitely not random data.

Making sense of the data is tricky. Maybe you can try to guess what sort of data I would put here, knowing the parameters and theme of the puzzle contest. Or maybe you have lots of hacking experience, and can recognize the raw forms of common file types and data structures just by staring at the bytes.

The people from level 1 who thought they could see three rows of large letter-type structures actually had a good idea. Frogor writes “I tried to figure out what my output -was- and could very definitely see some data structure by shifting the rows of hex bytes one character at a time. Since ‘file’ didn’t recognize it, I guessed it might be an image encoding of some sort – GraphicConverter RAW Import has an -amazing- visualizer which lets you play with the various settings until I tried as a last ditch effort a color encoding I probably should have started with.”

Yes, the bytes are a simple two-color bitmap, in raw form without any headers or other metadata. It’s just a grid of pixels. If you write each byte in binary, with a black pixel for a 1 bit and a white pixel for a 0 bit, then the 39 x 26 grid of glyphs from the first clue is converted into a 312 x 26 two-color bitmap image. Each one-byte glyph has eight bits which encode eight pixels horizontally, so the converted bitmap is eight times wider than the original grid of glyphs. And oh, what a bitmap it is.

 
Level 4

The upper-right of the bitmap says “BMOW RETRO PUZZLE AUG 2020”. Good, that tells you you’re in the right place. Then there’s some kind of weird code, and a couple of clock / arrow things pointing in different directions. Right.

It doesn’t take a rocket surgeon to recognize that this is some type of substitution cypher. Those boxy and wedgy shapes with dots inside them are clustered into groups that look like words, and the clusters

and

appear twice, on both the second line and the third. Maybe you immediately recognize this as the Pigpen Cypher, a classic cypher that’s often used in games and puzzles. Or maybe you search Google for “cypher with lines with dots inside them”, and are rewarded with Pigpen Cypher as the top result.

It seems Frogor was initially stumped, but was saved by outside help. “The next stage of decoding gave a tantalizing clue in the first row – but figuring out the second and third rows I credit to a suggestion of a friend.”

Performing a Pigpen substitution for the second and third rows of the bitmap reveals some new text. But two of the dots don’t seem to be part of the Pigpen cypher.

 
Level 5

Here’s where knowledge of 1980s cultural references comes into play. “We see farther.” If you were alive in the 80s and were involved in the home computer scene, you recognize this as the slogan of game developer Electronic Arts. And if you don’t recognize it, Electronic Arts is the top search result for this phrase.

The other lines are just lists of numbers. There’s also a mystery dot on each line, and those clock / arrow things at the end of each line. What’s this all about? What if you replace the numbers with the corresponding letters of the alphabet? It sounds worth a try. That gives you DI·FCDG and H·CEFG. Ugh.

Maybe the numbers are referencing one of the people on this iconic Electronic Arts “We See Farther” poster?

Maybe those clock / arrow things are pointing to someone on the poster? Or maybe they aren’t actually clocks or arrows, but compasses pointing north and east? That looks interesting! In that case, the mystery dots could be decimal points for a latitude and longitude in decimal degrees format. Frogor says “in hindsight the helpers on the right side were nice confirmation of being on the right path”.

What is at:

49.6347 degrees north
8.3567 degrees east

Google Maps provides a quick and ready answer for the latitude / longitude lookup.

 
Level 6

The location is somewhere in Germany, at something called “Worms Hbf”. Your German-speaking friend or a dictionary will tell you that Hbf is an abbreviation for Hauptbahnhof, the main train station in a city. Investigating the map further confirms that 49.6347 N, 8.3567 E is the location of the central train station in the city of Worms, Germany.

 
Level 7

WE SEE FARTHER

ELECTRONIC ARTS

WORMS, GERMANY

We see farther. Electronic Arts. Worms. All the pieces are here, but what do they mean? Is there some other clue in these words? If there’s some connection here, it’s not obvious.

If you go back to that Electronic Arts poster again, and take a closer look:

DAVID MAYNARD (arms folded) never intended that his innocently entitled WORMS? should become the Air Force’s secret I.Q. test for alien species. He does not endorse the wanton gambling cult that has sprung up around this product. And he deeply regrets the inhumane uses it has been put to by the Bulgarian Secret Police. “WORMS?”, he says, “was only meant as a lighthearted exploration of limited artificial intelligence using pretty light and simple music.” Right, David.

Seven levels deep into the puzzle, the mystery person is finally revealed! Phew! Success at last.

 
Creating the Puzzle

My original inspiration for this puzzle was simply “encode some stuff in ATASCII”. My first computer was an Atari 800, and I spent many hours staring at its strange square letters and symbols. They’re etched in my brain.

The idea to use an obscured latitude and longitude came from Brainchase. If you have kids that enjoy puzzles, they’ll love Brainchase. Or forget your kids and sign up for yourself. The first levels of their puzzles are simple enough for even young kids, but to finish them all requires hardcore problem-solving skills. And they have super cool prizes like buried treasure.

Eventually I arrived at the central idea: a latitude/longitude that points to a city whose name is also an English word, that when combined with another phrase, will uniquely identify somebody. “We see farther” jumped into my head immediately as a recognizable 1980s phrase that fit the puzzle’s retro-computer theme. I played loads of EA games as a kid, and also worked at Electronic Arts for many years as an adult.

To make the puzzle fit together, I needed to find an EA game whose name was also the name of a city. And it couldn’t be just any EA game, it needed to be an early game from the era when “We see farther” was still in use. There are no cities named “Archon” or “Pinball Construction Set”, but Worms fit the bill perfectly. So you see, I didn’t actually choose the mystery person. I chose the puzzle format, and the identity of the mystery person was determined for me.

Finding a latitude/longitude for Worms was harder than I expected. A city is a large place; it doesn’t have a precise latitude/longitude. No matter what coordinates I entered into Google Maps, the default behavior was to show a very zoomed-in view of streets and individual buildings, rather than a regional or national map of Germany. I worried this might give people the wrong idea. Would they understand that the clue meant the whole city of Worms, and not some random shopping mall or Burger King in the city? What building should I point to? I eventually settled on the train station as a stand-in for the city itself.

For the Pigpen cipher, I created a custom Pigpen font using Bitfontmaker2. This probably wasn’t necessary, but it was fun to type my secret messages in plaintext and have them automatically rendered in Pigpen. The other elements of the bitmap were drawn in by hand, to create the finished bitmap shown in level 4.

I used LVGL’s Online Image Converter to turn the bitmap into an array of hexadecimal bytes. Then I wrote a short Python program to turn the hex bytes into decimal bytes spread across DATA statements for use with BASIC. As a final step, I wrote an ATARI BASIC program and ran it in the Atari800MacX emulator.

10 FOR R=1 TO 26
20 FOR X=1 TO 39
30 READ NUM
40 PRINT CHR$(27);CHR$(NUM);
50 NEXT X
60 PRINT
70 NEXT R
1000 DATA 65, 31, 192, 32, 143, ...

CHR$(27) is the escape sequence. It ensures that control characters like tabs, newlines, and the bell are rendered as ATASCII glyphs instead of performing their control functions. Running this BASIC program created the finished image used for the first clue at level 1. Because the image came from a real (emulated) Atari rather than some paint program, I could be confident the glyphs, colors, and spacing were 100% accurate. This ensured that people could correctly identify the font, and do a pixel-by-pixel comparison against the ATASCII font map if necessary.

 
A Sequel?

I really enjoyed developing this puzzle, even though it took a long time to create. I also enjoyed watching other people’s thought processes as they tried to solve it. A friend of mine “live-texted” me his progress, which was lots of fun, even though he never finished.

I was a little bit disappointed that more people didn’t attempt the puzzle. Maybe lots of people took a brief look at it, weren’t sure where to begin, and immediately gave up. Or maybe people didn’t really understand what kind of puzzle it was, or why it might be interesting and worthwhile for them to invest time in solving it.

That leads to thoughts of a sequel. Now that puzzle #1 is done, and more people understand what this puzzle format it all about, I’m hoping there might be greater interest in a new one. I would enjoy the challenge. Would you?

Read 3 comments and join the conversation 

Floppy Emu Restock and Retro Puzzle Contest

The BMOW Floppy Emu disk emulator is back in stock and shipping now. Get yours and other BMOW hardware goodies at the store. But before you place your order, you might wish to try your hand at a special challenge.

Are you ready to test your nerd skills and win some prizes? It was quieter than usual around BMOW labs during the out-of-stock period, so I used the opportunity to design a devious retro-computing puzzle. What’s this crazy mess of blue and white symbols? Beginning with only this clue, skilled retro-nerds will work through a series of challenges that will eventually lead to the name of a person. Knowledge of vintage computers, software design, and 1980s cultural references will be helpful. Whoever is first to post the mystery person’s name in the comments section here wins a $100 BMOW gift certificate and one million internet fame points! You may use Google or any other tools you think might help. This is not an easy puzzle, but BMOW readers are a crafty and clever bunch. Ready… go!

Read 11 comments and join the conversation 

Acrylic Cases Back in Stock

Acrylic cases for the BMOW Floppy Emu and ADB-USB Wombat are back in stock. If you’ve been waiting for one of these, your wait is over. The Floppy Emu cases were held up longer than expected due to international shipping delays, which continue to be a major challenge. The Wombat cases are made locally, but the manufacturer has mostly transitioned to making emergency medical protective equipment and is processing other work slowly. To compound the problem, the first delivery of Wombat cases were somehow mis-cut at 15/16ths the correct size. The whole batch had to be thrown in the trash, and new cases re-cut. Sometimes even the simple things are hard!

Read 3 comments and join the conversation 

Floppy Emu Update: Favorites, Lisa Fixes, and More

New features have arrived for the BMOW Floppy Emu disk emulator! This update has something for everyone.

 
Favorites Menu

If your SD card contains hundreds of disk images or many deeply-nested subdirectories, navigating through the contents of the card can become tedious and slow. For convenience, an optional Favorites menu can now be configured. At startup the Favorites menu will be shown instead of the standard File Explorer menu. If needed, you can exit the Favorites menu at any time in order to choose non-favorite disk images.

The Favorites menu is configured using a plain text file named favdisks.txt. This file should be placed in the top-level root directory of your SD card. In this file, list the path to each favorite floppy disk image, one per line. An example file is included with the Floppy Emu’s firmware update package, which can be downloaded from the BMOW web site.

 
Auto-mounting

The Macintosh and Lisa will wait patiently for you to insert a boot disk, but most Apple II computers will give up if a boot disk isn’t found within a few seconds after power-on. To make life easier, past versions of the Apple II compatible firmware included a simple auto-remount behavior. At power-on, the most recently used disk was automatically re-mounted, if the disk was inserted when the power was turned off last time.

This new firmware enables further control over the Apple II automount behavior, using an optional automount directive on the first line of the favdisks.txt file. This is just the word “automount” followed by a space and a single digit:

  • 0 – Never automount. The Floppy Emu will always power up to display your Favorites menu.
  • 1 – Always automount the first disk image listed in favdisks.txt
  • 2 – Automount the most recently used disk, if there was a disk inserted when the power was turned off last time.

Automounting is only supported for the Apple II floppy disk emulation modes. The automount directive has no effect in other emulation modes, or for Macintosh / Lisa disk emulation.

 
Lisa 2/5 Fixes

Unlike the Lisa 2/10, the Lisa 2/5 doesn’t have an IWM chip for processing floppy disk signals. It uses a collection of discrete logic chips to accomplish the same result. For several years I’ve struggled to understand why the Floppy Emu firmware works poorly with the Lisa 2/5, and now I finally have the answer.

To detect a “1” bit from the floppy drive, the computer looks for a high-to-low transition occurring somewhere in the 2 microsecond bit window. It repeatedly samples the signal during that 2 microsecond window, looking for a transition. It turns out that the IWM samples the signal at a higher rate than the Lisa 2/5 discrete logic. The high periods of Floppy Emu’s “1” bits were too short to be reliably detected by the Lisa 2/5 level-sensitive hardware. This firmware update doubles the width of the high period, and my Lisa 2/5 testers report that it’s now working smoothly.

 
Floppy Emu for Visually Impaired Users

Several small tweaks have been made to improve the experience for visually impaired users. A new appendix has also been added to the instruction manual, with a detailed description of the behaviors necessary to use the Floppy Emu without seeing the display. The favorites menu was initially developed as a tool for blind users, before being extended into a general-use feature. With the Favorites menu, any desired disk image can be chosen reliably by counting how many times you’ve pressed NEXT before pressing SELECT to insert the disk.

Today’s firmware update also introduces an optional emumode.txt config file, which simplifies the process of changing the emulation mode by reducing the number of button presses needed. If this file is present, then as soon as the emulation mode menu is opened, the Floppy Emu will automatically change the emulation mode according to the ID specified in the file. An example file is included with the Floppy Emu’s firmware update package.

 
Download the New Firmware

Mac/Lisa firmware: mac-lisa-0.8G-F15
Apple II firmware for Floppy Emu Model B and C: apple-II-0.2L-F25

Read 6 comments and join the conversation 

Older Posts »