Monday, July 27, 2020

IR Remote to LANC bridge for my Sony Video Walkman GV-S50

The new, complete schematic

This second portion of the project involved IR code decoding and integration.  The short version is that I extended the LANC-Serial example to also include portions of the IR receiver code, using Ken Shirriff's IR library for Arduino.

The changes to the hardware included adding the IR receiver device, along with its passive components as recommended in its datasheet.  It's basically a combination of the LANC interface (J1, D1, Q1, R1, R2, plus SW1 for power), along with the IR interface (U1, C1, R3, R4).

Aside from just jamming everything together in the source code, I also disabled interrupts when it's sending out LANC codes, and re-enable them when it's done, since that's timing-critical, and the IR stuff works mostly via interrupts so that it can get its timing correct. ;)

IR decoding is not perfect, and some of the codes seem to confuse the decoding algorithm, but if I only handle received SONY codes, and specifically only compare the received code with a list of codes i'm looking for, it gives the impression of being super reliable. ;)

The best part is that this works REALLY well.  I've been using it all day on this deck and it's been perfect.  I can also add additional remote codes to do other things as well; control lighting, toggle solid state relays to turn on and off lamps and devices, etc.  Lots of leftover data ports for activities!

The list of Sony IR codes for VTR1/VTR2/VTR3 didn't seem to be available, so I found all of the codes using my RMT-V119 remote, and have documented them in this google spreadsheet.  Consider this information to be fully public domain; it's just numbers.  Feel free to use this information for your project or repurpose/reformat it for any other use.

All of the content for this project can be found in github at the project repository.

Everything seems to work well enough, however one issue is that if the LANC plug is attached to my VTR, it will not turn off.  I've tried disconnecting signal and power to that TRS plug, but it seems to be internally forced on if the player powers down and there's a plug physically in the jack.  

(This post was accidentally forgotten in the publish queue, so it was published on 7/27 instead of a month earlier when it was written. oops.)

Wednesday, April 29, 2020

Experiments with LANC on my Sony GV-S50 Video Walkman

An Arduino Uno with a LANC interface on a horrible looking shield.

I've been working from home, and I've of course been playing stuff while I work from my LaserDisc player, and 8mm Video Walkman GV-S50 playing some stuff I recorded in the 90s... MTV AMP and a few hours of a local WRUR electronica/trance show called "Digitalis".

Sony Video Walkman GV-S50

But of course, since I've got the deck right here next to me, and it doesn't have an IR receiver or any way to remote control it, I need to solve this major problem. ;D

LANC port is the 2.5mm jack on the bottom labelled "REMOTE"

The deck has a LANC connector on the back, and I happened to find a 2.5mm plug the other day, so this seemed like an obvious thing to do.  Obviously.

The schematic I based my circuit on. I did not include the 'push rec' button,
and I added a switch between LANC +5 and this circuit so I can decouple the power.
The transistor diagram shows the view of the transistor looking at the bottom of the device.

I found this schematic to interface to the LANC port, along with this arduino sketch that lets you just send the two byte commands out from a serial interface.   Thanks to getting totally confused from the article I found, I re-read through this doc about the LANC commands and figured out that what I need to do is send the standard command byte (0x18) followed by a standard command, and the deck will do what i command it to do!  So I did have it working, and better yet, the deck provides enough current to power the Arduino directly from the port.

My very slightly tweaked circuit

I made a tweak to the circuit just so that I could not worry about the 5V from my computer mingling with the 1990s 5v coming out of the VCR, so I added a switch.  In the pic of the shield above, the blue pushbutton switch can be seen by the second usb port.  That board has been re-used for a few projects, so there's only a couple of components on there that are actually for this one.

The only things on this board that are for this project are the blue switch in the bottom left, the transistor and zener diode in the middle and 4 of the resistors.  The schematic only shows two, but I didn't have a 5.6kΩ resistor so I cobbled one together using three in series.

The docs there weren't complete for this deck (Sony Video Walkman GV-S50), and I found a few more commands (volume, megabass) so I thought I'd put the list of commands here for future reference:

Group: (0001 1000) (0x18) - Normal Command to VTR or Video Camera 

  • 1830  stop
  • 1836  rew
  • 1838  ffwd
  • 1834  play
  • 1832    pause (still)
  • 1840    still
  • 1860    frame reverse
  • 1862    frame forward
  • 1850  search - (scan until 'play' or 'pause')
  • 1852  search + (scan until 'play' or 'pause')
  • 185E  power off
  • 18b4  counter display/data screen
  • 188c  counter reset
  • 18b0  tape speed (LP/SP)
  • 183a  rec  (untested, assumed to work)
  • 183c  rec-pause (untested, assumed to work)
  • 18d0  audio dub? (untested, might work?)
These were not listed on the LANC page, but I poked around until I found them:

  • 1876  megabass toggle *
  • 1824  volume +
  • 1826  volume -
  • 18fc  still/shuttle (still frame)
  • 1846  slow
  • 184c  x9 speed (scan forward)

Group: (0001 1110) (0x1e) - Normal command to still video camera)

  • 1e52  photo preview (scan forward)
  • 1e5e  power off

I tried a lot of the commands with the TV Tuner card installed, and none that I tried seemed to control it at all. (channel up/down, timer functions, menu functions).  In general, none of the menu interaction commands worked at all, sadly, other that direct tape speed, counter reset, megabass mentioned above.

I eventually want to have an IR Receiver module on there, and program it to receive commands from my mega sony remote, but for now, i can type the commands out to the serial port. For example. if I type 1834[RETURN], it is the equivalent of pressing [PLAY] on the deck.

Reference Links:

Saturday, November 9, 2019

RC2019-10 - A102 project - The end of the month of hacking

The short version is that I was super productive on these projects this past month.  I didn't complete it, but I never realistically thought I would be able to.  I lost a week's worth of time, or so, prepping our yearly Halloween Hack (blog post soon)... not to mention losing some time to work on building my Lego Saab 900... (blog post soon too).
One thing I will say, is that by combining the projects together, I tricked my brain into quite effectively "being okay with" working on one project or another, by them all being part of the same project.  So I would say that the month was quite successful.

So Anyway, I'm going to first go through a bunch of goals for the month, for the RC challenge, and in general, and briefly discuss my progress on them at a meta-level.  Then I'll get more into details about the actual work.

Overview and goals

Raspberry Pi / Emulation

I wanted to get the Pi 3 configured and booting right into an emulated  Amiga/Amibian environment.  I got the pi configured with standard raspian instead of Amibian, since I wanted this to be more of a general use machine.  It'd be nice to be able to use it for firmware development of the LL530 as well as the machine that it's targeted for.

So the target changed on this, but it is complete for now.

LL530 Development

I wanted to have the LL530 (USB Interface to Amiga serial keyboards, Amiga/Atari controllers and mice) fully finished.  Although I did not finish the firmware this month, I got more done on the project this month than I had in the past 6 months.  However, I was able to test the DIN pinout to discover that it's backwards, so I need to rev the board for those...

I didn't fully succeed, but I was successful.... if that makes any sense.

RC2014 Integration

I wanted to have an RC2014 Z80 computer built in as well, that I can connect to via serial port, for doing RC dev work without an emulator.  This aspect sadly got the least amount of attention.  I have an RC2014 mini installed, connected to the serial port on the Pi 3.  I've rewired the connection twice now, and I still cannot get it to connect using this wiring.

I spent time focusing on the other aspects.  So... 25% success.

Integration / Battery / Monitor / Enclosure

Most of the effort this past month was in this area.  I wanted to have the entire thing as a finished unit; to be able to be brought to a coffee shop, pull it out, turn it on and use it wirelessly. I can do all of these things right now with it.

So I would say this aspect was completely successful... although It does need improvements, particularly with the screen.

Installing The Linux

I started with a base Raspian image from their site.  I had the Pi hooked up to a HDMI monitor with USB keyboard and mouse.  After using Balena Etcher to get the image onto an SD card, I booted the  machine up.  I went through the basic setup, and updates.

I launched raspi-config from a terminal window, and went through to  enable ssh, i2c, and serial.

Next I installed some useful software packages:

apt-get install screen fs-uae-launcher stella

I made sure that serial was enabled  in /boot/config.txt,


I use screen as my quick and dirty way to connect to the RC2014 which is wired up to the uart on the raspi per the diagram above.  The reset line is wired to GPIO 4, so i use this shell script to "hit the reset button":


import RPi.GPIO as GPIO
import time

print "Resetting the RC2014."

# setup GPIO4 as an output

# send LOW (reset) for 1 second, then restore HIGH (normal run)

print "Done."
# return to high-z state

The Red and Green LEDs are wired to GPIO18 and GPIO12, and I can run this script to do a nice fadey display on them:


import RPi.GPIO as GPIO
import time

red = 18
green = 12


r = GPIO.PWM(red, 100)  # channel=12 frequency=50Hz
g = GPIO.PWM(green, 100)  # channel=12 frequency=50Hz
while 1:
for dc in range(0, 101, 5):

r.ChangeDutyCycle( 100 )
g.ChangeDutyCycle( 0 )
time.sleep( 1 )

for dc in range(100, -1, -5):

r.ChangeDutyCycle( 0 )
g.ChangeDutyCycle( 100 )
time.sleep( 1 )

except KeyboardInterrupt:

I may rewire these, or wire up additional LEDs to the ones specified with the Amibian/UAE led indicators, which are defined as GPIO4 for activity, GPIO16 for "Power", and GPIO16 for a clean shutdown button.

LCD Monitor

For a monitor, I'm using a $10 3.5" composite monitor.  I had to do a few things to get it to work however.

I had to hack the power input so that it would run off of 5v.  These are made to be used in cars, so they expect 12v of power.  At the time I did this, there were examples of doing this modification on
other displays, but not this model.  I powered it up using 12v, then probed the outputs in the power supply section for a 5v rail... and I soldered a 5V input there.

Once I had done this, I connected it to the 5v power in the enclosure, and hooked up the video input from the composite output on the Pi 3.

One snag I hit though, is that it wouldn't work right, It would flash on when the Pi booted, but it wouldn't show the desktop. Testing the Pi with HDMI or a known working composite input worked just fine though.

I was trying all sorts of things, and eventually decided upon trying PAL  video modes instead of NTSC, and that worked.  I spent some time tweaking the overscan settings as well, to stretch the screen to fit.  I also noticed that the contrast viewing range was substantially better on the top side of the display, so I ended up mounting it in the enclosure upside down, and I flip the video in the pi's config too.

So the changes that all this amounts to for /boot/config.txt are:





Although, as you can see from the screenshot above, it's basically unreadable.  So I was able to get it to work, but any future development on this will need to be with a different display.  Something with at least 480 rows, so that Amiga emulation can be reasonable on it.

Combining it all, and the Future...

I spent a few evenings rewiring that keyboard which mostly works really well.  I'm using a 5000mAh battery and get an undetermined-but-better-than-my-old-iBook amount of time with it.

The display is garbage.  I'm currently looking into replacing it with an HDMI-based 4" Waveshare IPS display with an 800x480 resolution for about $40.  Surely that will require moving around hardware inside of this enclosure, and since the display is meant to piggyback on the Pi, I will lose my integration board.

Obviously, I'll need to install the Amiga emulator, Tandy 102 emulator, my Model-T-Shell, and the Arduino IDE so that I can continue development on the LL530

In short, I'm super happy with where things are now, it just needs some tweaks to get it to be usable as a primary system. :D

Saturday, October 12, 2019

RC2019-10 Update 1: A102 Amiga/Tandy/RC2014 Frankenstein

The Enclosure

Since I had started working on this last year, the enclosure is partially completed.  I had removed some plastic ribbing prior to the RetroChallenge, and mounted both a Rasperry Pi 3 and a LL530 keyboard interface board inside of it.  That's about as far as I had gotten last year, so that's a good start. (pics in the next update post)

The Keyboard

I started out with trying to get the keyboard working.  This seems to be the most time consuming portion of the hardware at this point, and has the most question marks associated with it.
The big issue is using the Tandy 102 keyboard with a spare "two header" Amiga 500 keyboard "encoder" board.  I had toyed with the idea of perhaps just wiring up the row/columns to the Tandy keyboard's rows and columns, but this brought up some issues.  Obviously, the matrix would be different... ie; row 2 column 2 would be different keys on the two keybaords.  This would be fine as I could just change the code in the LL530 to convert the fakey-102-500 keycode to be the correct keypress.  I kinda wanted to use the LL530 stock though, so this meant rewiring the 102 keyboard.
The 102 keyboard has diodes at most of the junctions, and there were a different ratio of rows/columns. but I plan on ignoring those by cutting the traces on the board and wiring around them, ignoring them.

I measured resistance for each key on both keyboards.  The Tandy 102 keys ("Alps Mount Round Slider") came out at about 100 ohms when pressed.  The Amiga keys ("Mitsumi KPR Hybrid Switches") were 0 ohms (no resistance).  Could this be an issue with the custom Commodore key matrix scanner on the Amiga encoder board?  Only one way to find out... Wire it up!

I wired up a couple of the Alps keys to the scanner, hooked it up to my LL530 and tried it.  Turns out it all works great, so no worries there! I apparently picked "9" and the left spare key usually between 'left shift' and 'z', which apparently maps to a "section character" (§)

Next, I wanted to try to clean up the keys.  They seem to bind a little as you press them down, as the plastic tube is getting snagged in the mechanism. This is probably due to wear, dirt, etc.  I removed one from the board (four through-hole solder pins), and disassembled it carefully to see what I was dealing with.

The keys popped off using an official key cap removal tool... a pair of tweezers wedged under the key.  Then the plunger and dome could be removed from the enclosure by flexing out the two T shaped tabs on the enclosure top. From left to right: the key cap, top cover (snaps on using the two large T shaped tabs), round plunger, rubber dome with carbonized contact, and finally the enclosure with the contacts in the bottom.

As far as I know, all of the keys are contacting/switching okay, but if i need to replace components, they're easy to swap in or replace the entire key.

I also took this opportunity to replace the "caps lock" and "num lock" keys, which are latching, with two spare keys, since I wanted to reuse the Num key for "right Amiga" and the caps lock key needs to be momentary for the Amiga matrix scanner. The pin layouts were different, so i needed to drill new holes in the board for the momentary switches. The switch labelled "56" above is the replaced caps lock, while "57" is the control key next to it.

Four of the "top row" keys of the 102 keyboard, the arrow keys, don't have quite the right snap/click that the others do, due to 30 years of use and wear.  I happened to have a bunch of exact replacements, which I got on ebay for another project a couple years back, "12x12x7.3mm Tact Switches"

Next is the task of remapping the matrix.  I found some commonalities between the two matrices, seen color coded above... the keys in yellow share the same x/y indexing with the Amiga layout, and the other colors only share the same column.  I traced out the schematic on the keyboard, and cut a bunch of traces.  Next up is rewiring it and wiring it up to the Amiga Encoder board.

More to come....

Wednesday, October 2, 2019

RC2019-10 - The Globbing Of The Projects... Globjects?

Hey.  Long time no post.  How y'all doing?  I'm still here. I've gotten a lot of small things done over the past half year, and a lot of things almost done as well... and some long-standing projects not done too.  So, I've been almost productive...  Anyway, I hope to try something different this month for the RetroChallenge RC2019-10...  Let me explain...

The main projects I've been trying to work on recently are:

LL530 USB interface for Amiga serial keyboards and controllers

I've been poking at it a little over time, and am really damn close to getting the proper firmware done for it, but I just haven't finished it.  Which is stupid because I can actually sell these things once I'm ready!  I have keyboard working for all but my A1000 keyboards, and I have joystick/mouse/paddle working... but not at the same time in a way that I'd be proud of.  I also will eventually need to rev the board to fix three layout issues; a power/ground short, lack of ICSP programming header, and lack of pull-up resistor for VCS paddle sampling.

Llichen-80 Computer (LL80)

Okay, so it's not really a whole other completely new computer... but it is a specific configuration of the RC2014 Z80 computer.  It started out this year as a whole lot of customizations to standard (but old, obsoleted) RC2014 boards to add bank switching, using the 8 bit parallel IO board (the one with all the LEDs and switches!).   Now, I reworked the idea so that I just use the standard "Switching ROM" board and the "64k RAM" board.  That simplifies the design; making it easier to get to the LL80 spec, since just using those two cards replaces two RAM boards, one ROM board, and one IO board... plus no modifications to any of the boards are necessary.

The other part of the LL80 computer is the "LLSuper" board.  This is an arduino-based supervisor of sorts that sits on the serial console port.  It acts as your usb-serial interface for when you use a desktop computer as a console.  This board used a CH376S USB Drive interface to access any flash drive as mass storage (it's a neat part.. like $2 for a board with a USB A port... it talks TTLRS232, SPI or parallel, and handles all of the disk switching, FAT filesystem etc. So there's very little overhead on a tiny ATmega micro.  I also have an I2C based clock chip board for this.  This sits between your console and the RC, and lets you have a kind of shell access to the disk from the console, as well as from the RC.  The RC side of things also got direct access to virtual disk image files with a sector-based interface, as well as direct fileio...

The next steps would have been to write a CPM BIOS and make the thing boot into that.

But I've come to realize that even the LLSuper board is unnecessary.  I can accomplish near-similar things using the standard  "Pi Serial Console" board.  If i use a RasPi Zero, and boot linux on it (or adapt the code in the PiGFX kernel, I can put in my serial-disk IO stuff, for cheaper, without needing to fab up my own board.  I started to mess around with this using my new RC2014 Micro, a Pi Zero, and a slight hack to attach the reset line of the RC to a GPIO of the Pi, so i can now reset the RC from the Pi.

I do have the protocol all worked out for the serial interface using unused ANSI escape codes, which are made for custom purposes like this.

A102 - Portable Emulated Amiga in a Tandy 102 shell

This is one i've wanted to work on since last year. I was trying to get it done before Rochester MakerFaire last November, but burned out on it.  It essentially is a project that joins together a bunch of parts... all of which I have:

  • Raspberry Pi 3, with Amibian... booting right into an emulated Amiga environment
  • Tandy 102 shell, rescued from some unrepairable 102's
  • Tandy 102 keyboard, also rescued (keys bind as they're pressed though)
  • Amiga 500 keyboard interface board, from a long-gone computer
  • My LL530 USB serial keyboard interface board
  • Amiga mouse
  • 3.5" composite LCD panel (new, $10 online!)
  • large Power Bank battery pack
This project entailed hacking the keyboard (removing the wiring/traces on the board) to convert the scan matrix to match an Amiga 500 keyboard.  This gets connected to the LL530, which is plugged into the Pi.  All of it gets jammed into the 102 shell, and becomes a portable computer. 

I waffled a bit on this... mainly because the keyboard stuff would be a chore.  I want to remove every key, and clean their travel tubes, to eliminate the keys binding.  Wiping out the traces and rewiring the board seems like it's going to be a tedious process... So i kept thinking that maybe I should make a cherry-mx switch based board to fit the keyboard space instead... and... yeah... i just kept going down that same path of "maybe i should do this other thing" instead... instead of actually moving forward on any of it.

I also pondered putting the entire Llichen 80 computer into this shell... which brings us to...


So that's where RC2019-10 comes in.  Why almost fail at three projects when I can almost fail at ONE project! Seems a lot more efficient!

The end result for this month will be to have a working portable laptop computer that runs Amibian (Linux), RC2014 (via serial connection to the Pi) and general Linuxy stuff.

Or, more granularly, here are the tasks as I see them now: (in no particular order)

  • Finish the Keyboard + Joystick/Mouse firmware for the LL530
  • remove the wires on the 102 keyboard PCB
  • clean the travel tubes on the keyboard
  • rewire the keyboard to match the Amiga's matrix
  • Wire the keyboard to the Amiga 500 interface board
  • Connect the RC2014 Micro via the Pi's serial interface pins
  • Additional buttons on the device to cleanly shut it all down
  • Have it all powered from a 5V/USB powerbank mounted internally
  • Serial-console textmode app for Linux that provides the beginnings of a backchannel to 
Stretch goals:
  • Full drive interface for the RC2014
  • CP/M BIOS for the RC2014 that uses the serial protocol
  • Fit the RC2014 Mini + 64k RAM + switching ROM + TMS9918A cards inside the case
  • Have the video switchable between the Pi and the TMS9918A video card

Not sure how far i'll get, but it globs together all of the recent projects in a way that I won't feel like I'm neglecting one project by working on the others... since they're all the same project now. :D

Thursday, March 21, 2019

Llichen-80 (Retrochallenge 2019-03 Update)

I had originally intended for any time I could devote this month to the 2019-03 Retro Challenge was going to be for a new version of my RC2014 Z80 computer emulator, adding support for the TMS9918A video display chip.  But my plans have changed.  With the recent advancements with The 8-bit Guy's "Commander X16" 6502 computer, I decided to start reviving a project I was considering for a while.  The great thing is that there's so many aspects to it that it's like a grab-bag of things to do.

The original idea was to sit down with a C64, floppy drive, monitor, joystick, mouse and reference books, and start with BASIC, writing a text editor, assembler, IDE, etc and work my way up to having a windowed operating system like GEOS with a few utilities and such.

Except now, the spec of the system is designed by me, and I'm building that too.... Which meshes in perfectly with my original intention to build a RC2014+TMS9918 emulator, which I can use for initial development, and kickstarting the boot rom onto it.


I wanted some sort of related name for the project, so I was thinking Llama, TMS, which became Llitmus, like the PH sensitive dye.  I was gonna go with Llitmus-80 with the '80' because it uses a z80, but then once I read that the litmus was made from lichen, I just went with the name Llichen-80.

First, let's get into the Llichen-80 system specification.

  • RC2014 backplane/base system
  • 7.37 MHz clock speed
  • 32k RAM from 8000-FFFF
  • 8k BASIC ROM from 0000-1FFF (*)
  • 32k RAM from 0000-7FFF (*)
  • Digital IO board at port 00
  • TMS 9918A video board at port 10,11
  • ACIA Serial port at 80
  • ACIA Serial port 2 at C0 - connected to CH376S USB drive interface
So (*) Indicates something... there's an overlap of these two items. My existing design piggybacks bit 0 of the output from the digital board to select which of the two of these that memory READs come from.  That is to say that writing 0x00 to the digital out board will select ROM, and 0x01 will select RAM.  Writes to these locations always go to RAM.  So one way I can test this is:
  • Start up the computer
  • select ROM bank
  • Write a basic program to peek from the ROM and write to the RAM
  • select the RAM bank
  • Yank out the ROM board, and everything still works fine
10 OUT 0,0
20 FOR A=0 TO 8192
30 B = PEEK(A)
40 POKE( A, B)
60 OUT 0,1
This all works great!  One addition I made was to intercept the VCC to the RAM chip and have it also connected to some CR2032 batteries for a backup.  It's not perfect, but it works well enough for my system for now.  I also added a switch to force the use of the ROM, since sometimes the bank switching can get into a messed up state and you need to force reboot off of the ROM.

The other thing I created was a second ACIA serial port, essentially duplicating the circuit of the stock ACIA serial port, but changing it to look at ports C0 and C1 instead of 80 and 81.

The TMS could be configured for anywhere, for the most part, but the ACIA chip IO port mapping is messy so they consume essentially from 80 to FF.  I went with the SORD-M5 configuration of putting it at 10 and 11h.  Although there might be issues with this...

Anyway, more about these modifications and such at the end of the month.


I ended up reassembling my RC2014 system, and started working on testing out the configuration.  I Was able to write a few BASIC programs to output to the video chip and to a TV I had hooked up, as you can see in the photo above.  I was noticing some weirdness though. The LEDs on the IO board were flickering when I was doing writes to the TMS, so I may need to move the port around to another location. I think I'm gonna go with the MSX setting of 98 and 99h.

I also became very aware that I do not yet understand how to get the chip to do what I want.


I was going to write the emulator using QT Creator for maximum portability, and also using the Z80 emulation core and frameworks I created for my existing RC2014 emulators.  But recently, after thinking about it for a little bit, I realizes that 90% or the emulator I need is already out there and already very well supported.  MSX.

There was really no need to get a whole video display system working with my existing emulator when I could start with an existing, debugged, well supported emulator, openMSX, and just create a new hardware profile for the RC2014 with my system's configuration... and with some changes to support my bank switching hardware and such.

I made a branch of openMSX on github to handle any/all of the changes I've made for it, which at the moment is just getting it to build on OSX/Darwin 10.14 correctly.

I also was messing around with my good old friend, the Texas Instruments TI-99/4A as it uses the TMS9918 chip. I figured that I could experiment around with how color and graphics look.  I'm not a fan of the TI's font, nor the MSX's font for that matter, but I figured it's a good platform to get reacquainted with the weirdness of the TMS and to see how this all might look in the future, perhaps.

This is of course just a screenshot from the impressive web-javascript TI emulator at

More as it develops...

Friday, September 28, 2018

More Laserdisc Stuff! A wild Pioneer CLD-V2400 appears!

I just picked up this Pioneer CLD-V2400 in full working order, and in excellent condition.  It was made in 1993, around the same vintage as my Pioneer CLD-S201... but with one major difference... a SERIAL PORT!

It's missing a couple of the more "industrial" commands that allow it to seek quickly (+/- 100 frames) without noticeable glitches/squelching.. so it's not ideal for laserdisc video games, which were crafted so that you could play a game non sequentially without seeing pauses as the disc seeks.  I guess it's able to move the head super quickly within the VBLANK section of the disk

I'm getting ahead of myself...

This thing has a DB-15 connector On the back for the RS-232 serial interface, which includes TTL Serial (0-5v) and RS-232 serial (+/- 12v).

Since I couldn't find my USB-Serial interface, I tried making a TTL cable, and connecting that via FTDI cable to my Mac... I wasn't able to get it to reliably work. I think it might be a that the FTDI/Mac combo couldn't do the 4800 baud rate or something.

Instead I made a DB15-DB9 Null modem cable, and decided to plug it into the 9 pin serial port on... something?

I had a hard time finding any of my machines with DB9 serial, but eventually remembered that my tiny Toshiba Libretto 50 has one! So yeah! Windows 98 and HyperTerminal it is... and it worked great!

Next, I went through the V2400/V2600 manual, (and the V4400 manual) to figure out some commands that I could do.

I had some experiments I wanted to do with using the "user area" of the on screen text of the player.

First of all, I wanted to see how to do it.. which you can see in this pic.  I had my CAV Duran Duran disc playing, obviously.

My thought is that I can do thing similar to the "Rollercoaster" project and just command the thing to play scenes, but it can be taken a step further.

Another option available is to get a user number press from the remote.  The user presses 0..9 and you get that back through the serial port.

It would be possible to make a modern game or interactive video thing using onscreen text for the output, and remote for the input.

The display area on this player is 10 lines of 20 characters each.  Not a lot, but enough for activities.

Perhaps I could encapsulate the game and logic inside of an Arduino would work... but that still brings up the TTL serial issue.

I scoured my basement, looking for my Belkin USB-Serial dongle, which I'm starting to believe I never actually had... I eventually gave up and decided to kludge together this monstrosity.

The nice serial cable I made was a null-modem cable, but the serial level interface (blue board) had the wrong gender and pins for my use, so i tacked on some wires to the correct connector.

The Arduino is a Pro Micro (ATmega 32u4/"Leonardo") made for another project. so it already had the microSD socket and external FTDI connector for a serial peripheral, so this went together substantially quicker than looking for the USB interface.

Regardless, this somehow worked... really well.  I needed to make a simple Arduino program that just reads in from "Serial" port, the USB side of the Leonardo and writes to the "Serial1" port, which is on pins D0 and D1.

The trick was to have both open at 4800 baud.  I had the LD side at 4800 baud, and the USB side at 115200, but that didn't work.

I've made it so I can type on my mac, and control the player... or have the Arduino autonomously control the player.

One of the things you can monkey with is disabling the squelch of the video and audio.  This is what blanks/blues the screen and mutes the audio while seeking, or while doing pause in CLV mode.  When it's off, you can play multispeed/stillframe with audio, stillframe on CLV (which doesn't really work, but it's neat!) and do chapter seeks while still seeing the content.  It's really fun to mess around with...

I think I need to make a script that seeks to the end of the disc to get the duration, then randomly seeks around, plays a second or two, and then repeats that... Especially with squelch off!