It is currently Sat Dec 15, 2018 12:56 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Mon Oct 08, 2018 9:50 am 
Offline
User avatar

Joined: Fri Mar 16, 2018 1:52 pm
Posts: 67
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
 Profile  
 
PostPosted: Mon Oct 08, 2018 9:55 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7017
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
 Profile  
 
PostPosted: Mon Oct 08, 2018 10:03 am 
Offline

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


Top
 Profile  
 
PostPosted: Mon Oct 08, 2018 11:53 am 
Offline
User avatar

Joined: Fri Mar 16, 2018 1:52 pm
Posts: 67
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
 Profile  
 
PostPosted: Mon Oct 08, 2018 11:54 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7825
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
 Profile  
 
PostPosted: Mon Oct 08, 2018 12:25 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3725
Location: Mountain View, CA
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
 Profile  
 
PostPosted: Mon Oct 08, 2018 12:30 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7017
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
 Profile  
 
PostPosted: Mon Oct 08, 2018 12:31 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11012
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
 Profile  
 
PostPosted: Tue Oct 09, 2018 2:19 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7604
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
 Profile  
 
PostPosted: Tue Oct 09, 2018 10:49 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7017
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
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 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 forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group