Debugger doesn't start

[ross]

Originally Posted by Toni Wilen

I only get expected memwatch hit when that weird code reads from address zero. I can't duplicate anything else.

Note that I used simply WB 1.3 disk because you said it isn't important which disk is in use, just to boot it in CLI.

You are right but i've tested IPF images.. Maybe related?
I test with some standard ADF and report.

[ross]

Repost because of the edit and page change.
Strange output to the H command after the w trap:

>H
-1 00FC0F94 60e6                     BT .B #$e6 == $00fc0f7c (T)
 0 00000000 8000                     OR.B D0,D0
>

---
Not related to IPF so i'll upload an ADF from the IPF (with some work in progress change to the game code).
Even more simple when to insert command in debugger.
I've inserted my 'addchip' bootblock so when the screen become black after the initial 'Workbench Screen' you can press S-F12.
[EDIT: attach removed]

[Toni Wilen]

Originally Posted by ross

Repost because of the edit and page change.
Strange output to the H command after the w trap:

It is normal. (I can't believe you have never seen similar output) H outputs single useless line unless at least one break point is active.

[ross]

Originally Posted by Toni Wilen

It is normal. (I can't believe you have never seen similar output) H outputs single useless line unless at least one break point is active.

Ok sorry, sure always used H when f used

[ross]

I did dozens of tests to confirm the problem, and.. sometime the crash do not appear!
Maybe is only due to different timing on entering into debugger? (yes when i've no crash i've checked that i've inserter the proper w commands and value in memory).
But anyway is occasional that problem do not trigger.

This drive me mad.
I need absolutely to understand.

[ross]

Another behavior that seems to confirm that something is wrong.
Same situation as before, also always repeatable.

>f 400
Breakpoint added.
>w 0 1 3
Memwatch breakpoints enabled
 0: 00000001 - 00000003 (3) RWI CPU
>w 1 0 1
 1: 00000000 - 00000000 (1) RWI CPU
>W 0 80
Wrote 80 (128) at 00000000.B
>x

So only a dummy breakpoint added.

Debugger immediately trigger (as before) but this time the system is not corrupted (pc is valid and register contain proper value);

Memwatch 1: break at 00000000.B  W  00000080 PC=00FC0F94 CPUDW (000)
Cycles: 0 Chip, 0 CPU. (V=105 H=0 -> V=105 H=0)
  D0 00000000   D1 00000000   D2 40000000   D3 4CCED104
  D4 000975FC   D5 00000000   D6 80000000   D7 C0000000
  A0 00C0040C   A1 00C026E2   A2 00FDFF50   A3 00C00410
  A4 00FC0FE2   A5 00C036E8   A6 00C00276   A7 00C7FFFA
USP  00C0372A ISP  00C7FFFA
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=2 STP=0
Prefetch c0c6 (MULU) 48e7 (MVMLE) Chip latch 00000CE2
00FC0CE2 48e7 c0c6                MOVEM.L D0-D1/A0-A1/A5-A6,-(A7)
Next PC: 00fc0ce6
>x

But this time is a Memwatch 1 that trigger (without dummy f is everytime Memwatch 0).
PC at L2 IRQ start (before was at $0) and emulation can continue properly (without the dummy f logically there is a crash because all registers are corrupted).

In my mind there is no other solution for such a situation that some problem in the debugger, for some reason, corrupts the system.

[Toni Wilen]

Does it require both memwatch points or can you duplicate it with only one? (either one).

[ross]

Originally Posted by Toni Wilen

Does it require both memwatch points or can you duplicate it with only one? (either one).

Sequence of tests, always replicable results:

1) w 0 1 3, W 0 80, no crash

2) w 1 0 1, W 0 80, crash

3) w 0 0 1, W 0 80, crash

4) f 400, w 1 0 1, W 0 80, no crash

5) f 400, w 0 0 1, W 0 80, no crash

6) w 0 0 1, w 1 1 3, W 0 80, crash
The usual:

Memwatch 1: break at 00000002.W   I 00000000 PC=00000000 CPUI (000)
Cycles: 3384 Chip, 6768 CPU. (V=210 H=1 -> V=224 H=207)
  D0 00000000   D1 00000000   D2 00000000   D3 00000000
  D4 00000000   D5 00000000   D6 00000000   D7 00000000
  A0 00000000   A1 00000000   A2 00000000   A3 00000000
  A4 00000000   A5 00000000   A6 00004BFA   A7 00000102
USP  00000102 ISP  00C80000
T=00 S=0 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=0 STP=0
Prefetch 0000 (OR) 8000 (OR) Chip latch 00000000
00000000 8000                     OR.B D0,D0
Next PC: 00000002
>x

But by Memwatch 1.

7) w 0 100 1, w 1 0 1, W 0 80, at first no crash, then crash
First break:

Memwatch 0: break at 00000100.W R   00000000 PC=00FC0FEC CPUDR (000)
Cycles: 3146 Chip, 6292 CPU. (V=105 H=0 -> V=118 H=195)
  D0 00000000   D1 00000000   D2 00000000   D3 00000000
  D4 00000000   D5 00000000   D6 00000000   D7 00000000
  A0 00000000   A1 00000000   A2 00000000   A3 00000000
  A4 00000000   A5 00000000   A6 00004BFA   A7 00C7FFFA
USP  00000102 ISP  00C7FFFA
T=00 S=1 M=0 X=0 N=0 Z=1 V=0 C=0 IMASK=0 STP=0
Prefetch 0800 (BTST) 4e73 (RTE) Chip latch 0000004A
00FC0FEC 4cd5 7fff                MOVEM.L (A5),D0-D7/A0-A6
00FC0FF0 4e73                     RTE
Next PC: 00fc0ff2
>x
Memwatch 1: break at 00000000.W   I 00000000 PC=00000000 CPUI (000)
Cycles: 7 Chip, 14 CPU. (V=118 H=200 -> V=118 H=207)
  D0 00000000   D1 00000000   D2 00000000   D3 00000000
  D4 00000000   D5 00000000   D6 00000000   D7 00000000
  A0 00000000   A1 00000000   A2 00000000   A3 00000000
  A4 00000000   A5 00000000   A6 00004BFA   A7 00000102
USP  00000102 ISP  00C80000
T=00 S=0 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=0 STP=0
Prefetch 0000 (OR) 8000 (OR) Chip latch 00000000
00000000 8000                     OR.B D0,D0
Next PC: 00000002
>x

Then crash.


So seems that the pattern (w x 0 1, W 0 80) lead to crash.
If f active no crash.

Please ask if you want me to do other tests.

[Toni Wilen]

Does winuae.7z fix it? Memwatch point triggered even when already in debugger which could have confused the CPU emulator. I thought this was some new bug but it must have been there since the beginning.. This is why it is always good idea to test some older official versions.

[ross]

Yes! Bug defeated

Thanks.

[ross]

Another small question, but this is only a curiosity because it is certainly not a problem.
Why when q command is used there is no immediate quit, but a few others breakpoints/watchpoints are triggered?

[Toni Wilen]

Originally Posted by ross

Another small question, but this is only a curiosity because it is certainly not a problem.
Why when q command is used there is no immediate quit, but a few others breakpoints/watchpoints are triggered?

Because config changes are only checked at vblank start. Use CTRL+C to quit instantly

[ross]

Hi, I just do not know where to publish the request, so i'm here
There is a problem in the last beta (4.1.1 PB0 1/11) about the memory watchpoints:

>w 0 0
Memwatch breakpoints enabled
 0: 00000000 - 00000000 (1) RWI PC=0fffffff CPU
>

Is this new

PC=0fffffff

part of a new feature?
But the result is that memwatchs doesn't trigger anymore

[Toni Wilen]

It was already fixed yesterday..

[ross]

Originally Posted by Toni Wilen

It was already fixed yesterday..

Thanks

What would this new(old?) "option" be for?

[Toni Wilen]

Break only if also PC matches. Mainly for future "trainer" support option. (see uae wishlist forum)

[ross]

Originally Posted by Toni Wilen

Break only if also PC matches. Mainly for future "trainer" support option. (see uae wishlist forum)

Very useful option.

But I continue to have problems with memwatch.

w 0 0 1 w ff
 0: 00000000 - 00000000 (1)  W  =FF.b CPU

r
Prefetch 0000 (OR) 50f8 (Scc) Chip latch 00000000
00000100 50f8 0000                ST .B $0000 [00] (T)
Next PC: 00000104

Doesn't trigger...

Latest beta 4.1.1 PB0 1/13

[Toni Wilen]

Another related fix done..

[ross]

Originally Posted by Toni Wilen

Another related fix done..

[ross]

Hi Toni, this code:

	lea	(-(giro*8+tilepx).w,a3,d0.w*8),a2
	move.w	(a3,d0.w*2),d1
	lea	(a0,d1.w),a5

assemble to:

>d 6609ca
006609CA 45f3 0720 f3f0           LEA.L ($fffff3f0,A3,D0.W*8) == $0065fbb2,A2
006609D0 3233 0200                MOVE.W (A3,D0.W,$00) == $006607bc [0000],D1 <--
006609D4 4bf0 1000                LEA.L (A0,D1.W,$00) == $0004ebc2,A5

The 2nd line lack the

*2

display.