Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Certain instances of PeekByte() before controller initialization causes crashes (e.g. rebooting some cores with the hex editor open) #1168
With various cores, it appears that the controllers aren't initialized before the core load is complete. This means if you use PeekByte() on an address that results in a read to the IController object before the controller has been initialized, a crash occurs.
The easiest place to demonstrate this is with the TIA in 2600Hawk. Open the hex editor, swap to TIA, and reload the core. It should crash every time.
Another place where the same issue exists is in PCEHawk. Open the hex editor, go into the System Bus (21 bit), scroll down all the way to somewhere around 0x1FF332, reboot the core, same crash occurs.
This issue seems isolated to certain cores. I'm unsure if this affects other cores, but the root cause seems to be that the controller object doesn't exist at the time of the PeekByte()
Example crash log
Occurs in the latest dev build
The controller is initialized in EmuHawk but not in the core. Currently the only access the core has to the controller is through FrameAdvance.
Some cores that don't crash have indirect variables that can return a default value before a FrameAdvance call updates them. A7800 is an example.
NESHawk avoids the problem by not reading the controller during peek. It makes sense here because reading controllers in NES updates the state.
Ported cores don't have an independent instance of the controller at all since they don't need it.
So yeah, this is really inconsistent. Cores aren't required to have an independent instance of IController around, but currently most in house cores do. Probably they shouldn't? I'll think about it.
EDIT: looks like the easiest thing to do is to just initialize all such instances with a null controller.