NVRAMCallback: reporting writes vs diff

[francisdb]

I was working on a vpinball script to log NVRAM updates for https://github.com/tomlogic/pinmame-nvram-maps.

Unfortunately the NVRAMCallback is periodicaly doing a diff and reporting the changes. If a score is updated from 10.000 to 11.000 only the change of one digit is reported. I'm pretty sure the actual write is writing the whole assigned range.

Would there be a way to have it report actual NVRAM writes?

An other option would be a compiler flag that makes PinMAME write these changes to some file / stdout. Preferably with the option to filter out ranges as these updates can be very frequent.

[toxieainc]

I think the latter may be easier to handle on both ends? Will check..

[francisdb]

I think the latter may be easier to handle on both ends? Will check..

I'm having a hard time navigating the code to find the spot where nvram is actually written to. (nvram address + length + actual bytes)

[toxieainc]

From my understanding (its been >5 years i last fiddled with NVRAM stuff though, so maybe also wrong info) there is no special handling, its just a memory space like all the others, so in the standard read/write mem routines one would have to capture all the nvram ranges for each machine type. :/

[mjrgh]

From my understanding (its been >5 years i last fiddled with NVRAM stuff though, so maybe also wrong info) there is no special handling, its just a memory space like all the others, so in the standard read/write mem routines one would have to capture all the nvram ranges for each machine type. :/

That's consistent with my understanding of the code. At the CPU emulation level, there is no such thing as NVRAM, just RAM. That's because it was just ordinary RAM in the original hardware; the thing that made it non-volatile in the original hardware was that ALL of RAM was non-volatile, thanks to a set of AA batteries that kept the SRAM powered even when the (rest of the) machine was powered off. The thing that makes it non-volatile in PinMame is that PinMame copies a section of ordinary RAM to and from disk at session startup and shutdown. The section copied is just an address range that was empirically determined according to the range that the ROM software DOESN'T clear during its power-on self tests; everything not cleared during POST is treated as non-volatile because it was de facto non-volatile in the original hardware (due to the AA battery backup), whether or not the software actually needed it to be preserved across power cycles. I suspect that the ROM software only needs a small subset of the space to be actually non-volatile, since it writes into a lot of locations throughout the space essentially continuously, making me think a lot of it is just scratch variables. My point being that if someone wants to add a callback on every write into an NVRAM region, it would be a good idea to make sure it's lightweight, since it'll get called a lot.