Page 1 of 1
UNROM bus conflict handling
Posted: Mon Oct 08, 2018 9:50 am
by SusiKette
The wiki article on this particular mapper states "The original UxROM boards used by Nintendo were subject to bus conflicts, and the relevant games all work around this in software.", so I was curious about how is this usually done and what would be a good and reliable way to implement it? And now that we are on the subject; does bank swapping take a certain amount of cycles before it's been swapped successfully or is it instant?
Re: UNROM bus conflict handling
Posted: Mon Oct 08, 2018 9:55 am
by rainwarrior
A very common way is to have a table of numbers from 0 to 15, or however many banks you have, and do an indexed store on top of that table so the 2 numbers match (eliminating the conflict issue).
Code: Select all
LDA #bank
TAX
STA table, X
table: .byte 0,1,2,3,4,5,6,7...
It's effectively instant. The bank will be ready before the next instruction is fetched,
Re: UNROM bus conflict handling
Posted: Mon Oct 08, 2018 10:03 am
by tepples
See also replies to
casprog's recent question about the same issue on a different discrete mapper.
Re: UNROM bus conflict handling
Posted: Mon Oct 08, 2018 11:53 am
by SusiKette
rainwarrior wrote:A very common way is to have a table of numbers from 0 to 15, or however many banks you have, and do an indexed store on top of that table so the 2 numbers match (eliminating the conflict issue).
Code: Select all
LDA #bank
TAX
STA table, X
table: .byte 0,1,2,3,4,5,6,7...
It's effectively instant. The bank will be ready before the next instruction is fetched,
Seems simple enough. Thanks
By the way is there an actual explanation on why doing this eliminates the conflict and what issues you could run into if you don't handle the bus conflict, for both PRG and CHR (although UNROM doesn't have these) if the issues differ?
Re: UNROM bus conflict handling
Posted: Mon Oct 08, 2018 11:54 am
by lidnariq
SusiKette wrote:what issues you could run into if you don't handle the bus conflict
The wrong bank may be selected, depending on the specific values you write and in ROM
Re: UNROM bus conflict handling
Posted: Mon Oct 08, 2018 12:25 pm
by koitsu
SusiKette wrote:By the way is there an actual explanation on why doing this eliminates the conflict ...
Yes, there is an entire wiki page on the subject. The explanation requires understanding of how actual hardware works:
https://wiki.nesdev.com/w/index.php/Bus_conflict
Re: UNROM bus conflict handling
Posted: Mon Oct 08, 2018 12:30 pm
by rainwarrior
SusiKette wrote:By the way is there an actual explanation on why doing this eliminates the conflict and what issues you could run into if you don't handle the bus conflict, for both PRG and CHR (although UNROM doesn't have these) if the issues differ?
The bus conflict occurs because the ROM isn't disabled by the write signal (saves some wiring to have it enabled only by PRG A15, i.e. when the address is >= $8000), so at the moment of the write you have your storing value from the CPU on the bus, but also the value output from the ROM.
With two signals on the bus like this, one or the other "wins" or some other behaviour occurs depending on properties of their circuits. If both are the same, though, it doesn't matter which one wins, because both have the correct value.
That value goes from the bus to a latch on the chip that controls the banking.
You can have bus conflicts with either PRG or CHR banking, it doesn't matter
what you're banking though, it matters
where the register you're writing to is. If the register is at $8000-FFFF, that overlaps with PRG. (I think theoretically you could have a bus conflict with CHR while writing through $2007, but this is a bit obscure, mapper registers are usually in CPU space not PPU.)
They basically did this because it saves one extra component to disable the PRG-ROM during writes. With ASIC mappers it was easier to add the extra logic, so they typically don't have bus conflict problems.
Re: UNROM bus conflict handling
Posted: Mon Oct 08, 2018 12:31 pm
by tokumaru
SusiKette wrote:By the way is there an actual explanation on why doing this eliminates the conflict
The conflict happens because the CPU is outputting a value at the same time as the ROM chip, both going to the same wires. If the values are different, there's a conflict.
and what issues you could run into if you don't handle the bus conflict, for both PRG and CHR (although UNROM doesn't have these) if the issues differ?
The two values on the bus are combined in some way that depends on the type of memory chip used, and an unpredictable value ends up being sent to the mapper, which results in the wrong banks being selected.
I also heard that there may be electrical issues resulting from shorting 1s (+5V) and 0s (GND), like the chips heating up or something, but I don't know if that's true or if it could cause any permanent damage to the hardware.
Re: UNROM bus conflict handling
Posted: Tue Oct 09, 2018 2:19 am
by Bregalad
rainwarrior wrote:A very common way is to have a table of numbers from 0 to 15, or however many banks you have, and do an indexed store on top of that table so the 2 numbers match (eliminating the conflict issue).
Code: Select all
LDA #bank
TAX
STA table, X
table: .byte 0,1,2,3,4,5,6,7...
Sorry to nickpick but this piece of code is actually "wrong". Well it'll work but waste time/bytes. It's either
to select a fixed bank or
Code: Select all
LDA bank ; Or any other piece of code computing the bank and having the result in A
TAX
STA table, X
to select a variable bank.
If no variable bank is ever switched, then it can be simplified down to
Code: Select all
changebank:
LDA #bank
STA changebank+1
So that there's no need to waste 7 bytes on a table.
In classic UNROM (128kb PRG-ROM) you'll hardly ever select bank 7 as it is always swapped in $c000-$ffff, so you can take this into account and have the "table" hold the values 0-6 only.
Re: UNROM bus conflict handling
Posted: Tue Oct 09, 2018 10:49 am
by rainwarrior
Sure. I was merely trying to illustrate the table technique. the LDA immediate was really just a placeholder. I think most of those more specific techniques are covered on the bus conflict wiki page that koitsu linked, though maybe there's some more in there worth adding.