Why do you think Atari used trigger latches?

[Bryan]

It's interesting to me that Atari didn't connect the triggers to regular IO, but to latches. The only reason I can think of is so BASIC programs would be able to keep up with joystick events, but it would be just as easy to make the OS simulate a latch in RAM. Any ideas?

 

[Rybags]

In a way they're latched if you're reading the OS Ram variable since it's persistent until the next VBlank.

 

Why the latch option is available, no idea. I doubt many button presses would be under 1 frame duration.

Maybe it's another of those things that emerged during development where another chip just did the function & better anyway.

e.g. Pokey's 64KHz mode equates to scanline frequency exactly and Timers can be used instead of DLIs but ultimately much more cumbersome to use.

 

In this case, maybe latching was in aid of the light pen or something, although as it turned out Antic does all the light pen beam detection processing.

 

Or maybe there was the foresight, given that the joystick pins can do I/O that the TRIGs could receive input from future "lab kits" and such devices might have very short event times that might be missed by software polling alone.

 

Then again, having the TRIG bits as configurable to either input or output would have been way more useful than what we got.

[Bryan]

The lab kits are probably the best explanation I've heard. If Atari envisioned the ports being used for all kinds of miscellaneous I/O, then being able to capture all kinds of events is a useful feature. It was before its time, but the A8's would have made good industrial controllers (esp. the 400). When you buy a PLC today, you're getting a little box with similarly programmable IO.

[Rybags]

Possibly it is in aid of the light pen/gun.

 

It's been a while... but don't the PENH/PENV values remain persistent until Antic receives another TRIG0 transition?

Software could utilize TRIG latch mode to see if the user is still pointing the pen at a given position or not.

 

Which brings up another idea I've had a while but not tested... the PENH register is tripped regardless of where the TRIG input is coming from (you can activate it with a joystick) - a little loopback cable would allow software to determine the current horizontal position of the scanline, albeit needing a write, then read PENH. Probably novelty value only since with WSync and knowing what graphical environment exists, cycle-exact programming isn't too much of a chore.

[Bryan]

That reminds me of a little hack I wrote to fake a software IRQ by flipping the mode of the control pins on the PIA. Don't remember why I wanted it but it worked like a charm.

[ricortes]

Just odd thoughts.

 

I think 'logic probes' were really popular in that time period. I had a number of friends would would reach for a logic pen before they would turn on an oscilloscope. I never became proficient in their use. Lots of events happen to fast to detect with a normal logic function so the good logic pins of the day had a latch function so you could tell what is going on. For instance if you want to check a single write to the $D500 line a fast logic pen in latch mode would get you results in seconds. Of course the 400/800 were not logic probes. I saw one guy just place a logic probe on several locations on a motherboard in less then 10 seconds to find out what was wrong. Started with power pins and system clock to make sure it was running and a few other locations. Some people back then really knew their work.

 

I've toyed with the idea of a semaphore line for data transfer. Something that could be interrupted to do other stuff and still transfer data as fast as possible. Latched registers seems to be the way to do it but it was only a mental exercise. Something like the sender sets the state and the receiver gets the data and changes the state of the latch. i.e.

while latch is zero, nothing there so go about your business

when latch changes to 1, read the data and ack

sender sets new data bit followed by setting logic level to zero

receiver sees the change in the semaphore line and reads the bit.

 

So a bit gets transferred on each logic change rather then a full clock or time wait like RS232. I'm not sure where I saw it, probably a National Semiconductor 1 line temperature sensor or Motorola design back in the 70s.

 

I guess I am just trying to say latched data used to be much more important. Seems much less important now that everything is parallel. Then again, I know nothing about SATA.

[Creature XL]

FYI:

 

I like this "feature". I use dit in MJO. When you press you the trigger to skip the intro.

This is really helpful. You migh tthink I could use as well a variable in my code, but it is not.

There are multiple places/loops which check for the trigger. For example, I use G2F pictures.

When you skipp this picture my main program knows about it without modifiyng the code generated from G2F.

I hope the explaination wasn't to confusing

[Rybags]

Understood... you have that persistent flag automatically cleared for you until you no longer need it.

 

Also... just maybe there's some tie-in with the future FGTIA design for Secam systems.

Since Secam needs the extra lines on GTIA, the TRIGs there were processed serially so they could be input on a single pin.

[Bryan]

Understood... you have that persistent flag automatically cleared for you until you no longer need it.

I don't quite understand.. do you mean you have a flag NOT cleared until you no longer need it?

[tep392]

It seems reasonable to me that someone jabbing at the button could occasionally hold it less than 1/50th of a second so the press could be missed without a latch. Maybe I'll hook my scope up and take a look.

 

My guess is that the designers thought the cost adder of the gates required for the latch's was insignificant, so why not add them. It's a conservative design approach.

[Rybags]

Maybe they envisioned some future controller which would generate a momentary pulse.

 

Or more likely - chances are they had the OS in early stages and it was assumed that software would just read the hardware registers periodically and there'd be no shadowing.

The TRIG shadows are kind of useless anyway - you're still doing a nonzero-page read which costs the same memory/cycles.

 

Err... flag. Probably a peristent "NOT" flag that gets cleared automatically for you.

[Bryan]

Ah, got it. You meant the literal bit, not the condition of 'latched'.

[Kr0tki]

The explanation is way more straightforward. They used latches in the CTIA, because they did the same earlier in the TIA's trigger inputs.

[+Stephen]

The explanation is way more straightforward. They used latches in the CTIA, because they did the same earlier in the TIA's trigger inputs.

Well, that begs the question, why did they use latches in the TIA?

[Kr0tki]

Of course. Well, they might have inherited the idea from an earlier arcade game.

 

The VCS docs don't provide a hint on why they did it, but I can imagine it being a convenient feature on a system as limited as the VCS. Having latches, one doesn't have to check the triggers every frame. For example, a kernel might read only one trigger per frame, and only reset both trigger latches every second frame, thus saving precious kernel time.

[+Stephen]

Makes perfect sense. I'm not a hardware guy at all and have not had the pleasure(lol) of 2600 coding.

[+JAC!]

I think the point is that real HW trigger a bouncing heavily. The latches on VCS served the same purpose as the shadow registers on the Atari. Today there are many program that are coded on the emulator (where there is no bouncing) and they become unplayable/usable when you play them on the real machine. Code like this

START

A LDA $D010

BNE A

LDA $D010
BNE B

<do somethoing>

GOTO START

 

works nice in the emu and on the real hardware you'll get dozens of main loop iterations of <do something> is fast enough. I had the problem myself with a game I'm wirting in ACTION!. The trigger picked/dropped a tile - it was uncontrollable until a realized I was used the HW registers instead of the shadow. That one reason why all the hardware register for input are read only once during VBI and then "latched" in the shadow registers. The VCS does not have an interrupt and esp. no RAM to store the information separately. It was far easier to put single latch bits there than spare parts of the precious 128 B RAM. For the same reason there is no real sense of having latched behaviour in the XL/XE anymore, but as Rybas mentioned, GTIA is simply designed as "TIA" +"G" :-)

Edited April 2, 2014 by JAC!

[erichenneke]

Just wanted to confirm something...

 

As far as I can tell it seems that the PADDLE trigger cannot be latched like the STICK triggers can be latched. Is that true?

 

If there is a way to latch the paddle trigger, I'd be interested in trying it out.

 

-Eric

[kenjennings]

Paddle triggers are actually joystick direction lines. There is only one joystick and so one joystick trigger per port. But, two paddles per port, so something else had to be done to supply two paddle triggers.

[erichenneke]

Paddle triggers are actually joystick direction lines. There is only one joystick and so one joystick trigger per port. But, two paddles per port, so something else had to be done to supply two paddle triggers.

ah, good point !

 

Hmmm, thinking if there is still a way to "latch it" given that it is really just a joystick direction = paddle trigger ??

[Rybags]

You could use a short assembler routine in VBlank.

It would work for potential missed events because your Basic program is too slow but wouldn't be any good for very short events that the OS VBlank shadow copy doesn't pick up, though any normal trigger press will have a duration well over 1/60th of a second.

 

Just make extra copies of the PTRIG variables, AND them each time with the OS shadows. So, give all values initial value 1. Once you acknowledge a trigger event (it's value will be 0), set the value back to 1.

 

For very short events, as was stated there's no latch so not possible to register unless you monitor the port directly at much shorter intervals.