MAME vs Real AES Hardware - Page 1

Hi fellow developers,

Just wondering if any of you had experienced different behaviour on your homebrew efforts under MAME vs real hardware?

At this early stage of my development I'm not overly concerned, but I am a little surprised that I do see a number of differences. I won't bore you with details but I do, for example, suspect VRAM accesses are (significantly?) faster under MAME than real hardware?!?

I also see a few other minor behavioural differences, but I can't rule out the possibility that my code isn't following the rules. Regardless, I'd expect an accurate emulator to behave the same way.

Interested to know if you have similar observations?

Regards,
Mark

You are right, the timing is minimally different but generally MAME is the best emulator and very close to the real hardware.
MAME is not perfect (e.g. Raster effects) but if it works in MAME then you can be sure that 99.9% of the time it will work on real hardware - no matter if MVS, AES or NGCD.
The only thing you should keep in mind - ALWAYS use the original bios, the UNIBIOS falsifies some things (e.g. the timing).

blastar (./2) :
You are right, the timing is minimally different but generally MAME is the best emulator and very close to the real hardware.
MAME is not perfect (e.g. Raster effects) but if it works in MAME then you can be sure that 99.9% of the time it will work on real hardware - no matter if MVS, AES or NGCD.
The only thing you should keep in mind - ALWAYS use the original bios, the UNIBIOS falsifies some things (e.g. the timing).

Thanks for the tip on the BIOS - I'm running UniBIOS on my NeoSD by default atm...
FWIW my game runs about 1/2 speed on real hardware, as if every 2nd VBLANK is being missed because I'm spending too much time in there. I probably am atm, because my code is very, very sub-optimal to make it easier to debug.
I'm also seeing my emulated foreground tilemap layer shift down 2 lines after a while, which doesn't happen on MAME. Weird, but again, not concerned yet.

blastar (./2):
ALWAYS use the original bios, the UNIBIOS falsifies some things (e.g. the timing).

That's an interesting advice.

Thanks once more, blastar... : )

tcdev (./1):
Hi fellow developers,

Just wondering if any of you had experienced different behaviour on your homebrew efforts under MAME vs real hardware?

At this early stage of my development I'm not overly concerned, but I am a little surprised that I do see a number of differences. I won't bore you with details but I do, for example, suspect VRAM accesses are (significantly?) faster under MAME than real hardware?!?

I also see a few other minor behavioural differences, but I can't rule out the possibility that my code isn't following the rules. Regardless, I'd expect an accurate emulator to behave the same way.

Interested to know if you have similar observations?

Hey Mark,
no real hardware here yet, but had a go on the AES/NeoSD combination a friend of my owns. And I had problems with the offsets of graphics. Speed seemed to be okay.
I have a rather good grasp on coding the 68k with asm, and know where to scale my engine in that regard.

In my experience so far, excessive VRAM access usually just shears the image, but doesn't slow down.
Imo, most of these slowdowns one might see on the NG in various games just happens because of massive computations, probably mostly collision detection. That kind of stuff can add up fast because it usually scales not linearly.

To answer myself, I have seen one very real difference recently.

For a while I was doing a read/modify/write sequence on VRAM (SCB1) values.

Running on MAME, I had no issue setting the VRAM address and then reading data immediately.

On real hardware, this didn't work at all. In fact I had to insert quite large delays (ballast code) between setting the address and reading the data in order to get them to work properly. To be fair, this is documented (in terms of VCLKS) in Charles McDonald's MVS Hardware Notes document (circa 2007). By my calculations, that's a lot of time required before you can read the data!

Obviously this was a pretty silly way (for me) to do it, and I re-worked my logic to eliminate the VRAM reads altogether.

Just wondering whether anyone else had run into this issue before? Or did you all know well enough not to even attempt VRAM reads?

I wonder why you should read the VRAM?

Yeah I'm curious what idea you had

blastar (./7) :
I wonder why you should read the VRAM?

I had a situation were I was emulating another system and it updated the palette but did not provide X,Y flip at the same time. These fields all reside in a single word in SCB1.

So I was trying to do a read-modify-write sequence that only modified the palette bits. It worked in MAME...

Of course on real hardware this turns out to be extremely inefficient, and still potentially error-prone. I had to re-write my routines to read the rest of the information and construct the entire word each time. In the end it still ran fast enough anyway...

ok, I understand the task and your solution... it is the most obvious but also the ugliest one to read directly the VRAM, I don't think a commercial game will make much use of it. Maybe this is the reason it's not in the focus of emulation accuracy.