musings for making a debugging-mapper

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: musings for making a debugging-mapper

Post by Myask »

Yeah, I just keep the edge bookmarked. Here's
So to go back to T₁ tracking…
keep track of instr. cycle (obviously)
a table of opcode=>cycles (and which cycle is the data read, and whether optional fixup cycles)
fixup1: (izy | abx | aby) & !Read (not RMW nor Write)
whch then requires X,Y to be tracked (and TAX/TAY require A to be tracked, adn ADC/SBC and ROR/ROL A require C to be tracked…but we're wanting to keep track of P anyway because…
fixup2: branches when taken, 2.branches when taken and pagecrossed
(we can do our own PC.low+arg ≥ $100 or read3[7] != PC[7] && read3[0:6] != PC[0.6] (gotta not forget that -128 is an option) to see the latter one)
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: musings for making a debugging-mapper

Post by Oziphantom »

Other crazy idea...
You could use RESET in lieu of NMI as looking at the Schematic its not connected to the PPU... ALSO NOT ON THE CART EDGE!!!!!1111!!! 1

Okay super crazy idea...
If one can make sure that BreakPoints are on instructions and if not, happy with "weird stuff happens"
Hit Break Address
Force Data Bus to $EA (nops)
Tell on board CIC chip to Fail - thus forcing a RESET at some point
Bank in "monitor/Freezer" ROM
Wait for RESET Vector access
tell CIC to pass
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: musings for making a debugging-mapper

Post by lidnariq »

Oziphantom wrote:Tell on board CIC chip to Fail - thus forcing a RESET at some point
Bank in "monitor/Freezer" ROM
Wait for RESET Vector access
tell CIC to pass
The motherboard's CIC will never stop the 1/2 second enabled 1/2 second hold in reset once the handshake fails, unfortunately.
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: musings for making a debugging-mapper

Post by Myask »

Keeping track of registers and scanline would allow flagging of mid-render PPU writes.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: musings for making a debugging-mapper

Post by lidnariq »

Myask wrote:Keeping track of registers and scanline would allow flagging of mid-render PPU writes.
... The bit where it's vaguely permissible to overpower the CPU's pullups mean you could find a mid-render $2007 write and move it to $2001...
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: musings for making a debugging-mapper

Post by Myask »

The point is to have the ability to tap the programmer's shoulder, not pull hm out of the fire.

If you're doing that, then you might also forcibly stop any PPU.BG=master writes, and KIL opcodes…
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: musings for making a debugging-mapper

Post by lidnariq »

I was more thinking "fail hard and fast" rather than "fail soft and invisibly"... the point being making the error Very Visible.
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: musings for making a debugging-mapper

Post by Myask »

When you're being a debugger, treating that as "breakpoint, invoke debugger" is gonna be preferable to "crash" or "color a dinosaur".

Tracelog-without-full-6502-core is the primary difficulty, but knowing where you hit a breakpoint doesn't require that at all.

How to deal with loading graphics of debugger, and where to map the code, are really more "requires work" than "requires ideas".
Post Reply