Friday, March 18, 2022

Cobra Command wouldn't boot

I've been trying to get my Cobra Command boardset (Bega's Battle conversion) up and running.  I have no official wiring harness, so I've been making my own wiring + PCB adapters, including power, serial, and RGB video.  When I tried powering up Cobra Command and plugging it into Dexter I got nothing.

So I did what anyone who loves tedious troubleshooting work would do.  I sniffed the 6502 CPU to see where the program was getting stuck.

I found that the program was looping endlessly at a subroutine at 0xE176:

But I wanted to know what was calling this subroutine.  Through some clever triggering, I was able to narrow it down to this area of code:

So basically, the game is sending the "clear all" command to the laserdisc player and blocking indefinitely until it gets a response (which may never happen).

Conclusion?  Serial I/O isn't making it from the game to Dexter.

After some more poking around, the answer ended up being quite simple.

The game is communicating at 1200 bps!  I've never seen a game communicate this slowly to the laserdisc player!

I was getting tripped up because I was assuming 9600 bps and even after staring at the logic analyzer capture and seeing traffic, my brain just didn't make the connection that maybe everything on the game PCB was working correctly and I just was assuming the incorrect clock rate!

Saturday, November 20, 2021

My Dragon's Lair 2's RAM wasn't working. Here's how I [finally] discovered the problem!

I've had a DL2 boardset for a few years but have never tried to power it on.  I also did not have a harness for it.  Well, recently I decided to try to get it running.  After making a power harness and a speaker harness, and burning a v3.19 EPROM, it was time to give it a shot!

Well, after powering it on, nothing happened.  Three LEDs lit up, but there were no beeps and no I/O on the serial port that I could see.  Ugh.  After scanning some forums, I determined that the most common problem with getting DL2 working was the null modem adapter (it is non-standard).  I studied the schematics and owners manual and determined that this was likely not my problem.

As I was basically blind, I decided to do what anyone would do who is a glutton for punishment: to sniff the pins of the CPU to see where it was getting stuck (or if it was even working).

The CPU type is 8088 which I was very unfamiliar with.  I mean, I knew the assembly language command set quite well, but knowing what the actual pins on the CPU did, I was in the dark.

I pulled up the datasheet and was kinda mortified about how convoluted this CPU's design is.  Unlike other 8-bit CPUs of the era (Z80, 6809), this 8088 CPU can address 1M of addressing space (instead of 64k) which you'd think would be a good thing.  But unfortunately, to cram this functionality into 40 pins, they share the address lines with the data bus and some status bits.  This makes decoding the CPU quite a challenge and often requires a separate IC near the CPU to present a normal address and data bus for the rest of the system.  I am frankly a little shocked that intel won the CPU wars of the 80's as a result of this.

In order to make parsing a logic analyzer capture of the CPU more convenient, I needed to sniff a pin of said separate IC to make my life easier.  This pin is called the ALE (hehe) pin, or Address Latch Enabled.  Studying a hard-to-read schematic of the DL2 PCB, I was barely able to make this out on some empty pins that the DL2 PCB designers had kindly added to the PCB to make troubleshooting easier.  (Had they not done this, I would've had to figure out a way to attach to a 100 pin surface mount part.  Not my idea of fun!)

Here is the wire I soldered onto this pin in order to attach the logic analyzer pin.

I then used a 40-pin clip to attach my logic analyzer to the CPU itself.

After sniffing some random traffic, I noticed that the program flow was not leaving the "BIOS" section of the ROM.  I also noticed that the ROM seemed to be executing blank code or getting lost and branching/jumping to invalid code.

At this point, I was completely confused.  I disassembled the ROM in IDA and started setting triggers on the logic analyzer to see if program execution got to certain parts of the code.  This turned out to be much easier than just brute-forcing my way through arbitrary captured data.

Eventually, I narrowed my search down to this harmless looking subroutine.

It actually is the first subroutine that gets called after the ROM boots up (not a coincidence!).

Here's my logic analyzer capture of the 'retn' instruction (address 0xFE54F).

Here's my explanation of each numbered section in the screenshot:

  1. Status of 4 means this an instruction fetch is about to take place.
  2. 0xFE54F is the address of the instruction to be fetched.
  3. 0xC3 is the fetched instruction (0xC3 is the RETN instruction).
  4. Status of 5 means that this is a memory read.
  5. 0x0FFF6 is the address to read from (it should map to RAM).  This is reading from the stack to get the subroutine's return address.
  6. This is the data that the RAM returns.  But wait!  This isn't right.  It's giving us the same value in the lower byte as the address (0xF6).  The changes of this being the correct value are extremely unlikely.
  7. Status of 5 means that another memory read is about to take place (the other byte of the return address).
  8. 0x0FFF7 is the address to read from.  To get the return address's other byte. (wow, the 8088 was really messed up.  16-bit return addresses but the CPU supports a 20-address bus?  Who designed this thing? haha)
  9. This is the data that the RAM returns.  But again, this isn't right!  It's giving us the same value that was already on the address lines (0xF7).  In other words, nothing is driving these address lines!
And sure enough, the new CPU address is now 0xFF7F6 (ie completely wrong):

Conclusion?  RAM is either bad, not being controlled correctly, or missing entirely.

At this point, I decided to inspect the DL2 PCB a little closer.

What the heck?  Some empty sockets where RAM is supposed to be installed?

People who own the game tell me that this is normal.  So I haven't completely solved the problem yet.  But I'm getting closer.

UPDATE: I can confirm that pin 16 on the RAM chips (Output Enable) is stuck high.

UPDATE: Looks like the problem may be pin 10 of "RP3" not making good contact with pin 59 ("CAS'") of U1, this 100-pin surface mount chip!  That pin eventually is what drives the RAM's "Output Enable" to actually pulse.

UPDATE: I decided to reflow the surface mount pins and that actually fixed the problem!  I can't believe it!  I would've never figured this out with schematics, a logic analyzer, and a logic probe!

Saturday, October 9, 2021

Domesday Duplicator Gain Settings for specific laserdisc players

For the Domesday Duplicator gain setting, here are some values I've discovered through trial and error.


NOTE: The first number is switch 1 (so 1000 means switch 1 is on, the rest are off)


    1000    (8.5 gain)



  • 0100 (6 gain if the disc isn't full length; will cause slight clipping at the end of a full length disc) 
  • 0010 (4.4 gain if the disc is full length) 


Switch 1: R406, 1.5k
Switch 2: R407, 1k
Switch 3: R408, 680
Switch 4: R409, 560

Some values just for clarity:

Thursday, September 2, 2021

Freedom Fighter information from David Riordan, one of the creators!

 Last night, Brendon Zeidler and I had a chance to have a Zoom call with David Riordan, one of the creators of the laserdisc arcade game Freedom Fighter.  The call was recorded, but I am not sure if it will be published so I am recording some notes from memory so that I don't forget.

The lead (only?) programmer of the game was Dick Huston.

The reason the prototype units were made from converted Star Rider hardware was that Millennium Games purchased old unused Star Rider hardware from Williams under the understanding that about 150 working units would be provided.  In the end, less, maybe 50, units ended up working from that batch.

The modifications to the Star Rider hardware were done by an employee from Los Angeles who was better with electronics than with people.  He also was responsible for designing the custom PIF board that replaces Star Rider's PIF board.  David did not get along with this individual.

The Philips 22VP931 laserdisc player was chosen because of its amazing skipping ability without dropping video.  Philips offered to sell their remaining batch of these players, but would not provide support in case something went wrong (which I found shocking).  Philips also said it would not make any more of these players which meant that Freedom Fighter could have never been scaled up to mass production.  I have still not been able to find any official documentation on how to control these players and don't expect to.

The joystick for the game was custom made.  (Matt's notes follow in this paragraph) It relied on using Star Rider's existing inputs, which included the steering handlebar inputs for left/right movement and the acceleration throttle for up/down. Inputs unused by Star Rider, such as start1/start2, were used for fire and perhaps something else.

The laserdisc video that was split up into very short segments was created by a high-end machine made by Ampex.  The machine was programmed (by a human) ahead of time and fed film reels of the unedited footage and it will chop the film up according to the program.  The film was then reassembled to create the master that was used to manufacture the disc.  (Matt's note: I may have misunderstood this process so my description may not be entirely accurate)

Millennium Games was a company formed by Malibu who owned 30-40 major entertainment venues across the country.  Therefore, Freedom Fighter was a Malibu exclusive title.

Probably less than 50 prototype units were ever produced.

Steven Spielberg was a huge fan of the game and had one in his office at Amblin Entertainment in the 80's.

The animation to Freedom Fighter was done by a Japanese company called TOEI who had made a movie called Galaxy Express 999 and wanted to see their work featured in a video game.  Therefore, they were willing to work for very cheap to create the additional animation needed for the game.  Apparently 90% of the video in Freedom Fighter was created by scratch for this purpose.  On the disc if you can see the main character, it may have been movie footage.  If you are seeing through the main character's eyes, it was new content created specifically for the game.  Voices done for the game were done by Millennium Games.

The attract mode, including the saxophone music, was envisioned by Millennium Games, not TOEI.

The name, Freedom Fighter, was chosen since the alternative, 999, would be too confusing for audiences.

When the game worked, it was a big hit with crowds.  As expected, the laserdisc players tended to fail (due to dust problems) and this spelled the doom of the game from have a longer lifespan.

Friday, August 6, 2021

DEXTER Data line 6 of 7 was being held high

 This is a note to myself in case I ever have to troubleshoot this problem again.

On a Dexter board I was testing, I noticed that one of the data bits was stuck high.  After some non-trivial testing, I finally isolated it to a bad diode, which really surprises me.  This is the last part that I thought would be the problem!

NOTE to future self: try removing this diode if the problem ever happens again.

Thursday, July 22, 2021

Reproduction Dragon's Lair Scoreboard

 I finally got around to order parts for Shaun Wood's reproduction Dragon's Lair scoreboard PCB that he sells here.

For anyone considering soldering one of these up, I found this to be a relatively easy task compared to other boards I've soldered.  Shaun provides a list of parts along with Mouser and Digikey part numbers.  Some of the parts were out of stock, so I had to find alternates.  Here are the alternates (Digikey part numbers) I ordered that seem to work fine:

  • 493-1523-ND (C1)
  • 732-2095-ND (J1)
  • S1KQCT-ND (R1, R2)

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.