Monday, July 13, 2015

Retro Challenge 2015/7 Update 2: Keyboard And Joysticks

Space Invaders running in Stella on my Mac.  Jasper loved it!
(He also liked the green light-up USB cable.  That's my kid!)

As of last night, I have finished code for the joystick-to-keypress controller, as well as the ability to save the configuration in the EEPROM in the ATmega chip. As usual, the code is all available here on github.  What this basically means is that moving the joystick will send down keypress codes to the host computer... so the computer thinks that a keyboard is being used.  This means that applications like Stella, an Atari 2600 VCS emulator, which expect you to use the arrow keys and space bar in place of a real joystick, can see those key presses when you move your actual Atari joystick!

You can now pick from a list of keyboard mappings, including:

  • Stella (Atari 2600 emulator) (shown above)
  • Vice (Commodore 64 emulator)
  • Mame (Arcade game emulator)
  • WASD (general PC game usage)
  • HJKL (vi cursor movements (because why not!))

I have also implemented a basic settings system that saves settings to the EEPROM within the ATmega32u4 chip.  It currently has "slots" for a few things, but could be expanded with the above joystick-to-keyboard mapping, to send other keypresses from joystick movements or what have you.

The settings system works with 4 bytes in the EEPROM to determine what's going on with respect to saved settings. The first 3 bytes are a sentinel.  If the code does not read the sentinel, it will assume it's on a new device, and will install default values to the EEPROM.  The current sentinel are the three hex bytes: { 0x53, 0x44, 0x4c } which are the ASCII string "SDL", my initials. ;)  Next at setting slot [3] is the settings version number.  Currently this is just '1'.  Settings slot [4] contains the usage mode for the interface port. (Mouse/keyboard mapping, etc).

I attempted last week to get an Amiga Keyboard working with this.  I wired up an 8 position pin header to the interface board, using the Amiga 500 pinout:

  1. Data
  2. Clock
  3. Reset (toggled when Ctrl-A-A is pressed)
  4. +5v
  5. key (missing pin)
  6. Ground
  7. Status LED (power)
  8. In-Use LED (disk access)
I was going to just wire out the Data, Clock, +5 and ground but decided that it made more sense to use the actual A500 pinout. I ran into a problem on this though.  The interface can't provide enough power to drive the chips on the interface board.  I measured 4.5v at the pin header, then 3.2v down on the interface board itself.  This isn't good.  I will have to wire up a new interface connector with an external power connector, probably a USB-B jack, to provide dedicated power to the keyboard.

I did however find a phone being discarded, and retrieved the two 4P4C (RJ-22) connectors from it so that I can make a better A1000 keyboard jack.  The first one I made used an RJ-45 wall mount jack, which worked somewhat for RJ-22, but it was pretty hacked. ;)

Some thoughts for future additional expansion:

I'm currently going for the "cheap as chips" version of this, which is why there's no interface on it, and you have to connect via serial port to configure it.  This was all intentional to keep the build parts list down... to the point where the only necessary part is a D9 connector!  However, in using it, a few future revisions may offer more usability at the cost of parts expense:

  1. Multiple D9 jacks for multiple devices
    1. Ports dedicated for Mouse, Trackball, Multiple Joysticks, etc
    2. Could be just 2 that simulate Commodore/Amiga
    3. Could be 4 to simulate Atari 800 joystick ports
    4. Could be 1 for mouse, 5 for joysticks, so you never have to disconnect them.
    5. Would require a parallel-in, serial out shift register, or a port expander
    6. Expansion at the cost of a few cents, additional wiring, and time to read in the content
  2. (related) configuration for multiple ports
  3. User interface - Was thinking that this could be a variety of different methods:
    1. single pushbutton, Red/Green LED for indication codes (flashing colors)
    2. single or dual pushbutton, RGB color addressable LED for indication codes
      1. each could be wired directly to IO pins
    3. dual pushbutton, 7 segment LED display
      1. Could indicate use mode(s), etc
      2. 'C' for commodore mouse, 'A' for atari mouse
      3. '0'..'7' for joystick mode display
      4. Could flash multiple digits sequentially for info etc
      5. Would require LED driver chip
Obviously, all of these would require additional effort beyond the "let's get this working" and can be seen as stretch-stretch goals.  ;)


Tuesday, July 7, 2015

Retro Challenge 2015/7 - Amiga Mouse, Joystick, Keyboard USB interface

Once again, it is time for the Retro Challenge! This time around... well, I wasn't sure what I was going to work on,... In my "I want to partake" email, I listed projects such as working on an SD-card based storage drive for the KIM-Uno, my "Bare Metal C64" long term project.. which will likely wait until I retire, as well as working on the Interlock Homebrew Computer System.

Then I started to get parts from an aliexpress order that I placed.  I received my Arduino Pro Micro which is the teeny tiny version of the Arduino Leonardo.  What makes this special is that the main chip on it is the ATmega 32u4. This is the USB interface chip used in the Arduino Uno.  It has all of the standard IO of the 168/328, but with USB HID support.  This means that it can pretend to be a USB keyboard, mouse, etc.  This is a HUGE feature if you want to make standard computer peripherals.


For some reason, it clicked that I wanted to make a USB HID interface for my Amiga mice.  Long story short, within an hour, I had a functional prototype. I was moving my Amiga mouse, and the cursor on my MacBook's screen was moving.

I figure that this will be great for using the Amiga emulators. It'll be nice to use an authentic mouse, joystick and maybe keyboard with UAE, Vice or just for fun for regular usage.  I know that there are other projects out there or products that do this kind of thing, but they're a bit pricey to have a widget that I can't expand or repurpose... and besides at its core, this is not really a difficult or expensive product.  The most expensive single part so far is the microcontroller, and that was $3.

A little background on the Amiga's mouse...

The way old optical ball mice work is that they have two rollers that sit on a weighted ball, one for the horizontal, and one for the vertical.  As the mouse moves horizontally, the horizontal roller moves, and the ball slips on the vertical one.  The rollers have an encoding wheel with little windows that make and break optical connections with a pair of sensors.  These two sensors generate two bits of data for each direction. (four total.)  These two rotary encoders generate a gray code quadrature output.

Movement in one direction outputs:  00  01  11 10  00
Movement in the other direction outputs: 00 10 11 01 00

So, if you read these in a tight loop, and detect changes you can detect movements in the horizontal and vertical directions. In the same loop, if you look at the button inputs, you can determine if the buttons are pressed.

This is the basis for this project.  By reading these values from a dumb (no internal processing) Amiga mouse, I can generate vertical and horizontal motion values.  I can then send these down the USB HID stack through the Arduino libraries, and voilĂ , we have an Amiga Mouse to HID USB mouse adapter.  NOTE: PS2 and ADB mice have more smarts in them and output movement deltas rather than optical sensor pulses.  Reading either of those requires serial communications and protocol decoding instead.

My cheat sheet for pinouts and connection information.


Within an hour of this brainstorm, I had this prototype:

Arduino Pro Micro (ATmega32u4), with headers and D9 cable attached.

Commodore Amiga mouse plugged into a spare serial cable re-used as a D9 cable.

Unfortunately, the serial cable I was using had all of the wires connected except for the line used for the right mouse button.  Oh well... For the "what's available on my desk" approach, it was good enough for a proof of concept.

From there, some simple acceleration was added to convert "quick" movements of the mouse to "large deltas" sent down as mouse movements...

The way I implemented acceleration was that each time through the loop, i check for Horizontal or Vertical ticks.  I store the ticks as +1, 0, or -1 in an array of the last 128 readings.  Then, I sum the entire 128 elements of each (horizontal and vertical) array, and use that as the mouse movement.  The faster the mouse is being moved, the more +1s or -1s there will be, so it sends a larger number.  It was a quick hack that I thought might work, that turned out to work perfectly!

Some upcoming additions that I might / probably will do:

- Atari ST Mouse Support.  The only difference between an Atari and Amiga mouse are that two of the lines (specifically D9 pins 1 and 4) are swapped. This is an easy change in software.  The difficult part is tracking down an Atari ST mouse to test with!

- Atari (Digital) Joystick Support.  By combining the button read code with the acceleration code hinted at above, I can convert Joystick movements to HID mouse movements

And really, from that point, it would be near trivial to add in HID keyboard support as well... I can send down WASD key presses for joystick movements... or really any other key presses based on joystick movements.

Additional features may include support for Amiga keyboards as HID keyboard, joystick as HID gamepad, etc.  In preparation for working with one of my old Amiga 1000 keyboards, I cleaned one up to get the years of finger grime of of it...

The right side has been cleaned using my proprietary cleaning technique described below.

Keyboard in the process of being cleaned. More like CLEANBOARD. HAHAHA. :(

Here's the (yellowed) keyboard with some keys removed. (The 'X' key has been missing for years, sadly.)  The proprietary cleaning solution is in that "Cascade" container.  I would use that dental pick tool and my hand noodles to pop the keys off of the keyboard.  Then I dropped them into the cleaning solution.  After about 30 minutes, I pulled each one out, wiped it off with my fingers, rinsed it off, and they were as clean as new.  The proprietary cleaning solution is one squirt of dish soap with some warm water. ;)

NOTE: Not shown is the process of removing all of the lint, hair and other bits of whatever that were stuck between the keys because that's kinda gross and you don't really want to see that anyway..

More on this project to come...

I briefly explored the idea of supporting Mac/Apple IIgs ADB mouse and keyboard support, but I quickly learned the complexity of the ADB spec, and am putting that safely outside of the scope of this project!

The code for this project and other development details are available on github in the AmigaInputToUSB repository.

Post Backlog...

I've got a bunch of projects I've been working on here and there. I'm a bit behind with this.  That seems to be a theme.  I'll be putting up posts over time of various things...

Sunday, January 18, 2015

KIM-UNO (Software)

As mentioned in the previous post about the hardware for my implementation of the KIM-UNO, some changes needed to be made to accommodate the updated hardware.  First, let's look at the new schematic layout for the updated circuitry:

The reference version had a 3x8 matrix, and this one uses 4x6.  I tried doing this a few different ways. I knew (or at least I thought I knew) that I needed to come up with something different for scanning the keypad since this has a common-cathode LED display. (It's what I had in my toolbox.)  I tried one version that added about a dozen resistors... It didn't work.  I tried one with a half dozen resistors, and a dozen 1N1914 diodes... that didn't work either.

On a whim, I decided to just hook it up directly and see how it goes... I tried scanning the keypad myself but it wasn't working.  I tried scanning the keypad using the Arduino Keypad library, with nothing else, and that worked fine... okay.  got something.

I then added the Keypad library to my test program that displayed stuff to the LED display, and it was broken again. Okay. so it's something between the two of them.  What I came up with is far from optimal, but it works. (The screen flickers visibly a tiny bit... which might also be due to the added 220 ohm resistors, making the display dimmer than before.)


First, I replaced the code block that handles the LED rendering in the KIM UNO program with my display routine which works well.  I've included the arduino/c code here in case someone else is crazy enough to do this.
void driveLEDs_CommonCathode( void )
{
  char digit = 0;

  for( byte i = 0 ; i<3 ; i++ )
  {
    for( byte j = 0 ; j<2 ; j++ )
    {
      // get the current byte to display
      byte b = threeHex[i][j];
   
      // get the segment mask
      byte s = dig[b];
   
      // select just this digit
      for( int d=0 ; d<8 ; d++ ) {
        pinMode( ledSelect[d], OUTPUT ); // make sure we're output
        digitalWrite( ledSelect[d], (d==digit)?LOW:HIGH );
      }
   
      // now go through and turn on/off the right segments
      for( byte col =0 ; col <8 ; col++ )
      {
        pinMode( aCols[col], OUTPUT );
        digitalWrite( aCols[col], (s & (0x80>>col))? HIGH : LOW );
      }
   
      // wait a moment...
      delay( 2 ); // necessary?
   
      // go to the next display digit
      digit++;
    }
  }
}


Next, I replaced the code block that handles the 3x8 keypad scanning with mine; It initializes the keypad lines every time through the loop.  The LED scanning gets things into an unexpected/unwanted state for the Keypad scanning.  It's kind of a kludge, but it works well enough. Once it scans the keypad, I munge the output data slightly to match up with the original code.  I filled in the keypad library to return the proper key codes.  The only one i had to monkey with was the SST toggling. Not a big deal though.

#include <Keyboard.h>
void scanKeysFourBySix()
{
  static int keyCode = -1, prevKey = 0;
  static unsigned long timeFirstPressed = 0;
  
  // scan the keys and then remap them
   int i;
  
  // first, wipe everything
  for( i = 0 ; i<8 ; i++ ) {
    pinMode( aCols[i], INPUT );
    digitalWrite( aCols[i], LOW );
    pinMode( ledSelect[i], INPUT );
    digitalWrite( ledSelect[i], LOW );
  }
  
  for( i=0 ; i<ROWS ; i++ ) {
    pinMode( rowPins[i], INPUT );
    digitalWrite( rowPins[i], HIGH );
  }
  
  for( i=0 ; i<COLS ; i++ ) {
    pinMode( colPins[i], OUTPUT );
    digitalWrite( colPins[i], HIGH );
  }
  
  char key = keypad.getKey();
  
  if( key == NO_KEY && ((keypad.getState() == IDLE) || ( keypad.getState() == RELEASED ))) {
    prevKey = 0;
    return;
  }

  // convert key to keycode (addressing in the other matrix )
  if( key == 't' ) {
    // sst toggle
    key = SSTmode==0?']':'[';
  }
  
  if( key != NO_KEY )
    keyCode = key; // fill this.

  if (keyCode!=prevKey)
  {
    prevKey = keyCode;
    curkey = key; // we're already decoded. parseChar(keyCode);
    timeFirstPressed=millis();  // 
  }
  else // if pressed for >1sec, it's a ModeShift key
  {
    if ((millis()-timeFirstPressed)>1000) // more than 1000 ms
    {
        if (key == '[' || key == ']' ) //keyCode==17) //it was the SST button
        {
          keyboardMode=(keyboardMode==0?1:0); // toggle
//                Serial.print(F("                                      Eeprom R/O     ")); 
          Serial.print(F("                                keyboardMode: "));  Serial.print(keyboardMode, DEC); 
          SSTmode=0;
          curkey=0;  // don't do anything else with this keypress
        }
        if (keyCode==18) // it was RS button // fix
          curkey = '>';  // toggle eeprom write protect
        timeFirstPressed=millis(); // because otherwise you toggle right back!
    }          
  }

}

The second half is pretty much lifted directly from the core scanKeys().

Saturday, January 17, 2015

KIM-Uno

I ordered a KIM-UNO kit, which should arrive in a couple weeks, but in the meantime, I decided to see if I could cobble one together with parts I had around... Turns out, I can.

I used an Arduino Uno R3 as the base micro board. On top of that I have a Seeed Studio protoshield, with connectors for the display and keypad, as well as 220 ohm resistors for the display.

Not the best soldering job ever, but it'll do.


I went through a bunch of different versions of the circuit for the keypad scanning, and I finally resorted to using a breadboard to figure things out.  Since I switched this from a common anode to a common cathode display, the circuit for the keypad matrix got all confused as-is. 

In a nut, the polarity of the power to the display was reversed, which caused the keyboard to not scan properly.  I had tried a few circuits that should have worked, but didn't... one with a load of diodes, one with a mess of resistors... I eventually decided to just wire it in directly, and use the Keypad library.  Once I realized i had to manually initialize the pins before scanning, it all Just Worked(TM).

To test those bits, I made a sample Arduino sketch that displays and scans the keyboard so that I could get the code working with these devices.

The display itself is an 11 digit 7 segment display that I found up in Active Surplus on Queen Street, Toronto, a bunch of years back. KIM emulation only uses 6 of the digits. (More about this display module in this other post.)

The keypad and case I got from a hamfest... they were part of some project that someone was working on at one point.  I have a second case like this somewhere.  The above picture shows the printed out keypad labels (Futura font) which I cheapo-laminated to the case using lots of magic transparent tape.

Mix in a little 9v battery snap, a power switch, a piece of red gel, and I've got my own little portable KIM clone


I should note that I also had to hack the KIM-UNO source project a little to support my display (Common Cathode instead of Common Anode) as well as to support my keypad which is wired as 4x6 buttons, rather than the 3x8 that the reference project uses. A few evenings of hacking on the source and here we are!

I've also got a post up about the software/firmware modifications I made on the KIM-UNO source...

Monday, November 10, 2014

Flat panel light box


I've been getting into making stained glass pieces, as I've been taking a class at the Rochester Memorial Art Gallery.  One of the tools they have available there is a light box, which I have used to make the template for the macaw piece I'm making.  I used it to help me adapt a pattern I found online into something that better suits my needs.  I traced it, then retraced that sketch.

The light box also works well to see how things look with light behind them, however it's not something I can use a lot for this, since my project is a couple dozen pieces of glass and we have to share the light box.


On the recycle pile at work was a couple of old, broken laptops.  I snagged two of them; one with an LED backlight, and one with a CCFT backlight.  I thought that the LED one would be easier to get working.


Over at Interlock, I tore apart the screens, tossing out the LCD panel, so I was left with just the light source, light guide, diffusion screens, and control circuitry.  Its control/driver board also managed the LCD itself.  There were many test points on the back, so I applied power to the "LED PWR" pin, ground to a ground point, then about +5 volts to the BLEN (assuming it to be "backlight enable") as well as the "PWM" test point. After futzing with it for a little bit, I gave up and focused efforts on the CCFT-based one.

The slightly larger CCFT (Fluorescent) based one had a single board that connected to the backlight tube through standard white/pink silicone-insulated wiring.  The board itself had one tiny connector on one side with a few pins that seemed to have obvious use.  V+, which assumably powers the backlight circuitry, should be connected to +5 or maybe +12.  GND, which of course is ground. Then two other connections "EN" and "CTRL", which I guessed to be "Enable" and "Control".  A guess would be to tie these to a logic "high" which might maybe enable the thing.

I connected just the V+ and GND to a power supply, and applied power.  Ranging from 0v up through 12v yielded no results. I connected the other two logic lines to power too, and started ramping up the power.  At around 7v, the backlight flickered on, but then wouldn't do anything until I brought the power back to 0v, and then back up again.

On a hunch, I figured that the backlight needs a higher voltage, and the logic stays at TTL levels.  Applying the same power to both would give a possible point between the two where both kinda worked, which is where I saw the flicker.  I hacked together two power supplies, with grounds tied together, 5v from one power brick, and the V+ to the variable supply.


I ramped up the voltage, and sure enough, it would get dim around 7v, then go full brightness around 12v.  It seemed to use about 300mA to drive it too. Good to know.  I found a 12v power brick and.. it would light for about 20 seconds then power itself off.  The 12v brick put out 18v.

I eventually found a brick that worked, so i hooked up two supplies, a 5v and a 12v and it was stable and bright.  Next would be the task to put in a 5v regulator to provide the 5v it needs, so i can run it all on one single power supply.


A simple circuit using a 7805 and two capacitors later, and I have 12v in, and a backlight lit!  I wrapped the circuit in tape (purple because it was there), hooked it up to a power connector, and reassembled the case.


Best of all, it all managed to fit within the old plastics. Huzzah!

Now I just need to put something on the diffusers to protect them from cut glass, maybe a piece of plexi, or even a large Ziplock or plastic wrap, and I'll be set!

Wednesday, November 5, 2014

Kindle 2 Repair



Again, from the recycle pile, I found something very nifty.  It was a broken Amazon Kindle 2 with 3G cell modem.  The screen was very messed up.  I attempted to charge it, which seemed to work.  I was able to connect it to my computer, and see the files on it, so I knew it was somewhat working.  A quick search on ebay showed a used, working eInk screen was $20.  I asked around on a few Kindle boards online about repairs, or getting Amazon to repair it, and the basic overall response was "just buy a new one".  That wasn't the point.


I eventually decided to drop the $20, order the screen, and take my chances that the main unit works and has decent battery life.  A few days later, I received what you see above.  I love how eInk displays hold their last image.  It's a pretty good sign that this one has a standard Kindle startup image showing on it.


Lots of screws holding this thing together.  After assembling and reassembling it a few times I got pretty fast at doing the whole procedure.  I wouldn't have been able to do it without resources like iFixit who provided teardown and disassembly procedures.


The battery removed from the left.  You can see, left to right, Battery bay, 3G sim card slot, cellular modem.  The orange bit at the top is the display screen ribbon connection.


The inside of the upper case, showing the orange flex cables for the side buttons and such.


Just for good measure, here's the entire board, removed from the casing.

That explains the bad screen display.

All in all, it took about an hour.  I had to disassemble and reassemble it a few times to get the display flex cable seated properly, but once it was, it all just worked.  Battery life is still excellent on it, the 3G service works great, and I've loaded it up with a bunch of books to read.


I hacked it a little to change the sleep display images but other than that, it's pretty stock.  Not bad for $20 and some manual labor!

I should note that about a week after I performed this operation, it suddenly decided that it would constantly press the "4" key for me.  Very nice of it, but not very convenient.  I disassembled it all again.  The keypad buttons all looked okay to me.  I even removed the '4' key from the main board to examine it, but it looked fine.  Something about that process, however, seemed to have fixed the problem.  It is currently working perfectly, and other than the battery dying on me, after 4 months of use, it has performed excellently.  :D