AppleWin
AppleWin copied to clipboard
AppleWin
WOZ: Phantasie fails to boot
AppleWin version : 1.30.17.0 OS version : Windows 10 22H2 Emulating : Apple IIe, Apple II+, Enhanced
The attached WOZ for Phantasie does not boot in AppleWin. It does boot in MAME (251, 262). Bonus: It does make quite the interesting sound when booting with Enhanced Disk Access on. After saving the game in MAME and booting again in AppleWin, it still fails to boot, but without the same sound as mentioned above.
Thanks for all your hard work!! I have very much enjoyed AppleWin over the years.
A couple other notes I forgot to include.... I did try altering the Optimal Bit Timing, I did not find a value that allowed it to work. The other interesting thing, (at least to me), is that I can use this WOZ with AppleWin and 4am's Passport to create a working cracked DSK image. This DSK is identical to a DSK image I created doing the same in MAME.
Thanks - so far, I've confirmed what you are seeing. I'll dig into this and share what I find here.
Bonus: It does make quite the interesting sound when booting with Enhanced Disk Access on.
Yeah, the sound should be muted when running at full speed (ie. when the drive's motor is on in "Enhance disk access" mode). Just ignore this for now.
Thanks for all your hard work!! I have very much enjoyed AppleWin over the years.
No problem and thanks for your feedback! :-)
The other interesting thing, (at least to me), is that I can use this WOZ with AppleWin and 4am's Passport to create a working cracked DSK image.
The disk has a weak-bit protection check that AppleWin isn't emulating correctly. Passport is detecting the protection check, and just patching the routine so that it always passes.
Some quick notes...
The weak-bit protection check is at $300 after the game has loaded sectors from tracks 0-2:
0300:AE F1 BA LDX $BAF1 BAF1:60
0303:BD 89 C0 LDA ROMIN1,X C0E9:00 ; motor on
0306:A9 00 LDA #$00
0308:20 1E BD JSR $BD1E ; Seek
030B:A9 00 LDA #$00
030D:85 00 STA GOWARM 0000:00
030F:C6 00 DEC GOWARM 0000:00
0311:F0 17 BEQ $032A 032A
0313:20 65 BC JSR $BC65 ; ReadNextSectorAddr
0316:B0 F7 BCS $030F 030F
0318:C1 00 CMP (GOWARM,X) FFFF:C3
031A:C1 00 CMP (GOWARM,X) FFFF:C3
031C:EA NOP
031D:EA NOP
031E:BD 8E C0 LDA LCROMIN1_,XC0EE:00 ; set read mode
0321:BD 8C C0 LDA LCRAMIN1_,XC0EC:00 ; read latch
0324:10 FB BPL $0321 0321
0326:49 EE EOR #$EE #-18
0328:D0 E5 BNE $030F 030F
032A:85 00 STA GOWARM 0000:00 ; must be $00 to allow game to boot
032C:60 RTS
Nibbles read by ReadNextSectorAddr: D4 AA B7 FF FF AA AA AA AA FF FF DE AA(1) ... next nibbles are: 85 DD F9
NB: $85 isn't a valid nibble - it has a run of 4 consecutive 0's!
The nibble & bitstream looks like this:
DE AA (1)85 DD F9
1101 1110,1010 1010 0,1000 0101,1101 1101,1111 1001
1 1101 110
EE
And the protection check is expecting to read $EE. But $EE starts from bit0 of "nibble" 85... and I can't see how the weak-bits are coming into play here.
FWIW, I tried MAME:
- 0.260 fails everytime like AppleWin
- 0.262 works ~50% of the time
When it works for MAME:
- $31E latch read (via set read mode): 86
- How can it read 86? (1000 0110) Weak bits should randomly set the 3rd/4th zero, so the nibble becomes eg. 95 or 8D.
- NB. there's nothing special about "set read mode", it could equally be another "read latch"
- $321 latch reads: 01 07 1d 77 ee
Looking at Epidemic!, another SSI game with the same protection... (From Passport's test suites, here)
Here, the nibble pattern makes more sense:
D4 AA B7 FF FF AA AA AA AA FF FF DE AA 80(3)EE FC
This has "80(3)" which is a 1 bit followed by 10 zeros. Nibble copiers will read random 1's after the first 4 zeros, and then lose sync, so that they won't read $EE correctly.
I found another Epidemic! on Internet Archive. This one looks dodgy:
D4 AA B7 FF FF AA AA AA AA FF FF DE AA 82 EE FC
I'm suspicious now, wondering if any of these SSI .woz images are actually correct around this weak-bit protection area.
@LanHawk4 - where did you get your Phantasie.woz from?
Passport is detecting the protection check, and just patching the routine so that it always passes.
Yes, I assumed something along those lines was happening as it wasn't trying to "boot", just evaluating the nibbles as they come by.
0.260 fails everytime like AppleWin 0.262 works ~50% of the time
Interesting, I have not had it fail yet with 0.262. I have booted it at least 10 times. (plus at least 5 more since I saw your message.) Nor has it failed using 0.251. Although I haven't booted with that version nearly as much. But I do get 100% failure with 0.260.
@LanHawk4 - where did you get your Phantasie.woz from?
I created it myself from this A2R: https://archive.org/download/sdancer_a2rs > Phantasie-Boot-Copy2.a2r
There are other A2R available, but each of those seems to display an issue in AppleSauce, so I went with the one above as it was clean.
4am has a WOZ version available along with his cracked version here: https://archive.org/details/Phantasie4amCrack > Phantasie (4am and san inc crack) extras/Phantasie.woz But that is from 2018 and is WOZ version 1. It does not work in AppleWin nor MAME.
I'm suspicious now, wondering if any of these SSI .woz images are actually correct around this weak-bit protection area.
@tomcw I think you are correct in regards to the SSI disks. Per 4am: "In general Applesauce is very good at detecting and normalizing regions without flux transitions ("weakbits" protection). There are some disks from SSI and Sierra where the region is so small that Applesauce can sometimes miss it."
He had indicated that he had to manually manipulate some of the WOZ images he created for it to work. So I think you can probably close this issue if you want.
Thanks - that's very interesting info from 4am! Where did he say?
I created it myself from this A2R: https://archive.org/download/sdancer_a2rs > Phantasie-Boot-Copy2.a2r
Did you use a2woz to convert it?
Thanks - that's very interesting info from 4am! Where did he say?
I believe that was in the AppleSauce discord.
Did you use a2woz to convert it?
No, I created the woz using the AppleSauce software. I am going to attempt to create a modified woz file myself that has more proper timing and see if that works in Mame 0.260. So maybe leave this open until I can create a "proper" one and verify that it works (or not) in AppleWin.
I created another WOZ, attached. Phantasie-Boot-Copy2.zip This one I created with Track 0 marked as "Track Requires Flux Accuracy". It works in all 3 versions of MAME I have tested: 0.251, 0.260, 0.262. And sorry to say, it does not work in AppleWin.
The current version of AppleSauce does not seem to have the issue it used to have in dealing with SSI weakbits. That 4am info about SSI and weakbits was from almost 2 years ago.
Thanks for this new flux (for track-0) image. This gives me more impetus to support woz flux tracks.
The previous version works with both Mame 0.262 and Accurapple. Both of them supports Woz Flux tracks. The new Phantasie-Boot-Copy2 however do not work with Accurapple. It is also not working using CrossRunner, (an Apple 2GS emulator) that also supports Woz flux tracks. Maybe more flux tracks are required.
Maybe more flux tracks are required.
No - the protection is only on track 0 (so only track 0 needs to be represented as flux).
I know this, because if I:
- set a breakpoint at 300 and wait for it to hit
- then apply the Passport patch (
30f: a9) - go
Then the game boots (and the breakpoint at 300 never fires again)
The straightline cycle count from immediately after reading the $AA nibble (at $BCB6) to reading the first read latch (at $31E) is 36 cycles (or 9 disk bitcells):
BCB6:BD 8C C0 LDA LCRAMIN1_,XC0EC:00
BCB9:10 FB BPL $BCB6 BCB6
BCBB:C9 AA CMP #$AA #-86
BCBD:D0 A4 BNE $BC63 BC63
BCBF:18 CLC
BCC0:60 RTS
;
0316:B0 F7 BCS $030F 030F
0318:C1 00 CMP (GOWARM,X) FFFF:C3
031A:C1 00 CMP (GOWARM,X) FFFF:C3
031C:EA NOP
031D:EA NOP
031E:BD 8E C0 LDA LCROMIN1_,XC0EE:00 ; set read mode
36 cycles (or 9 disk bitcells) isn't long enough when (from the woz, non-flux track) we have:
Epidemic (passport test disk): 11 bitcells, ie "80(3)" D4 AA B7 FF FF AA AA AA AA FF FF DE AA 80(3)EE FC
Phantasie (4am and san inc crack): 10 bitcells, ie. "80(2)" D4 AA B7 FF FF AA AA AA AA FF FF DE AA 80(2)EE
But from the flux track-0, we have: (hard to represent visually!)
flux: 41 3d 41 3d
bits: 0 1 01 01 01 0 ; final 0 is from next 5d
nibbles: AA
flux: 5d 98 48 ; Total Sum = 0x11D - 0x20 (285). 285/8 = 35.625ms
bits: 01 00001 01
nibbles: (0) 85
flux: 1f 23 3d 21 1f 3f
bits: 1 1 10 1 1 10
nibbles: EE
You can see from the flux between nibbles AA and EE (ie. 5d 98 48) that there are some shorts 0 bitcells here.
Here the timing gap between AA and EE is 35.625ms, so sometimes after reading AA, then the 36 cycle gap means that the latch will start reading the EE nibble.
EDIT: @univta0001 points out a few comments below that the decoding of the last flux data is DD (and not EE). (The timing info is still correct, it's just that final EE nibble that's wrong, and also the final flux values of 3d and 3f should be bits 01.)
Hi, i have managed to make Phantasie-Boot.zip to work in AppleWin by patching the following bytes in the WOZ file
- Patch byte offset 0xc53 from 0xBB to 0xBD
- Patch byte offset 0xc54 from 0xBF to 0xCF
- Fix the checksum at offset 0x8 from (0x37095c9c) to (0xf96ecdb5)
This patch will generate the 0xEE from the read latch as required. Here how the patched works, the game detects for 0xAA, skip one byte and expect 0xEE. The disk byte is located at offset 0xc51 in the woz image
Before Patch
0xc51 0xc52 0xc53 0xc54
0xaa 0x90 0xbb 0xbf
10101010 10010000 10111011 10111111
^ ^ ^
The bytes decoded indicated are 0xaa (0x10101010), 0x85 (0x0x10000101) and 0xdd (0x11011101)
After Patch
0xc51 0xc52 0xc53 0xc54
0xaa 0x90 0xbd 0xbf
10101010 10010000 10111101 11001111
^ ^ ^
The bytes decoded indicated are 0xaa (0x10101010), 0x85 (0x0x10000101) and 0xee (0x11101110)
Attached is the patched WOZ (Patched Phantasie-Boot.zip)
In the provided, WOZ image with Flux Track, the description from Tom seems on the following seems wrong
flux: 1f 23 3d 21 1f 3f
bits: 1 1 10 1 1 10
nibbles: EE
The decoded value is 0xDD and not EE
I think the flux image should have been
flux: 1f 23 21 3d 1f 1f 3f
bits: 1 1 1 01 1 1 01
nibbles: EE
I have attached the patch WOZ image (Patched Phantasie-Boot-Copy2.zip) that works with Crossrunner, Mame and AccurApple.
the description from Tom seems on the following seems wrong
Yes, you are right! (I will add an "EDIT: ..." note to that comment, to make it clear it's erroneous.)
It begs the question how MAME is still able to read 0xEE from this seemingly bad flux track 0?! Anyway, that's not my problem... and I know MAME has other WOZ-related issues (eg. https://github.com/mamedev/mame/issues/9073). Just need to bear it in mind that we can't use MAME as a "gold" reference for WOZ images working / not working.
Completely agree on there being no "gold standard" and one is right and another is wrong. I realize this particular one is an edge case. If you are confident that AppleWin is processing the data accurately, that is good enough for me. The only reason I opened the issue was have it confirmed that AppleWin didn't have a bug. Feel free to do whatever you wish with this issue.
Thanks for sharing your thoughts.
I am going to leave this open for now, primarily because AppleWin doesn't support flux tracks, and this issue gives me more motivation to address that missing support.
@univta0001 - thanks for attaching your patched woz & woz-with-flux images.