EclaireXL

If this is confirmed it will need some digging to get to the root cause. Anyone up for the challenge?

Tried it today running more versions of WoW with the same results.
Addition to the behavior I described, when the game freezes, I press F12 and ESC, and the game continues to work. Till the next lockup. Then F12 and ESC makes it work again.

Thanks for checking more versions, always worthwhile. We need to work out what is going wrong, or if its just a game bug that manifests due to defined state e.g. the memory is zero initialised prior to starting the 6502.

I checked a car version on core 14, it started this behavior on the first level after killing monsters and an additional two monsters re-spawn in the upper left which will only move vertically in a small area. After killing these two monsters, a musical tune plays then the game crashes with garbled characters at the bottom of the screen. Now if I press F12 to go into the system menu then Escape back to Atari mode the game resumes and starts the second level as if nothing happened. When I run out of lives, I can press F12 and return to the system menu. If I escape back to Atari mode, the screen goes black and now the system will not respond to any keys including F10, F12, etc. requiring a hard reset to bring it back to life. If i make it to past level two, the screen displays "DOUBLE SCORE DUNGEON" then crashes again as level three is suppose to start. Once again, pressing F12 then Escaping back to Atari mode makes the game continue on to level three. I died at the end of level three so I can't confirm what happens after that.

I see this too. Any luck tracking down the cause? I'm hoping @xxl or @Xuel can help me here with their machine code wizardry:-)

For now I'm not concerned about the F12 issues, more the core game problem ignoring the F12 menu. There are known imperfections of the system freezing with F12 which I need to investigate separately.

So how do we track this down? I wonder if its possible to load turbo freezer save states in Altirra so we can tell if its down to early game state being corrupt or something that happens at the time.

Well I tried many settings in Altirra and can't reproduce with a different hardware variant.
Things I found:
i) Recursive NMIs
ii) No illegal op codes, even works on 65C02 etc.
iii) Still works with zero initialised ram (the eclaire clears ram prior to boot)

Checked with equivalent setup, pal, 320K compy, dual pokey etc.

Tried a different version and I get the 'freeze with blocks' at the end of every level. Will have to see what happens here - is the 6502 still running until I hit f12 and freeze it?

Turbo freezer does not freeze it when its in 'frozen blocks' state but does otherwise.

I'm going to build a debug tool to make it easier to track these things down.

For now, a workaround. Use 2x turbo mode! It hasn't crashed yet...

Just testing it and ... tried the atx version and the cart version. They both work now! I guess due to a fix in the last year.

Can someone else double check please to check I'm not going mad?

Nope, I was just too rubbish and kept dying before it failed :-)

First dli, seems to reposition player and missiles - for map?
Second dli, wsync, change charset
Third dli, was entered during pla of second dli! Seems to reposition players then copy stuff in loops. I guess The players are used for the main char and the others are software sprites and these are sprite moving loops?

9c0c: pla on 2nd dli is when 3rd dli fires. This could be shifted by a few cycles on 'events', which could be when it crashes. pla takes 4 cycles.

Planning to shift the dli so it does not overlap, to see if that fixes it.

I have a feeling I did a cpu patch that I wasn’t certain about to fix the Irq blocking nmi acid test. I expect that is related.

Tried shifting the dli, seems to then work.
Tried removing my cpu hack, no change.
Updated to latest cpu core, change was just in sensitivity lists (no real change).

Since the following work:
i) Running core 2x faster
ii) Shifting dli 1/2 1 line earlier

Reckon there is a cpu bug with the recursive nmi. Trying to capture on logic analyzer...

One of the common crashes is when it ends up with the character set in the bottom half. In this state there are no NMIs. Going to try to catch that on the logic analyzer with a large history and see how it entered that state. I guess nmien/nmist are not set properly in some path.

Disables them at $a535 then never re-enables... (this address is normal, I see this call on Altirra)

I think its a CPU bug, trying to wire up T65 to see if that works. If it does, I'll run the CPUs against each other and highlight the discrepancy! More realistic than it used to be since Wolfgang did a LOT of t65 fixes since I last used it.

Crashes in the same way with T65, so... I guess its not a cpu bug!

I'm trying it on my 600XL. I'm getting similar crashes, when running with PokeyMAX. So could be a Pokey bug, or incompatible with stereo pokey?

Nope, fails with pokeymax in mono mode too!

So, the issue seems to be with pokey. OK, getting closer! Will check which pokey regs its accessing in Altirra to get some clues...

I put my real pokey back in the 600Xl to confirm. Definitely works properly with real pokey and definitely fails with pokeymax.

So, we have a pokey core bug.

No Pokey IRQs
Reads pots, writes potgo
Reads random
Reads skstat
+ plays some music

Nothing out of the ordinary that I can see...

I wonder if its possible to play with paddles or this is used for something else.

Could random lfsr get stuck somehow?!

It writes 8f and 00 often to audctl. This switches the shift register from 17 bit to 9 bit and back. Could there be some freak timing thing where the random ends up giving the same values?

With 8f for only ... 6 cycles

Will try nopping these to see (on cart!!)

A0BB: A9 8F LDA #$8F
A0BD: 8D 08 D2 STA AUDCTL
A0C0: A9 00 LDA #$00
A0C2: 8D 08 D2 STA AUDCTL

easier to set memory on xex or atx version...

36FD: A9 8F LDA #$8F
36FF: 8D 08 D2 STA AUDCTL
3702: A9 00 LDA #$00
3704: 8D 08 D2 STA AUDCTL

I set them to nop ... then the game works and no longer crashes!

I think the 17/9 bit lsfr is based on the decap schematics, so this is probably down to the number of cycles to delay on writes/reads or suchlike.

Altirra has two massive poly tables and selects between them with this flag. So, not really much help since here we are using a real lsfr... I'll check the decap.