Hi lithy,
thanks for sharing the updated code — it is great to see that the information from our reverse-engineering work was useful. Your new reset hook also matches what we observed very closely:
Code:
move.b $300000.l,D0
btst #$5,D0
bne .continue
bclr #$7,($b35,A5)
move.w #$0,$2c0fee.l
.continue:
jmp $c11002.l
Clearing
before switching GSEL back to 0 is the important part. We found that this bit survives the warm-reset preparation and is used by UniBIOS as PICK'N'MIX resume state. So simply writing GSEL 0 is not sufficient — UniBIOS can otherwise see the preserved PNM state and resume that path instead of returning cleanly to the VTX menu.
One other thing we looked into was your comment about changing ROM offset
from:
We decoded zardam's current
Code:
uni-bios_4_0_BackToMenu.bps
, and that change definitely originates there. What is particularly interesting is the history of the patch:
- the older zardam patch explicitly NOPs the BIOS integrity/checksum test around
;
- the newer BackToMenu BPS leaves that integrity-check code untouched;
- instead, it changes the word at ROM offset
from
to
.
So our strong suspicion is that
is being used as a checksum/integrity fix-up word in the newer patch, allowing the original UniBIOS integrity test to remain intact.
We have not yet reconstructed the exact checksum arithmetic around
, so I would not call that completely proven yet. But the patch history is a pretty strong indication of what
is doing.
There is one potentially important consequence for your modified BIOS:
may be specific to zardam's exact BackToMenu binary. Since you have now added additional code, the mathematically correct fix-up value for your build could in principle be different. If we get a copy of your resulting BIOS/BPS at some point, we can disassemble the integrity routine and calculate the correct value instead of relying on
by inheritance.
On our side the VTX project has also moved quite a bit further. We already have a completely new menu intended to replace the old one. Besides the rewritten menu logic it now supports things such as:
- game artwork,
- sprite graphics,
- audio,
- integrated Soft-DIP management.
We also have a generator now which uses a new CSV database together with the
produced for
. From that common data source we can generate/control the game ordering and metadata for all three sides:
Code:
new VTX menu
PICK'N'MIX
Attract Mode
So the intention is that the menu, PNM and attract rotation no longer evolve as three independent game lists — they can all be derived from the same source data.
There was one additional complication caused by the new menu: because it now has its own sprites and audio resources, the original
behaviour for
was no longer sufficient for our layout. We therefore had to patch
for the
generation path as well.
At the moment we are also modelling the stock 161-in-1/PICK'N'MIX behaviour in MAME in quite some detail. Among other things we now have the original selector semantics, the stock helper/MCU behaviour, PNM manual launch/reload and attract switching running against the VTX mapping. That work is actually what exposed the
reset behaviour in the first place.
So your BIOS work and our MAME/menu work are starting to meet in some very useful places.