What's new
Just a note on the WeAct boards as well. They have an official store on Ali (linked by ack above) but there are a lot of resellers with a significant price difference between them and the official store

In AUD for example the official store is around $30AUD with shipping. A reseller is around $90AUD
 
1. WeAct board and thee pcb’s (gerbers are on the git). Nothing else. Each pcb required 2 2x22 2.54mm pin headers and 2-3 0.1u caps.
2. vtxcrt tool generates all necessary dumps for the programmer, and verilog include files for cpld. Flash programming and verifying is carried out by STM32. sources and binaries are available.
3. You decide what to include to the cart by editing games.txt file. Vtxcart do checks automatically and will inform you if something goes wrong (for example, if there is no space left)
4. To program the cpld’s you will need a Quartus 13 and a USB blaster.

As I dont know if you want to provide a documentation, I will just follow up with my questions :saint:

Regarding the STM32 part:
The physical part is clear to me now - we need the three "adapter pcbs" to connect the STM32 board to the desoldered 161in1 chips.
The "VTXCart.exe" tool generates the data for these chips in the "ROM" subfolder.

1. Do I need to flash your "cart.bin" in the firmware subfolder to STM32H750 programmer? If so, how / by which tool?
I cant really find any documentation by WeActStudio and their github isnt helpful either.

2. Regarding the rom files created by the compiler: are all of those files simply required on the micro sd card or does your firmware require a specific structure?

Regarding the CPLD part:
1. First of all, how do you connect the USB blaster? Simply by using the 10pin cable and the respective connector on both 161in1 pcbs?
2. You mention Quartus as a programming tool: can you be more specific on how to use that tool and with which data? "VTXCart-main\CPLD" seems to contain relevant files .. you mention that files in the subfolder "Verilog" created by the compiler are relevant as well. Do these need to be magically combined somehow?


If anyone else has already figured both parts out .. please share some details :whistling:
 
Regarding the CPLD part:
1. First of all, how do you connect the USB blaster? Simply by using the 10pin cable and the respective connector on both 161in1 pcbs?
2. You mention Quartus as a programming tool: can you be more specific on how to use that tool and with which data? "VTXCart-main\CPLD" seems to contain relevant files .. you mention that files in the subfolder "Verilog" created by the compiler are relevant as well. Do these need to be magically combined somehow?


If anyone else has already figured both parts out .. please share some details :whistling:

open the excel file, choose the CPLD tab, scroll down to JTAG pinout ;)
not sure how to use Quartus 13 with the usb blaster though, last time I used Quartus it was to compile a core for MiSTerFPGA
 
1. Do I need to flash your "cart.bin" in the firmware subfolder to STM32H750 programmer? If so, how / by which tool?
I cant really find any documentation by WeActStudio and their github isnt helpful either.
You want to grab the zip file from here

https://github.com/WeActStudio/MiniSTM32H7xx/tree/master/Soft

Hold down the B0 button on the STM board and plug it into your computer. This will put the STM board into programming mode. The first time you do this you will likely need to install drivers for it. To install the driver run the included "DFU_Driver/STM32Bootloader.Bat" as administrator. You might need to re-plugin after installing the driver, I dont recall. Copy the cart.bin to the same dir you decompressed the zip to. Run "WeAct Studio USB Download Tool. Bat", it will prompt you for a filename, type in cart.bin. This will program the STM board. Once its done you should see the firmware running on the STM board's screen "P-ROM VTX V1".

The right most button on the STM board is the only button used for navigation in the firmware. A single short press will go to the next menu item, a 2 second press will pick the current item. The top level menu lets you pick the rom type (P, S, M, V, C). Once you select a rom type, you can choose from between TEST, DUMP, PROG, VERI.

The TEST command will try to read the flash chip's ID. I've documented what I have gotten on them all here along with the crcs of the original flash contents, but they need to be verified they are correct.

The DUMP command will dump the contents of the flash to xrom.bin, where x is p, s, m, v or c depending on which flash type you picked. ie P-ROM DUMP will write to prom.bin file.

The PROG command will write xrom to the flash, where x is p, s, m, v or c depending on which flash type you picked. ie P-ROM PROG will write prom to the flash. Note that dump and prog use different files (prom.bin vs prom)

The VERI command will verify the flash against the xrom file, where x is p, s, m, v or c depending on which flash type you picked. ie P-ROM VERI will compare the flash with the prom file.

The sdcard should be formatted FAT. I've been using a 16G sandisk.

2. Regarding the rom files created by the compiler: are all of those files simply required on the micro sd card or does your firmware require a specific structure?

The compiler will create the following rom files under the ROM folder

Code:
crom-1
crom-2
mrom
prom-1
prom-2
prom-3
srom
vrom

These are the roms that need to be written to the flash chips. You will notice crom/prom's filenames don't match up with the expected filenames the PROG command is wanting. So you will need to

  • install c1 flash chip in STM board
  • copy crom-1 to the sdcard
  • rename crom-1 to crom on the sdcard
  • program the flash (and verify)
  • install c2 flash chip in STM board
  • copy crom-2 to the sdcard
  • rename crom-2 to crom on the sdcard
  • program flash (and verify)
And the same type of thing for the proms

The compiler will also create the following verilog include files in the Verilog folder

Code:
ix_c.inc
ix_p.inc
ix_v.inc

Code:
ix_c.inc needs to be copied to CPLD/XXX/CHA_CP1/rtl/ directory
ix_p.inc needs to be copied to CPLD/XXX/PROG_CP1/rtl/ directory
ix_v.inc needs top be copied to CPLD/XXX/PROG_PCM2/rtl/ directory

Where XXX is either AES or MVS depending on your 161in1 cart.


Regarding the CPLD part:
1. First of all, how do you connect the USB blaster? Simply by using the 10pin cable and the respective connector on both 161in1 pcbs?
2. You mention Quartus as a programming tool: can you be more specific on how to use that tool and with which data? "VTXCart-main\CPLD" seems to contain relevant files .. you mention that files in the subfolder "Verilog" created by the compiler are relevant as well. Do these need to be magically combined somehow?

The pinout of the jtag connector on the 161in1 boards is

pin 1 = VCC (3.3V)
pin 2 = GND
pin 3 = TCK
pin 4 = TDO
pin 5 = TDI
pin 6 = TMS

You would need to wire up the jtag connector to the usb blaster based on that. I didn't program my CPLDs with a usb blaster so someone else will need to help with that.

Each CPLD has its own Quartus project. So in Quartus do open project goto the synth directory of a given CPLD and open the project file. Pressing the Compile/Play button will compile the verilog code (this will only work if you copied over the ix_X.inc file from above). Once you have it compiled you would then need to program it to the the corresponding CPLD.

Just to note I'm still working my way through getting a cart fully working. I've got the P, S, M, V flashs all good, but the C flashes are being a pita because of the shitty daughter boards they use. They are super thin and fragile.
 
@Vortex hoping you might have some insight. I'm working on a MVS 161in1 with the DIP style C rom daughter boards. I'm not having any luck getting the C rom working correctly. I've had no problems with all the other flash'd roms, but something is off with the C roms. I've tried multiple different daughter boards against 2 different CHA boards on a couple different MVS motherboards and they all do the same thing. This picture from the start if winner stakes 2 shows whats going on the best.

IMG_1044.jpg


This is what its suppose to looks like

Screenshot 2023-09-13 at 8.15.30 PM.png



It looks like all the data for the sprite is there, but just seems to be drawing individual rows of pixels are on the wrong lines. This makes me think C_ADDR[3:0] or PBUS[19:16] lines are somehow in the wrong order since these seem to deal with pixel row number. I've looked over the verilog and traced out those lines between the cart edge, cpld and flash chip and seeing any issues there.
 
hrm I did a quick test by reversing the order of C_ADDR[3:0] in the verilog and its working now.

IMG_1045.jpg


I did this, but the real fix must be some place else.

Code:
// orig wire [23:0] C_ADDR_1 = {C_LATCH_U[2:0] & MASK[5:3], C_LATCH[19:17] & MASK[2:0], C_LATCH[16:4], CA4, C_LATCH[3:0]};
        wire [23:0] C_ADDR_1 = {C_LATCH_U[2:0] & MASK[5:3], C_LATCH[19:17] & MASK[2:0], C_LATCH[16:4], CA4, C_LATCH[0], C_LATCH[1], C_LATCH[2], C_LATCH[3]};
 
Yep. Just swap it in the qsf file:

set_location_assignment PIN_118 -to C_ADDR[0]
set_location_assignment PIN_119 -to C_ADDR[1]
set_location_assignment PIN_120 -to C_ADDR[2]
set_location_assignment PIN_121 -to C_ADDR[3]

to

set_location_assignment PIN_118 -to C_ADDR[3]
set_location_assignment PIN_119 -to C_ADDR[2]
set_location_assignment PIN_120 -to C_ADDR[1]
set_location_assignment PIN_121 -to C_ADDR[0]

This happened because in the AES version of the cartridge these pins are swapped and strictly tied to the logic and I had to add the scrambling procedure into the STM 32 programmer.
 
This is absolutely awesome. I really do hope the Chinese start pumping these out.
 
I always wondered if the hacks shared roms with the originals, and now that it's confirmed the original game selection makes more sense. Thank you for confirming it with your hard work.

Since we can't fit everything on one of these carts, there's no one game selection that will ever please everyone, save for those willing to have two carts.
 
Curious - will anyone here be offering this as a service?

Its pretty clear ol' DD wont be able to do this. Ive got two nanner carts that Id love to have 'fixed.'

edit: make that 3 carts. 'cept one is blue.
 
Last edited:
Curious - will anyone here be offering this as a service?

Its pretty clear ol' DD wont be able to do this. Ive got two nanner carts that Id love to have 'fixed.'

edit: make that 3 carts. 'cept one is blue.

I wouldn’t think so. These games are still being sold and licensed. Loading games onto these carts where the potential buyer does not own the original cart is not legal
 
Vortex, if a new daughter board was designed, that has all the flash lines branched off to say a high density connector, would it be possible to reflash the chips in circuit? Maybe some jumpers could be used to interrupt continuity from the other chips if needed. What do you think?
 
I don't think there's much point in developing a new daughterboard. The cartridge uses three different flash memory modules. To make a daughter board for each module... well, I don’t know... I think it’s easier to make a new cartridge board for these modules.

Several ways are possible:

1) The Chinese will release a new multi-game flash cartridge. If they release a cartridge with THREE stilted chips for C-ROM, then I think that the entire collection will fit on one cartridge. I think the increase in price will be small. Something like 25%.

When I started, I tried to reach out to the real developers of these multi-cartridges from China. Unfortunately, this was not successful. And so far no one has contacted me either.

2) Develop new motherboards for existing chips, on which to provide either connectors for the programmer or the programmer itself on STM32, thereby creating a cheaper alternative to existing SD cartridges. But the price here will no longer be +25%.
 
I wouldn’t think so. These games are still being sold and licensed. Loading games onto these carts where the potential buyer does not own the original cart is not legal
I dunno man. I get not putting NeoDev games or things like that on the carts since they are fairly recent.

But getting a cart with the KOF/Garou/LastBlade/SamSho series on them isn't hurting SNK or the Neo. Then another cart can be platformers/slugs etc.

I don't see an issue there, especially considering we have NeoSD/Darksoft and other multis here.
 
Back
Top