What's new
Can you get a picture of the PCB and the game running, you have so much going on it makes it hard to diagnose.
Your V roms are correct, first part of V1 splitting is V1 and second is V3 same as for V2.
 
Can you get a picture of the PCB and the game running, you have so much going on it makes it hard to diagnose.
Your V roms are correct, first part of V1 splitting is V1 and second is V3 same as for V2.
After playing the game again, it looks like graphical issue is just camera shake from crashed ship, so no unusual graphical artifact in my game. However, the audio is bad. What I thought was tracks playing at the wrong time is actually audio volume issue. Some parts of audio are very quiet, others are very loud. I compared it to the 161 in 1 version, and the audio level is uniform throughout. I attempt to demonstrate this in jukebox feature with Unibios. First I play the intro music to establish baseline, then I play another track that has quiet audio, then it got much louder later on.

View: https://youtu.be/IhccgnN63EE

Here are shots of my PCB after the third or 4th round of soldering. Haven't cleaned up the flux residue yet since I may have to desolder. Last pic is the patch wire I did for M1 since that pin's pad had lifted.
 

Attachments

  • IMG_20210522_233005122_HDR.jpg
    IMG_20210522_233005122_HDR.jpg
    244.7 KB · Views: 129
  • IMG_20210522_233036384_HDR.jpg
    IMG_20210522_233036384_HDR.jpg
    269.3 KB · Views: 133
  • IMG_20210522_233134257_HDR.jpg
    IMG_20210522_233134257_HDR.jpg
    213.3 KB · Views: 125
Last edited:
Everything looks okay, I'd check continuity between the V roms.
Could also be a bad chip.

If it were me I'd replace the V roms with 2 x 27c322s and swap the jumpers like the original. Less chips are easier to diagnose.
 
Everything looks okay, I'd check continuity between the V roms.
Could also be a bad chip.

If it were me I'd replace the V roms with 2 x 27c322s and swap the jumpers like the original. Less chips are easier to diagnose.
Thanks for looking it over. I followed Mike Mcbike's conversion here: http://www.wolfgangrobel.de/mvs/pulstar.htm

He used 4x 27c160 and the PCB says TC5316200, which is a 27c160 EPROM. So I had thought we have to use 160 if we're using EPROMs. If 322 works too, I would try that.
 
I went with 160, and I replaced each of the 4 V rom one by one and even the m1 rom, testing after each replacement and the sound issue is still there. The only thing I haven't replaced that might be related to sound is the LS74 smd that I took from another progbk1 board. So after more testing, I think this is a memory addressing issue maybe. When I playback the sound track in jukebox for 0x0785, as shown in my video, it's quiet, then jumps to loud audio. That loud audio track is 0x0786 in mame. The 785 that is quiet in my cart, isn't even the same track in mame. What could explain this? Maybe the pcm chip is bad?
 
the PCM chips do go bad, I've got a whole stack of Cart PCBs with bad PCM chips.
 
the PCM chips do go bad, I've got a whole stack of Cart PCBs with bad PCM chips.
I just swapped the LS74, if this doesn't work, I'll have to swap to a new progbk1 then.

OK that didn't work. I then reflowed the PCM, every ceramic cap, still no go. I guess I have to swap progbk1 then.
 
Last edited:
bad connectivity on the edge connector of the cart can cause this kind of thing too. it couldn't hurt to clean it if you haven't already.
 
I did swab it real good with ipa using cotton swab and tried different mvs, no luck. Now i've swapped over to a new progbk1, (LS47 from old board) it's still doing it! Swapping p1 next.

Totally stumped. Just quick run down of where I am now.

1. Swapped each V-Rom one at a time on PROGBK1 #1, also M-Rom on CHA board, then swapped LS74 on PROGBK1 #1. Issue persist after each swap.
2. Installed old V-Rom removed from #1 to PROGBK1 #2, old LS74 from #1, then swapped P1, SP2. Issue persist after each swap.

From step 1, since swapping V-Rom had no effect, I am assuming this issue is not with the V-Rom. Same with M-Rom, same with LS74. So the only conclusion was the PCM chip. Swapping to a new PROGBK1 in step 2 should also eliminate that as being bad. At that point, only P1 and SP2 are still untested, but swapping them out did not fix the issue either. Also tested continuity between all the V-Rom legs, most of them have continuity between the 4 EPROMs, only some legs I assume aren't supposed to be connected together, but I didn't jot down which ones to verify. The fact that in Jukebox the address of the playbacks don't match tells me it should be addressing related, but I don't know enough to say what or how. It's as if the records for the audio tracks are wrong, so wrong audio is being played.

The only thing I didn't do is dump the Rom and test it in MAME when I had them out. But, I did verify them via the burner program, as well as via window's "FC" command, the burns were successful. I must be missing something obvious, everything else are graphics related.
 
Last edited:
V-ROMs are just the samples. Music is controlled by the M-ROM and the ZMC chip on the CHA board.
 
It could be the V Rom files, how did you split them?

used OSX comman, split -a 1 -b 512k filename filename. it splits it into 512k files with an extension of a, b, c, d etc. I think it's ok, as I've had success with Ironclad. and the files reconstitute and chksum just fine.

V-ROMs are just the samples. Music is controlled by the M-ROM and the ZMC chip on the CHA board.

Since I've swapped the V-ROM and M-ROM, the only thing left is the ZMC on the CHA board. That means I'll basically have redone the whole game lol. Maybe I'll just burn all new EPROMs on to a new CHA board.
 
I think it's ok, as I've had success with Ironclad. and the files reconstitute and chksum just fine.
please open the resulting file in a hex editor and let us know the address for the very last bit.
for a 27c160 file it should end at 0x200000 exactly... such that 0x200000 itself has no data and 0x1FFFFF is the last bit of the file.

both files should end this way.

This is an important check because if it's not splitting at the correct point the second file will be offset even if they reconstitute correctly. the result is that some sounds will work (those on the first rom) but others wont (those on the second rom)
 
Last edited:
please open the resulting file in a hex editor and let us know the address for the very last bit.
for a 27c160 file it should end at 0x400000 exactly... such that 0x400000 itself has no data and 0x3EEEEE is the last bit of the file.

both files should end this way.

This is an important check because if it's not splitting at the correct point the second file will be offset even if they reconstitute correctly. the result is that some sounds will work (those on the first rom) but others wont (those on the second rom)
Sorry I'm not understanding which file you want me to check. I have V-ROM file 089-v1.v1 This splits into 089-v1.v1.a, 809-v1.v1.b etc until h. I looked at both the .a .b .e .h file in HxD, they end with offset address 0007FFF0 with data if i have it display in HEX mode. I'm not sure I'm using HxD correctly.
 
are you splitting so much to fit in the banks with the TL866?
Yea the TL866 can only do 512KB or 4MBit per bank. So each 322 chip will have 8 files, and 160 will have 4 files to burn via the adapter since it's burned as a 27C4096 EPROM. For the V-ROM, I burn a,b,c,d to one 160, and e,f,g,h to another 160.
 
that should be correct then.

if you want to confirm you can re-dump after you've burned the ROM, then re-combine and compared against the original file.
 
Back
Top