Emulating Bus Conflicts

[3gengames]

Basically, a chip can only out put directly to a chip, right? So if a chip is getting two different values from both chips, any different values being asserted is unknown. It can be wrong on any bit, it can be right on any bit. We don't now. It's based on which chip is outputting more and can over ride the other. In NES's case, you WRITE to the mapper. But if the chip doesn't get the output disabled on WRITES, the CPU tries to put the data on the bus WITH the ROM, so both the chip on the board and the microprocessor are trying to "write" data, so this affects the 3rd chip, which is reading the output, which is messed up because two devices are trying to output on the same bus.

Code: Select all

1010
0110
----
UU10

U means unknown, it can be either 0 or 1 to the device reading the bus.

[tepples]

Let me rephrase: What value should an accurate emulator load into each bit of a 74LS161 or 74HC161 binary counter whose input is being driven with this 'U' signal?

[lidnariq]

As a random sample (no idea as to how representative), the AT28C64 provides the following Vout-vs-Iout graph:

AT28C64-pg8-crop.png (7.11 KiB) Viewed 9017 times

while the R6502 datasheet only mentions the somewhat lacking "Iload = 1.6mA, Voutmax = 0.4V; Iload = -100µA, Voutmin = 2.4V"

From this, we can conclude that if the ROM pulls low, it'll definitely win. The only question is whether the CPU or ROM wins when the ROM is pulling high and the CPU pulling low.

Code: Select all

         ROMout
         0 1
CPUout 0 0 ?
       1 0 1

Most sources I've seen assume AND, not =ROM. Mapper 144 implies that the ROM was not assumed to win in ordinary Color Dreams boards.

[tokumaru]

I find this setence a little crytic .

A "bus" is made of several lines where bits travel. The address bus has 16 lines and the data bus has 8 lines. These are the paths that addresses and data use to move around. Some carts don't make use of the R/W line (it indicates whether the CPU is reading or writing), meaning they don't know the difference between reading and writing, so they output the contents of the address being accessed regardless of the operation. If it's a write operation, both the CPU and the ROM chip will try to output data into the same bus at the same time! If the values they output are different, then you have a bus conflict.

[blargg]

Once someone writes some test ROMs for this, we'll have the definitive answer and test of accurate emulation.

[3gengames]

Want me to write a UNROM test that uses WRAM and just writes conflicted values (A=0,writes to a location which contains FF, and then an FF to a location which contains 00) and upload 8192 test results for the bank switched to for the 2 writes by taking the bank number as the first byte in each ROM? We can even make it after the test, it goes back to the PRG-ROM and lets you go through the results, sort of like a hex editor, so we can see it on a console-by-console/chip-by-chip/setup-by-setup basis.

[blargg]

That's the first step, to research what actually happens. Then when we have determined what reliably happens (i.e. what a crappy game might depend on), we can write a pass/fail test ROM.

For the research phase, it'd be best to test on actual unmodified game boards, so we're using the original ROM chips, not EPROMS, flash, or whatever.

[3gengames]

That can be done by scouring the ROM are above C000 for a $00 and $FF value, save them, and then run the code in RAM. There'd need to be controller reading portion in RAM but that's no big deal either. Sound like a plan? I can maybe get on it now, although I'd rather not really. I have so much other NES stuff going on, I need to stop taking on projects like this so often...

[Bregalad]

The problem is that mask ROMs in game paks are very different and elvolved trough the years. EPROMs are just as different. A difference in the 74xx161 chip might come into account too.
There could be a definite answer for a given mask ROM and 161 chip, but this result could change if you change the chips.

Also I don't think it's a probability thing like WednesDay seems to understand it in his original post, I assume that for a given cart, the "winner" of the bus conflict will always be the same, but for another cart, the "winner" could be a different chip. You will most likely not see a cartridge where the "winner" randomly alternates between the CPU and the ROM.

In all cases, I think a "AND" behaviour is probably the cleanest - if the programmer assumes that the value he writes to $8000-$ffff is what will get bankswitched he'll be wrong, and if he assumes the value in rom is what will be bankswitched he's wrong too. It's probably the most accurate electronically (see my previous answer).

[MottZilla]

In all cases, I think a "AND" behaviour is probably the cleanest - if the programmer assumes that the value he writes to $8000-$ffff is what will get bankswitched he'll be wrong, and if he assumes the value in rom is what will be bankswitched he's wrong too. It's probably the most accurate electronically (see my previous answer).

I'd agree with you because the end result should be that the actual behavior ends up different than what the mistaken programmer intended. There is too much dependent on electrical behavior between components that differ to have one accurate solution. So whatever happens on a mapper that is known to have bus conflicts, it should result in wrong behavior all the time, or wrong behavior none of the time. The reason I think it should just go with what the CPU writes is it will result in people writing programs that have bus conflicts but this is a minor issue for a new game and can easily be corrected either with one extra chip or implementing the table for register writes. Or just have an option, Bus conflicts -> CPU WINS, AND LOGIC, and whatever other options you'd want.

[blargg]

Accuracy mode does as best what NES does. Development mode warns programmer of conflict and possibly allows selection of behavior.

I just tested on unmodified GNROM, AOROM, and UNROM (Dragon Power, Battletoads, and Rygar). I had code running out of NES internal RAM writing bank selection values, then determining the bank that was set and printing it. GNROM and UNROM were AND (value in ROM AND value written by CPU), and AOROM had no conflict. This gives confidence that AND is accurate for these. See photos for details on the boards.

[Bregalad]

I just tested on unmodified GNROM, AOROM, and UNROM (Dragon Power, Battletoads, and Rygar). I had code running out of NES internal RAM writing bank selection values, then determining the bank that was set and printing it.

Man, you are a genius !! I'd never thought of that !

[tepples]

I added the test result to the wiki page about bus conflicts.

[org]

You can use simple rule : "Ground wins"

For example, when two devices A and B are connected to bus D, you can resolve bus conflict in following way :

if (Device A connected) D = A;
if (Device B connected) D = B;
if (Device A connected AND Device B connected) D = A & B;

[zzo38]

If the cartridge is readable for the entire 64K, will the addresses that interfere with the CPU/APU/PPU also have their values ANDed in this way (so if set to 255, you can read/write them normally)?

If this works, then you could not only increase the ROM size without bankswitching, but also have hardwired AND masks for some variables in RAM (four each, because it is mirrored) and many for the PPU registers, possibly making some algorithms more efficient.

Will it damage anything to do this?