Showing posts with label soldering. Show all posts
Showing posts with label soldering. Show all posts

Tuesday, July 13, 2021

Finding solder bridge using thermal camera

I had a Dexter with the RESET and DIAGNOSE lines tied together somewhere.  I suspected a solder bridge but I couldn't find it.  So I decided to send some current through RESET and DIAGNOSE and get out my thermal camera to see where things were getting hot.  Here's what I saw:

I eventually found the bridge, but was not in the most intense place on the PCB:


In the future, instead of looking for the most intense spot on the PCB, I should observe the path that the heat is traveling.  The fact that the heat was traveling down and left of where I was applying power was a clue that I would find the bridge somewhere along that path.

Monday, November 16, 2020

Esh's Aurunmilla sync PROM replacement! (with CPLD!)

 Esh's Aurunmilla uses two PROMs to generate video sync.  Unfortunately, these two PROMs are obsolete and the ones I was able to find tend to overheat so are unsuitable for cabinet use.  Fortunately, Xilinx makes a pretty nifty Complex Programmable Logic Device (CPLD) that should be able to replace both PROMs nicely!


Monday, May 25, 2020

Re-purposing a blank Dexter PCB!

I had a few blank Dexter PCBs lying around.  I got this great idea to use it as an LD-V1000 tester!  (ie, it plugs into a real Dexter unit in LD-V1000 mode and sends LD-V1000 commands as if it was a game)


Nintendo Switch Controller Repair

Here's something you don't see on my blog very often!



If anyone is curious, my favorite Switch games are Overcooked 1 and 2 (which are also available on other platforms).

Monday, July 29, 2019

How I created my MAME cab

Greetings all,

I have eight arcade game cabinets.  My wife informed me that I had reached my limit.  So in order to have more games, I needed to break down and build a MAME cab (which I hope will evolve into a MAME/Daphne cab in the future).

For whatever reason, the look of the monitor was really important to me.  So I found an existing 25" CRT monitor installed inside of a D&D "Tower of Doom" cab that had a control panel with a ton of buttons on it.  Not only did I like this game, but having 4 joysticks with 4 buttons each was what I needed for a good MAME experience.  The monitor had been tube swapped and recapped so was looking great.  So I brought it home and began working on it to MAME-ize it.

Another important factor for me was to be able to run JAMMA games inside of it in the future if I chose, so I didn't want to mess with the JAMMA harness or the extra kick harness (which was configured for D&D Tower of Doom).

Here are the links that I used for research:
https://ryanfb.github.io/etc/2017/11/11/converting_a_jamma_arcade_cabinet_for_mame.html
https://wiki.arcadeotaku.com/w/Kick_Harness#CPS2_-_3.2F4_Player_Harness
http://bencao74.blogspot.com/2017/05/retropie-15khz-crt-tutorial-for.html
https://www.retrorgb.com/rpi240p.html
https://choccyhobnob.com/compiling-mame-on-raspberry-pi/

I purchased a JPAC and an IPAC4 (which I probably didn't need) in order to get full inputs.  In hindsight, I probably could've got an IPAC2 (or whatever it's called) since I only needed to wire up controls for players 3 and 4.  However, despite the IPAC4 being overkill, it also made setup easier because I didn't need to remap the player 3 and player 4 inputs.




I also purchased a gert666 adapter and the latest Raspberry Pi (3b+ at the time of this writing, the 4 is still hard to obtain).  UPDATE: I can confirm that these instructions do NOT work on the Raspberry Pi 4.



The power supply for your Pi is important.  You can't just get any generic one (I got burned by this) or the voltage to the pi will drop at random spots and your games will go into slow motion mode randomly.  I can confirm that this power supply works well for my Raspberry Pi 3b+.

For audio, I went with this amp which may not have been the best choice because it's a stereo amp and JAMMA cabs are only mono.  I also added this 3.5mm to RCA and this ground loop isolator which was very necessary to reduce unwanted buzz/hum.  I still get some minor hum through my speakers, so I don't really know if my audio choice is to blame or not, but it mostly works and I don't notice the hum while playing games.  I powered the amp through the existing 12V line on the JAMMA power supply that came with the cab.  Not sure if this was the best choice.  I've got a lot to learn about analog audio.


To hook up players 3 and players 4, I referred to the kick harness section for D&D at this link.  I wired up my own connector to match what is on the D&D board, and secured the wires with heat shrink and a glue gun.  Now I feel safe that this thing isn't going to come loose, and if I ever acquire a real D&D JAMMA, I can plug it in and play without any other configuration.



Configuring the software for the Pi was probably the hardest part.

I installed the latest Raspbian ("Buster" at the time of this writing), enabled SSH/Wifi and disabled video overscan.

I tried RetroPi but was unsatisfied with the old version of MAME they included and the way they force input mapping.  So I decided to build the latest MAME from scratch instead.

At the time of this writing, the latest MAME version is 0.211 .

There are a few problems with building this version of MAME on the Pi but I was able to work around them:

  1. Uncomment "NOWERROR = 1" to not fail on warnings
  2. Uncomment "NO_USE_XINPUT = 1"
  3. Uncomment "NO_USE_XINPUT_WII_LIGHTGUN_HACK = 1"
Follow the build instructions here.   When building SDL, you only need to build SDL and SDL_ttf, not the rest of the optional libraries.  In order to build SDL_ttf, use at least v2.0.15 or else you will get errors about a missing freetype-config script.

I tried for several days to get cross-compiling working for MAME but eventually gave up and just followed choccyhobnob's instructions.  Building MAME on the Pi 3 takes forever (like 24-36 hours, literally).  I concluded that letting your pi churn away this long is probably still faster than messing around with cross compilation, so I'd just plan on waiting this long.

NOTE that you need to add "-video accel" to the mame command line to enable the hardware acceleration.  It seems to default to unaccelerated software mode which is too slow.


Once I had the software ready to go, I added this to /boot/config.txt to make the video output 15 khz 320x240 :

# MPO
disable_audio_dither=1
dtparam=audio=on
dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
audio_pwm_mode = 2
hdmi_timings=320 1 16 30 34 240 1 2 3 22 0 0 0 60 0 6400000 1 #240p

I then plugged the gert666 VGA adapter onto the pi, plugged its VGA output into the JPAC VGA input, then plugged the JPAC into the JAMMA harness.  I powered on the cab and got a nice big boot screen.



Running MAME in this res is problematic because it will downscale some games (like Capcom's 384x224) which looks pretty crappy.

I found a neat solution to this problem here.

By running games at 1600x240 or 1600x224 and turning off bilinear filtering, the display looks pretty dang good and you don't need to mess around with a ton of different configs (such as 320x224 or 384x224).  Besides, I couldn't get 384x224 to work on my monitor anyway, so I had to use 1600x224.

I created a few scripts to launch games at the proper resolution.  I haven't yet tried to setup a frontend because I've been trying to get the games looking great first.

My script (to_224.sh) to convert display to 1600x224:

#!/bin/bash

vcgencmd hdmi_timings 1600 1 70 150 215 224 1 10 14 16 0 0 0 60 0 32000000 1
fbset -depth 8 && fbset -depth 16 -xres 1600 -yres 224

My script (to_240.sh) to convert display to 1600x240:

#!/bin/bash

vcgencmd hdmi_timings 1600 1 70 150 215 240 1 4 3 15 0 0 0 60 0 32000000 1
fbset -depth 8 && fbset -depth 16 -xres 1600 -yres 240

My script to convert back to 320x240:

#!/bin/bash

vcgencmd hdmi_timings 320 1 16 30 34 240 1 2 3 22 0 0 0 60 0 6400000 1
fbset -depth 8 && fbset -depth 16 -xres 320 -yres 240

My script to launch Rastan (320x240) :

#!/bin/bash

./to_240.sh
cd code/mame
./mame rastan -video accel -noka -nofilter



My script to launch Golden Axe (320x224):

#!/bin/bash

./to_224.sh
cd code/mame
./mame goldnaxe -video accel -noka -nofilter



My script to launch Teenage Mutant Ninja Turtles (224 lines) :

#!/bin/bash

./to_224.sh
cd code/mame
./mame tmnt -video accel -noka -nofilter



My script to launch D&D Tower of Doom (384x224):

#!/bin/bash

./to_224.sh
cd code/mame
./mame ddtod -video accel -noka -nofilter




You get the idea.

Adding -noka tells MAME to fill the whole screen.  -nofilter tells MAME to disable bilinear filtering to give it that authentic CRT look.  The 1600 pixel width is enough so that the nearest neighbor scaling isn't noticeable (at least to my eyes).

Performance is very good all things considered.  All of the games I mentioned play at full speed except during some busy parts of the game.  Rastan looks especially good.  You'd never know that you weren't playing on the original JAMMA board.

I hope this helps someone :)

PS - You may notice black bars above and below my display.  This is due to the way I've adjusted the monitor pots.  There is some problems with the monitor when certain bright colors are displayed at the top and I decided I'd rather have the black bars rather than have to see the problems.  I don't think this is an issue with my Pi/JPAC config.

Nov 2020 Update:

I tried to go through these instructions again and found a few things I missed.  To setup wifi for a hidden network, follow the instructions you will find online but in your /etc/wpa_supplicant/wpa_supplicat.conf file, be sure to add "scan_ssid=1" or it will not find the hidden network!

To make wifi restart:

sudo wpa_cli -i wlan0 reconfigure

To make game(s) autostart:

Inside /etc/rc.local, add:

# MPO
cd /home/pi
exec ./game_loop.sh

Create a script at /home/pi/game_loop.sh with this:

#!/bin/bash

while :
do
        ./tmnt.sh
        sleep 1
        ./goldnaxe.sh
        sleep 1
done

Hope that helps!

Monday, February 11, 2019

Added a new molex connector to my Electrohome G07

Someone had cut off the original molex power connector for this G07.  I studied the connector for another G07 that I have in my Dragon's Lair and found what I believe is a compatible replacement.

A small victory, but at least it was a mini project completed.


Wednesday, November 28, 2018

My first Apple IIgs hardware fix

So when I was a kid, my dad bought an Apple IIgs for Christmas of 1986 and I loved that thing and used it until I finally gave up around 1993 and moved to a MS-DOS 486.

I still have this original machine and it's a ROM 01 machine which means it may have more game compatibility.  Apple also released a ROM 03 version which is newer, has more memory, but may not play every game that the ROM 01 could.  I decided to purchase a ROM 03 a year or so ago so that if my siblings ever came and demanded the ROM 01 family machine back, I'd still have a IIgs that I could call my own :)

Well, the ROM 03 IIgs came and I left it in a box for many months.  Finally, last Father's Day, I opened it and tried to show my kids some games.  That's when I discovered that it had a sound problem!

Fast forward to a week ago.  An accelerator board and a power supply replacement that I paid for literally 7 months ago finally showed up and I was eager to install it in my ROM 03.  But I decided that I really wanted to fix the sound problem before messing with the accelerator.

So I did some basic troubleshooting and this stuff was happening:



My first attempt to fix the problem was to simply de-solder the sound chip and socket it.



I've done this sort of thing several times on arcade PCBs so not only was I familiar with how to do it, but I already had a de-soldering gun along with several 40 pin sockets so I didn't have to wait for any parts to arrive.

Unfortunately, it did not fix my problem.

I wanted to replace the sound chip, but didn't want to destroy a working Apple IIgs.  Fortunately, someone was selling a "battery acid destroyed" IIgs motherboard on ebay, so I got it for fairly cheap.

The acid damage was really bad but it looked like the sound chip was still okay, so I desoldered it.


I plugged the replacement sound chip into my ROM 03 IIgs ...


and fired up the self-test...



Wow!  Despite thinking that replacing the sound chip would likely fix the problem, I was still a bit giddy to see that it actually worked! :)

I fired up a game to test the sound ...


and everything sounds great!

I'm one happy camper.

Now... to install that accelerator board... :)

Sunday, June 3, 2018

Star Rider NTSC board cap kit

The Star Rider NTSC board doesn't seem that great.  I thought that perhaps I could get some better image quality out of it if I replaced the capacitors.  I do so in this video.  Frankly, I'm not sure if it's worth it, but I am going to document the parts that I used for posterity just in case.



Schematic symbol Manufacturer Product part Description
C001,C205,C207,C208 Nichicon UKL1V100KDDANA 10uF, 25V radial, 'low leak' (replaces two axials on original board)
C102, C405 Nichicon UKL1E470KEDANA 47uF, 25V
C209,C800,C801 Nichicon UKL1C471KPD 470uF, 16V
C701, C601 ? ? 1uF, 50V; I missed these and didn't replace these, just adding it here for future reference

Thursday, April 5, 2018

Yet another Star Rider repair


Would you use ice to find a troublesome part on a large board with a lot of generic TTL ICs?  Wise people wouldn't.  I may not be a wise person.

Saturday, November 18, 2017

Star Rider repair video (Ed Beeler's second CPU board!)

Here's another Star Rider CPU repair video.  This was a very challenging problem to solve!



FALSE ASSUMPTIONS ABOUT CAUSE OF PROBLEM:
-----------------------------------------
- turning on board while it was wet damaged something
- cpu was bad
- rom was bad
- 74LS245 was bad
- an unknown malfunctioning component on the board was interfering with the data bus

ACTUAL CAUSES OF PROBLEMS:
------------------------
- CPU RAM was bad (first problem)
- Two traces on the PCB were broken, causing corruption on both the data bus and address bus. (second problem)

Tuesday, September 12, 2017

Finding a short circuit on a Dexter PCB

One of the Dexter PCBs that I was preparing to ship out to customers had a short circuit on it.  After using a multimeter to isolate the approximate area that had the short (by observing voltage drop), I could not find any soldering problems.  So I used a FLIR C2 infrared camera to help me.  After cranking up the current through the VCC power pin to 4 amps to force the short to get hot, here is what the infrared camera was showing (bright yellow is hottest local area):


This is hard to tell what's going on from this blurry image so I've also included a computer generated image with the hot areas high-lighted.


I have now successfully located where the short is by cutting a few traces (I got it wrong the first time, got it right the second time).  Can you do better than I and figure out where the short is without "cutting any traces"?  Hint, the area that is getting hot is supposed to be just VCC (without a connection to ground).  Hint #2, the voltage had dropped substantially on the resistor pad just above the letter 'C' (in CPC1008N) and had dropped to almost 0 on the pad below the 'O' in DIAGNOSE.

Tuesday, February 21, 2017

Star Rider : Playing a 1984 piece of hardware with an xbox 360 wireless controller?


It started innocently enough... the 'DISC SEARCH' test wasn't working and I wanted to fix this.  Eventually, I ended up creating a custom PCB in conjunction with an xbox 360 wireless controller just to get the dang test working :)

I use a (IMO) very cool troubleshooting technique involving the ROM program disassembly and a logic analyzer to track the issue down.

Saturday, February 4, 2017

Fixing Steve Bower's PIF board



I made a new 25 minute video showing me troubleshooting and eventually fixing a problem with Steve Bower's Star Rider PIF board, after going down several wrong paths.

This hardware is incredibly difficult to keep running :)

Saturday, January 21, 2017

Everything I ever wanted to know about the Apple IIgs RGB monitor signals

My favorite 80's computer by far is the Apple IIgs.  I had this machine as a kid growing up and thought it was awesome.  I think I was even more stubbornly loyal because so many of my peers refused to give it the respect that it deserved.

Well, the Apple IIgs stock RGB monitor is intriguing to me because it is relatively small and I do a lot of work with arcade game PCBs in a bench type setting.  I have a need of a nice compact RGB monitor for testing and so if I can somehow use the Apple IIgs monitor for this purpose, that would be awesome.

I asked a question on Facebook about the Apple IIgs RGB signals and got no response.  Either no one knew the answer or no one knew why I possibly would want to know. :)

Never one to rely on other people to achieve my goals, I decided to take matters into my own hands and created a little break-out PCB so that I could 'sniff' the RGB signals myself and get my own answers.

The first step was to whip up the schematic in Eagle:


I whipped this up as fast as possible because I knew that I would only need this board once and then probably would never use it again.

I spent an equally short amount of time on the PCB layout:


This was a mistake to rush through this, but not a fatal one.

On a recommendation from a friend, I decided to use pcbway.com to make the PCB.  To my shock, I had the PCB in my hands in only 7 days after placing the order.  And it was from China!!  Only cost me $10 for 10 boards (why buy one when you can get ten? lol) and $20 for shipping which is a steal in my book.  Awesome!


After ordering the rest of the parts I needed from digikey.com, I whipped out my soldering iron and got to work.

It was then that I realized my mistake.  I wasn't paying close attention to the DB15 datasheet and ended up having the two connectors facing INWARD instead of outward.  That simply was not going to work!!!

Not to be defeated, I decided to solder on wires and hack the thing together enough to do what I wanted.




I plugged it in ...

and turned on my IIgs ...


it was working!! WOOHOO!!!

Once I got this far, I decided to hook up my Rigol scope to the CSYNC and BLUE signals to see what kind of voltage levels I was getting.


I decided to use a nice nearly solid blue screen so that I could see what the full blue intensity would be.

First I wanted to see what vsync looked like:
Interestingly, the blue signal seems to also contain sync information.  I really don't understand why they would do this and I strongly suspect that this monitor will probably work without the sync info being part of the color voltages.  But I guess I'll find out.  At any rate, I observed that the sync was a fairly typical negative composite sync signal going from 0-5V with hsync being mixed with vsync.  I've seen it both ways where the vsync is a solid low pulse and where vsync has hsync mixed in with it.  This is, I believe, what the jamma csync looks like (or is pretty close at least).

Next was to see what the voltage range of the blue signal was by going to a random line in the middle of the field/frame:

 It looked like the voltage was going from 0-1V.  I'm glad I checked this because I would've assumed it would've been from 0-5V.  If I do rig up arcade PCBs to talk to this monitor, I'll probably need to drop the voltage down to avoid damaging stuff.

Next I wanted to zoom in on an hsync pulse and see how wide it was:


Nothing earth-shattering here.  Just wanted to document it :)

Just to be sure I was seeing what I thought I was seeing, I decided to switch the screen to a black background with blue border:



This is what I was expecting.  By zooming in a single line, I was expecting to see 1V near the beginning of the line, followed by a drop in voltage to indicate black, followed by 1V again toward the end of the line, and that's exactly what I am seeing here.  Interestingly enough, black seems to be around 0.3V, not 0V.  It seems that 0V is reserved for sync signals.  This is pretty similar to how NTSC composite works.

Again, I suspect that it is not necessary for the sync signals to be part of the blue signal, but maybe I'm wrong.  Why would Apple go to the trouble of including it if they didn't have to?  Maybe it was part of the RGB encoder they used. *shrug*

The last thing I wanted to document was whether this signal had fields like an NTSC signal.  The NTSC signal's vsync pulse is slightly different depending on whether it is a top or bottom field.  I wanted to see whether this RGB sync had the same kind of characteristics.

Using a scope was probably not the best way since I didn't have a good way to trigger on vsync.  Therefore, I switched to using my Saleae logic analyzer to measure distance between vsync pulses:


Here's a logic analyzer capture zoomed in on a vsync pulse.  It looks similar to what it looked like on the scope except more well defined :)

Zooming out, I was able to put time markers on each vsync to see the intervals:


As you can see, the interval between each vsync pulses is "exactly" 16.689 ms with no variation.  This means that it is a ~60 Hz signal but that it not like NTSC composite where top and bottom field vary.  However, I am not sure what it _does_ mean :)  I don't  have a lot of experience with progressive signals, but if I were to guess, I'd say that this is a progressive signal and that the entire frame is being sent 60 times per second.  The hsync pulses were similar to NTSC (63.5uS apart) so I'd guess that this means that this signal is describing 525/2 lines just like NTSC (~262.5ish but without the decimal since it's progressive).  That would kinda make sense since the IIgs can display 200 vertical lines and it has this extra border on the top and bottom.  But I'm kinda just speculating at this point.

At any rate, I've concluded that in order to get this monitor to work with arcade games, I'm going to need to do a few things:

a) if arcade game has separate positive vsync and hsync, I'm going to need something like an xnor gate to combine them.  Otherwise if it's just a jamma csync signal, I may be able to use it unmodified.
b) if arcade game RGB voltages are 0-5V, I'll probably have to add some resistors to drop the voltage down to 0-1V.  This may be something that I play around with until I find values I like.

I hope you enjoyed my journey.

Friday, November 25, 2016

Fixing a Dexter board with a short circuit problem

I had never had to track down a short circuit this difficult before. I guess I am somewhat of a newbie in this area.

 
I had eight Dexter boards with a common problem. I filmed some videos of the steps I took to diagnose and solve the problem for those interested.

Tuesday, November 8, 2016

I made four Cliff Hanger VMB PCBs

I've been slowly acquiring Cliff Hanger hardware for research and had trouble getting my hands on the VMB board.  So I borrowed one and then cloned it:

Hopefully, I can get some time soon to solder the parts onto it so it can be tested.

Friday, April 22, 2016

Dexter boards are here! (video)

Here's more video than you ever wanted to see about me opening up (and soldering) the Dexter boards that just arrived.