support trimmed roms to non 4-aligned sizes (supposedly a regression from 0.9.10)

This commit is contained in:
zeromus 2015-07-25 23:46:58 +00:00
parent 9b370cd602
commit 5a55349155
2 changed files with 33 additions and 8 deletions

View File

@ -545,24 +545,49 @@ void GameInfo::closeROM()
u32 GameInfo::readROM(u32 pos)
{
u32 num;
u32 data;
if (!romdata)
{
u32 data;
if (lastReadPos != pos)
fseek(fROM, pos + headerOffset, SEEK_SET);
u32 num = fread(&data, 1, 4, fROM);
num = fread(&data, 1, 4, fROM);
lastReadPos = (pos + num);
return LE_TO_LOCAL_32(data);
}
else
{
if(pos + 4 > romsize)
if(pos + 4 <= romsize)
{
printf("Panic! GameInfo reading out of buffer!\n");
exit(-1);
//fast path
data = LE_TO_LOCAL_32(*(u32*)(romdata + pos));
num = 4;
}
else
{
data = 0;
num = 0;
for(int i=0;i<4;i++)
{
if(pos >= romsize)
break;
data |= (romdata[pos]<<(i*8));
pos++;
num++;
}
}
return LE_TO_LOCAL_32(*(u32*)(romdata + pos));
}
//in case we didn't read enough data, pad the remainder with 0xFF
u32 pad = 0;
while(num<4)
{
pad >>= 8;
pad |= 0xFF000000;
num++;
}
return LE_TO_LOCAL_32(data) & ~pad | pad;
}
bool GameInfo::isDSiEnhanced()

View File

@ -71,10 +71,10 @@ u32 Slot1Comp_Rom::read()
//if (address > gameInfo.header.endROMoffset)
// ... the cart hardware doesnt know anything about the rom header. if it has a totally bogus endROMoffset, the cart will probably work just fine. and, the +4 is missing anyway:
//3. this is better: it just allows us to read 0xFF anywhere we dont have rom data. forget what the header says
//note: we allow the reading to proceed anyway, because the readROM method is built to allow jaggedy reads off the end of the rom to support trimmed roms
if(address+4 > gameInfo.romsize)
{
DEBUG_Notify.ReadBeyondEndOfCart(address,gameInfo.romsize);
return 0xFFFFFFFF;
}
//actually read from the ROM provider