SpritesMind.Net

yeah, give us more challenge !

Hell yeah!!

I can't really explain it... you access data beyond the ROM size and get the data form the ROM... that applies to ROMs that are smaller than 4MBytes. So you have 2MByte ROM, it accesses data after the 2MBytes, and it gets the data form the ROM at location : address - 2MB... I don't know if it makes any sense...

That's called 'mirroring', afaik, and usually happens because of incomplete address decoding in hardware.

yes, it makes sense
so this mean that rom access should be handled like this (pseudo C code for byte access, for example):

return cart_rom[address & (rom_size-1)]


that's interesting: is it default behavior or does it need that cartridge hardware support this ? I always thought that unmapped address would return undefined data on bus

btw, how work address decoding from the cart side, does it depend on the eeproms size ? the number of eeproms ?

TmEE co.(TM) wrote:I can't really explain it... you access data beyond the ROM size and get the data form the ROM... that applies to ROMs that are smaller than 4MBytes. So you have 2MByte ROM, it accesses data after the 2MBytes, and it gets the data form the ROM at location : address - 2MB... I don't know if it makes any sense...

Could you write a similar program like your "emulator detector" to test this?

Eke wrote:that's interesting: is it default behavior or does it need that cartridge hardware support this ? I always thought that unmapped address would return undefined data on bus

For example, if you have CS of ROM to be active for range #0000..FFFF, but ROM has only 12 lines (A0..A11, 4096 bytes), it will be mapped in whole range, but because A12..A15 will be not connected and thus ignored, it will be 'mirrored' (repeated 16 times). It happens because of simplified decoding logic, so it not needs additional hardware (it needs additional hardware if you want to prevent mirroring).

It usually emulated by logical operations which mask some bits of address.

I can't see how this could not be emulated...or am I missing something??

AND the addresses with ROM size

You have to AND with ROM Size-1 or do something like ROM[addr % rom_size]

address bits masking work for games which rom size is a factor of 2 (128Kb, 256kb,512kb, 1MB,...)
but for example, when you have a rom size of 768KB (mapped between 0-$BFFFF), you can't simply mask the address with the rom size in that case (A0-A20 are used but A19 is meant to be zero)

when the program accesses cart-area beyond ROM size, then just AND the address used with ROM size.

Also, you can identify emulators by running benchmarks... I made a small private proggy that tells you which emulator its running on... at least what emus I have (need to test Regen ). That you can't fool, unless your emu is PERFECT. Even Fusion fails.

TmEE co.(TM) wrote: Also, you can identify emulators by running benchmarks... I made a small private proggy that tells you which emulator its running on... at least what emus I have (need to test Regen ). That you can't fool, unless your emu is PERFECT. Even Fusion fails.

What do you benchmark?

68K... but I can try Z80 and YM2612 timers and busy bit... no emulator emulates them perfectly.

TmEE co.(TM) wrote:68K... but I can try Z80 and YM2612 timers and busy bit... no emulator emulates them perfectly.

Tell me how far is Regen is from real thing. I am always trying to get it perfect.

Sure.

Tomorrow I'll probably make another emu detector... which no emulator passes


BTW, AamirM, I noticed that your emu's screen is few pixels bigger and it causes lots of slowdown on my PC. The 320x240 screen is 320x247... can you fix it ?

Also, the YM2612 PCM/DAC is not very good too, only Fusion emulates it almost perfectly (it has one flaw).
A proggy to test PCM and a real HW recording : http://www.sega-16.com/forum/showthread.php?t=4091