What's new
Well apparently my problem wasn't real. It's working now.. Must have been a poor contact the first time I plugged it in. Time for romset number two testing I guess. Although I will try the original bios version first.
 
With the QB DDP, its the same romset across the m27c322, no change? and just the QB on the U5 GAL + JP1? = bypass stock bios?
The description is in the first message of this thread, you need to build a special version of the program rom that includes the special bios from a stand-alone game.
Also do any of the 3 cave carts offer any bios settings or options etc via test or service?
Yes, hold the test button for ~1s.
 
Question: I've seen posts go back and forth asking this but I haven't seen a picture of anyone actually doing this. Can the EPROMs be socketed with the 3d printed cases or is there still a clearance issue and the EPROMs still need to be soldered? I'm about to assemble my first one (friend gave me a PCB set) and would prefer socketed but will solder if it's the only way. Thanks in advance.
 
Question: I've seen posts go back and forth asking this but I haven't seen a picture of anyone actually doing this. Can the EPROMs be socketed with the 3d printed cases or is there still a clearance issue and the EPROMs still need to be soldered? I'm about to assemble my first one (friend gave me a PCB set) and would prefer socketed but will solder if it's the only way. Thanks in advance.
There's room to make a case with sockets but I can't tell you if the existing one someone designed has enough room
 
There's room to make a case with sockets but I can't tell you if the existing one someone designed has enough room
Thanks for the quick reply. Alright, I'll have to see about posting photos of the shell I printed out and see if the sockets work or not so others will have a solid reference in the future.
 
Has anyone used GAL16V8D with this project? The datasheet seems to have the pull ups shown in the diagram but I'm not an expert on the matter.
 
Yep. I've used GAL16VD on mine

https://www.arcade-projects.com/thr...ssembly-and-troubleshooting.10015/post-317834

Here's the gals I have installed

BgA4Lav.jpeg
 
Also, shoutout to everyone recommending standoffs. I went 1 step further and added a pair of supports so if the motherboard is flat, the PCBs are level. It's not attached to the motherboard, just rests perfectly on the case of it. It's a 15mm standoff fwiw.
 

Attachments

  • 20220613_140653.jpg
    20220613_140653.jpg
    220.2 KB · Views: 122
I've built a DDP set, but I'm having difficulties getting it to boot. Most of the time it just goes straight to the test menu, but sometimes I get garbled pink graphics. My question is: is there a rule-of-thumb way of knowing if the files need to be byte-swapped or not? I suspect maybe I didn't byte-swap the files when I was supposed to.

I see in the early posts in this thread that the DDP header (paraphrasing) "should be garbled," but to facilitate that in my EEPROM burner software (using a TL866ii), I actually had to byte-swap the file myself. Does that then hold true for the remaining EEPROMs? I know the GALs I'm using contain resistors so I don't think the three additional resistors are necessary. Also, is it the case that, if everything in the "blue square" region (P1, GALs, etc) is installed properly, the game will at least attempt to boot? That'd be a great help for drilling down into the problem. Thanks!
 
I've built a DDP set, but I'm having difficulties getting it to boot. Most of the time it just goes straight to the test menu, but sometimes I get garbled pink graphics. My question is: is there a rule-of-thumb way of knowing if the files need to be byte-swapped or not? I suspect maybe I didn't byte-swap the files when I was supposed to.

I see in the early posts in this thread that the DDP header (paraphrasing) "should be garbled," but to facilitate that in my EEPROM burner software (using a TL866ii), I actually had to byte-swap the file myself. Does that then hold true for the remaining EEPROMs? I know the GALs I'm using contain resistors so I don't think the three additional resistors are necessary. Also, is it the case that, if everything in the "blue square" region (P1, GALs, etc) is installed properly, the game will at least attempt to boot? That'd be a great help for drilling down into the problem. Thanks!
PGM carts and slots can be very picky if the contacts aren't clean. I had to swab down my freshly assembled cart edges on mine, and found I had not made mistakes when it just worked then.
 
PGM carts and slots can be very picky if the contacts aren't clean. I had to swab down my freshly assembled cart edges on mine, and found I had not made mistakes when it just worked then.
Yeah, I've done a lot of cleaning of both the slot and the boards. I do have an OEM cart for testing the system and that boots without controversy, reliably, so I think the contacts are probably okay? Probably bears doing again though.
 
I've built a DDP set, but I'm having difficulties getting it to boot. Most of the time it just goes straight to the test menu, but sometimes I get garbled pink graphics. My question is: is there a rule-of-thumb way of knowing if the files need to be byte-swapped or not? I suspect maybe I didn't byte-swap the files when I was supposed to.

I see in the early posts in this thread that the DDP header (paraphrasing) "should be garbled," but to facilitate that in my EEPROM burner software (using a TL866ii), I actually had to byte-swap the file myself. Does that then hold true for the remaining EEPROMs? I know the GALs I'm using contain resistors so I don't think the three additional resistors are necessary. Also, is it the case that, if everything in the "blue square" region (P1, GALs, etc) is installed properly, the game will at least attempt to boot? That'd be a great help for drilling down into the problem. Thanks!
Mine turned out to be the Fluffy PCB needing a reflow cause the ground plane is so big on it that my iron wasn't hot enough to make some solder flow and caused a cold joint in some places. Give that a shot if the cleaning doesn't work.
 
I have working conversions. If I don't plug the cart in just right it's utterly normal to get a pink screen of noise instead of the game. The PGM is definitely picky. So just make sure you really play all the games with adjusting it a little, pushing it in more, pulling slightly back out, all the stupid stuff before you decide it's broken. It might be! Or, it might just need to be coddled.
 
Yeah, I've done a lot of cleaning of both the slot and the boards. I do have an OEM cart for testing the system and that boots without controversy, reliably, so I think the contacts are probably okay? Probably bears doing again though.
Which GAL16V8 are you using? It looks like some don't have pull-up on their inputs, so they'll be unstable without external pull-ups.

Generally the PGM bios checks the header of the game, and if that fails it jumps into the test menu.
 
I've built a DDP set, but I'm having difficulties getting it to boot. Most of the time it just goes straight to the test menu, but sometimes I get garbled pink graphics. My question is: is there a rule-of-thumb way of knowing if the files need to be byte-swapped or not? I suspect maybe I didn't byte-swap the files when I was supposed to.

I see in the early posts in this thread that the DDP header (paraphrasing) "should be garbled," but to facilitate that in my EEPROM burner software (using a TL866ii), I actually had to byte-swap the file myself. Does that then hold true for the remaining EEPROMs? I know the GALs I'm using contain resistors so I don't think the three additional resistors are necessary. Also, is it the case that, if everything in the "blue square" region (P1, GALs, etc) is installed properly, the game will at least attempt to boot? That'd be a great help for drilling down into the problem. Thanks!
This is hard to answer. Generally: The EPROM is 16 bit, and the cpu reads them like that.
The ROMs in Mame and the ones that my script generates from them are byteswapped, so for example the copyright message in the header has each pair of characters swapped. The Top3000 programmer I'm using reads them as-is and writes them correctly to an EPROM without changing any of the defaults. I have not heard anything from other people who use TLS866 that they needed to byteswap ROMs or change any options when burning them. (Please correct me if I'm wrong.)
My guess is that since the host platform (the PC) is little-endian it expects to read ROMs like that, and write them correctly to 16-bit EPROMs.

If everything in the blue square region is installed correctly, there are no bent pins or loose solder joints, and R1 is present, the game should attempt to boot. The CPU has no connection to the other ROMs, so they should just result in graphical glitches.
 
Back
Top