Wednesday, November 18, 2020

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.

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!