Using the Propeller as a pinball controller is very possible and practical, and there are a lot of folks on this forum that will help you with any questions you may have.
While I have not done much work on pinball machines I don't see that the circuitry is much if any different from the automation systems I have worked on, and would certainly chip in with suggestions. You can also take advantage of the objects in the OBEX for reading switches, controlling leds and solenoids, and most other functions you may need.
To start I would suggest posting an initial diagram and listing the number of switches to read, types of led displays and their current/voltage requirements, and solenoids with their current/voltage needs.
The pinheck board in America's Most Haunted (as well as other Spooky Pinball games) uses a Propeller to do sound/music and drive the DMD display. That's all coded in Spin/PASM, and I helped Ben with some of that code.
The gameplay and whatnot is done by a PIC coded in C.
I am experimenting with large-scale pinball i/o driver, currently (theoritically) able to flexibly do 100+ IOPS on 30+ elements, but my ambitions are much higher.
Also, main idea behind it is to be able to use ANY language, thats my secret sauce
Just asking is it possible to convert Arduino code to spin or run Aduino code on a propeller chip, I have found a lot of useful stuff on the internet that other people have done for pinball using Arduino
I convert useful bits of Arduino code to Spin all the time. If you stick with C it may be easier. About the only thing that I really like about the Arduino is the millis() function. Since the Propeller doesn't have interrupts, I launch a cog like this:
var
long bgstack[32]
long millis
pri background | t
millis := 0
t := cnt
repeat
waitcnt(t += MS_001)
millis += 1
' call other background methods in the time left
Instead of having a function, I have a global variable called millis that I can use or even reset if needed (you can't do that with the Arduino without resetting the whole program). There is a lot of time left in the background loop so I uses that for "background" features that make sense for my application. On the EFX-TEK HC-8+ controller I use this time to update an R/G LED (which can be red, green, yellow, or off, and blink two colors if desired) and scan a couple shift registers which gives me the TTL inputs and the settings of the board's DMX switch.
Perhaps you could supply some detail on your bare homebrew pinball rather than what you think it might need. Also it always helps if you insert the link to some information on any particular product that you mention such as the HUB75 panels. Could you use a VGA monitor in place of these LED panels as the Prop can generate the video easily?
The Prop itself is not really capable of running a resource hungry language like Python but I know which fast and compact interactive language I would specify
Perhaps you could supply some detail on your bare homebrew pinball rather than what you think it might need. Also it always helps if you insert the link to some information on any particular product that you mention such as the HUB75 panels. Could you use a VGA monitor in place of these LED panels as the Prop can generate the video easily?
The Prop itself is not really capable of running a resource hungry language like Python but I know which fast and compact interactive language I would specify
@bossgp, since you're new, you may not realize this but Peter is clearly advocating the new Whitespace interpreter for the Propeller.
These could be combined to read the switches and multiplex the leds with shared circuitry, pins, and code.
2 - up to max 30 solenoids
Four ‘595/TPIC style shift register chips could drive 32 solenoids.
The max voltage and current the solenoids require will determine the type of drivers required.
3 - Read the sdcard for music, sounds, and display animation, to drive 2 X HUB 75 LED PANELS 128 X 32 for the DMD display.
Music/sounds using one or two pins for PWM. Display animation would be the hard part. depends on the display hardware.
4 - Maybe a few servo's for toys on the playfield
A ‘595 or similar shift register for up to 8 servos. Could possibly be combined with #1 circuitry.
All this could possibly be done by a single Propeller if the hardware and software were carefully designed. Not likely to be done in Python, but Spin/PASM, Tachyon, or C may work.
Perhaps you could supply some detail on your bare homebrew pinball rather than what you think it might need. Also it always helps if you insert the link to some information on any particular product that you mention such as the HUB75 panels. Could you use a VGA monitor in place of these LED panels as the Prop can generate the video easily?
The Prop itself is not really capable of running a resource hungry language like Python but I know which fast and compact interactive language I would specify
@bossgp, since you're new, you may not realize this but Peter is clearly advocating the new Whitespace interpreter for the Propeller.
David-
???. I would think peter is referencing Tachyon?
Maybe the whitespace space and tabs can represent bumper and ball actions? This also simplifies the display which can utilize a zero-power cellulose flat-screen to display whitespace code and results using a null-wire bus interface.
Put an LED + resistor onto SCL to Vdd as a quick diagnostic aid. When the Prop is booting you can see it flash. If it doesn't flash then the Prop isn't booting and it has nothing to do with the eeprom of which you can only load 32kB directly from the Spin tool, the other 32kB + 64kB in another I2C device address is up to your code.
Post a couple of clear photos of the board from top and bottom as that may yield a clue.
@Peter, I have seen two variations of the basic Propeller circuit. One has pull-ups on SDA & SCL, the other has one on SDA only. And do you see any need to keep an LED on SDA permanently?
EDIT: After thinking this out, both pull-ups are a good idea if you are using these line's as a bus for comunication between multiple devices.
yes, pull-ups on both lines are (should) be standard. Parallax is lazy there not putting pull-ups on both pins.
The reason is as you said the use as a buss. Having pull-ups on both lines allows the driver (Prop) to just drive the pins low or float them, but no need to drive high.
The scl pull up is not really necessary so it is not a matter of laziness or expense but rather one of practicality for that design perhaps as I have done this myself. The led + resistor I mentioned for diagnostics is not meant to replace the actual pull up though. Some PCB designs I do are very tight and it is practical to leave it off since scl is only ever driven except with one or two unusual chips that I never use. Where a pull up is useful for me is allowing more than one cog to use that pin as output control is or'd which means if you need to leave a pin high you can't control it from another cog until it is released by floating the pin. A pull up ensures that the pin floats high yet can still be controlled by another cog.
bossgp
Posts: 13
Comments
While I have not done much work on pinball machines I don't see that the circuitry is much if any different from the automation systems I have worked on, and would certainly chip in with suggestions. You can also take advantage of the objects in the OBEX for reading switches, controlling leds and solenoids, and most other functions you may need.
To start I would suggest posting an initial diagram and listing the number of switches to read, types of led displays and their current/voltage requirements, and solenoids with their current/voltage needs.
The gameplay and whatnot is done by a PIC coded in C.
Also, main idea behind it is to be able to use ANY language, thats my secret sauce
I convert useful bits of Arduino code to Spin all the time. If you stick with C it may be easier. About the only thing that I really like about the Arduino is the millis() function. Since the Propeller doesn't have interrupts, I launch a cog like this:
var long bgstack[32] long millis pri background | t millis := 0 t := cnt repeat waitcnt(t += MS_001) millis += 1 ' call other background methods in the time leftInstead of having a function, I have a global variable called millis that I can use or even reset if needed (you can't do that with the Arduino without resetting the whole program). There is a lot of time left in the background loop so I uses that for "background" features that make sense for my application. On the EFX-TEK HC-8+ controller I use this time to update an R/G LED (which can be red, green, yellow, or off, and blink two colors if desired) and scan a couple shift registers which gives me the TTL inputs and the settings of the board's DMX switch.
The Prop itself is not really capable of running a resource hungry language like Python but I know which fast and compact interactive language I would specify
@bossgp, since you're new, you may not realize this but Peter is clearly advocating the new Whitespace interpreter for the Propeller.
Four ‘595/TPIC style shift register chips could drive 32 solenoids.
The max voltage and current the solenoids require will determine the type of drivers required.
Music/sounds using one or two pins for PWM. Display animation would be the hard part. depends on the display hardware.
A ‘595 or similar shift register for up to 8 servos. Could possibly be combined with #1 circuitry.
All this could possibly be done by a single Propeller if the hardware and software were carefully designed. Not likely to be done in Python, but Spin/PASM, Tachyon, or C may work.
David-
???. I would think peter is referencing Tachyon?
Maybe the whitespace space and tabs can represent bumper and ball actions?
Post a couple of clear photos of the board from top and bottom as that may yield a clue.
EDIT: After thinking this out, both pull-ups are a good idea if you are using these line's as a bus for comunication between multiple devices.
I am missing capacitors in your description, the prop needs some capacitors really near to the pins for vdd/vss.
Best schematic might be that for the breadboard PE kit.
Enjoy!
Mike
yes, pull-ups on both lines are (should) be standard. Parallax is lazy there not putting pull-ups on both pins.
The reason is as you said the use as a buss. Having pull-ups on both lines allows the driver (Prop) to just drive the pins low or float them, but no need to drive high.
Enjoy!
Mike
You just compile this main file and all sub files get included automagically.
Enjoy!
Mike