Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
02802 Gameplay Critical (emulation) Always Jan 6, 2009, 06:08 Jan 10, 2009, 13:21
Tester mash View Status Public Platform SDLMAME
Assigned To R. Belmont Resolution Fixed OS Linux
Status [?] Resolved Driver parodius.cpp
Version 0.129 Fixed in Version 0.129u1 Build 64-bit
Summary 02802: parodius, parodiusj: ram rom check fails
Description On my 64-bit sdlmame, ram rom check fails.
This does not happen on the 32-bit compiled sdlmame.
So, the problem is 64-bit speciffic.
Steps To Reproduce
Additional Information parodisj -> parodiusj in 0.133u1
Flags 64-bit specific
Regression Version
Affected Sets / Systems parodius, parodiusj
Attached Files
There are no relationship linked to this issue.
User avatar
Jan 6, 2009, 11:22
edited on: Jan 6, 2009, 12:57
There was discussion of this being a possible SDL specific issue. Not sure if there was ever a resolution, but it might be worth bringing it up again there:

As stated, in a normal baseline build - the problem doesn't happen. I'll wait for 64-bit Windows and SDL users to test and report.
User avatar
Jan 6, 2009, 12:55
Doesn't repoduce on MameUI64 - Vista64.
User avatar
Jan 7, 2009, 15:09
No repro for me with vmame64 on vista 64.
User avatar
Jan 7, 2009, 15:18
Ok - we need some input from SDLMAME users - is anyone having this issue? I'm guessing at this point it's an isolated (non MAME) issue, but you never know.
User avatar
Jan 7, 2009, 21:45
64-bit SDLMAME (based from MESS SVN, since that's what I have handy) shows C5 as bad, and some repeated clicking sound occurs during this too. Occasionally, C5 is given as OK, but it then resets at the cross hatch pattern.

Have yet to try out 32-bit SDLMAME.
User avatar
Senior Tester
Jan 7, 2009, 23:51
edited on: Jan 7, 2009, 23:53
parodius doesn't use eeprom, so it's not an f2+f3 issue

ROM_REGION( 0x80000, "konami", 0 ) /* 053260 samples */
ROM_LOAD( "955d04.bin", 0x00000, 0x80000, CRC(e671491a) SHA1(79e71cb5212eb7d14d3479b0734ea0270473a66d) )

is rom c3, the sample rom.

it can read the sound rom with

static READ8_HANDLER( parodius_sound_r )
return k053260_0_r(space,2 + offset);

(why the +2?, looks odd..)

which calls

READ8_HANDLER( k053260_0_r )
return k053260_read( space, offset, 0 );

which reads the rom with

case 0x2e: /* read rom */
if ( ic->mode & 1 ) {
unsigned int offs = ic->channels[0].start + ( ic->channels[0].pos >> BASE_SHIFT ) + ( ic->channels[0].bank << 16 );

ic->channels[0].pos += ( 1 << 16 );

if ( offs > ic->rom_size ) {
logerror("%s: K53260: Attempting to read past rom size in rom Read Mode (offs = %06x, size = %06x).\n", cpuexec_describe_context(space->machine),offs,ic->rom_size );

return 0;

return ic->rom[offs];

rom is unsigned char *rom;

is unsigned char actually 8-bit on 64-bit ? (dumb question maybe)
still.. should probably be using UINT8 etc.. I'm definitely not keen on that code.

somebody with 64-bit and the issue will have to trace / log through the code anyway.. it's clearly failing to read the sound rom correctly.
User avatar
Jan 8, 2009, 17:48
With the confirmation and some explanation even though I cannot reproduce this - I'll confirm it.
User avatar
R. Belmont
Jan 10, 2009, 04:52
Problem was the banking of the ROM reading went wrong when 'unsigned long' was > 32 bits. Replaced all instances of 'unsigned long' with UINT32 and Parodius plays fine on x64 Linux.
User avatar
Senior Tester
Jan 10, 2009, 13:21
edited on: Jan 10, 2009, 13:22
right.. as a general rule the mame types (UINT8, UINT16, UINT32 etc. should be used whenever possible..)

(which is why I really didn't like the look of that sound code..)