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

Repost because of the edit and page change.
Strange output to the H command after the w trap:
---
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]

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 :)

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.

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

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

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:
But by Memwatch 1.

7) w 0 100 1, w 1 0 1, W 0 80, at first no crash, then crash
First break:
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.

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.

Yes! Bug defeated :)

Thanks.
:great

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 :)

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:
Is this new

PC=0fffffff

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

It was already fixed yesterday..

Thanks :great

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

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.


Doesn't trigger...

Latest beta 4.1.1 PB0 1/13

Another related fix done..

:great

Hi Toni, this code:
assemble to:
The 2nd line lack the

*2

display.