BMOW Quality Control Breakdown
I need a QA team with a suite of regression tests! The BMOW Floppy Emu disk emulator supports many different emulation modes, disk image types, and usage scenarios, so it’s easy to break something without realizing it. If I break something big and obvious that escapes my testing, people will complain and let me know there’s a bug. But if I break something more subtle, I might not realize it for a long while. A very long while.
Today I discovered that writing to a 1440K Macintosh disk image has been very buggy since 2019. It sort of half worked, but it was very slow because the Mac was doing a huge number of retries for each sector write. If you tried copying a large file onto a 1440K disk, it would fail about 20 percent of the time with “a disk error occurred”. After the December 1 firmware update that introduced MOOF support, the situation got even worse, and attempts to copy a large file onto a 1440K disk would almost always fail. But nobody ever reported a problem, and I didn’t realize anything was wrong.
Thank God for revision control systems. I was able to walk backwards through a huge number of past changes in the firmware code, attempting to isolate where the bug first occurred. This was incredibly tedious because prior to the recent MOOF changes, the 1440K writes sort-of-worked well enough that I needed to try many separate file copies and count how many succeeded and failed before I could be sure whether the bug was present. It took about 10-15 minutes per changelist, and there were a LOT of changelists. The whole process filled nearly an entire day.
And the guilty change was: OLED dimming. This change was made in May 2019. To prevent screen burn-in on the OLED display, the firmware dims the brightness after 30 seconds of inactivity. There’s a bit of code that happens after every sector that says “Has the dimming timer overflowed? Has it been 30 seconds yet?” This code was just slow enough to break the Floppy Emu’s real-time guarantee and introduce a burp into the 1440K MFM bitstream between each sector and the next one whenever the timer overflowed. While recently adding MOOF support to the firmware, I switched the dimming logic to use a different hardware timer so that I could use the original timer for MOOF purposes, and this exacerbated the MFM burp problem. The burp caused sector verifications to frequently fail after writing to the disk, resulting in a huge number of errors and retries.
Honestly I’m not sure why the burp is even an issue, since there are sync bytes before each sector that should resynchronize the Mac’s disk controller if it was thrown off by the burp. But it clearly is a problem. I made a simple change to skip the check for dimming while the disk motor is on, and it’s a night and day difference. Copying files to 1440K disks is not only 100 percent reliable now, but it’s also about twice as fast as before. Look for a new firmware release with this fix and other changes soon.
Read 4 comments and join the conversation4 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
I finally discovered the true root problem here, and it was a 9-year-old bug! There’s a bit of logic in the CPLD that will introduce an extra sync byte if the microcontroller isn’t ready to provide a byte, to prevent an underrun. But this logic was buggy and would sometimes introduce a sync byte with an invalid MFM clock bit. Since this happened before reaching the good sync bytes at the start of the next sector, the Mac’s disk controller freaked out and thought an error occurred.
After fixing this, the change to OLED dimming is no longer necessary and 1440K disk emulation works sooooo much better than before.
…. After the December 1 firmware update that introduced MOOF support, the situation got even worse, and attempts to copy a large file onto a 1440K disk would almost always fail. But nobody ever reported a problem, and I didn’t realize anything was wrong……….
hihihihihi
– may be i may be the first one with reporting over this problem by report over the small 2 pixel bug and sometimes fatal error copying bigger programms from HDD to EMU
last week i also had this problem copying bigger programms from HDD to EMU in HD20 ! – error – copy stopps, must do EMU reset and try to copy again – somtimes 3 times till same programms copyed complete and sucessfull – mayby there is same M1400 copy problem im Mac HD20 mode ???
i will install the newest firmware and will see if these copy problems are hopely gone
greetings
————————————
NT-Tom – November 25th, 2022 1:40 pm
Hi, im use this little thing since 1 week and make my first experience and have much fun with the HD20 fast copy 100MB space on my Macs
new firmeware 221122M i think i foud a little, little bug with the display mode – select normal display, in settings ,then restart , then select HD20, then resart boot 6.0.2 –
the display is jumped in jumbo mode – showing Mac HD 100 and logo , but left missing 2 pixels , right 2 pixels line but this is only a little optical fail
some times i get a fatal error coying bigger files to the HD20 like hundrets of letter files from my Mac HDD – is this a reading error of the original files or too much little single files try to copy ?
again i want to say i have so much new fun with the this EMU and my 16! Macs
greetings MacMadTom
———————————-
Steve – November 26th, 2022 7:55 am
Thanks, I’ll check out that 2-pixel error with the Mac firmware. Except for the UI, Mac hard disk mode hasn’t changed in this firmware. There’s no limit on the number or size of files beyond the normal HFS filesystem limits. It sounds like the disk I/O isn’t working quite right, maybe due to a minor hardware problem, and you’re getting occasional I/O errors. You might try copying files in smaller batches as a work-around.
The problem described here was specific to 1440K MFM disk emulation.
Hi Steve,
I’d be happy to volunteer to be a part of the QA team for Floppy Emu stuff. I have two devices, currently, one I use for Apple II stuff, mostly on a IIc (that has ROMxc installed, usually running the ROM5X image), and another I use for Mac stuff, mainly on an SE. I know the Apple one is a Model C, I’m not sure offhand if the Mac one is a C or a B. I typically use a number of the different modes on my Apple //c, including 5.25, Smartport HDD, Smartport 3.5. I have the older internal/external switch so haven’t been able to try dual drive mode, but as I’ve recently ordered the newer switch version with the dual-mode toggle, I look forward to trying it soon. And of course I’m happy to run tests in modes that I don’t personally use as frequently, but am capable of.