uze6666 wrote:
No need for that, the kernel already fetches all the 16 bits. So you could use those to for the coin counters
Well that's good, but first let me explain what a counter counter is:
That metal box with all of the numbers inside above the service switch button is the coin counter. Every time a coin goes through the mechanisms and activates the coin 1 or coin 2 line, the game board sends either 12 volts or 24 volts (I forgot which one) to the coin counter to increment the number. From what it looks like, I would not be able to attach the coin counter to a free pin on the SNES controller circuit since the coin counter is an output not an input. According to the standard pin allocation post it seems that:
Do you see any difficulty in getting it to work with optic rotary encoders, like those used in Arkanoid and Tempest-style spinners, as well as steering and track balls? I'm 99% the answer is obviously that there's no problem, but thought I'd ask. Custom games that use Star Wars flight yokes would be pretty cool too, I think those use potentiometers.
That's a good question. The current goal for the Uzebox project is to be able to fit into most JAMMA cabinets which use standard joysticks and buttons. Most of these cabinets don't use the JAMMA interface, those I've seen some use JAMMA with an extra harness for those controls. Though that is a good question. It can be possible to use encoders but it may be more difficult with potentiometers. Potentiometers would require the use of a ADC probably.
And remember, this is an open source project. If somebody wants to make a game with those types of controls he/she is free to do so. Though I will consider the suggestion and experiment. I have a replacement TRON spinner encoder board which I can try wiring up to see how it functions. If there were to be some type of analog/encoded controls, they would most likely have to be separate from the JAMMA harness and be wired into the board somehow.
Encoders ("spinners") can generate some really fast signals. I suspect that without some external hardware you'll have trouble keeping up with a raw quadrature encoder input in software with the rest of the Uzebox kernel stuff happening. (If you miss one clock edge you essentially lose the count direction-- so when the kernel is pumping pixels out if it's not watching the quadrature inputs you're going to have problems.)
That having been said, an average speed AVR (~12MHz+) can keep up with four channels of relatively low resolution encoders just fine-- if that's all it has to do. (I've used AT90S8515's on up to XMega32A's to read four channels to support two Happ trackballs in arcade machines.) A Mega32 @ 32MHz for example can super sample four trackball inputs fast enough that a power drill spinning a trackball shaft can't outrun the software sampler. You're even better off with interrupts, but I don't think that'd work on the Uzebox.
If you go to something like a TRON spinner (or Sega-- like Star Trek, Tac/Scan, etc.) the pulses per revolution are much higher (I don't remember exactly, but I think a TRON spinner has close to 128 slots per revolution vs. like a Happ trackball disc that's only 24) and you need to be proportionally faster to keep up. IIRC, Arkanoid has a geared spinner, so I'm not sure what it's pulses per revolution is.
Just FYI, all the older arcade games generally had a direction latch and pulse accumulator (of various sizes) to keep track of the encoder position with more infrequent polling from the CPU.
uze6666 wrote:Ohh I see! Indeed you will need an output pin then. PD5 is good for me. I guess you'll need a relay or triac to drive your counter though.
Arcade coin counters are typically +12V on the high side (sometimes +5V) and switched to ground. So a decent N-channel MOSFET will work fine. A protection diode is a good idea (even with a MOSFET) to snub back-EMF. For multiple channels (like dual counters and/or driving some control panel lights) I use a ULN2803. Logic level input and it'll sing a coin counter safely. I parallel up two channels per coin counter, just to be safe.
Something jet popped into my mind a day or two ago. Many arcade games have settings which can be adjusted (coins per credit, lives per game, upright or cocktail, etc...). These settings are configure via DIP switches and sometimes through software in a separate setup screen. I am debating whether or not I should include some DIP switches on the board for game configuration or have a program that changes values in EEPROM which the games read.
I am debating whether or not I should include some DIP switches on the board for game configuration or have a program that changes values in EEPROM which the games read.
Personally, I'd go with "virtual dip-switches" with the EEPROM.
I am debating whether or not I should include some DIP switches on the board for game configuration or have a program that changes values in EEPROM which the games read.
I agree that virtual dip-switches using the EEPROM would probably be the best idea. This would eliminate the need for extra hardware upfront to build it and would allow for everyone to experience the game with the different settings on NON-Jamma UzeBoxes.
So you could use those to for the coin counters
