A new intellivision controller possibility?

[stc2009]

The only thing that bothers me about the INTV controllers is the side buttons barely move, they work, but still awkward.I would like a controller that has buttons that have more travel for a better feel.

 

Yeah I'm with you Rik, The side buttons never quite feel as if you've pushed it properly - but you soon find out if you haven't

 

But on a "New Joystick" project - the biggest limitation for me is that unless you're confident to solder it in for a Intellivision I the joystick will be limited to INTV II's (& III's?) which I get the impression don't really reside in large numbers outside of the Americas

[jaybird3rd]

I think that the control issues with Lock 'n' Chase have much more to do with the game itself than with the controllers. (Warning: possibly boring technical digression ahead ...)

 

One of the things I learned from programming the Aquarius controllers (which are very similar to the Intellivision's) is that hand controller input requires a lot of processing before the controls will "feel right" to the player. Making use of the hand controllers in a game isn't always as simple as reading disc directions and key presses: you usually need some sort of debouncing logic, and you may also need to use nested loops to implement different repeat rates and delays. Keyboard input requires similar processing, but modern keyboards contain dedicated controllers which handle all that for you; in the Intellivision and Aquarius, the hand controllers plug directly into the 8910's I/O ports, so everything has to be done in software. I don't know if the Intellivision EXEC included routines to make this easier, but even if it did, the games probably still needed to be "tweaked" to some extent on an individual basis.

 

Lock 'n' Chase was probably a game that simply needed more tweaking. I've heard that the control issues in the original 6K version were fixed in a later 8K version, but I've never seen this version.

[+DZ-Jay]

I think that the control issues with Lock 'n' Chase have much more to do with the game itself than with the controllers. (Warning: possibly boring technical digression ahead ...)

 

One of the things I learned from programming the Aquarius controllers (which are very similar to the Intellivision's) is that hand controller input requires a lot of processing before the controls will "feel right" to the player. Making use of the hand controllers in a game isn't always as simple as reading disc directions and key presses: you usually need some sort of debouncing logic, and you may also need to use nested loops to implement different repeat rates and delays. Keyboard input requires similar processing, but modern keyboards contain dedicated controllers which handle all that for you; in the Intellivision and Aquarius, the hand controllers plug directly into the 8910's I/O ports, so everything has to be done in software. I don't know if the Intellivision EXEC included routines to make this easier, but even if it did, the games probably still needed to be "tweaked" to some extent on an individual basis.

 

Lock 'n' Chase was probably a game that simply needed more tweaking. I've heard that the control issues in the original 6K version were fixed in a later 8K version, but I've never seen this version.

 

I'd like to add another technical note to yours. One of the reasons the older Mattel games are not as responsive is because the "EXEC" (the operating system of the Master Component, on which most older games depend) is not very responsive.

 

A bit of history: As opposed to the Atari VCS, where the console offers just the processor and other peripherals, and the games need to do all the work in handling the hardware; the Intellivision was designed to facilitate game creation by including a game "operating system" (the EXECutive) built-into the console that handled most general game functions. As Keith Robinson typically describes it, the EXEC is "the game program," and the cartridge merely contains a set of sub-routines specific for each game.

 

This was a great technological leap, and gave the Intellivision an edge in creating many titles with complex functions like graphics, sound, and input handling, without having to re-write those things for every single game.

 

The problem was with the implementation. And that's just a problem when you look at it with modern eyes. In retrospect it seems crude and slow, but you have to remember that the designers were trying to write this OS from scratch, at the same time that they are writing the games that would use it--all without an obvious model of game programming available at the time.

 

The other major requirement that they were addressing was robustness. The EXEC needed to work, under all circumstances, for every single game made, on every cartridge, every time. It also needed to be, in a way, "future-proof." Mattel will continue making games for years, and the EXEC would reside in "ROM" inside the Master Component, unchangeable. Three years down the line, it still needed to work with new games.

 

This is a very tall order, indeed. So rather than concentrating on spiffy features, they concentrated on making sure that the EXEC worked with simple games and complex games.

 

The EXEC has to do so many things: move and manage 8 movable "sprites," update sound and music information on the sound chip, update graphics information of the play field, alert the game-specific sub-routines of various events that occur behind-the-scenes (like when a player collides with an enemy bullet), read the hand-controller input and convert it to a useful format, etc. All of that needs to happen on every "game-cycle," so that graphics, music, and sprites all keep the pace with the state of the game.

 

The Intellivision (and most game consoles then and now) keep the pace of a game by using the synchronization signal sent to the TV as a timer. Every time a new TV picture frame is sent, at roughly 60 times per second on an NTSC set, the game "ticks" a game-cycle. The EXEC needs to do so much at once, that the designers made a simple compromise to ensure it will be able to keep up: they split the game-cycle into three of those "ticks."

 

Now the EXEC has plenty of time to do all its work, but instead of running at 60 Hz, it requires three times as much. Which brings us back to the original point of the story. The hand-controllers are read and decoded at 20 Hz. This means that any input must be sustained for longer than 1/20th of a second, or else it is missed. It also means that the game updates its state 20 times a second instead of 60, which makes the game feel sluggish and unresponsive.

 

As you play something like Lock'N'Chase, and your thief is about to reach a corner, you press on your disc to turn, but if you didn't do it at precisely the right moment when the thief reaches the corner, you may miss and have to wait until the next game-cycle; but by then the thief may already have passed the corner, and you have to turn around.

 

This, and various glitches and bugs in the way the hand-controller input signal is handled, as jaybird3rd suggested, is what makes the older games feel sluggish.

 

And what about the later games? How come they work better? After a couple of years of using the EXEC, programmers knew enough about its intricacies and the innards of the hardware, to work around its limitations or bypass it altogether. It is possible to fit a "game-cycle" within the built-in "heartbeat" provided by the TV signal, at 60 Hz. That's why later games from Mattel, Activision, Coleco, all the way up to the home-brews of today, not only seem more responsive, but their graphics and animations look smoother and the games feel faster in general.

 

 

-dZ.

Edited August 25, 2012 by DZ-Jay

[+Rick Reynolds]

Thanks for that write-up. I knew the EXEC was the cause of the sluggishness in older games, but I didn't know about the 3x issues. That explains a lot.

[Jeffrey Bouchard]

Hello,

 

As a fan of Intellivision and video games in general, Would it be possible to make new Intellivision style controllers with USB or as replacements for INTV 2, I etc? I own the Ultimate PC Interface and it works nicely on windows (still no luck on Linux) but with the controllers being old and or not working well. A modern version with USB and or works with the consoles would be great. Just an idea.

[+DZ-Jay]

Thanks for that write-up. I knew the EXEC was the cause of the sluggishness in older games, but I didn't know about the 3x issues. That explains a lot.

 

The problem APh (the engineers designing and programming the EXEC and many of the original Mattel titles) had is that there is a brief window of time during the TV synchronization signal (known as "VBLANK," for Vertical Blank) that the graphics RAM (GRAM) and the video chip (STIC, for Standard Television Interface Circuit) can be accessed and manipulated. As I mentioned before, the engineers were more concerned about making everything work in a stable manner than with speed and pizzazz, so they broke up this access into three VBLANK periods: on the first, some sprites are updated; the rest are updated on the second; and everything else happens on the third.

 

So it takes three VBLANK periods to perform a full "game-cycle," and the EXEC maintains the overall state of the game "frozen" until it completes. What I mean by this is that to the game-specific routines in the cartridge, the full information of the current state of the game is not available until the full cycle completes. The game therefore runs at a maximum of 20 Hz.

 

For reference, consider that a lot of modern console games that have plenty stuff to display, refresh the screen at no less than 30 Hz--and that feels a bit slow and flickery. However, that's typically only the display that lags behind. The game usually continues running at a faster pace, which is why you may notice at times that on a very "busy" screen, some objects tend to just flash from one place to another jerkily, rather than moving smoothly in between.

 

With the EXEC, that can't be done; the entire game runs slower, so input response is slower too.

 

-dZ.

[+DZ-Jay]

By the way, I'm by no means an expert on the EXEC or the Intellivision. The explanations I wrote are based on my understanding of how things work under-the-hood. Perhaps someone with more experience can corroborate or explain in more detail, although it gets highly technical quickly, and I don't think we want to bore any of you.

 

-dZ.

[jaybird3rd]

Thanks for that information, DZ-Jay! I vaguely remembered that the EXEC included hand controller routines, but I couldn't remember the particulars. Of course, on the Aquarius, one doesn't even have that luxury: there are several re-usable routines in the BASIC ROM, but there's nothing at all pertaining to the Mini Expander or the hand controllers.

[intvnut]

Throwing some more detail on Lock 'n' Chase specifically: It's actually known for its bad controls. Apparently, it was bad enough Mattel ordered a running change, although I suspect it never actually made it into carts on store shelves. The released version of the game is only 6K words, and the revised version is 8K. I haven't come across the 8K version in a released cartridge. If any of you have a Lock'n'Chase that displays a proper copyright symbol on the title screen, I'm told that's a sign you have the 8K version.

 

My own theory as to why Lupin is hard to control on the 6K version is this: You have to push the desired direction to move at pretty much the exact right time as Lupin moves through the intersection. If you press too soon, he won't make the turn. The revised version allows you to turn "ahead" of intersections more like Pac-Man.

[intvnut]

Thanks for that information, DZ-Jay! I vaguely remembered that the EXEC included hand controller routines, but I couldn't remember the particulars. Of course, on the Aquarius, one doesn't even have that luxury: there are several re-usable routines in the BASIC ROM, but there's nothing at all pertaining to the Mini Expander or the hand controllers.

 

Ah, the Mini-Expander doesn't have a ROM of its own? Then yeah, you'll have to implement everything yourself.

 

My own personal experience with directly processing the controller inputs suggests that the decode strategy needs to be aligned to whatever the game needs. For example, I use some heavily debounced input for Space Patrol's menus, but completely raw input to control the tank's velocity and detect the fire buttons. The only debounce is the "reload interval" for the bullets, and the acceleration/deceleration curves of the tank itself. You can't get more responsive than "raw", so if you can handle raw inputs, go for it.

[+DZ-Jay]

Thanks for that information, DZ-Jay! I vaguely remembered that the EXEC included hand controller routines, but I couldn't remember the particulars. Of course, on the Aquarius, one doesn't even have that luxury: there are several re-usable routines in the BASIC ROM, but there's nothing at all pertaining to the Mini Expander or the hand controllers.

 

Ah, the Mini-Expander doesn't have a ROM of its own? Then yeah, you'll have to implement everything yourself.

 

My own personal experience with directly processing the controller inputs suggests that the decode strategy needs to be aligned to whatever the game needs. For example, I use some heavily debounced input for Space Patrol's menus, but completely raw input to control the tank's velocity and detect the fire buttons. The only debounce is the "reload interval" for the bullets, and the acceleration/deceleration curves of the tank itself. You can't get more responsive than "raw", so if you can handle raw inputs, go for it.

 

I did the same in Christmas Carol (no surprise there, since I learn a lot from your own games). The Practice Menu has some heavy de-bouncing, and it is processed at 60 Hz. The game-play itself is taken "raw," and processed very close to "real-time." That is, the input processing routine is called at least once on every game-cycle, and constantly while the game engine is idle. This means that there is a high probability that the input is being read--and reacted upon--more than once per game cycle.

 

It may not be strictly necessary, but my personal observations suggest that it feels more responsive, especially on fast-action arcade style game. The sprite direction may not update as fast, but it somehow feels intuitively reassuring that the sprite seems to go in the direction you wanted, even though your thumb is rolling or twitching over the controller disc very fast.

 

-dZ.

[jaybird3rd]

My experience with the hand controller (at least so far!) is limited mostly to the menus and other UI elements in the Aquaricart. Those definitely required lots of processing for debouncing and repeat delays, but I can see why that would not be necessary or even desirable during gameplay.

[Purdy]

As is the norm on this forum, some really interesting posts and great discussion from well informed members...thanks folks!

 

My own thoughts re the controller would be to attempt to mod an original as a sort of half-way house. The disc could be replaced with a new part with a small 'thumbstick' attached. Some thought would have to be given to limiting the amount of force which could be applied to the stick to prevent levering the controller apart...perhaps a sprung stem.

A more robust pivot for the bottom of the stem would be desirable too.

As for the side switches, though there's limited room, it should be possible to squeeze in tactile switches.....perhaps....

 

As a plus the controller would still fit into the console...and the console box (at least on the original console).

 

I've no plans to try it though....I can't cos Ive already declared that I like the originals!

[+DZ-Jay]

I think that the control issues with Lock 'n' Chase have much more to do with the game itself than with the controllers. (Warning: possibly boring technical digression ahead ...)

 

One of the things I learned from programming the Aquarius controllers (which are very similar to the Intellivision's) is that hand controller input requires a lot of processing before the controls will "feel right" to the player. Making use of the hand controllers in a game isn't always as simple as reading disc directions and key presses: you usually need some sort of debouncing logic, and you may also need to use nested loops to implement different repeat rates and delays. Keyboard input requires similar processing, but modern keyboards contain dedicated controllers which handle all that for you; in the Intellivision and Aquarius, the hand controllers plug directly into the 8910's I/O ports, so everything has to be done in software. I don't know if the Intellivision EXEC included routines to make this easier, but even if it did, the games probably still needed to be "tweaked" to some extent on an individual basis.

 

Lock 'n' Chase was probably a game that simply needed more tweaking. I've heard that the control issues in the original 6K version were fixed in a later 8K version, but I've never seen this version.

 

I'd like to add another technical note to yours. One of the reasons the older Mattel games are not as responsive is because the "EXEC" (the operating system of the Master Component, on which most older games depend) is not very responsive.

 

A bit of history: As opposed to the Atari VCS, where the console offers just the processor and other peripherals, and the games need to do all the work in handling the hardware; the Intellivision was designed to facilitate game creation by including a game "operating system" (the EXECutive) built-into the console that handled most general game functions. As Keith Robinson typically describes it, the EXEC is "the game program," and the cartridge merely contains a set of sub-routines specific for each game.

 

This was a great technological leap, and gave the Intellivision an edge in creating many titles with complex functions like graphics, sound, and input handling, without having to re-write those things for every single game.

 

The problem was with the implementation. And that's just a problem when you look at it with modern eyes. In retrospect it seems crude and slow, but you have to remember that the designers were trying to write this OS from scratch, at the same time that they are writing the games that would use it--all without an obvious model of game programming available at the time.

 

The other major requirement that they were addressing was robustness. The EXEC needed to work, under all circumstances, for every single game made, on every cartridge, every time. It also needed to be, in a way, "future-proof." Mattel will continue making games for years, and the EXEC would reside in "ROM" inside the Master Component, unchangeable. Three years down the line, it still needed to work with new games.

 

This is a very tall order, indeed. So rather than concentrating on spiffy features, they concentrated on making sure that the EXEC worked with simple games and complex games.

 

The EXEC has to do so many things: move and manage 8 movable "sprites," update sound and music information on the sound chip, update graphics information of the play field, alert the game-specific sub-routines of various events that occur behind-the-scenes (like when a player collides with an enemy bullet), read the hand-controller input and convert it to a useful format, etc. All of that needs to happen on every "game-cycle," so that graphics, music, and sprites all keep the pace with the state of the game.

 

The Intellivision (and most game consoles then and now) keep the pace of a game by using the synchronization signal sent to the TV as a timer. Every time a new TV picture frame is sent, at roughly 60 times per second on an NTSC set, the game "ticks" a game-cycle. The EXEC needs to do so much at once, that the designers made a simple compromise to ensure it will be able to keep up: they split the game-cycle into three of those "ticks."

 

Now the EXEC has plenty of time to do all its work, but instead of running at 60 Hz, it requires three times as much. Which brings us back to the original point of the story. The hand-controllers are read and decoded at 20 Hz. This means that any input must be sustained for longer than 1/20th of a second, or else it is missed. It also means that the game updates its state 20 times a second instead of 60, which makes the game feel sluggish and unresponsive.

 

As you play something like Lock'N'Chase, and your thief is about to reach a corner, you press on your disc to turn, but if you didn't do it at precisely the right moment when the thief reaches the corner, you may miss and have to wait until the next game-cycle; but by then the thief may already have passed the corner, and you have to turn around.

 

This, and various glitches and bugs in the way the hand-controller input signal is handled, as jaybird3rd suggested, is what makes the older games feel sluggish.

 

And what about the later games? How come they work better? After a couple of years of using the EXEC, programmers knew enough about its intricacies and the innards of the hardware, to work around its limitations or bypass it altogether. It is possible to fit a "game-cycle" within the built-in "heartbeat" provided by the TV signal, at 60 Hz. That's why later games from Mattel, Activision, Coleco, all the way up to the home-brews of today, not only seem more responsive, but their graphics and animations look smoother and the games feel faster in general.

 

 

-dZ.

 

By the way, one slight correction to the above. While the "game-cycle" of the EXEC indeed runs at 20 Hz, the music and sound effects processors do not. The sound chip is still updated on every VBLANK signal, which triggers at 60 Hz.

 

Graphics movement at 20 Hz is still acceptable to the eye, it just looks a bit "jerky," but no more than old-school Japanese animé cartoons. However, sound effects with waveform updates at 20 Hz may appear as if they are stuttering, which is less acceptable.

 

-dZ.

Edited August 26, 2012 by DZ-Jay

[Games For Your Intellivision]

The Exec was a one man show. Dave Rolfe wrote Baseball and the Exec at the same time.

[IntellivisionDude]

And i will add, that for those of you who haven't noticed the FAQ pinned at the top, there are some good topics in there about this very topic (alternate controllers)

[cparsley]

Pulls hair out...

 

Why you all dis Lock 'n Chase... The reason for the 6k to 8k change is folks whining that Lupin would stop in the tunnels.

 

The 6k version if you pushed in a direction of a wall, Lupin would stop dead in his tracks at that wall (personally the version I like)

The 8k version if you pushed in a direction of a wall, Lupin would ignore the controller press and continue along his previous direction. (This version also had room for both Mattel's and Data East's copywrights (easiest way at startup to see which your using), and also for the collapsing Lupin at death (which appears in the arcade version of Lock 'n Chase)

[First Spear]

Maybe Nurmix could modify his Flashback adapters to work with these puppies:

 

[wolfy62]

That would be great because I have a new one of those sitting on a shelf at my house.

[+nurmix]

Maybe Nurmix could modify his Flashback adapters to work with these puppies:

 

Atari5200trackball.jpg

 

Well now... not so sure that would be an improvement!

 

I love the original controllers. But that's not to say I don't have some ideas about "improving" them, or making an alternative available. I don't have anything concrete to talk about at the moment, but I am toying with some things.

[First Spear]

 

 

Nothing can truly replace the OG Intellivision controllers. But I was thinking that a track ball might "read" on the Inty basically the same way, with the trackball mechanics of rolling being equivalent to "rolling" the disc.... Not that there is a good source of 5200 trackballs out there...

[NumbThumb]

I have been playing around with designs for new controllers for a while.

 

I like the original controller for the original Mattel/Inty games, but it always bothered me and still bothers me that there never were any alternatives.
(At least not for me with a System III with hardwired controllers.)
The Intellivision II never made it to Europe I think, and even if it did the alternative controllers available, like the Wico joystick were not any good as I understand.

 

So, here are some design ideas for new controllers. I have tried to combine classic joysticks (and a d-pad) and arcade buttons without losing too much
of the feel and look of the original controller. Just making it a bit more ergonomic and also with bigger side buttons:

 

 

I am no expert but here is the basic idea and my general thoughts on the matter of new controllers:

 

The original controller is really good and innovative I think.
It excels in the original Mattel games but all other games are supposed to be played with a joystick or d-pad.

Like Pac-Man, Donkey Kong, Boulder Dash etc. etc.

 

Let´s face it. The number one complaint about the Inty is the controller issue…

 

I think the Intellivision would increase in popularity if there were joystick alternatives like there are for Atari and Commodore for example.
The possibility to try and find your personal favourite was great fun.

I tried many and have to say that the TAC-2 and Slik Stik became my preferred choises.

(Nr 1 in the image below has a Slik Stik stick btw, and the arcade buttons on top are also SlikStik.)

 

Nr 1-3 are the ones I would manufacture first. Nr 5 is just an improved version of the original controller and in my opinion not a priority since the original does the job.

 

Directions?

 

Would 4-way be sufficient for most non-Mattel games?
I would like 16-way for flying games with a “flyer” joystick though (nr 3). Games like for example Hover Force and Space Battle would be a lot more fun with that one.
Although not a 16-way game, Mission X would be much more fun with that as well. This joystick would also be to satisfy those who only want 16 directions…

 

With more than 100 000 Flashbacks out there and of course all the original consoles, I think there ought to be at least a decent market for new controllers.

I am pretty sure that a lot of people (especially newcomers) would like to have one or more alternatives.

 

I think these could be produced at a fairly low cost at a quantity of 1000-2000 pcs/model.
Looking briefly at China prices (without knowing exactly what to look for...) there is custom plastic injection from $1-2,

custom PCB:s from $1-2 and readymade joysticks from $2-5 at those quantities.

 

Not sure about quality and I have not found what a custom made stick would cost, but just saying that it looks like the finished product would not

have to cost a fortune in the end if you find the right suppliers.

 

If new controllers/joysticks were to be made I guess Hyperkin would be the preferred manufacturer since they are the manufacturer of the Flashbacks

as I understand and therefore already have the basic knowhow and the contacts with the retailers.

 

Anyways,

 

Just brainstorming here but it would be great with at least one new really good joystick for decent cost.
Be it in this design or something else.

 

And of course, if some sort of new 9-pin joystick controller would be a hit Nurmix would have to work his ass off making more adapter cables...

Edited September 9, 2015 by NumbThumb

[+BBWW]

Just get Intellivision well ported for an iPad and have a companion app for the I phone that mimics the original controller. Hook it up to you TV and go.. or now with the new osTV for the new Apple TV it would be even better...sort of...maybe...or not...

 

But the cost of two iPhones and an Apple TV will set you back more than $200 bucks. :-)

[+DZ-Jay]

I think 16-way is the only way to go. Sure, some games (most?) only read 4 directions, but as far as I know, the EXEC had routines to convert disc angles to velocity vectors, and a few tricks that took advantage of the 16 independent positions of the disc. I believe some games were not "directional" at all, but accounted for the change in the angle pressed on the disc to adjust acceleration or direction. At least that's how I remember it.

 

And of course, newer games would hopefully take better advantage of the actual hardware mechanics. (I still say that Christmas Carol works significantly better on real hardware than on a gated joystick, since it accounts specifically for thumb-on-disc rolling mechanics. I expect other homebrewers would do similar things.)

 

-dZ.

[First Spear]

I am with you on the 16-direction requirement. If I had to bet money I would say many games take 16 directions into account even if they are not explicitly requiring all 16 points to be "hit" in a game.

 

I think it would be cool to have a horizontal controller housing design.

 

 

Something the resembled a 21st-century controller, but was still the Intellivision innards, just placed differently. Disc on the left for the thumb, keypad on the right, side buttons are all placed along the top.

 

 

 

I think 16-way is the only way to go. Sure, some games (most?) only read 4 directions, but as far as I know, the EXEC had routines to convert disc angles to velocity vectors, and a few tricks that took advantage of the 16 independent positions of the disc. I believe some games were not "directional" at all, but accounted for the change in the angle pressed on the disc to adjust acceleration or direction. At least that's how I remember it.

 

And of course, newer games would hopefully take better advantage of the actual hardware mechanics. (I still say that Christmas Carol works significantly better on real hardware than on a gated joystick, since it accounts specifically for thumb-on-disc rolling mechanics. I expect other homebrewers would do similar things.)

 

-dZ.