On Sat, Dec 29, 2007 at 12:34:13AM -0500, user@domain.invalid.holland-consulting.net wrote:
quoted text
> Gary Baluha wrote:
> > On Dec 27, 2007 10:41 PM, Douglas A. Tutty <dtutty@porchlight.ca> wrote:
 
quoted text
> >> You could have a "Please wait" light to be lit during the reboot.
> 
> This is precisely why I asked this question, to make sure this doesn't
> happen.  While having a self-cleaning mess beats having a persistent
> mess, I'd rather just avoid the mess. :)
> 

With standard COTS hardware and a admittedly bug-containing OS (yes,
everyone agrees that even OpenBSD contains bugs), you cannot guarantee
that something won't happen to either cause a spontaneous reboot or to
make the device stop working causing any heartbeat monitor to force a
reboot.

 
quoted text
> Getting an off-the-shelf MP3 player to play one sound file is not too
> difficult.  Ah, heck, a tape loop would work fine, too.
> 
> Getting it to play one of a pile of different sound files, not trivial.
> 

I didn't read your description of the issue to mean playing different
sounds.  With this spec, some sort of logic would make sense.

 
quoted text
> As it is, 1/3 of the storage device (I'm not gonna use the 'f' word here,
> as people apparently keyed off it and have been answering questions I didn't
> ask, so just pretend it is a little, slow disk) is a DOS FAT partition, so
> someone (anyone!) could remove the storage device, plug it into their
> Windows computer, and add, remove, replace, or re-order the message files.
> (I've also set it up that if someone plugs a USB storage device in at boot,
> it uses that for sound files rather than the "on-board" files.)

I wouldn't want to risk the root filesystem by having the device its on
be plugged into a random user's windows box.  It would make more sense
to use your CF card for the root device and provide a USB port under a
flap or something for people to mount replacement sound files.  It would
be nice if it could be ro mounted-on-insert and used with the next coin and
unmounted-on-removal to revert to the built-in tunes.  Save the reboot.

 
quoted text
> About the only compromise I took that I really didn't like was not using
> the parallel port for the input on the thing.  I wasn't having much luck
> doing that when the idea of using a mouse as an input device was suggested
> to me by the artist I'm working with.  My first thought was, "that's crazy",
> but then I realized I could simply hack wsmoused to execute a program
> whenever the mouse is clicked, and ta-da, we got ourselves a solution.  I
> don't think I spent more than a couple hours doing that before I had
> a demonstrator program running.  When I got the opportunity to get the
> iPaq desktops, I grabbed one, flipped it over, saw PS/2, parallel and
> serial ports, figured "That's it!", and grabbed twenty of the things.
> You can see where I'm going: I kid you not, the one I grabbed was the ONLY
> one with PS/2, parallel and serial, the rest were all "legacy free".
> Suddenly, the mouse-as-input-device didn't seem anywhere near so stupid. :)

What was the problem having the coin detector trigger the "printer
ready" line on a parport or one of the status lines on a serial port?
Would seem to be less hacking.  Personally, I would avoid hacking the
base system (e.g. wsmoused) and instead have my program over top of
base.  Python has both a parallel and a serial module to allow accessing
those ports.  

quoted text
> If something goes wrong in the field, the people near the machine will be
> much more likely to be able to put a monitor and keyboard on it than they
> will be able to put a serial terminal.

I wasn't suggesting a serial terminal for use by the user.  I was
suggesting a phone jack that the user plugs in then you or another
service tech dials in to the unit from the comfort of your office.

Summary:

I still suggest a heartbeat monitor and a modem.

Good luck,

Doug.