Forums

For some reason on my latest update to Video Poker (v0.8) MEKA will not create a ".SAV" file of the 8k SRAM containing the high score.

My old v0.7 one appeared to work, now admittedly I have changed some things - but both Fusion / DEGA work fine with this latest update and both create appropriate save files which get loaded back whenever you reload the ROM image.

I have checked the code many times and cannot see anything wrong with it - just though I should check if MEKA is quirky in anyway with SRAM saves?

It's late here and maybe there is something I missed in my code, but the fact that the two other emulators both create the SRAM file ok doesn't help me get to the bottom of this.

Regards

Richard/Sket

I have uploaded the offending version 0.8 to the homebrew area.

Still not got to the bottom of this yet - still refuses to create a "SAV" SRAM backup file - yet Fusion it works OK.

If anyone has chance to try it on a real SMS and could let me know if it saves the High score or not - I would be most grateful.

Richard / Sket

I'm looking into it now.

OK. you stumbled on a very tricky problem here :)

MEKA attempt to detect the mappers of ROM not into its database.
The way it does it is that it scans for "LD (xxxx), A" opcodes within the first 32 KB of the ROM image for typical mapper signature. In vpoker's case it finds multiple occurrences of "LD (8000h), A" - which I assume are data patterns in your game - and decide that the program uses a Codemasters type of mapper.

If you look into the "technical information" box you can see it says "Mapper:3" at the bottom (3 being the undocumented identifier for Codemasters mapper).

The way I emulate Codemasters mapper is supporting the onboard memory included in Ernie Els Golf, but as no other Codemasters games include battery backed memory it doesn't emulate it with this mapper.

That's a bit annoying since your game is the first ROM image to fail with MEKA detection scheme :) I can "fix" it by adding entries to MEKA database but it would fail the point of updatable homebrew software. I will see if I can finetune my detection heuristic.

In the meanwhile the silly workaround is: include less of 0x32 0x00 0x80 in your ROM or more of 0x32 0xFF 0xFF please ;-)
It is currently finding 8 occurences of the former and 0 of the later.

Note that if you look in the SRAM pane of the Memory Editor it says "None".

Thanks for the reply Bock:

Yes the 8 occurrences of $32 $00 $80 happen to appear in the Intro screen tile data - hence the problem appearing in v0.8 which is the point the new Intro screen was added.

So I have added 9 x $32 $ff $ff as dummy data - and it works (as I'm sure you knew it would).

Just glad to find out I'm not going mad and it is just the way the mapper detection works in MEKA.

I will upload the new v0.8 shortly. <-- Done

Richard / Sket

Author	Message
Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	Problem with my SRAM file and MEKA Posted: Fri Aug 26, 2011 11:20 pm
Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	For some reason on my latest update to Video Poker (v0.8) MEKA will not create a ".SAV" file of the 8k SRAM containing the high score. My old v0.7 one appeared to work, now admittedly I have changed some things - but both Fusion / DEGA work fine with this latest update and both create appropriate save files which get loaded back whenever you reload the ROM image. I have checked the code many times and cannot see anything wrong with it - just though I should check if MEKA is quirky in anyway with SRAM saves? It's late here and maybe there is something I missed in my code, but the fact that the two other emulators both create the SRAM file ok doesn't help me get to the bottom of this. Regards Richard/Sket

Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	Posted: Mon Aug 29, 2011 11:34 am
Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	I have uploaded the offending version 0.8 to the homebrew area. Still not got to the bottom of this yet - still refuses to create a "SAV" SRAM backup file - yet Fusion it works OK. If anyone has chance to try it on a real SMS and could let me know if it saves the High score or not - I would be most grateful. Richard / Sket

Bock Site Admin Joined: 08 Jul 2001 Posts: 8649 Location: Paris, France	Posted: Mon Aug 29, 2011 11:39 am
	I'm looking into it now.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8649 Location: Paris, France	Posted: Mon Aug 29, 2011 11:51 am
	OK. you stumbled on a very tricky problem here :) MEKA attempt to detect the mappers of ROM not into its database. The way it does it is that it scans for "LD (xxxx), A" opcodes within the first 32 KB of the ROM image for typical mapper signature. In vpoker's case it finds multiple occurrences of "LD (8000h), A" - which I assume are data patterns in your game - and decide that the program uses a Codemasters type of mapper. If you look into the "technical information" box you can see it says "Mapper:3" at the bottom (3 being the undocumented identifier for Codemasters mapper). The way I emulate Codemasters mapper is supporting the onboard memory included in Ernie Els Golf, but as no other Codemasters games include battery backed memory it doesn't emulate it with this mapper. That's a bit annoying since your game is the first ROM image to fail with MEKA detection scheme :) I can "fix" it by adding entries to MEKA database but it would fail the point of updatable homebrew software. I will see if I can finetune my detection heuristic. In the meanwhile the silly workaround is: include less of 0x32 0x00 0x80 in your ROM or more of 0x32 0xFF 0xFF please ;-) It is currently finding 8 occurences of the former and 0 of the later.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8649 Location: Paris, France	Posted: Mon Aug 29, 2011 11:56 am
	Note that if you look in the SRAM pane of the Memory Editor it says "None".

Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	Posted: Mon Aug 29, 2011 12:51 pm
Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	Thanks for the reply Bock: Yes the 8 occurrences of $32 $00 $80 happen to appear in the Intro screen tile data - hence the problem appearing in v0.8 which is the point the new Intro screen was added. So I have added 9 x $32 $ff $ff as dummy data - and it works (as I'm sure you knew it would). Just glad to find out I'm not going mad and it is just the way the mapper detection works in MEKA. I will upload the new v0.8 shortly. <-- Done Richard / Sket

Forums

View topic - Problem with my SRAM file and MEKA