Re: [stella] Fire button routines

Subject: Re: [stella] Fire button routines
From: Mark De Smet <de-smet@xxxxxxxxxxxxxxx>
Date: Wed, 21 Jun 2000 22:33:46 -0500 (CDT)
> >Assuming that you are reading the register in vertical blank/overscan etc,
> >then you won't be able to tell the difference between that scenario and
> >holding the button.  This is effect the interferance case can cause.  If
> >you want to do edge detection, you can use the interrupt logic in the
> >PIA(only for the joystick or paddle buttons).
> But aren't there two ways to read the joystick buttons, one latched and one 
> not latched?  By not latched meaning the current state, not the latched 
> (locked on) state?

It is not two ways of reading, but two ways of configuring the hardware.  
Once you configure the hardware, you are probably not going to want to
change it(if using latched, you need to toggle back to non-latched to
clear the latch).  If it is setup as not latched for the entire frame,
then you switch it to latched, read it, and switch it back you certainly
don't have the latched data for the whole frame(because being in
non-latched mode clears the latch).  Not 100% sure what you would get if
you did this though.

NOTE, I am not 100% sure about this.  The manual is not clear enough on
this.  The latch may be always on, and by reconfiguring it, you are simply
deciding to read the line before or after the latch.  If this is the case,
then the latch is always active, and I guess you could use both mode in
the same frame(etc), but you would have to switch back and forth each
time.  I would have suspected that the configuration is actually enableing
or disabling the latch though.

> In games where you can hold down the fire button for a while (like Enduro) 
> you wouldn't want to clear the latch every single frame.  You'd read the 
> INTP4/5 while in latched mode, set to dumped mode by setting D6 of VBLANK 
> and read the direct value, and only clear the value if the button is 
> currently not on, right?  Then set back to latched mode.

There is no 'dumped' mode on I4/5, that is on I0-I3 for the paddles.  I
don't know why you would want to do what you are describing.(assuming you
mean not latched by dumped)  The only reason for the latched mode is to
catch presses of the button between times when you are checking.  This
could be to allow very fast presses, or more likely, if you don't poll it
very often.  If your game isn't a speed game, then you may want to have a
lot of calculations going on, and don't want to check the button every
frame, then you would turn on the latch, (after clearing it), do your
calculations(ignoring the input), then when you are ready, read the input.  
This way if someone pushed and released the button while you were doing
something else, you will know.  I would say 99% of games use non latched
mode(only a guess, no proof).  For enduro, you would not use latched mode,
but simply read the input directly.

> That way the latch allows you to test for sub-frame-duration presses later 
> within VBlank, but once in Vblank you can decide whether to clear the latch 
> based on the current direct value?

Yes, you can use the latch to test for sub-frame durations, but why would
you care for Enduro, you don't really push the button fast in enduro, just
hold it.  There is no reason to test the current value to determine
whether to clear it, you would clear it each time after reading it.  I
mean if it hasn't been pressed, then it is already cleared, so what's the
harm in clearing it again?  But if it has been pressed, you probably want
to clear it so that you can check again later.

Besides, switching it into non-latched mode does the clearing anyway, so
what you describe wouldn't work the way you seem to want it to.(ie. you
can read the 'current direct value' without clearing it)

NOTE: the latched port is inversed, in that when I/you have said clear,
you are logically clearing the latch, but that is really setting it to
1.  A button press is a logic 0.

> For games that enforce delays between missiles (like only one missile in 
> play at once like Combat) then the latch can be left alone and the button 
> ignored until the missile is expended, right?

Yes.  Whether or not you would do this depends on how you structure your
code to determine if the player is allowed to start a new missile.  You
point out a neat trick.  You could turn on the latches, then launch a
missile whenever the input goes from 1 to 0(start of press).  You would
read the input every frame, but you would not clear it.  You would only
clear it at the point in your code when the missile stops.  But then this
is only one possibility...

> It's just that if the latch locks on when the button is pressed and is not 
> cleared when the button is released, then the program needs to manually 
> clear the latch by testing the current state, right?

I does need to clear it if it want's to recognize another press later.(I
don't know why you wouldn't)  You don't really have to test the current
state.  I guess you could read the latch, and only if it has latched in a
press clear it, otherwise not, but that would probably take more code and
time than simply clearing it each time.

Has anyone used latched mode in thier game?


Archives (includes files) at
Unsub & more at

Current Thread