Konami VRC2 - $6000

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Konami VRC2 - $6000

Post by Near »

Ran into a problem with VRC2 that wasn't documented in the Wiki or Disch's docs, so I added it to the Wiki. Posting here to explain the change.

So, since VRC4 is basically (VRC2++)++, it seems most emulators probably just use VRC4 on it, and thus the VRC2 games have 8KB of PRG RAM mapped from $6000-7fff. However, VRC2 lacks any PRG RAM, as you can see from this board screenshot:

http://bootgod.dyndns.org:7777/profile.php?id=1568

And yet, VRC2 games seem to expect to be able to write to $6000.d0, and read back the result. If this fails, the games crash before showing any graphics. This is true for at least Contra (J) and Ganbare Goemon 2 (J). I didn't test any others.

I've verified that neither 0x00 nor CPU MDR (open bus) allow the games to work. Here's a disassembly from Contra (J):

Code: Select all

f863  ldy #$03      A:05 X:00 Y:ff S:ff nvdIzC
f865  tya           A:05 X:00 Y:03 S:ff nvdIzC
f866  and #$01      A:03 X:00 Y:03 S:ff nvdIzC
f868  sta $07e9     A:01 X:00 Y:03 S:ff nvdIzC
f86b  sta $6000     A:01 X:00 Y:03 S:ff nvdIzC
f86e  lda $6000     A:01 X:00 Y:03 S:ff nvdIzC  //returns open bus here
f871  and #$01      A:60 X:00 Y:03 S:ff nvdIzC
f873  cmp $07e9     A:00 X:00 Y:03 S:ff nvdIZC
f876  bne $f87d     A:00 X:00 Y:03 S:ff NvdIzc
f87d  jmp $0000     A:00 X:00 Y:03 S:ff NvdIzc
0000  brk #$01      A:00 X:00 Y:03 S:ff NvdIzc
f8e1  rti           A:00 X:00 Y:03 S:fc NvdIzc
...
I have no idea what $6000.d0 is or does: it may be a chip enable, it may just be a one-bit storage latch. Who knows. Anything can be returned in d1-d7, and nothing needs to happen for $6001-7fff for the games to work.

I've added the info to the Wiki here:

http://wiki.nesdev.com/w/index.php/VRC2 ... .246000.29

Feel free to make any changes/corrections.
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla »

Shouldn't be hard to get someone with a test cartridge to run a simple program to verify this behavior, or have you already?
2600
Posts: 96
Joined: Tue Aug 07, 2007 10:28 am

Post by 2600 »

On real hardware, I'd bet that the address for that latch is more then just $6000.
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla »

Perhaps any write from $6000 to $FFFF gets latched and can be read back in the $6000 to $7FFF range?
2600
Posts: 96
Joined: Tue Aug 07, 2007 10:28 am

Post by 2600 »

MottZilla wrote:Perhaps any write from $6000 to $FFFF gets latched and can be read back in the $6000 to $7FFF range?
I thought that first, but because VRC2 looks at some of the lower bits it could be $6000,$6004, etc or some other combination.

Like you said though it would be easy to determine.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Post by Near »

It would be great if someone could test it. I don't have any kind of hardware setup for NES stuff.

What I usually do with empirical research is implement the absolute minimum possible to get something working. If we need more than one bit, or to mirror to more than one address, then we will need to verify it on hardware first. Safer in case homebrew tries to use it.
BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Post by BootGod »

Tested on my Contra cart, d0 does get latched when writing 6000-6fff, there is no effect on the 7000-7fff region, even when writing to that region.

The WRAM area returns open bus normally, when d0 is set, everything in the 6xxx region reads open bus OR'd by 1

You need any other tests done, let me know, I still have the majority of carts in the DB here (submitted by me anyways).
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Post by Zepper »

Does "open bus" mean the high byte of the address, in this case, 0x60 ORed with 1 (0x61)?
BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Post by BootGod »

Yep, that's a better way of putting it.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Post by Near »

You need any other tests done, let me know
Thank you so much! :D
Really nice of you to test, I appreciate that.

I have two last questions on this chip, if you don't mind.

1. you said open bus OR'ed by 1. So if you write $00 to $6000, then read from $6100, it will return $61 instead of $60? In other words, d0 is not the bit to return, but rather the bit to OR against the return. Just want to be certain. Guessing case 0x6000: return MDR | 6000_write_bit;

2. is the power-on value of $6000.d0 zero, one or undefined (random)? Guessing zero.
Does "open bus" mean the high byte of the address, in this case, 0x60 ORed with 1 (0x61)?
I'm not a fan of this method, it fails on the SNES in a few games. I know the NES is more limited, but I'm sure there are ways to read from $6000 without the previous cycle being a fetch from the high-byte of the address.

The technical term is the MDR (memory data register), but emulation authors tend to call it open bus. It's always the last value on the data bus, either from a read or a write.
BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Post by BootGod »

1. Yep, that's it exactly, d0 is OR'd against the return.
2. On power on, the latch is not set, so yes $6000.d0 is 0

Zepper: on second look, it is not always the high-byte of the address returned in the $6xxx region.

$6000-61ff returns $60 or $61 (if latch set)
$6200-63ff returns $62 or $63 (^)
...
$6e00-6fff returns $6e or $6f

The $7xxx region is "normal" though and always returns the high-byte of address
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Post by Zepper »

BootGod wrote:Zepper: on second look, it is not always the high-byte of the address returned in the $6xxx region.

$6000-61ff returns $60 or $61 (if latch set)
$6200-63ff returns $62 or $63 (^)
...
$6e00-6fff returns $6e or $6f

The $7xxx region is "normal" though and always returns the high-byte of address
That's what I meant, if not clear. :)
User avatar
Jarhmander
Formerly ~J-@D!~
Posts: 569
Joined: Sun Mar 12, 2006 12:36 am
Location: Rive nord de Montréal

Post by Jarhmander »

byuu wrote:The technical term is the MDR (memory data register), but emulation authors tend to call it open bus. It's always the last value on the data bus, either from a read or a write.
Is the MDR a bus-holder?
User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Post by kyuusaku »

????

The 65XXX's data latch (DL) and pre-decode register (PD) are "MDR", open-bus values are from persistent voltage due to parasitic capacitance of IC pins. People call it open-bus because that's what it is, a condition where the bus is open (/not driven/disconnected like an open-connection). This may refer to the full bus width or a single bit. If I understand correctly in this thread there is a register which drives a single bit, D0, and the other bits will return open-bus.

read_value = (previous_bus_value & 0xFE) | (6000_reg & 1)

note that 6000_reg doesn't necessarily return what is written to it. Famicom copiers always map RAM to $6000-7FFF, so that is the basis of this protection.


Bus-holders are similar, but are active/have amplificative properties so will persist forever instead of decay like open-bus. In other words open-bus is unintentional, bus-holders are intentional to prevent oscillations/lower power consumption. AFAIK 65XXX do not have bus-holders but unless you wish to emulate the bus' analog properties in a multi-processor system the keeping mechanism is probably irrelevant.
Last edited by kyuusaku on Sun Nov 06, 2011 1:30 pm, edited 1 time in total.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

What about this cart who apparently has VRC2 and SRAM ?

EDIT : Fixed the url
Last edited by Bregalad on Sun Nov 06, 2011 1:57 pm, edited 2 times in total.
Useless, lumbering half-wits don't scare us.
Post Reply