As promised when I released the LisaFPGA boards, I've gotten to work on ESFloppy after my break from the project, and I have some really good progress to report.
Sony 400K/800K emulation is fully-working at this point, with reads, writes, and formats tested in every Lisa OS/environment that I could get my hands on. And it appears to be faster than the Floppy Emu too, which has noticably-longer seek times.
Twiggy emulation is also pretty much done. As far as I know, this is the first emulator capable of emulating a Twiggy, so I'm pretty excited about this! Reads, writes, and formats are fully tested and working on Twiggy, and while it can only emulate the lower Twiggy drive right now, the full framework is in place to add upper drive capability so that both can be emulated simultaneously. This should honestly be quite easy to add; it'll likely be done by today or tomorrow.
Twiggy emulation was significantly harder than I expected for a variety of reasons. Even though Twiggy uses the same sector encoding as Sony, just with a different track count and different numbers of sectors per track, it's got some seriously-annoying quirks:
- This one's probably pretty obvious to anyone who's worked with Twiggies before: Given the odd positioning of the heads, when one head is on track T of the disk, the other one is on track 45-T, so you have to read in two separate tracks from the disk image for each seek. And to make matters worse, in the vast majority of cases, each side will have a different number of sectors too...
- Twiggy has a set of "speed sync" bytes that have to be sent out before sector 0 on each track that the controller uses to fine-tune the spindle speed before a format op. This isn't present on Sony at all.
- Twiggy has a weird "track -1" that's used as a timing track during a format. Before the format begins, the controller seeks to track -1 and writes a pattern of 14 sectors, then 15, and then 21, measuring and adjusting the disk speed each time. This requires making a "dynamic track" that allows storage of different numbers of sectors instead of hard-coding it to the expected number of sectors per track like you can for all the others.
- During a format, the Twiggy controller expects each track to take a very specific amount of time between consecutive starts of sector 0. If the track is too long or too short, the format will fail. On an emulator, you generally want to send data out as quickly as possible with minimal padding in between sectors (which works fine on Sony), but on Twiggy you're forced to use very specific (and different) amounts of padding on each track to ensure that the track time is exactly what the controller expects.
- And that just scratches the surface!
Here's a video showing the Twiggy emulation in action; I didn't bother making a video about Sony emulation since that's boring by comparison: https://www.youtube.com/watch?v=8sN7Cv-MONM
The big thing left to do (after I emulate the upper Twiggy) is to make the UI that runs on the OLED. This won't really be hard (the hard part was all of the optimization necessary to get the actual disk routines to run fast enough), but it will certainly be tedious, and will probably take a little while.
Very cool thank you!
Genuinely incredible, Alex! Wow!