Friday, July 25, 2014

Troubleshooting Star Rider :)


I hooked up my logic analyzer and my sniffer board tonight to see why STAND BY wasn't working for PR-8210A mode for Dexter rev3.  (I was successful, BTW)

See how many relevant components you can name in this picture.

For starters, there is a Dexter rev3 board, an AVR dragon, and my ultimate I/O sniffer board.  There are at least 3 other things in this pic that are of interest to laserdisc collectors :)

Star Rider + DEXTER (25 July 2014)



I've got DEXTER rev3 stable enough that I had a chance to try it out with Star Rider.  In short, the VBI frame number injection wasn't working at all and it's because of defects in the DEXTER firmware and software.  I look forward to fixing these so that I can see if any kind of frame number detection is working.

Also, seeks seem to be getting ignored by the firmware which is odd.  There may be a problem with the video squelch and/or the stand-by line.  Again, this appears to be a firmware defect.

As you can see, laserdisc video is working but looks pretty bad.  I'm not sure if this is just how Star Rider looks (like crap) due to being filtered through crappy ADC/DAC hardware on the expander board or if there's something wrong with the hardware.

And for those still reading (hehe), I did modify two of the ROM ICs so that the game will boot faster and get into the frame seek tests without having all of the inputs hooked up.  I modified U52 (on the CPU board) so that the long color tests that start when the game is powered on are completely skipped, and the first ROM test is also skipped.  Only the rug pattern tests remains because it goes fast.  I happened to have an EEPROM that is pin-compatible with the 2764 used on the original and it seems to be working great.  This thing is super easy to reprogram over and over again.  I also modified U26 which is a 27128.  Unfortunately, I do not have a compatible EEPROM for this one so I ended up reading it (it matches the U26 that is floating around on the internet), erasing it with a UV light, and re-writing it with a modified version of the self-test that immediately skips to the "search to" portion of the DISC TEST.  The two former tests (RESET RESPONSE and WALKING BIT test) only test I/O from the main CPU to the PIF board, and don't actually test laserdisc I/O so I am not particularly interested in those for DEXTER development.

Monday, July 21, 2014

Fixing Dexter rev3 hardware defect

So Dexter rev3 has a hardware defect where PR-8210/A mode conflicts with VP-931 mode.  I had this crazy idea to remove one of the tiny SMT 2-input OR gates that I have on the board and replace it with a huge 3-input OR gate (DIP version) to fix this conflict.  I just soldered it up tonight and it seems to work great!  Future updates will have this fixed at the PCB level, so no need for this massive monstrosity on top.  But, hey, it works.  I really want rev3 to be fully functional no matter how many fixes it needs :)

Friday, July 18, 2014

DEXTER rev3 running at CAX 2014

Here are some videos I took of cabinets running DEXTER rev3 at CAX: Space Ace '91, Dragon's Lair, and Badlands.


Wednesday, July 16, 2014

CAX 2014 Dexter presentation

For those of you who wanted to attend my presentation but could not for whatever reason, here is how it turned out.

Dexter Facebook Page (presentation is near the top)

Monday, July 14, 2014

A few short Eugene Jarvis clips from CAX

A bunch of people filmed this entire thing so it is (or will be) available in multiple places but here are just a few short clips I filmed since I was sitting on the front row.  You can't tell but the entire room was totally packed with people standing in the back.


Sunday, July 13, 2014

I got to meet Eugene Jarvis and Sam Dicker!

I've become increasingly interested in Williams' early arcade games ever since digging deep into Star Rider's interesting/complicated design so I was quite interested to hear what Eugene Jarvis and Sam Dicker (who worked on the 1980 game, Defender) had to say at California Extreme 2014.  After their remarks, I had the opportunity to chat briefly with both of them.

I asked Sam about Rich Witt (who put an Easter Egg in the Star Rider PIF board ROM program) and Chuck Bleich (whose name appears on the schematics). Sam said that he did indeed know Rich but had no idea what had happened to him and was interested if I knew his contact information.  I reported that I did not, but I was hoping to one day tell Rich that I found his hidden easter egg inside the PIF board ROM.  Sam told me that Chuck Bleich was the guy who designed the hardware.


I also asked Eugene Jarvis about Rich Witt and Chuck Bleich.  Eugene told me that he didn't know Rich very well but did know Chuck and also confirmed that Chuck was the guy who designed the hardware.  I've sent a few messages to Chuck but so far I have not received any response.  I'd love to just chat about the hardware for no other reason than I've spent so much time reverse engineering it.  I also told Eugene that I had written an emulator for Star Rider and I asked him about the origins of the special Williams blitter chips.  Eugene told me that he thought that Greg Wepner was the guy behind the design of the chips, and I have seen Greg's name on the Star Rider expander board schematic.  I think that is pretty amazing to get more insight into the special chips.


Friday, July 11, 2014

Packing for CAX

I sure that I didn't forget anything and that nothing gets broken in transit.

Wednesday, July 9, 2014

5 Dexter boards ready for CAX!

I've tested 5 Dexter rev3 boards as much as I can at home. They all work as far as I can test at home which means Firefox remains untested. I intend to bring all of them to CAX. Now the real test begins :)

Saturday, July 5, 2014

Dexter rev3 Dragon's Lair test

Now that I have my rev3 Dexter board assembled, it is time to test it out on my Dragon's Lair cab.


Dexter components labeled


In case anyone is curious, here is a brief description of the integrated circuits on the board and their purpose.  I labeled these really quickly so they are a little hard to read.


  • Voltage converter: convert between 5V and 3.3V for I/O between 5V AVR and 3.3V raspberry pi.
  • micro 2: Auxilliary AVR microcontroller.  Injects frame number into video signal for PR-8210/A games.
  • sync separate: grabs vertical sync and horitzonal sync signals from video signal to that AVRs know when frame starts and which line number is active (so it can inject frame number into video signal)
  • video mux: so that video can be muted during seeks and frame number can be injected into video signal
  • tri-state buffer: to transform the centronics-24 connector so that it can support PR-8210A mode.  Also to squelch AUX AVR transmit (see OR gate 1).  The main AVR and aux AVR communicate with each other through TX/RX lines but the main AVR's TX/RX lines are also used to talk to the serial1/2 ICs so this is a way to shut down communication if the aux AVR is inactive without shutting the aux AVR down entirely (Warren pushed for this feature strongly.  I was okay with just putting the AUX AVR in reset mode when it was not being used)
  • OR gate 1: to squelch Auxilliary AVR's transmit line if either of the serial ICs are active (to avoid conflicts)
  • OR gate 2: to merge PR-8210A "remote control" and "remote control enable" signals into a single signal since we ran out of pins on the main AVR.  Also improves performance because it means code for main AVR uses less cycles.
  • micro 1: main AVR microcontroller, this is where the bulk of the work is done
  • BAT1/2: voltage protection in case someone plugs in a serial cable to the DB25 port to ensure that 12V/-12V doesn't make it to the 5V main AVR.  Also protects the optocoupler from some idiot plugging in something bad to the PR-8210 port.
  • RELAY: solid-state relay to add more protection to the main AVR
  • optocoupler: PR-8210 interface that protects the main AVR from someone plugging in something stupid to the PR-8210 port
  • serial 1/2: supports serial laserdisc players.  The reason there are two of these is that the Sony players are wired backward from the other players so we put two of these on the Dexter board so that the user doesn't have to mess around with null-modem adapters.
  • led driver: the board has a lot of LEDs on it and the main AVR can control them all using only 3 pins.  Efficient.


Friday, July 4, 2014

First Dexter rev3 prototype fully assembled!

It took a lot longer than my optimistic mind predicted, but I've finished putting the first rev3 board together!  And I think it looks awesome! (I am obviously biased)


Wednesday, July 2, 2014

Soldered all of the ICs onto the rest of the Dexter prototype PCBs

I decided that the fastest way to finish all 6 of the prototypes at once is work in parallel, meaning, place one bag of parts on all boards at a time instead of doing one board at a time and having to switch between 50 bags or however many there are.  So I decided to solder on all of the ICs this morning.  I made great time!  Got all 5 boards populated with ICs in 4 hours which is probably a new best time record for me.

Solder paste applied to all boards.  This part took FOREVER!

ICs populated on top of solder paste.

All finished with all solder bridges removed.  I am sure glad to be finished with this part!

Tuesday, July 1, 2014

CAX Presentation Schedule Finalized

I have received final confirmation about when the CAX organizers have scheduled my presentation.  It's going to be at 11 AM on Saturday (July 12th).  I'd sure love to have a lot of people there, so bring a friend :)
I plan on having some prizes available for participants :)

First Dexter rev3 prototype almost finished

Well, I stayed up way too late working on this, but I've mostly finished soldering!  I also learned a few things about skillet temperature, mainly, that it is possible for it to be too hot!  Hahaha.  I burned the PCB pretty badly but INCREDIBLY, so far everything is still working!

I put solder paste on half of the board, then got scared of accidentally nudging an IC out of position and decided to solder the ICs on first before continuing with the rest of the easier parts.

The IC soldering went incredibly well.  I only had about 3 solder bridges.  The middle of the board has started to turn brown at this point but I wasn't worried.  I knew I just had to use less heat on the hot plate the second go around.

The second go around using the hot plate was pretty scary as the board started sizzling, smoking, and turning very dark brown (as you can see).  I thought "OH NO, I've ruined the board and all my work is for naught!!"  But I decided to solder on a few components to see how bad the damage was and WOW, everything is working so far.  Both microcontrollers (AVR 644p and 328p) work, crystals work, and the LEDs (which look horrible after the burn) work too.  I don't want to get overoptimistic here, but I think this board might be saved!  And don't worry, I will be keeping this one for myself so no one has to worry about getting a burnt prototype board :)