The Guru is proudly supported by....

15th December 2018 A few months ago a couple of Dodonpachi Dai Ou Jou PCBs came in for repair. They had been purchased as non-working boards. One had major damage and corrosion on the large video chip. To make it worse, someone had also removed all of the SOP44 ROMs and seemingly tried to put them back with their eyes shut, or in the dark or something O_o Here's a few pics of the worst one which I'll try to repair now.... OMG what a nightmare!! and here's what it looks like after removing the video chip.... looks like a bomb went off under the chip! This kind of serious chip and pad damage does not just happen by itself. Someone with no brains, no skill and no equipment tried to repair it and basically scrapped it as soon as they touched it. Several of the tiny 0.5mm pads have been lifted and were just hanging on by a few microns. WOW! Talk about the biggest loser... this guy must have won the competition! It is going to be a big challenge to get this thing going and stretch my Guru-Skills to the limit! First thing to do is clean up the board and fix the pads. After a few hours of delicate work it was done. I scraped the corrosion off the pads, straightened the bent/lifted pads then patched the one missing pad with the thinnest piece of wire I could find (~0.15mm). Hopefully it would stay there when remounting the chip. It's not perfectly clean but several pads were loose so I could not clean the area too much otherwise those pads would fall off. If that happened the repair job would become even more difficult. It's a miracle only one pad was missing! The board was ready to accept the chip but now there's a dilemma. Should I put back the original chip... did I want to spend hours straigtening all those tiny legs on that really bad looking old chip and was it blown up? Experience tells me it was probably dead and I doubt the PCB pads could take the removal and re-mounting of another chip if it didn't work the first time. So an executive decision was made. A good working chip must be sourced from some other PCB. Fortunately there are several other non-Cave games using that chip so the owner promptly bought a donor PCB and had it shipped to me. The good chip was removed and mounted onto the PCB. This was a very tedious, delicate job. It required several hours of intense concentration and is an experience I would like to forget ever happened, so I'm going to skip the details and just show the re-mounted good chip.... I suppose it came out ok in the end, but we're not done yet. The SOP44 ROMs had to be removed and read to make sure they were ok. They had to be removed anyway because of the previous poor hack job done to them so I figured I would read them anyway while they were off the board. Luckily all the ROMs were ok. However after removing the ROMs and cleaning up the PCB pads it was clear there was more damage and nearly every ROM had at least one lifted pad! Arrgghh!! Fortunately only one pad was missing and it was an unused pad. The remaining pads were hanging on by their fingernails so I just straigtened them, rolled my eyes in disgust and imagined I didn't see it. After remounting all the ROMs it was now ready for the first power-up. Would it work or was it still dead? Would it just blow up?..... 3...2...1.... power-on... hold breath!!! Sigh!! It works!! Next I had to test it to make sure it fully works. I coined it up and hit start and it appeared to be working. I started playing it and I'm thinking 'wow this is great' but then I noticed I couldn't move backwards! Damn! I went into the test mode and checked the controls and sure enough the down movement didn't work. First I suspected the I/O chip (IGS026) because it was also in bad condition but fortunately had not been touched by our Biggest Loser winner. It appeared to have been effected by the battery. In case you didn't realise, these boards have a Ni-CD barrel battery on them. If you have been following my previous work and repairs, you will know that is bad news for any PCB. If you own one of these boards you should immediately get that battery off the board before it kills it if you haven't already done it. On this particular board the battery had already been removed but there were remnants of corrosion around the area where it once was. So I removed the I/O chip, cleaned it up and remounted it onto the PCB. Tested again but still no go with back movement. I traced the down signal from the JAMMA connector to a few resistor networks but they checked out ok on the multimeter resistance test. I looked more closely at the edge connector and noticed the green solder mask was slightly darker at the place where it meets the JAMMA pad so I suspected a broken track caused by the leaking battery and doing a continuity test with multimeter confirmed a break in the trace. I scraped off the old solder mask and then the break was visible. For some reason the JAMMA pads had some of the gold plating flaking off too so I scraped that a bit and ran some old solder wick over it to clean it up. Using old solder wick and rubbing and pushing down while heating with soldering iron allows the solder to stick to the pads and re-coats it so tiny imperfections are filled in. I patched the track with a small piece of wire and re-tested. Success, now down was working. I went back to test mode and checked everything again and noticed button 3 was not working. I checked the edge connector again looking for another broken track and sure enough found that the trace at the button 3 JAMMA pad was broken. I patched that like the previous one, but this time instead of running the patch wire back to the via I simply patched the trace directly. This looks MUCH neater. If you have to patch a break in a track or a bad via do it right there where the break is, don't run ugly long wires across the PCB! I went back to test mode and verified all controls were now working. Job done! Here's a few pics of the game fully working and the final pic showing the PCB fully repaired. The last pic is very large. First click the arrows at the bottom right corner to expand the pic to full size, then you can scroll around and look at the PCB using the mouse by left clicking and holding then moving the mouse. Another successful Guru-Repair! Fortunately it was sent to me otherwise it would definitely have been scrapped. 2nd December 2018 Well well, seems it was added and then removed.... like the hoarders (Shoutime and Co.) own the IP or something and have the power to stop distribution LOL! I don't think so... in other words, I've put the src + ROMs online here in.... My Google Drive Small update: Also add OOParts to My Google Drive, a prototype Arkanoid rip-off made by Success that also runs on Sega C2 hardware. This is not supported in MAME and may never be due to arcade scene hoarders not wanting their stuff in MAME but you can run it as 'tantr' and it works fine. Just rename the zip to tandr.zip and then run 'mame tantr'.... problem solved.... If Sega were concerned they would also not be happy about the other 1000 Sega games in MAME including several other 'Sonic' games. Of course they are not worried and don't care. The game is 28 years old and is a pretty poor effort which is why it failed at the test location. You guys are funny. Better luck next time losers. Oh and thanks for an excuse to direct an inordinate amount of traffic to my site, it's great for publicity... thanks guys! :-D So.... to get it going, in your MAME source tree, simply replace the original segac2.cpp file with the file in the zip, re-compile MAME then put the ROMs in your MAME ROMs dir. Result..... instant Sonic Bros. LOL!! Since it's an unprotected set, I'm sure the ROMs could be used to convert a C2 arcade PCB too.... Get it while it's hot because in a week or two this will be just another shitty arcade game 'Columns' rip-off and will be totally forgotten. 26th November 2018 A couple of years ago an unreleased Sega C2 game surfaced. It was shown on the net and at some arcade shows and hoarded by the usual people so no ROMs have become available..... until now ;-) One of the hoarders even tried to scare anyone else with the ROMs to keep them secret by spreading rumours that the men in black would come looking for them if they leaked the ROMs! LOL! The Bottom line is this is another game rescued from the clutches of hoarders and will be coming to MAME very soon..... While I'm on the subject of arcade PCBs, a large box of PCBs arrived from Korea recently. Some are to re-dump ROMs of games that had bad ROMs and some are totally undumped games. As for what they are, you'll just have to wait ;-) In other news, the Sega Sonic System 32 trackball interface PCB was so popular that I completely sold out of stock so I have got another batch of PCBs made. If you missed out on the first batch today is your lucky day ;-) I have also been working on a few PCB projects. There are a few NVRAM boards available for use in pinball machines that normally use a 5101 or 6116 static RAM to hold settings and high scores and a nasty NiCad battery to keep the RAM powered. Unfortunately they are priced out of reach of most people even though there is very little to it, just a PCB and a RAM LOL! A buddy asked if I could make some so I made my own budget design and it works very well :-) The 2nd pic shows the 6116 NVRAM installed in my 6803-based pinball machine (Eight Ball Champ). This series of machines needs around 50 settings correctly set or the machine doesn't work at all. The little adapter is almost invisible but it's the tiny thing just above the red push button. This allows highscore and settings to be saved so a back-up battery is no longer needed so I removed the back-up battery from my PCB completely :-) 15th November 2018 I received some PCBs from Korea thanks to GPLee.... Quiz Punch 2 (previous PCB I dumped was faulty with bad ROMs) Gun Dealer 1990 DooYong (to dump missing PROMs) More More 1999 semicom (clone version) Gwa Su Won 1997 Semicom (Hanafuda) Eqoos Turbo Plus 2002 Yun Sung (gamble/betting) El Dorado 1991 Dyna bootleg (8 line cherry master) Double 8 line 1991 AMT (8 line cherry master) Dong Jak Geu Man.. Gi Ga Electronics (Korean bootleg of Jaleco's Captain Flag) Ga Jang Mu Do Hoi.. Promat (Poker) Choice Fever 1998 Blue System (Poker) 6th October 2018 I've been busy doing mostly non-arcade repairs to some Amigas (one rare and special Amiga took 3 months to be documented here soon!) and other unrelated things for the last few months and making some PCB designs. I was recently given a fancy but dead PC monitor. But this is no ordinary monitor, it's a LG 34" UltraWide Curved Gaming Monitor, model 34UC79G. Seems to be still a current product and is listed on the LG web site at AU$1349. This kind of thing is really only for serious gamers that have plenty of money to throw around, the average Joe will never see something like this except at a large computer or electronics chain store. Since this is such a rare beast I'm going to document my repair and I guarantee the end repair will surprise you ;-) The problem with it is it's dead. It's pretty sad that something that is only just 2 years old and was incredibly expensive is now dead. It's also pretty sad to see even Korean stuff is now made in China. To make it worse I didn't have the power supply and it's a strange connector... great! :-/ After some research I discovered the power supply and connector is almost identical to the PSU used by some Sony VAIO laptop models, namely the P-series. By luck I have a Sony VAIO P here so I plugged in the power supply and tested it. The LED on the PSU came on for 1 second then went off. This is a sign of a short on the main power input. I opened the case to discover there's only 1 board inside. If you check the PCB pic you'll see there's not much on the PCB. Even better there's no BGA chips... WOW! this might even be easy to fix. After checking some parts with my multimeter set on continuity I confirmed there was a short between ground and the input voltage (19VDC). When diagnosing a power short fault, the usual thing to do is to hook up a bench-top power supply and give it a small voltage (like 1V) with current around 1A to 2A and see if anything gets hot. Normally by spraying freeze spray on it before and watching to see where the freeze spray warms up. It's a fairly stock technique used by a lot of professional repairers and there's a lot of videos on youtube showing the technique. Unfortunately I don't have a bench top power supply so I had to do it the ghetto way. So not knowing anything about this monitor and finding no repair logs online (likely because it is rare and expensive and few 'gamers' would own one and be skilled enough to repair it), I proceeded to remove a few parts like surface mounted capacitors (known to short in iPhones etc) to see if the short went away... it didn't. But worse every part was seriously difficult to remove, even tiny surface mounted capacitors were held on with a tarzan grip! Obviously this PCB has at least 4 layers, but possibly 6 or 8 layers would not be surprising on such a new product. After removing over 20 parts I wasn't getting anywhere :-/ So what to do now?..... Obviously start looking up parts on Google and find out what they do! Fortunately there are not many parts on the PCB. After checking out a few parts I was getting bored with research and I wanted to just fix it! I looked over the board a bit more and noticed a chip package I had seen before in several repair videos of Apple Macbook laptop repairs by Louis Rossmann. His soldering skills aren't the best but he seriously knows his stuff and routinely repairs Macbooks that no one else can handle (check Youtube if you want to know more). The chip I remember being replaced often is usually one that takes a higher DC voltage and drops it to a lower DC voltage. This is called a Buck Regulator. The chip on the board is very small (5mm x 5mm) and has a very strange number, probably re-badge by some manufacturer to hide the identity. The number was 'SN1302001', but fortunately Google knows what it is.... it's a Texas Instruments TPS65286 Switching Buck Regulator (Google it for datasheet etc). So I figured I'll just remove it and see if the short goes away.... and it did! I discovered this chip is used to create the power for the USB hub on the rear of the monitor. Amazingly this tiny chip can provide 6 amps which explains the large heatsink pad in the middle of the chip on the bottom side and why it was very, very difficult to remove. I suspect this chip is not really up to the task given to it which is why it failed. Basically it's just too small to output 6 Amps and survive for any long period of time. Now it gets interesting because I don't keep spares of this part in stock and I have never seen one on any junk board I have lying around here. Rather than order one off the net and wait 4 weeks for it to arrive from China I just decided to power it on and see what happens... after-all the short is now gone. To my amazement it powered up straight away and works. Well kind of anyway. The LED on the power supply stayed on and the LED on the monitor also came on, but nothing on screen except the backlight. Then I realised I had not put back a bunch of parts I removed earlier hehehe! So I put them back and re-tested. It works! I couldn't believe it! In case you were wondering, the message on screen is telling me there's no signal input. So I re-assembled it and to confirm it was fully operational, I plugged it into my Toshiba C665 i5 laptop which has a HDMI output. The Windows desktop came up and shows fine, although the resolution of the monitor is so high (2560 x 1080) this laptop will never be able to show it full screen and I don't have any other device I can try that outputs a higher resolution. LG provide a driver for Windows 10 but I am sticking with Windows 7 so I can't get the higher resolution. But I can get 1920x1080 just fine. Obviously the USB ports won't work but I was never a fan of those stupid USB hubs on the rear of TVs/monitors anyway so no big deal that it doesn't work and I won't miss them! And here's a later update with some pics running in Windows 10 with the full 2560 x 1080 resolution :-D The last pic shows a directory thumbnail view of a compact flash memory card from my camera, showing all 159 pics as large thumbnails all on screen at the same time! So now I have a working 34" UltraWide Gaming Monitor for $0, fixed by simply removing one chip. Not a bad score and it's now minus one nasty chip that will never cause this monitor to die again since it's not on the PCB. Even better the previous owner left the protective clear tape on the bezel edges of the monitor so after removing it the monitor looks like new :-D Score: Guru 1, LG 0 Anyway.... Life's Good (LG-related pun intended) ;-) 9th June 2018 Well here it is, sooner than expected.... The System 32 Trackball Interface is now a reality! It turned out I was upgraded to the express service for free. I quickly assembled one using the minimum number of parts.... 5 IC's and the bottom connector. I used an original press-fit bottom connector taken from a System 32 driving interface board, but don't worry there is a common alternative available that will do the same job. I plugged it in and screwed it down using stand-offs taken from some old Sega board. Those holes are specifically designed to take the original Sega stand-offs but I don't have them so I used some black ones I had lying around and the height is perfect. I'm guessing they probably came off a dead Hikaru board. Common board spacers can also be used and fit just fine. I checked the three trackballs in the test mode and they all test GOOD. SUCCESS! :- D Note the Sonic PCB shown in these pics is sold. I am selling the trackball PCBs to recover my costs. I have sold 7 of the trackball PCB's (so far). I have 13 PCB's total but I have no use for these now that the job is done since the Sonic PCB is sold and I have no plans to get more S32 main boards and/or convert them. That can now be done by _YOU_ using my System 32 Conversion Info Page here. I will keep one fully assembled trackball board for myself, so I currently have 5 PCB's available. If you are interested to buy one (or more) contact me. If more than 5 are wanted I can re-order another batch so don't worry if you missed out getting one of the available boards, just tell me how many you want :-) Update: Now only 4 in stock. Update: Now only 3 in stock. Update: Now only 2 in stock. Update: Now only 1 in stock (as of 1st November 2018). Update: Sold Out ! Another batch has been made, see news above.... Here's some more pics of it fully assembled (I'm still waiting for some more parts to arrive to compete the partially assembled ones)..... Update: They are now all assembled and tested working. 2nd June 2018 The System 32 Trackball Interface PCBs have finally been shipped and should arrive within the next 3 weeks. While I'm waiting, I made another small Eagle project and assembled it today. Tested and it worked first time :-D Anyone who owns a Commodore 64 will know of the constant joystick swapping that is required because some programmers did not know the difference between Port 1 and Port 2 (LOL!!) and games use any random port regardless of the number of players it supports. Great! :-/ But fear not the solution is here! Now no more pissing around swapping joysticks to the other port.... I simply press the little button on top and it switches them instantly so the joystick works no matter which port it is plugged into :-D There are some other similar things out there already but this one has been made as small and unobtrusive as possible on purpose. This one also supports the mouse and switches the analog pins too, so a joystick and mouse can be left connected permanently! Total build price was about $10 :-D 14th May 2018 My System 32 Trackball Interface is finally complete and PCBs have been ordered.... 8th April 2018 (Updated 26th September 2018 with pic #5 of actual part assembed) While I'm on the subject of Taito PCB repairs, here's the next project I've just completed.... This is a reproduction of the Taito TC0070 RGB Module used on many, many Taito PCBs from the 80's and 90's. These were originally made on a ceramic substrate and then covered in black ceramic and often break off or are damaged, or just fail internally. They are the very same things pictured in my Chase HQ repair log Part 3. Some time ago (~2013) 'JROK' reverse-engineered the TC0070RGB module and provided a schematic here. There was a re-made version using PALs which re-produced the logic exactly but it was a bit ugly. Someone else came along and took the JROK design and copied it 1:1, called it their own and sold it for US$65, which is just highway robbery. Need proof? Google has all the answers. eBay has answers too LOL!! Instead of paying through the nose, this can now be made by anyone familiar with the hot end of a soldering iron for $5. The simplified design presented here replicates the same logic and works 100% the same way. This design uses less chips (all common off-the-shelf parts available on eBay etc) and the final result is the same..... 5-bit digital R+G+B input (15-bits total) and standard analog RGB output. The design is based on JROK's reverse-engineered design and the Bubble Bobble bootleg PCB which uses the same kind of 15-bit RGB DAC on the PCB but instead of a flimsy ceramic module, they made the circuit with common logic chips etc and put it on the main PCB. Bryan McPhail helped to trace out the bootleg circuit and I laid out the PCB and routed the tracks using Eagle PCB CAD. You might be thinking (or some leech who sells the US$65 one might be trying to convince you) "it isn't a 1:1 from the original so it can't be good". FYI, all logic chips contain circuits made from resistors, transistors, diodes etc. Any circuit can be made from a number of different chips. There's no hard rule about how things can be done. It's called 'innovation'. Regardless, it works and is free so it doesn't matter whether there are non-believers or not. The smart people will see the light and make it themself. Yes that's right, it's free. I have no plans to sell this, this is purely so people who want to fix their boards can get some PCB's made themselves and fix their own boards cheaply. I have some other future repairs to do to almost-worthless Taito PCBs that would otherwise be scrapped due to the cost of buying a pre-made TC0070 module. Now these can be fixed very, very cheaply using this module, which is 2" x 0.9" (i.e. smaller than the original). The PCB costs $3 (quote from Osh Park... probably $1 from most Chinese PCB manufacturers) and the parts are (depending on where you buy them) around $2 total. Design files (gerbers) are available free on my "Guru's Useful Eagle PCB Designs" page. You make your own at any PCB manufacturer such as Osh Park then solder on $2 in parts and you have your own. Don't get shafted and pay US$40 for a blank PCB or US$65 for an assembled version from somewhere else LOL!!! You will learn something and feel better when you build your own TC0070 module for $5 :-D 2nd April 2018 Let's continue with the Chase HQ repairs, Part 4. If you have not read the previous repair logs, read Part 1 and Part 2 and Part 3 so you can catch up with the current situation. The remaining final issue is there's no sound. Fortunately with this game the sound section isn't too complicated as far as the actual circuit. Most of the complexity lies within the custom Taito TC0140SYT and the YM2610 chips. The first thing I need to do is find a good TC0140SYT and mount that onto the board, since it was blown and I had removed it in Part 1. I have already verified all of the pads on the PCB join to the correct places. I found a chip among a pile of other chips of unknown origin.... While not in the best condition, I've seen a LOT worse so as long as none of the legs are broken or break off when I straighten them, and it's not blown up (hehe!), it should be usable. After about 1 hour of prodding with tweezers and pushing with a stanley knife, and pressing the chip down on a flat surface, then prodding and tweezing and pushing again several times all the legs are straight.... This isn't the actual chip (note the date code is different hehehe!!), I had already re-mounted it on the PCB and forgot to take a pic, but this gives you an idea what it's supposed to look like ;-) Ok so now I just need to put it back on the PCB. There's not a lot to say about this, I just solder it on then clean up with isopropyl alcohol... I powered on and I got this screen.... Great! The sound error is gone! But does it make any sound? Well..... it's trying. On first boot there's the normal speaker click, but it's crackling a bit where it should be silent. When the Chase H.Q. title appears and drops the shadow down, it should make a clunk sound then the music should play. Unfortunately, there's just some bad screeching instead of any kind of correct sound, but it seems to be kind of in time with the correct sounds. The TC0140SYT receives the reset signal and is active on all address/data pins so I suppose that means the TC0140SYT I just re-mounted is ok. The Z80 and EPROM and RAM are active and so is the YM2610. When I coin up the screeching changes to different screeches and some of the pins on the Z80 change so the sound program is definitely running. Maybe the ROMs are suspect? I need to read them, should be a simple two minute job to read four ROMs, right? On the PCB is printed '23C4001E'. I don't know the brand of these ROMs, but the info on the net tells me it's equivalent to a 27C4001 or 27C040. So I read them as that type and got no output, just 00's! I removed another ROM and read it and got the same result. So I repeated with the last two and got the same result. Hmmmm, surely all four ROMs couldn't be bad? I'm not going to worry about that right now, just replace with EPROMs of type 27C4000/27C4001/27C040. I have plenty in stock so I grabbed a handful, erased them and re-programmed them with the correct data. On power-on I still got the same crackling and screeches! The address and data lines on the ROMs are active so for now I'll move on. The next chip to check is the YM2610. It seems to be active, but all of those active pins are inputs coming from either the Z80, the ROMs, the sound RAM or the TC0140SYT custom chip. The only audio output on this chip is the digital audio outputs (SH1 and SH2, the analog output on pin 27 is not connected and unused) and a clock that drives the YM3016-F DAC. The input clock is correct (8MHz) and the output clock is also correct (2.666666MHz). I probed the two digital audio output pins with my logic probe but all I see is a regular high/low flash no matter what sounds are being made. Is it working or not? I got out the scope and probed those two pins again. This is the output of SH1 while in attract mode where it is supposed to be playing music (it's a bit hard to get a clean shot of it)....    and CH2....  There's mainly no change in the waveform except a little 'wiggle' at the top. When the sound isn't playing the waveform looks exactly like SH2. On SH2 the waveform has no change at all even when sound and speech is playing in game. Is it good or is it bad? I don't know what it's supposed to look like since I have no reference waveform. I would have thought the waveform should be a bit more irregular and span the full 0v to 5v range as different sounds are output but only the top wiggles hehe! That little wiggle might be the noise and crackle I'm hearing. Or maybe not. I think I'll try the 'Louis Rossman Repair Method' (search youtube for more info) and just change stuff that looks corroded heheh! The YM2610 certainly looks bad and rusty. But this theory might be on shaky grounds already here in arcade land because if I were to fully apply it, then everything would need to be changed because everything looks bad heheh! Anyway let's pull this sucker and change it and see what happens.... Those little pieces left in the holes are not legs, they are the remains of the plating on the legs, the corrosion lifted the plating and it fell off. After cleaning it all up it looks like this.... While the chip is off the board, I went along every pin hole and beeped out all the connections to where they go. They were all joined so everything is ok. I replaced the chip with another one taken from a junk board, powered on and got exactly the same output, crackling and screeches. Oh well, so much for the 'replace bad looking stuff theory'. That doesn't apply in arcade land, sorry! So moving onto the next chip in line, maybe this is a digital to analog problem. The schem shows the complete path of the audio.... YM2610 --> SH1/SH2 pins 29 & 30 --> YM3016-F pins 7 & 8 --> pins 10 & 11 --> TL074 @IC64 pins 10 & 12 --> pins 8 & 14 --> TL074 @IC65 pins 5 & 12 --> pins 1 & 8 --> Taito TC0060DCA custom pins 2 & 5 --> pins 3 & 4 --> two resistors --> one line output --> volume pot --> MB3735 pin 1 --> pin 8 (+) & pin 5 (-) --> 28-way edge connector pins 10 & 11 --> speaker Here's the relevant circuit on the schems.... I know from past repairs I can probe the TL074 outputs and 'hear' the sound on my logic probe through the built-in piezo speaker. I probed the TL074 output pins and heard nothing. Probing the YM3016-F outputs also gave no sound on the probe and this is the next chip in line after the YM2610. There should be something coming out of the YM3016-F when music is playing, but there's nothing. Maybe that's it! I removed it, cleaned the pads and replaced it with another YM3016-F from a junk board. I anxiously powered on and waited for the start-up tests. There was silence, no crackling. The title showed then the shadow dropped and 'CLUNK!' then the music started playing! Yay!! It's finally fixed!!! I coined up, started a game and Nancy announced we have an emergency(!), so I grounded the accelerator pin on the edge connector and the car took off. It's perfect :-D But we're not done yet! I went back and tested the YM2610 digital outputs with the oscilloscope again and got the same readings, so the waveform above is what the digital out on a working YM2610 looks like. I'm still curious about those ROMs. I removed the EPROMs and put back the original mask ROMs expecting to hear bad sounds, but the sound was still perfect! Hmmm, what's going on with those ROMs? I must investigate, we *still* have an emergency Nancy! I read the ROMs again but still got bad reads. Some research is needed. Here's the relevant datasheet pages for 23C4001 and 27C4001 and my original mask ROM pinout shown on the schem... There's no difference between the first two pinouts, but the original ROM has pin 1 tied to ground. That pin 1 is a no connection on the 23C4001 mask ROM and VPP on the 27C4001 EPROM. On my programmer it pulls pin 1 high by itself when reading it. The datasheet specification for 27C4001 says pin 1 on the EPROM is 'don't care', which means either low or high it will still read it just fine. Whereas the original mask ROM must have that pin tied low to be in read mode, otherwise it goes into power-save mode. I put the original ROM in a socket and read it with pin 1 lifted.... Here's a tip! When doing this do not just put the ROM directly into the EPROM reader and bend pin 1 out at 90 degrees or more because you'll break the leg off the ROM! Put it in a socket and then you can bend it about 20 degrees and the height of the socket allows the pin to clear the EPROM programmer zif socket, then gently bend it back afterwards and the ROM leg will survive. I did another read as 27C4001 and to my surprise the read came back ok and the CRC32 matches the known good ROM dumps in MAME. So it looks like my EPROM programmer just pulls that pin high because there's no hard rule about it and the manufacturer chose to pull it high to 5V. Heheh! You learn something every day ^_^ Here's a summary of what was actually bad: Replaced 10x Toshiba TMM2063 8k x8-bit Static RAMs (bad) with good RAMs, including adding sockets so if they go again it will be easy to fix. Replaced 1x 256k x16-bit mask ROM (bad internal CE or OE) with 27C400 EPROM (IC27) Replaced 1x Taito TC0140SYT custom chip (blown/cooked) with good chip Replaced 1x Yamaha YM3016-F DAC (blown) with good chip Repaired broken/corroded track from PAL at IC52 pin 21 to via with a patch-wire Not In The Log: Re-programmed 1x 27C512 EPROM (IC51).... the dump of the original sound program EPROM didn't match the known good dump in MAME so I re-programmed it. So you're probably wondering how this board got in such bad condition and had so many faults. Did you notice this board-set was a Frankenstein one? The sticker on the top board says "CHASE HQ UP", meaning it's an upright board. The sticker on the bottom board says "CHASE HQ CP" meaning it's for a cockpit board-set. The actual PCBs for any of the different cabs are exactly the same, just the program EPROMs differ. So it looks like some loser had several boards and swapped them around to get one going then sold the remaining non-working boards on ebay as 'untested'. However that's not all bad. Losers like that are part of the lowest end of the food chain, just as a spider needs bugs and other nasties to survive, PCB owners/repairers need PCBs that come from dubious locations with dubious faults sold by untrustworthy losers trying to sell stuff that they know is tested and doesn't work. All pretty common and predictable behaviour LOL! Bonus Log Event: Pissed off the loser ebay seller who sold this as 'untested' hehehe!! BTW, to all the Chase HQ owners out there, if you happen to have a Chase H.Q cockpit or deluxe cab, please dump the EPROMs on the top board and send them to me so they can be preserved in MAME because they are currently not dumped. Or at least it looks like they are not dumped. Maybe there's some additional hardware in the cockpit/deluxe? UPDATE: Yep, there's an extra board in the DX cab. Got dumps of it and documented it. Should be in MAME by the time you read this. Anyway, all problems solved, now we can go catch some criminals! 1st April 2018 Ok, continuing on with the Chase HQ repairs, Part 3. If you have not read Part 1 and Part 2, click here for part 1 and here for part 2 so you can catch up with the current situation. The blurred video issue is the main problem right now. I think if that is solved the game will be fully working other than missing sound (which I'll fix last). Here's some pics of the blur effect. Notice the in-game pic is almost perfect except a blur at the far right side of the screen... The first thing I noticed was the RGB custom was a bit dodgy, hacked up by some loser who doesn't know how to use a soldering iron. Underneath the PCB was some dirty flux crap and it was really nasty. I think now I know what grizzly bear shit looks like.... urgghh! So I removed the RGB custom and some legs fell off. This is a pretty common issue with these ceramic custom SIL packages. I assume it works because the colors are ok, but just in case I'll swap it over with another one I have, which is also missing legs but not as many. Basically just remove the old one and solder in the good one. Before putting the new part in, check ALL the connections to the source and ensure they are all joined. It's *much* easier to check connections while the part is off the board than do it when the new part has been put back. That way if there is a connection issue it can be fixed directly at the track or via without having to add bodge-wires ;-) All the connections from the RGB custom to the color RAM and TC0110PCR custom were ok so I soldered in the exchange part. To replace the missing legs, first just solder in the good legs, taking care to make sure the holes with missing legs stay clean. Ensure the body of the RGB custom is as high as possible to allow working space underneath it. Then get a new resistor or capacitor and cut off the legs about 3/4" long. Tin the pin on the custom with solder and add some flux there too, then poke the wire through the hole from underneath the PCB. While holding it in place, solder it to the remaining RGB custom pin. Repeat for the other legs, then turn the board over and add solder to the hole. Don't put too much heat there otherwise the leg may come unsoldered from the RGB custom. When all the legs are soldered in place, trim off the new legs, clean up with isopropyl alcohol and job done! Did that fix the problem? Unfortunately not, but it's exactly the same so I know the RGB custom is ok. At least now I know the connections are solid :-) The next part in line is the TC0110PCR custom chip. This takes the pixel data from all video sources, merges it and sends it to the RGB custom. So let's change it. There's not much to say about this really, simply remove *the correct way*, clean-up the pads and re-mount another identical known good part. Just check the pics, a picture paints a thousand words, and the picture caption tells the rest ;-) So did that fix the problem? Nope! It's still exactly the same. Anyway, the chip was a bit corroded and the pads looked bad so at least now it's clean and tidy :-) Time to get serious. I first beeped out all the connections from the PCR to where they went. Lots of stuff, but all ok. Then I beeped out all the connections from the next chip in line (the TC0100SCN custom) to where they went. Also lots of stuff, but all ok. Then I went around the PCR and SCN chips with my logic probe looking for suspect signals, but they all looked ok. I unplugged the video board and to my surprise, the CPU board actually starts to boot up. It shows some of the RAM tests then resets. But more importantly, the blur is there even without the video board. That means the fault is definitely on the CPU board. I'm thinking, it looks like the pixels are too bright. Like some voltage is shorting the RGB lines, but all the colors are correct, it's weird! I'll just check the harness to make sure nothing is out of place.... D'oh! I found it. I had originally made a harness for Operation Thunderbolt and fixed that one first last week. I have re-used the harness since the wiring is mainly the same for Chase HQ except the video which comes off a 5 pin connector and I'm not concerned about inputs yet so I don't care where the other wires are. So I left the RGBS wires in place on the 28-way connector and added extra RGBS wires to the 5 pin connector coming off the existing wires on the 28 way connector where the RGBS is for Operation Thunderbolt. I just piggybacked the wires and fed them to a 5 pin connector which plugs into connector V. Obviously a mistake!! I did that mainly so I could leave the harness the same and use it to run both boards to see that they powered up and worked without having to re-wire the harness. I was thinking it wouldn't matter because those pins were just inputs/unused but obviously one of them has some voltage or ground there and was screwing with the video heheh!! OK so I removed those extra wires on the harness and the video is back to normal! :-D WOW! It's April 1st. I think I may have April-Fooled myself! hehe! Note to self: When re-using an old harness, remove all the unused wires hehe! Note the purple Taito logo is actually blue on screen (i.e. correct). For some reason the camera makes it look purple. So now there's just the sound issue to fix and then the Chase HQ board should be fully working. 31st March 2018 Let's continue with the Chase HQ repairs, Part 2. If you have not read Part 1, click here to read that first (posted March 30th 2018) so you can catch up with the current situation. I'll look at the sprite issue now. The problem seems to be that the transparent (outer) section of the sprite isn't fully transparent, there are lines through it. That means data is missing. It's definitely not ROM related since I checked the ROMs and they are all ok. Incidentally, one thing I discovered about the ROMs.... there are some that have an indented line running the full length of the chip, a tell-tale sign they are made by Fujitsu. On the PCB is screened 'MB834100'. I couldn't find the datasheet for this chip but I figured it was like 23C4100 so I read them as 27C4100 with my EPROM programmer and got a bad read so I figured they were bad and replaced them with 27C400 EPROMs. That didn't help and made it much worse! The datasheet for the Fujitsu MB834100 is not easy to find but there is a good quality datasheet in the 1989 Fujitsu MOS Memory Products Databook available at bitsavers.org. After checking it I realised the MB834100 mask ROM is pin-compatible with a 27C4096 EPROM! So I read the mask ROMs again as 27C4096 and got good reads :-) Note to self: MB834100 = 27C4096 Note to self in 2023: MB834100 NOT EQUAL to 27C4096. You need to make an adapter and use 27C400. See my repair log on SCI November 1st 2023 for more info and my MB834100 adapter gerber files and you can make your own adapter for a couple of dollars :-) I got a quick tip-off from Bryan McPhail... yes, the same very talented MAME developer who emulated many games in MAME years ago. The suggestion was to look in the area surrounding IC173/IC174 because that has something to do with the transparency of the sprites, or check the video RAM. This is the relevant section of the schematic.... Personally I didn't think it was the RAM because piggy-backing the RAM has no effect except to make it worse and put wide vertical stripes across the entire screen, but the tip-off was close! I probed about with my logic probe and pin 8 of IC174 (LS260) sounds strange. My logic probe has a piezo speaker inside so I can 'hear' the 1's and 0's... it's very nice.... good data sounds pleasant and rhythmic, but this didn't sound good at all. When I shorted pins 8 and 9 of the LS260 together with my logic probe, by pure luck it fixed the sprite problem 100%!!! Obviously that's not the solution but it shows I'm close. What that actually did was inject the signal from pin 9 into pin 8 because pin 8 has something missing. The actual suspect signal is on pin 8 of the LS260 at IC174. The schems show it as a signal on the FRD BUS called FPO10 or something like that (the schem is the usual poor quality crappy hard to read scan... arrgghh!). Here's a close-up of some of the circuit with the relevant signal highlighted in red.... The schematic shows FPO10 connects to several places..... 74LS260 at IC174 pin 8 (input), 74LS166 at IC153 pin 12 (input), 74LS244 pin 9 at IC130 (output only, all inputs on this chip are grounded), pin 11 (D0) of the 256k VRAM at IC85 and a PAL at IC52 pin 21. All inputs can be ignored because they have no effect on the signal. We need to find some chip that 'creates/outputs' this signal. The schem show the source of the signal is the PAL at IC52 pin 21. There is a bank of eight PALs together in the top left corner of the video board and out of those chips, there's only two different types. Checking PALs with MAME as a reference is not the easiest or quickest thing to do. The PALs in MAME must be converted to .jed files using the JEDUTIL program provided with the MAME distribution. Then the actual PAL is read using an EPROM programmer and compared manually with the MAME-converted .jed file. The reason it has to be manually compared is because the MAME-converted .jed file only shows lines in the fusemap that contain 1's. Any line with all 0's is omitted, so the CRC32 of a MAME-converted PAL .jed and the real read from an EPROM programmer will always be different. Even looking at both of the actual fusemap files will show they are very different, except those lines that contain the same bits. Knowing several of the PALs are the same, rather than go through the hassle of all of that converting and comparing B.S., I simply read the PALs and checked the CRC32 against the other identical PALs. They all matched so the PALs must be ok. There is another way too.... I could swap the PALs to the other location where the same PAL is, but IMO that would not tell me whether the PALs are good or not, especially if there was no difference on the screen. The better way is to just read the PALs and compare them against one of the other identical PALs :-) When I probed the RAM on pin 11 it shows the same strange signal. Luckily on this board the data lines are not connected across multiple RAMs. When data lines are connected across multiple RAMs (for example to create a 16-bit data path from two 8-bit RAMs) it's a nightmare to find the suspect RAM because when probing the RAM you are actually probing two or more pins on multiple RAMs. This is why it's very difficult to repair faults on later arcade games that have 16 or more 8-bit video RAMs tied together to create a large 32-bit chunk of RAM. A classic example is Namco's Point Blank, where sixteen 32k x8-bit static RAMs are tied together on their data lines and address lines. It's a nightmare to find a sprite fault on that board. In that case the only way to find the bad RAM is either remove all of the connected RAMs and test separately or use an oscilloscope and hope something looks different. But even an oscilloscope won't fully help, although it can allow you to narrow it down to less possibly-bad RAMs. I have a nice 80MHz quad-trace dual time-base scope but I'm no expert with it so I skipped that part. Personally I think scopes are over-rated. They have their uses, but not in this case. I already know there's a bad signal but the scope isn't going to help me find it and even if it did show an abnormal waveform, it can't tell me exactly which chip it comes from. That's where the schematics come in handy and why schematics should be scanned at a minimum of 300 DPI, or better 600 DPI. Without a schematic the only way to trace signals is by having a known good reference board or removing parts and using a multi-meter to beep out the connections by visually locating the connections on the board. It's a huge job. The schem pages for Chase HQ were scanned at a measly 72 DPI!! The moron who did it probably looked at the page on a 14" CRT back in about 1992 and saw lines so he thought it was good. He obviously never viewed it full size and tried to read the text. OH MY GOD! It's just barely readable ggggrrrrr!!!! Imagine if I couldn't read the schematic signal labels, it would be useless and the scanning would have been a complete waste of time. It's a big nightmare to find the actual connections when it's unreadable, especially on a bus where all the signals are on the single bus line and they only fan out at the IC pins. Here's a tip for future schematic scanners out there.... scan at 300 DPI or 600 DPI so that your good work becomes useful for repair work rather than a burden. If only everyone had scanned schems at 300/600 DPI, MAME could be even better.... yes that's right, in some cases MAME suffers from lack of info because schems were scanned at a very low resolution and were useless! Anyway, my rant about schem quality is finished. When I short pins 11 and 12 of the VRAM at IC85 (D0+D1) it also fixes the sprite problem. Again, not the solution but shows I'm looking at the right signals. Since D0 is a bi-directional data pin, it can either be input or output. There's no real way to know for sure if the RAM is bad except to remove it and test it either in an external testing device like an EPROM programmer with RAM testing capability, or plug it into another PCB. In my case I keep a set of working PCBs with various parts socketed so I can test parts on the PCB. So I removed the RAM. I plugged it into my test PCB and it was fine, so the RAM isn't bad. I also noticed when there's no sprites on screen that specific pin on the RAM (D0) is still active (regular pulsing) on my logic probe even though all the other data pins on that RAM and all the other VRAMs are quiet, so I guess it's floating or something. There's definitely some signal missing so it's time to get beeping! I know where the D0 signal connects so I probed the FPO10 pins of the connected chips with my logic probe and found the same regular pulsing signal on all of the chips no matter what was on screen. All EXCEPT the PAL. On the PAL (IC52 pin 21) I got a LOT of activity when sprites were on the screen and no activity when no sprites were showing. BINGO!! That PAL was about 12 inches away from the initial bad signal I found so without the schems that fault would never have been found. I set my multimeter to continuity and checked the actual connections on the PCB. All of the chips were connected except the PAL pin 21. I hooked up a mini-clip to pin 21 of the PAL and touched the other end of the cable to the nearest chip with the same FPO10 signal (the 74LS244 pin 9) and that fixed the sprite problem 100%! I looked on the bottom of the video board and the trace from the PAL goes to a via but between them it has 'The Curse Of The Taito Green Mask Turning Black And Rotting The Trace' problem which plagues many Taito PCBs :- ( I don't think there's much point patching the PCB trace with a micro-wire because the track is shot, so I added a wire to join the PAL pin 21 to the via and that restored the sprites back to normal :-D Sprite problem solved! Obviously we're not done yet since there's still more problems so the repair will continue later.... 30th March 2018 Chase HQ repair, Part 1. A couple of Taito PCBs came in for repair a few days ago. The games are Operation Thunderbolt and Chase HQ. Neither PCB was in great condition but they HAD to be saved from the junk pile so I put in an extra special Guru-Effort to make sure they came back to life again! One of the main issues with late 80's and early 90's Taito boards is the RAMs made by Toshiba have failed. Taito PCBs are loaded with them usually. The specific chip is Toshiba TMM2063 (8kx8 Static RAM), and also TMM2018 (2kx8 Static RAM) is another one that fails often. Here's a pic of the nasty TMM2063 culprits.... The Chase HQ board has 10 of these chips on the CPU board and if any of them fail the board will have major problems, most of the time just killing the board dead. In some cases the road or colors will be bad but if it's any of the 68000 program RAMs or the shared RAM the board won't boot. This Chase HQ board showed only a wavey pattern on screen and was resetting very quickly so with this RAM type in mind and knowing they would probably all be bad, I decided to pull and replace the TMM2063 RAMs for the Master 68000 CPU and Shared RAM hoping it would at least boot up to some sort of screen. After doing the main CPU RAM (Taito call this the LOCAL RAM, IC28 & IC35) it was still resetting quickly so I also changed the Shared RAM (Taito call this the COMMON RAM, IC43 & IC44). A change! It was resetting very slowly, about once every 4 seconds, but there was still nothing on the screen. I checked the data and address lines on the 1st 68000 and there was some activity, so the master 68000 was alive! But only for 4 seconds. At this stage I checked the 2nd 68000 reset line to see if it was active and it wasn't.... the reset pin on the 2nd 68000 was still low. I was thinking the 1st 68000 was waiting for the 2nd 68000 to reset, but because it didn't, the 1st 68000 just kept resetting. In reality the 2nd 68000 doesn't reset automatically, it only resets after some of the RAM tests pass then the 1st 68000 sends a command to reset the 2nd 68000. Essentially the reset for the 2nd 68000 is CPU-controlled. Before realising that I started tracing out where the reset for the 2nd 68000 was coming from and thinking maybe I had a logic problem somewhere but when checking the schematics I found a complicated path leading back to the 1st 68000 and a dead end to the theory that the 1st 68000 was waiting for the 2nd 68000 to reset :-/ Time to change tactics! I had previously checked the ROMs and found a bad mask ROM which was connected to the TC0100SCN custom chip, but at that point I had not changed it. Mainly because I figured it wasn't important at this stage since it's not program-related. The mask ROM had absolutely no activity on any data pins and reading it with an EPROM programmer only gave a 0xFF output (i.e. nothing), so it looks like the CE pin (chip enable) or OE pin (output enable) has failed internally. On a whim I took out the bad ROM and put in a random 40 pin EPROM I had lying around and the data pins were active! The screen showed some strange block graphics on screen like perhaps a potential text message!! So I grabbed an EPROM from my stock of parts and of course found it wasn't blank! I popped it into my UV eraser and painstakingly waited about 10 minutes for it to erase. Eventually it was blank so I programmed the AM27C400 EPROM (pinout-compatible with the original 234000 mask ROM) with the correct data, plugged that in and got this screen! It turns out the ROM at IC27 holds the text characters. This message tells me the local RAM (main 68000) and common RAM (shared between both 68000's) is ok and the color RAM is bad. So I replaced the color RAM (IC2 & IC3) and got this screen.... Still something not quite right but it kept going and booted up!!! WHOA!!! The next thing to do is fix the "ROOT MPU RAM ERROR". That's the RAM connected to the 2nd 68000 CPU which is currently not running, just resetting. It should actually be called the 'SUB MPU' but I'm guessing the Japanese person programming it at that time back in 1988 didn't quite understand English properly and put ROOT instead heheh! Anyway, I replaced that RAM (Taito call this the ROOT MPU RAM, IC38 & IC54) and that got rid of the ROOT MPU RAM error and improved the graphics a lot! I also heard the speaker pop and a hum is coming from it now. That suggests the Z80 (sound) program is running because one of the tasks of the 2nd 68000 is to talk to the Z80 and issue sound commands.... one of them is probably a 'wake-up!' command. Still lots of graphical issues! The next step is to replace the road RAM since the road is missing too. That's the RAM at IC22 and IC23. After changing them the road now shows! There's still has some graphical issues relating to sprites and a weird horizontal blur but I'll sort that out later because a quick check of the video board didn't reveal anything obvious. There's a lot of RAM on the video board and it's a time-consuming job to find the (possible) bad RAMs and strangely, piggy-backing the RAMs didn't help, it just made the display much worse. There's also a lot of PROMs and PALs on the video board and all of them run hot. Fortunately all of them are dumped and they are preserved in MAME :-D I checked all the graphic ROMs and they are ok so it looks like it's not going to be so simple to fix the banding and sprite issues. Some more research and schematic reading is needed first. In the meantime, let's move on. I want to address the sound fault and show a technique for removing a dead/blown-up custom quad-flat-pack chip without over-heating the board and damaging or warping it like some idiots do when using a heat gun (check my news 7th January 2017 for a typical example). The sound fault shown on the boot-up screen that still remains could be caused by several things..... bad sound RAM (yet another of those nasty Toshiba RAMs), or bad Z80, or bad Z80 program ROM, or missing clock/reset signals or a multitude of other things including one or more broken connections. However the Z80, sound RAM and sound ROM are active so I doubt any of those are bad. As I was looking in the sound area for a possible fault, I happened to touch the Taito custom chip marked 'TC0140SYT' and I burned my finger! S.O.B!! So that chip is blown and has to go! Normally I would remove a custom chip cleanly using a special temperature-controlled hot air tool without damaging the chip in case it is actually good and then it can be kept and re-used. But in this case I knew the chip was toasted (literally!) so there's no need to save the chip, just get it off without damaging the board. The NUMBER ONE concern in any repair is DO NOT DAMAGE THE PCB!!!! In this case, the PCB isn't in great condition anyway, so we don't want to make it worse. To remove it, start by adding some flux to the chip, then run some fresh solder across all of the legs with a soldering iron using the 'drag soldering' method. There's no need to be neat or worry about solder bridges since the chip is coming off and going into the bin after anyway. Now heat each leg with the soldering iron and lift the legs **ONE AT A TIME, CAREFULLY** using tweezers. Start from the edge and work your way to the other edge. Lift the legs high enough so you can get the tweezers in underneath the next leg then lift it up slowly, making sure the solder is melted BEFORE you lift the leg up. Again, do it slowly and carefully one leg at a time. Here's a pic showing one side lifted.... Go all the way around the chip and eventually it will come off without damaging the PCB pads. When there's about 10-15 legs remaining, heat all of them by putting the soldering iron sideways to heat all of them together (the newly added solder will help with this) then slide the chip away off the pads. If you don't do that, as you lift the last remaining legs the chip will move and could tear the remaining pads off the board. You could put a weight on top of the chip to hold it but it's just easier to heat the last 10-15 legs in one go and then slide the chip off while the solder is molten. Just remember, when you do it this way the chip is scrap, so only do it like this if you know the chip is dead! Now clean up the PCB pads with some wick and isopropyl alcohol and it will look pretty good. But it's not quite Guru-Worthy yet.... notice around pins 60 and 90 there's some corrosion on the pads. As I said, the board wasn't in great condition and there's some corrosion crap on the pads. That can be fixed easily. Scrape off the crap with a small flat-bladed screwdriver or a knife **CAREFULLY** to expose the copper trace underneath. We're not mining for iron ore here, do it very very gently and carefully! Problem solved right? No, the pads need to be re-tinned. There's a really easy way to do that. Add flux and then use old wick containing old solder and with the soldering iron, rub the wick on the copper pads. The solder will come off the wick and stick to the pads. After cleaning up with isopropyl alcohol again, now it's Guru-Worthy! The next step is to simply find another TC0140SYT chip on a junk Taito PCB and transplant it and hopefully that fixes the sound fault. But it's late now so that's a job for another day :-) Here's a summary of the various RAMs and their locations..... Note the 'Road RAM' and the 'Sound RAM' isn't tested. On the video board, the Object RAM is the two 2018 static RAMs at IC185 and IC186. The large bank of 256k static RAMs isn't tested either. They are for the sprites. 29th March 2018 Some more of my To-Be-Decapped chips have been decapped by CAPS0ff. The Mega Blast C-Chip was dumped, so now all of the Taito C-Chips have been successfully dumped! It has also been marked green on my Decapping Status Page Please support CAPS0ff with funds if you can so more chips can be decapped. 12th March 2018 Some more of my To-Be-Decapped chips have been decapped by CAPS0ff. This time we have almost all of the Taito C-Chips (#73, #189, #232 & #236). I'm not sure what happened to the C-Chip for Megablast (#231), which is also listed in my decap list as 'sent', but there is no mention of it by CAPS0ff. The Megablast C-Chip is a special case because the game only checks for the chip being plugged into the board and after that ignores it, so a decap of it isn't so important.... it's more of a curiosity thing ;-) Anyway, these new dumps will help with MAME's emulation of various nice Taito games from the late 80's and will be available in the next MAME release at the end of this month. In case you didn't realize there is a new MAME released at the end of every month. Those newly decapped chips have also been marked green on my Decapping Status Page There's more news and pics of the decapped chips on the CAPS0ff blog. Please support CAPS0ff with funds if you can so more chips can be decapped. 27th January 2018 A few months ago I added a page here with info about converting any Sega System 32 board to run Sonic The Hedgehog. I did not announce it here but many people noticed it ;-) That page has been updated with decrypted ROMs for ALL of the System 32 games that use a FD1149 so now all System 32 games can live once again! Click here to jump to the page, or click on the top menu 'Guru Misc' and select the Sega System 32 link. Enjoy! 26th January 2018 If you have been following MAME progress you will have seen a recent addition of the TV Boy II. This is a rip-off of the Atari 2600 and not to be confused with the Japanese TV Boy made by Gakken. I happen to have an original boxed Japanese TV Boy here. Although not related to the recent MAME addition I thought since it is quite rare this would be a good time to showcase what's inside since that information is mostly guessed or unknown. Unfortunately there are no dumpable parts inside. Inside is 6 logic chips, a 7805 voltage regulator, a MC6847 video controller, a 6116 (2kx8 SRAM), a MC1372 modulator chip and a 3.579545MHz XTAL. So now you know why it has not been dumped..... there's nothing in there to dump. I don't have any carts, but I assume it contains a 6801 which has 2k ROM and 128 bytes of RAM. It was common to see a micro-controller in a cart with the game code built-in in some other early game consoles of that era too. The 6801 datasheet says it's pin and electrically compatible with the 68701 microcontroller so there may be hope to dump the 6801 as a 68701 if carts were available.... Anyway, here's some pics of the PCB....