Project

General

Profile

Bug #33

Wizard of Wor

Added by jozsef over 1 year ago. Updated 2 months ago.

Status:
Closed
Priority:
High
Assignee:
-
Start date:
06/02/2017
Due date:
% Done:

0%


Description

Loading it from an external sio2SD drive with core 7:
At least on the 4th of 5th level, the monsters start appearing in the top left corner and their behaviour stops to be random.
If I kill them all, the game freezes before the next level could be loaded.

Can anybody confirm this?

wor_perf.png View (177 KB) foft, 10/07/2018 07:58 PM

lfsr_delay_sel9bitpoly.png View (568 KB) foft, 10/12/2018 09:00 PM

History

#1 Updated by foft over 1 year ago

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

#2 Updated by jozsef over 1 year ago

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.

#3 Updated by foft over 1 year ago

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.

#4 Updated by 917k over 1 year ago

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.

#5 Updated by foft over 1 year ago

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.

#6 Updated by foft over 1 year ago

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.

#7 Updated by foft over 1 year ago

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?

#8 Updated by foft over 1 year ago

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

#9 Updated by foft over 1 year ago

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...

#10 Updated by foft 2 months ago

  • Priority changed from Low to High

This one annoys me, raising the priority and going to take another look...

#11 Updated by foft 2 months ago

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?

#12 Updated by foft 2 months ago

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

#13 Updated by foft 2 months ago

So, taking another look in Altirra:

Altirra> .dumpdlist
2110: x3 blank 8
2113: mode D @ 3500
2116: x59 mode D
2151: mode.i D
2152: mode 4
2153: mode.i 4
2154: mode.i D
2155: x3 mode 7
2158: waitvbl 2110

Things that jump out looking at this are the dlis on 2153 and 2154. They run into each other (as mentioned in recursive nmis).

As seen on perf its idle much of the time except in these interrupts

Pure speculation: Could there be a cpu bug where interrupts end and start at the exact same cycle?

#14 Updated by foft 2 months ago

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?

#15 Updated by foft 2 months ago

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.

#16 Updated by foft 2 months ago

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

#17 Updated by foft 2 months ago

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.

#18 Updated by foft 2 months ago

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...

#19 Updated by foft 2 months ago

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.

#20 Updated by foft 2 months ago

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

#21 Updated by foft 2 months ago

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.

#22 Updated by foft 2 months ago

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

#23 Updated by foft 2 months ago

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?

#24 Updated by foft 2 months ago

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...

#25 Updated by foft 2 months ago

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.

#26 Updated by foft 2 months ago

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?!

#27 Updated by foft 2 months ago

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?

#28 Updated by foft 2 months ago

With 8f for only ... 6 cycles

#29 Updated by foft 2 months ago

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

#30 Updated by foft 2 months ago

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

#31 Updated by foft 2 months ago

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

#32 Updated by foft 2 months ago

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.

#33 Updated by foft 2 months ago

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.

#34 Updated by foft 2 months ago

The high bit of audctl is sel9bitpoly. In the original chip is is delayed and then combined with itself. So I need a 1 enable delay + a bunch of nors to do it the original way...

#35 Updated by foft 2 months ago

  • Status changed from New to Closed

I modeled this by adding a 1 cycle delay on sel9bitpoly going high. The game then works!

Also available in: Atom PDF