What's new
Thanks heaps for nutting this out, I was looking into this a few years ago I'm glad it's been mostly figured out.

I just ordered some stuff to make a DDP cart :).
 
Having recently bought both an EPROM programmer and one of sheep_nova's Ketsui bootlegs, and then bumped into this post on Ikotsu's blog, I began wondering whether anyone had tried running trap15's Arrange version on sheep's conversions?

While I haven't yet opened up my cart, going by the original label it's also a KOV2 like Ikotsu's cart. Based on the copious amounts of hot glue on the PCB in the picture, I'm also guessing his cart is probably one of Joerg's conversions.

Could the process be as simple as burning the Arrange version to a 27C322 and replacing the vanilla EPROM with it?
 
There's already an arrange version of the program rom floating around. Can't remember what page of this thread it's on but I posted a link to my GDRIVE with all the program files. Would link it again but I'm in China and can't access google at the moment.
 
I did look into the crash, and it's not writing to ASIC shared space (or other r/o memory) when one reaches that point in the level, so i'm a bit stumped why it crashes.

I'm suffering from a severe lack of time these days, our 7 year old is a real handful and needs guidance and attention :).
If i was still unemployed i would have put more time towards this. It also bothers me and my OCD :(
 
I understand perfectly you personal situation.
And I'm OCD too ;)

What about the high score table bug?
 
High score i didn't look at, but it works fine if you boot with dip 8 off (clean/default table is loaded from rom?). If you factory reset it can boot fine. Then let it run attract a few times, turn on dip 8 and play a few games, it will trigger the save code and store that correct table in the nvram as well.

If you have a decent table by accident from cold boot, it will show that with buggy scores and buggy ship type on screen.
If you have a crappy table it will crash after the warning.
Or, you can bypass that by smashing the credit input :)
 
Having a weird issue with graphical glitching and wondering if folks have seen behavior like this before. The glitching *seems* to happen on all layers (sprite, bg, text), so I'm not sure where to even start. What's weird is that it doesn't happen during the demonstration but does during gameplay.

I cut the power traces to the Vinput pins on the EEPROMS and left them lowered, originally, but I've gone back and lifted all of them just in case (no change). I've reflowed all pins on the EEPROMs (no change). I've tried using both the original U15 PLD and Fluffy's hacked one (no change).

At this point I'm kind of baffled and wondering if it might just be the EEPROMs themselves, since they're Macronix branded ones I got off aliexpress, but I'm not entirely sure how I would prove that out.

Anyway, here's a video showing the issue, make sure to watch full screen, set to 1080p, and pay close attention to the sprites.


edit: I've gone back and re-ran the 3.3v power from my regulator--I originally ran the wire underneath the legs of the EEPROMs to keep everything neat, but on the off-chance that was interfering, I went back and ran it as short as possible. I should also say that when I burnt everything, I went through the same process of erase, blank check, write, and verify, so that shouldn't be an issue. I've also tested by taking the GFX board and swapping it into another known working cart and the issue followed.
 
Last edited:
Just to show that I didn't give up on the project:
prog.jpg


I decided to drop the second program socket to simplify routing, and re-arranged everything to fit into the area that allows sockets. I'll most likely drop the debug connector as well.

I'll probably tinker with the layout a few days, and then order PCBs.
 
Having a weird issue with graphical glitching and wondering if folks have seen behavior like this before. The glitching *seems* to happen on all layers (sprite, bg, text), so I'm not sure where to even start. What's weird is that it doesn't happen during the demonstration but does during gameplay.

I cut the power traces to the Vinput pins on the EEPROMS and left them lowered, originally, but I've gone back and lifted all of them just in case (no change). I've reflowed all pins on the EEPROMs (no change). I've tried using both the original U15 PLD and Fluffy's hacked one (no change).

At this point I'm kind of baffled and wondering if it might just be the EEPROMs themselves, since they're Macronix branded ones I got off aliexpress, but I'm not entirely sure how I would prove that out.

Anyway, here's a video showing the issue, make sure to watch full screen, set to 1080p, and pay close attention to the sprites.


edit: I've gone back and re-ran the 3.3v power from my regulator--I originally ran the wire underneath the legs of the EEPROMs to keep everything neat, but on the off-chance that was interfering, I went back and ran it as short as possible. I should also say that when I burnt everything, I went through the same process of erase, blank check, write, and verify, so that shouldn't be an issue. I've also tested by taking the GFX board and swapping it into another known working cart and the issue followed.
Have you installed a decoupling capacitor on the 3.3V line? This is definitely needed and you'll get graphics issues without it.
 
Having a weird issue with graphical glitching and wondering if folks have seen behavior like this before. The glitching *seems* to happen on all layers (sprite, bg, text), so I'm not sure where to even start. What's weird is that it doesn't happen during the demonstration but does during gameplay.

I cut the power traces to the Vinput pins on the EEPROMS and left them lowered, originally, but I've gone back and lifted all of them just in case (no change). I've reflowed all pins on the EEPROMs (no change). I've tried using both the original U15 PLD and Fluffy's hacked one (no change).

At this point I'm kind of baffled and wondering if it might just be the EEPROMs themselves, since they're Macronix branded ones I got off aliexpress, but I'm not entirely sure how I would prove that out.

Anyway, here's a video showing the issue, make sure to watch full screen, set to 1080p, and pay close attention to the sprites.


edit: I've gone back and re-ran the 3.3v power from my regulator--I originally ran the wire underneath the legs of the EEPROMs to keep everything neat, but on the off-chance that was interfering, I went back and ran it as short as possible. I should also say that when I burnt everything, I went through the same process of erase, blank check, write, and verify, so that shouldn't be an issue. I've also tested by taking the GFX board and swapping it into another known working cart and the issue followed.
Have you installed a decoupling capacitor on the 3.3V line? This is definitely needed and you'll get graphics issues without it.
Should've mentioned I tried this as well.
 
I'll probably tinker with the layout a few days, and then order PCBs.
I ordered PCBs and parts...
For now I went with 2x GAL16V8 for ROM decoding, just in case I need some extra logic to get the board to boot. If I ever make a version 1.1 of the program board I can move both into a single GAL, though it is not THAT much of a cost difference.
Wish me luck that I didn't buy expensive paperweights. :)
 
Should've mentioned I tried this as well.
It may seem obvious but have you cleaned the cart edges and also tried another PGM board?
I've arrived at the conclusion it's the EEPROMs.

Popped some newly programmed ones on a known working GFX cart and I'm seeing the same glitching.

Guess I get to buy some new ones; do not buy from Shop3008035 on aliexpress.
 
Sorry if you've already answered this but have you tried multiple PGM boards?
 
Back
Top