BL-328 Computer: The keyboard

I was going to integrate this into the megapost for BL328, but there was enough here that I wanted to give it its own post.

For a while, I was thinking that I wanted to use a PS2 keyboard for my BL-328 computer.  This would have worked well; being just software serial to receive PS2 messages from the keyboard, and sending down RS232 keys, or just integrating it right into the main board of the device, using the above.  Space was getting tight on the main board, but I could have made it work.

One fateful trip up to Active Surplus up on Queen Street in Toronto, Canada changed that idea.  (NOTE: this is one of the reasons I love browsing there.  I wish they were closer!)

I found this.  It's a Commodore 16 keyboard.  I remember looking up Commodore 64 keyboards at one point, and they were a simple matrix.

Keyboard matrices work pretty simply. You have a grid of wires in the horizontal and vertical.  At each intersection, there's a switch (one key on the keyboard).  To "read" it, you send out a signal on each of the horizontal lines, then read in through each of the vertical lines. If you see the signal on the vertical line, you know that the intersection of that vertical with the horizontal that you sent out the signal on is where there's a key that's pressed down.

I made an interface for this using an old serial Arduino board, a Seeed Studio shield kit, and a bunch of wire. Above you can see the early version of this before I had everything figured out.  The above worked somewhat, but had to be directly plugged in to an Arduino.  I've since added a FTDI header for communications, as well as switching around one line to he header.  On the Arduino boards (and on this board) Digital 13 was broken out to an LED for display.  This interfered with the keyboard scanning, so I had to rewire it a bit.  The topmost red line was swapped down to be just below the bottommost line.  It made the code a little confusing, but it all worked out.

In a testing configuration, directly wired in to an Arduino Pro.  Notice that I'm using a Commodore 64 keyboard instead of the Commodore 16 keyboard purchased/shown earlier.

Detail showing that one rewired line on the controller board.  This is also after I mounted the Arduino, Shield and keyboard on a piece of lexan.  Rubber feet on the bottom, underneath the keyboard keep it nice and sturdy.  This also shows the three-wire serial at the top of the image, which connects it to the host computer.

Hooked up to a test display to get a feel for how it would work.

And as a part of the completed system.  CPU board is in the red project box, with a battery pack sticking out from it.  Keyboard and controller sit on the bottom of the image.  Between the two is the video display module, sitting on its plexiglass monitor stand. I also settled upon a color scheme for the keyboard as well.

Tiny FTDI adapter for the D15 Stepper Motor Controllers

Here's a quick one. I wanted a VERY compact FTDI interface for the D15 devices, that didn't offer any IO pin access, just so that I could try building stuff to the Atmega 168 in there, and chat with it through serial.

Rather than using the cable I made and showed in previous posts, I decided to just do point-to-point soldering of a 6 pin header directly to a D15 connector.

The results are that I have a very compact device to play with.  It's very portable too!

Microphone Mount for my Voice Recorder

I like to audio record stuff, and have since I was a kid.  I recently got a Sony ICD-PX820, which records to MP3 files, accessible through USB, which is super handy.  It has a proprietary database file that contains the time and date of the recordings, and probably some other information. I somewhat recently reverse engineered this file enough to retrieve some information out of it, and made this available through github.

One of my minor issues with it, is that although it does record decently through the builtin microphone, it's mono and of limited dynamic abilities.  I found that I could get decent recordings by using the stereo mic I bought many moons ago for use with my DV camcorder.  The Sony has a mic jack on it, which is perfect, but it only has two gain settings "High" and "Low".  It's enough to get by, until I buy a real portable recorder.

The one problem I had with this setup though is that there was no way to easily carry it.  I decided to make some sort of mounting adapter to attach the microphone to the voice recorder.  The mic came with a clip with a hotshoe/tripod mount on it, as well as a little extension arm which also has the same abilities.   I decided that the best way to take advantage of this was to mount a screw through the case of the voice recorder, and attach the mic to this.

I started by mapping out the best locations for screws. I decided to make two holes, so that I would be able to switch it around if I needed to.  The screws I have, have heads that are a little too rounded, so they force the battery cover up a little bit, but it's good enough for now.

In the future, I'd like to try flatter-headed screws for this design.  I'd also like to perhaps try a 3D-printed thing, which the voice recorder can be snapped into, and the microphone slid into the bottom, to make it more sleek.

11 Digit, 7 Segment Display

An early test result, showing text and millseconds since power-on.

About a year ago, I bought a few 11 digit, 7 segment red LED displays from Active Surplus up on Queen Street in Toronto. (Excellent store.  If you're into hacking stuff at all, it's well worth the trip. Look for the monkey on Queen street to find their entrance.)

This past week, I wasn't sure what to do at Interlock on Tuesday night, but I had recently re-found these displays, so I figured I would finally get them working.  I hit Radio Shack to get a Seeed Studio Arduino Shield ($10 with a mess of components, probably the best deal in all of Radio Shack.)

The display with a header soldered on, and the shield with its assorted parts.

I was all set to figure out how to reverse-engineer the pinout on the bottom of the display; I googled for the LED module, and found specs on those, and then on a whim, decided to check on the entire module board, a Rohm LU-3011, and found the jackpot, this post about figuring out the pinout.  It suddenly became very easy to do this project.

The two key things gleaned from that above post, which I have mirrored here, are this table of enables for each of the 11 digits:

Digit	1	2	3	4	5	6	7	8	9	10	11
Pin	1	2	3	4	6	8	10	12	14	16	18

and this image, showing the pin mappings of the segments:

Mapping of the segments to the pins on the header.

The basic way these displays work is that all of the 7 segments (plus one decimal point) are all tied together to the pins specified above.  Then the anodes for each of the displays are broken out to the pins in the table above.  So to draw a '7', you would set all of the segments to LOW, except for pins 11, 19, and 7 which you set HIGH.  Then to turn on a specific digit, let's say digit 11 (rightmost), you set the digit enable pin 18 to be an output, and set it LOW.  Set all of the other digit enables to be inputs (tri-state, not low or high), and only position 11 will show a "7".  You repeat this for all of the 11 digits in the display, and you can display 11 full digits from just those 19 pins. 

In my code (available below) I start at digit 1, and work down to digit 11, enabling each one, in turn, showing its segments, waiting 1 millisecond, then disable that digit, move on to the next one.  Because of this quick display time, and to preserve brightness, I did not put any current limiting resistors in the mix.  Perhaps this was a bad idea, but it works great for now. ;)

I soldered a pin header on the display, and built up a shield to plug it into.

All of the digit enables wired up.  The top ones are a bit messy. Sorry about that.

I wired it up such that the digit enables and segments are wired directly to IO lines on my Arduino.  This used all of the IO lines, minus the D13 pin, which has an on-board LED.

The code that I wrote (available below) lets you do arbitrary digits per character, so that i can do (primitive) alphanumerics, or do animation patterns, etc.  I also store the decimal point as a separate character going in to the display code, so "3.141" is five ascii characters going in, but a flag is set on the '3' position saying that this digit should also display its decimal point, so it only consumes four digits in the display.

just testing out all of the segments and digits

For now, it displays a nice clock and some animations on my desk, but I plan on changing it around a little in the near future.  I want to use the D13 line as one of the segment enables (probably decimal point) and move the segment enables off of the Serial Receive line.  That way i will be able to control it via serial to display patterns, animations or text content.  Since the hardware serial port is hardwired to 0 and 1, and I will be using the TX line for the LED displays, I'll have to instead use the Software Serial, with only its Receive line mapped to an IO pin, and its Transmit line mapped to junk. I've done this before and it works well.

The code for this project is available in my Geodesic Sphere github repository.

This project was constructed and started at the Interlock Rochester hackerspace.

Barcamp Rochester Spring 2013 - Ridiculous use of Video Tech

On display at Barcamp Rochester this year was my Amiga-Genlock autotumblr setup.  It's a mix of technologies that span from 1985 to 2013.  It's fun, ridiculous and here's what's happening with it.  (Note: the complete list of technologies used is at the bottom of this post.)

Here's the basic workflow as it was planned:

And here's the slide I made to describe the system in Deluxe Paint 3, which is close to the same thing, but a little more (less?) informative: (Note: the color cycling is not available for this display, sadly.)

And here's a snapshot of it from the system itself, with some MST3K overlay goodness:

The Amiga 1000 is running Deluxe Paint 3.  You draw on a color 0-backed canvas.  The Amiga has an 8 meg ram expansion board attached to it via DataFlyer expansion module, and was running two floppy drives.

The Amiga 1300 genlock (which is hidden underneath the Amiga) replaces anything that is color 0 on the screen with the video input.  The video input in this case is connected to the old-school Minolta vidicon-tube video camera.  This gives us the Amiga graphics over top of the video coming in. I should note that all of this happens external to the computer itself, in the anlog video path.  The only thing going into the computer is the sync signal.  This means that if you were to "save" an image in Deluxe Paint, you will get only the mustache you drew, not it on your friend's face as well.

It's that overlayed image that we want here, so we feed that output video signal into the DV camcorder, which is acting like an AV-DV bridge in this case, only that we're ignoring the Firewire DV output from it.   Instead, we use a feature on this particular camera, in which it saves a screenshot of the current video to the SD card you have installed with it.

I should note that this camera came with an 8 meg SD card.  This should give you a sense of scale for the vintage of this thing.  I have instead replaced this with a 2 gig EyeFi card.  This EyeFi card is linked to my Macbook Pro via the wifi access point on the table.  The Eye-Fi software saves its content into a  Dropbox folder.  When a picture comes in, it then magically gets copied up into the cloud.

Once saved there, a script at IFTTT.com (If This Then That) takes the photo, and puts it into a tumblr post, which is then viewable by all in a standard way.


Here's a list of all of the hardware and technologies used to make this happen.

• Amiga 1000 (Spring 1986 vintage)
• AmigaDOS 1.3 (1988)
• 7.16 MHz 68000 processor
• 512k byte RAM (graphics, cpu ram)
• Deluxe Paint III software (1983)
• Commodore 1300 Genlock
• Dataflyer 8 megabyte RAM expansion (1991)
• Sony Trinitron 9" monitor
• Minolta K-520 Tube Video camera (1985)
• "VHS" connector, with custom power supply and AV interface connector
• Canon Optura XI DV Camcorder (2003)
• Eye-Fi Share (2007) 2 gig SD card
• WiFi Access Point
• Dropbox folder syncing software (current)
• Linux Laptop running Ubuntu and Dropbox software (current)
• IFTTT script to post new Dropbox items to Tumblr (current)
• Images posted to http://amigapics.tumblr.com (current)

So... what happened?

In practice at home, this all worked well, both going through my home access point, as well as through the extra access point, connected to my laptop directly (whose wifi-based internet access was shared through the AP).  But once I got it all at RIT, that's where things started to break.

First of all, I forgot my Amiga floppy disks at home, so I had to run home to grab those.  Oops.

Next, there was a sync/color issue with the genlock when i got it all connected.  I'm pretty sure this is because of two things.  First, the Amiga doesn't sync with the genlock before the Kickstart disk is loaded... and without this disk on-hand, I couldn't fix this until I had gone home to get them.  Secondly, I think the RGB connector on the genlock is faulty, causing it to make a poor connection with the system.  I need to examine this more.

Next, the wireless network at RIT prevented me from re-sharing its network on my Mac.  It claimed some sort of 802.1x protection or somesuch. Next up was to get the Eyefi and macbook directly onto the RIT network. The Eyefi card I have (not sure if modern cards are like this) would not connecto to the RIT networks since the network required username/password, whereas the Eyefi software only supported a password for the network settings.  The Barcamp network dude helped me get both onto the unprotected RIT network (unlocked to the devices via MAC address, rather than user/password).  Unfortunately for some reason this didn't quite work with the card and laptop either.  I'm not entirely sure why.   I then had a friend with a linux laptop to share his wireless connection out through his wired ethernet, which then was re-shared via the access point I brought.  This kinda worked. but at rediculously slow bitrates to be useless.

It was pretty much at this point that I just gave up on the wireless aspect of the Eyefi card, and would just plug the SD card into my laptop occasionally and manually copy the files into the Dropbox folder.  Oh well.

Other than that, It worked pretty well.  All of the images captured are available on the tumblr site at least for now.

Here's some of them as well:

Brian and Skip at the Interlock table

Chorn talking with someone

Me, testing out the system

Dennis being frightened by a deadite.

Some Deluxe Paint fun

Just like old times, the Amiga crashed a few times.

Video feedback

Chris

Anamatronic Avian: Skeleton Experiments

I'm about to start making the skeleton for my animatronic Tiki-Room Macaw.  Rather than futzing with drawing up detailed plans in some cad program, Iv'e decided to instead get the basic shape made, and then just build one out of foam core.  My thought was that once I have the shape worked out, I'll disassemble it and come up with plans for 3d printable parts that can be attached together, and eventually some vacuum formed parts as well for the head and beak, which need to be lightweight... although I'm starting to think that they could all be 3D printed, with a skin stretched over them for feathers and fur, after seeing the posts on Hack-A-Day about using acetone vapor to smooth out parts... anyway..

One of the things I was unsure of was the control linkages, and how the articulation points can be made.  It needs to have a few points of articulation to match the birds in the Enchanted Tiki Room:

• Perch rotation - 270 degrees, spins the bird around (not shown)
• Lean - +20, -20 degrees, to lean forward and backward at the point where the legs connect
• Head yaw - +45, -45 degrees back and forth
• Head tilt - +15, -15 degrees up and down
• Beak - 30 degrees, could be all open or all closed (shown in the diagram as 15 degrees)

I was thinking that after I constructed the foam version, I could figure things out from there, but after seeing this post on Hack-A-Day with a "HOG Drive", I realized I could leverage off of this design for the head linkages.

I chatted with Skip at Interlock, and by the end of this past Tuesday evening, I had two 3-D printed versions of this, using ABS, rather than the PLA material I am more familiar with. (Here's the Thingiverse link for the design.) Since I wasn't going to be mounting a motor, we (and by "we" I mean "he") replaced the motor space with a flat plate with a mounting screw hole.  He also replaced the back control arm with just a peg, since the bridge-like shape wouldn't hold up properly on his printer.

The first print (on the left) has a failed control peg on the center disk.  It was adding material onto printed material that didn't cool yet, so it just kinda globbed up.  This was improved by Skip by adding a second post, seen in the second version on the right.  He also added some material around the screw holes in the frame, to improve durability.

After printing and having this in my hand, I'm realizing that it won't quite work for me, although it does give me an excellent starting point.  The center disk is too small to mount the head on.  It's only about 1 1/2 inches in diameter. I think I'd want something about 2-3" in diameter, with plenty of mounting points and space for securing the head ,as well as space for wiring for the beak servo (or linear motor, or solenoid, or whatever).  It really showed me the design considerations for actually constructing something, not to mention it really emphasized that whatever design I can think of, I can print... which is pretty futuristically awesome.

But the important thing is that I know have ideas to build on for the final version.  I'll still be constructing a foam core model, and I'll be using this above design as a kick-off point.

(This post is cross-posted to the Interlock blog as well.)

Arduino EEProm Explorer

NOTE: there would be a screenshot right here, but there's really no point. It'd just be a terminal window showing something like this:

> 

Anyway... while working on the BL-238 uComputer, I wanted to add EEProm support to load and save programs. One of the things I needed was a way to probe into the EEProm to see if everything in there looked correct, or if things were going awry, a way to reformat it and so on.  In the process, I created this EEProm Explorer which is available on github.

It presents a shell interface over the serial connection, that has a few commands that can be typed in.  Perhaps some of you out there can use it to help snoop at the data for your own programs, or whatever.  I may be adding in functionality to this (along with in TinyBasicPlus) to load and save EEProm data directly to SD Cards as well, but that's in the future.

Commands are:

• format - clear the EEProm - fill it with 0x00 (zeroes)
• dump - display a fancy hexdump of the EEProm contents, hex values and ascii equivalents
• print - display the contents as though they were a text file (ascii only)
• record - capture user input until a "." starts a line.  Great for filling with textual content.
• poke A D - poke the data value "D" into address "A".   Both values are decimal numbers.
• ? - display the help message, along with RAM/EEProm sizes.

So, download this sketch to your Arduino, and connect via the serial monitor, and just type in the commands to use them.

Be aware that different micros have different amounts of EEProm storage.  The 168-based devices have 512 bytes, while the 328-based devices have 1024 bytes.  Arduino DUE (Arm CPU) devices have no EEProm (so far.)

Future versions of this may change the builtin commands, or add to them.  (Current version as of this post is v002.)

Hope y'all have use for this little tool!