Wednesday, August 24, 2022

My Lego/Technic Saab 900 and Popup Camper

My mid-80s (flatnose) 1:12 scale Saab 900 Turbo.  I 3D printed my own set of 24-spoke "manhole cover" wheel covers for it.  I have a design for the "Inca" wheels too, but I can't get them to print right.

Rear shot showing the back lights and trailer hitch.

The trunk hatch opens!

And the hood slides open just like the real one. Also you can see the 3D printed steering wheel.

Trailer hitch? Let's hook up a trailer!

This is a 1:12 scale reproduction of our Forest River 2318G pop up camper... 

Let's look at that and all of its features in more detail now!

First, let's detach it from the car.

Lower the small support wheel first of course!

Lower the four stabilizers in each of the four corners.

Next, let's turn the crank to raise the top!

The lifting mechanism is based on the real one.  One string from the crank pulls a liftarm that slides, which pulls the four additional strings that go to each corner's telescoping lifter.  I used some "rigid" tubes to help guide the strings better.

The only issue is that by the time the force of the string pulling gets to the end bits of the liftarm, there's not a lot of power left... so it can lift the arms just fine, but not when the roof is in place.  So we need to remove the roof first...

Turn the crank and it lifts the four corners!

And now we can put the roof back in place.

Slide out the front bed...

and lower its support stabilizers

Next we fold up the end fabric support frame

and hook in the roof support bar

and then we repeat this for the rear bed.

Looking good!  Next we need to slide out the dinette.  

Look, i know it's ridiculous to have a slide-out on a popup camper, but this is based on my real camper that does this.  And it is ridiculous. :D

It just slides right out, no supports underneath needed.

Fold out the side frame and insert the roof support

The only remaining thing to do is to pull out the step that helps you get in easier!

There we go!  On the real camper, the entrance door is right there in front of the wheel.

And that's it! The camper is all set up now!
Here are some more pics of the completely setup camper, as well as the real one that it's based on...
which it's been sitting on this whole time! HA!


Friday, November 19, 2021

Rochester Maker Faire 2021 - Exhibit info!

Welcome! If you're here you either from using the QR code I had at Maker Faire, follow me as @yorgle on twitter, or perhaps from my YouTube channel ... regardless... welcome!  This is my project blog thing and I post info about all of the esoteric and weird things I work on here.

This post is meant to provide more information to you about all of the projects involved.  Follow this blog for more updates about these projects; links to videos, source code, etc.

Projection Mapping

For this, I got inspiration from this video on YouTube where they played this video of the Happily Ever After fireworks show at Walt Disney World onto a Lego model of "The Disney Castle".  It came out awesome, and I wanted to do something similar.

While I'd love to have that Lego set, I don't have any place to put it, and on top of that, I don't have $350 to spend on it... however, Lego released the much more budget-friendly Mini Disney Castle which sells for $35 and still has some excellent details and even comes with a Mickey minifig!  I used this as my starting point.

I dug out my Dell short-throw 1080p DLP projector, and projected it onto the castle.  It didn't match up perfectly, which I had expected.  I bought a second Lego Mini Disney Castle for parts, and made a bunch of modifications to the model to add a few small spires, adjust heights and proportions.

Then I built a base using some gray rocks made out of Lego, to line it up perfectly with the projector.

For MakerFaire, I also made a projection screen to set up behind it.  For this I used some 1/2" PVC pipe and fittings, and made space for a roughly 2x3 foot screen.  For the screen itself, I used about a yard light-blocking fabric from Joann Fabrics for about $8.  The fabric I picked out was tan, with a white backing. I'm using the white backing side for the screen.  The main criteria I was looking for in a fabric was something with as little surface texture and depth as possible. I think this material choice was a great find!

Lighting Effects for Lego Models

I've loved the idea of using small vignettes to display my favorite minifigs, and I was super happy to find instructions from @benbuildslego to build a super tiny Cinderella Castle, long before the "Mini Disney Castle" was released. I highly recommend his instructions.  And I have no plans to make a tiny projection mapped version onto this model. Lol.  Anyway, one of the other instructions of his that I ordered included my favorite geodesic sphere in the world... Spaceship Earth from EPCOT.  (aka "that big golf ball thing").

I thought it would be great to light it up just like the real thing, so that's what I did.

I built up his design, but I added some supports around the edge for some Technic pieces to support some lights.  I also 3D printed some Technic-compatible holders that I used to mount some of these tiny NeoPixels into.  I designed the element so that the lights can be adjusted and pointed exactly where I wanted them to go.

The NeoPixels are wired together using some kynar/wire wrap wire so that I could be sure it could be routed well, and not be too obvious.  All of this is wired back to an Arduino to control it all.  Any model of Arduino (Uno, Leonardo,  Mega, etc) would work, but I used a "SS Micro" as I had an extra one and I love the formfactor of it.

The code, soon to be available in Github, consists of a set series of "scenes", which the 10 Neo Pixels can display.  The scenes can be faded between, randomized in intensity so that they've got some life to them, and randomized in duration and sequence.  The code demonstrated just cycles through the four animated scenes forever.

The scenes are: 
  • "Night" - dark blue, as though it's just night time by itself
  • "Glow 1" - the wonderful color mix of orange, reds, gold and lavender
  • "Glow 2" - same as Glow 1, but roughly mirrored left-to-right for some variation
  • "Twinkle" - just like "night" but with a twinkle of cyan on the lights occasoinally
There's also two special lights; one for the obelisk/fountain in front of the sphere, and one for a spotlight on the Mickey minifig atop the sphere. These operate externally to the animation sequences described above.

Monday, November 1, 2021

Handheld RC2014 System (RetroChallenge (sorta))

One of the great things about making stuff is that you can make stuff that doesn't yet, or shouldn't exist.  

I honestly didn't get anything done on my RC2014 projects for RetroChallenge this year, other than an idea, and some 3D printed stuff within the final few days of the month.

I've had it in my head for a while to make a gameboy formfactor RasPi system for a while now, even though I already have a portable Pi emulation system in my Atari Lynx enclosure.  So I found a model for the "super retropipod" enclosure on Thingiverse and printed it out, and ordered and then modified a 3.5" lcd and shoved it all into the case.

I decided i didn't want to make a PCB or hack up a perfboard to support tact switches, and I had a bunch of largeish 12mm tact switches, so I modeled and 3d printed mounting boards for those too.

Then I had an awesome-horrible idea.  I would mount a RC2014 inside the enclosure as well!  If I managed to make the enclosure a little thicker (about 1cm) I could easily fit a RC2014 mini or micro inside the case along with the pi and all of its fun stuff.  I could even probably also fit in the TMS9918A video card piggybacked onto it inside the enclosure.  So I modeled and printed out the thickness extension too!

Long story short, I have the beginnings of my ultimate multipurpose Pi/RC2014/Llichen-80 handheld!  And she's a chonky beast too!

I modeled and printed a piece to sandwich between the layers of the "pi-boy" enclosure I printed, and added a space for a nice switch for power on the side.  I still need to wire it all up, but I'm on my way to having this thing be AWESOME!  

Although I still want to make a "tall-boy" at some point... take two GB DMG enclosures, and extend the screen space to be taller, and put in a rotated, vertical monitor in the space there.  eg, use a 4" or 5" lcd in portrait instead of a 3.5" in landscape...

Next actions on this project:

  • Wire up the buttons to the GPIO header
  • Wire up the LED on the front panel to the GPIO header
  • figure out a power solution for the system (batteries, recharging, etc)
  • Mounting solution for RC2014 inside the enclosure without it moving around
  • Make a 2-board backplane for the RC2014 so I can also have the TMS board internally
  • Wire the TMS to the monitor too, and figure out a quick way to switch inputs... perhaps two NC momentary buttons that disconnect the monitor from each of the two inputs, so it will auto-switch to the other input. (or short the input to ground via 75Ω resistor?)

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


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