Nestopia or Nintendulator, Do Either emulate Bus Conflicts?

[MottZilla]

Very simple question. I did a hack of a game from one mapper to UxROM and I cannot be sure it conforms to avoid bus conflicts so I was wondering if either emulator would emulate this. Both emulators seem to run the hack fine. Problem is I'm in doubt that the game doesn't have bus conflicts as some mapper writes aren't your typical STA $####,X where you have an array of 00 01 02 and so on. However some of the mapper writes ARE that way. So it's confusing and so if either emulator does emulate bus conflicts that would be nice to know. Neither said anything in their readme files.

[kyuusaku]

I don't think any emulator will crash on a bus conflict so I would go about this by using FCEUXDSP for the conditional breakpoint feature. First break on any write, and note every address used, then put conditional breakpoints for A, X and Y != $address for each of the addresses.

[MottZilla]

I'll grab FCEUXDSP sometime and see myself I guess. And I didn't mean the emulator crashing, I mean do these emulators emulate bus conflicts where with UxROM if you write to $8000 - $FFFF a value of lets say 1 but the address you wrote to contains 2, shouldn't the emulator not respond to the program as you would think? I seem to recall bus confilcts tend to take both values and they are ANDed together. At the very least you are unlikely to get what you wanted unless you write to an address containing the value you are writing.

So that's what I'm asking is if either emulator handles bus conflict behavior or if it lets bad ROMs behave badly.

[kyuusaku]

How bus conflicts work depends on the ROM family, the values won't always be ANDed if the ROM can source as well as it can sink.

I wouldn't call a UNROM game with bus conflicts really a bad ROM, just not suitable for the original UNROM board, which is the programmer's problem, not the mapper or emulator's. Mappers generally take a few liberties with boards, like extending CNROM for mapper 3 and giving all mappers WRAM, so it's no surprise they aleve bus conflicts which certainly weren't intended in the first place.

[MottZilla]

Well, I took an easier route and modified my emulator to tell me when a UxROM game was writing to ROM a value that was different than what exists there and the game I was concerned about does have bus conflicts. However, only during the startup, not during the game itself. And no matter what I did to decide what bank to make it if there was a bus conflict, such as ANDing, ORing, setting any value I want, the game always ran still so I'm happy with it now.

It is interesting to know more about bus conflicts now though.

[tepples]

Bus conflict avoidance is one 74HC02 chip to disable the ROM during writes. This chip was the only difference between AMROM and ANROM. WRAM is two chips: a 6264 RAM and kyuusaku's 74HC10 based decoder. But granted, chips weren't cheap as chips in the classic era.

[kyuusaku]

kyuusaku's 74HC10 based decoder.

OT: I don't think the 7410 circuit will work afterall because there's a race condition that could trigger unintentional writes :( Still a 7410 could be used to decode an active high enable RAM like 6264 while preventing bus conflicts and have an AND3 gate left over. Since Phi2 apparently goes HiZ during reset, this circuit's pulldown may offer some write protection: http://img504.imageshack.us/img504/9528/updatepr8.png

Or you could just use a NAND4 to decode any active low memory, also using the /WE priority method. If this is done with a two gate 7420, the second gate could be used to invert r/w to prevent bus conflicts as in the circuit above. This is probably the *final* best way unless you happen to need the extra AND3 from the 7410 and have a positive CE.

[bunnyboy]

Since Phi2 apparently goes HiZ during reset, this circuit's pulldown may offer some write protection: http://img504.imageshack.us/img504/9528/updatepr8.png

Any suggestions for how large "big R" should be? 1K? 10K? 100K?

[Zepper]

- Since both emulators are open source, you should give a look into it. As far as I can tell you, from a quick look into it, yes, Nintendulator emulates bus conflicts. Of course, this might be subjective, as I'm "guessing" anyways.

[blargg]

For intentional writes to $8000-$FFFF, you could always read the current value then write it back, ensuring there are no conflicts. But this doesn't cover unintentional writes there, as your improvement to the emulator does.

[kyuusaku]

Any suggestions for how large "big R" should be? 1K? 10K? 100K?

4.7K for LS or 10K for HC inputs I'd guess. I wonder how much protection this would actually offer. <OT> Anyone have an idea how to best corrupt RAM powering off?