Excellent! Really well done! I can't believe you had a Fluke 9010A "in your attic" 😂 Those things are so difficult to find these days. From just using a logic probe on the last video straight to getting the "big guns" of the Fluke and oscilloscope out on this one - what a difference! Really good trouble shooting and reasoning. No hard bit errors so no bus lines tied high or low. Oscilloscope showed very dodgy behaviour on D0. Good methodology to test the signature of the EPROM without others in the circuit and add them one by one until the fault recurred. Looks like another case of bus contention from a failed EPROM. Video issues from a failed multiplexer solved by simply using the logic probe to find a floating pin. Really nice that the game worked once those issues had been sorted. Just the colour PROM to find/program and you have a perfectly working board set that, as you say, can be considered "known good" to test the other boards with. Looking forward to the next video 👍🙂
Yes well I really did it pull out of the storage area of my house. It is such a great tool. I was really lucky when I found it on the bay a couple of years ago... and it was WAY too cheap. The seller did not know what he had to be honest.
Thank you very much. It is always a diffucult balance to keep. I actually do scratch some of the "head scratching" as well but not much. Just if it was obviously stupid in hindsight ;-)
The trusty "touchy finger". Helped me fix a Voodoo card with an open 0R resistor in a RAS line and an Amiga with broken traces under the Denise socket. Always worth a try if you have visual feedback.
Wonderful! I could watch your repairs all day long =D That ROM pulling D0 low (despite CRC checking OK in the EPROM programmer) - that was a hard one to find, most people would spend a long time trying to work that out!!!
Nice repair :). So soothing. When you checked the ROMs, IC49 got identified as IC47. I'm not at all into MAME and stuff, this would have thrown me totally off guard. Nice one. Love your videos. Keep on going.
Yes that confused me too, and I did not mention that in the vid. But there seems to be some kind of numbering error in the mame database. I could confirm that with the phoenix.cpp source code so I knew I was fine.
Thank you very much! As far as the rom failiure is concerned I havn’t come across an issue like this before either. I found this also to be pretty surprising but somehow the eprom must have had a tendency to interfere with d0 even if it wasn’t selected.
It's often that a multiplexer or -de-multiplexer or buffer is the cause of this kind of failure, I actually was thinking this would be the cause of the rom corruption too, but that turned out to be different to my (and I think all viewers) surprise. I think the failed 157 was a fujitsu, and as your probably know these are know to go bad often due to age. Nice repair, looking forward to the next one...
Best question of all. The official arcade cabinet clearly reads "Pleiades" and then the game calls itself "Pleiads". The programmers could not even write their games name correctly? I'm afraid that this is how it was... ;-)
@@christophzett I guess.. Pleia "D"'s ??? early L33t sp33k perhaps ;) My guess it just didn't easily fit OR they didn't like repeating letters (truly optimised programming)
Hi doktorzett! I'm trying to learn to repair pcbs. I have a Thunder Fox pcb by Taito. The game has sound and seems to be running but I can see only a black screen, no video. What is the first thing can I check on the pcb? Thanks in advance for any help. Thank you for the videos! Great job!
The game runs so look at the video output circuit. I would start from the video output and work myself back. Look at the RGB and Sync-Signals. Maybe some "distal" IC in the chain has a problem.
@@christophzett Thanks for the reply! I checked RGB starting from edge connector and the traces of the RGB is connected on a custom Taito's IC (TC0260DAR). One of yours videos about the repair of Double Dragon, you gave a real good explanation about the video circuitry so I understand the custom IC is the pallete / RGB output. I found starting from the edge connector the RGB output pins but I don't know the input pins on that IC. You helped me a lot so I need to go further on the video circuitry. Thank you so much!
The Bad LS157 chip was causing the ROM chip to have ROM Checksum Errors? So it was an Addressing Error that was causing the ROM checksum Error, NOT a Data line Error
No, the 157 had nothing to do with the roms - in the circuit it is switching the address lines of the video rams. so it was causing the video problems.
@@christophzett Why is the 157 switching the address lines of the video ram? because the switching of the address line of the video ram has to do with the Horizontal lines and Vertical lines on the Arcade monitor. The 157 is switching 4 address lines to the video ram which has something to do with the H&V signals be applied to the arcade monitor.
@@waynegram8907 The video ram has kind of 2 states. 1) it is written by the cpu and filled with data that it needs to send to the screen. 2) it is outputitibg the data to the screen or graphics eproms. The 157 is a switch for the address lines of the video ram that either connects the videoram to the h&v signal lines for video output or connects it to the cpu so that the ram can be filled with data. as the 157 had floating lines the ram could not be filled with data and did not even output „regular garbage“ which it only would if it would be at least read correctly (with working address lines)
@@christophzett The Video Ram is getting Filled up with the PROM color palettes data codes? Somehow the H&V signals gets mixed with the PROM chip Color Palette data code that goes to the arcade monitor. The H&V signals are the arcade monitors X&Y or H&V coordinates. The hard part is how to calculate the H&V signals to the arcade monitors H&V coordinates?
Great job. I like the way you take us along with your train of thought. You delve right down into the heart of the problem.
Wow, thanks. Always glad to hear if someone is able to follow the train of thought in my videos... ;-)
Excellent! Really well done! I can't believe you had a Fluke 9010A "in your attic" 😂 Those things are so difficult to find these days. From just using a logic probe on the last video straight to getting the "big guns" of the Fluke and oscilloscope out on this one - what a difference! Really good trouble shooting and reasoning. No hard bit errors so no bus lines tied high or low. Oscilloscope showed very dodgy behaviour on D0. Good methodology to test the signature of the EPROM without others in the circuit and add them one by one until the fault recurred. Looks like another case of bus contention from a failed EPROM. Video issues from a failed multiplexer solved by simply using the logic probe to find a floating pin. Really nice that the game worked once those issues had been sorted. Just the colour PROM to find/program and you have a perfectly working board set that, as you say, can be considered "known good" to test the other boards with. Looking forward to the next video 👍🙂
Yes well I really did it pull out of the storage area of my house. It is such a great tool. I was really lucky when I found it on the bay a couple of years ago... and it was WAY too cheap. The seller did not know what he had to be honest.
Great video. Glad to see you back making these. Thank you!!
Thank you very much... next videos coming soon... ;-)
Great video!! Love how you show all of the 'working', some channels skip some of the head scratching, but that's what you need to do it yourself.
Thank you very much. It is always a diffucult balance to keep. I actually do scratch some of the "head scratching" as well but not much. Just if it was obviously stupid in hindsight ;-)
The trusty "touchy finger". Helped me fix a Voodoo card with an open 0R resistor in a RAS line and an Amiga with broken traces under the Denise socket. Always worth a try if you have visual feedback.
Absolutely. Good way to spot floating lines.
Wonderful! I could watch your repairs all day long =D That ROM pulling D0 low (despite CRC checking OK in the EPROM programmer) - that was a hard one to find, most people would spend a long time trying to work that out!!!
Wow, thank you very much, please do so =D. Havn't had this kind of EPROM issue before myself.
Nice repair :). So soothing.
When you checked the ROMs, IC49 got identified as IC47. I'm not at all into MAME and stuff, this would have thrown me totally off guard.
Nice one. Love your videos. Keep on going.
Yes that confused me too, and I did not mention that in the vid. But there seems to be some kind of numbering error in the mame database. I could confirm that with the phoenix.cpp source code so I knew I was fine.
As always, great job! On the ROM issue, I was thinking the select signal for it must be bad. I've never seen a ROM fail in that way
Thank you very much! As far as the rom failiure is concerned I havn’t come across an issue like this before either. I found this also to be pretty surprising but somehow the eprom must have had a tendency to interfere with d0 even if it wasn’t selected.
Always have first time for all issues ☺️
It's often that a multiplexer or -de-multiplexer or buffer is the cause of this kind of failure, I actually was thinking this would be the cause of the rom corruption too, but that turned out to be different to my (and I think all viewers) surprise. I think the failed 157 was a fujitsu, and as your probably know these are know to go bad often due to age.
Nice repair, looking forward to the next one...
Yes, you are very right! Strange EPROM fault I have to say. And Fujitsus are not aging well - very true.
As usual an very interesting and instructive video. Thanks a lot for this kind of content.
Best regards, Nicolas
One more time.Every time you surprise me for good.
You amazing 🤩
Thanks go out to one of my biggest fans! ;-)
Thanks for what you are doing.
You are welcome!
I've watched a whole bunch of repairs now and its always bus transceivers or multiplexers that fail. Rarely something like a NAND gate
Why if it is called "Pleiades" does the screen say "Pleiads"? ;)
Best question of all. The official arcade cabinet clearly reads "Pleiades" and then the game calls itself "Pleiads". The programmers could not even write their games name correctly? I'm afraid that this is how it was... ;-)
@@christophzett I guess.. Pleia "D"'s ??? early L33t sp33k perhaps ;) My guess it just didn't easily fit OR they didn't like repeating letters (truly optimised programming)
Hi doktorzett! I'm trying to learn to repair pcbs. I have a Thunder Fox pcb by Taito. The game has sound and seems to be running but I can see only a black screen, no video. What is the first thing can I check on the pcb? Thanks in advance for any help.
Thank you for the videos! Great job!
The game runs so look at the video output circuit. I would start from the video output and work myself back. Look at the RGB and Sync-Signals. Maybe some "distal" IC in the chain has a problem.
@@christophzett Thanks for the reply! I checked RGB starting from edge connector and the traces of the RGB is connected on a custom Taito's IC (TC0260DAR). One of yours videos about the repair of Double Dragon, you gave a real good explanation about the video circuitry so I understand the custom IC is the pallete / RGB output. I found starting from the edge connector the RGB output pins but I don't know the input pins on that IC.
You helped me a lot so I need to go further on the video circuitry. Thank you so much!
The Bad LS157 chip was causing the ROM chip to have ROM Checksum Errors? So it was an Addressing Error that was causing the ROM checksum Error, NOT a Data line Error
No, the 157 had nothing to do with the roms - in the circuit it is switching the address lines of the video rams. so it was causing the video problems.
@@christophzett Why is the 157 switching the address lines of the video ram? because the switching of the address line of the video ram has to do with the Horizontal lines and Vertical lines on the Arcade monitor. The 157 is switching 4 address lines to the video ram which has something to do with the H&V signals be applied to the arcade monitor.
@@waynegram8907 The video ram has kind of 2 states. 1) it is written by the cpu and filled with data that it needs to send to the screen. 2) it is outputitibg the data to the screen or graphics eproms. The 157 is a switch for the address lines of the video ram that either connects the videoram to the h&v signal lines for video output or connects it to the cpu so that the ram can be filled with data. as the 157 had floating lines the ram could not be filled with data and did not even output „regular garbage“ which it only would if it would be at least read correctly (with working address lines)
@@christophzett The Video Ram is getting Filled up with the PROM color palettes data codes? Somehow the H&V signals gets mixed with the PROM chip Color Palette data code that goes to the arcade monitor. The H&V signals are the arcade monitors X&Y or H&V coordinates. The hard part is how to calculate the H&V signals to the arcade monitors H&V coordinates?
where yours old fluke.
i saw in your past videos?
beautiful fluke like brand new
someone duplicate this fluke. on ebay
This is the fluke I always had... ;-)
Electronic Art