ATARI 2600 EPROM/ROM AND DATABUS COMPATIBILITY ISSUES

[Blinky]

While I was working on a Dodge'm disassembly for a hack I found some programming bugs where the programmer forgot the # for an immediate instruction like LDA WSYNC instead of LDA #$02 (happens to me sometimes too). I found the same bug in all NTSC and PAL dumps I could find. So I assumed that the last byte read was always floating long enough on the databus and just ignored it. But when I burned the game in an eprom, it showed annoying flicker/mirroring of the score as I would have expectred with the bug. So with the EPROM the bug does show.

I asume that the output from a cart ROM stays active a little longer and keeps the last byte read from the ROM on the databus and (faster) EPROMS do not.

 

Anyone had experiences with games that just didn't work well when burned on a eprom ?

 

Also wondering if those pull down resistors on a 32 in 1 cart where added for simmilar problems.

[supercat]

I asume that the output from a cart ROM stays active a little longer and keeps the last byte read from the ROM on the databus and (faster) EPROMS do not... Also wondering if those pull down resistors on a 32 in 1 cart where added for simmilar problems.

671434[/snapback]

 

Floating data bus lines can do one of four things:

• Stay where they are, consistently
  
• Float high, consistently
  
• Float low, consistently
  
• Do whatever they please without rhyme or reason
  

It doesn't take a whole lot of leakage current to turn what would otherwise be #1 into #2, #3, or #4. Some types of EPROMs are apt to be leakier than others, and so you could try experimenting there.

 

An alternative approach, which I use in my 4A50 game cart, is what's called a "bus keeper". This is a device that will weakly pull bus pins high if they're high, or low if they're low. I've tested my bus keeper and it has no problem holding D0 high during an "LDA (1,X) instruction with X=0, even with a 10 meg scope probe on the pin. The pin voltage drops somewhat, but then stays where the keeper holds it even though the pin is floating for four cycles. Note that using a a bus keeper also allows RAM to be read and written at the same address without requiring the software to do anything special (during each memory cycle, read each byte, hold it with the bus keeper, and then write it back: if the CPU does a write, it will put the new data on the bus; otherwise the keeper will hold the read data which will then get written back).

[+batari]

Anyone had experiences with games that just didn't work well when burned on a eprom ?

671434[/snapback]

I hear that Video Pinball also relies on a persistent data bus, as does the "secret" area in Mountain King.

 

For this reason (I think) the emulators also keep the values on the data bus. It's kind of a double-edged sword for development purposes, however, because although zero page loads to some addresses between $00-$7F might behave exactly the same as immediate #$00-#$7F in most cases, these usually point to collision registers, fire buttons and paddles so the game will mostly work right except for a few fleeting bugs that are hard to locate.

[supercat]

For this reason (I think) the emulators also keep the values on the data bus.  It's kind of a double-edged sword for development purposes, however, because although zero page loads to some addresses between $00-$7F might behave exactly the same as immediate #$00-#$7F in most cases, these usually point to collision registers, fire buttons and paddles so the game will mostly work right except for a few fleeting bugs that are hard to locate.

937373[/snapback]

 

IMHO, emulators should allow 'try to make it work' mode and 'pedantic' mode. In the former, floating data bus bits would return the last solid value. In the latter, floating data bus bits would read random data unless a particular cart includes a "bus keeper" circuit (like mine does).

[+batari]

For this reason (I think) the emulators also keep the values on the data bus.  It's kind of a double-edged sword for development purposes, however, because although zero page loads to some addresses between $00-$7F might behave exactly the same as immediate #$00-#$7F in most cases, these usually point to collision registers, fire buttons and paddles so the game will mostly work right except for a few fleeting bugs that are hard to locate.

937373[/snapback]

 

IMHO, emulators should allow 'try to make it work' mode and 'pedantic' mode. In the former, floating data bus bits would return the last solid value. In the latter, floating data bus bits would read random data unless a particular cart includes a "bus keeper" circuit (like mine does).

937376[/snapback]

Yes, that would be a good idea, especially since omitting the # is a very common mistake, even for experienced programmers.

 

However, for what it's worth, I think that older z26 versons did not use a persistent data bus. Based on the FAQ, it appears that 1.40 and earlier might work as a sort of 'pedantic' mode.

[Delicon]

I've tested my bus keeper and it has no problem holding D0 high during an "LDA (1,X) instruction with X=0, even with a 10 meg scope probe on the pin.  The pin voltage drops somewhat, but then stays where the keeper holds it even though the pin is floating for four cycles.

Does this mean that your new bus has been tested in a working VCS/cartridge situation? If so, thats great news that it works.

 

Vern

[supercat]

Does this mean that your new bus has been tested in a working VCS/cartridge situation?  If so, thats great news that it works.

937416[/snapback]

 

Tested on a Junior and a Heavy Sixer. I have a cool demo program running on the cart, but for some reason I can't figure out it seems to have some power-on problems. The BRK vector and reset vector both point to a routine which makes a half-second noise prior to running the main program. For some reason, the cart sometimes does "noise show-one-frame noise show-one-frame noise start-working". Not sure exactly what's going on, since my program starts with the CLEAN_START macro.

 

Once I get the startup problem fixed, I'll try the thing on a 7800 and see how it works there.

 

BTW, if you're curious about the demo, here's a version of it coded for M-Network format (use the -g7 switch in Z26). Ignore the ugly playfield--that was put in for debugging. The M-Network cart uses 85x85 pixel resolution (the real one uses 96x96 and could be adapted for 96x128 but it was easier to keep things 'square'). Use the left joystick to control the angle and skew of the text.

spin_e7.bin

Edited September 24, 2005 by supercat

[supercat]

The Atari 7800 seems to have weak pullups on the data bus.  The Xilinx's keeper "wins" but not by much (the pins get pulled up over a volt).

671434[/snapback]