Jump to content
IGNORED

using q-meg to debug


Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by danwinslow
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...