Dragon's Lair (and Space Ace) boot-up explained

 I occasionally get questions about whether Dexter is 'the problem' when a Dragon's Lair or Space Ace doesn't work.  Here's a video to shed some light on where boot problems may be.

ASUS G75VW laptop - replacing small internal fan connector

 When I was taking my Asus G75VW laptop apart (an older laptop but still quite useful!), I noticed one of the fan power connectors was falling apart.  It broke as I removed it.

After much searching, I found an "exact" replacement:

TE Connectivity part 440146-4

or Digikey part A98724-ND

Hopefully this helps someone else in the future, as this was quite difficult for me to locate.

Dockerized ld-decode (rev6)

Easy way to run ld-decode (rev6) using docker:

docker pull mpownby/ld-decode:rev6

Launching with Ubuntu (with X windows shared, allows 'ld-analyse' to be run)

docker run --rm -v $HOME:/shared -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY -e "QT_X11_NO_MITSHM=1" -ti mpownby/ld-decode:rev6 /bin/bash

Launching with Windows (or other host where you only want to use the command-line tools)

docker run --rm -v /c/your/host/dir/here:/shared -e DISPLAY -e "QT_X11_NO_MITSHM=1" -ti mpownby/ld-decode:rev6 /bin/bash

In the above example, c:\your\host\dir\here is written as /c/your/host/dir/here .  Modify this to point to a folder that you want the docker container to have access to (ie the place where your domesday capture lives).  From within the container, this can be accessed by going to '/shared'.

Caveat: I couldn't get the volume mapping to work with an external USB hard drive.  But it worked with my internal SATA hard drives.

Caveat: Beware that Docker advises that this may cause performance problems but it seems to be working fine for me in my tests.

Once the container starts, run these commands:

• cd ld-decode
• (optional) cat /usage.txt
• python3 ld-decode.py /shared/your_domesday_file_here.ldf /shared/output

This will begin decoding the .ldf file (compressed domesday capture) from the beginning.

NOTE: 'output' is the prefix of the output files that will be created.  You can use a different name but my instructions will assume you are using 'output'.

IMPORTANT: Most domesday captures were recorded while the laserdisc player is spinning up so the beginning of the capture will be "throw away".   You need to let the decode run until you see the CAV frames go back to frame 1.  Here is an example of how this looks:

(stuff before this removed for brevity)

file frame 626 CAV frame 244

file frame 627 CAV frame 245

file frame 628 CAV frame 246

file frame 629 CAV frame 247

file frame 630 CAV frame 248

file frame 631 CAV frame 249

file frame 632 CAV frame 250

file frame 633 CAV frame 251

file frame 634 CAV frame 252

WARNING:root:NTSC field phaseID sequence mismatch (player may be paused)

file frame 635 CAV frame 252

WARNING:root:NTSC field phaseID sequence mismatch (player may be paused)

WARNING:root:NTSC field phaseID sequence mismatch (player may be paused)

file frame 636 CAV frame 252

WARNING:root:NTSC field phaseID sequence mismatch (player may be paused)

file frame 637 CAV frame 202

WARNING:root:NTSC field phaseID sequence mismatch (player may be paused)

file frame 638 CAV frame 152

WARNING:root:NTSC field phaseID sequence mismatch (player may be paused)

file frame 639 CAV frame 102

WARNING:root:NTSC field phaseID sequence mismatch (player may be paused)

file frame 640 CAV frame 52

WARNING:root:NTSC field phaseID sequence mismatch (player may be paused)

file frame 641 CAV frame 2

WARNING:root:NTSC field phaseID sequence mismatch (player may be paused)

WARNING:root:NTSC field phaseID sequence mismatch (player may be paused)

file frame 642 CAV frame 1

WARNING:root:NTSC field phaseID sequence mismatch (player may be paused)

WARNING:root:NTSC field phaseID sequence mismatch (player may be paused)

file frame 643 unknown

file frame 644 unknown

file frame 645 CAV frame 1

file frame 646 CAV frame 2

file frame 647 CAV frame 3

file frame 648 CAV frame 4

file frame 649 CAV frame 5

Once you get this far, hit control-c (sometimes twice) to abort the process, take note of the file frame (645 in this example).  Then re-run ld-decode using the following command line:

python3 ld-decode.py /shared/your_domesday_file_here.ldf /shared/output -s 645 --noEFM

Instead of 645, put the appropriate file frame.  Including the --noEFM option may speed up the decoding (which is inherently quite slow even on modern hardware) as no arcade game laserdisc of which I am aware of has any EFM data.

You should see CAV frame 1 show up first in the log file:

file frame 645 CAV frame 1

If you don't, adjust the starting file frame accordingly and try again. For example, try subtracting 1 from the staerting file frame.

This will eventually produce files called output.tbc (which will be huge) and output.pcm.  Follow instructions at this page for further processing.  I recommend using the "(Mostly) Lossless export" instructions in the NTSC wiki section and then doing further processing upon that resulting file.

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!

Esh's Aurunmilla Repair

Esh's Aurunmilla reproduction PCB! Soldering and testing!

I first got the idea to clone the Esh's Aurunmilla PCB aboout five years ago.  I've always liked this game because it is so cheesy that it's endearing.  The fact that hardly any PCBs are known to exist and that no one seems to have the schematics makes preserving this game a more interesting challenge.  I would never be able to own the original game PCB.  But could I make a 1:1 clone of it?

Looks what showed up today!

 As some of you know, I have been working on cloning the Esh's Aurunmilla PCB.  The first prototype PCBs arrived today.  Pictured is the original (populated) next to the cloned PCB.  Looks pretty close if I do say so myself!

Installing huffyuv under wine on linux

So that I don't ever have to figure this out again:

using:

• Ubuntu 20.04 LTS
• WineTricks

steps:

• Downloaded and unzipped 32-bit virtualdub.
• Downloaded 32-bit huffyuv from here .

From within the winetricks environment, run regedit and import (or manually add) this entry:

[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32]"VIDC.HFYU"="huffyuv.dll"

Copy the huffyuv.dll from the downloaded zip file to c:\windows\syswow64\ from within wine. (you can launch task manager, then run cmd to do this)

Frustrated with Ubuntu GDM refresh rate problem

Pulled my hair out for an hour or two trying to fix a refresh rate problem for an old monitor I had lying around that I was using to build a machine for the kids.

For my own future reference, here is my solution.

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).

Star Rider repair: closing coin door causes game reset!

(it was actually Apr 13th, I said 15th on the video by mistake)

Atari Space Ace with Dexter!

Finally got this working!

Latest Atari Dragon's Lair progress with Dexter

Here's the latest Dexter progress for Atari Dragon's Lair:


Fixes since last time include:
- no screen blanking at the beginning of scenes
- audio level increased

My new Z80 emulator

So five years ago, I started speculating about how emulators could be improved and came up with several ideas.  One of them was to emulate the clock pin on CPUs (and other devices such as flip-flops or the PIA6821) for maximum accuracy.  I speculated that this would take a major performance hit but perhaps with multi-threading technology, this performance hit could be offset.

Well, I've been working on this secretly for several months now.  I've emulated almost every TTL chip on the Dragon's Lair logic board as a standalone device and tied them all together.  Performance at the moment is barely adequate on modern beefy hardware (75% CPU usage on a single thread on an AMD Ryzen) and not adequate on a Raspberry Pi 4.

I experimenting with using multi-threading solutions to speed this up, but the critical timing and the need to keep the whole system running in lock-step made me conclude that this must be run on a single thread.  I'll keep looking at ways to use other threads to offload things like video and sound processing which I think will work fine.

So the good news is that I believe I'll be able to design the "perfect" Dragon's Lair emulator and it will be able to run at full speed on modern CPUs (such as the aforementioned Ryzen) and possibly even older CPUs like the Intel i5.  When I say perfect, I mean that every single pin on every single IC in the system (including the Z80) will be emulated and have the exact timing of original hardware.  Where a device is digital, there will be no shortcuts.  (analog devices such as the sound chip will not be held to this same standard of perfection).  I'm pretty excited about this because I sometimes study/repair original game board sets and not having the ability to study how the hardware is supposed to work via emulation has been quite inconvenient.

The bad news is that Dragon's Lair is the simplest of laserdisc games, so a game like Star Rider (which has three 6809E CPUs and a ton of TTL chips) probably won't able to run at full speed even on the newest of hardware using this approach.  I'll be looking at thoughtful optimizations/compromises to make for these scenarios since obviously with enough compromises, any of these old games could be made to run at full speed.

Here's a brief description of how the Z80's pins work from an arbitrary instruction:

Here's every single pin of a Z80 captured via my logic analyzer.  When I embarked on the journey to emulate this beast, I thought "this is insane.  it will take so long to figure this stuff out."  but.. this is the kind of emulator I want Daphne to be, so I did it anyway.  now it's starting to make sense.

I had to do two separate captures because my logic analyzer can capture 32 pins at a time (which is a ton!) and the z80 has 40 pins.  that alone almost made it give up.

I've put colored lines to show how this instruction (LD (HL), 00h) works.

First section ("M1") is loading the instruction's opcode from the ROM program.  It sets the address to 1153h, lowers RD and MREQ lines, then the EPROM puts 36h on the data bus.  Z80 then raises RD/MREQ, then lowers MREQ/REFRESH, putting the number 0005h on the address bus which is used for dynamic ram to refresh itself (I think dragon's lair ignores it because it uses static ram).  That takes 4 clock cycles and is known in Z80 speak as "M1".  Next section ("M2") it needs to read the rest of the instruction, so it sets address to 1154h, lowers RD/MREQ again and the EPROM puts 00h on the data bus.  M2 is complete.  Now it has the full instruction.  It goes to the next section ("M3").  HL happens to have a value of A000h, so it sets the address bus to A000h, lowers MREQ but instead of lowering RD, it puts 00h on the data bus and lowers WR which tells the rest of the system that "Hey, I want to write a 00h to address A000h".  The rest of the system's hardware maps that address to the RAM and the RAM wakes up and grabs the data from the data bus and stores it.

The amazing thing is... how did they design the Z80 in 1976 or whenever?