Sunday, January 15, 2023

My Migraine Remedy

Do you hate migraines?  Do you have trouble getting rid of them once they come?  Here’s my "shotgun" recipe to kill migraines:

- take two Excedrin Migraine pills

- drink one caffeinated beverage* (I use Diet Mountain Dew)

- do about 30 minutes of cardio where your heart rate is in the “green” zone (70-80% max heart rate), drinking lots of water.  Migraine will slowly go away the longer you exercise.

- go to bed early and get extra sleep

Sometimes not all of these steps are necessary, but doing all of them almost always works for me.

* - Caveat: I avoid caffeinated beverages almost always _except_ when I am applying this remedy.  If you drink caffeinated beverages regularly, your results may be different. 

Wednesday, October 5, 2022

Cobra Command (dedicated) confirmed working with Dexter!

 Very exciting progress to show here.


Thanks to Mike Treu for testing for me!

By the way, not only will this mod work with Dexter, but it will also work with the Sony LDP-1450 which Mike also tested.

The mod replaces 16K on the bottom Data East board with a custom PCB that I designed.  So unfortunately, it will require modifying the game hardware, which I have tried to avoid as much as possible but which was ultimately the only feasible solution I could find for these games (Bega's Battle, Cobra Command and Road Blaster).

After the mod is installed, the game will work with:

  • The original Sony LDP-1000A (yes, I maintained backward compatibility)
  • Dexter
  • Sony LDP-1450 and probably most other Sony players.

Wednesday, September 21, 2022

Saturday, September 17, 2022

How to kill ants

So, I was using peanut butter as bait for mouse traps in my garage, but ants kept coming and stealing it.  I find it rather ironic that I had to get rid of a second pest (ants) in order to deal with the pest I originally was targeting (mice).

Here's an ant bait recipe I took from another website and modified:

  • 1 teaspoon Peanut Butter
  • 2 teaspoons Borax (yes, the stuff used as a household cleaner; this stuff is the ant poison)
  • A small amount of vegetable oil
Mix the peanut butter and borax together as best as you can.  Add small amounts of vegetable oil until consistency is like the peanut butter was before you added the borax.  This is important to keep the bait from drying out (ants will ignore it if it dries out).  Place bait in the place you see ants (or where ants are known to come steal your mouse bait!!).  Do not interfere with the ants as they take the bait back to their queen.  This will take about 4 days.  Afterwards, the entire colony will be dead.

Day 1



Day 2



Day 3


Day 4



Friday, September 9, 2022

Making a MC44144 tester for Cobra Command / Dexter research

I've pondered about whether the "obsolete" MC44144 chip could be useful for making Bega's Battle (and Cobra Command dedicated) work with Dexter.  Although it isn't in production anymore, from what I can tell, it's still fairly obtainable.

Here's the PCB I've designed to help test it and see how well it works.



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!