Apple2 (diskiing, diskiiiwm): cannot boot ProDOS 2.5 floppy image

[leesaudan2]

The Apple II emulation (apple2, apple2p, apple2e, apple2ee, apple2ep, apple2gs) fails to boot ProDOS 2.5 floppy image when emulating floppy drives with diskiing and diskiiiwm.

To repeat

Download the ProDOS 2.5 floppy image (.dsk format), and boot with command:

mame apple2ep -flop1 ProDOS_2_5_a8_143k.dsk

Instead of booting into ProDOS 2.5 menu, one gets thrown into the
monitor:

099F-       A=AE X=FF Y=FF P=B4 S=F9
*




PRODOS
.

This happens to floppy controllers emulated by diskiing as well as diskiiiwm. However, switching to diskii, the problem goes away and ProDOS 2.5 boots up and shows the menu!

Diagnosis

I have traced the booting process with the help of -debug, and found that the system successfully loads the boot sector (256 bytes) into memory region $800-$8FF. The code there (entry point: $801) then takes over, and tries to load the 2nd stage loader (3 more sectors) into $900--$BFF. However, these 3 sectors are not loaded correctly. When the boot sector code finally transfers control to the 2nd stage loader by jumping to address $99E, a zero byte is there. This is the 6502 opcode for BRK, which causes the monitor ROM code to take control and show the "*" prompt

I have done a similar tracing in another Apple II emulator linapple. It correctly loads the second stage loader into $900-$BFF and transfers the control there properly to complete the boot process, showing the ProDOS 2.5 menu.

Further tracing of the loading process in the emulated machine reveals that the nibbles being read by the emulated code in MAME are different from those in linapple, suggesting that MAME is generating the wrong nibbles. Since the .dsk format stores the disk data in high-level bytes, which get converted into nibbles (actually a bit stream reflecting magnetic flux changes) by MAME to emulate the floppy media, I suspect that the culprit is in MAME's nibbilization code.

To verify this, I have converted the .dsk file into WOZ2 format using a tool called dsk2woz2. This format stores the disk data as bitstreams reflecting magnetic flux changes. Using MAME with the resulting .woz file, ProDOS 2.5 successfully boots up and shows the menu.

[galibert]

I suspect wrong sector order due to the code not recognizing the disk is prodos. RB? OG.

…

On Tue, Jan 26, 2021 at 2:11 PM leesaudan2 ***@***.***> wrote: The Apple II emulation (apple2, apple2p, apple2e, apple2ee, apple2ep, apple2gs) fails to boot ProDOS 2.5 <https://prodos8.com/releases/prodos-25/> floppy image <http://prodos8-releases.s3-website-us-east-1.amazonaws.com/ProDOS_2_5_a8_143k.dsk> when emulating floppy drives with diskiing and diskiiiwm. To repeat Download the ProDOS 2.5 floppy image (.dsk format), and boot with command: mame apple2ep -flop1 ProDOS_2_5_a8_143k.dsk Instead of booting into ProDOS 2.5 menu, one gets thrown into the monitor: 099F- A=AE X=FF Y=FF P=B4 S=F9 * PRODOS .. This happens to floppy controllers emulated by diskiing as well as diskiiiwm. However, switching to diskii, the problem goes away and ProDOS 2.5 boots up and shows the menu! Diagnosis I have traced the booting process with the help of -debug, and found that the system successfully loads the boot sector (256 bytes) into memory region $800-$8FF. The code there (entry point: $801) then takes over, and tries to load the 2nd stage loader (3 more sectors) into $900--$BFF. However, these 3 sectors are not loaded correctly. When the boot sector code finally transfers control to the 2nd stage loader by jumping to address $99E, a zero byte is there. This is the 6502 opcode for BRK, which causes the monitor ROM code to take control and show the "*" prompt I have done a similar tracing in another Apple II emulator linapple <https://github.com/linappleii/linapple/>. It correctly loads the second stage loader into $900-$BFF and transfers the control there properly to complete the boot process, showing the ProDOS 2.5 menu. Further tracing of the loading process in the emulated machine reveals that the nibbles being read by the emulated code in MAME are different from those in *linapple*, suggesting that MAME is generating the wrong nibbles. Since the .dsk format stores the disk data in high-level bytes, which get converted into nibbles (actually a bit stream reflecting magnetic flux changes) by MAME to emulate the floppy media, I suspect that the culprit is in MAME's nibbilization code. To verify this, I have converted the .dsk file into WOZ2 <https://applesaucefdc.com/woz/reference2/> format using a tool called dsk2woz2 <https://github.com/mr-stivo/dsk2woz2>. This format stores the disk data as bitstreams reflecting magnetic flux changes. Using MAME with the resulting .woz file, ProDOS 2.5 successfully boots up and shows the menu. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7707>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGSF4P6Y34RFVXTJAVXVHLS325RPANCNFSM4WTNV2JA> .

[rb6502]

Correct. The usual workaround for this is that files are named .do or .po to indicate sector order, which is why I've complained in the past that new-style format handlers can't see the file extension.

In this particular case something else is wrong because we do already recognize the ProDOS 2.5a8 image and set it to ProDOS order, except a2_16sect_format doesn't seem to be what's loading the image now (or at least a printf put in it doesn't show).

[peterferrie]

It's failed to identify it correctly as ProDOS and is using DOS-ordering instead of ProDOS-ordering. I can look into it.

[leesaudan2]

I suspect wrong sector order due to the code not recognizing the disk is prodos. RB?
OG.

No, I don't think so. AppleCommander reports:

Archive Order: DOS 3.3
Disk Format: ProDOS

on this .dsk file. So, I think the file does organize the sectors in DOS order, although the contents constitute a ProDOS filesystem.

[leesaudan2]

It's failed to identify it correctly as ProDOS and is using DOS-ordering instead of ProDOS-ordering. I can look into it.

I think it's the other way around. The sectors are DOS-ordered (see my previous comment), but MAME misidentified it as ProDOS-order.

I have been studying the code for many hours. Now that you've pointed out the .do vs .po problem, I remember having seen the code for identifying the order based on contents (instead of filename). I've located the following code in ap2_dsk.cpp (lines 651--654 as of 3ec3d5a):

			else if (!memcmp("PRODOS", &sector_data[0x40], 6))
			{
				m_prodos_order = true;
			}

and this matches the data in that ProDOS 2.5 .dsk file!

[leesaudan2]

I've done one simple test to confirm my finding in the comment above:

1. I made a copy of the ProDOS 2.5 dsk image. Call it test.dsk.
2. Using a hex editor, I changed PRODOS at file offset 0x0040 to PRODOT.
3. I've also changed PRODOS in the root directory to PRODOT, at file offset 0x0b2c.
4. mame apple2ep -flop1 test.dsk.

Now, it boots successfully!

This confirms that MAME is checking for the string PRODOS at file location 0x0040 to determine if it is a ProDOS-ordered image. Changing this name defeats this detection (but not the boot-strapping code). Now, MAME treats it as a DOS-ordered image and boots correctly.

So, we need more robust (and complicated) tests for the sector ordering of disk images. Just checking for the string PRODOS in the boot sector isn't sufficient. It only tells that the filesystem inside the image is (probably) ProDOS. It doesn't tell the sector ordering reliably. One suggestion is to scan the root directory for valid entries. I think linapple does this, as I've examined its code a few weeks ago. It checks for the "linked list" of sectors/blocks comprising the root directory of DOS or ProDOS. (It also uses the filename extension as another source of hint.) Since MAME now uses a scoring system from 0 to 100 (linapple uses only 0, 1 and 2), it could potentially do a better detection. Of course, I agree with RB, that having the filename (or at least the extension part) would be very very helpful!

[leesaudan2]

One more test...

Using disk2woz2 and then woz2dsk, I've converted the ProDOS 2.5 image into an ProDOS-ordered image. This latter works correctly in MAME! 😃

[peterferrie]

This confirms that MAME is checking for the string `PRODOS` at file location 0x0040 to determine if it is a ProDOS-ordered image. Changing this name defeats this detection (but not the boot-strapping code). Now, MAME treats it as a DOS-ordered image and boots correctly.

Right, but checking sector 0 is insufficient to determine the sector ordering. We'd need something instead from one of the sectors that moves (i.e. not 0, 5, A, or F).

[timriker]

This image boots on AppleWin. Copying it over to a real apple with ADTPro and burning to floppy also works. Does anyone have a replacement that correctly identifies sector order?

[galibert]

Just use a po or do extension as appropriate. OG.

…

On Thu, Jul 28, 2022 at 12:36 PM Tim Riker ***@***.***> wrote: This image boots on AppleWin. Copying it over to a real apple with ADTPro and burning to floppy also works. Does anyone have a replacement that correctly identifies sector order? — Reply to this email directly, view it on GitHub <#7707 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGSF4L42HZU52U6I7HWM2LVWKZJ3ANCNFSM4WTNV2JA> . You are receiving this because you commented.Message ID: ***@***.***>

[timriker]

renaming the ProDOS 2.5 image to:
ProDOS_2_5_a8_143k.do
still fails to boot. Converting it to ProDOS sector order with CiderPress does get it to boot, or using the older diskii driver.
It looks like even though it's a .do file it still does the auto-identification, which is different than other emulators.

[peterferrie]

The sector-ordering heuristic is failing, and even though it's .po, we're reading the wrong sectors.

[timriker]

Copying the disk over to real hardware with ADTPro and then back to a .dsk still gets this ProDOS disk in DOS order.
It fails to boot as a .dsk and renaming the file to a .do, still fails to boot.

[galibert]

The heuristic is supposed to be taken into account only if the extension is not po or do. OG.

…

On Thu, Jul 28, 2022 at 4:48 PM Peter Ferrie ***@***.***> wrote: The sector-ordering heuristic is failing, and even though it's .po, we're reading the wrong sectors. — Reply to this email directly, view it on GitHub <#7707 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGSF4LEXKJY2FWSPX34NJDVWLWZNANCNFSM4WTNV2JA> . You are receiving this because you commented.Message ID: ***@***.***>