Home Page Forums MAME MAME SVN builds - new driver flood

Re-encrypting them isn't terribly hard, the address and data swaps are static, and mame already has good handlers for dealing with those.
The REAL problem is every single pegasus software rom (and the bioses too?) has a serial number embedded in it which is compared against the serial number set on the machine using diodes (and sealed under some epoxyish white putty stuff); if the numbers don't match, the software doesn't run. The bios can apparently be patched to remove/bypass this check, but a better way would probably be to auto-patch (IN RAM! not permanently) every rom to have the correct serial number in it, so the bios checks pass.

LN

Not quite true.. only some of the roms have the check. For example, Monitor 2.3 and 2.3a has no checking. I have a protection-defeat handler in the code which will allow anything to pass the test - no patching is used.

Just about any driver is now crashing on startup if you use the newui.

-----------------------------------------------------
Exception at EIP=7C9369AA (no map): ACCESS VIOLATION
While attempting to read memory at 00000000
-----------------------------------------------------
EAX=00000000 EBX=00000086 ECX=06F605D0 EDX=00000000
ESI=06F60188 EDI=06F60198 EBP=0022F724 ESP=0022F504

Yes, that happens to me too. Investigating..

it does not reproduce here with the latest svn (7930), I've just started c64 and ibmpc5160 with newui and no crash.

the problem you experienced might have been related to the crash I've just fixed in my last commit: MESS was failing software list validation if any xml was missing in the hash path.

Yes, newui is working now, thank you

I tested one step at a time and found that r7914 caused the problem for me. I have reverted it.

fwiw, 7914 gave no problem here (win xp 32bit)

That is what I use, but it was very unstable, sometimes would work, the next time instant crash. Seemed like memory issues all over again with the random behavior. I tested with Super80, but I'd expect trouble with any system that had the choice of Mount, Create, Unmount in the device menu.

The patch in question was a partial (apparently incomplete? It's hard to tell) fix for the mess of osd_free vs global_free vs mame_free vs free functions used in newui and wimgtool. I think Firewave can't actually truly fix it without messing with some SDL OSD code which R. Belmont has a lock on, due to some problems with dependencies.
R. Belmont: maybe talk to firewave and see if you can figure out what exactly needs fixing? It sounded bad on IRC.

LN