using q-meg to debug

[danwinslow]

I have a 130 with q-meg on it. I understand there is a ML monitor program on it; is it possible to find out where your ML program is hung at with this monitor? So, when the machine locks up, what do I do to interrupt and invoke the q-meg monitor?

[Kyle22]

Look here: http://atariage.com/forums/topic/66398-looking-for-instructions-for-qmeg-roms-v3-and-onwards/

[Rybags]

A hang condition where the 6502 stops responding can't be debugged as such on a normal machine or one with custom Rom.

 

The problem there is you have to at least press Reset to get control of the machine back. Reset doesn't store any return info to the stack, and state information gets lost as well.

Emulation is often the key for such situations.

[danwinslow]

Thanks Rybags, yes that's it exactly. Unfortunately it does not occur in emulation. I was just hoping q-meg might have a interrupt mechanism.

 

Thanks Kyle, I had seen that, but I was hoping there was more to it than just that.

Edited May 20, 2015 by danwinslow

[Rybags]

What you'd need is a piece of hardware that can snoop the address bus, data bus would be handy too.

 

When 6502 locks up, it's still fetching data. It just gets stuck on the same instruction phase until you reset it.

A logic analyser that can keep a buffer would be helpful. Capture address/data, you'd probably also want /HALT from Antic to determine who's doing the access.

By looking at a few dozen accesses leading up to a lockup event, you'd probably be able to work out most register/flag contents for the CPU.

[pirx]

What you need is a freezer, e.g.: http://www.horus.com/~hias/atari/#freezer

[flashjazzcat]

What's happening exactly? Might be worth flagging up in the Altirra thread if you suspect an emulation issue, although discrepancies between emulation and actual hardware are often down to uninitialised memory.

Edited May 20, 2015 by flashjazzcat

[danwinslow]

Well, I've been stress testing the dragoncart driver by bombing it with unreasonable amounts of data. Without basic running, it performs as well as could be expected given the processor speed; the card backs up and starts losing packets (because I can't pull them off fast enough) but the driver lives through it and recovers. With a basic program running, though, once things really get jammed it locks up the system. A warmstart restores normal operation though, so I suspect that rather than 'crashing' it's actually stuck somewhere due to a race condition or something similar. I can't reproduce it on Altirra for a number of reasons, but the biggest is that I can't ping the Altirra dragoncart....there's some kind of issue revealing the Altirra emulated network IP to the outside world that hasn't been solved. Phaeron gave me a few things to try, but none of them worked.

 

The cycle goes :

Def. VBI begins

check to see if we are still in previous VBI

if so, exit VBI

set 'in VBI' flag

save ZP vars

swap in ext mem bank

call driver process loop

swap out ext mem bank

restore ZP vars

clear 'in VBI' flag

exit VBI

 

During this kind of load It is extremely likely that I am overrunning the next VBI occasionally, but I though that simply checking a flag and leaving would prevent most issues. I suppose I could have a race condition on the flag, though. I'm also tempted to just turn off interrupts during the execution of the VBI but I wasn't sure what kind of side effects that would have.

Edited May 20, 2015 by danwinslow

[ricortes]

Just a quick and dirty check. I am not familiar with q-meg, I'll assume it does have some kind of monitor on reset? Take a look at the stack to eliminate it as a possibility. In normal use, I've never seen the stack go more then 7 deep/14 bytes. If you have anything other then zeros from bytes $100-$1F0, there is a good chance that is the problem. Analyzing the stack itself is problematic since it can have extra info pushed to it. It may not be nicely divided in two byte return addresses but have registers and data pushed to it.