What's new
If the Usb Blaster dont supply the correct voltage, could be connect the vcc/gnd pins to a external power supply, per example a arduino with 3.3 V out? or the boar must be connected to a mvs board (mv-1, etc...), the mvs or aes card could be connect to another power supply (Power adapter) to the cart pins?
I order the FT232H USB, this friday i tested.
You could use some other way to power the board, but using the mvs motherboard is the easiest.
 
You could use some other way to power the board, but using the mvs motherboard is the easiest.
Thanks, could you send a photo for this setup, how it is connected the board to de mvs board, and the programmer, please. So many thanks.
 
Thanks, could you send a photo for this setup, how it is connected the board to de mvs board, and the programmer, please. So many thanks.

IMG_1131.jpg


Nothing fancy going on. Supergun provides power to the MVS motherboard, which is providing power to the 161in1 pcb, which is connected to the computer via the usb blaster.
 
It was the PROG_CP1 CPLD. It only happened with one of the carts I have. openocd would see the device, but programming would always fail.
Well, finally ran into this. 71/72 carts without a problem. OpenOCD will program and fail, or program and then hang on the MSSE flush no response in xxxx time error. Also a PROG_CP1 CPLD. AES. Must have tried 30 times now.

Gonna borrow a USB Blaster again I suppose, since Amazon won't ship your recommended knock-off to me.
 
Would it be possible to interface a logic bank switcher with a 512kb eeprom wired up to the srom to get support for larger s roms? Could something like that work with how the srom is implemented on these 161 carts?

Edit: I think it would be possible after looking up some examples. The only question is could a flex pcb cable be made successfully with connections small enough to interface to the js28f512 tsop package?
 
Last edited:
Finally had time today to make an attempt on a new cart and seems to be going well so far

At least with the dead cart I have spares for the third C-ROM and the M1/S1 in case I lose a leg on one of these
 
Hm, the game files don't include samsh5pf - I have the ROM, do I use the same DS files as samsh5sp or is there another way to do this?
 
You can use this.

https://github.com/aluzed/MiSTer-Neogeo-Rom-Decrypter

Or do it manually because this tool says it's not compatible with the whole neo geo rom library, whatever that means.

https://www.arcade-projects.com/threads/how-to-convert-files-to-work-with-neogeo-multi.24393/

Pay attention to rewrite's post of it not containing all the info on how to properly combine the C roms. You basically have to use the python script on two c rom files at a time. Then combine them all into one big file.

Also look at this to fix an audio issue on fp and 5s in the vrom. Towards the end of that thread, there is a fix for Nightmare in the Dark as well.

https://www.arcade-projects.com/thr...al-perfect-improperly-decrypted-v-roms.18187/
 
Last edited:
I've also just found that my S1 chip is a JS28F256 not a JS28F512

Will this still work or will I need to replace with a 512 (I still have one of these spare)

Also literally none of my chips seem to match the MD5 that ack posted. Not even close. Hardware IDs check out and I'm not getting errors on the dump so I'm not sure what's going on there
 
Last edited:
A24 of the s rom(JS28XXX,) is left floating on the 161 CHA board. This address line is not connected to anything. This mean's the 161 can only address up to 256MB for the s rom, so it's fine.
 
Ok, but is the file that the VTXCart generates doubled up to 512mb?
 
Good question. Probably, haven't compiled a game list yet. Open the srom up in a hex editor and you will likely either see that the first half is full, while the second half is empty. That, or the first and second half are the same. Used a hex editor to split the size in half.
 
It's a pity that @rockbottom hasn't appeared on this forum for a long time.
The project is very interesting and useful. Even in V3 there are problems with games and I really want to re-flash this cart.
I currently began to reverse and study the V3 boards.
It is almost like the previous, but differs with 1.27mm headers for stilts.
I developed three boards for my STM32 dev board for programming P, S_M and C_V chips.
I'll keep you informed.

Another (crazy) approach is to program the cart boards right in the slot. To do this, we need two 120-pin slots and a MCU.
Unfortunately, some pins (WP#, etc.) are hard-wired in the cart's PCB, so I decided to start with separate boards first.
Hello, where can I find the gerber file for the dump pcb of the rom?
 
Ok got one of my C ROMs to match the MD5 posted by ack so confident this one is good to go. Programming now.
 
Just hit a dead end.

Cart doesn't boot. It just goes straight to the check board screen.
I've programmed everything, dumped and checked the Cr32 for every chip's content before soldering them into the cart.
Could this be related to the CPLDs? I've never used Quartus before, so I'm not sure if I'm doing something wrong.
What I do is click compile, get some warnings after compiling, then click on program device (open programmer), check the first box, and click start.
I don't get solid connections every time because I didn't solder directly to the connector of the cart, but after some tries, I get a 100% successful green bar.

I would appreciate any suggestion.
 

Attachments

  • print2.png
    print2.png
    167.7 KB · Views: 63
Just hit a dead end.

Cart doesn't boot. It just goes straight to the check board screen.
I've programmed everything, dumped and checked the Cr32 for every chip's content before soldering them into the cart.
Could this be related to the CPLDs? I've never used Quartus before, so I'm not sure if I'm doing something wrong.
What I do is click compile, get some warnings after compiling, then click on program device (open programmer), check the first box, and click start.
I don't get solid connections every time because I didn't solder directly to the connector of the cart, but after some tries, I get a 100% successful green bar.

I would appreciate any suggestion.
A crosshatch screen indicates an issue talking to the program roms on the PROG board. For the 161in1 it could be caused by the PROG_CP1 CPLD or something with the P1/P2/P3 flash chips. If you have unibios what you can do is at crosshatch screen press 'D' to go into the memory viewer, then scroll down to around address 0x000100 and see whats there.
 
Last edited:
A crosshatch screen indicates an issue talking to the program roms on the PROG board. For the 161in1 it could be caused by the PROG_CP1 CPLD or something with the P1/P2/P3 flash chips. If you have unibios what you can do is at crosshatch screen press 'D' to go into the memory viewer, then scroll down to around address 0x000100 and see whats there.
I'm happy to report that I have solved the problem and have a proper working cart now.
Reflowed the P-roms and the cart booted properly.
The only problem is powering off the system to choose a different game, but I'm not complaining it's worth the trade-off.
Special thanks to RockBottom, Vortex, Ack, Rewrite, and everyone else who helped here in this thread or was involved in the project.
 

Attachments

  • 1703715194112.jpg
    1703715194112.jpg
    186.6 KB · Views: 118
The only problem is powering off the system to choose a different game, but I'm not complaining it's worth the trade-off.

Install a Unibios and you can soft reset with a button combination.
 
Install a Unibios and you can soft reset with a button combination.
Unfortunately this just reboots the existing game and doesn't go to the menu system.
 
  • Sad
Reactions: nem
Back
Top