Jump to content
IGNORED

Why Does Rob Fulop Hate The Intellivision?


SpicedUp!

Recommended Posts

Was just reading the interview with Rob Fulop (who wrote Demon Attack on the Atari 2600) in the latest issue of Retro Gamer magazine (I think it was the latest issue) and he said he hated the Intellivision and the Intellivision version of Demon Attack!

 

I don't really understand fully what he meant. But he said that on the Atari 2600 you can move objects (sprites) fractions of pixels and that you couldn't do this on Intellivision. And this was why the demons didn't move as nicely on the Intellivision version (which he didn't write himself). He also said it was stupid to turn the Intellivision game into a clone of Phoenix (with the extra mothership level) but that's a different story

 

I originally assumed he meant he was using a floating point system - so objects appear to move smoother even if they still just move on pixel boundaries. Surely the Intellivision could do this?? Or can the Atari really move sprites fractions of pixels???

 

 

Edited by SpicedUp!
  • Like 1
Link to comment
Share on other sites

He might be referring to a limitation of the Exec framework in the Intellivision firmware.  Someone more knowledgeable on the Exec can comment, but I think the Exec has some sprite move routines to offload this work from the cartridge and the programmer.  The programmer isn't required to use any Exec routine or the framework at all. 

 

Games that use the Exec also suffer from lower frame rates.  It's not so much of an issue with most sports games but is with some high speed action games.  Intellivision cartridges that don't use the Exec framework do show high framerates and smoother character movement.

 

I do understand what he's saying about Intellivision Demon Attack and sprite movement, but I think it has more to do with programming than limitations of the hardware.

Edited by mr_me
  • Like 1
Link to comment
Share on other sites

26 minutes ago, mr_me said:

He might be referring to a limitation of the Exec framework in the Intellivision firmware.  Someone more knowledgeable on the Exec can comment, but I think the Exec has some sprite move routines to offload this work from the cartridge and the programmer.  The programmer isn't required to use any Exec routine or the framework at all. 

 

Games that use the Exec also suffer from lower frame rates.  It's not so much of an issue with most sports games but is with some high speed action games.  Intellivision cartridges that don't use the Exec framework do show high framerates and smoother character movement.

 

I do understand what he's saying about Intellivision Demon Attack and sprite movement, but I think it has more to do with programming than limitations of the hardware.


I agree.  From my recollections of the documentation, the EXEC has autonomous object movement, where you give it velocity vectors or a target position, and it will move the sprites automatically.  It also has an option to adjust the trajectory periodically, to ensure accurate targeting.

 

I am not sure if this included sub-pixel movement, but I would be surprised if it didn't, because the system is actually quite sophisticated in many regards.  It also took angles and converted them into vectors, and vice versa, and unless movement was constrained to some narrow set of angles, I can't see how you would move a sprite semi-diagonally in whole pixel increments.  Yet, games attest that you could, and have ballistic trajectories, etc., as well.

 

Of course, sub-pixel movement does not really mean moving an actual fraction of a pixel, but moving across pixels at irregular rates, or at rates which are not a wholly divisible by the display frame rate.


In any case, as @mr_me said, even if the EXEC did not support this, it is still not a limitation of the hardware.  Programmers were encouraged to use the EXEC to conserve cartridge space and reduce programming time, but were not required to do so.


So it was a rather odd comment to make, perhaps coloured by the programmer's own biases against the platform.

 

    dZ.

Edited by DZ-Jay
  • Like 1
Link to comment
Share on other sites

I was just looking at the Exec documentation, and the .objmot variable that defines sprite velocity is as precise as 1/32nd of a pixel per tick.  So while the sprite movement routine is actually pretty sophisticated, overall the Exec still suffers from a low framerate.  Rob Fulop was still misinformed on (or misunderstood) the system limitations.

Edited by mr_me
Link to comment
Share on other sites

2 hours ago, mr_me said:

I was just looking at the Exec documentation, and the .objmot variable that defines sprite velocity is as precise as 1/32nd of a pixel per tick.

 

That still sounds like sub-pixel movement.

 

2 hours ago, mr_me said:

So while the sprite movement routine is actually pretty sophisticated, overall the Exec still suffers from a low framerate.

 

Although that is true (and a drawback in many regards), it's completely irrelevant to the point of sub-pixel motion on the Intellivision.

 

2 hours ago, mr_me said:

Rob Fulop was still misinformed on (or misunderstood) the system limitations.

 

Agreed.

 

     -dZ.

  • Like 1
Link to comment
Share on other sites

25 minutes ago, DZ-Jay said:

That still sounds like sub-pixel movement.

It is sub pixel movement, or "fractional pixels" as Rob Fulop describes it.  Using his example of moving three pixels in two frames would be the decimal value 48 in the Exec .objmot variable.  And three pixels in four frames would be decimal 24 using the Intellivision Exec.

 

I wondered if the Imagic programmers were using the Exec to move sprites.  They feel more like Mattel games compared to the Intellivision cartridges from Atari and Activision that did not use the Exec.

Link to comment
Share on other sites

The EXEC handles sprite positioning as 8.8 floating point.  That's 1/256th of a pixel on both axes.

 

The reason for the lower frame rate is because the EXEC was designed to do everything in three-frame cycles by default, so you're capped at 20 FPS on NTSC.  But one of the 8-bit variables defines how many frames between cycles.  That's how you get the slower speeds when pressing 1, 2, or 3 on title screens for early games.

  • Like 1
Link to comment
Share on other sites

What frame rate do you think Intellivision Demon Attack runs.  Here's an interview with the programmer.  The guy asking the questions thinks the control input is off.  I thought so too.  It's usually a symptom of Exec frame rate and high speed games.

https://www.classic-consoles-center.at/interviews/interview-with-gary-kato

Link to comment
Share on other sites

14 hours ago, mr_me said:

What frame rate do you think Intellivision Demon Attack runs.  Here's an interview with the programmer.  The guy asking the questions thinks the control input is off.  I thought so too.  It's usually a symptom of Exec frame rate and high speed games.

https://www.classic-consoles-center.at/interviews/interview-with-gary-kato


Personally, that has always been my gripe about the early Mattel titles which use the EXEC -- not only do they run at 20Hz, but the input is sampled at 20Hz (or slower!) as well.

 

I do not think it is necessarily an EXEC problem.  My understanding from the documentation is that the input is sampled and decoded on every tick.  Perhaps the event handlers are triggered once per game cycle (at 20Hz), but I believe that the decoded record is available for direct access at any time.
 

I think this is why some EXEC games feel more responsive than others, especially the later ones.  I sort of recall reading somewhere that programmers started reading the decoded input or raw input record directly from their program routines, rather than waiting for the events to trigger.

 

Someone with more intimate knowledge of the EXEC should correct me, I am just speculating.

 

    dZ.

Edited by DZ-Jay
Link to comment
Share on other sites

Here is an example of what I mean.  In an event-driven model, like the EXEC or my P-Machinery framework, the engine triggers routines in your program to handle various events that occur throughout the game, such as controller input changes.

 

When the user presses the disc, a handler routine for the "disc-press" event is called, and your program then can use it to, say, change the player's direction variable.  As the rest of the program continues, it reads this variable to move the player's sprite, and so when the variable changes, the sprite moves in a new direction.

 

The latency between the time the input was read and when the event was handled, determines the responsiveness experienced by the player.

 

In such a scenario, it does not matter if the engine decodes the controller on every tick; if the events are still triggered every third tick (20Hz), the program will react at that rate.

 

Moreover, depending on the order of processing events, the program may react on its next engine cycle, delaying the player's view of that reaction by another 3 ticks!  Your response rate has just decreased from 20Hz to 10 Hz, adding to player frustration.

 

On the other hand, if your game forgoes using the provided event-model for handling input events, and instead reads the decoded input values directly when it needs it; you remove the latency in the event-handler dispatch from the equation.

 

In this second scenario, when your program needs to move the player's ship, instead of reading a variable populated with the decoded value, you read the EXEC's decoded value directly -- or even better, read the hand-controller directly and avoid any indirection -- then your program will react as fast as the engine runs.

 

You have cut the reaction time experienced by the player from 6 ticks (10Hz) to 3 ticks (20Hz).  Still not "real-time," but undoubtedly an improvement.  My understanding from the documentation is that is is not a "hack" -- the EXEC offers both ways to handle input, and it is up to the programmer to decide which one to employ.

 

Anyway, that is my theory of why most Mattel EXEC games feel a bit sluggish, and why some (particularly the earlier ones) feel more so than others.

 

Eventually Mattel and third-party developers bypassed the EXEC completely (or, built a replacement with a much faster engine cycle, like they did at Intv Corp.), thus improving response time to near "real-time."  This is definitely the case for most home-brews, especially those of the first and second generation written entirely in Assembly Language.

 

(My own framework, used in my game Christmas Carol, polls the hand-controller in as close to real-time as possible, even during the engine idle cycle between ticks. It then triggers high-priority events closely thereafter, so the player's sprite direction is constantly reflecting the most recent input signal from the hand-controller.)

 

    dZ.

Edited by DZ-Jay
  • Like 2
Link to comment
Share on other sites

This thread is very interesting, thanks @SpicedUp! for highlighting Retrogamer's interview with Rob. 

 

Perhaps the EXEC discussion is a bit of a poisson rouge?  I don't think that Demon Attack uses the EXEC as a game framework.  Sure there are some calls in the code to the likes of X_PRINT_R5 and X_FILL_ZERO, however, the game code starts at address $4800, so it doesn't use the EXEC's standard bootstrap block at $5000, and I don't think its start up hands back to the EXEC.  Certainly, it installs its own ISR handler by reprogramming the ISR vector at $100-$101.

 

Demon Attack does seem to rely on some EXEC code to read the controller (reads from $1fe & $1ff seem to originate from $14f* and $152*). but the STIC largely seems to be programmed by Imagic code in the $49** and $4b** range.  In fact looking at the timing in JzIntv it seems to me that the state of all MOBs are refreshed at 60Hz (and certainly Inty Demon Attack looks to be way more fluid than a 20Hz EXEC game).

 

So I'm going to say that Rob's comments in Retrogamer are just plain wrong.  Non-integer pixel movement is a software feature, and is possible on the Inty.  As has been mentioned above, the EXEC does support this feature, as described on page 4-4 of YFTE:

image.thumb.png.28bc263d583f4489848ca6935db7480a.png

 

It looks to me as though Demon Attack does not use the EXEC as anything other than a library of useful utility functions anyway.  So, if there are any shortcomings in regard to MOB motion it's down to Imagic's framework, or the code in Demon Attack itself.  Now, according to the BSR's, Demon Attack was programmed by Gary Kato, something that is confirmed in this interview with Gary:

 

https://www.classic-consoles-center.at/interviews/interview-with-gary-kato

 

Gary says that he wrote his own mini-EXEC prior to Imagic getting a full reverse engineering report on the Mattel EXEC (he also wrote Imagic's CP-1610 cross-assembler).  This was used in Demon Attack and perhaps Atlantis.  This is something that corroborated by the code comparison analysis - see the third image in this posting:

 

 

 

So, if Rob has any complaints regarding MOB motion, I think he needs to take them up with his colleague Gary! ;)

 

Having said all this, I recognise that the Inty is far from perfect, and I can understand that someone used to the kind of flexibility and control that the VCS allows might not really being comfortable with the constraints imposed by the Intellivision.  It's just that this particular beef is not justified. 

 

Finally, to be fair to Rob, this is all a long time ago now, and it's possible he's just misremembering things after 40 years - I know I am!

Edited by decle
  • Like 4
Link to comment
Share on other sites

3 minutes ago, decle said:

This thread is very interesting, however, perhaps the EXEC discussion is a bit of a poisson rouge?  I don't think that Demon Attack uses the EXEC as a game framework.  Sure there are some calls in the code to the likes of X_PRINT_R5 and X_FILL_ZERO, however, the game code starts at address $4800, so it doesn't use the EXEC's standard bootstrap block at $5000, and I don't think its start up hands back to the EXEC.  Certainly, it installs its own ISR handler by reprogramming the ISR vector at $100-$101.

 

Demon Attack does seem to rely on some EXEC code to read the controller (reads from $1fe & $1ff seem to originate from $14f* and $152*). but the STIC largely seems to be programmed by Imagic code in the $49** and $4b** range.  In fact looking at the timing in JzIntv is seems to me that the state of all MOBs are refreshed at 60Hz (and certainly Inty Demon Attack looks to be way more fluid than a 20Hz EXEC game).

 

So I'm going to say that Rob's' comments in Retrogamer are just plain wrong.  Non-integer pixel movement is a software feature, and is possible on the Inty.  As has been mentioned above, the EXEC does support this feature, as described on page 4-4 of YFTE:

image.thumb.png.28bc263d583f4489848ca6935db7480a.png

 

It looks to me as though Demon Attack does not use the EXEC as anything other than a library of useful utility functions anyway.  So if there are any shortcomings in regard to MOB motion it's down to Imagic's framework, or the code in Demon Attack itself.  Now, according to the BSR's Demon Attack was programmed by Gary Kato, something that is confirmed in this interview with Gary:

 

https://www.classic-consoles-center.at/interviews/interview-with-gary-kato

 

Gary says that he wrote his own mini-EXEC prior to Imagic getting a full reverse engineering report on the Mattel EXEC (he also wrote Imagic's CP-1610 cross-assembler).  This was used in Demon Attack and perhaps Atlantis.  This is something that corroborated by the code comparison analysis - see the third image in this posting:

 

 

 

So, if Rob has any complaints, I think he needs to take them up with Gary! ;)

 

Having said all this, the Inty is far from perfect, and I can understand that someone used to the kind of control that the VCS allows might not really being comfortable with the constraints imposed by the Intellivision.  It's just that this particular beef is not justified. 

 

Finally, to be fair to Rob, this is all a long time ago now, and it's likely he's just misremembering things after 40 years!

 

Thank you for the thorough explanation.  I agree 100% with you.  I guess that in my own round-about way I was trying to get to the same point:  the problems of sluggishness with the controls are down to software implementation (my own personal bugbear on most Intellivision games, including many home-brews).

 

I also was trying to point out that for early EXEC games, although there are some limitations and constraints built-into the framework, most of the problems with responsiveness are not inherent to the EXEC, but self-inflicted by the programmer due to various compromises -- many or most of them valid and justified:  When you only have 4K of cartridge space for game logic, graphics, music, and everything, off-boarding most of your routines to the built-in ROM is a very wise decision; so you end up designing your game processes in terms of the EXEC rather than the other way around.

 

However, the EXEC does not force you to do that -- your development manager may, though, in order to shorten development time and minimize expensive cartridge space.

 

The reason I went through some lengths in trying to explain how programmer decisions have an effect on user experience -- even though it may not be very relevant to this specific discussion -- is that people tend to blame the Intellivision hand-controller itself for these problems (more so than the EXEC, especially laymen users); which is not only misplaced, but propagates the perception that the Intellivision "sucked" because of those "darn weird controllers."  I believe there are some games -- both classic and home-brews -- with some very clever programming that have proven this notion wrong.

 

    -dZ.

 

 

  • Like 2
Link to comment
Share on other sites

Thanks for all the replies and information here. I had no idea you could actually circumvent the EXEC! Not sure why I've heard people complain about it so much if you have the option not to use it.

 

So it sounds like even with the Exec sub-pixel movement is possible because you can just update the movement values as you want. It's a bit of a strange thing for Rob Fulop to say then. The guy explaining it to him must have done a bad job.

  • Like 1
Link to comment
Share on other sites

On 9/25/2022 at 12:18 PM, SpicedUp! said:

Thanks for all the replies and information here. I had no idea you could actually circumvent the EXEC!

 

That’s how home-brews are made:  general knowledge and experience of working with the EXEC was lost with the last Intv Corp. titles, so the home-brew scene basically started from scratch.

 

On 9/25/2022 at 12:18 PM, SpicedUp! said:

Not sure why I've heard people complain about it so much if you have the option not to use it.


Well, The early Mattel guys sort of had to:  It was the best way to make games with complex mechanics and sophisticated logic fit in 4K.

 

The EXEC took care of a lot of things, and in most cases did it superbly.  It allowed you to lower the cost of development, developer training, and testing — since code that is already there is code you do not have to design, write, nor test.

 

The cost of that power and sophistication was to mold your game to the capabilities, processing model, and limitations of the EXEC.

 

Still, moment programmers gained more experience and cartridge space became more accessible, they dropped it like an old hat.

 

On 9/25/2022 at 12:18 PM, SpicedUp! said:

So it sounds like even with the Exec sub-pixel movement is possible because you can just update the movement values as you want. It's a bit of a strange thing for Rob Fulop to say then. The guy explaining it to him must have done a bad job.

 

 

Indeed!

 

 

    dZ.

Edited by DZ-Jay
  • Like 4
Link to comment
Share on other sites

Back in the late 1990s, Intellivision Productions was selling an Intellivision development kit for PC.  It never happened but they did send people copies of "Your Friend the Exec", the official documentation provided to Mattel programmers.  So it's been out there for a while, but as some of the original programmers realised, you can get better performance bypassing it.  Worm Whomper, for example, is a simple game but it runs at 60fps and is only a 4k cartridge.  The author of the Exec even wrote in the documentation, "It has the disadvantage that certain classes of things are hard to do, if not impossible.  Provisions exist for defeating all or parts of the EXEC if the user finds it unsuitable for his application."

 

In an interview with Mattel and INTV programmer David Warhol, it was asked why Mattel programmers stuck with the Exec, and he said something to the effect of you'd be foolish not to use it.  That's understandable.  I'm only aware of one Mattel programmed cartridge that runs at 60fps, and that's Masters of the Universe.  There were some all new cartridges programmed at INTV in the late 1980s, do Body Slam, SMB, or Deep Pockets run under the Exec?.

 

 

-------------------

I think my issue with Intellivision Demon Attack control has to do with how fast the player moves.  it results in imprecise positioning as tapping the direction control in the Intellivision version, the player might jump four, six, eight, and sometimes up to 12 pixels, and very rarely two pixels.  While with Atari 2600 Demon Attack, the player might jump two, three, or four pixels, and rarely one single pixel.  With some crude timing, I figured the player moves at a speed of about one pixel per frame in the Atari version and two pixels per frame with the Intellivision version (assuming 60 fps).  If the player speed matched the Atari version, I think Intellivision Demon Attack would feel more precise.  And if it ran at 20fps it would be much worse.

 

 

  • Like 2
Link to comment
Share on other sites

On 9/25/2022 at 6:12 PM, DZ-Jay said:

 

That’s how home-brews are made:  knowledge and experience of working with the EXEC was lost with the last Intv Corp. titles, so the home-brew scene basically started from scratch.

 


Well, The early Mattel guys sort of had to:  It was the best way to make games with complex mechanics and sophisticated logic fit in 4K.

 

The EXEC took care of a lot of things, and in most cases did it in superbly.  It allowed you to cost the cost of development, developer training, and testing — since code that is already there is code you do not have to design, write, nor test.

 

The cost of that power and sophistication was to mold your game to the capabilities, processing model, and limitations of the EXEC.

 

Still, moment programmers gained more experience and cartridge space became more accessible, they dropped it like an old hat.

 

 

 

Indeed!

 

 

    dZ.

Ok thank you, that makes sense about the 4K cartridge size especially. 

 

Othwerise EXEC reminds me of AMOS back when I had an Amiga :) You used to groan when you loaded up a game and it used that AMOS font or had that orangey screen at the start. You knew the game wouldn't be as slick as if someone had written in assembly to start with. (AMOS could be compiled to machine code)

Edited by SpicedUp!
  • Like 1
Link to comment
Share on other sites

On 9/25/2022 at 3:50 PM, mr_me said:

Back in the late 1990s, Intellivision Productions was selling an Intellivision development kit for PC.  It never happened but they did send people copies of "Your Friend the Exec", the official documentation provided to Mattel programmers.  So it's been out there for a while, but as some of the original programmers realised, you can get better performance bypassing it.  Worm Whomper, for example, is a simple game but it runs at 60fps and is only a 4k cartridge.  The author of the Exec even wrote in the documentation, "It has the disadvantage that certain classes of things are hard to do, if not impossible.  Provisions exist for defeating all or parts of the EXEC if the user finds it unsuitable for his application."


 

 

The documentation wasn't in general distribution early on, and it is not much helpful for someone coming in cold into the platform.  There was no guidance on how to make games with the EXEC, no tutorial or sample source code.  The document out in the wild does not include the symbol table, nor the macro definitions discussed in it.

 

At least when I joined the scene (back in 2006 or so), internal knowledge of the EXEC wasn't something being passed around, and I had no access to any of it.  Some had a notion of "we should not use or share proprietary IP, lest we incur the wrath of Intellivision Productions"; but in any case, it wasn't much of an option to go the EXEC route unless you wanted to reverse engineer it yourself (like some did).

 

Sure, you can get better performance by bypassing the EXEC, but I bet you anything that most early newcomers like me would have loved to be able to get something done quickly, with fast turn around using a pre-fab framework that was documented and well-trodden.  Doubly so if it was something used by BSRs back in the day.

 

As it turned out, we had to fly by the seat of our pants, and figure out on our own even the most basic stuff: how much RAM should I reserve for the stack?  Which parts should be handled in an ISR?  How do I program a sound effect on the PSG?  How can I detect a keypad key?  How do I print the score on the screen from a numeric variable?  How do I allocate memory for my variables? Etc., etc., etc.

 

(I did get great help from others, but having gone through the ring of fire themselves, that's the path they offered.)

 

On 9/25/2022 at 3:50 PM, mr_me said:

In an interview with Mattel and INTV programmer David Warhol, it was asked why Mattel programmers stuck with the Exec, and he said something to the effect of you'd be foolish not to use it.  That's understandable.


That's my point above, from a home-brewer's perspective.  I did not set out to be some "macho-cowboy-coder" to program at the "bare metal."  IntyBASIC did not exist, and I had no access to anything else.  (The SDK-1600 was too low-level, terse, and hardcore for a simpleton programmer wannabe like me.)  Had I had access, guidance, and support for using the EXEC I would had jumped at the chance.

 

(As it turned out, I did get lots of guidance, support, and hand-holding for using the SDK-1600, so that's the road I took.  But I reiterate that it was the only option available.)

 

In retrospect, what I learned the hard way was very valuable, and I do not regret it one bit.  And the help I received was invaluable.  Plus I have my own framework now, such as it is, so there is that.

 

However, I wouldn't recommend that as the way to gain entry into the exciting world of Intellivision programming. *shrug*


The road to home-brew nirvana is paved with the dead bones of myriad first-time projects left unfinished.

 

On 9/25/2022 at 3:50 PM, mr_me said:

I'm only aware of one Mattel programmed cartridge that runs at 60fps, and that's Masters of the Universe.  There were some all new cartridges programmed at INTV in the late 1980s, do Body Slam, SMB, or Deep Pockets run under the Exec?.

 

I met David Warhol at CGE-2012 when I released Christmas Carol.  He is a very nice man, and we talked a little about things back then.  (I was mostly starstruck at the time, so I just nodded and listened).  He told me that at INTV Corp. they had a 60hz version of the EXEC.  I believe he said he wrote it.  We didn't go into much detail, but I took this to mean that they bypassed the one in ROM in favour of a custom framework linked into the game program itself -- perhaps even the original source modified.

 

(Was Worm Whomper a Mattel title?  I thought that one ran at 60Hz too.)

 

On 9/25/2022 at 3:50 PM, mr_me said:

I think my issue with Intellivision Demon Attack control has to do with how fast the player moves.  it results in imprecise positioning as tapping the direction control in the Intellivision version, the player might jump four, six, eight, and sometimes up to 12 pixels, and very rarely two pixels.

 

I completely agree.  I suppose that's caused by the low resolution of input handling in the game code.

 

On 9/25/2022 at 3:50 PM, mr_me said:

While with Atari 2600 Demon Attack, the player might jump two, three, or four pixels, and rarely one single pixel.  With some crude timing, I figured the player moves at a speed of about one pixel per frame in the Atari version and two pixels per frame with the Intellivision version (assuming 60 fps).  If the player speed matched the Atari version, I think Intellivision Demon Attack would feel more precise.  And if it ran at 20fps it would be much worse.


Good points.

 

    dZ.
 

Edited by DZ-Jay
  • Like 1
Link to comment
Share on other sites

Yes, in an interview, David Warhol did talk about his 60hz Exec he created for INTV Corp.  He also created a cross assembler for PC, and a colleague made the ISA based RAM cartridges.  So the INTV cartridges not based on a Mattel game could use his 60hz framework.  An updated Exec was probably something that should have been done at Mattel, and by 1983 they were working on an updated console, hardware and software, which was cancelled, and then layoffs.  Worm Whomper was from Activision.

 

 

That's right about exec symbols and macro definition files, you'd probably need a compatible cross assembler as well.  I don't think those ASM files have ever been shared.  And I agree, you'd have needed permission to use that stuff from Intellivision Productions, I wonder what they would have said at the time.

 

 

 

Link to comment
Share on other sites

1 hour ago, mr_me said:

Yes, in an interview, David Warhol did talk about his 60hz Exec he created for INTV Corp.  He also created a cross assembler for PC, and a colleague made the ISA based RAM cartridges.  So the INTV cartridges not based on a Mattel game could use his 60hz framework.  An updated Exec was probably something that should have been done at Mattel, and by 1983 they were working on an updated console, hardware and software, which was cancelled, and then layoffs.

 

Yeah, I think they should have updated the EXEC for the Intellivision II.

 

1 hour ago, mr_me said:

Worm Whomper was from Activision.

 

OMG!  I knew that!  Sorry.  :dunce:

 

1 hour ago, mr_me said:

That's right about exec symbols and macro definition files, you'd probably need a compatible cross assembler as well.  I don't think those ASM files have ever been shared.  And I agree, you'd have needed permission to use that stuff from Intellivision Productions, I wonder what they would have said at the time.

 

I do not even know if anybody asked Keith for those files.

 

   -dZ.

Link to comment
Share on other sites

  • 2 months later...
On 9/21/2022 at 4:13 PM, DZ-Jay said:

Programmers were encouraged to use the EXEC to conserve cartridge space and reduce programming time, but were not required to do so.

Bingo! Furthermore, it wasn't an all-or-nothing situation: programmers could use pieces of the EXEC. For example, if your program didn't move and sequence all eight of the objects you could modify the EXEC's high-level code to adapt it to run in two or one frame cycles instead of three. Easy Peasy. But, as you point out, you'd have to include the modified portions in your **4K** cartridge. You could beg the suits for the extra ROM needed to accommodate that, but they weren't going to give it to you before late 1982.

 

On 9/21/2022 at 3:49 PM, mr_me said:

Games that use the Exec also suffer from lower frame rates.

The EXEC gets a bit of a bum rap for that. A lot of its perceived sluggishness is more due to its debouncing of hand-controller input than to the display update rate. The hand controllers make multiple contacts for each state, which contacts aren't guaranteed to be simultaneous. The EXEC's controller input routines had to be robust, but it was easy for programmers to make their games more responsive by installing a controller driver that didn't debounce. In doing so they risked putting black holes into their programs because of misinterpreted controller state. It took a few years for programmers to discover that this deficiency could be easily dealt with in the instruction booklet. Here's how it was dealt with in Space Hawk: "Every once in a while, your space hunter will move near a 'black hole,' and the computer will automatically put him into HYPERSPACE. This will cost you the same number of points as if you had pressed the HYPERSPACE key yourself. On the other hand, it will save your hunter."

  • Like 2
Link to comment
Share on other sites

4 hours ago, Walter Ives said:

The EXEC gets a bit of a bum rap for that. A lot of its perceived sluggishness is more due to its debouncing of hand-controller input than to the display update rate.

 

I wholeheartedly agree with this, and it has been something I have pointed out in the past -- but of course, it is good to know it authoritatively, so thank you for the insight.

 

Further proof is that most IntyBASIC games do not even try to process the game loop at 60Hz, and they are still quite snappy and effective, provided they handle controller input in a timely manner.

 

4 hours ago, Walter Ives said:

The hand controllers make multiple contacts for each state, which contacts aren't guaranteed to be simultaneous. The EXEC's controller input routines had to be robust, but it was easy for programmers to make their games more responsive by installing a controller driver that didn't debounce. In doing so they risked putting black holes into their programs because of misinterpreted controller state. It took a few years for programmers to discover that this deficiency could be easily dealt with in the instruction booklet. Here's how it was dealt with in Space Hawk: "Every once in a while, your space hunter will move near a 'black hole,' and the computer will automatically put him into HYPERSPACE. This will cost you the same number of points as if you had pressed the HYPERSPACE key yourself. On the other hand, it will save your hunter."

 

Moreover, in practice, it turns out that debouncing or signal conditioning sometimes occurs organically as other game-play mechanics may conspire to limit the possible states accepted at any point in time.

 

For example, in my own game, we debounce the input during phases when input accuracy is more important than processing speed -- e.g., menu option selections, etc. -- but do not debounce the disc during the time-critical phases, namely, during active play.  The reason for this is that it turns out that, while we poll the hand-controller at close to real-time (i.e., during the idle loop between interrupt events), the player can only move on specific directions depending on where his sprite is on the play-field.  The constraints on the player imposed by the play-field quantize the movement in a way that -- in practice -- discards virtually all invalid input.

 

This, along with some basic (and reasonably fast) heuristics to decode and disambiguate the disc from other input, turns out to be sufficient.

 

In practice, a player will have to go out of his way to try to "break" the game by actively entering invalid input which does not occur during normal use -- but even when they do so, the most that will happen is that the input will be either ignored, or the player would turn towards one of the limited valid directions, mitigating the impact of the fault.

 

Of course, it is a domain-specific solution -- the game has some very particular mechanics -- but it illustrates that debouncing aggressively as a general feature for all cases, is not necessarily desirable.  Still, you can see in later games how Mattel (and third party) developers managed to work around some of these limitations, without perhaps needing to throw the entire EXEC baby out with its bathwater.

 

     -dZ.

Edited by DZ-Jay
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...