Lassoing the Lisa
Floppy Emu for Lisa progress report: I now have a firmware version that sort-of-works on the Lisa, when using Macintosh disk images, and running Macworks Plus on the Lisa. I can read from an emulated 400K Macintosh disk as well as write to it. From the limited testing I’ve done so far, it looks like the data is read and written correctly. But it’s not really usable as-is, and there are still some significant problems to overcome.
Bit Slip
The reason it wasn’t working yesterday appears to have been a problem with the way Floppy Emu generates something called bitslip markers. The data on a floppy disk is just one long string of bits, with no framing information to show where one byte ends and the next begins. The floppy controller only knows that disk bytes always have 1 as the MSB, so if it reads a byte where the MSB is 0, it means the framing must be wrong. It slips one bit, and tries again. To assist the floppy controller, disks normally contain a series of special 10-bit markers called bitslip markers, with the binary value 1111111100. After five consecutive bitslip markers, it turns out that the floppy controller will always end up with the correct framing, regardless of what framing it started with in the bit stream.
The trouble was that Floppy Emu wasn’t generating 10-bit 1111111100 markers, it was generating 8-bit 11111111 markers. This is one of those cases where you scratch your head and wonder how it ever worked at all, even on the Macintosh. Once I fixed the bitslip generation (I hope), Macintosh disk images started working on the Lisa under Macworks Plus. Woot!
Slowness
The biggest problem is that it’s slow. S… L…. O….. W…… After inserting a disk image through the Floppy Emu interface, it takes about 20-30 seconds before the disk icon appears on the desktop. And file copy operations take so long, you may as well go eat a sandwich while you’re waiting, even for files in the 10K size range. I’m guessing it’s still encountering a ton of low-level errors, causing the floppy controller to retry over and over, until it finally succeeds. So something is definitely still wrong.
I’ve been corresponding with a Lisa owner who’s got a Floppy Emu and Basic Lisa Utilities already set up, and he’s run a few tests for me. What’s strange is that this new firmware version is actually much worse than the old version, according to BLU. Despite the fact that this one actually works on the Lisa and the older one didn’t, this new version shows more disk errors in BLU, and more types of different disk errors. Hmmm.
Stepping Out
The other problem is that Floppy Emu on the Lisa is stepping to the wrong track for the desired sector… I think. On a 400K floppy, there’s only data on one side. There are 80 tracks, and each track has between 8 and 12 sectors. Each sector is 512 bytes. So 512 bytes per track times an average of 10 sectors per track times 80 tracks = 800 sectors and 400K. I’ve written a simple utility program where I can type in the sector number I want to read, and it fetches the data from the floppy and displays it, along with any error code returned by the read operation. With a 400K disk, if I request the last sector (number 799), it should step to the last track (track 79).
I can see the current track number on the Floppy Emu LCD, so I can verify whether it’s doing the expected thing. And when tested on a Mac Plus or a Mac SE, the Floppy Emu with a 400K disk image does what it should: it steps to track 79. But on the Lisa, under Macworks, when requesting sector 799 the Floppy Emu consistently steps to track 35 and returns bogus data. What the heck?
It turns out that track 35 is exactly where you’d expect to find sector 799, if the disk were a double-sided 800K disk. So maybe the Lisa is somehow confused, and thinks there’s a double-sided disk and drive present. But if this were the case, reading and writing files from the disk through the Finder shouldn’t work at all – it should be hopelessly broken. Yet as far as I can tell, it works, just very slowly. Could there be something about my testing program that’s flawed? I just don’t know.
It’s also possible this stepping weirdness is some kind of problem with the particular Lisa I’m using for testing. From what I’ve learned, the Lisa originally supported 400K floppies only. Later an 800K upgrade kit became available, which included a new 800K-compatible ROM chip for the Lisa’s IO board. I’m running Macworks Plus on the Lisa, which is supposed to make the Lisa act like a Mac Plus, which had an 800K drive. But if this Lisa doesn’t have the 800K ROM chip on its IO board, maybe using Macworks Plus will cause this kind of strange stepping problem.
Download
If you’ve got a Lisa and a Floppy Emu, and want to test this out, you can download a few different firmware variations here. There’s a single CPLD firmware file (firmware.xvf), and a few different AVR firmware files (femu.bin), each of which uses a slightly different strategy for bitslips. In my tests, the “address to data gap size 20” AVR firmware doesn’t work, but all of the others one do. But they’re all very slow. If you try it, please let me know how this firmware works for you, as well as the details of your Lisa hardware and software configuration. Thanks!
Read 22 comments and join the conversation22 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
I am really interested in fixing your test utility to work on 64k ROMs, and thus MacWorks XL. I wouldn’t expect MacWorks XL to treat the floppy as double-sided, since double-sided floppies aren’t recognized by the 64k ROMs. There is a variant of Mini vMac that can emulate the 128/512, so let me see if I can track down an old enough compiler that can build working apps for it.
I’ll post the source for the test utility program. Think C should probably be better than Metrowerks for building programs targeting the very earliest Macs and system versions.
Floppy sector reading test program, application and source code: http://www.bigmessowires.com/FloppyReadAny.sit
404
Fixed link.
Try this build on your 512: https://www.dropbox.com/s/zc6gyynavkkixrk/Floppy%20Read%20Any%2064k.zip?dl=0
I built this using THINK C 5.0 and included the source, too. Had to change calls to GetDialogItem, SetControlValue, and GetDialogItemText to their older names GetDItem, SetCtlValue, and GetIText, respectively.
“What’s strange is that this new firmware version is actually much worse than the old version, according to BLU. Despite the fact that this one actually works on the Lisa and the older one didn’t, this new version shows more disk errors in BLU, and more types of different disk errors. Hmmm.”
I’m not sure that’s surprising. It probably gives up trying things after a certain number of consecutive failures. If it half-works, then it probably gets further into the test process?
I decided to install BLU to the Lisa’s hard drive, so I can easily boot the machine with BLU with a Floppy Emu attached, and run the floppy drive tests. But can you believe this – the M key on the Lisa’s keyboard doesn’t work, so I can’t access the (M)iscellaneous function sub-menu where the option for HD installation is located. So no HD install for, unless I can find a work-around.
The alternative is to find a way to boot BLU from a real floppy disk, then switch to the Floppy Emu for testing. I could just unplug the floppy drive and plug in the Emu, but hot-swapping drives is risky, especially for the Emu. Instead, I built an adapter that connects power and the computer’s floppy outputs to both drives, with a manual switch to control whether the computer’s enable output is connected to drive 1 or drive 2. The read lines from the floppy drives are connected together, but it should be OK since only one drive will be enabled at a time. That’s similar to how the two external and internal floppy drives are connected on a Mac.
I tested the adapter on a Mac SE (not wanting to risk the Lisa, if the adapter were flawed), with one 400K drive and one Floppy Emu, and it mostly works. I can use the switch, and the computer will only see the drive that’s enabled with the switch. But there are some problems too that I can’t explain. With the adapter and two drives connected, the SE’s internal hard drive just disappears, like it’s not even there. And depending on which drive I boot from, sometimes the 400K drive works fine, but sometimes it complains that any disks I put in are unreadable. Sometimes it ejects disks fine, and sometimes it appears unable to eject. Sometimes disks just randomly eject themselves from both the 400K drive and the Floppy Emu. Sometimes the eject mechanism on the 400K drive triggers like 10 times in a row. So it’s definitely not ready for the Lisa yet.
Ah, my adapter works after all. The problem was that I’d combined a real 400K drive with a Floppy Emu that acted like an 800K drive. So from the computer’s point of view, the type of drive would magically change when I flipped the switch, causing badness. After changing the Floppy Emu firmware to identify itself as a 400K drive, it works. I’ve put the adapter on the Lisa, and I’m not able to load BLU from a real floppy, and then run test on the Floppy Emu.
Unfortunately BLU sends the test results to the serial port, and not the screen. I’ve ordered a DB-25 to USB serial cable, but it’ll be a couple of days before it arrives. Meanwhile, the only thing I can do watch the the sector number that’s displayed on screen, while BLU runs its tests. When it pauses at some sector number for several seconds, I can tell it’s having some kind of trouble with that sector.
Steve,
I can’t seem to find info on it, but if the Lisa has TTL-level serial and you have a spare Arduino board around, you can make a temporary serial-to-usb converter for free:
http://hackaday.com/2010/10/09/using-an-arduino-or-seeeduino-for-its-ftdi-chip/
Best of luck – I enjoy reading your hardware posts and appreciate seeing both the successes and failures.
— Joe
I do have a USB-to-serial cable that terminates in a 6-pin 0.1 inch header. But it’s just a 5V device, and I don’t think it can handle the higher voltages and negative voltage swings of a real RS232 device. I also don’t have DB-25 connector to wire it to. I guess I could cut up some other cables, and get a MAX232 converter, and cobble together a cable… but that doesn’t sound like much fun. 🙂
OK,
So I have done some “un-scientific” testing with the different firmware variations using my Lisa2/10 and Floppy Emu SN#67.
In each test I “inserted” the same 400K Raw image and timed how long it took to mount on the finder desktop and then eject and repeat a few times.
Here are the results:
Using the orginal app FW 1.0L and CLPD 11,
2min15sec
1min23sec
9sec
2min
Using AD100u, DD100u:
9sec
7sec
Using AD180u, DD180u:
7sec
6.5sec
6.5sec
Using AD400u, DD400u:
7.5sec
7.3sec
6.5sec
A to D Gap 20:
2min
9sec
7.8sec
DD 180u:
7sec
7sec
6.4sec
I can’t explain why the numbers seem to jump around.
I was also able to mount and write to 800K disk images using the newer FW.
I also was able to boot System 6.0.8 from Steve’s 800K disk image.
We are making progress.
Rick
Thanks! The newer firmwares (DD 180u, AD400u-DD400u, AD180u-DD180u, AD100u-DD100u) definitely seem to be working better for you than the older ones (A to D gap 20, FW 1.0L and CLPD 11), so that’s good. But what’d odd is that all the firmwares, both old and new, appear to be working significantly better on your Lisa than on mine. On mine, the new firmwares take around 30 seconds to mount a floppy, though it varies a lot. And the old firmwares don’t work at all. Very curious.
Rick does your Lisa have the PFG installed? I’m willing to bet that your success with the Floppy Emu can be attributed to that as one of its functions is to adjust to the timings of whatever floppy drive is attached.
Is there an easy way to tell if a Lisa has the PFG installed or not? I’ll be opening mine up soon, and I’d like to check. Is the PFG an additional PCB? Or an extra chip?
The system it did the testing on does have the PFG board installed (it’s a requirement to run MW+II). BUT, I don’t think that the PFG is effecting the operation. 1st of all the PFG can be turned off by using the Floppy CP and using the “stock” settings. 2nd, if you have the PFG activated, the mouse cursor will change (displaying a disk icon and a number) if the system sees and error and the PFG is invoked to correct things. The number that’s displayed indicates the level of adjustment that is being invoked (levels 1 min -3 max).
During my testing I only saw the PFG get invoked a few times (for the long minute plus times) and mostly it was only at level 1, I only saw the system kick into level 2 once in all the testing.
Since my Floppy Emu is still flashed with the DD 180u firmware, for quick test this morning I turned off the PFG (by using the stock settings) and did the same test. The results were the same, about 7 secs.
Rick
Keith, your modified Floppy Read Any program runs on my Mac 512K with the 64K ROMs, so that’s great! It doesn’t seem to work correctly, though. If I boot with System 2.0, no matter what sector I tell it to read, it always returns error -81 (can’t find sector). It’s the same behavior whether I use Floppy Emu or a real 400K floppy disk and drive. If I boot with System 3.3, it always returns error -50 (variously documented as paramErr, params don’t specify an existing volume, bad positioning info, or bad drive number).
Steve,
you said “If I boot with System 2.0″…
Be warned that each version of MacWorks requires a specific system version to be booted. Normally you can’t just use an older version of the mac system with MacWorks, this may be causing you other issues. MacWorks is NOT a Macintosh emulator, it provides and adapts the mac toolbox calls to connect with the Lisa hardware, it does not try to emulate the mac hardware or behaviors. Any program trying to address the Mac hardware at low level with have troubles in MacWorks.
Rick
The Floppy Read Any test I referred to above was actually on a Mac 512K, not the Lisa.
It looks like the “Floppy Read Any” code that reads the drive number, start sector, and sector count from the dialog box got broken during the translation to Think C 5.0. I’ve fixed that, and now it works fine on a Mac 512K (with the 64K ROM). That means I can finally do the test that was the whole point of this: switch back to Macworks XL on the Lisa, and use this new version of Floppy Read Any to do more Lisa-based testing of the Floppy Emu.
@Rick – do you know what version of the Mac OS is supposed to be used with Macworks XL? I think it’s Macworks XL version 3.
My version of MacWorks XL 3 came with a System 2.0 install disk, but I believe it can go up to System 3.2, which is what I had installed on the hard drive. MacWorks Plus 1.x I think came with a System 3.2 install disk but can handle up to System 6.0.2.
Here is a direct quote from the Apple Lisa/Macintosh XL Do-it-Yourself Guide by Sun Remarketing:
“One Caveat: Following through with inappropriate versions of the System and Finder will
crash the machine. Acceptable System/Finder combinations for use with MacWorks 3.0 and
MacWorks XL include 2.0/4.1 and 3.2/5.3. These are the exact same limitations that 512K Macs
have. Additionally, you must load the System and Finder from an M FS (Macintosh File
System) disk. HFS (Hierarchical File System) disks are not recognizable on any Mac under the
64K ROMs.
MacWorks Plus version 1.07 or greater requires at least System/Finder 6.02/6.1. In this case,
previous versions of the System and Finder result in a crash. The important thing to
remember is that system crashes of this nature have nothing to do with the hardware. Once
you get to the blinking floppy disk icon, you can assume that the machine is OK If your
computer restarts after this point, the problem is most likely with the system folder. It may
also fail if you only have 512K RAM installed.”
The full document is here:
ftp://ftp.apple.asimov.net/pub/apple_II/documentation/applelisa/Lisa_Do-It-Yourself_Guide.pdf
Hope this helps,
Rick