Tigervision banking and low-memory reads

[DirtyHairy]

I have started to reinvestigate a loose end that came up during 6502.ts development and still am stumped, so here it goes...

 

According to the documentation I could find on tigervision banking, it switches banks on writes to low memory positions starting with 3F. As the cartridge bus does not expose R/W select, I originally implemented my code to trigger on both writes AND reads. To my utter surprise, including reads breaks several historic cartridges badly (e.g. Miner 2049er). If I disable switch-on-read, everything is back to normal, so that's what's implemented right now. I cross-checked Stella, and it's the same there: switches happen only on write.

 

However, this cannot be the real deal as real cartridges don't have any way to tell a read from a write. So, does anyone know what is going on here in real hardware? Some of these games read only from 0x00 and 0x01, and, as nothing else drives the data bus, this should also be the value read, so it can't be connected to the handling of invalid bank values. Is the documented address range for bankswitching wrong? Is the cartridge watching for specific instructions? Is there some peculiarity in the cartridge circuit that modifies the behavor of undefined reads?

Edited June 2, 2017 by DirtyHairy

[Thomas Jentzsch]

The FE scheme reacts to opcodes, maybe this works similar?

[+stephena]

While Stella does follow what is reported to be required for 3F handling (only switch on writes), I would also be interested in what really happens in hardware. If for no other reason than to accurately emulate it

[DirtyHairy]

The FE scheme reacts to opcodes, maybe this works similar?

 

I was under the same impression, and this is one of the possibilities that have crossed my mind However, it seems that, at least for FE, this is wrong after all (http://atariage.com/forums/topic/266200-my-2600-playground/?do=findComment&comment=3775673)

 

While Stella does follow what is reported to be required for 3F handling (only switch on writes), I would also be interested in what really happens in hardware. If for no other reason than to accurately emulate it

 

Same with me. Actually, the mismatch between Kevin Horton's banking docs (which is what I used for pretty much all historic bankswitch schemes) and David Crane's patent for FE banking (http://atariage.com/forums/topic/266200-my-2600-playground/?do=findComment&comment=3775673) makes me wonder how accurate those really are. It might well be that the reported range of "hotspots" for Tigervision (0x00 -- 0x3F) is simply wrong.

[+stephena]

The potential problem now is that while the 3F docs might be incorrect, they have been around for some time, and all emulators and the Harmony cart emulate what they say. So even if 3F was initially different, it might no longer matter. Put another way, the docs may have become a de facto standard.

 

EDIT: That's not to say I'm not interested in the actual standard; I'm all for tracking down and documenting exactly what should be happening. It just may be that even if/when we figure that out, we still need to emulate the (possibly) incorrect way too.

[alex_79]

How is 3F banking implemented in the Harmony/Melody? It can't distinguish between read and writes too, so maybe Fred (Batari) figured out already what's really going on.

Speaking of mismatch between banking docs, there's some official documentation for the CBS ramplus ("FA" scheme) too:
US4485457_cbs_ramplus.pdf
According to that patent, the scheme should check both the address and data bus (data bus D0 must be HIGH to trigger a bankswitch), while in Stella and Harmony, accessing the hotspot seems to suffice and the data bus is ignored.


For example, Omega Race performs bankswitching with the sequence

    lda #$01
    sta $FFF8 ;or $FFF9, or $FFFA

I replaced the "STA abs" with "LDA abs" and changed the values in the hotspot locations in the binary to be "$FE", so that bit D0 will be LOW while accessing the hotspot. The modified rom runs fine in Stella and Harmony cart.
omegarace.bin

(I first verified that Stella and Harmony can read the hotspot values in the rom file, and, by looking at the rom dumps, I think that's the case on real hardware too. So if the value in the hotspot has bit 0 set, a load operation might work on the real deal too. Mountain King and Tunnel Runnel roms have some of the hotspots containing values with bit 0 cleared, so it should be possible to verify that. Unfortunately, I don't have those carts)

[TomSon]

hmm, Tiaras 3F implementation is agnostic to reads/writes.

If the cpu uses a read to trigger the Tiara would read a 'zero' value on the bus since the cpu isn't supplying data.

Just played a round of Miner 2049er again - no problems with this behavior that I can see.

 

Same with FA - the adr. on the bus is the trigger for switching and nothing is put onto the bus for FA bank switch regs (in case it's a write).

[DirtyHairy]

TomSon, on what addresses is the tiara triggering? 6502.ts is listening on 0x00 - 0x3F, and including reads will cause most Tigervision games to crash and burn (hang and display garbage right on startup, no exhaustive testing required). As side note, reading from an invalid address will not put zero on the bus. The way the VCS is wired, if nothing drives the bus, a read will usually return the last valid value. This is pivotal in correctly emulating many cartridges

EDIT: I just checked in the debugger: for Miner 2049er, one of the problematic accesses happens at 0x306C during a "STA $07,X" --- the third cycle is a read from $07 that puts $07 on the data bus.

Edited June 5, 2017 by DirtyHairy

[DirtyHairy]

The potential problem now is that while the 3F docs might be incorrect, they have been around for some time, and all emulators and the Harmony cart emulate what they say. So even if 3F was initially different, it might no longer matter. Put another way, the docs may have become a de facto standard.

 

EDIT: That's not to say I'm not interested in the actual standard; I'm all for tracking down and documenting exactly what should be happening. It just may be that even if/when we figure that out, we still need to emulate the (possibly) incorrect way too.

 

I agree; as far as historic games are concerned, any implementation that handles the existing historic ROMs is esentially correct. As far as new ROMs are concerned, the accepted status quo is what is relevant, the actual historic implementation might not work and is essentially academic. Still, I am curious about how the original hardware worked

 

How is 3F banking implemented in the Harmony/Melody? It can't distinguish between read and writes too, so maybe Fred (Batari) figured out already what's really going on.

 

Speaking of mismatch between banking docs, there's some official documentation for the CBS ramplus ("FA" scheme) too:

US4485457_cbs_ramplus.pdf

According to that patent, the scheme should check both the address and data bus (data bus D0 must be HIGH to trigger a bankswitch), while in Stella and Harmony, accessing the hotspot seems to suffice and the data bus is ignored.

 

 

For example, Omega Race performs bankswitching with the sequence

    lda #$01
    sta $FFF8 ;or $FFF9, or $FFFA

I replaced the "STA abs" with "LDA abs" and changed the values in the hotspot locations in the binary to be "$FE", so that bit D0 will be LOW while accessing the hotspot. The modified rom runs fine in Stella and Harmony cart.

omegarace.bin

(I first verified that Stella and Harmony can read the hotspot values in the rom file, and, by looking at the rom dumps, I think that's the case on real hardware too. So if the value in the hotspot has bit 0 set, a load operation might work on the real deal too. Mountain King and Tunnel Runnel roms have some of the hotspots containing values with bit 0 cleared, so it should be possible to verify that. Unfortunately, I don't have those carts)

 

 

 

Very interesting, I wasn't aware of that patent, either. It might be worthwhile to get hands on a historic cart, swap out the ROM with an EEPROM and run some tests. I guess this would also be the ultimate way to get a conculsive answer for the other schemes.

Edited June 4, 2017 by DirtyHairy

[alex_79]

Unfortunately, in the case of cbs, there's no separate rom chip: the 10.5kb rom, 256b ram and bankswitching logic are integrated in a single ic (there are pictures of cbs ramplus carts here, towards the middle of the page).

Anyway, it's possible to copy a small test routine in the RIOT ram, then making the cart rom accessible, by using an external cart selector type of device (basically two cart ports and a switch), or a custom bios in a 7800.

[DirtyHairy]

Unfortunately, in the case of cbs, there's no separate rom chip: the 10.5kb rom, 256b ram and bankswitching logic are integrated in a single ic (there are pictures of cbs ramplus carts here, towards the middle of the page).

Anyway, it's possible to copy a small test routine in the RIOT ram, then making the cart rom accessible, by using an external cart selector type of device (basically two cart ports and a switch), or a custom bios in a 7800.

 

That's a pretty much brilliant idea. I think it wouldn't even require a cart selector. The VCS would start the test cart which would copy the actual test code to RIOT RAM and jump there. The test code would then wait for fire to be pressed, allowing to simply hotswap the carts. A possible improvement would be hooking an arduino to the joystick port and establish serial communication; this would make the whole procedure much more convenient. That sounds like a worthy project when I find myself in the posession of more spare time again

 

The only downside I can see that it would miss any effects of a cart watching the bus for traces of the 6502 boot process, but I think doing the corresponding memory accesses should be enough to fool any simple implemention of this (if such a thing actually exists).

Edited June 5, 2017 by DirtyHairy

[alex_79]

That's a pretty much brilliant idea.

It really is, and in fact it's not my idea!

 

http://atariage.com/forums/topic/78065-how-to-dump-your-fb2-games/

 

You can send serial data using the joystick ports, no need to use an arduino.

And yes, hotswapping works too (with some practice)

Using the same technique I also managed to use the TIA audio to send data:

http://atariage.com/forums/topic/185932-my-2600-cart-dumper/

 

[Thomas Jentzsch]

Some years ago, I have written a dumper that which dumps from RIOT RAM onto a SaveKey (which lead to RAM-Pong BTW).

DumpJTZ_18.asm

[DirtyHairy]

It really is, and in fact it's not my idea!

 

http://atariage.com/forums/topic/78065-how-to-dump-your-fb2-games/

 

You can send serial data using the joystick ports, no need to use an arduino.

And yes, hotswapping works too (with some practice)

Using the same technique I also managed to use the TIA audio to send data:

http://atariage.com/forums/topic/185932-my-2600-cart-dumper/

 

 

Yikes I was musing about an Arduino because I wasn't sure whether it would be worthwhile to get true RS232 bitbanging working, but there it is, already done, complete with source and even at 38400 baud. I know that I have at least one USB-TTL dongle lying around that I bought for interfacing an ESP8266, so that should be all I need (apart from some cartridges). I think I will try to get a minimal protocol running that allows to peek and poke remotely and run everything else on the attached computer.

 

However, it will take some time until I tackle that as I want to tie up some other loose ends around 6502.ts and Stella before (and true spare time is rather rare atm).

 

Some years ago, I have written a dumper that which dumps from RIOT RAM onto a SaveKey (which lead to RAM-Pong BTW).

 

I stumbled over RAM-Pong some time ago, though it was very cool and was on the verge of attempting a cartridge dumper that runs from RIOT RAM and transfers the data using a QR-Code like optical code. Now I wish I had try to do so, that would have closed the circle

Edited June 5, 2017 by DirtyHairy

[TomSon]

TomSon, on what addresses is the tiara triggering? 6502.ts is listening on 0x00 - 0x3F, and including reads will cause most Tigervision games to crash and burn (hang and display garbage right on startup, no exhaustive testing required). As side note, reading from an invalid address will not put zero on the bus. The way the VCS is wired, if nothing drives the bus, a read will usually return the last valid value. This is pivotal in correctly emulating many cartridges

 

EDIT: I just checked in the debugger: for Miner 2049er, one of the problematic accesses happens at 0x306C during a "STA $07,X" --- the third cycle is a read from $07 that puts $07 on the data bus.

 

'invalid adr.': when the 650x accesses the cart. the adr. is valid and the cart supplies the data, nothing else better put their eager

data pins on the bus.. and when I <assume> a CPU write cycle the data is either really put on the bus by the CPU or it's a

CPU-read - then noone drives it.

 

'3F': checked the code today since I was hardening it for 7800 anyways and tested this a bit - I only trigger at 3F in the moment

and see a few uncommented lines w/ comments that e.g. Miner indeed has problems when I enlarge to the 0-3F range.

Tried this again and sure enough, Miner II glitches.

[DirtyHairy]

'invalid adr.': when the 650x accesses the cart. the adr. is valid and the cart supplies the data, nothing else better put their eager

data pins on the bus.. and when I <assume> a CPU write cycle the data is either really put on the bus by the CPU or it's a

CPU-read - then noone drives it.

 

That's indeed what I meant with "reading from an invalid address": reading from an address where nothing drives the bus In this case, you're gonna read whatever was put on the bus when it was last driven. For example, 0x07 is CXPPMM, and the TIA drives only the two highest bits, so, on the third cycle of STA $07,X, bits 0 - 5 will read 00111, causing a switch to bank 1.

 

'3F': checked the code today since I was hardening it for 7800 anyways and tested this a bit - I only trigger at 3F in the moment

and see a few uncommented lines w/ comments that e.g. Miner indeed has problems when I enlarge to the 0-3F range.

Tried this again and sure enough, Miner II glitches.

 

Great, thanks for confirming this on real hardware!

Edited June 5, 2017 by DirtyHairy

[Kroko]

I have implemented 3F bankswitching for any access to bus location $003F, no matter if it is read or write.
As you wrote, there is no way on real hardware to detect if somebody is doing a read or write to that location.

Maybe it works on real hardware, because I am only using $3F, not the locations below $3F. Could be that
the cartridges that make trouble with read access do the same thing. They would have trouble with reads from

addresses below $3F as well. They may only work because these addresses are ignored...

Do you have an example of how a 3F cartridge fails because of a read access to $3F (not below $3F) ?

I have started to reinvestigate a loose end that came up during 6502.ts development and still am stumped, so here it goes...

 

According to the documentation I could find on tigervision banking, it switches banks on writes to low memory positions starting with 3F. As the cartridge bus does not expose R/W select, I originally implemented my code to trigger on both writes AND reads. To my utter surprise, including reads breaks several historic cartridges badly (e.g. Miner 2049er). If I disable switch-on-read, everything is back to normal, so that's what's implemented right now. I cross-checked Stella, and it's the same there: switches happen only on write.

 

However, this cannot be the real deal as real cartridges don't have any way to tell a read from a write. So, does anyone know what is going on here in real hardware? Some of these games read only from 0x00 and 0x01, and, as nothing else drives the data bus, this should also be the value read, so it can't be connected to the handling of invalid bank values. Is the documented address range for bankswitching wrong? Is the cartridge watching for specific instructions? Is there some peculiarity in the cartridge circuit that modifies the behavor of undefined reads?

[DirtyHairy]

Do you have an example of how a 3F cartridge fails because of a read access to $3F (not below $3F) ?

 

I just checked: nope; if I restrict the code to reads and writes to 0x3F only, all Tigervision cartridges that I am aware of (Espial, Miner 2049er, Miner 2049er II, River Patrol and Polaris) work fine,

[alex_79]

I just found an old post from Eckhard Stolberg that might shed some light on this:

http://atariage.com/forums/topic/68544-3f-bankswitching/?do=findComment&comment=843498

 

 

As Kevin Horton's bankswitching guide says, 3F games react to accesses to all addresses between $0000 and $003F. But the switch will only happen when this access is followed by an access to an address between $1000 and $1FFF.

[Dionoid]

On 6/5/2017 at 3:31 PM, Thomas Jentzsch said:

Some years ago, I have written a dumper that which dumps from RIOT RAM onto a SaveKey (which lead to RAM-Pong BTW).

DumpJTZ_18.asm 11.32 kB · 35 downloads

Excellent stuff, Thomas!

I found that on my Atari 2600 Jr, while hot-swapping the carts, reading the joystick's fire-button sometimes triggers the dump too soon. I think INPT4 isn't stable when hot-swapping carts.

So I changed that to listening to the RESET switch, which works better for me (but takes up an additional byte of code in RAM):

...

; wait for user pressing RESET button:
.waitForTrigger:
    lsr SWCHB
    bcs .waitForTrigger
    
.startDump
...

 

Edited April 7, 2021 by Dionoid