It is currently Sun Nov 19, 2017 5:29 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 47 posts ]  Go to page 1, 2, 3, 4  Next
Author Message
 Post subject: Emulating Bus Conflicts
PostPosted: Sat Mar 09, 2013 1:47 pm 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
I have read documentation that says that what value the CPU is writing 'generally wins' but does anybody have a statistic for this? (70%? 99%)

Also are bus conflicts even across mappers/boards that have them or are some more prone to others?

I know that it isn't really necessary for NES emulation but it is more of an accuracy thing that I am interested in implementing into my emulator.

_________________
http://www.jamesturner.de/


Top
 Profile  
 
PostPosted: Sat Mar 09, 2013 2:42 pm 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2803
I don't know about "generally wins" but if you want to emulate or simulate bus conflicts you might want to figure that if a bus conflict happens, return both sources ORed together. While it isn't necessarily what would happen on a real board in theory you want to return not the CPU value since if the CPU really generally wins then we wouldn't have to worry about bus conflicts.

But there is another problem. Mapper 7 sometimes has another chip to disable PRG-ROM during writes. But there is no iNES flag to determine this. And similarly any discrete logic could also have this chip to do that.


Top
 Profile  
 
PostPosted: Sat Mar 09, 2013 2:57 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 932
MottZilla wrote:
I don't know about "generally wins" but if you want to emulate or simulate bus conflicts you might want to figure that if a bus conflict happens, return both sources ORed together. While it isn't necessarily what would happen on a real board in theory you want to return not the CPU value since if the CPU really generally wins then we wouldn't have to worry about bus conflicts.
I thought I read somewhere else it is AND, but maybe not?

Quote:
But there is another problem. Mapper 7 sometimes has another chip to disable PRG-ROM during writes. But there is no iNES flag to determine this. And similarly any discrete logic could also have this chip to do that.
Does the NES 2.0 submapper numbers have any flag to specify?

_________________
.


Top
 Profile  
 
PostPosted: Sat Mar 09, 2013 3:03 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19230
Location: NE Indiana, USA (NTSC)
NMOS usually has "and" behavior: a transistor pulling down to 0 beats a resistor pulling up to 1.

There's a submapper draft covering bus conflicts on discrete mappers.


Top
 Profile  
 
PostPosted: Sun Mar 10, 2013 10:39 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7266
Location: Chexbres, VD, Switzerland
Since there is no PMOS transistor in the CPU, whenever the CPU wants to write a 1, only a weak NMOS transistor mounted drives the bus line to +VCC. If an EPROM (or another thing) is trying to pull the line low, it will succeed without any doubt, and a '0' will be output.

If the CPU wants to write a '0', it's more ambiguous. A strong NMOS transistor in the CPU will drive the line to GND, but an external EPROM will probably be made of CMOS technology, and so a strong PMOS transistor in the EPROM will also drive the line to +VCC. The situation is ambiguous.
NMOS transistors are usually stronger than PMOS so again the '0' from the CPU will probably win, but the EPROM could as well be made of more modern transistors that will win against the CPU. In this case, the EPROM could as well win with it's '1'. Also, the mapper is physically closer to the EPROM (I'm not sure if this actually plays a role).

For this reason, both the AND behaviour, and the "EPROM wins" behaviour could be encountered, and be considered correct. Only thing I'd say is that the CPU will never win by writing a conflicting '1'.

EDIT : It's possible that mask ROMs in NES games were not CMOS, but NMOS too, like the CPU, especially for early (<1988) made games which had 128kb or more of PRG ROM (you know, those games which became hot when you play them for a long period of time). In this case, the AND behaviour is without a doubt what will be encountered.


Top
 Profile  
 
PostPosted: Sun Mar 10, 2013 11:21 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1923
Location: WhereverIparkIt, USA
If it's on the powerpak that's outputing a '1' the CPU should win either way. If the powerpak outputs a '0' the powerpak will probably win either way.

If it's really an unknown, but you're most likely to get an AND or an OR function depending on things specific to the cartridge and such why now just implement both. Randomly select whether it's AND/OR or possibly powerpak logic above. A game shouldn't rely on bus conflicts. You're really only looking to break a game that has bus conflicts for homebrew development correct? If that's the case something like the ability to turn on warning messages might be nice where you display transparent text informing the developer that they're causing bus conflicts and could get strange behavior. But if you were to bankswitch via bus conflict your game will probably jam anyways giving you enough info to know something's going wrong. You just need to make sure something goes wrong, so there aren't surprises when running on the NES.

More importantly make sure you're only implementing bus conflicts when the mapper is subject to them, as Tepples linked to. Basically all discrete mappers are subject to bus conflicts except ANROM. Since the other members of that mapper family have bus conflicts, you won't be able to implement bus conflicts unless you use submappers. You certainly wouldn't want to implement bus conflicts on any of the ASIC mappers, You'd have to check each one, but I'd guess none of them do.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Sun Mar 10, 2013 11:26 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
infiniteneslives wrote:
A game shouldn't rely on bus conflicts.

Some do, though, by accident: viewtopic.php?f=3&t=7273

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Sun Mar 10, 2013 11:43 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1923
Location: WhereverIparkIt, USA
thefox wrote:
infiniteneslives wrote:
A game shouldn't rely on bus conflicts.

Some do, though, by accident: viewtopic.php?f=3&t=7273


Then perhaps the best option is to have the user select whether to emulate them allowing games like that to work (are there known others?), or randomly resolve bus conflicts to break the game.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Sun Mar 10, 2013 12:15 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
I agree that an emulator should have an accurate hardware mode, and a development mode that can warn of things that won't behave consistently on hardware or do things that will break games which rely on them. One thing the warnings do is expose bugs in the emulator where it's doing something wrong that causes warnings where there shouldn't be.


Top
 Profile  
 
PostPosted: Sun Mar 10, 2013 12:35 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
Can't find a game that does it, but just an LDA $4016 AND $43 CMP #$41 to rread the controller will surely be broken without bus conflicts.

IMO bus conflicts shouldn't even be an option. Put them in! :)


Top
 Profile  
 
PostPosted: Sun Mar 10, 2013 1:26 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7266
Location: Chexbres, VD, Switzerland
Quote:
Can't find a game that does it, but just an LDA $4016 AND $43 CMP #$41 to rread the controller will surely be broken without bus conflicts.

You're confusing bus conflics and open bus, my friend.

Quote:
If it's really an unknown, but you're most likely to get an AND or an OR function depending on things specific to the cartridge and such why now just implement both.

It can't be an OR function, as the CPU will never win when writing a "1" (see my post above). It could be either a AND function or a "ROM always wins" function.

Quote:
I agree that an emulator should have an accurate hardware mode, and a development mode that can warn of things that won't behave consistently on hardware or do things that will break games which rely on them. One thing the warnings do is expose bugs in the emulator where it's doing something wrong that causes warnings where there shouldn't be.

I agree. Such a development mode should trap not only bus conflicts, but undocumented opcodes, use of uninitialised memory, and attempts to write to VRAM outside of VBlank.


Top
 Profile  
 
PostPosted: Sun Mar 10, 2013 4:06 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19230
Location: NE Indiana, USA (NTSC)
Bregalad wrote:
Such a development mode should trap not only bus conflicts, but undocumented opcodes, use of uninitialised memory, and attempts to write to VRAM outside of VBlank.

Agreed with one proviso: allow the developer to specify a fine-grained whitelist for intentional use of stable unofficial opcodes.


Top
 Profile  
 
PostPosted: Sun Mar 17, 2013 2:53 pm 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
Thanks guys but none of this really answers my original answer.

In the event of a bus conflict what happens, and how often does 'it' happen.

_________________
http://www.jamesturner.de/


Top
 Profile  
 
PostPosted: Sun Mar 17, 2013 2:56 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
Every time a output isn't the same on both chips asserting on the bus.


Top
 Profile  
 
PostPosted: Sun Mar 17, 2013 3:14 pm 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
3gengames wrote:
Every time a output isn't the same on both chips asserting on the bus.


I find this setence a little crytic :oops:.

_________________
http://www.jamesturner.de/


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 47 posts ]  Go to page 1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 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