Intellisivion - Emulation of Disc, Keypad and Side-Buttons

[+wavemotion]

So I'm working on an update for Nintellivision (an Intellivision emulator for the DS/DSi) and I noticed something strange when using FWDIAG.

 

If I press the DISC RIGHT LEFT, it shows properly... I see bit 1 set (really cleared as it's inverted).  If I press one of the TOP buttons, I see the 101 pattern that shows correctly in the upper bits.

 

But when I press both DISC RIGHT LEFT and TOP button together, I see those light up and the correct bit-pattern (both on the hand-controller and at the FWDIAG DB9 pinout) but I also see the buttons 4 and 6 light up on the hand-controller diagnostic.

 

And this perplexes me... I know the KEYPAD and the DISC/BUTTONS can ghost in combination but the DISC and BUTTONS should never ghost - by design (the controller is basically designed to be either DISC+Action BUTTONS or KEYPAD but not really both at the same time... though I do support the 'Dual Action Controller' which some games support by using the DISC/BUTTONS from Controller 1 and Keypad from Controller 2).

 

Can anyone with FWDIAG running on a real system let me know if they see the same behavior?

 

Thoughts of any kind?

 

Edited September 14, 2022 by llabnip

[+DZ-Jay]

I do not know FWDIAG, but it seems that it does not disambiguate between the signals, which seems a propos for a diagnostic tool.

 

As you say, DISC-RIGHT (from the image and the code, it is right, not left) and BUTTON-TOP are represented correctly, as "10100010"; but this signal also overlaps both keypad input for KEY-4, "10000010," and KEY-6, "00100010."

 

In context:

76543210
--------
10100000 : BUTTON-TOP
00000010 : DISC-RIGHT
10000010 : KEY-4
00100010 : KEY-6

 

It seems to me correct for a diagnosis tool to reflect the actual reality of the input signal, without clouding it with judgment or any further interpretation.

 

Obviously, a game program should take care to disambiguate between the various input types (as you say, the hand-controller is designed for either DISC+BUTTON or KEYPAD, but not both at once), but the diagnostic tool just tells you the reality of the active signal without decoding it -- and the reality is that "10100010" fits all four control elements.

I think that as long as you are getting the expected code exactly (and it seems you are), then the device is working correctly.

 

    dZ.

Edited September 14, 2022 by DZ-Jay

[+wavemotion]

Thanks so much dZ!  Yeah... I got my lefts/rights mixed up - a holdover from when I was five years old

 

Ok... so it's up to the program to disambiguate - that makes sense. 

 

One of the reasons I was slightly concerned is that in a game like Astrosmash, when I move left/right and rapidly press the top FIRE button, I do see the ship momentarily stop for the briefest of time.

 

I have two Dual-Action controller types available...

 

Dual-Action A uses the Disc/Buttons from Controller 1 and Keypad from Controller 2.

Dual-Action B uses the Disc from Controller 1 and the Buttons/Keypad from Controller 2.

 

If I select Dual-Action B, the Astrosmash ship moving left/right never stops when I manually press the fire button.

 

The same behavior happens on Buzz Bombers.  But other games that use the disc and buttons together never stutter. Again, the stutter is almost imperceptible.. .which makes me think I'm doing something but I can't see it in my code nor do I see any issues when using various Diagnostics programs.

 

In any event - I greatly appreciate the insight here!

 

Dave

[+DZ-Jay]

53 minutes ago, llabnip said:

Thanks so much dZ!  Yeah... I got my lefts/rights mixed up - a holdover from when I was five years old

 

Ok... so it's up to the program to disambiguate - that makes sense. 

 

One of the reasons I was slightly concerned is that in a game like Astrosmash, when I move left/right and rapidly press the top FIRE button, I do see the ship momentarily stop for the briefest of time.

 

I have two Dual-Action controller types available...

 

Dual-Action A uses the Disc/Buttons from Controller 1 and Keypad from Controller 2.

Dual-Action B uses the Disc from Controller 1 and the Buttons/Keypad from Controller 2.

 

If I select Dual-Action B, the Astrosmash ship moving left/right never stops when I manually press the fire button.

 

The same behavior happens on Buzz Bombers.  But other games that use the disc and buttons together never stutter. Again, the stutter is almost imperceptible.. .which makes me think I'm doing something but I can't see it in my code nor do I see any issues when using various Diagnostics programs.

 

In any event - I greatly appreciate the insight here!

 

Dave

 

You are welcome. 😀

 

I know the behaviour you are talking about, and that's entirely up to the program.  Those specific cases could be caused by electrical noise or mechanical "bounce" in the signal between the transitions, which the game interprets as a bad signal to discard.  This could be more pronounced on one hand-controller, depending on use and condition -- and especially on the left one, since it's the typical "single player" controller.  Forty years of environmental conditions and human use would do that.

 

I've said many times in the past that decoding Intellivision hand-controller signals, for a smooth and intuitive experience, is not trivial.  May programmers take it for granted (or naïvely ignore it altogether), but it requires a bit of work and clever programming to get things right.

 

       -dZ.

[mr_me]

1 hour ago, llabnip said:

Thanks so much dZ!  Yeah... I got my lefts/rights mixed up - a holdover from when I was five years old

 

Ok... so it's up to the program to disambiguate - that makes sense. 

 

One of the reasons I was slightly concerned is that in a game like Astrosmash, when I move left/right and rapidly press the top FIRE button, I do see the ship momentarily stop for the briefest of time.

 

I have two Dual-Action controller types available...

 

Dual-Action A uses the Disc/Buttons from Controller 1 and Keypad from Controller 2.

Dual-Action B uses the Disc from Controller 1 and the Buttons/Keypad from Controller 2.

 

If I select Dual-Action B, the Astrosmash ship moving left/right never stops when I manually press the fire button.

 

The same behavior happens on Buzz Bombers.  But other games that use the disc and buttons together never stutter. Again, the stutter is almost imperceptible.. .which makes me think I'm doing something but I can't see it in my code nor do I see any issues when using various Diagnostics programs.

 

In any event - I greatly appreciate the insight here!

 

Dave

By separating the disc and side action buttons to two different controller ports, you eliminate the chance of an incomplete action button press, while pressing the disc, being misinterpreted as a keypad press.  It explains why your dual action B controller never experiences that glitch. 

 

But that glitch should only happen with physical Intellivision controllers, it shouldn't happen with emulated controllers.

Edited September 14, 2022 by mr_me

[+wavemotion]

14 minutes ago, mr_me said:

But that glitch should only happen with physical Intellivision controllers, it shouldn't happen with emulated controllers.

So... if one is emulating the controllers accurately (meaning the emulator is setting the proper input bits to the program), why wouldn't these glitches happen?

Don't get me wrong - I'm assuming that I'm doing something not quite right here... but the inputs to the CPU look right.  I can avoid the minor (and it's a very minor - just the briefest of movement glitches on Astrosmash and Buzz Bombers - as if the ship got snagged on the carpet and pulled loose immediately) issue by separating the inputs... but the default is to use the Player 1 Controller as a standard controller. 

I'll keep digging in my code to see if I can uncover some other explanation for the Player 1 Controller issue I'm seeing.

[mr_me]

Jzintv can receive either port bits or specific buttons actions as input.  Either way, with a modern controller, the side button physical input starts as single switch that is interpreted as two bits by emulation software.  There shouldn't be any chance that only one bit is input as can happen with a physical intellivision controller.  If the glitch still happens the only explanation is in the Intellivision exec/game software not the emulator.

[+DZ-Jay]

59 minutes ago, llabnip said:

So... if one is emulating the controllers accurately (meaning the emulator is setting the proper input bits to the program), why wouldn't these glitches happen?

Because you are emulating the correct signal, and not the mechanical and electrical noise inherent in an physical switch.

 

    dZ.

[+wavemotion]

Thanks guys... I think we're talking about 2 different glitches

 

I was mainly referring to the small stutter that the ship undergoes in Astrosmash when moving and firing manually (same in Buzz Bombers).

 

So at lunch I got out my Intellivision and found a TV I could still hook it up to... and sure enough the same stutter appears in the real game with real controllers.

 

The emulation here is correct. And I don't have a real Dual-Action type controller to test but in emulation the disc on Controller 1 and the buttons on Controller 2 make the ship movement/fire buttery smooth.

 

 

[mr_me]

It's two different causes to the same symptom.  I've seen the same thing happen with Space Hawk in emulation.  It shouldn't happen but it does.  I suspect something in the exec code but it could be something else.  Interesting that by cross mapping the two controllers the problem goes away in emulation.  I'll have to try that.  If you don't cross map the controllers does the same glitch happen similarly with either controller (that's in emulation).

Edited September 14, 2022 by mr_me

[+DZ-Jay]

What is the glitch, specifically?  Is it that when you hit a direction and an action button repeatedly at the same time, the player ship stops moving?

 

   dZ.

[+wavemotion]

Yes, the issue is that if you hold left/right to move the ship across the screen and then press any fire button, the ship pauses for the briefest of moments. If you repeatedly press fire, the ship will stutter across the screen as it moves.

 

It behaves the same if you use Controller 1 or Controller 2.

 

If you cross the controllers (disc for 1 and fire buttons for 2 or the reverse) the ship moves buttery-smooth with no stutter and no stopping.

 

This appears to happen in emulation - I was only able to test Controller 1 and Controller 2 on a real system and both have the same jerky movement if you're pressing FIRE while moving.

[+DZ-Jay]

2 hours ago, llabnip said:

Yes, the issue is that if you hold left/right to move the ship across the screen and then press any fire button, the ship pauses for the briefest of moments. If you repeatedly press fire, the ship will stutter across the screen as it moves.

I see.  That could be an idiosyncrasy of the program input decoder.  I wonder if the programmer did not account for both action buttons and disc being pressed simultaneously and is expecting instead one or the other.

 

2 hours ago, llabnip said:

It behaves the same if you use Controller 1 or Controller 2.

 

If you cross the controllers (disc for 1 and fire buttons for 2 or the reverse) the ship moves buttery-smooth with no stutter and no stopping.

 

This appears to happen in emulation - I was only able to test Controller 1 and Controller 2 on a real system and both have the same jerky movement if you're pressing FIRE while moving.

Yes, it seems to be a program logic quirk, not a hardware problem.

 

One more question:  When you press the disc and leave it pressed, and then you press the action button to fire, does the ship stop moving briefly and resume while you are still pressing both?  Or is it only brief because you press and release the action button quickly?

 

    dZ.

Edited September 15, 2022 by DZ-Jay

[mr_me]

You can see this happen with the Mattel sports cartridges, e.g. MLB, NBA, NASL, although you're not expected to repeatedly press side buttons in these games.  Tennis is an exception where the programmer worked it out so you can run and swing without interruption.  You'll also see that cartridges from Atari and Activision don't have this behaviour.  They also wouldn't have used the Exec routines.

 

Pressing and holding the side action button will only stop the player momentarily.  The player continues uninterrupted while holding the button.

 

And Ilabnip is right, that this behaviour is different than the unintended keypad press I was thinking of.

Edited September 15, 2022 by mr_me

[+DZ-Jay]

7 hours ago, mr_me said:

You can see this happen with the Mattel sports cartridges, e.g. MLB, NBA, NASL, although you're not expected to repeatedly press side buttons in these games.  Tennis is an exception where the programmer worked it out so you can run and swing without interruption.  You'll also see that cartridges from Atari and Activision don't have this behaviour.  They also wouldn't have used the Exec routines.

 

Pressing and holding the side action button will only stop the player momentarily.  The player continues uninterrupted while holding the button.

 

And Ilabnip is right, that this behaviour is different than the unintended keypad press I was thinking of.

Thanks for the description.  I can imagine some scenario in which a debouncing logic would attempt to ignore an immediate transition from, say, "00000010" (DISC-LEFT) to "10100010" (DISC-LEFT + BUTTON-TOP) as potential noise -- but rather than discarding the input temporarily, treating it instead as entirely invalid; consequently causing the previously accepted disc input to be thrown away as well.  This, compounded with the EXEC's 20Hz sampling rate, would then result in a brief stuttering, before the input is accepted as valid again.

 

It's just a theory, and perhaps not a very good one; but it could explain the behaviour.

 

The fact that this behaviour exists in the early Mattel sports games (including MLB which was programmed by David Rolfe himself), suggests to me that it may be the default behaviour built into the EXEC.

 

That Atari and Activision games behave similarly makes this suspect, but it could be mere coincidence, based on some perhaps well known pattern in the industry related to the electronic processing of mechanical switches. *shrug*

 

Then again, it could be that Atari and Activision reversed engineered (or gain access to reverse-engineered resources thereof) the EXEC, and employed only some parts of it rather than the entire framework.

In any case, it is an interesting question (at least to me), and offers an example of early patterns of behaviour and game mechanics from which we can learn.

 

     dZ.

Edited September 15, 2022 by DZ-Jay

[+wavemotion]

2 hours ago, DZ-Jay said:

That Atari and Activision games behave similarly makes this suspect, but it could be mere coincidence, based on some perhaps well known pattern in the industry related to the electronic processing of mechanical switches. *shrug*

 

Then again, it could be that Atari and Activision reversed engineered (or gain access to reverse-engineered resources thereof) the EXEC, and employed only some parts of it rather than the entire framework.

I think what mr_me was saying is that Atari and Activision games don't exhibit this behavior.

Imagic's Demon Attack, however, has the problem. If you fire manually while moving, the ship will pause briefly and then resume moving (even if holding the fire button down).  What sucks is that Demon Attack will not use the Player 2 controller so I can't play the emulation "Dual Action B" (player 1 disc, player 2 buttons) trick to make it work smoothly.

 

[+DZ-Jay]

1 hour ago, llabnip said:

I think what mr_me was saying is that Atari and Activision games don't exhibit this behavior.

 

 

Ah, sorry, I misunderstood.  Then it makes more sense, and adds additional weight to the theory that it is an EXEC quirk.

 

1 hour ago, llabnip said:

Imagic's Demon Attack, however, has the problem. If you fire manually while moving, the ship will pause briefly and then resume moving (even if holding the fire button down).  What sucks is that Demon Attack will not use the Player 2 controller so I can't play the emulation "Dual Action B" (player 1 disc, player 2 buttons) trick to make it work smoothly.

 

It would make sense that Imagic games interact with the EXEC, since it included Intellivision programmers amongst its ranks, and they were known for reverse-engineering the platform in order to work around any potential liability or conflict.

 

    dZ.

Edited September 15, 2022 by DZ-Jay

[mr_me]

To be legal the reverse engineering was done by people without official Intellivision experience.  I think the third party publishers used the reverse engineering work of the same independent consultant.  The Intellivision group at Atari were also ex-Mattel programmers and were sued by Mattel.  Some Activision cartridges were programmed by some of the most experienced Intellivision programmers at the time.  They knew the exec better than anybody but bypassed it for higher performance.  Even some Mattel programmers started to bypass the exec to get 60fps i.e. Masters of the Universe.