Thanks for checking!
Metro VG420 Multi interest and development thread?
- Thread starter twistedsymphony
- Start date
AlxUnderBase
Enlightened
These are the files E2 & E3 from the Lady Killer VG460-(B) . Let me know if is something need to check
Good news on the VG420 front: Yesterday I got in the last of the parts ordered for the kits, and I also finally worked out minimization of the custom PLD logic so I can ship every kit with the same chip rather than needing a custom chip for each donor.
I'll be building a setup to test out the new PCB design today.
I did realize I'll need to buy some boxes an appropriate size to ship these out in but if all goes well on the test build I can start shipping these out this week!
I'll be building a setup to test out the new PCB design today.
I did realize I'll need to buy some boxes an appropriate size to ship these out in but if all goes well on the test build I can start shipping these out this week!
Unfortunately I'm not having great luck with the new PCBs and new PLD logic. The original multi design had a small bug in the circuit, which I did fix, but it also had some stability issues with certain donor boards which I was hoping I would fix with handling the program ROMs a bit differently, sadly it seems that the change I made has made those stability issues worse instead of better 
the updated PLD logic, while able to support all donors in a single chip is also contributing to the stability issues as well.
I have some experimentation to do to see what I can do to resolve this. if that doesn't work out I do have an idea for a completely different multi design scrapping the design of the core multi functionality for something different.
the updated PLD logic, while able to support all donors in a single chip is also contributing to the stability issues as well. I have some experimentation to do to see what I can do to resolve this. if that doesn't work out I do have an idea for a completely different multi design scrapping the design of the core multi functionality for something different.
Go @twistedsymphony Go.
We're sure you'll fix it. PM if you want and I'll try to help.
We're sure you'll fix it. PM if you want and I'll try to help.
So here's the situation.
the core design of this multi is an idea I've had for ages (not for metro specifically but for ANY multi) that puts some custom logic between the CPU and the rest of the PCB such that I can take in the high-level addressing and apply logic to reconfigure the addressing in real-time so that you can support games with different address maps without modifying any game code.
So for instance if Game A is a Donor and expects RAM is at address 0xF00000 and Game B is the target and expects RAM at address 0x400000 then my custom logic will read 0x400000 and translate it to 0xF00000 before sending that along to the rest of the PCB. Traditionally this kind of conversion would require you modify thousands of lines of code in the game program and even then you'd likely worry constantly that you missed some, so by remapping in real time you can use the original game code and don't have to re-wire the PCB either.
For the most part this works, and works well! Certainly I wouldn't have got as far into this as I have if my early test along the way didn't prove this out. However I've found that it really needs to be done FAST; you need to translate fast enough that the PCB can keep up with the CPU, otherwise the games can suffer from crashes/reboots (hence the stability issues I mentioned). The added complexity in the logic of supporting multiple donors in the same PLD seems to slow it down enough that issues crop back up. PangPom's gets to the title screen then reboots, most other games get further but can sometimes randomly reboot. Rolling back to my older, more simplified remapping logic that is unique for each donor seems to solve the issue though. I haven't done any long tests but most of the other games seem to boot and go through attract mode just fine.
Certainly the older version of the multi seems to work fine, I've got multiple hours of play on it without any reboot issues, and Ekors has and tested one and hasn't reported any issues.
There is one other issue with the NEW PCB design though and that is the Korean version of Toride mysteriously wont boot, it displays the RAM check screen then crashes, even with the older simplified logic. it works perfectly on the older PCB design but not the new one and I have yet to figure out why. The game code is 99.9% identical to other regions so I'm hoping it's just some stupid mistake in how I've loaded the ROMs.
the core design of this multi is an idea I've had for ages (not for metro specifically but for ANY multi) that puts some custom logic between the CPU and the rest of the PCB such that I can take in the high-level addressing and apply logic to reconfigure the addressing in real-time so that you can support games with different address maps without modifying any game code.
So for instance if Game A is a Donor and expects RAM is at address 0xF00000 and Game B is the target and expects RAM at address 0x400000 then my custom logic will read 0x400000 and translate it to 0xF00000 before sending that along to the rest of the PCB. Traditionally this kind of conversion would require you modify thousands of lines of code in the game program and even then you'd likely worry constantly that you missed some, so by remapping in real time you can use the original game code and don't have to re-wire the PCB either.
For the most part this works, and works well! Certainly I wouldn't have got as far into this as I have if my early test along the way didn't prove this out. However I've found that it really needs to be done FAST; you need to translate fast enough that the PCB can keep up with the CPU, otherwise the games can suffer from crashes/reboots (hence the stability issues I mentioned). The added complexity in the logic of supporting multiple donors in the same PLD seems to slow it down enough that issues crop back up. PangPom's gets to the title screen then reboots, most other games get further but can sometimes randomly reboot. Rolling back to my older, more simplified remapping logic that is unique for each donor seems to solve the issue though. I haven't done any long tests but most of the other games seem to boot and go through attract mode just fine.
Certainly the older version of the multi seems to work fine, I've got multiple hours of play on it without any reboot issues, and Ekors has and tested one and hasn't reported any issues.
There is one other issue with the NEW PCB design though and that is the Korean version of Toride mysteriously wont boot, it displays the RAM check screen then crashes, even with the older simplified logic. it works perfectly on the older PCB design but not the new one and I have yet to figure out why. The game code is 99.9% identical to other regions so I'm hoping it's just some stupid mistake in how I've loaded the ROMs.
AlxUnderBase
Enlightened
Lovely puzzle style game ! Thanks to @twistedsymphony , i added another great one in my collection . If will not happen to have multi running on this , no problemo 
Attachments
Mageta the Lion
Professional
Could you switch Roms/Pals/whatever on the Donor to make it a stable Base Version and your custom has less variants to handle? (I have zero idea how much work that would be)
Could you offer different versions for different donors? You already stated you want to use the concept for different Multis anyway (obviously not sure if a more flexible solution also means it is less work intensive to change... simply assuming for now that you can just drop the Memory Map from MAME into your Custom
)
partially, but not completely.
These games use 4 PALs and all 4 are "registered" and have "latching outputs", two things which make them impossible to dump and very difficult to manually reverse engineer. This is actually a big part of why I chose this method to make the multi work because modifying the original PALs isn't really possible, so there's really no other way (at least not until the logic in these PALs is reverse engineered).
With that said I DID actually manage to reverse engineer one of the 4 PLDs and I've hand-crafted replacement logic for that PLD all VG420 and VG460 games. it was a bit of luck though as I realized that the more complicated functions of the PLD logic for this particular PLD wasn't actually being used, the pins that used it weren't connected to anything, which made working out the rest of the logic very straight forward.
only 2 of the 4 PLDs are game specific, and the one I was able to reverse engineer is one of the game specific ones, which means that there's still at least 1 chip that the multi needs and can't be replaced.
--------
Kind of Moot though, turns out the Toride Korea version was just a bad ROM burn, and the stability issue seems to be resolved using my older/simpler logic but will require a unique chip depending on your donor. I still have more testing to do to make sure all games are stable on each donor. but assuming that works out then this will be how I ship it.
I have learned a lot though this though and that has given me some ideas on getting the VG460 version working.
happy to report that after about 3 hours of testing including playing pang poms, sky alert and karate tournament through to completion everything seems to be working and stable 
Here's what the final PCB looks like:
Really impressive work @twistedsymphony , congrats on the final product! Looks like a very nice design and great way of handling different memory maps. 
Thanks for the kind words! It's definitely been a learning experience.
My advice to anyone else attempting this memory map method is to incorporate the Address strobe, I think if I had done that it would solve most of my stability problems, also use a CPLD rather than a simple PAL/GAL as the logic gets complex FAST and I was definitely right on the edge of the speed and complexity that I could get out of a 22V10
I actually have a whole list of multi ideas and 2 others already in the works (3 if you count VG460) but I wanted to start with this hardware as a low-risk way to get my feet wet with the whole design, testing and production process.
My advice to anyone else attempting this memory map method is to incorporate the Address strobe, I think if I had done that it would solve most of my stability problems, also use a CPLD rather than a simple PAL/GAL as the logic gets complex FAST and I was definitely right on the edge of the speed and complexity that I could get out of a 22V10
I actually have a whole list of multi ideas and 2 others already in the works (3 if you count VG460) but I wanted to start with this hardware as a low-risk way to get my feet wet with the whole design, testing and production process.
Last edited:
Anyone in the AU or NZ region have any VG420 or VG460 game that they could lend for some inspection? This is to help with the potential VG460 version of the multi getting developed.
PM me if you're in this area and can help.
PM me if you're in this area and can help.
Here are the tools to build your own roll up pack
as well as instructions for assembling the multi, installing the multi, and using the build tools
Just in time for 4/20 the VG420 multi I think can now be considered officially released. I have these ready to ship for anyone that wants one.
* I will say make sure you have a donor in hand before ordering because I need to send you a kit specific to your donor. Don't worry about me selling out as I'm pretty sure I have way more kits than people who are interested
Last edited:
Not me, I'm afraid! Someone from AU or NZ has any Metro Game that could loan for a few days?
im definitely interested in this, ill start looking for a donor
Anyone?
AlxUnderBase
Enlightened
Apo need it ?