UNROM bus conflict handling

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

Post Reply
User avatar
SusiKette
Posts: 104
Joined: Fri Mar 16, 2018 1:52 pm
Location: Finland

UNROM bus conflict handling

Post by SusiKette » Mon Oct 08, 2018 9:50 am

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?

User avatar
rainwarrior
Posts: 7738
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: UNROM bus conflict handling

Post by rainwarrior » Mon Oct 08, 2018 9:55 am

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,

tepples
Posts: 21882
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: UNROM bus conflict handling

Post by tepples » Mon Oct 08, 2018 10:03 am

See also replies to casprog's recent question about the same issue on a different discrete mapper.

User avatar
SusiKette
Posts: 104
Joined: Fri Mar 16, 2018 1:52 pm
Location: Finland

Re: UNROM bus conflict handling

Post by SusiKette » Mon Oct 08, 2018 11:53 am

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?

lidnariq
Posts: 9130
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: UNROM bus conflict handling

Post by lidnariq » Mon Oct 08, 2018 11:54 am

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

User avatar
koitsu
Posts: 4217
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: UNROM bus conflict handling

Post by koitsu » Mon Oct 08, 2018 12:25 pm

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

User avatar
rainwarrior
Posts: 7738
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: UNROM bus conflict handling

Post by rainwarrior » Mon Oct 08, 2018 12:30 pm

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.
Last edited by rainwarrior on Mon Oct 08, 2018 12:31 pm, edited 1 time in total.

User avatar
tokumaru
Posts: 11561
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: UNROM bus conflict handling

Post by tokumaru » Mon Oct 08, 2018 12:31 pm

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.

User avatar
Bregalad
Posts: 7813
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: UNROM bus conflict handling

Post by Bregalad » Tue Oct 09, 2018 2:19 am

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

Code: Select all

LDA #bank
STA table+bank
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.

User avatar
rainwarrior
Posts: 7738
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: UNROM bus conflict handling

Post by rainwarrior » Tue Oct 09, 2018 10:49 am

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.

Post Reply