Code for original Intellivision games

[dalves]

I had taken a bit from programming for a bit, but looking to get back into it as the fall and winter months will be approaching. Many people here have been very helpful by submitting samples of their code so others could learn how to program. I would have sworn that once a while back I stumbled onto a site that had code for some of the original Mattel Intellivision games, like Space Armada, Astrosmash, and others. I've never been able to find them since. I was wondering if anyone here knows if the code of those games have ever been released and if there is anyway to have access to them? I apologize if the question has been asked before.

[David Rolfe]

I've wondered whether any original code is out there. I have Beamrider source on disk and hard copy source (old fanfold line printer format) for other stuff I worked on, plus doc. I don't know what its legal status is, or what the Intellivision Productions position is with respect to putting it out (and I'd like to hear the IP official position on the matter!). I can tell you that the old source might be historically interesting, but I doubt it would be of any technical use to anyone. Maybe that's my prejudice speaking, but I generally regard looking at other people's code as an exercise in frustration. That's especially true of Baseball, which was a learning experience, and the code is a blight on humanity, except for the minor virtue that it worked. For imparting useful information, I prefer to deal with examples to highlight a point. Just my 2 cents.

[decle]

I had taken a bit from programming for a bit, but looking to get back into it as the fall and winter months will be approaching. Many people here have been very helpful by submitting samples of their code so others could learn how to program. I would have sworn that once a while back I stumbled onto a site that had code for some of the original Mattel Intellivision games, like Space Armada, Astrosmash, and others. I've never been able to find them since. I was wondering if anyone here knows if the code of those games have ever been released and if there is anyway to have access to them? I apologize if the question has been asked before.

 

Hey,

 

Unfortunately, I'm not aware of the source code of any of the original titles being in the public domain. The nearest I have found is Killer Bees, a tutorial game written by David Rolfe (above). However, this lack of original examples is not a problem for two reasons:

• The original Mattel titles used a different assembler syntax to modern tools and so the source will not compile without modification. For example the MOV #CH.WHITE,R3 command in Killer Bees would is the equivalent of MVI# CH.WHITE, R3 in the modern as1600
• Original Mattel titles make heavy use of the EXEC. This is only partially documented (not all entry points are known) and places significant restrictions on the games that use it, most noteably that they can only run at 20Hz or lower.

Together this means that even getting simple games like Killer Bees to compile and run using modern tools is quite challenging. There are, however, a number of people who have at least partially disassembled games either to understand how they work or tweak them in some way. Examples would be:

• intvnut's investigation of Utopia
• intvdave's extensions and improvements to games like BurgerTime, Night Stalker and World Championship Baseball
• DZ Jay's support of the Intellivision Baseball League

If you are interesting software archeology using dis1600 or dasm1600 in the Jzintv SDK along with a copy of Your Friend the Exec, also written by David Rolfe, is the way to go, however, you will need alot of patience.

 

If you want to write new games the route is to forget the EXEC and the old methods and start from scratch, just as Atari, Activision and the other third party developers had to do back in the day. The easy route in is, as you have found, IntyBasic and then from there switching to assembler if you need to, or are interested. There are plenty of small examples in the Jzintv SDK to get you started in assembler programming. Then like all software it is a case of switching between adding a bit, refactoring a bit and asking questions of people who have done it before.

 

 

Hope this helps

 

decle

Edited September 2, 2017 by decle

[mr_me]

I would have thought Beamrider would belong to Activision or Cheshire. Unless the contract included copyrights it would otherwise remain with Cheshire. I don't see Intellivision Productions having any say. They should have copyrights on the APh, Mattel, and INTV Intellivision source code.

 

Normally understanding someone else's program can be alot of work itself. I've heard Mattel programmers that had to work with APh code for demo cartridges or updates comment on how well written and easy to understand it was; specifically Tennis. I think Baseball was updated and worked on by several programmers. They did have a hard time debugging the updated version.

 

How reliable is disassembling and then reassembling? That's if you wanted to tweak or modify the original game. If it's just for analysis, reassembly doesn't matter. Original source code with comments from the programmer would be nice. For learning Intellivision assembly there are lots of examples that come with Jzintv. And as Decle pointed out the syntax is a little different than what APh originally used.

 

Jzintv examples: http://spatula-city.org/~im14u2c/intv/jzintv-1.0-beta3/examples/

Edited September 2, 2017 by mr_me

[decle]

How reliable is disassembling and then reassembling? That's if you wanted to tweak or modify the original game. If it's just for analysis, reassembly doesn't matter.

 

When analysing the World Championship Baseball crash screen I found there were two tweaks I needed to make in order to re-assemble the output of dis1600. I think the following is symmetric and ends up creating a wcb.bin image that is identical to the worldChampionshipBaseball.bin original:

dis1600 -f -a -S -X worldChampionshipBaseball.bin wcb.asm
sed -e 's/ [GL]_/$/g' wcb.asm > wcb.asm1
sed -e 's/SKIP/DECLE $0208/g' wcb.asm1 > wcb.asm2
as1600 -l wcb.lst -o wcb.bin wcb.asm2

The first sed command replaces all the labels with memory addresses. The second replaces SKIP instructions with a DECLE, I should probably have replaced it with a NOPP instruction. The dis1600 command above is not ideal for understanding the code as it disables all the helpful source code interpretation (things like the cartridge headers and EXEC address interpretation). However, it does minimise the fuss when reassembling. I used a separate dis1600 run with advanced analysis turned on to generate a listing to actually understand what was going on, and then inserted my tweaks into the output of the code above. It was easy enough to find the insertion points using the code address.

[David Rolfe]

The Exec was desirable in its day because ROM was expensive, so a 4k cart could get more bang for the buck if generic service could be offloaded. At this point in time, I don't see much reason anyone would want to deal with the Exec, unless you want to put together a quick-and-dirty Killer Bees-type project, or find it easier to grapple with the arcane Exec interface rather than grapple with the arcane STIC interface.

 

By the way, I first wrote Killer Bees as a minor proof-of-concept demonstration for Mattel. There was some question as to whether an Exec was necessary, or whether some alternative competing technology to STIC was preferable. Some other vendor was hawking an alternative that struck me as pretty hokey and unworkable, but it was the sort of thing that might impress the know-nothing suits. I recall the acronym of PDI, which I said at the time stood for "Pretty Dumb Idea", but I'm pretty sure it stood for something else. Anyway, we wanted to show the suits how the kernel of a game could be implemented with a very small ROM footprint, thus reassuring them that we were on track to produce superior results.

Edited September 3, 2017 by David Rolfe

[+Lathe26]

The Exec was desirable in its day because ROM was expensive, so a 4k cart could get more bang for the buck if generic service could be offloaded. At this point in time, I don't see much reason anyone would want to deal with the Exec, unless you want to put together a quick-and-dirty Killer Bees-type project, or find it easier to grapple with the arcane Exec interface rather than grapple with the arcane STIC interface.

 

By the way, I first wrote Killer Bees as a minor proof-of-concept demonstration for Mattel. There was some question as to whether an Exec was necessary, or whether some alternative competing technology to STIC was preferable. Some other vendor was hawking an alternative that struck me as pretty hokey and unworkable, but it was the sort of thing that might impress the know-nothing suits. I recall the acronym of PDI, which I said at the time stood for "Pretty Dumb Idea", but I'm pretty sure it stood for something else. Anyway, we wanted to show the suits how the kernel of a game could be implemented with a very small ROM footprint, thus reassuring them that we were on track to produce superior results.

 

Awesome back history.

 

I wish I could say that the computer industry's know-nothing suits learned from this incident and that it was now standard classroom material in all MBA courses, but sadly not much has changed.

[mr_me]

Would you say the exec really allowed that first set of games to happen as quickly and as well as it did. It allowed a bunch of inexperienced summer students to quickly program some quality games; and the exec structure allowed other programmers to more easily step in when needed. The exec was very important at first but I think Mattel stuck with it too long. There are only a handfull of games that use the Intellivision's full power, mostly third party games.

 

Could the PDI have been the proposal from MOS Technology. I think they would have offered the VIC-20 graphics chip (no sprites). Texas Instruments made a proposal a little late with their TMS9918; that would have caused some flicker. Mattel really liked the chipset from National Semiconductor but it was more costly.

[Carl Mueller Jr]

I don't want to state (or restate) the obvious, but I really believe the EXEC was really instrumental in the early success of the Intellivision. With the initial 4K cartridge restriction, and without code for interfacing with the hardware, a macro language for sound effects, impression routines for graphics, collision routines that dispatch only on collisions the game is interested in, etc. etc., there is no way they could have been as sophisticated as they were.

I would go as far as to say they could not have offered anything much more advanced than a typical Atari VCS game at the time, and considering the heftier price tag of the Intellivision, it would have been a dealbreaker. Intellivision may not have test marketed successfully, and we probably would not even be talking about it today if it wasn't for David Rolfe's brilliant idea, design, and execution.

I suspect the Pretty Dumb Idea was perhaps a smaller ROM size and/or a more conventional approach (routines that cartridges simply called to, rather than the EXEC being the main program that dispatched to cartridge programs). I think it's utterly brilliant that cartridges essentially contain tightly compacted data tables that describe things such as which object collisions it's interested in, where graphics tables are located, etc. and need only include routines for custom behavior, allowing cartridges to be even trimmer, the extra space allowing them to be even more sophisticated, include more animation, etc.

The EXEC may be criticized for updating objects at 20 Hz and splitting up tasks, but it did have to fit in 4K. There would not have been space to unroll code to update GRAM, and the 10-bit ROM restriction also meant no packing (allowing for the "SWAP" trick to buy even more cycles). And obviously, it also had to be programmed to be more generally useful.

[decle]

It looks as though my earlier comment about constraints could been taken as a criticism of the philosophy or execution of the EXEC.

My apologies if that is the case, that was not my intention. Communication is a difficult thing.

As several have pointed out, the value of the EXEC in speeding the development, reducing the hardware costs and improving the consistency of APh / Mattel titles is undeniable.

My comment regarding constraints was made in the context of dalves question about writing new software today, where reduced memory costs and the bedroom hobby nature of much development typically leads to a different performance / time / memory trade off.

Kudos to all who battle the VBLANK interval, whenever and however they choose to do it.

[intvnut]

 

When analysing the World Championship Baseball crash screen I found there were two tweaks I needed to make in order to re-assemble the output of dis1600. I think the following is symmetric and ends up creating a wcb.bin image that is identical to the worldChampionshipBaseball.bin original:

dis1600 -f -a -S -X worldChampionshipBaseball.bin wcb.asm
sed -e 's/ [GL]_/$/g' wcb.asm > wcb.asm1
sed -e 's/SKIP/DECLE $0208/g' wcb.asm1 > wcb.asm2
as1600 -l wcb.lst -o wcb.bin wcb.asm2

The first sed command replaces all the labels with memory addresses. The second replaces SKIP instructions with a DECLE, I should probably have replaced it with a NOPP instruction. The dis1600 command above is not ideal for understanding the code as it disables all the helpful source code interpretation (things like the cartridge headers and EXEC address interpretation). However, it does minimise the fuss when reassembling. I used a separate dis1600 run with advanced analysis turned on to generate a listing to actually understand what was going on, and then inserted my tweaks into the output of the code above. It was easy enough to find the insertion points using the code address.

 

You don't need a sed script to replace SKIP, just a MACRO.

.

MACRO SKIP
      DECLE $280
ENDM

.

SKIP is semantically different from NOPP, in that NOPP always encodes 2 words, with the 2nd word ignored. SKIP is used for skipping a single-word instruction unconditionally, like INCR PC would, only without horking the flags. You'd break the code if you replaced SKIP with NOPP, as that would end up inserting an unwanted $0000 into your ROM.

 

As for the sed command that replaces G_xxxx and L_xxxx labels with $xxxx labels: You really only want to do that with the G_xxxx labels. The L_xxxx labels should all be defined in the body of the code. If you want to make any modifications that shift things around, you want the L_xxxx labels to move with the code. That still won't find all addresses embedded in data structures, but it at least will help with branches and calls.

Edited September 19, 2017 by intvnut

[intvnut]

I recall the acronym of PDI, which I said at the time stood for "Pretty Dumb Idea", but I'm pretty sure it stood for something else.

 

I've spent too many hours trawling the Papa Intellivision site. It mentions an alternative proposal involving Signetics chips named PVI, rather than PDI. Perhaps it was creatively corrupted from PVI to PDI? :-)

 

I've transcribed the relevant memo below (you can click the link above to verify my transcription):

.

July 10, 1978                                     C_O_N_F_I_D_E_N_T_I_A_L


TO:                 RICHARD CHANG

FROM:               DAVE CHANDLER

SUBJECT:            BACK-UP VIDEO SYSTEM

___________________________________________________________________________


It is clear that we should continue to strive to get our system completed
for the January C.E.S. based on the G.I. STIC chip set.  However, in light
of the facts that the schedule for obtaining F.C.C. approval outlined by
G.I. is quite tight for January C.E.S., cost reductions in the forms of
40K ROMS and a consolidated chip set will not be available for 1979 pro-
duction, and the 40°C temperature specification on the STIC chip set
promises to cause problems and expense, it seems wise to pursue a back-up
system.

An interesting candidate for a back-up system appears feasible based on a
combination of Signetics PVI chip set and MOS Technology's VIC chip.  The
VIC provides better background capability than we now have, with higher
resolution and better alphanumerics.  The PVI system provides more flex-
ible foreground capability, primarily because of the multiplexing capability.
All the chips exist now, functioning hardware can be put together right
away.  The lowest temperature spec on any of these chips is 55°C.  There
is the necessity to marry the two systems and while I have found no inherent
obstacles to such a marriage, there could still be some problems.

I am proposing a three stage approach to pursuing this back-up system:

1.  Proceed as quickly as possible to breadboard a system which would
    incorporate 1 VIC chip and 4 PVI chips.

2.  Assuming the breadboard looks good, design and build PC boards to fit
    into our present housing, again based on 1 VIC chip and 4 PVI's.  This
    system could be put through F.C.C. for January C.E.S. and used for
    limited early production, if desired.

3.  Fund Signetics to lift the portions from PVI which generate moving
    objects, expand them to 16 lines high and put 8 moving objects in one
    new chip for us (call it MOVI).  Of-the-top-of-the-head estimates by
    Signetics are that this could be done in about 6 months.  That could
    permit us to use this chip for the quantity production and would appear
    to give us a chip set cost comparable to the STIC set.







Richard Chang
July 10, 1978
Page 2




It would be good if we could be in a position to discuss the MOVI chip
with Signetics management when they come here July 17.

To minimize the problems associated with creating another competitive
system which we might not use, I would propose that the breadboard be put
together at APh but with them having no contact with either Signetics or
MOS Technology.  All of the coordination would come through here and we
would not let either company know the full nature of the systems we are
putting together.  They would also not know where it is being put together.


DPC:lb


CC:  Denis Bosley
     Josh Denham
     Ed Krakauer
     Jeff Rochlis

Edited September 19, 2017 by intvnut

[intvnut]

Also, there was TI / Milton Bradley's proposal for the "H.E.C." built around the TMS9918 VDP and TMS9900 CPU and a serial-ROM technology called GROM and an interpreted programming language called GPL. (Briefly mentioned in this PDF; also mentioned in others.)

 

 

Could the PDI have been the proposal from MOS Technology. I think they would have offered the VIC-20 graphics chip (no sprites). Texas Instruments made a proposal a little late with their TMS9918; that would have caused some flicker. Mattel really liked the chipset from National Semiconductor but it was more costly.

 

See my previous comment: I think PDI refers actually to the PVI chips that would be paired with the VIC. The TI/MB proposal, if I believe the docs on Papa Intellivision, was believed to be limited by the GROM/GPL architecture, not the number of sprites-per-line.

 

Recall the TMS9928 VDP later showed up on the Colecovision. IIRC, David Rolfe put it to good use there in Steamroller.

Edited September 19, 2017 by intvnut

[intvnut]

I would have thought Beamrider would belong to Activision or Cheshire. Unless the contract included copyrights it would otherwise remain with Cheshire. I don't see Intellivision Productions having any say. They should have copyrights on the APh, Mattel, and INTV Intellivision source code.

 

I believe Intellivision Productions acquired the rights to Beamrider and other Activision games. That's what allowed them to appear on Intellivision Rocks!

 

Copyright law in 1982 was a bit different than 1989 and later (when we adopted the Berne Convention). For example, the US did not protect moral rights, and I believe it was easier to create uncopyrighted works, and to assign copyrights to others. Now, with Berne, everything is automatically copyrighted (even if not registered), and the author retains moral rights even if they assign copyrights to others.

[mr_me]

Intellivision productions had a licensing deal with Activision for the Rocks CD. It was covered in Intellivisionairies episode 9 at 2:25 interview with Keith R. They wanted to do it again with the playstation/xbox cds but couldn't make another deal with Activision. Intellivision Productions did later publish the unreleased game Steamroller and needed Activision's permission. http://www.intellivisionlives.com/retrotopia/steam.shtml

 

Yeah, copyright changed around that time. It use to be important to have that copyright symbol displayed otherwise it wasn't protected.

 

The graphics chip in the coleco vision is a slight update to what TI had in 1979. The coleco vision is still limited to four sprites on a scanline. With some of Intellivision sports games either some pixels would get dropped or you have to create some flicker. The TI chip seems to work fine otherwise although the colour palette is a bit ugly.

 

I could see PVI being heard as PDI in a meeting. Interesting that Mattel was willing to fund chip development and had input on design changes with chip manufacturers but never wanted any part of ownership of it. There was some dispute between Milton Bradley and Texas Instruments over that TI graphics chip. Its not clear what that dispute was about.

[decle]

You don't need a sed script to replace SKIP, just a MACRO.

True, good point.

 

SKIP is semantically different from NOPP, in that NOPP always encodes 2 words, with the 2nd word ignored. SKIP is used for skipping a single-word instruction unconditionally, like INCR PC would, only without horking the flags. You'd break the code if you replaced SKIP with NOPP, as that would end up inserting an unwanted $0000 into your ROM.

Ahh, OK. So this might explain why I used the DECLE rather than a NOPP. The decle in the ROM is definitely $208 and when writing my post I just thought that using a DECLE was me being stupid and lazy. So I looked up the opcode, bingo, NOPP. Looking at the occurences of SKIP in the disassembly of WCB now it looks like they are post call data (do these constructs have a proper name?), for example this looks like it might be writing the message "walk" to the screen:

 

        JSR     R5,     G_1ED5                  ; 63B3   0004 011C 02D5
        JSR     R5,     L_5241                  ; 63B6   0004 0150 0241

        SKIP                                    ; 63B9   0208
        RLC     R3,     2                       ; 63BA   0057
        SWAP    R1,     1                       ; 63BB   0041
        SLL     R0,     2                       ; 63BC   004C
        SLL     R3,     1                       ; 63BD   004B
        DECLE   $0000                           ; 63BE   0000

        JSR     R5,     L_6489                  ; 63BF   0004 0164 0089

And as such the correct interpretation is, as you say, a DECLE statement, not NOPP. This does vaguely ring a bell now. Apologies for the misinformation.

 

 

As for the sed command that replaces G_xxxx and L_xxxx labels with $xxxx labels: You really only want to do that with the G_xxxx labels. The L_xxxx labels should all be defined in the body of the code. If you want to make any modifications that shift things around, you want the L_xxxx labels to move with the code. That still won't find all addresses embedded in data structures, but it at least will help with branches and calls.

Yup that was me being lazy, kind of

 

In this instance because of what I was doing I wanted to have minimal change. So I was using the absolute addresses as a check against my accidentally shifting something. You are correct in the more general case only changing the G_xxxx labels is the way to go

Edited September 19, 2017 by decle

[Kiwi]

The graphics chip in the coleco vision is a slight update to what TI had in 1979. The coleco vision is still limited to four sprites on a scanline. With some of Intellivision sports games either some pixels would get dropped or you have to create some flicker. The TI chip seems to work fine otherwise although the colour palette is a bit ugly.

It would require more RAM to use for video if they would have gone with TI chip 4KB is the minimum I think 2KB would be doable if the sprites and char share the same table. Other than the 4 sprites on the line, it doesn't have hardware flip, individual resize sprites, priority(can't go behind foreground pixels). Also, no hardware scrolling. I do appreciate both systems and enjoy developing games on both in my freetime.

[mr_me]

Yes the original TI994 computer had 16k of video ram, just like the coleco vision in 1982. I wasn't sure how that could have worked for Mattel in 1979. The TI chip did use cheaper dram so it might have worked out if they could get away with 4k or less dram.

[intvnut]

The VDP is designed to work with either 4K or 16K DRAMs. A 4K VDP based system may have worked cost-wise for Mattel; however, it looked like what they evaluated was buying into the whole HEC concept MB and TI were pushing, and that probably required 16K. Coleco probably arrived at a different decision in part thanks to the MSX. The MSX and Coleco look an awful lot alike, just with their memory maps flipped. That, and the cost reductions that come with 4 years makes it a better proposition.

 

 

The graphics chip in the coleco vision is a slight update to what TI had in 1979. The coleco vision is still limited to four sprites on a scanline. With some of Intellivision sports games either some pixels would get dropped or you have to create some flicker. The TI chip seems to work fine otherwise although the colour palette is a bit ugly.

 

 

The Coleco used the TMS9928A VDP rather than the TMS9918A VDP, but they were both released roughly together. The only difference is that the TMS9928A output color-difference signals, which allowed for external color carrier mixing and video overlay. This also made it possible to eliminate the "Rainbow Effect." (Later Colecos used the TMS9128A, which is indeed a revised implementation to reduce power.)

 

I don't know if the 'A' version was available in 1978, but it would have been available by the time Intellivision went to market. The main thin the 'A' version added was bitmap mode, although to use that, you need 16K of DRAM. The pattern table for bitmap mode alone takes 6K, if memory serves (768 * 8 ) while the color table takes an additional 6K. The name table stays at 768 bytes.

 

I actually have a scan of Karl Guttag's hand-written memo where he invented the 'A' version's bitmap mode, using just 50 transistors.

Edited September 19, 2017 by intvnut

[David Rolfe]

These posts are interesting, but I can't nail down the "PDI" that I remember. I was the software guy trying to show STIC off to best effect; I was probably told more details about the "competition", but they're vague. Yes, four sprites on a line was stated; we stressed that this was an important limitation, because it would make a lot of games ugly. The mysterious competition had apparently provided some sort of demo game to match our "Killer Bees"; I never saw it, but I was told that the too-many-sprites-on-a-line situation never came up. I suppose that's what I'd do if I were them, which is arrange a demo to show strengths and hide weaknesses. Now that I mention it, that's also what I'd do if I were me. That was our big claim with the Exec: Look how much we can do with a teeny tiny program! We made a point of providing a byte count, which was a big deal in those days. I also recall some things being said about the PDI processing either being slow or more removed from the hardware than we were. I'm not sure of the details...very slow memory, or a level of interpretation, or some factor that I figured would hobble/limit the game designer. Bottom line was that I really did believe, based on whatever knowledge I had at the time, that STIC would be a great platform and this alternative would not. And of course, had Mattel not gone with STIC, our participation in the project would have been terminated.

 

I wrote an early (pre-Exec) demo for Mattel in December of 1977, and it was my understanding that they showed it to a limited crowd in their hotel suite at Vegas CES in January of 1978, and this helped convince them that the project had good potential. But this PDI stuff happened after we had a working (albeit non-final) Exec, so that must have been maybe pushing towards mid-1978?

[Walter Ives]

On 9/6/2017 at 5:16 PM, Carl Mueller Jr said:

I don't want to state (or restate) the obvious, but I really believe the EXEC was really instrumental in the early success of the Intellivision. With the initial 4K cartridge restriction, and without code for interfacing with the hardware, a macro language for sound effects, impression routines for graphics, collision routines that dispatch only on collisions the game is interested in, etc. etc., there is no way they could have been as sophisticated as they were.

Not to mention that the EXEC enabled the games to be programmed in about ten weeks by college students on summer vacation.

On 9/6/2017 at 5:16 PM, Carl Mueller Jr said:

Intellivision may not have test marketed successfully, and we probably would not even be talking about it today if it wasn't for David Rolfe's brilliant idea, design, and execution.

The idea for the EXEC was not Rolfe's. It was a specific assignment that he was given about three months to perform in anticipation of the first wave of summer-student programmers. His execution was indeed brilliant—those who know him describe him as an extraordinary craftsman.

On 9/7/2017 at 12:26 AM, decle said:

Kudos to all who battle the VBLANK interval, whenever and however they choose to do it.

Few people appreciate this: VCS programs spent all of active picture feeding the hardware registers ("chasing the beam") and implemented game play during VBLANK; Intellivision programs spent all of VBLANK feeding the hardware registers and implemented game play during active picture.

On 9/19/2017 at 2:17 AM, intvnut said:

I've spent too many hours trawling the Papa Intellivision site. It mentions an alternative proposal involving Signetics chips named PVI

Programmable Video Interface

 

[+DZ-Jay]

On 12/3/2022 at 8:09 AM, Walter Ives said:

Not to mention that the EXEC enabled the games to be programmed in about ten weeks by college students on summer vacation.

But it was mentioned, or at least submitted for consideration, just a few posts above:

On 9/3/2017 at 7:17 AM, mr_me said:

Would you say the exec really allowed that first set of games to happen as quickly and as well as it did. It allowed a bunch of inexperienced summer students to quickly program some quality games;

 

On 12/3/2022 at 8:09 AM, Walter Ives said:

Few people appreciate this: VCS programs spent all of active picture feeding the hardware registers ("chasing the beam") and implemented game play during VBLANK; Intellivision programs spent all of VBLANK feeding the hardware registers and implemented game play during active picture.

Interesting way to put it, but I think it captures the point spectacularly.

 

All I know is that I have taken a look at some of the techniques employed by VCS programmers, delved into the theory that drives them, read some arcane documentation, and even watched some online videos intended to instruct or "demystify" such techniques for "racing the beam; and I still find it utterly and excruciatingly insane as a matter of standard development pattern for making a video game.

 

Absolutely the stuff for macho-cowboy-coding-wizards.  No thank you!  😱

 

    dZ.