Yeah the cabinet could be set up with the monitor's power switch on its own controlled circuit so that a startup program can power it up when windows boots (3rd party in startup folder) or when the FE auto-launches after windows boot if the serial is to be controlled from FE directly. Then if someone powers on the cabinet, monitor is blank until it's ready and windows is set up to run MAME after boot. As long as there's no crashing. The circuit could have a 2 minute timeout so that if it hasn't been instructed to power on within that time, it will come on and then you can see what went wrong (I posted another project for power on delay triggering, which may be useful in that).
Likewise when shutting down, kill monitor power before anything else to avoid seeing the useless stuff and have a 2 minute time-out that kills everything if it's taking too long and likely crashed anyway.
rotating monitor is right up my alley (",)
(",)
Which is bad as other games use that light and if you are typing (or in xp) the knocker can get stuck in the on position, thus burning it out
XtremeVBtalk (Did I see your name over there when I was searching on a few topics?? Something about mouse stuff and math stuff. I think I came across that when I was trying to figure out "Why can't I scroll in the source code text editor with the damn mouse wheel?")
Maybe eventually I'd solder a prototype and document the way I did it with pictures. Building the other stuff like the actual power side driver circuits being controlled may be a bit more stressful like if someone had to build a fancy DC motor bidirectional controller from scratch for a rotating monitor, there's a bunch of discreet components to solder up in the way I'd do it and I'd find it annoying myself but I can take scrap drivers from work so I'm going to shortcut that.
The project has officially reached its functional stage. Now it just needs to be enhanced as time goes on.
Everything would work except instead of the "Set" command for channel 1 and 2, we'd use the unimplemented momentary trigger command so it will automatically just pulse the channel high and then return to low until next trigger, otherwise we'd have a latched channel that needs to be somehow cleared.
So Mamewah will automatically pass vertical or horizontal info based on the game? That's very useful for this to work.
It would be convenient if a front end sent all pertinent discreet details that could be useful in hardware control projects but
even if just the game name is passed, that would be useful enough that the batch file could run another program to go digging for that rom set info and find out what it needs to know
After I find time to sleep I'll start implementing the unimplemented microcontroller features like the momentary thing, toggle on/off from whatever is current state, etc. I gotta stop going to BED at 5am when I get up to work at 6:30am.
druin, on the software end you have things well in hand, however, looking at the interface you designed.... ughh
My question is why over-complicate things? I'm sure there's one out there, but I can't really think of a reason you'd need more than about 8 i/o pins tops.
Another idea I have thought about - and is opened up by this project is to auto-switch the orientation of the joysticks from 4 way to 8 way for each game..
Another idea I have thought about - and is opened up by this project is to auto-switch the orientation of the joysticks from 4 way to 8 way for each game..
Oky, now THAT I can see being VERY useful! Bring on the solenoids!
Another idea I have thought about - and is opened up by this project is to auto-switch the orientation of the joysticks from 4 way to 8 way for each game..
I think what I'm geting at here is although the ultimarc sticks are ok... compared to the proper sticks they sorta suck.
(Have fun making a mechanism to remove the e-clip of your Super, flip the actuator and refit the clip, lol)