TraceBullet/vba-rerecording

Innacurate MBC1 emulation for GBx

Closed this issue · 2 comments

Problem 1: VBA allows ROM bank 0x00 to be accessed between 0x4000-0x7FFF, when 
in real GBx, 0x01 is accessed instead:

What steps will reproduce the problem?

Write bXXX00000 anywhere in the range 2000-3FFF.

For example in Super Mario Land 2 go down at least 34 (and less than 66) rows 
into the garbage data, then destroy a block. This will write 0x60 (b0110000) 
somewhere in the range 2000-3FFF. 

What is the expected output? What do you see instead?

The expected output is that 0x4000-0x7FFF should show ROM bank 0x01, instead it 
shows ROM bank 0x00

"2000-3FFF - ROM Bank Number (Write Only)
Writing to this address space selects the lower 5 bits of the ROM Bank Number 
(in range 01-1Fh). When 00h is written, the MBC translates that to bank 01h 
also. That doesn't harm so far, because ROM Bank 00h can be always directly 
accessed by reading from 0000-3FFF.
But (when using the register below to specify the upper ROM Bank bits), the 
same happens for Bank 20h, 40h, and 60h. Any attempt to address these ROM Banks 
will select Bank 21h, 41h, and 61h instead."

Reference: http://nocash.emubase.de/pandocs.htm

Problem 2: VBA registers an illegal write when writing anything to 
0x0000-0x1FFF and crashes the emulator.

What steps will reproduce the problem?

Write anything anywhere in the range 0x0001-0x1FFF.

For example in Super Mario Land 2 go down a few rows into the garbage data, 
then destroy a block. This will write 0x60 somewhere in the range 0000-1FFF. 

What is the expected output? What do you see instead?

Writing anywhere in this area should enable or disable the external RAM, 
instead, it crashed the emulator.

"0000-1FFF - RAM Enable (Write Only)
Before external RAM can be read or written, it must be enabled by writing to 
this address space. It is recommended to disable external RAM after accessing 
it, in order to protect its contents from damage during power down of the 
gameboy. Usually the following values are used:
  00h  Disable RAM (default)
  0Ah  Enable RAM
Practically any value with 0Ah in the lower 4 bits enables RAM, and any other 
value disables RAM."

Reference: http://nocash.emubase.de/pandocs.htm

What version of the product are you using? On what operating system?

VBA-RR v23.4 svn318 (windows)
VBA-RR v23.2 (windows)
VBA-RR v22 (windows)

These are the one's I've tested it on.

Please provide any additional information below.

I'm not entirely sure, but this may lead to finding some more emulation 
innacuracies do do with MBC controllers.

Original issue reported on code.google.com by andrewjpritchard@gmail.com on 11 Jan 2011 at 7:55

Sorry guys, I just got an interim build of VBA 24 and it appears that version 
fixes all of these problems.

Original comment by andrewjpritchard@gmail.com on 11 Jan 2011 at 8:04

I trust you.

Original comment by aquan...@gmail.com on 22 Jan 2011 at 6:27

  • Changed state: Invalid
  • Added labels: Priority-High
  • Removed labels: Priority-Medium