Dynamic Button Display, ABM

[goldengears5]

So I built my cabinet (build will be put up when I have time) and I thought to my self how am I gonna show what the controls are with so many games?!?! Then while I was working it hit me. Take LCD screens and make one button graphic that the screens can fit into and have the screens display what each button does when a game is started. So I am almost done (minus the housing and graphic) I have the LCDs wired up, and the hardware programed, And the scripts to run it created. So now I am sharing It with all of you!

So the first thing I did while waiting for the LCDs to come in is figure out how I was going to do this, what I did know is that I had an arduino laying around and that was gonna be my brains. So I got to work writing the code for it:

Arduino Script:

Code: [Select]

#include <LiquidCrystal.h>

/*
Terminal2Arduino
 Start OS X terminal.app
 Find serial device name: ls /dev/tty.*
 Open terminal session: screen [serial device name] 9600
 Close session: ctrl-A ctrl-\
 \ = shift-alt-7 on some keyboards
 */



    // include the library code:

// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(12, 8, 5, 4, 3, 2);
LiquidCrystal lcd2(12, 9, 5, 4, 3, 2);
LiquidCrystal lcd3(12, 10, 5, 4, 3, 2);
LiquidCrystal lcd4(12, 11, 5, 4, 3, 2);
LiquidCrystal lcd5(12, 13, 5, 4, 3, 2);
LiquidCrystal lcd6(12, 14, 5, 4, 3, 2);
LiquidCrystal lcd7(12, 15, 5, 4, 3, 2);
LiquidCrystal lcd8(12, 16, 5, 4, 3, 2);
LiquidCrystal lcd9(12, 17, 5, 4, 3, 2);
LiquidCrystal lcd10(12, 18, 5, 4, 3, 2);
LiquidCrystal lcd11(12, 19, 5, 4, 3, 2);
LiquidCrystal lcd12(12, 20, 5, 4, 3, 2);

#define LED 13
int led_pin = 13;
byte inbyte = 0;
byte test = 1;
String currentbutton = "";
String reset = "";
String button1 = "";
String button2 = "";
String button3 = "";
String button4 = "";
String button5 = "";
String button6 = "";
String button7 = "";
String button8 = "";
String button9 = "";
String button10 = "";
String button11 = "";
String button12 = "";

int button = 1;
boolean active = false;

void setup() {
  Serial.begin(9600); //open the serial port
  pinMode(LED, OUTPUT);
}

void loop() {

  inbyte = Serial.read(); //Read one byte (one character) from serial port.

  if(inbyte != 255 && inbyte != '%'){

    active = false;

    if (inbyte == 'a') {
      currentbutton += 'a';
    }

    if (inbyte == 'b') {
      currentbutton += 'b';
    }

    if (inbyte == 'c') {
      currentbutton += 'c';
    }

    if (inbyte == 'd') {
      currentbutton += 'd';
    }

    if (inbyte == 'e') {
      currentbutton += 'e';
    }

    if (inbyte == 'f') {
      currentbutton += 'f';
    }

    if (inbyte == 'g') {
      currentbutton += 'g';
    }

    if (inbyte == 'h') {
      currentbutton += 'h';
    }

    if (inbyte == 'i') {
      currentbutton += 'i';
    }

    if (inbyte == 'j') {
      currentbutton += 'j';
    }

    if (inbyte == 'k') {
      currentbutton += 'k';
    }

    if (inbyte == 'l') {
      currentbutton += 'l';
    }

    if (inbyte == 'm') {
      currentbutton += 'm';
    }

    if (inbyte == 'n') {
      currentbutton += 'n';
    }

    if (inbyte == 'o') {
      currentbutton += 'o';
    }

    if (inbyte == 'p') {
      currentbutton += 'p';
    }

    if (inbyte == 'q') {
      currentbutton += 'q';
    }

    if (inbyte == 'r') {
      currentbutton += 'r';
    }

    if (inbyte == 's') {
      currentbutton += 's';
    }

    if (inbyte == 't') {
      currentbutton += 't';
    }

    if (inbyte == 'u') {
      currentbutton += 'u';
    }

    if (inbyte == 'v') {
      currentbutton += 'v';
    }

    if (inbyte == 'w') {
      currentbutton += 'w';
    }

    if (inbyte == 'x') {
      currentbutton += 'x';
    }

    if (inbyte == 'y') {
      currentbutton += 'y';
    }

    if (inbyte == 'z') {
      currentbutton += 'z';
    }


    if (inbyte == 'A') {
      currentbutton += 'A';
    }

    if (inbyte == 'B') {
      currentbutton += 'B';
    }

    if (inbyte == 'C') {
      currentbutton += 'C';
    }

    if (inbyte == 'D') {
      currentbutton += 'D';
    }

    if (inbyte == 'E') {
      currentbutton += 'E';
    }

    if (inbyte == 'F') {
      currentbutton += 'F';
    }

    if (inbyte == 'G') {
      currentbutton += 'G';
    }

    if (inbyte == 'H') {
      currentbutton += 'H';
    }

    if (inbyte == 'I') {
      currentbutton += 'I';
    }

    if (inbyte == 'J') {
      currentbutton += 'J';
    }

    if (inbyte == 'K') {
      currentbutton += 'K';
    }

    if (inbyte == 'L') {
      currentbutton += 'L';
    }

    if (inbyte == 'M') {
      currentbutton += 'M';
    }

    if (inbyte == 'N') {
      currentbutton += 'N';
    }

    if (inbyte == 'O') {
      currentbutton += 'O';
    }

    if (inbyte == 'P') {
      currentbutton += 'P';
    }

    if (inbyte == 'Q') {
      currentbutton += 'Q';
    }

    if (inbyte == 'R') {
      currentbutton += 'R';
    }

    if (inbyte == 'S') {
      currentbutton += 'S';
    }

    if (inbyte == 'T') {
      currentbutton += 'T';
    }

    if (inbyte == 'U') {
      currentbutton += 'U';
    }

    if (inbyte == 'V') {
      currentbutton += 'V';
    }

    if (inbyte == 'W') {
      currentbutton += 'W';
    }

    if (inbyte == 'X') {
      currentbutton += 'X';
    }

    if (inbyte == 'Y') {
      currentbutton += 'Y';
    }

    if (inbyte == 'Z') {
      currentbutton += 'Z';
    }
 if (inbyte == '1') {
      currentbutton += '1';
    }

 if (inbyte == '2') {
      currentbutton += '2';
    }

 if (inbyte == '3') {
      currentbutton += '3';
    }

 if (inbyte == '4') {
      currentbutton += '4';
    }

 if (inbyte == '5') {
      currentbutton += '5';
    }

 if (inbyte == '6') {
      currentbutton += '6';
    }

 if (inbyte == '7') {
      currentbutton += '7';
    }

 if (inbyte == '8') {
      currentbutton += '8';
    }

 if (inbyte == '9') {
      currentbutton += '9';
    }
   
 if (inbyte == '0') {
      currentbutton += '0';
    }

    if (inbyte == ' ') {
      currentbutton += ' ';
    }

  }
  if (inbyte == '%' && active != true) {
    if (button == 1){
     
      button1 = currentbutton;
  // Button 1
 // set up the LCD's number of rows and columns:
 lcd.begin(16, 2);
 // Print a message to the LCD.
 lcd.print(button1);
 Serial.println(button1);
 
 // set the cursor to column 0, line 1
 // (note: line 1 is the second row, since counting begins with 0):
// lcd.setCursor(0, 1);
 // print the number of seconds since reset:
// lcd.print(millis()/1000);
    }
    if (button == 2){
      button2 = currentbutton;
  // Button 2
 // set up the LCD's number of rows and columns:
 lcd2.begin(16, 2);
 // Print a message to the LCD.
 lcd2.print(button2);
 // set the cursor to column 0, line 1
 // (note: line 1 is the second row, since counting begins with 0):
// lcd2.setCursor(0, 1);
 // print the number of seconds since reset:
 //lcd2.print("");
    }
    if (button == 3){
      button3 = currentbutton;
  // Button 3
 // set up the LCD's number of rows and columns:
 lcd3.begin(16, 2);
 // Print a message to the LCD.
 lcd3.print(button3);
 // set the cursor to column 0, line 1
 // (note: line 1 is the second row, since counting begins with 0):
 //lcd3.setCursor(0, 1);
 // print the number of seconds since reset:
 //lcd3.print(millis()/1000);
    }
    if (button == 4){
      button4 = currentbutton;
  // Button 4
 // set up the LCD's number of rows and columns:
 lcd4.begin(16, 2);
 // Print a message to the LCD.
 lcd4.print(button4);
 // set the cursor to column 0, line 1
 // (note: line 1 is the second row, since counting begins with 0):
// lcd4.setCursor(0, 1);
 // print the number of seconds since reset:
// lcd4.print(millis()/1000);
    }
    if (button == 5){
      button5 = currentbutton;
  // Button 5
 // set up the LCD's number of rows and columns:
 lcd5.begin(16, 2);
 // Print a message to the LCD.
 lcd5.print(button5);
 // set the cursor to column 0, line 1
 // (note: line 1 is the second row, since counting begins with 0):
 //lcd5.setCursor(0, 1);
 // print the number of seconds since reset:
// lcd5.print(millis()/1000);
    }
    if (button == 6){
      button6 = currentbutton;
  // Button 6
 // set up the LCD's number of rows and columns:
 lcd6.begin(16, 2);
 // Print a message to the LCD.
 lcd6.print(button6);
 // set the cursor to column 0, line 1
 // (note: line 1 is the second row, since counting begins with 0):
// lcd6.setCursor(0, 1);
 // print the number of seconds since reset:
 //lcd6.print(millis()/1000);
 
    }
    if (button == 7){
      button7 = currentbutton;
  // Button 7
 // set up the LCD's number of rows and columns:
 lcd7.begin(16, 2);
 // Print a message to the LCD.
 lcd7.print(button7);
 // set the cursor to column 0, line 1
 // (note: line 1 is the second row, since counting begins with 0):
// lcd7.setCursor(0, 1);
 // print the number of seconds since reset:
// lcd7.print(millis()/1000);
 
    }
    if (button == 8){
      button8 = currentbutton;

  // Button 8
 // set up the LCD's number of rows and columns:
 lcd8.begin(16, 2);
 // Print a message to the LCD.
 lcd8.print(button8);
 // set the cursor to column 0, line 1
 // (note: line 1 is the second row, since counting begins with 0):
 //lcd8.setCursor(0, 1);
 // print the number of seconds since reset:
 //lcd8.print(millis()/1000);
 
    }
    if (button == 9){
      button9 = currentbutton;
  // Button 9
 // set up the LCD's number of rows and columns:
 lcd9.begin(16, 2);
 // Print a message to the LCD.
 lcd9.print(button9);
 // set the cursor to column 0, line 1
 // (note: line 1 is the second row, since counting begins with 0):
 //lcd9.setCursor(0, 1);
 // print the number of seconds since reset:
 //lcd9.print(millis()/1000);
 
    }
    if (button == 10){
      button10 = currentbutton;

  // Button 10
 // set up the LCD's number of rows and columns:
 lcd10.begin(16, 2);
 // Print a message to the LCD.
 lcd10.print(button10);
 // set the cursor to column 0, line 1
 // (note: line 1 is the second row, since counting begins with 0):
 //lcd10.setCursor(0, 1);
 // print the number of seconds since reset:
 //lcd10.print(millis()/1000);
 
    }
    if (button == 11){
      button11 = currentbutton;
  // Button 11
 // set up the LCD's number of rows and columns:
 lcd11.begin(16, 2);
 // Print a message to the LCD.
 lcd11.print(button11);
 // set the cursor to column 0, line 1
 // (note: line 1 is the second row, since counting begins with 0):
 //lcd11.setCursor(0, 1);
 // print the number of seconds since reset:
 //lcd11.print(millis()/1000);
    }
    if (button == 12){
      button12 = currentbutton;
 // Button 12
 // set up the LCD's number of rows and columns:
 lcd12.begin(16, 2);
 // Print a message to the LCD.
 lcd12.print(button12);
 // set the cursor to column 0, line 1
 // (note: line 1 is the second row, since counting begins with 0):
// lcd12.setCursor(0, 1);
 // print the number of seconds since reset:
// lcd12.print(millis()/1000);
    }
   

    if (currentbutton != "reset"){
    currentbutton = "";
    button++; 
    active = true;
    }
  }
if (button > 11){

}
  if (currentbutton == "reset"){
    Serial.println("reseting");
    button = 1;
    currentbutton = "";
    button1 = "";
    button2 = "";
    button3 = "";
    button4 = "";
    button5 = "";
    button6 = "";
    button7 = "";
    button8 = "";
    button9 = "";
    button10 = "";
    button11 = "";
    button12 = "";
    digitalWrite(led_pin, LOW);
    active = true;
  }
 
   if (currentbutton == "testme"){
    Serial.println("testing...");
Serial.println(button1);
Serial.println(button2);
Serial.println(button3);
Serial.println(button4);
Serial.println(button5);
Serial.println(button6);
Serial.println(button7);
Serial.println(button8);
Serial.println(button9);
Serial.println(button10);
Serial.println(button11);
Serial.println(button12);
if (button12 == "l"){
  digitalWrite(led_pin, HIGH);
}
Serial.println("test complete");
currentbutton = "";


  }



}



Then I made the Batch file to initiate Powershell to send serial data to arduino:

Code: [Select]

@echo off
Powershell.exe -executionpolicy remotesigned -File C:\ABM\buttonmaps\%~n1.ps1
echo %~n1
TIMEOUT 10

Then For the powershell script (this will be named the same as the rom just like an other extra for mame ie for mspacman.zip its named mspacman.ps1):

Code: [Select]

$port= new-Object System.IO.Ports.SerialPort COM3,9600,None,8,one
$port.open()
#Resets arduino button data
$port.WriteLine("reset")
#Button1
$port.WriteLine("button1")
$port.WriteLine("%")
#Button2
$port.WriteLine("button2")
$port.WriteLine("%")
#Button3
$port.WriteLine("button3")
$port.WriteLine("%")
#Button4
$port.WriteLine("button4")
$port.WriteLine("%")
#Button5
$port.WriteLine("button5")
$port.WriteLine("%")
#Button6
$port.WriteLine("button6")
$port.WriteLine("%")
#Button7
$port.WriteLine("button7")
$port.WriteLine("%")
#Button8
$port.WriteLine("button8")
$port.WriteLine("%")
#UP
$port.WriteLine("UP")
$port.WriteLine("%")
#DOWN
$port.WriteLine("DOWN")
$port.WriteLine("%")
#LEFT
$port.WriteLine("LEFT")
$port.WriteLine("%")
#RIGHT
$port.WriteLine("RIGHT")
$port.WriteLine("%")
$port.Close()
Eventually I want a script to take input and generate this file but for now its pretty easy to just copy an existing one and edit it for another game. (If anyone wants to make that script to make it more stream lined that would be awesome)


Last thing I had to do Is make it run when the game was started, first I ran Mgalaxy and just had mgalaxy point to the batch file and added some lines to start mame, then I switched to hyperspin and that was even easier surprisingly just had to add the following line to the AHK file for mame:

Code: [Select]

run, C:\ABM\ABM.bat %romName%
When the LCDs came I wanted to see what the layout would be and if it would look alright


Which I figured out where I would fit it and it looks good.

then I wired the LCDs up



It all works great,
When I get a chance I will upload a video of it working.

Any suggestions or comments are welcome!

-GG

[bfauska]

Sounds super intriguing , but the images aren't working.

[Yvan256]

I had a similar idea a few months ago and this fits with another idea that I need to implement with a front-end that would enable all kinds of various projects and be 100% future-proof. I talked a bit about the idea in my MVS-99-6 thread, but here's the basic idea:

The front-end needs to send the ROM filename on selected serial port(s) (even if the physical connection(s) is/are USB, the signals are still serial) and each peripheral accesses its own internal look-up table/database/whatever to decide what to do for the selected game. Given the cost of flash storage these days, I don't think it's a big deal even for a few thousand games.

Why go this route instead of asking the PC to do everything? Simply because the front-end developers cannot foresee  what kind of peripherals we'll come up with and going this route means it's future-proof even if the front-end is never updated again.

In my case, for MVS-99-6 I'll need to store tiny marquee graphics on an SD card in the particular dimensions and file format that I'm using, so I can't ask a front-end developer to make something just for my cabinet. If everybody does that the front-end will be bloated after only a few dozen similar requests.

Yes, some front-end allow plug-ins, but I'm talking about making some sort of standard for the community that everyone could follow and then changing which front-end you use wouldn't matter as long as it supports that standard all your custom peripherals would continue working.

Here's the kind of projects that could use such a standard: motorized rotating displays, motorized rotating control panels, LCD marquees, lighted buttons, displays used as dynamic labels for buttons and joysticks, motorized joystick restrictors, etc.

I'm sure some people even have other crazy ideas that I haven't though about yet, maybe a motorized display that changes its angle depending wether you're playing an arcade game or a pinball game?

The only thing we need to standardize is the connection, the protocol and the data being sent. I'm going to suggest a serial connection since USB-to-serial cables exist, new computers don't have serial ports but most microcontrollers have at least one serial port. And given that we only need to send a few bytes, I'll suggest a low-speed serial connection or at least something which is common/default for both Atmel and Microchip microcontrollers. And to simplify the control logic on the microcontroller end, I suggest 8 bytes (the ROM filename) followed by an "End of line" character (I can't remember if it's 0x10 or 0x13 right now) so that the logic doesn't confuse "dkong" with "dkongjr" before the data is completely sent.

edit: you should fix your images, please attach them to your post instead of using a third-party hosting service.

[SavannahLion]

Not to steal the thread, but without pictures...

@Yvan256

I think you're on an interesting path but overlooking a few details. I have a similar scheme in my project but I don't have to deal with a shitload of games.

Here's a few thoughts.

MAME runs a ballpark of about 7 or 8 thousand images (not sure nor do I care if all of them work) and last I checked the "BIG" download had something like 30kish images. Flash for the AVR line peaks out at about 64k with the bulk being 32k or less and about 328k for the 8/16 hybrids (which are junk). Tracking 7000 ROMS using 8 bytes of data equates to a requirement of about 56k of RAM just to have the table. This number is without any of the configuration data for any particular game at all. 8-bit AVR generally uses 15bits for addressing the Flash, so you'll need another 2 bytes (or a sum of 10 bytes) for each game bumping that requirement up to 70k or more.
   
Imagine if someone wants to run MAME, MESS and half a dozen other emulators. The resulting table would be dizzying not to mention the risk of name collisions since MAME and MESS have a different file naming convention that other emulators. This doesn't include the possibility of new games added to the list in the future.

Without using external storage like an SD card, a list like that would quickly overwhelm all but the beefiest MCU's. Basically excluding the 8bit line entirely. I probably wouldn't even consider 8/16 AVR line either but head straight to the 32bit ARMs.

In a modular design, using an ARM with that much memory to say... rotate a monitor for no other reason than the need to have that table is MAJOR overkill IMHO.

There are ways to overcome this though.

One solution is to have an application snag the file name, either through a virtual serial port for standardization or through API. I like the serial port myself. The packet sent would consist of no less than two fields, the APP name (eg MAME), and the file name. The size of each fields matters none and would be truncated with \00 but have a hard limit (say 255). Any sane app should be able to deal with that. This "helper" app is then responsible for managing "registered" serial devices attached to the ports, sending the appropriate data required to the individual devices and more importantly, managing updates. This can be done via "profiles" that are loaded with each registered device. Sounds a bit like USB eh?
   
That method completely overcomes the "adding new games" problem. If a new game is added, update the master list, update the appropriate profiles and the helper app does the rest.

That's the rub though. We have apps like that already. We have front ends that wrap the launching of emulators with no problems. If the front end doesn't feed the serial port, it's almost trivial to add a small "forwarding" app that scoops up the name and forwards it to a serial port or to whatever we want then proceed to launch the emulator with the necessary command lines.

If I'm misunderstanding, feel free to clarify. I like the idea, I just don't know if it's something that's absolutely necessary given the current landscape right now.

[nitrogen_widget]

Don't the recent versions of Mame just do this with its abikity to address multiple monitors?

[Yvan256]

Not to continue stealing the thread, but without pictures...

I think you're on an interesting path but overlooking a few details. I have a similar scheme in my project but I don't have to deal with a shitload of games.

Here's a few thoughts.
[...]

If I'm misunderstanding, feel free to clarify. I like the idea, I just don't know if it's something that's absolutely necessary given the current landscape right now.

You understood perfectly, however like you said storing the data on an SD card would overcome the problem of too many ROMs. Is there really so many people with thousands of games on their cabinet?

But as far as front-ends go, do they allow you to run a program when selecting a game, not just when you run it? Doing so for things like a rotating monitor or motorized joystick would be a bad idea, but in the case of my mini-marquees LCD I'd like for it to change when you are in the front-end menu selecting games. It's a minor thing but I think it would be neat.

But yes, being able to run a program with the emulator name and the ROM filename would be enough to be future-proof too and still allow anyone to work the way he wants.

edit: goldengears5, can you attach the images to your first post? All we see is the error message attached to my post.

[Yvan256]

Don't the recent versions of Mame just do this with its abikity to address multiple monitors?

In my case it wouldn't work since my tiny 128x160 pixels LCD connects via SPI, not VGA/DVI/HDMI. It probably wouldn't work for goldengears5 either because if he's using the displays I think he's using, it's probably SPI too. We need a microcontroller to talk to the small LCDs.

[SavannahLion]

You understood perfectly, however like you said storing the data on an SD card would overcome the problem of too many ROMs. Is there really so many people with thousands of games on their cabinet?

True, not everyone does. But if you create a Diddle that does Daddle, how can you guarantee that whomever decides to use your Diddle limits their game selection to X? You can't.

This problem would be further compounded by the problem of new games being added. There is no way to expect a user to "lock" a game list onto their cab over a given span of time. It would be foolish to assume so. As soon as a user finds out they can't add game X or Y because they lose some of that functionality because the game isn't on the Diddle's game list, it'll go into the trash. The feature becoming a hindrance.

One of the controllers I have in my set up has a whopping 8k of Flash. I haven't done a code analysis on it yet, but I imagine I'm using at least 2k just for the framework (for testing). The remaining 6k would be quickly overwhelmed if I decided to allow it to manage game specific data. So my controller does what it does best, it continues sending the same data, regardless of the "mode" the rest of the system is in. We'll get to that in a minute.

But as far as front-ends go, do they allow you to run a program when selecting a game, not just when you run it? Doing so for things like a rotating monitor or motorized joystick would be a bad idea, but in the case of my mini-marquees LCD I'd like for it to change when you are in the front-end menu selecting games. It's a minor thing but I think it would be neat.

I doubt it, but I could be wrong.

For that functionality, you'll likely be left modifying the source code of an existing one or writing your own. If enough people select your FE over another, the other FE authors will likely take note of your feature set and begin to include them.

That's a tough thing to accomplish though and I don't bother expecting people to use or even download my FE if I elect to make it available. The market is astronomically small for FE's, even smaller for the type I'm drawing up, and about 1/∞ for anyone that'll actually use it.

But yes, being able to run a program with the emulator name and the ROM filename would be enough to be future-proof too and still allow anyone to work the way he wants.

Given your requirements and features, I would suggest creating an FE with a "plug in" architecture where you have a configuration setup that allows specific data constructs to be broadcast (so you don't flood the system with hundreds or thousands of unnecessary even broadcasts) and a "receiver" that manages the game list and transmits the bulk of the desired functionality to the devices. I think there are a couple of FE's with similar functionality but I don't know if they do exactly what you want.

It might even be easier to do it in Linux as opposed to Windows since Linux environment tends to have the "do one thing and do it well" mentality so there are a very good mechanisms for communicating between tools. Windows has many of the same functions, I just find it a hell of lot easier to access them on Linux than I do on Windows.