It is currently Tue Jan 22, 2019 8:26 pm

 All times are UTC - 7 hours

 Page 1 of 1 [ 10 posts ]
 Print view Previous topic | Next topic
Author Message
 Post subject: UNROM bus conflict handlingPosted: Mon Oct 08, 2018 9:50 am

Joined: Fri Mar 16, 2018 1:52 pm
Posts: 80
Location: Finland
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?

Top

 Post subject: Re: UNROM bus conflict handlingPosted: Mon Oct 08, 2018 9:55 am

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7118
Location: Canada
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:
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,

Top

 Post subject: Re: UNROM bus conflict handlingPosted: Mon Oct 08, 2018 10:03 am

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21011
Location: NE Indiana, USA (NTSC)
See also replies to casprog's recent question about the same issue on a different discrete mapper.

Top

 Post subject: Re: UNROM bus conflict handlingPosted: Mon Oct 08, 2018 11:53 am

Joined: Fri Mar 16, 2018 1:52 pm
Posts: 80
Location: Finland
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:
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?

Top

 Post subject: Re: UNROM bus conflict handlingPosted: Mon Oct 08, 2018 11:54 am

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7977
Location: Seattle
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

Top

 Post subject: Re: UNROM bus conflict handlingPosted: Mon Oct 08, 2018 12:25 pm

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3776
Location: A world gone mad
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

Top

 Post subject: Re: UNROM bus conflict handlingPosted: Mon Oct 08, 2018 12:30 pm

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7118
Location: Canada
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.

Top

 Post subject: Re: UNROM bus conflict handlingPosted: Mon Oct 08, 2018 12:31 pm

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11099
Location: Rio de Janeiro - Brazil
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.

Quote:
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.

Top

 Post subject: Re: UNROM bus conflict handlingPosted: Tue Oct 09, 2018 2:19 am

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7651
Location: Chexbres, VD, Switzerland
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:
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:
LDA #bank
STA table+bank

to select a fixed bank or

Code:
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:
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.

Top

 Post subject: Re: UNROM bus conflict handlingPosted: Tue Oct 09, 2018 10:49 am

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7118
Location: Canada
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.

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 1 of 1 [ 10 posts ]

 All times are UTC - 7 hours

#### Who is online

Users browsing this forum: No registered users and 2 guests

 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum

Search for:
 Jump to:  Select a forum ------------------ NES / Famicom    NESdev    NESemdev    NES Graphics    NES Music    Homebrew Projects       2018 NESdev Competition       2017 NESdev Competition       2016 NESdev Competition       2014 NESdev Competition       2011 NESdev Competition    Newbie Help Center    NES Hardware and Flash Equipment       Reproduction    NESdev International       FCdev       NESdev China       NESdev Middle East Other    General Stuff    Membler Industries    Other Retro Dev       SNESdev       GBDev    Test Forum Site Issues    phpBB Issues    Web Issues    nesdevWiki
Powered by phpBB® Forum Software © phpBB Group