Sniffing/recording address/data/PC on an Atari 7800

[+Propane13]

Hello!

 

Some of you may know from another thread in the 7800 forums that I was working on an Atari 7800 game called "Get Lost".

It worked wonderfully in emulation, but once people started trying it on physical hardware, a difficult problem occurred.

On occasion, the screen would go completely black. This is not reproducible in emulation, which makes me suspect that something is triggered only by real hardware.

 

I have done some thinking, and I have an idea for how to debug this-- I basically need to make something that can "sniff" and record information in real-time.

Then, when the issue reproduces itself, I can go back through the trace that I have, and try to deduce what went wrong.

 

I could do this with a logic analyzer, but even to get there, I need some sort of hardware to be able to interface with the cartridges.

That's when a few ideas hit me, and I'd like to query some hardware folks for some information.

 

My first thought was to basically make an extendo-cartridge between the 7800 and the cartridge that I would solder some wires to, in order to hook those into some sort of logic analyzer or equivalent place that stores data. There are 32 pinouts on a cartridge:

http://www.atarimax.com/jindroush.atari.org/7800cart.html

They include:

- 16 address lines

- 8 data lines

- 2 ground lines

- 1 Vcc (+5V)

- HALT

- R/W

- CLK2

- EAUDIO

- IRQ

 

If I was to make my own "sniffer", I think the pieces of importance are the address and data lines, and the clock.

So, my first question is... if I made such a cart to get information from these pieces, how do I account for crystal drift in the clock?

Here's what I mean-- if I monitor oscillations in the clock line, I need to deduce when to read the address and data lines.

And, there could be very, very small differences in when the clock refreshes vs. these lines.

Do I need some sort of mechanism to sample the clock only when it's exactly halfway-between oscillations?

Maybe this sounds crazy, but if I sampled all lines the exact millisecond when the clock changed, I wonder if everything will be ok, or if a circuit needs a millisecond to change a data line, etc. I'm wondering how that's all handled in hardware, as I'm new to this.

 

My second question is that I was debating whether or not I could just hook in alligator clips inside the atari 7800, and if there was a place where I could read the PC. Is that exposed? Or, is the PC hidden inside of the 6502 hardware itself? I think sampling that might actually get me the data I need a little bit easier than translating data and address lines and mapping them to locations in code. Is that something that's doable?

 

My third thought is that I was wondering about space utilization. If I sampled a 3 bytes each clock iteration (2 address bytes, one data), and logged it to a file, how fast would it grow? This site: https://sites.google.com/site/atari7800wiki/vblank seems to indicate there are 2166 cycles per frame in a base case. So, 2166 * 3 * 60 frames/second = 389,880 bytes per second. That's 23,392,800 bytes per hour (so, 23M an hour). So, this implies that if it generally takes 1-2 hours for my bug to show up, hardware-wise, I'd need the ability to store at least 100M of data in the miniumum case, but probably I should have a couple hundred megabytes available just to be safe. So, are my calculations correct here?

 

Thanks for the insight; I have a very limited hardware background, so I'm grateful for any help.

 

-John

[+Mitch]

Were you able to verify if it was a PAL only issue or not, like one person suggested?

 

Mitch

[+Propane13]

Yeah, sadly I have seen it on my NTSC 7800 on a burned cartridge three times. It is a little rare, but it's definitely I there.

If I can trace back to where it's happening, I may be able to fix it.

 

-John

[bust3dstr8]

Maybe look for a cheap used logic analyzer or gamble with one of those Chinese USB ones?

Edited January 21, 2013 by bust3dstr8

[DanBoris]

Hello!

 

Some of you may know from another thread in the 7800 forums that I was working on an Atari 7800 game called "Get Lost".

It worked wonderfully in emulation, but once people started trying it on physical hardware, a difficult problem occurred.

On occasion, the screen would go completely black. This is not reproducible in emulation, which makes me suspect that something is triggered only by real hardware.

 

I have done some thinking, and I have an idea for how to debug this-- I basically need to make something that can "sniff" and record information in real-time.

Then, when the issue reproduces itself, I can go back through the trace that I have, and try to deduce what went wrong.

 

I could do this with a logic analyzer, but even to get there, I need some sort of hardware to be able to interface with the cartridges.

That's when a few ideas hit me, and I'd like to query some hardware folks for some information.

 

My first thought was to basically make an extendo-cartridge between the 7800 and the cartridge that I would solder some wires to, in order to hook those into some sort of logic analyzer or equivalent place that stores data. There are 32 pinouts on a cartridge:

http://www.atarimax....g/7800cart.html

They include:

- 16 address lines

- 8 data lines

- 2 ground lines

- 1 Vcc (+5V)

- HALT

- R/W

- CLK2

- EAUDIO

- IRQ

 

If I was to make my own "sniffer", I think the pieces of importance are the address and data lines, and the clock.

So, my first question is... if I made such a cart to get information from these pieces, how do I account for crystal drift in the clock?

Here's what I mean-- if I monitor oscillations in the clock line, I need to deduce when to read the address and data lines.

And, there could be very, very small differences in when the clock refreshes vs. these lines.

Do I need some sort of mechanism to sample the clock only when it's exactly halfway-between oscillations?

Maybe this sounds crazy, but if I sampled all lines the exact millisecond when the clock changed, I wonder if everything will be ok, or if a circuit needs a millisecond to change a data line, etc. I'm wondering how that's all handled in hardware, as I'm new to this.

 

My second question is that I was debating whether or not I could just hook in alligator clips inside the atari 7800, and if there was a place where I could read the PC. Is that exposed? Or, is the PC hidden inside of the 6502 hardware itself? I think sampling that might actually get me the data I need a little bit easier than translating data and address lines and mapping them to locations in code. Is that something that's doable?

 

My third thought is that I was wondering about space utilization. If I sampled a 3 bytes each clock iteration (2 address bytes, one data), and logged it to a file, how fast would it grow? This site: https://sites.google...7800wiki/vblank seems to indicate there are 2166 cycles per frame in a base case. So, 2166 * 3 * 60 frames/second = 389,880 bytes per second. That's 23,392,800 bytes per hour (so, 23M an hour). So, this implies that if it generally takes 1-2 hours for my bug to show up, hardware-wise, I'd need the ability to store at least 100M of data in the miniumum case, but probably I should have a couple hundred megabytes available just to be safe. So, are my calculations correct here?

 

Thanks for the insight; I have a very limited hardware background, so I'm grateful for any help.

 

-John

 

The clock is the key to knowing when to read the data. The address and R/W are valid on the rising edge of the clock and data is valid on the falling edge.

 

As for your third question, no the program counter is not accessible, it's internal to the processor.

[honestbob]

I can't help with the hardware sniffing, sorry. But I have a bit of experience in emulation vs actual hardware with the Sega SC-3000. This is the approximate checklist (in no particular order) that I run through when tracking down an error that occurs on real hardware but not in an emulator. I know this is a different platform, but the basic troubleshooting process will be similar. I hope this is helpful.

 

1. Is it a hardware fault?

Check on multiple machines (it sounds like you have). I spent ages chasing a bizarre sprite problem when helping with the recent SC-3000 Astrododge release that turned out to be just a failure of a couple of bits in one of the 8 VRAM chips on one computer. But it just happened to occur consistently in the byte that holds the Y position control for sprite 0, so your main ship would suddenly jump 32 pixels up and down the screen depending on whether you hit the stuck bit or not. This hardware problem was not obvious as other games carts I tested on that computer seemed to play fine, but they obviously didn't use the faulty part of memory.

 

2. Have you initialized your RAM and your VRAM?

Most emulators give you a nice zeroed out memory space. You can't make any assumptions about what default values you get in RAM / VRAM when powering on. It is safest to explicitly zero them out.

 

3. Are you writing within correct memory ranges?

eg. the Sega SC-3000 has 2KB of RAM on-board from $C000 to $C7FF. That is mirrored every 2KB from $C800 to $FFFF, so a write to $C800 maps to the same memory space as $C000. But the Sega SG-1000 (which is Sega's original game console and is like a SC-3000 without a keyboard) only has 1KB of RAM from $C000 to $C3FF. So if you write to $C400 then you overwrite the bit in $C000 when the cart is played on a SG-1000 instead of a SC-3000, which may not be what you meant to do. It is safer to make sure that all read / writes are within range so you don't get any unexpected surprises if a given hardware configuration has a different memory layout. Similarly make sure that your stack pointer is sitting in a valid memory range and not a mirrored memory range.

 

4. Are all your port read / writes to valid ports?

eg. the Sega uses I/O mapping for all input and output, including the VDP. The actual hardware mirrors the ports, so if you accidentally write to an undefined port then an emulator will probably ignore it, but the real hardware may well send that data to a real I/O port with unpredictable consequences. If the 7800 uses memory mapped hardware, then the same principle applies.

 

For #3 & #4 above, you want to find an emulator that lets you trap memory read / writes to given ranges. I use Meka for that. eg. I can get the system to break on any reads / writes to $8000 to $BFFF and $C400 to $FFFF. Those are out of range for the SG-1000, and it is safest to not rely on RAM mirroring so I can change the read / write addresses to the correct range. Similarly, I can stick a breakpoint on reads / writes to any ports from $00 to $7E, $80 to $BD, $C0 to $DB, $F0 to $FF (I think that is correct) which will catch all read / writes to invalid ports which the real hardware might respond to unpredictably.

 

 

5. Are all your VDP commands within specifications?

eg. I converted several Samsung Gamboy titles to run on the Sega SC-3000 multicart. The Gamboy is basically a Korean Master System. A lot of titles for that system use the legacy TMS99XXA screen 2 video mode (as they are ports of MSX games) rather than the newer Master System video mode, so the games work with minimal modification. But several of them wrote some data to the VDP registers that worked fine on a Master System VDP and in emulators, but which was out of spec for a real TMS99XXA and caused a variety of nasty screen behaviour. I just had to look at what was being written to the VDP, especially around the initial VDP initialization, and correct the writes so the data was within spec by checking against the TMS99XXA datasheet for what values are allowed. In a couple of cases I had to add an extra init command or two which the Master System VDP and the emulators did not need, but that a real TMS99XXA required.

 

6. Have you performed all the other system hardware initialization that real hardware requires?

eg. the Samsung Gamboy games (and Taiwanese SG-1000 II games) never thought about initializing the SC-3000 PPI, keyboard, and joysticks because those systems didn't have them, and the SC-3000 was never really sold into those markets. And for the SC-3000 it pays to check that the CPU interrupt mode is set correctly.

 

 

7. Are you writing data too fast to the VDP?

I've never run into this one myself. But apparently with the Master System it is possible to write data too quickly to the VDP during the vblank. Or something like that. Apparently that tends to give unpredictable display level issues.

 

 

I hope there is something useful in there for you. If I had the symptoms you described (screen occasionally turning black), I would quickly eliminate steps 2-4 above in an emulator, then start looking through your VDP commands looking for anything that doesn't fit with the VDP specifications. Look for anything like unused or undefined bits in your VDP commands. eg. some of the TMS99XXA register commands really only use 4 or 5 of the bits. But if you go and set one of the unused bits rather than setting them to zero, then a real VDP may do something unexpected.

 

Cheers

Edited March 12, 2013 by honestbob