mame icon indicating copy to clipboard operation
mame copied to clipboard

neogeo.cpp incorrect memory card access behavior compared to real hardware

Open jwestfall69 opened this issue 5 years ago • 3 comments

I've been working on adding memory card testing support to the neo geo diag bios and came across a behavior issue with it in mame.

The neo geo hardware memory map has 0x800000 - 0xBFFFFF setup for memory card.

In mame when you load a memory card (2k/8bit) it gets mapped to 0x800000 to 0x800FFF as seen here in drivers/neogeo.cpp

        if (m_memcard)
        {
                main_program_space.unmap_readwrite(0x800000, 0x800fff);
                main_program_space.install_read_handler(0x800000, 0x800fff, read16sm_delegate(*this, FUNC(ngarcade_base_state::memcard_r)));
                main_program_space.install_write_handler(0x800000, 0x800fff, write16s_delegate(*this, FUNC(ngarcade_base_state::memcard_w)));
        }

The behavior issue comes into play when access memory above address space that the memory card supports (ie trying to detect the size of the memory card).

On hardware if you had a 2k/8 bit card and tried to access 0x801000, it would end up mapping to 0x800000 because that high address line is not wired up on the card and gets ignored.

The behavior in mame is (i assume) writes do nothing and reads always result in 0x0.

This doesn't seem to be a problem on stock bios because of how its doing the memory card size test, its basically doing

  move.w #$aa, (a0) ; probe address 0x801000
  move.w #$0, (a6)  ; 0x800000
  move.w (a0), d0   ; results in 0x0000, which is technically correct but for the wrong reason.
  cmp.w. #$aa, d0
  bne stop_probe

I had used a slightly different approach which works on hardware but not mame

  move.w #$55, (a0) ; 0x800000
.next_probe_address:
  move.w #$aa, (a1) ; probe address
  move.w (a0), d0
  cmp.b #$55, d0
  bne .stop_probe
...
  setup next probe address, loop to .next_probe_address

The write to the probe address would do nothing instead of being mapped to 0x800000 like it is on hardware, which causes the read of 0x800000 to always be 0x55.

I will switch to the way the stock bios is doing it, but wanted to bring the behavior issue to your attention.

thanks

jwestfall69 avatar Dec 24 '20 01:12 jwestfall69

This is a characteristic of the card itself, though. The address lines are all connected, but the card may or may not decode all of them. Your card is showing mirroring behaviour because it has a single chip and no decoding logic. That isn't necessarily the case for all memory cards.

cuavas avatar Dec 24 '20 02:12 cuavas

My original code was able to detect the proper card size on hardware with all the cards I have for testing, which are

2k 8bit (original neo geo card sram) 16k 8bit (reproduction fram every makes) 64k 16bit double wide (generic sram) 256 8bit (generic sram) 256k 16bit double wide (generic sram) 512k 16bit double wide (generic sram) 1024k 16bit double wide (generic sram)

Same code in mame doesn't because the lack of mirroring. I switched my code to handle the lack of mirroring, so in the end it doesn't matter to me.

I was bringing it up because the behavior is different between mame and hardware, assuming mame is trying to mimic an official 2k card. If this isn't considered something worth fixing please close the issue.

thanks

jwestfall69 avatar Dec 24 '20 04:12 jwestfall69

To my knowledge Neo-Geo uses JEIDA v3 format (68-pin), which is also reused by PC-98HA for a handful of SW cards. The underlying emulation is pretty much a stub, lacks better abstraction of the various pins (namely WP and BUSY signals, I'm assuming that CD1 & CD2 are just keyed connections?), plus as you mentioned a proper template creator (8/16-bit and size).

https://wiki.neogeodev.org/index.php?title=Memory_card https://wiki.neogeodev.org/index.php?title=Memory_card_pinout

angelosa avatar Feb 26 '22 16:02 angelosa