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.

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.  

Git repository: https://github.com/BleuLlama/IR-Lanc-Bridge

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

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:

• The SONY LANC Protocol
• Arduino.cc project: Serial-to-LANC
• Another LANC-arduino interface

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

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!

Finishing touches on LL530 v1.00 firmware

I'm currently cramming to get the first version of the firmware for my LL530 project out, so I can ship the first few ordered boards. (YAY!).

Quick backstory...

LL530 is a board with an Atmega32u4 (Arduino Leonardo/Pro Micro) and a few connectors on it so that you have a USB interface for Amiga/Atari ST/Atari mice, Atari controllers, and Amiga 500, 1000, 2000, 3000 keyboards.  Yes it even supports weird Atari controllers like Basic Programming's "Keyboard Controller" and Star Raiders' Video Touchpad, as well as the Indy 500 "Driving" controller that they made look identical to Paddles,... which are also supported.

Yes, there are other versions of portions of this, but I wanted more flexibility. I want to be able to just connect to the device, tell it that i have a mouse plugged in now, and it will just work... and in the future, auto-configuring the ports without even connecting... but i digress...

Yeah. I wrote a program in VCS Basic Programming via the Stella

emulator on my Mac.  Yeah. it's as cumbersome as it looks, but I'm

still freaking impressed that BASIC is even possible... it means only

one thing.. Warren Robinett is a god among men!

I'm getting off the subject here... okay...

Hey, Scott... don't forget the reason for this post...

Oh right.. Thank you Document McSubheading for reminding me.

No Prob..... now get on with it!

RIGHT.  So I'm trying to get all of the non-keyboard stuff working in one firmware.  I have a decent shell interface that lets you do all sorts of configuration stuff of the two ports, which I call "Port A" and "Port B".  I have a framework where you can pick the input device (joystick, mouse, paddle, etc) and then pick what it sends out to the host computer (mouse movements, joystick movements, various keyboard configurations.)

Now, the Arduino framework is kind of notorious for being slow in some respects.  That's the price you pay for ease of use.  One of the slowest is the port pin reads and writes.  For example:

digitalWrite( Pin3, HIGH )

 is a function that sets Arduino Digital Pin 3 as a HIGH value.  So internally, it looks at "Pin3", and figures out where on the ATmega microprocessor that maps to... The digital/analog pins from the Arduino are abstractions of the ATmega's actual ports.  for example digital pin 3 might actually be "PORTD" bit 5.  This function makes it so that beginners don't need to know that stuff... and what's more, all arduinos have digital pins 0, 1,2, 3, etc but generally map to different ATmega ports/pins... it might be PORTD bit 5 on a 328P, but it might be PORTG bit2 on a 32u4.  

Too much info.  TL;DR: digitalWrite() digitalRead() are an order of magnitude slower than just reading PORTG and masking off bit 2, which is near instantaneous.  (I should note that analog reads are slow, regardless, as the micro needs time to make the reading.)

I noticed this on the Eastman Theater sign project. I was using digitalWrite() calls to bit-bang out the data to the sign's shift register/LED drivers.  I was getting roughly 5 frames per second, when driving all 240 columns of 8 pixels...  When I switched it to direct bit writes, it went well over 60 FPS!

Mouse support....

I have all of the other controllers working, at least somewhat, and I've had a USB-Mouse interface using a 32u4/Pro Micro on my RaspberryPi/Amibian system for years now, so I knew it would work... but i was surprised when I finally got to working on the mouse device reading to find it wasn't working.  It was getting readings, but it was missing some... it was missing a lot of them.

To read a joystick, you only need to know "is it up now?"  "is it left now?"... not very time critical between readings.  However, for reading a mouse, you need to read all of the "gray code" sequence state numbers that it generates.  As it rotates left-right (the up-down axis is identical), it sends out, over two bits of the connector, a sequence of digits.

00 ⇨ 01 ⇨ 11 ⇨ 10 ⇨ 00 ⇨ 01 ⇨ 11 ⇨ ....etc

Moving left

00 ⇨ 10 ⇨ 11 ⇨ 01 ⇨ 00 ⇨ 10 ⇨ 11 ⇨ ....etc

Moving right

The mouse generates these regardless of you reading them. 

There was some slowdown in reading the mouse, so i was missing some of the readings... so instead of getting 00, 01, 11, 10, 00, 01, 11, ... I was reading 00, ... 11, 10, 00, .. 11, .. .. 01, ... 00,  which generated bad mouse movements, since those are sometimes recognized as left, sometimes as right, sometimes as completely invalid changes.

So it must've been the port reading?  Right?  That was my first thought too.  This thought was cemented further, when I tried out some stripped down firmware, which worked, but once i read from all three possible buttons, it would fail again.  I thought maybe the arduino framework was doing an analog read on one of those ports or something. I wrote some code to profile read/write times, and found that it was just as fast as expected.  (I had switched the port IO for this project to direct reads, without the framework long ago.)  (sidenote: Still not sure why commenting out button 3 had any affect... weird.)

So that wasn't it.

I eventually moved some simple mouse reading/generation code as a dedicated loop, which worked.. 

Next, I re-enabled my big switch statement that checks the input types, and checks the output types and does the right thing... to my surprise, it still worked.

I re-enabled some of the other polling routines... some are timing based, so they use the millis() function which of course has some overhead... and surprisingly, everything still worked.

Then I re-enabled the serial shell interface... and things broke... quickly!

But... the serial interface wasn't doing ANYTHING?!  what?!  All it's doing is first doing a

if( !Serial ) return;

The 32u4/Leonardo/Pro Micro will have major issues if you try to send out Serial data before it's done initializing that HID device.  This call just checks to see if the port is active.. I littered my code with them before Serial.print() blocks to prevent the thing from bricking again...  But even when the shell is active, i do a standard

if( Serial.available()) { .... }

to check if the user typed anything... then it pretty much returns...

The problem is... my assumptions were WRONG.

I threw some of these calls into my profiler, which is basically this kind of thing

startTime = millis();for( x=0 ; x<1000 ; x++ ) {    /* do the thing to test in here */}endTime = millis();

then it prints out (endTime - startTime)/1000, and you get the average time per loop.

if( Serial.available() ) { /* do nothing */ }

This took roughly 0ms per loop, so it's probably just checking a bit inernally...

if( !Serial ) { /* do nothing */ }

I thought this did the same sort of thing... Nope.  No matter what I did, 10ms.  Every time this is called, it blocks for 10ms.  No wonder that my mouse polling was failing! it was missing tons of gray code sequence states since the thing was almost constantly blocking in the "!Serial" check.

BLAGH!

It's feeling better now. :D

Anyway... Here's some more info on the project in general:

Links for the project are in flux right now; once I get the first version of the firmware packaged up, i'll be setting up a proper website/hub for it with full documentation of the project.  Until then, here are some links:

• LL530 at my Tindie store
• Controller Compatibility Chart... and my general notebook for research for the project 
• Firmware Version Roadmap

Testing the system is kinda fun!  Although that 7800 controller is pretty horrible.

Arduino-Midi for Sim City Music Playback...

Roland Sound Canvas SC-55, hooked up through a hacked cable to an Arduino Uno,

which is connected to... NOT THE MACBOOK because I FORGOT

THE STUPID USB-C ADAPTER AT HOME. GEEZ.

Was thinking in the car on the way to Interlock of a way to make the Sim City 2000 music thing better.

The project I'm talking about is to play the weird Sim City 2000 midi files at random intervals throughout the day, so that life feels more like Sim City. ;)

I have a python script that will play the songs on my laptop... (see below) but I want something more physical..

Roland MT-90. It plays midi files off of floppy disks to a builtin Sound Canvas.

Yes. I think it's a weird thing as well, but at least it sounds nice!

Was thinking of putting an Arduino inside of the MT-90, which would press the button sequence to: (switch on shuffle mode), (switch on random play), then (wait) then (play the next track)... (The arduino would press the buttons via relays, the way I did it inside the Yamaha Tape deck..

I was thinking that it might be nice to not have to hack the device, and have just a midi thing i could plug in to any midi device... I'd have it do the above with the MT-90, but it doesn't have any midi control sequences to control playback... just midi notes/tone generation stuff.

Then I took a step back and thought that if i just stored the midi files on a sd card, and just had the arduino play them itself out to a sound canvas, that'd do the trick! I found a 5 pin din cable, hacked in connections.... but I forgot my USB-C to USB adapter at home. Dang!

So it's not really a failure of a project *YET*, but it was a definite lack of success...

Here's the python script. It expects to be run on a Mac, with timidity installed, which will play the music. Also it expects the midi files to be in a "SC2000/" subdirectory. It's not the most elegant thing, but I hacked it together in a couple days...



#!/usr/bin/python
#
#  an attempt to make real life more like playing SimCity
#
#  It picks a random amount of time from 15-90 seconds
#  if there's silence for the entire thing, it will pick a random 
#  track in the SC2000 directory and play it.
#  then it repeats... until you ctrl-c out of it
#
#  v2 2017-07-28 - made more configurable, quieter output, class
#  v1 2017-07-27 yorgle@gmail.com
#
# Requires: - timidity to be installed (brew install timidity)
#   - OS X (10.12 tested)


import sys
import os
import time
import random
import subprocess
sys.dont_write_bytecode = True


class SimMusic:

# defaults
midicmd = "/usr/local/bin/timidity --no-loop {} 2> /dev/null" 
mididir = "SC2000/"
silenceTimer = 0
timerMin = 15
timerMax = 90
disabled = 999999
timeout = disabled

# constructor
def __init__( self, tmin = None, tmax = None ):
if( tmin != None ):
self.timerMin = tmin

if( tmax != None ):
self.timerMax = tmax

self.setupTimer()

def setupTimer( self ):
self.silenceTimer = 0
self.timeout = random.randint( self.timerMin,  self.timerMax )

def resetTimer( self ):
self.silenceTimer = 0

def stopTimer( self ):
self.silenceTimer = 0
self.timeout = self.disabled

def systemIsPlayingAudio( self ):
process = os.popen('/usr/bin/pmset -g' );
text = process.read()
process.close()
if( "coreaudio" not in text ):
return False
return True


def playRandomMIDI( self ):
self.stopTimer()

files = os.listdir( self.mididir )
fname = self.mididir + random.choice( files )

print( "Timidity: {}".format( fname ))
process = subprocess.Popen( self.midicmd.format( fname ), shell=True )
process.wait()

self.setupTimer()


def run( self ):
playingTimer = 0
print( "scanning..." );

self.setupTimer()
while True:
if( self.systemIsPlayingAudio() ):
if( playingTimer == 0 ):
print( "\n" )
sys.stdout.write( '\033[2K' )
sys.stdout.write( "\rAudio is playing... Waiting. ({})".format( playingTimer ))
sys.stdout.flush()

time.sleep( 1 )
playingTimer = playingTimer + 1
self.resetTimer()
else:
playingTimer = 0
if( self.silenceTimer == 0 ):
self.setupTimer()

self.silenceTimer = self.silenceTimer+1

if( self.silenceTimer > 0 ):
if( self.silenceTimer == 1 ):
print( "\n" )
sys.stdout.write( '\033[2K' )
sys.stdout.write( "\rShhh! {} of {} seconds has passed".format( self.silenceTimer, self.timeout ))
sys.stdout.flush()
if( self.silenceTimer >= self.timeout ):
self.playRandomMIDI()
self.setupTimer()
self.silenceTimer = 0
else:
time.sleep( 1 )

################################################################################

# put this in your main app as well.
if __name__ == "__main__":
simMusic = SimMusic( )
simMusic.run()

Building some RC2014 upgrades...

I've been working on upgrading my RC2014 Z80 computer for the past few months, but in a very low-impact-to-my-finances-that-can't-support-it-otherwise way.  This post will just go into explaining a few of the upgrades I have in mind,

First of all, my current hardware scheme, the "RC2014/LL MicroLlama" as I call it, is and has been fully functional in its current state, and is emulated well in my emulator.

I started working on a mass-storage solution for the MicroLlama, which I have slightly back-burnered this month so that I could attempt to focus on the 2017-04 RetroChallenge ("The Andy Project"), but I'll likely pick it up again next month, especially with some of the upgrades I now have in my hands, which I will now briefly talk about...

Dr. Scott M. Baker's Bus Supervisor Board

A ton of chips and a well packed board!

I just received a "kitted" version of Dr. S.M.Baker's RC2014 Bus Supervisor board. Major kudos to Rob Leisenfeld from the RC2014 community...

The short description of this is that it has some I2C I/O Expanders that sit on the entire bus (Data, Address, Control) as well as replaces the system's 7.37 Mhz clock board.  This can be used to snoop on the system, read/write IO, read/write RAM, etc... taken one level above that, you can use SMB's python scripts to upload data right into RAM, thus eliminating the need for a ROM module.

People have successfully used this to run 64k RAM-only RC2014 computers, and upload the program ROM from their Raspberry Pi. (Schematic, GitHub link to software)

It took me about 15 minutes to figure out the orientation of that crystal.
(Pin 1, the pointy corner, is in the bottom right)
Also, I'm not sure the jumper configuration is correct yet.

That's where my personal problem with it comes in.  As it stands, his project uses a RasPi to communicate with the board over I2C.  This is fine, however it does not fit within my workflow.

I do not really have a RasPi to use for dev work, so my solution is to take a tiny Arduino Leonardo clone ("Micro-SS" like this one), with a cable connecting its I2C lines to the Bus Supervisor Board.  Then, I'll make a thin Serial-I2C bit of software and making some desktop tools, perhaps in python to fit with the original from SMB.

My "proof of concept" for USB-I2C communications.
Here it's connected to an RGB color sensor.

The end result is that in my Z80 project makefiles, i can add a target for the generated .HEX files to be downloaded directly to the physical RC2014.

I've made a cable for my Micro-SS and have built my Bus Supervisor Board.  As you can see in the photo, this is it set up on a powered RC2014 backplane with only the standard IO module, and a few LEDs on a few data lines, so that I can test out everything before putting the CPU and RAM on there, potentially damaging them.

Obviously, it would also be possible to include a couple of ROM programs directly into the MicroSS, and possibly store a small one in the ATmega 32u4's EEprom as well.  Some buttons on the MicroSS could be used for injeting these pre-stored programs.  i could even see a program that generates a menu that the arduino can basically farm out to the Z80 to get user responses/menu options, etc.

Additionally, I can make a RC2014 bus - to - pac-man bus adapter, and actually deploy code-in-development directly to the machine from my desktop from the makefile/build scripts.  ... This is a dev tool I've wanted for about 20 years now!

Lots of possibilities!

I will put out another blog post and a github link for the supporting software, when I've got this working. (estimated - mid next month)

64k RAM and Pageable ROM

I also received this past month the boards for these two official RC2014 boards: the 64k RAM and Pageable ROM.  As you can see in the pic, i still need to order quite a bit to make these work.  Now that I have the Bus Supervisor board, the Pageable ROM is less interesting to my needs, although I may still adapt my RC2014/LL design to use these pieces instead.

You can see pics of these in the top of this blog post.

The 64k RAM will definitely work well with the Bus Supervisor board, however the Pageable ROM board has definitely taken a bit of a slip down my plate... Until I can get the parts in for the RAM (sockets, etc) I can use my existing unmodified 32k RAM board for the upper segment of memory ($8000-$FFFF) and my slightly modified second 32k RAM board for the lower segment of memory, I just have to manually enable it for read/write.