Just re-checked all the roms. 2 didn't verify, so I re-burned them. Still similar issues with the noise, but the sprite palette looks fixed. I don't trust this thing anymore, maybe i'll just table this one until my new programmer gets here.
- Thread starter ekorz
- Start date
The one from Aliexpress?
Post some impressions when you get it! I've been eyeing one as well. $500+ is too much, but for half price I'm definitely interested.
I got one from an eBay seller. One of his reviews was for the same item and said it was "authentic". So yeah, rolling the dice a bit but I thought it was worth a shot. I'll let you know if it's the real deal.
Well, the Xeltek verified the roms (very quickly compared to the top3000) but they all still verified.
But the noise is still present. It's odd I don't see it in the original... Guess I might need that scope after all.
But the noise is still present. It's odd I don't see it in the original... Guess I might need that scope after all.
thanks @caius
hey, it's tutorial time for how to do this conversion (or uh, how I attempted it) @ShootTheCore
acquire Gonta the Diver II / Party Time
remove socketed roms @ 1e 13h
desolder roms at 9a, 12f, 13a, 14a, 14d, 14h
add sockets to the above
desolder 8pin NVRAM at H3 (chip is 93C45, but 93C46 works)
files required osman.zip from mame set
write 1e to 27c4002 equivalent (I'm using HN27c4096G-12)
write 13h to 27c2001 equivalent (I'm using ST M27c2001-15f1)
write 9a, 12f, 13a, 14a, 14d, 14h to 26c160 equivalent (I'm using ST M27c160-50f1)
byteswap eeprom-osman.bin, write to 93c46
(I recapped it too)
assemble
ask for help
Here's hoping I forgot something! In some photos online I see ceramic caps tying pins 4&5 of the 741F138N at 4f. It doesn't seem to matter for me when I install one. I also started with a ceramic cap tying pins 1&15 on a 74F157AN at 12E. Removing it didn't seem to do anything.
hey, it's tutorial time for how to do this conversion (or uh, how I attempted it) @ShootTheCore
acquire Gonta the Diver II / Party Time
remove socketed roms @ 1e 13h
desolder roms at 9a, 12f, 13a, 14a, 14d, 14h
add sockets to the above
desolder 8pin NVRAM at H3 (chip is 93C45, but 93C46 works)
files required osman.zip from mame set
write 1e to 27c4002 equivalent (I'm using HN27c4096G-12)
write 13h to 27c2001 equivalent (I'm using ST M27c2001-15f1)
write 9a, 12f, 13a, 14a, 14d, 14h to 26c160 equivalent (I'm using ST M27c160-50f1)
byteswap eeprom-osman.bin, write to 93c46
(I recapped it too)
assemble
ask for help
Here's hoping I forgot something! In some photos online I see ceramic caps tying pins 4&5 of the 741F138N at 4f. It doesn't seem to matter for me when I install one. I also started with a ceramic cap tying pins 1&15 on a 74F157AN at 12E. Removing it didn't seem to do anything.
ShootTheCore
Legendary
Awesome instructions-thank you! Hope you're able to get your graphic glitches sorted out.
It seem you did it in the right way.My only concern could be the 27C160s.Have you any chance to try other devices?It happened to me to face some bad devices (altought my programmer didn't complain about), especially the ones bought from China (whihc are not new but erased and erased many times).
Regarding the PALs, I think there is not need to change them.In my conversion I changed the one @5C but I was using a Joe&Mac Return PCB which has slight different hardware.
P.S:
Obviously when you revert the conversion I guess you use the original MAKS ROMs from Party TIme and not some programmed 27C160.You could try to program your 27C160 devices with Party Time GFX data and see if this will produce same issue.
Regarding the PALs, I think there is not need to change them.In my conversion I changed the one @5C but I was using a Joe&Mac Return PCB which has slight different hardware.
P.S:
Obviously when you revert the conversion I guess you use the original MAKS ROMs from Party TIme and not some programmed 27C160.You could try to program your 27C160 devices with Party Time GFX data and see if this will produce same issue.
thanks. I forgot to mention the PALs. I used the ones from jammarcade but they didn't seem any different than the ones on my board, so I didn't list that step.
I will try some new 27c160 chips on Gonta per your recommendation. I actually did that with the 4096 and the 2001... but didn't because programming a 160 took so long with my old burner!
@caius I'd love to know what else you did for the Joe & Mac. I have a Chain Reaction that I think uses the same board.
I will try some new 27c160 chips on Gonta per your recommendation. I actually did that with the 4096 and the 2001... but didn't because programming a 160 took so long with my old burner!
@caius I'd love to know what else you did for the Joe & Mac. I have a Chain Reaction that I think uses the same board.
Try on Gonta the same 27C160s (after erased them obviously) your are using now on the conversion and see if same corruption issue occurs.
Some magic...
Update: I burned a copy of Gonta using the roms I had. That worked fine. Then I erased the roms and wrote Osman, and went back to graphics errors. 9A was the problem child for sure. I tried a few random things... ".9a" files had an association in Windows, and I wondered whether windows was writing some header to the file that was goofing things up. When I open the files in HxD it was no problem, but in something like notepad they weren't showing up in hex, but rather odd ascii. Didn't seem to make a difference for Gonta though.
But I removed the associations, and unzipped a copy to a different file extension. This one also opened into ascii. I tried writing it without the setting "buffer clear on data load with FF" and that seemed to work better.
OR I just finally stumbled upon a ROM chip that works better than the others in 9a...
Anyway the glitch fx seem to be treatable if I fiddle with the power, now, so I can make them all go away somewhere around 5.15v at the jamma edge. Good enough for me, it's playable now. Anyway not sure what actually fixed it, but I'm happy to call it case-closed. I may buy some more 160s and try again, or resolder that whole socket, or something.
I wish it was more conclusive, but at least the conversion above is fine-to-use. @caius looking forward to your notes since I have a magical drop just sitting here...
But I removed the associations, and unzipped a copy to a different file extension. This one also opened into ascii. I tried writing it without the setting "buffer clear on data load with FF" and that seemed to work better.
OR I just finally stumbled upon a ROM chip that works better than the others in 9a...
Anyway the glitch fx seem to be treatable if I fiddle with the power, now, so I can make them all go away somewhere around 5.15v at the jamma edge. Good enough for me, it's playable now. Anyway not sure what actually fixed it, but I'm happy to call it case-closed. I may buy some more 160s and try again, or resolder that whole socket, or something.
I wish it was more conclusive, but at least the conversion above is fine-to-use. @caius looking forward to your notes since I have a magical drop just sitting here...
Well, I got in some new 27c160's and re-burned the full gfx section. And by "new" I mean "clearly used, but also clearly real." So far it looks like 100% of my video noise went away! Damn fake roms... wtf.
Last edited:
Sorry to resurrect an old thread, but I just bought Gonta to convert to the incredibly awesome game that is Osman/Cannon Dancer.
Can ST M27c160-100f1 be used in place of ST M27c160-50f1? Or are they too slow? If I cannot get them, should I just erase the original MASK ROMs and write the files as 27c160? I don't really care about the original game.
Can ST M27c160-100f1 be used in place of ST M27c160-50f1? Or are they too slow? If I cannot get them, should I just erase the original MASK ROMs and write the files as 27c160? I don't really care about the original game.
Probably 100f1 is fine, that's the speed rating 100ms vs 50ms. You could also try 29F1615 if your programmer can handle it, or use 27c322 and double the binary. Or the originals if they're erasable, but usually mask roms are one-time-programmable.
Devices access time is expressed in 'ns' (nanosecond), not 'ms' (milisecond)
Anyway, the access time matters only when you deal with CPU code, GFX-audio data is not affected by propagation delay time.