Tuesday, October 5, 2021

Lego Lighting braindump (for Rochester Maker Faire 2021)

For this year's Rochester Maker Faire, I'm going to be showing off a couple things related to lighting up Lego stuff.  This post is just meant to show where I am with the two things (for now) that I'll be showing off and what's left to do.  This year, I will be showing off stuff in the "dark room". I've wanted to do something back there for a while, and without Interlock or RLUG exhibiting this year, and at Dan's suggestion, it seemed like a perfect time to do it!

Spaceship Earth lit with LEDs

This one is setting up an "SS Micro" Arduino (my favorite 'ardy form factor) to drive a handful of tiny neopixels to simulate the nighttime illumination of Spaceship Earth in EPCOT.  This is based on @BenBuildsLego's EPCOT design.  Buy his instructions, they're great!

Currently, I have everything as seen above.  The model is essentially complete, and the arduino code is written with a LED strand "scene" concept.  I've started to add a few transitions to go between scenes, randomize them, etc.  Here's the current TODO list for it:

  • Add illumination for Mickey
  • Add illumination (and update the baseplates) for the fountain to be lit up
  • More decoration around SSE
  • Redo the wiring to be less conspicuous - replace the servo wiring with kynar/wire wrap wire
  • New version of the light mounts?
Now, that all said, everything as it is now is sufficient to be exhibited, the above are all icing. :D

Projection Mapping on the Mini Disney Castle

After seeing this done with the fullsized castle, I had to do it for myself on my "Mini Disney Castle", set #40478.  I tried it with the same source video, and it has promising results. There are a few issues with it that I can fix by Maker Faire.
  • The proportions differ a little from the real Cinderella castle slightly, and do not include the side walls.  
    • I need to buy a second MDC and use it for parts to adjust the model to fit the one in the video properly.
    • Until they're back in stock, I can mock up the additions using Lego elements I already have.
  • Video needs to be edited
    • about 70% through, there's a slight jostling where everything shifts by a few pixels
    • There is no fadeout at the end, so that needs to be done
    • or remove the fadein from the beginning so it just runs forever.
  • Playback device needs to be figured out. 
    • Perhaps a Pi connected directly to the DLP, that launches OMXPlayer or VLC on boot, with looping?
  • Need to figure out a good tabletop + back screen system that's easily reproducable rather than the quick test seen in the photo above.  
    • I need to be able to just plop everything down at MakerFaire without needing to spend lots of time to tweak things endlessly.
    • The geometries need to be 100% figured out and perfected before then.
  • Try my other DLPs for best fit
    • The above is with my Dell Short-Throw projector, which means it can be closer, and the background will be larger, which is really nice
    • The BenQ projectors might have better results though and need to be tested.
    • Perhaps figure out all of the geometries for both projectors and bring one as a backup, since they're all self-refurbed anyway.  (leave the backup(s) in the car)

Saturday, October 2, 2021

RetroChallenge 2021-10 intentions (RC2014 Projects Braindump)

Hi all.  So I've decided to settle on working on various RC2014-based projects for this RetroChallenge.  I have a few related projects that I'm kind of in the middle of and have set aside for various reasons... the primary of which being my "ooh... shiny!" reason, where I get pulled off existing projects to start something else thanks to my brain.  ;)

Most of my RC2014 projects are all intertwined so it makes sense to kinda work on all or each of them simultaneously...

Anyway, here's a few things I'd like to work on this month:


"Lego Brick" RC2014

This is my main RC2014 system.  The display on it somehow developed a weird glitch on it that looks like Lichtenberg lightning print.  
I have a spare LCD panel that I can swap into place, i just haven't done it yet.  

Llama Vampire-Storage system (LLVS)

This is my "storage over serial" system that I started working on in the past.  It basically uses something like ANSI escape sequences over your serial console to do disk accesses. It could eventually be used for other devices as well like network and printer access, reatime clock, GPIO, etc.

Eventually, it would be great to have the LLVS "type in" a BASIC program that is a simple bootloader that will load in a custom CP/M kernel with  LLVS routines, so that a super cheap (and slow) CP/M system can be booted without boot roms, CF card module, or any of that expensive stuff.  

Also to be included with this are tools that natively talk the LLVS protocol so that you can retrieve and store content to your host machine from "standard" CP/M systems.

Obviously this also requires a host/terminal side of things too, which is being implemented in python currently, but could easily be reimplemented in C/C++ to be compiled in with the Pi Zero Serial Terminal module, so that you can use the Pi Zero's SD card as your CP/M storage device.

RC2014 Pro Build

I have most of an RC2014 Pro kit around, and I'd like to build up the various parts of it including the backplane, compact flash storage, and so on, so that I can finally do a native CP/M boot up.  This could be combined with the LLVS above to allow for easy transfers to and from the CP/M system and your "host" system.

I have a few modules that I want to build up and test and experiment with... i've just never really dug in to work on it.

Llichen-80

Llichen-80 is a CP/M kernel-based system that takes my LLVS-based system a step further, and adds in the TMS-9918A video card as its main graphics display.  This could be used simultaneously with the standard terminal, or as a replacement to it.  I haven't quite figured all of that out yet.  

I plan on making a few CP/M programs that configure the TMS and download files from the mass storage device into it, for loading fonts, graphics, etc.  Or just to use it for console output.

For use with a single composite display, I also have an hardware video switcher (simply two relays with a digital gpio input) that could be connected to a digital out from the RC2014 or as a GPIO line from the Pi Zero on the Pi Zero Serial Terminal card.

I have some of the basics of this working, but nothing really solidified.

The Llichen-80 system consists of an RC2014 CPU, Clock, Pi Zero Serial Terminal cards, along with the TMS9918A video card.  The Pi Zero Serial card is set up with a PiZero W, and is not running the standard PiGfx kernel, but instead running linux, so that it can run my python terminal application, so that i can add in all of the LLVS code

RC2014 Mini / Micro Mods for CP/M

It's well known that by removing some components on these boards, you can use them as a standard CPU module when upgrading to a CP/M system... replacing the fixed RAM/ROM for the switchable RAM/ROM and so on.  But it would be nice to be able to simplify this so that the RAM/ROM on the RC2014 Mini or RC2014 Micro could be made to be switchable using a simple jumper to connect to the logic needed to do the switching.  Not sure that this even makes sense being that the Mini CP/M upgrade exists, but I'll be thinking about it...

RC2014 Peripheral and IO Switcher Traffic Cop Thing

This one is more of a musing about a new Z80 system architecture, but it could be prototyped using lightly modified  RC2014 modules.

I feel like a peripheral manager type of card might be useful for a new system... one board that has ALL of the logic for peripherals, to switch them on and off, so that peripheral cards needn't have this logic repeated on all of them.  Then it could be vastly simplified for chip count.  It could handle catching bus requests for reading/writing memory or port based io, and work it out to be a single enable/disable line to be run to your peripherals.  That way peripheral cards could be made much simpler, and more easily moved around in the RC2014 memory and IO space... perhaps even live while the system is running.  It would be easy to make it such that any peripheral could be moved to any address, enabled, disabled, etc. Hmm...

Thursday, August 27, 2020

LaserDisc Capture Device Ecosystem


Diagram of the capture system

I've been doing a bit off and on with my Apple IIc (Early model, upgraded to Rom4X) and my LaserDisc player (Pioneer CLD-V2400), now that I have it all working.   I've created a video switching device (less prototype-ish version of it coming soon) and have made a few different serial interface adapters so I can control the LDP from the Apple IIc, Tandy "Model T" line, and my Amiga.  I plan on having stub BASIC programs for each in github eventually, here on my LaserDisc catch-all repository.

But this brings up the issue that it's a niche project for a very esoteric and specific audience.  That is to say, vintage computer enthusiasts WHO ALSO have a LaserDisc player, WHO ALSO have specific LaserDisc titles... It's the Sega 32X issue all over again. ;)

So... how to bring playability ("play" in the sense of "playing games created" as well as "playing the video discs") to a larger subset of the vintage computer enthusiasts... and also reduce reliance on super heavy players with large spinning plastic discs in them...  Of course the answer is Raspberry Pi!

The Idea 

The basic idea is to use a Raspberry Pi (Zero hopefully) as a standalone LaserDisc Player simulator.  More on that specifically in a future post, but the goal of this post is to talk about getting content for this simulator.  And, yes, there are LD simulators/emulators out there, like "Daphne", but they're generally for Arcade machine use, and simulate older players (like for Dragon's Lair), and they work VERY well, but they're quite expensive.  This will be a solution that may not work for arcade machine applications, but for home/game/toy/experimenter use, it will be super-cheap (no more than $20 total for the Pi + Serial interface... lowering the bar of entry substantially.

So for capturing a disc, One method might be to just capture the audio and composite output of a disc, and have the PI run something like the VLC player application, which might still be the solution, but I thought I'd experiment with making a custom player, since it will probably be cumbersome to do this with VLC, being how there is a large level of control needed.

The issue comes in when you realize that playback requires frame-specific actions being done with the disc itself.  This is usually fine, but for some content, there's a 2-3 pulldown put in to convert the original 24fps film content to 29.97fps NTSC composite-video LaserDisc content.  The short-short version of this is that if you were to just step through frame by frame, you'd see repeated frames, as well as some frames that are interleaved with each other.  This is not what consumers expect when they hit frame-forward or frame-backwards on their player.  Instead, when you use those functions, the player jumps around, skipping duplicated as well as interleaved frames.  This is handled invisibly by the player, as it accesses the frames from the disc, which are marked as being "full frames".  (this is a gross overview, but generally correct-ish.)

So you can capture the video stream, and play that back via VLC (or other media player) but the results won't be accurate to a LDP.  You'll have to manually skip frames, and offset per the 2-3 pulldown... it gets messy, but you can get an "okayish" approximation.  This is what my Javascript "Rollercoaster" laserdisc simulation did.  And it worked decently.  But it's not good enough.

The Domesday Duplicator Project

I had the idea to capture discs in a more "raw" form, so I started looking into what was available for this.  I looked into the Domesday Duplicator for capturing LaserDiscs, and use their "ld-decode" software to decode it and play it back, since it would be ideal.  I could capture the raw RF content stored on the LD, and play it back exactly as a LDP.  There are some issues with this though...

First of all, I do not have the right LaserDisc player to capture the content, nor full documentation about the hack necessary, nor the expensive hardware needed to sample the RF stream... It is a substantial overhead to capture discs.  Perfect for their archival use, but it's massive overkill for playing some homebrew games.

Secondly, for their captures, each side of a disk requires approximately 103 gigabytes of storage space, which is inconvenient. ;)

My Solution

The solution I decided to run with is to simply step through the disc, frame by frame, and capture each composite video frame individually, then capture the audio separately, and sync them back up in the playback application.

Video would be captured frame-specific on the disc... that is to say only unique 480p-ish frames will be captured, so file "32908.png" will be frame 32908.  No need to convert or deal with if a title has 
a 3-2 pulldown, or it's 29.97 fps, or whatever...  Playback of video might be odd, but this could always be augmented with video files for playback of segments, using these files as still-frame files.

For video capture, I'm using my Canon Optura Xi DV camcorder as a video-firewire bridge, and capturing the video frames using imagesnap, which can save jpeg or png images captured from standard Mac video sources, including firewire-DV connected devices.  It could just as easily been done through some USB Composite AV capture device, but I do not have access to one.

Each of the pairs of audio tracks will be captured directly from the analog audio output from the player.  (I have not done this part, but I plan on using sox to do this, probably, although some tests I've done so far have had dropouts while recording... which is less than ideal... audio capture could be accomplished using a more modern computer or recording device...)

The diagram at the top of this post shows this workflow.

For controlling the LDP, I have a simple python script that connects using the standard serial libraries to a USB-Serial interface, which is wired to my player via RS/232 (4800 baud).  I don't have a store-bought USB serial device, but any of them should work fine.  I decided to just throw together something using stuff I had, which can be seen in this image:

This is my USB-RS232 interface. There are many functionally like it, but this one is mine.

There really is nothing special to this, it's just a USB-RS232 adapter.... using an old USB-Ipod serial dock adapter, FTDI extension wire, and then a cobbled-together TTL-RS232 level shifter. :)

Results

All of this is working as expected. (python script will be posted to github soon.)  I have the LDP spin up the disk ("PL"), seek to the lead-out (end) of the side ("FRLOSE"), get the frame count ("F?"), then seek back to frame 0 ("FR00000SE").  Most discs seem to have between 32,000 and 45,000 frames per side, providing about 30 minutes of content.

Each frame of 704x480 (I know, i was expecting 720x480, but this is what I got.) as JPG is about 140 kilobytes, and as PNG is about 600 kilobytes.  The issue with it though is that it was slow to capture.  The frame seek and stepping was quick, but the capture tool was slow, capturing about 27 PNG frames per minute, or about 35 JPG files per minute.  This would be hours to capture a single side of a disc.  Which is fine, since it's completely automated.  It would produce about 7 gigabytes of video frames per side.

I experimented with capturing audio as well.  I couldn't capture from the firewire/DV stream, but I just hooked the LDP directly in to the Mac Mini I was testing with.  I used SOX to capture some content, and it had a few dropouts.  This could have been because the computer is ancient... So more tests are necessary on that front.

The plan for the capture software is to have it query the LDP to get more meta-content out of the disc as well.  It can get data about the disc, player serial number, number of audio tracks, etc.  From that it could completely automate capturing each of the two potential pairs of  audio streams, or as individual tracks, depending on the needs of the disc... as well as all video frames, and perhaps a DV stream as well... maybe.  


Remember to set the DV Camcorder/Bridge for "video in"

Currently, I've got the software doing the following process:

  • Initialize the player:
    • "PL" Spin up the disc, and "Play"
    • "FRLOSE" When that's done, seek to the frame at the lead-out at the end of the disk
    • "F?" Query to get the current frame number (the number of frames)
    • "FR1SE" seek back to frame 1 on the disc (*)
    • "SR" Step in reverse, back 1 step (*)
  • For each frame:
    • "FRxSE" seek to frame x (the current frame number)
    • run: "imagesnap outdir/x.png" to capture a video frame to a PNG file


This is currently working.  Eventually, I'll add in the additional commands to query available audio tracks, and run "sox -d discname_audio.wav" to capture that.

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,

enable_uart=1

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":

#!/usr/bin/python

import RPi.GPIO as GPIO
import time

print "Resetting the RC2014."

# setup GPIO4 as an output
GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)
GPIO.setup(4,GPIO.OUT)

# send LOW (reset) for 1 second, then restore HIGH (normal run)
GPIO.output(4,GPIO.LOW)
time.sleep(1)
GPIO.output(4,GPIO.HIGH)

print "Done."
# return to high-z state
GPIO.setup(4,GPIO.IN)

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:

#!/usr/bin/python

import RPi.GPIO as GPIO
import time

red = 18
green = 12

GPIO.setmode(GPIO.BCM)
GPIO.setup(red,GPIO.OUT)
GPIO.setup(green,GPIO.OUT)

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

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

for dc in range(100, -1, -5):
r.ChangeDutyCycle(dc)
g.ChangeDutyCycle(100-dc)
time.sleep(0.01)

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

except KeyboardInterrupt:
pass
r.stop()
g.stop()
GPIO.cleanup()

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:

disable_overscan=1
display_rotate=2

overscan_left=0
overscan_right=0
overscan_top=5
overscan_bottom=5

sdtv_mode=2
sdtv_disable_colourburst=0

framebuffer_width=320
framebuffer_height=288

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