yeah it seems ok
- Thread starter goguelnikov
- Start date
@Vortex i experimented with the contraints a little bit: i took the same settings for PROG_CP1: nPORTWEL, CHA_CP1: CK1B, CHA_CP1: DRD0,CHA_CP1: PCK2B as for PROG_PCM2:CLK_68KCLKB but it neither got worse nor better: it stayed exactly the same. What was working before remained working and what failed before resulted in exact the same errors (and errorcodes)
Any other idea i could try? would you suggest i`d reduce the gamecount or wait till i can test von my v3 to exclude hw incompatibility?
Any other idea i could try? would you suggest i`d reduce the gamecount or wait till i can test von my v3 to exclude hw incompatibility?
I ran into something like this today when starting to work on a 2nd (V3) cart for testing 3G C roms. I had reused my CPLD directory and just copied over the new .inc files, recompiled, flashed the CPLDs. I only had P/S/M flash chips installed, so it was enough to see if games booted. The first 11 games were fine, 12-14 were crosshatch, 15 was the wrong game (was the game for slot 14), really high numbers would stay on the menu but be messed up. After much debugging it seems that quartus was still using the data from the old .inc files, even though they were updated. It was only after I nuked all the directories under each CLPD's synth directory did quartus seem to start using the updated .inc files.
I rechecked the inc files.
I inserted errors to check if they are really read in during sythesis and they were...
So i rebuilt the CPLD projects and updated the CPLDs: no change
Edit: During this week the new daughterboards shall arrive... therefore i'll be able to test with my v3...
I'll keep the files as they are and just flash them to the v3
I inserted errors to check if they are really read in during sythesis and they were...
So i rebuilt the CPLD projects and updated the CPLDs: no change
Edit: During this week the new daughterboards shall arrive... therefore i'll be able to test with my v3...
I'll keep the files as they are and just flash them to the v3
Last edited:
Progress update for the dual C flash chip daughter board, which arrived today. I did the non-castellated hole order as @ManCloud suggested since jlc rejected doing it with.
You can see the effects of not doing castellated holes on the jlc order if you zoom in
The left side copper from the through hole is still there, just kinda pushed in a bit. I ended up just using fine tip tweezers and pushing the dangling copper all the way against the right side of the hole. Seemed to work ok.
Here are pics of it assembled and installed
Last weekend when I was doing some debugging I found a way to optimize the prom data, which saved about 70MB of prom space. This made it possible to include the full rom set plus a number of homebrew titles on the cart. I made a cart that included all of the games (except xeno crisis) from @Vortex's archive.org romset. There is still a little bit of space to add more too. I also sorted the games based on their menu name.
Loading up zupapa! confirmed the 3rd C flash chip is working
I need to make a small adjustment to the daughter board, then will put it up on github, probably this weekend. Code changes for the prom optimization and support for the 3rd C flash chip have been PR'd.
You can see the effects of not doing castellated holes on the jlc order if you zoom in
The left side copper from the through hole is still there, just kinda pushed in a bit. I ended up just using fine tip tweezers and pushing the dangling copper all the way against the right side of the hole. Seemed to work ok.
Here are pics of it assembled and installed
Last weekend when I was doing some debugging I found a way to optimize the prom data, which saved about 70MB of prom space. This made it possible to include the full rom set plus a number of homebrew titles on the cart. I made a cart that included all of the games (except xeno crisis) from @Vortex's archive.org romset. There is still a little bit of space to add more too. I also sorted the games based on their menu name.
Loading up zupapa! confirmed the 3rd C flash chip is working
I need to make a small adjustment to the daughter board, then will put it up on github, probably this weekend. Code changes for the prom optimization and support for the 3rd C flash chip have been PR'd.
JayAwesome
New User
You sir are amazing!
big thanks to all of you!xodaraP
Legendary
That’s awesome, would be interested in doing this if you are posting up the Gerbers
Have you found a source for the additional F0095H0 or did you sacrifice another 161 for that?
How did you program the 2 flash chips? Did you need to program them individually on the original daughter boards then combine them onto the adapter board?
Have you found a source for the additional F0095H0 or did you sacrifice another 161 for that?
How did you program the 2 flash chips? Did you need to program them individually on the original daughter boards then combine them onto the adapter board?
My plan is to provide the kicad project and gerbers sometime this weekend. I want to write up some docs first.
I sacrificed another 161in1.
If only the U1 flash chip is installed in the dual daughter board it acts like the normal daughter board, so you can program it that way. For the 2nd flash chip at U2 you need to program it with something else. I just used the daughter board the chip originally came on to program it.
Thanks for doing all the leg work in figuring out how to add more games than stock. I'm going through the process of ordering the dumper boards from JLCPCB (1.6mm thick, tented) which doesn't really matter, as it's just for dumping. Can you provide sizes for the PCB that goes back in the cart? (e.g. 0.8mm thick?)
I also noticed there are 2 dumper boards for the F0095H0; one that uses the STILT PCB that these chips are installed on (Y13), and one where you solder these flash chips directly to the dumper board (Y12) Good luck to the person who manages to do that! We only need the the plug in version (Y12) and skip the solder one (Y13) correct?
There are 2 versions of the daughter boards. I believe the older 161in1 V2 carts use the STILT version, 161in1 V3 uses the DIP version. You can see the difference between the daughterboards here
161in1 V2
https://www.arcade-projects.com/thr...-to-change-rom-games.15069/page-7#post-280338
161in1 V3
https://www.arcade-projects.com/thr...-to-change-rom-games.15069/page-9#post-384469
The STILT dumper board expects you to solder the STILT daughterboard and not the flash chip. Check the size difference between the pads and flash chip
The dual daughterboard will only work on the V3 boards. The thickness will need to be 0.8mm.
161in1 V2
https://www.arcade-projects.com/thr...-to-change-rom-games.15069/page-7#post-280338
161in1 V3
https://www.arcade-projects.com/thr...-to-change-rom-games.15069/page-9#post-384469
The STILT dumper board expects you to solder the STILT daughterboard and not the flash chip. Check the size difference between the pads and flash chip
The dual daughterboard will only work on the V3 boards. The thickness will need to be 0.8mm.
Its pascal. I used this when I was messing with it
https://www.embarcadero.com/products/delphi/starter/free-download
Make sure you change it to build 64bit binary (top right window) or it will just crash with an out of memory exception when you run the complied exe.
https://www.embarcadero.com/products/delphi/starter/free-download
Make sure you change it to build 64bit binary (top right window) or it will just crash with an out of memory exception when you run the complied exe.
Well Poop. It's a Windows 10+ only binary. I have Windows XP and 7 in a VM running on OSX. I also have multiple releases of Linux running on servers, Pi's etc. But no Windows 10. Pretty much all programmer software to this day works on 7.
I guess applying your fixes and releasing an exe (like other github project do using the Releases feature) is not an option?
I guess applying your fixes and releasing an exe (like other github project do using the Releases feature) is not an option?
Vortex needs time to look the PR's over and verify hes happy with the changes. It wouldn't make sense to create an exe/release for changes that haven't been accepted.
