apple: diskiing/iwm corruption

[arekkusu42]

MAME version

0.282 @ 64ec4fb

System information

arm64 macos Sonoma 14.8.1, M3 Max MacBook Pro, Mac15,8

Emulated system/software

apple2e*, apple2c*

Incorrect behaviour

apple2 machines corrupt 5.25" disks when writing, resulting in the disk becoming unusable. This only affects machines using clock rates different from the default 1021800 Hz.

Once a disk is corrupted:

• it no longer boots
• CiderPress2 can't catalog it ("Unable to recognize disk image contents")
• booting from a good disk with the corrupt disk as -flop2: CAT,D2 produces "I/O ERROR"

In a DEBUG=1 build, machines using the diskiing emulation hit the assert recently added to wozfdc_device::lss_sync(). In a DEBUG=0 build, proceeding past this assert while writing to a disk results in corruption (read-only access seems to work OK.)

Expected behaviour

• all apple2 machines (regardless of 60/50Hz, or Zip Chip settings) should not corrupt disks
• unless using a Zip Chip, and software disables the slot6 delay, then all bets are off

Steps to reproduce

You can eventually reproduce this by booting ProDOS to BASIC, typing 10 REM and SAVE FOO <repeat as needed>, but for the sake of easy reproducibility and burn-in testing, here are more explicit steps:

1. boot A COPY OF Apple IIe Diagnostic v2.1 (this disk is IIc-aware)
2. c Choose Tests, <return>
3. (e/f) Disk (Card/Port) Test, <return>
4. a Disk (Card/Port) Test, <return>, <esc>, <esc>
5. d Options, <return>
6. a Loop Tests Until ESC is Pressed, <return>, <esc>
7. b Execute Selected Tests, <return>

Additional details

Here are some results, across a slice of machines using different disk emulation, with different clock speeds:

machine		disk			options				result
-------		----			-------				------
apple2ee	diskiing							100 iterations OK
apple2ee	"				<Zip Chip enabled>	asserts after 2-3 iterations
apple2eede 	"									asserts 1 second into boot
apple2c 	A2BUS_DISKIING						100 iterations OK
apple2c 	"				<Zip Chip enabled>	asserts after 2-3 iterations
apple2c 	"				-nothrottle 		100 iterations OK
apple2cfr	"									asserts 1 second into boot
apple2c0 	A2BUS_IWM							100 iterations OK
apple2c0 	"				<Zip Chip enabled>	100 iterations OK
apple2c0de	"									ProDOS error after 1 iteration, disk corrupted
apple2cp	IWM				<built-in Zip>		100 iterations OK
apple2cp	"				-nothrottle			100 iterations OK
apple2gs	IWM									100 iterations OK
apple2gs	"				<Zip Chip 16 MHz>	100 iterations OK

(apple2gs using -flop3 "Apple IIgs Diagnostic v3.1" instead)

From these results, we can see:

• 50 Hz fr/de/etc machines immediately corrupt disks when writing
• 60 Hz machines also corrupt disks if configured to use the 4 MHz Zip Chip, but this happens more slowly than the 50 Hz machines
• The //c+ and IIgs work with the Zip Chip (edit: see additional testing below)
• The diskiing emulation catches the corruption with an assert, but corruption can also occur with the A2BUS_IWM emulation, where there is no assert

Occurs with:

• local build of master (circa Nov 3 2025 @ 64ec4fb)
• local build of mame0279 tag (circa Jul 30 2025)
• local build of mame0229 tag (circa Feb 23 2021) (using apple2ee Zip Chip, but not with apple2eefr, prior to ff5b73b)

(using buildenv: arm64 macos Sonoma 14.8.1, Apple clang version 15.0.0 (clang-1500.3.9.4) per vanilla Xcode 15.4, no homebrew/MacPorts)

Corruption in 0.282, apple2c0de:

Corruption in 0.229, apple2ee with Zip Chip:

[arekkusu42]

I looked at this a little, but haven't understood it yet. Disclaimers up front:

• unlike the 6502 and apple2 video, I didn't spend my childhood poking the guts of the floppy drive; it is alien to me.
• I have only a rough understanding of MAME's scheduler, and the interplay between timer callbacks and device execution.

Adding instrumentation and using apple2eede as an easy reproducer, what I see happening is:

execute_timers: timer callback wozfdc_device::generic_tick
time() in callback, returning 1.710000000
WOZFDC lss_sync() clock 2043600 time 1.09DA6D3CFE870000 extra 0, limit 3494556, cycles 3494541, cycles_next_flux 3494541, down 3494542
WOZFDC generic_tick completed
WOZFDC read
time() in device, returning 1.709999154
WOZFDC lss_sync() clock 2043600 time 1.09DA6C7819A22535 extra 0, limit 3494554, cycles 3494556, cycles_next_flux 3494557, down 3494558
Assertion failed: (cycles <= cycles_limit), function lss_sync, file wozfdc.cpp, line 413.

The device time() has gone backwards, relative to the earlier completed callback time(). The cycle counts are reproducible run-to-run.

If I then start hacking diskiing_device to use PAL-appropriate clocks, the timing changes but the assert is still hit slightly later:

execute_timers: timer callback wozfdc_device::generic_tick
time() in callback, returning 2.010000000
WOZFDC lss_sync() clock 2031314 time 2.002386F26FC10000 extra 0, limit 4082941, cycles 4082927, cycles_next_flux 4082936, down 4082937
WOZFDC generic_tick completed
WOZFDC read
time() in device, returning 2.009999438
WOZFDC lss_sync() clock 2031314 time 2.0023866FC4D18BEC extra 0, limit 4082940, cycles 4082941, cycles_next_flux 4082960, down 4082961
Assertion failed: (cycles <= cycles_limit), function lss_sync, file wozfdc.cpp, line 413.

Or, if I revert the PAL clocks, and instead slightly change the config via -aux "", the timing changes again:

execute_timers: timer callback wozfdc_device::generic_tick
time() in callback, returning 0.950000000
WOZFDC lss_sync() clock 2043600 time 0.0D2F13F7789F0000 extra 0, limit 1941420, cycles 1941389, cycles_next_flux 1941391, down 1941392
WOZFDC generic_tick completed
WOZFDC read
time() in device, returning 0.949999311
WOZFDC lss_sync() clock 2043600 time 0.0D2F135735663A23 extra 0, limit 1941419, cycles 1941420, cycles_next_flux 1941423, down 1941424
Assertion failed: (cycles <= cycles_limit), function lss_sync, file wozfdc.cpp, line 413.

What I think this means is:

• a machine has several executable devices and timers
• changing any one of them affects the scheduler quanta for all of them (like a beat frequency shifting)
• the wozfdc_device quantum changing then gets it into this situation where the device time and the callback time no longer align

But... is that a scheduler problem? A wozfdc_device problem? Help from someone who knows these areas would be appreciated.

Also, reading the code, there are a few related things that Look Wrong:

1. both the 7M and Q3 clocks should be passed from a2 machines to a2bus devices, so they can use values derived from the machine-appropriate master XTAL, instead of hard-coding A2BUS_7M_CLOCK, 1021800 etc.
2. the hard-coded values 1021800 (NTSC) and 1016966 (PAL) are also slightly wrong. The master XTALs visible in motherboard photos are:
   14.318181 "197-0001" (NTSC)
   14.25045 "197-0002" (PAL IIe)
   14.24982 "CK0044AC" (PAL IIc)
   7M and COLOR_REF are divided from these. Q3, PH0/PH1 can be approximated by the average clock after stretching, for example PH0:
   m_1M = (m_14M / (14 + 2.0 / 65))
   which produces these more-correct approximations:
   1020484 (NTSC)
   1015657 (PAL IIe)
   1015612 (PAL IIc)
   Correcting this would change the NTSC video rate from 60.0 Hz to 59.92 Hz, which is more accurate, but creates a user education issue for everyone using modern displays.
3. various a2bus devices hard-code various clocks (1021800, 1020484, 1022727) which should be audited to use Q3/PH0/PH1 as appropriate.

That's not to imply that any of those are the root cause; only related things to think about.

[rb6502]

It's actually highly likely the problem is 100% just that PH0, Q3, and 7M aren't passed through the bus.

[arekkusu42]

Hmm... I've tried correcting for that, though, in my "PAL-appropriate clocks" paste above. I hard-coded the m_maincpu clock, 7M, and Q3 throughout apple2e, diskiing_device, a2bus_iwm_device to consistent PAL values.

Also, that wouldn't explain the Zip Chip problems, would it? The 4'000'000 clock there temporarily resets to 1021800 around slot6 access, but it still intermittently breaks.

[rb6502]

Oh, really? That's interesting. As far as I know if all the clocks match it should work fine. Might need @galibert for this.

[arekkusu42]

Possibly related issue #14477 with Mac IWM.

[arekkusu42]

Additional testing shows intermittent disk corruption on apple2gs when using the ZipGS:

1. boot A COPY OF XPS Diagnostic IIe 1.0.5
2. G) DISK SYSTEM, let run until PASS 10+ (will have SEEK errors)
3. L) MEDIA VERIFY, let run until PASS 1+ (will error on last TRACK)
4. if corruption didn't occur, reboot, repeat from step 2 several times
   (Quit/relanch MAME around changing the Zip Speed or CDA System Speed)

Corruption is intermittent, but occurs after a few tries with any ZipGS clock speed:

apple2gs    1 *   2.8 √             7 X     8 X    12 X    16 X
apple2c0    1 *             4 *

*: SPEED errors instead of SEEK errors, but no corruption

X: disk corruption
   G) READ errors in addition to SEEK
   L) MEDIA VERIFY shows error with tracks 0, 34 and 35
and the disk is corrupt: crashes on boot, and can't be cataloged.

I could not reproduce the ZipGS corruption after fixing the 1 MHz clock, in PR #14495:

apple2gs    1 *   2.8 √             7 √     8 √    12 √    16 √

The PAL problems still need to be root-caused.

[ajrhacker]

I accidentally stumbled upon a very reliable way to trigger this assert on my debug build: start to boot apple2_flop_orig:bswenhtutiip on any system on which it does or doesn't boot, abort with Ctrl-Reset, then resume with PR#6 or the equivalent monitor command.

[arekkusu42]

I think triggering the assert is as simple as:
./mame apple2eede -flop1 <any disk>