[Available] Modified PICKnMIX for leonk's Vortex carts

lithy

Enthusiast
Joined
Nov 8, 2024
Messages
119
Reaction score
216
Location
Pittsburgh, PA
Patch files for a modified bios are available at the GitHub fork here. I consider this to be reasonably well tested but would appreciate any bug reports or feedback from anyone using the files.

https://github.com/lithyV/ub_vortex_multicart_leonk


ORIGINAL POST BELOW:

I put it in the generic Vortex thread, but so I don't derail that further, here is a WIP/discussion thread.

Goal: A modified version of Unibios 4.0's PICKnMIX feature that will cycle attract mode from a Vortex All-In-One cart with the game list that leonk uses (I hope present tense is still appropriate! It did take me over a year and half to start on this project.)

First, credits to Razoola for The Universe Bios 4.0 and the PICKnMIX feature. I only barely know enough to modify, not build something like this from scratch.
Also credits to zardam and kuze who built versions of this for different game lists. Especially kuze who provided source documentation that was easy to follow and understand for a novice.

Their work is available here if that game list is what is on your Vortex cart:
https://github.com/zardam/ub_vortex_multicart
https://github.com/kuzearcade/ub_vortex_multicart

Per discussion from the other thread, here is the current splash screen.
iaminvincible.png


Lots of jabbering about the finer details below:

The next goal was the clean up the naming and find space for them all. In the end I found space for every game except The Eye of Typhoon and XenoCrisis. I could maybe find a little more space to include them, but honestly, I didn't want those two games in the attract loop anyway so in they end they won't be accessible from the PICKnMIX menu either. Sorry, but I'm building this for myself first and foremost, so it will match my wants first.

Some names in the original Universe Bios are a bit of a mishmash. In the end, I put everything to its US region title and cleaned up a few spelling/punctuation/formatting issues. The priority was that the title was neat and tidy in the PICKnMIX menu. This involved duplicating some names because I needed more space than just stealing the title used on the cheat menu. The cheat menu title may retain some small errors that I fixed for the PICKnMIX menu because I did not want to mess with how the bios loaded cheats.

For alphabetization, I kept any leading 'THE' but alphabetized without it. Within a series, chronology takes priority over alphabetical order. This affects the Baseball Stars, Fatal Fury, King of Fighters, Metal Slug, Real Bout, and Samurai Shodown series when compared to previous versions of PICKnMIX. With regard to both previous points, Super Sidekicks - The Ultimate 11 was a major problem child. Other versions called it Super Sidekicks 4 which is something of a fan creation. I tried Super Sidekicks-Ultimate 11 but that is 1 character too long (max 26) and with limited space anyway, I used the default "The Ultimate 11" that is already in the Unibios code and thus it is separated off from the series.

I also prioritized 'QUIZ' and 'MAHJONG' in titles so that the Japanese heavy games will appear grouped together. This has the added bonus of grouping Quest of Jongmaster with the Quiz games and Master of Syougi with the Mahjong games in an alphabetized list. The Japanese titles obviously have some creative translation or transliteration to accommodate a meaningful title with the limited space. Alphabetization in general is tricky, I think you could ask several people about where a small handful of games belong in the list and get different answers. None are necessarily wrong, this version of the list is just what feels most right to me, open to hearing any feedback though.

Besides Xenocrisis and Eye of Typhoon, 240P Test Suite is also obviously excluded from the attract loop and game list, you'll have to use a stock bios to access those three titles. Metal Slug 2 Turbo, the AES version of Magician Lord and Revision A of Shock Troopers are excluded from the attract loop but can be selected in the game list. King of the Monsters is conditionally removed from the attract list when Hard Dip Switch #7 (Free Play) is ON. This is because when in free play King of the Monsters gets 'stuck' on the Game Compulsion screen and doesn't cycle out of its own attract mode.

Currently, I think I have finished the kind of testing that I can do/show just from MAME. My eprom programmer is supposed to arrive Wednesday and once I figure out how to use it, I can program a chip and test with the actual cart and then address any issues that I find from that point. Then once I'm comfortable that it is working, I can post the file for others who might be interested. Here is a video flipping through the game list with the titles all displayed.

View: https://youtu.be/l2pBRO0xLSs

If there are any questions or suggestions in the meantime, feel free to post them here.
 
Last edited:
I like how the game list doesn't cause the background to artifact like it often does using the 161 cart and vanilla unibios. Looks a lot more polished
 
https://x.com/leonkiriliuk/status/2092439365662150707

Thanks @leonk for doing some testing while I wait on my programmer (hey at least the delivery date looks accurate, it made it into town tonight!).

Hopefully addressed a small goof on what I sent over that was making the random game selection after a natural attract loop ended not work. Silly mistake, had it working and then broke it while undoing something else that wasn't even necessary in the first place!
 
That’s an impressive job, man! The amount of work involved to bring this working is quite large. 👍
 
Can I please ask - does this bios still have the return to list function (holding b during soft reboot)? That way you still have access xenu crisis without a hard cab restart.

Leon suggested something similar as a way to access the 240P Test Suite (and The Eye of Typhoon, and Xenocrisis). It's a good idea, looking into it and I'll see what I can figure out.
 
The fact that we still have developers that can code for 68000 in ASM with nothing more than a hex editor and debugger is astonishing!
 
Got my programmer and got a bios burned. Everything is up and running on my cab. I have a list of checks I want to go through and so far I did find one issue. When Riding Hero is the selected game, I get an addressing exception error after opening the PnM menu and letting it close or browsing game titles. I've been able to recreate it in MAME. So, something to work on.
 
Found that this crash also happens with the other hacked PickNMix by zardam and kuze but when exiting the menu on a new game it produces a reset crash instead of an exception error. Scrolling too far around the menu still produces exception errors.

It seems like maybe the game is picking up some part of the modified bios code that it expects something else to be there and then it corrupts the addressing, but I haven't been able to entirely decipher what's going on yet.

This could be an issue on the standard 4.0 but since Riding Hero is not on the 161 carts, it wouldn't have come up.

Edit: It seems to be an issue with the stack pointer...

Edit #2: I think this might be a bug in the original game code... At $870 in the P1 rom it loads address $104FFC to the User Stack Pointer which doesn't make sense since the stack pointer is in the $10F300 region. If I change it to load address $10F4FC instead, it doesn't crash leaving the PnM menu or when scrolling around the game titles. Now I just need to see if this is something I can fix on the bios side...
 
Last edited:
I made a mame version dedicated to the vtx cart with custom driver derived from the cpld part. It's great for debugging and development. A new menu v2 with artworks is pretty much ready.
I already made pnm work with custom gamelists and paired it with a new generator script for auto-patching the ub4.0
I have the vtx-mame in my gitHub and give u access if needed.
the big vtx roms are lazy-loaded so the Performance is good.
 
Had to step away from this for a few days, got a little stuck for a night and then kid activities used up the whole weekend.

But I think I resolved the Riding Hero bug. I'll have to get home, reburn the rom and retest the entire menu with each game. But it is not crashing at least with Riding Hero in MAME like before.

Riding Hero was using a range around $104FFC for loading things into RAM. When PnM wants to load the menu into RAM it is using $104000 and the entire menu takes up a decent amount of space so a portion overlapped right around the three SamSho5 titles which was corrupting the data and causing the crashes. As mentioned before, it seems like most or all other games are using something around $10F300 instead since its mentioned on the dev wiki it must be kinda standard? Hopefully some other random game isn't using the $106000-$107500 range...

So it maybe can't be considered a 'bug' in Riding Hero but if its the only one using a different range that UniBios thought was open, that was the issue.

So anyway, I took the bios instructions at $A25A which loads $104000 and made that $106000 and the instruction at $A46A which loads $1040A0 and made that $1060A0.

There are two other instructions that point toward $104000, I haven't been able to trigger them in the debugger to know what they're for yet, I could update them to $106000 or just leave them alone and hope whatever it is using it for doesn't go far enough to interfere with Riding Hero at $104FFC. For now, I'm leaving it alone to introduce as few changes as possible.
 
I'm more than happy to burn a rom - I have a mv1c, mv4f and mv4ft boards I could test it on.

Thanks, I'm hoping to put the file up this weekend as a beta I guess for others to start testing, just want to make sure I've got most of the possible issues checked myself first.

The Riding Hero issue is fixed with the last change and doesn't seem to have affected any other titles.

I found I understood one of the values slightly wrong so it was crashing eventually if left on attract mode. Theoretically it should just run forever. Returned the overflow value to 9E as it was in kuze's hack and seems to be fixed. Going to let it run for 24 hours to confirm.

I reverted excluding Slug 2 Turbo, Magician Lord AES, and Shock Troopers ver. A. The setup was to just advance to the next title which meant Slug X, Mag Lord MVS, and Shock Troopers ver. B. I figured that there really wasn't a good reason to exclude them.

So the only excluded title from PnM for attract mode is King of the Monsters and that's only if free play is on.

I think that's everything done for the basics on PnM. I still need to see if there is a good option to boot to the cart's menu to make 240P, TEOT, and Xenocrisis accessible.
 
You made PnM as the default, which is opposite of how stock UNIBIOS works with regular 161-in-1 carts (161-in-1 menu boots, unless you hold button during power on and PnM is enabled) Is reverting back to that behaviour an option? or reversing it? (PnM on by default unless button is held) Should be similar code to what was there before.
 
You made PnM as the default, which is opposite of how stock UNIBIOS works with regular 161-in-1 carts (161-in-1 menu boots, unless you hold button during power on and PnM is enabled) Is reverting back to that behaviour an option? or reversing it? (PnM on by default unless button is held) Should be similar code to what was there before.

With the qualifier that the auto-boot into PnM was already done for me, yeah I can do a couple different things with it either revert the auto-boot entirely or reverse the behavior so that holding start boots normally which will send to the vortex menu.

I've tested both out in Mame and can get PnM disabled but can't really test beyond that until I remake the bios to use with the actual cart, and that will wait until the 24 hour test is over (about 1/3 done so far).
 
I've been doing some parallel tracing of UniBIOS 4.0 with the VTX cart in MAME, and we found a few things that might be useful to you, especially for the "boot back to the cart menu" part.
The biggest finding is that `$10FE35.bit7` is not just a harmless "PnM enabled" flag. It directly changes the next UniBIOS boot path.
On a warm reset UniBIOS does:
Code:
C1BDC0: lea     $10FE35.l,A1
C1BDC6: andi.b  #$DC,(A1)
...
C1BDEC: jmp     $C04400.l
`$DC` preserves bit 7.
Then the next boot reaches:
Code:
C04458: btst    #7,$10FE35
C0445E: bne     $C044CE
If bit 7 is still set, it enters the PnM resume path. That eventually does:
Code:
C04506: moveq   #1,D0
C04508: bsr     $C04516
C04516: bra     $C0441C
and on our VTX mapper this ends up at the GSEL write:
Code:
E00048: move.w  D0,$2C0FEE
So simply doing:
Code:
GSEL = 0
RESET
is not enough when PnM was previously active. UniBIOS sees bit 7 again during the warm boot and PnM can immediately remap a game over the cart menu.
What we have tested successfully is:
Code:
; only in the VTX + B-button "back to menu" reset path
bclr    #7,$0B35(A5)          ; $10FE35
move.w  #$0000,$002C0FEE.L    ; GSEL 0 = cart menu
jmp     $00C11002.L
With that we verified all three cases:
Code:
PnM -> game -> normal soft reset
    = same game
PnM -> game -> soft reset + B
    = VTX cart menu
full restart -> hold START
    = PnM works normally again
So if your goal is simply "exit PnM and boot the cart's own menu", clearing bit 7 only in that specific return-to-menu path seems to be a clean solution. We initially tried manipulating bit 7 more globally and that oke cold boot/PnM behavior, so the gating is important.

One warning if you want PnM to remain logically active after returning to the cart menu:
Re-setting `$10FE35.bit7` while the menu is running, or immediately before the menu launches another game, is too early. We traced that case too. The following BIOS boot sees bit 7 and re-enters the PnM mapper th, which can overwrite the GSEL chosen by the cart menu.
A clean non-PnM game handoff reaches:
Code:
C046CE: btst    #7,$10FE35
C046D6: beq     $C04862
C04862: jmp     $122.w
`$C04862` therefore looks like a possible very-late place for a one-shot PnM re-arm, but we have NOT finished or proven that part yet. It would need a one-shot condition so normal game boots are untouched.
Another useful detail: PnM mapper activity happens several times during the PnM state machine, not just at the final game launch. In traces we see the mapper path repeatedly going through the PnM logic. So I would oid treating the mapper write as a single "launch event".
On the list/attract overflow: in our VTX build I changed all count-dependent PnM logic to use a generated `PNM_COUNT` instead of fixed values. The UniBIOS code has several separate count-dependent operations: nderer wrap, +/-1, +/-4, clamp/wrap, previous/next index etc.
So I think `$9E` should be treated as "the count for that specific list", not as a magic UniBIOS constant. `$9E = 158`, so if your active PnM list really contains 158 entries, then going back to `$9E` is exactly ght. If the list size ever changes again because of filtering, it may be safer to derive that value from the actual descriptor count rather than keep it hard-coded. Our generator now does exactly that.

Your Riding Hero fix is also very interesting. We independently reproduced a symptom consistent with it:
Code:
Riding Hero launched through PnM        OK
next game selected through PnM          crash
attract mode after Riding Hero          OK
That does not independently prove the `$104000/$104FFC` overlap, but it makes your explanation very plausible.
We also noticed two other references related to the `$104000` area around `$C04EC4` / `$C04EEA`, but we did not prove that they execute in the Riding Hero scenario. So your approach of only changing the two known tive references first is probably the safer one.

We also learned something about PnM Soft-DIPs that may be useful if you run into that later.
The original UniBIOS load path around `$C04572` is:
Code:
C04572: bsr     $C04530
C04574: jsr     $FF146.l
C0457A: jsr     $FF390.l
C04580: cmpi.b  #$AA,$108140.l
C04588: bne     $C04574
C0458A: jsr     $FF246.l
C04590: lea     $108120,A0
C04596: lea     $10FE40,A1
C0459C: lea     $10FD84,A2
C045A2: moveq   #3,D0
C045A4: move.l  (A0),(A1)+
C045A6: move.l  (A0)+,(A2)+
C045A8: dbra    D0,$C045A4
So `$108120` is a 16-byte PnM Soft-DIP state block which UniBIOS copies into both `$10FE40` and `$10FD84`.
There is also a native UniBIOS routine at `$C11612` which loads the currently mapped game's default Soft-DIP block into `$10FD84`.
The important lesson from our stock-161 experiments is that `$FF146/$FF390/$FF246/$FF0B2` appear to be parts of one cartridge transaction/state machine. Emulating or bypassing just one helper at a time created sleading intermediate states. A coherent replacement of the whole hardware-specific transaction works much better.

One last VTX-specific detail in case it helps with your tables:
Code:
stored PnM selector = final VTX GSEL - 1
because the UniBIOS mapper path adds 1 before the actual mapper write.
For example:
Code:
stored selector $7A
-> UniBIOS adds 1
-> $2C0FEE gets $7B
-> VTX GSEL $7B
We verified that directly with mapper watchpoints.
If useful, I can also send you the exact trace windows around `$C04458/$C044CE` and the Soft-Reset+B path.
 
Last edited:
Great info, should make implementing something pretty easy.

I finished the 24 hour test with no issues. I checked every title with two loops around the menu and no other issues like Riding Hero.

The only new thing to note is that the Unibios in-game menu is corrupted on Zintrick but upon going back to using a standard Unibios 4.0, the behavior is the same. Not knowing anything about this hack, I'm not sure if this would be fixable, in MAME testing pierpa's newer conversions don't have the same issue. The menu still functions, the text and border are corrupted though.
 
Back
Top