Debugging on Ancient Game Platforms

[RevEng]

I've been spending a little too much time at the MAME debugger these days, and so as an outlet, I wrote this article at the 7800.8bitdev.org wiki: Debugging On Ancient Game Platforms

 

It has techniques and thoughts on debugging that apply to the 7800, 2600, and old consoles generally. None of it is revolutionary, but hopefully someone will find it useful. If anybody has any more techniques to add, feel free to share them here.

[Trebor]

Excellent write-up.  Thank you for once again sharing your knowledge, expertise, and experience with the community.  It is very much appreciated.

[RevEng]

Thanks for the kind words, and you're welcome, Trebor.

[+Karl G]

Excellent collection of tips.  Here's my small contribution: In my current project, I don't ever use more than 4 bytes of stack, so I trap writes to the next byte up, since if that's being used, then something is going awry.

[RevEng]

Very nice! I'll add that (attributed) when I get a chance.

[TailChao]

You can also look at the other end of the stack, and push a soft reset handler or full exception handler at its base. That way if you use one rts too many it'll either reset or tell you about it. Similarly, if you're not using BRK or the IRQn line on the cartridge slot - drop an exception handler as your IRQ vector. Having clues as to "why" something went awry is always helpful.

 

A perk of the 7800 here, especially compared to the 2600, is that there's enough resources to have debug features or full debug modes in your software.

[RevEng]

Those are very good too. In addition to updating the doc, you've convinced me to update 7800basic with a fatal exception handler. ?

 

Let me know how you guys want to be credited in the doc.

[TailChao]

No credit is required, but using my handle is fine.

 

A readability technique I don't often see is to use equates for low and high offsets.

 

So instead of...

	clc
	LDA GLO_PointerA
	ADC #<DATA_WIDTH
	STA GLO_PointerA
	LDA GLO_PointerA + 1
	ADC #>DATA_WIDTH
	STA GLO_PointerA + 1

...you'd write...

	clc
	LDA GLO_PointerA + LO
	ADC #<DATA_WIDTH
	STA GLO_PointerA + LO
	LDA GLO_PointerA + HI
	ADC #>DATA_WIDTH
	STA GLO_PointerA + HI

 

This is purely a style thing, but I think it helps coherence immensely - especially if you're switching among platforms with different endianness.

Edited February 25, 2020 by TailChao
Editor space'd my tabs :(

[+Karl G]

I don't need attribution, either, but if you want to add it, you can add it however you wish.

[RevEng]

Ok, sounds good on the credit, guys. (but you'll definitely get mentions anyway)

 

On using + HI or +LO, I name the two bytes with _hi or _lo suffixes explicitly. It means the indirection in the opcode always references the _lo, but I don't think that's necessarily a bad thing. As you say, it's a matter of style, but either way is better than just using +1.

[+Karl G]

For anyone who may not realize or remember that a7800 is a fork of MAME, it might be good to note that the MEME debugging info applies equally to a7800.

[RevEng]

Thanks - that's a great point.

[tep392]

One trick I’ve used before is using the score line to display the value of a variable or flag that I want to monitor during gameplay. 

[RevEng]

Definitely a good one to add. Thanks!

 

 

[RevEng]

Updates made, with attributions. If you want to fast-forward to the updates, scroll to the bottom section and follow links from the attributions.

 

Thanks for contributing!

[TailChao]

No problem

 

Another one I've tried out recently is padding with NOPs ($EA), then putting a jump to your exception handler at the end of every bank (assuming your ROM uses paging). This is pretty handy if your project is using the IRQ vector for... IRQs, but as an additional perk the exception handler jump can include some info like the current bank and vaguely where the PC was.

[RevEng]

Yep, that's very nice as well. Next set of updates it's going in.

[RevEng]

BTW, I love that the community is helping to build this doc. When you're struggling with a bug, it's a solo activity, and potentially demoralising when you're badly stuck. It was my intent with the article to be a supportive voice, reminding the coder of other approaches; even better that it's now a chorus of supportive voices.

[RevEng]

And updated.

 

I also added another point about tracking down too many gosub/jsr... the return address of the unmatched gosub or jsr is going to eventually be repeated all over the stack, ready for the reading.

[TailChao]

Great! Also...

On 2/25/2020 at 9:59 AM, RevEng said:

Those are very good too. In addition to updating the doc, you've convinced me to update 7800basic with a fatal exception handler. ?

 

If it's helpful, here's some additional info on how I usually rig up my own fault systems. This is all Watara SuperVision (Rikki & Vikki's diagnostics were stripped for space long before release), but is still pertinent to the 7800 and other 6502 platforms.

 

Detecting stack underflows by pushing a trap routine at the bottom is nice, but is even nicer if the fault handler dumps the stack.

 

 

Another helpful approach is to push a separate trap routine to the stack at the entrance of an IRQ or NMI handler (if you have the cycles), then remove it before you leave. This way you can get a separate fault for these conditions. It's especially helpful if you're running the game tick in your NMI handler and using the time outside of it as a sort of asynchronous low priority task.

 

 

For the runaway CPU condition, using a macro to place jsr [fault_handler] at the end of each bank is convenient. So then you just have to terminate your bank definitions with something like BANK_RUNAWAY or TRAP_RUNAWAY. Using the jsr also nets you the PC, so...

 

 

Of course, user defined exceptions which supply a string are also nice to have.

 

 

[RevEng]

That's definitely helpful. I don't know how much of that I can adopt, as I'm always at the mercy of rom constraints, and if I make it any bit of it an optional thing, when people have problems they'll tell me they don't have enough rom to enable it in their program.  

 

I can probably setup a digit display for dumps by copying some packed chars to a ram block. The text strings probably won't fly, cool though they are. Even a digit code for the type of fault and some debug values would be a big leap forward.

[RALPH!]

Mame does 7800 debugging? That great news. Tried 7800 Basic and PROSYSTEM. Does not tell me much of where problem is if program not correct run. No update for long time. Other emulator EMU7800 will not recognize compiled program. Need good tools to help put game together.