What's new
I managed to steak a V3 AES out of China just before the supply chain issues hit. Then I misplaced in my massive mountain of unfinishedstarted projects, found it again last night - this is what it looks like inside.

Does this looks like a straightforward reference implementation?

IMG_8618.png

IMG_8620.png

IMG_8619.png
 
1731263049946.jpeg


So what's the deal with these ones? I know in @Vortex 's repo there are pics of a cart with this style daughterboard. Are these effectively the same, just visually different, or altogether not usable? (clearly need a different daughterboard PCB). I'd have assumed not usable, but the pics in the repo have me second guessing.


Completely unrelated to the thread, are you using a cocktail table as your desk?
 
I managed to steak a V3 AES out of China just before the supply chain issues hit. Then I misplaced in my massive mountain of unfinishedstarted projects, found it again last night - this is what it looks like inside.

Does this looks like a straightforward reference implementation?

IMG_8618.png

IMG_8620.png

IMG_8619.png

Yep this is the standard one with the pins attaching the daughterboards
 
1731263049946.jpeg


So what's the deal with these ones? I know in @Vortex 's repo there are pics of a cart with this style daughterboard. Are these effectively the same, just visually different, or altogether not usable? (clearly need a different daughterboard PCB). I'd have assumed not usable, but the pics in the repo have me second guessing.
My AES 161 in 1 looks like this. Should I still send it into you?

It's the same configuration as this video.
 
Mission Complete!! After doing extensive testing during the weekend, I can confirm that the capacitor replacement completely fixed all the audio issues. I ran trough every game at least a couple of minutes (including Xeno Crisis and Hypernoid), played a lot of matches of Windjammers, Neo Turf Masters, Baseball Stars 2 and League Bowling, and completed the whole Metal Slug series. All of this without any single audio issue, system crash/freeze/reboot, or visual glitch. Everything is 100% perfect and stable now.

Regarding the original capacitors, I measured them and both are 49pF, so if they are supposed to be 47pF, the value is correct. Maybe they are low quality and another parameters, as the ESR, are off, I can't tell. I just think that some combinations of cartridge and MVS (mine is a MV1ACHX) may require a bigger value to fine tune the timing, but it is just an assumption.

I found this to be a very enjoyable and rewarding mod, as long as you have the required tools and skills (could be very frustrating otherwise). Cause of this, I would like to share some tips and ideas of the process, I hope this can help someone in the future, both on the hardware, and the software side.

On the hardware side
  • The most frustrating part of the process, for me, was extracting the daughterboards. The good thing, is that there is no need to be much careful at this step. The daughterboard can be completely destroyed on the process without any problem, as new ones can be made easily, as long as the main board and the flash chip are not destroyed on the process (which is very difficult, as the heat is applied on the bottom side of the board, an the chip is on the top side side of the daughterboard, there is a big gap for the heat to dissipate). Building new daughterboads, with new gold plated pin strips, is recommended in any case, because the old daughterboards with tin leftovers on the pins are very likely to have connection issues with the female headers. When I did the mod, I totally destroyed one the daughterboards and slightly damaged the other two, but I was going to build new ones anyway.

  • Several pages before, there was discussion about what vacuum de-soldering gun and what nozzles to use. My answer here is clear: none. I don't recommend to use a vacuum de-soldering gun at all, I don't even have one, as I don't like them much. For extracting the daughterboard, use a hot air soldering station and the process described by @rewrite here (https://www.arcade-projects.com/thr...lticart-upgrade-build-guide.27994/post-404691). The preheating station is no really needed, it will make the extraction process easier, that's for sure, but not strictly needed (I don't have one). Once the daughterboards have been extracted, for removing the tin leftovers inside the holes, I keep heating with the air station and when the tin is melted, I quickly put my mouth as close as I can above the board and throw a short but intense blow (I know, not very professional, but it works nicely). By this method you can easily clean 2x5 holes per blow, but be careful because the tin will fall on the table. With and air compressor maybe this can be done quicker and easier, I didn't test it as I don't have a compressor.

  • For the new daughterboards, the mangled castellated holes doesn't need to be fixed, as they can be soldered just the way they are, but I found that fixing them, although time consuming, is worth it, cause it makes soldering the chip easier and gives better results. For fixing them, I put them on a solid and stable surface and, with a very sharp surgeon knife, I made two well directed and firm cuts, on both sides of the holes, to cleanly rip the unneeded half of the ring. If doing this, always check with a microscope or magnifying lens that there are no bridges between the castellated holes.

  • After soldering the 22x2 male pin stripes on the daughterboard, check that all the pins are correctly aligned and if not, align them with fine tweezers, before inserting them on the female header. These connectors are very flaky and the heat applied while soldering is very likely to slightly unalign them. I didn't check this on my first daughterboard and partially damaged one hole of the female header when trying to insert it. Luckily I was able to put it back in place and didn't have to replace the whole header. Also, before inserting the daughterboard in the female header, be sure that there are no flux leftovers on the pins, as it could cause connections issues later, and could very hard to clean inside the holes.

  • This point is important, I mentioned it before. If after completing the mod everything works fine, but there are occasional sound issues, in the form of wrong or louder notes, or missing or incomplete sound samples, remove capacitors C4 and C5 on the PROG board and replace them with new 100pF ceramic capacitors. This totally fixed the issue for me.

  • Another important point, if your MVS board has the M68K NEOBUF replaced with a FPC yellow bridge, is very likely to cause troubles. When I bought my first 161-in-1 several years ago, I had very frequent crashes and reboots, and I got them totally fixed by replacing the bridge with a NEOBUF equivalent PCB. I mean replacing this (https://wiki.neogeodev.org/index.php?title=File:Neo-buf_bypass.jpg), with this (https://www.tindie.com/products/furrtek/neo-buf-replacement/).

  • And last, but not least, I HIGHLY recommend using a good digital microscope for this work. It can be done without one if you have good eyesight, I did similar jobs on the past, but my eyes are not as good as they used to be, and now that I have a microscope, the difference is like day and night. It makes everything much less frustrating, and very easy to spot and fix mistakes like shorts, bridges or unsoldered pins. Also it is nice for taking pictures and videos, for documenting purposes. I use one like this: https://es.aliexpress.com/item/4000901809079.html
On the software side
  • A few pages ago, before I started the mod, I launched a question about the compilation of the CPLDs code, but I didn't get a clear answer, so I had to test myself. Depending on the number of games and how they are sorted on the list, Quartus may give an error about not being able to fit the CPLD code. In that case, just change the fitting strategy from Speed to Area, it is totally safe to do it and won't cause any issue. The option is in "Assignments -> Settings -> Analysis & Synthesis Settings".

  • For the ROMs, I made the following modifications:
    • For KOF 2000, I used the ROM Kof2000nrxfix.zip from this post (https://www.arcade-projects.com/thr...rtridge-to-change-rom-games.15069/post-409161). It still has S layer corruption, but texts are far more readable, and in-battle graphics are almost perfect. This is maybe the best we can get. To use this ROM take S, M and P (concatenate p1 and p2 together) from the mentioned ZIP file, and C and V from the kof2000b ROM on the Vortex archive.org repository.

    • For Garou MotW, the prototype is the best we can get, but I found a patch for the P ROM that fixes the crash when doing the Kim Jae Hoon TOP attack, plus other minor cosmetic changes to make it look closer to the final version. The ending sequences are still missing, and the Tizoc Arena TV monitor glitch is still present, but the game is 100% playable. I will attach a xdelta patch at the end of this post, for the P ROM of the garuoub ROM set on the Vortex archive.org repository.

    • For Irritating Maze, I found a patch that allows the game to be controlled with the directional stick, plus B, C and D buttons to change the speed of the rod. Is not the ideal way to play this game, but at least is playable, otherwise this game is totally useless. I will attach a xdelta patch at the end of this post, for the P ROM of the irrmaze ROM set on the Vortex archive.org repository.

That's everything that comes to my mind right now, but if anyone is currently doing the mod, or is trying to decide if do it or not, and have any questions, feel free to ask. I will try to do my best to help, as the rest of the users on this thread.

Finally I would like to share some pictures of the process, as they can help another users to have things clearer, and the mentioned xdelta patches.
 

Attachments

  • garoub xdelta patch.zip
    1.2 KB · Views: 39
  • irrmaze xdelta patch.zip
    911 bytes · Views: 28
  • 01.jpg
    01.jpg
    353.7 KB · Views: 83
  • 04.jpg
    04.jpg
    195.4 KB · Views: 67
  • 03.jpg
    03.jpg
    320.5 KB · Views: 68
  • 02.jpg
    02.jpg
    326.2 KB · Views: 68
  • 05.jpg
    05.jpg
    356.1 KB · Views: 66
  • 06.jpg
    06.jpg
    354.9 KB · Views: 73
  • 07.jpg
    07.jpg
    136.6 KB · Views: 77
  • 08.jpg
    08.jpg
    181.3 KB · Views: 79
Last edited:
I reworked the programmer code (the WeAct board).

This change the "E: %d" message to a "E: %bbbbbbbb" for the Test menu. This allows to detect which bank is defective when testing chip ID on CV chips.
When SD file access is failing, a text message is displayed instead of only error code.

This also improve delay while reading/programming CV chips. Verify should be faster and, sorry for that, programming slower but more robust.

Last but not least, I reworked menu and file loading. It split menu for P1/P2/P3 and C1/C2/C3, allowing to put all the files on the same SD card. File naming is the same as Compiler output: crom-1, crom-2, crom-3, mrom, prom-1, prom-2, prom-3, srom, vrom.
 

Attachments

  • cart.zip
    50.5 KB · Views: 44
Very nice work!
Is the split menu for c1/c2/c3 already in this version? I cannot seem to activate it. Only works when I have crom on the sd cart.
 
This should be (I'll check I've not put the wrong cart.bin). There is nothing to "activate", it just add more menu: P/S/M/C1/C2/C3/V
 
This should be (I'll check I've not put the wrong cart.bin). There is nothing to "activate", it just add more menu: P/S/M/C1/C2/C3/V
You might want to fix a couple of compiler bugs in your source.

sprintf(video_mem[0], "ERROR %d", error);

should be

sprintf(video_mem[0], "ERROR %ld", error);

error is of type uint32_t, not int. Not sure what you compile with, but GCC cross compile will throw you an error.
 
Thanks.
I use IAR, as the original project was made for it. Feel free to amend the pull request.
 
Thanks.
I use IAR, as the original project was made for it. Feel free to amend the pull request.
Take a look at Vortex' repo. Ikari of SD2SNES fame submitted a PR to change the codebase to use GCC instead of IAR. It makes the code more portable and should add new language features. It's what I've been using to cross compile from. :)
 
Legendary ikari you're talking about just prepared his GitHub repo to commit his latest changes ^^

https://github.com/mrehkopf/VTXCart/blob/enhancement/CHANGES-ikari.md

It's a more or less complete rebuild of the original programmer with a lot QoL features (like open line detection, short detection, flash resume, pre check if data needs to be written etc) features a simple file manager (cycle through all files of root directory) and is even slightly faster than the original programmer.

This is a preview as he will review the code once again after he pushes it to the repo 👌
 
Last edited:
Legendary ikari you're talking about just prepared his GitHub repo to commit his latest changes ^^

https://github.com/mrehkopf/VTXCart/blob/enhancement/CHANGES-ikari.md

It's a more or less complete rebuild of the original programmer with a lot QoL features (like open line detection, short detection, flash resume, pre check if data needs to be written etc) features a simple file manager (cycle through all files of root directory) and is even slightly faster than the original programmer.

This is a preview as he will review the code once again after he pushes it to the repo 👌
Very nice. I'm waiting for the code update (currently, QoL and menu is not in the github).

Also, you didn't mention the voltage mod. It looks like a "must have", easily done with the diode on the adapter.
 
You're right I forgot to mention that 😅
Was more focussed on the soft that the hardware it seems 🙈
Yeah in my opinion it's absolutely mandatory. Writing to this Chips is at ease afterwards. I only had one Chip that had totally corrupted blocks and could not surpass this.

Before it were like 8-10 Chips that seemed "dead"
 
Back
Top