What's new
I had some time to work on this today and built a python script for executing commands to the whole gpio bank at once using the pigpio library. Rather than sending out commands 1 pin at at time like I was forced to do with wiring-pi.
So far it seems to work WAY better than than the previous script I'm not seeing any command misinterpretation at all.

with this I setup a simple test script for testing the speed of commands. I issue a command then sleep before issuing the next.

The test uses the commands that set the segments one at at time. So I clear the display and then one command at a time I turn on each segment of the display (16 commands total). this means that if commands were issued too fast there would be a missing segment on the display.

I loop this 5 times and generally I can pick out if something didn't light up even if it wasn't on the final loop.

I was able to get the sleep time down to .00386 between commands (the actual time is slightly higher than that as it does take some clock cycles to prepare the bit-masks for each command before issuing). but even still that's about 250Hz and at that speed the display is flickering so fast you can barely make out what it's doing.

This bodes very well for making custom animations as it's definitely fast enough to make it work.
The method for writing to the whole bank at once also makes for a nice foundation for building a custom control app.
 
I spent half my weekend re-writing my Arduino code. I reconfigured a lot of it for better efficiency and of course updated with the new knowledge I've gained. I also built a test setup to run the real billboard concurrently with my arduino billboard so that I can see any differences in how they react in real time.

Here's a pic of my setup:
billboard_testing.jpg


15V Meanwell PSU in the lower left the arduino hanging below the desk and outputting to it's billboard on the bread board above, the arduino is hooked up to my laptop which has a serial monitor up that dumps out comments as the code runs so I can keep track of how it's processing the commands.
The Pi3 is on the desk to the right of the bread board and is running the keyboard and monitor in the center of the screen, I can punch in commands or command sequences on the keyboard and the Pi outputs it the same way a game PCB outputs billboard commands.

the big mess of wires is because the pi output, as well as the arduino input and the real billboard input are all tied together on the breadboard.

This was crucial to getting the winner lamp flash timing down. I was close in my initial estimates but the slow blink is 512ms on/off, med blink is 256ms and fast blink is 128ms. the double, triple and quad flash modes run at 205ms. I also discovered that the double triple and quad flash modes actually run on a 5 blink cycle. So the double flash blinks twice then skips 3 blinks, the triple flash blinks 3 times then skips 2 blinks, and the quad flash blinks 4 times and skips 1 blink. Also some weird timing quirks such as the triple flash, quad flash, and fast blink all start with the lamp in the off state, while the slow, medium and double flash all start with the lamp in the on state.

I am a bit frustrated with some of the arduino's limitations. it only allows for 2 interrupt pins, but I need to check for changes across 8 pins. Similarly I'd like to read in the data in a single command, rather than performing separate reads per pin. The right way to do this is by port. you can interrupt on a whole port and read/write to a whole port, but it limits the pins you can use.
The Arduino only has 3 ports. Port D has 8 pins (perfect!) but pins 0 and 1 are reserved for the serial connection (ok so that makes it useless). Port B only has 6 pins (wont work, too few), and port C only has 5 pins... WTF! Why the hell are there ports with fewer than 8 pins and why the hell do you reserve the serial pins for the only port that can carry a whole byte?

So for now I'm just hammering the input pins, compiling the byte and checking against my last read to determine if there's a change. Hopefully I can come up with a more elegant solution. There's no real threading available on the Arduino but I found a psudo thread timer library that allowed me to really clean up with code that handles the winner lamp blink timing... so at least there's that. This will also be greatly beneficial when I implement animations as it should allow them to run without (noticeably) blocking the input reads.
 
about threading in arduino, i just used state machine library. i've coded some arcade games not long ago and never needed interupt function.
 
about threading in arduino, i just used state machine library. i've coded some arcade games not long ago and never needed interupt function.
I'm not familiar with that library, I'm looking through the description but I'm not understanding how this can help me effeciently trigger a function when any one of 8 pins change states.
 
about threading in arduino, i just used state machine library. i've coded some arcade games not long ago and never needed interupt function.
I'm not familiar with that library, I'm looking through the description but I'm not understanding how this can help me effeciently trigger a function when any one of 8 pins change states.
are the changes for all the pins same? i.e. all is falling edge triggered, or rising edge? if it is, then might need additional ttl chip to 'sense' them.
well, maybe no need since the code is working already.
 
are the changes for all the pins same? i.e. all is falling edge triggered, or rising edge?
the change is not the same, I need to sense both falling and rising edge, and it it could happen on any one of 8 different pins.
Some pins will rise, some will fall, some will not change state, and the pins that change are not the same command to command.

Timing is not consistent either, I might have two commands come in 4ms apart, and then the next one might happen until 5 minutes later.

another problem is that by reading 1 pin at a time, sometimes the first few pin readings are for one command and the last few pins readings are for a different command because the change occurred mid-read. I need to read in all 8 pins concurrently as a single byte to avoid this problem.

My current solution is basically this:
Code:
last_val = 0;
while(1) {
  new_val = 0;
  new_val |= read_pin(0);
  new_val |= read_pin(1)<<1;
  new_val |= read_pin(2)<<2;
  new_val |= read_pin(3)<<3;
  new_val |= read_pin(4)<<4;
  new_val |= read_pin(5)<<5;
  new_val |= read_pin(6)<<6;
  new_val |= read_pin(7)<<7;

  if(new_val != last_val){
     handle_command(new_val);
     last_val = new_val;
  }
}
This is terrible inefficient but so far I haven't found a better solution.

If I could read a whole port, and set an interrupt on that port then whole thing could be reduced to 2 lines of code and it would only execute when it needed to, and it wouldn't have any mis-reads either, but there doesn't seem to be a single port on the Arduino that can do 8 pins at once.
 
Last edited:
The Arduino only has 3 ports. Port D has 8 pins (perfect!) but pins 0 and 1 are reserved for the serial connection (ok so that makes it useless). Port B only has 6 pins (wont work, too few), and port C only has 5 pins...
hmm, what the serial connection are for?
you can always use softserial that can use any pins, so the port D is free for you to use.
 
The Arduino only has 3 ports. Port D has 8 pins (perfect!) but pins 0 and 1 are reserved for the serial connection (ok so that makes it useless). Port B only has 6 pins (wont work, too few), and port C only has 5 pins...
hmm, what the serial connection are for?you can always use softserial that can use any pins, so the port D is free for you to use.
The serial connection is for debugging. I can open serial monitor in the Arduino IDE to view how the program is running.
AFAIK it cannot be moved to another pin. and if I remove it to use port D then I can't determine if the new program is working properly or not.

Are you on an Uno? Does the Mega 2560 have enough? There appear to be entire ports devoted only to digital I/O and not reserved for anything else.

arduino.cc/en/uploads/Hacking/PinMap2560big.png
Interesting... yes I'm on Uno, though it seems as if most of those pin aren't mapped to any of the actual headers:

uno.jpg

Notice the note on PD0 and PD1 that they're used for USB programming.
Port C only has pins 0-6 and port B only has pins 0-5
 
It looks like on the MEGA 2560 you could access all pins via headers on ports F, K, A, and C without conflicting with necessary dedicated functionality.

You're going to need one for your MEGA JVS anyway, so you'll have one on hand to play with anway. :D
 
looking at pinouts I might actually consider the Arduino Micro:
micropdf.png

the pins are all over the place but it looks like I might have access to all of port B, and it still has enough pins left over to control the 7 segment displays, winner lamps (8 outputs total) and have a few jumper/dip switch inputs.

@winteriscoming What software have you been using to design your PCBs? I'd like to start diving into that soon. it's been probably 15 years since I last did a PCB design ^^ I'm sure things have chanced since then.
 
@winteriscoming What software have you been using to design your PCBs? I'd like to start diving into that soon. it's been probably 15 years since I last did a PCB design I'm sure things have chanced since then.
So far I've exclusively used the free version of Eagle, which has a size limitation, but is otherwise full feature software. It's not the most intuitive program, but if you're running into any issues chances are that many others have before you and a quick Google search will give you an answer.

I'm on version 7.6.0 for what it's worth. When I originally downloaded it they had various tiers of costs for releasing certain limitations and some of the lower tiers were pretty reasonable for a hobbyist.

However, I was just looking at their site to see what the tiers of paid versions were and it looks like they might have recently moved to a subscription model, which is not a model I support... :(

I haven't looked into other options.
 
Eagle is what I used back in the day so I'm somewhat familiar with it. sucks that they're using subscription licensing now :-/

After some further investigation it looks like the Arduino Micro actually uses a slightly better chip than the Uno (ATmega32U4 vs ATmega328P). the major difference is that the 32U4 in the micro has native USB support and no native serial support while the 238P has native serial support but no native USB support. if you're buying the Atmel chips alone the then 32U4 is more expensive, but the Micro is cheaper than the Uno because it requires an additional FTDI chip for the USB interface.

This also means I wont be wasting 2 IO pins for USB debugging. Seems like a winner all the way round.
 
Eagle is what I used back in the day so I'm somewhat familiar with it. sucks that they're using subscription licensing now :-/
It must have been a pretty recent thing. It looks like they've been purchased by Autodesk.

I'm going to attempt to learn an open-source alternative. KiCad seems to come up in my searches as an open source alternative, so I'm going to start there. If it removes the limitations I was hitting in the free version of Eagle, but otherwise lets me use a similar design workflow, so much the better.
 
KiCad seems to come up in my searches as an open source alternative, so I'm going to start there
I played around with KiCad a little today and managed to load up some component libraries that included an Arduino footprint, create a schematic, create a board design, and generate Gerber files without too much fuss. I already found Eagle to be quite unintuitive, so moving to KiCad with Eagle expectations didn't really result in too much disappointment. I had to look up a few specific questions I had, but otherwise the workflow and capabilities seem pretty comparable. I kind of wish now that I had started with KiCad to begin with. I'll be using it for the PCB I design for the FFB translator.
 
I'll definitely start out with KiCad then, I'd rather use an open source product anyway.
 
Got the Micro in today... so far I like it!

arduino_micro.jpg


way more compact. my Uno code compiles for it without any modification and there seems to be more memory space on the micro too!

I haven't tried running the program on it yet as I'll have to re-do all my wiring but so far so good :)

I'm thinking from here forward I'll be buying these instead of the Uno.
 
@XeD asked me about this the other day and I realized I haven't posted an update in a while so I figured I'd add an update.

I have been chipping away at this despite not posting much.

For the Arduino Billboard emulator: I've got everything programmed and running except the attract modes, I have the code in place to run an attract mode loop, so it's mostly just entering in all the segment and timing data and then tweaking it until it runs right. I do also still need to migrate the code to the the Arduino Micro but that's mostly just wiring work.

I actually posted a short video on instagram a couple of weeks ago showing the "SEGA" scroll animation running on the real billboard as well as my Billboard emulator, having the real hardware tapped into the same control lines as my emulator is a great way to ensure that the timing is spot on.

http://instagram.com/p/BQzDsHql8OG/?taken-by=twistedchu

I'm also well under way on the Raspberry Pi Billboard controller: This will be for people who own a Billboard or Versus City cab (or the Arduino Billboard Emulator) and want to send their own animations, text scrolls or commands directly to it. I've got the "hard part" done that is a small python app that pushes out billboard commands. This is controlled via a websocket interface. I'm also building in provisions to save, and run "macros" that are sets of commands and timings so you can create your own animations or text scrolls etc. and then run them on command as desired.

I got a lot of work on this done last night since the blizzard we had here in NH knocked out my internet so I had nothing to do but write code :P

What I need to do now is build a nice web-interface for this. Currently it's just a single text box that you can issue commands to. Ultimately the goals is that you will install the Pi in your machine, then you can visit "http://vs_billboard" on your phone and run commands to make your billboard do whatever you want.

Once I have this built it should make it easier for me to work out the details of the attract mode which is why I stopped short of doing that on the emulation side of this project.

-------
There was also some discussion about also building a "scoreboard app". The idea being able to use the billboard as a win counter for games that were not originally designed for the billboard.

This wouldn't tie into the game board at all but rather the control app would keep track of the win counts and when a new win is recorded would update the score and play through a predetermined "win animation". This should be really simple to accomplish through the web interface I'm building, all I need a UI with a button for "P1 win" and "P2 win" then keep track of the score and issue the appropriate animation commands. I could also add provisions for 2 additional button inputs on the Pi so that physical "win counter" buttons could be wired into the machine or tapped into existing buttons (start or coin for instance).

This was XeD's idea and I think it will add a nice bit of usability to the billboards even if it's not as seamless as having them controlled directly by the Gameboard.

I'm open to suggestions if anyone has any ideas on other features or things they'd like to see.
 
So Last night I pulled apart all of the wiring and decided it was time to finally switch over to the Arduino Micro.

only to discover that on the micro, unlike other Arduinos, they don't dual purpose the serial pins for digital I/O use. So while I thought I had all of port B available... several of the pins are reserved for serial use so it looks like this wont work :-/

My options now look like either going forward with the Mega... which seems way overkill, or develop the code on the mega so I can debug and then switch it back to the Uno (which I should be able to make work with port read/interrupts but can't Debug over serial at the same time.

one benefit if I do switch to the Mega is that, I'll be able to get rid of the shift registers in my circuit since I'd have enough pins to output to each segment of each digit directly.

on the bright side I found ULN2803 transistor array looks like a good alternative to drive the high voltage LEDs compared to the very expensive M54583P used on the original Sega Billboard PCBs.
 
I've got the code migrated to the Mega 2560 and I've been able to reduce the input code from about 30 lines to about 5

17493729_1863617867213221_7181707286287482880_n.jpg


inputs are now triggered by a port interrupt rather than reading on every loop and comparing to the last read.

for anyone interested in working with multi-pin interrupts there's a fantastic write up here:
https://thewanderingengineer.com/2014/08/11/arduino-pin-change-interrupts/

information on this seems hard to come by but the above reference is great.

I did also have to implement a debounce as the interrupt was triggering twice on some commands with a partial port read on the second trigger. I'm unsure why but for now I'm willing to blame it on the Raspberry Pi not ACTUALLY performing a full bank set. I'll have to test it on actual hardware to see how it compares.
 
Back
Top