FA bank switching not checking D0 about stella

[ale-79]

At least for standard Atari schemes (f8, f6, f4) a known common trick that allows to use a bankswithed eprom board for a 4k game, is to repeat the rom data in each bank. For this to work the hotspot cannot return a random value or the game could glitch/crash. I think the most common behavior is that the bankswitch is fast enough to return the value from the destination bank.
But also a value where each bit can be from either the old or new bank would work (as all banks contain identical data in that case).

Anyway, the hardware in the cart can vary (even for the same scheme), so there might not be a single "correct" behavior.

For CBS games, since the bankswitching uses a write operation, maybe the cart doesn't drive the bus at all when reading the hotspots (else you'd have bus contention with unpredictable result in case of different D0 values outputted at the same time by the CPU and the ROM).

This seems to be supported by the results that Omegamatrix got dumping CBS games using an Harmony cart in this old thread on AA:
https://forums.atariage.com/topic/164988-harmony-as-a-copycart/?do=findComment&comment=2122082
The hotspots all returned the same value, and were different from the known dump, suggesting an "undriven bus" condition.

BTW, I'm just speculating. I'm definitely not an expert.

[sa666666]

Do you know of any ROMs that fail because of this? In any event, I guess we should get that fixed.

[arpruss]

I don't know of any ROMs that fail, and I would be surprised if any developer depended on the bank-switching NOT happening when D0 is not high -- what would be the gain from that?

I suspect this is merely a super nitpicky accuracy issue.

The patent application discusses some timing issues which I couldn't follow, and says that monitoring the data line makes the bank-switching system more reliable. (I kind of wonder if another purpose of checking the data line isn't to make their system different enough from Atari's that they don't need to worry about Atari's patents.)

[thrust26]

Just for the record: The existing ROMs confirm this. There is always a lda #1 before accessing the hotspots

[sa666666]

'Mountain King' is the only FA ROM I know of off-hand. When I change the bankswitch code to check for D0 = 1, the ROM still works. So I guess in some cases, there were erroneous bankswitches happening that didn't change anything.

[thrust26]

Omega Race and Tunnel Runner are the other two. Plus the Wings proto.

[sa666666]

@thrust26, do you think I should just go ahead and add the check? Or is there more specific timing involved, I wonder?

[thrust26]

No clue. 😄

[thrust26]

I tried to implement this by adding && mySystem->getDataBusState() & 1 to CartridgeFA::checkSwitchBank, line 34. However this breaks e.g. Mountain King.

The reason for this are the return values from the multiple peeks required for executing e.g. sta $5ff8,y.

Due to commit 28d21eb, these values are randomized when peeking at a hotspot. So I removed that code, but the ROM still failed. That's because the dump contains $fc at the hotspot addresses in all 3 banks. Only after I fixed that to $fd (thus setting D0 high), the ROM started working again.

Anyway, I don't think that really fixes it. The code explicitly does lda #$01 before each bank switch. Why would it do that, when the following peeks invalidate setting D0 high?

Now I wonder if:

1. Either System::getDataBusState() (which was never used before in our code) is implemented wrong. Maybe it must only return the value of the previous instruction and not the last peek? Doesn't make sense to me.
2. Or the lda #$01 is superfluous. But this means that the hotspot peeks must return D0 high, which means they are not random.* Also the ROM dumps are wrong then (but hotspots are hard to dump correctly).

So how do we find out what is correct here? Can someone (@arpruss ?) scrutinize the patent if it provides more details?

*Note: I have already wondered if the values peeked from hotspot are really random. Or if only the bits varying between the from and to switched bank are undetermined. So if the values are identical in both banks, the peek returns this value. Could this be true? And if yes, would that be true for all schemes or only certain ones?

[thrust26]

At least for standard Atari schemes (f8, f6, f4) a known common trick that allows to use a bankswithed eprom board for a 4k game, is to repeat the rom data in each bank. For this to work the hotspot cannot return a random value or the game could glitch/crash. I think the most common behavior is that the bankswitch is fast enough to return the value from the destination bank. But also a value where each bit can be from either the old or new bank would work (as all banks contain identical data in that case).

Makes sense.

Anyway, the hardware in the cart can vary (even for the same scheme), so there might not be a single "correct" behavior.

Yes, this might be tricky. Not sure if it is worth implementing is.

For CBS games, since the bankswitching uses a write operation, maybe the cart doesn't drive the bus at all when reading the hotspots (else you'd have bus contention with unpredictable result in case of different D0 values outputted at the same time by the CPU and the ROM).

So something like that could be done by the cart's hardware? I really would like to test or find a cart where the ROM has bit 0 clear at the hotspots.

This seems to be supported by the results that Omegamatrix got dumping CBS games using an Harmony cart in this old thread on AA: https://forums.atariage.com/topic/164988-harmony-as-a-copycart/?do=findComment&comment=2122082 The hotspots all returned the same value, and were different from the known dump, suggesting an "undriven bus" condition.

Thanks for the link. Although I followed it, I cannot even remember it now. He got $E9 for all hotspots. Which coincidentally(?) has D0 high.

BTW, I'm just speculating. I'm definitely not an expert.

Same here. 😄

[ale-79]

So something like that could be done by the cart's hardware? I really would like to test or find a cart where the ROM has bit 0 clear at the hotspots.

Production CBS cartridges used a single custom chip integrating the RAM, ROM and bankswiching logic, so ,if it really doesn't drive the bus, there's no way to know what's on the mask ROM at the hotspot addresses.

You'd need one of the prototype boards that used (lots of) standard ICs and EPROMs to test that.

Like this thing:
http://www.atariprotos.com/2600/software/wings/101083.htm

[thrust26]

Hm, seems almost impossible to find out. Maybe I should close the issue and ignore the check.

[thrust26]

Let's ignore this.