Intellivision Memorabilia

[daniel3302]

Thanks for the trip down memory lane. The supplement basically confirms my recollection, which was the last paragraph in post #7. The one additional comment I can say regards the games that did not use the Exec for character movement, but rather stole every interrupt and handled it themselves. As part of the interrupt processing they would have to explicitly call the Exec's sound processing function.

[+DZ-Jay]

Thanks for the trip down memory lane. The supplement basically confirms my recollection, which was the last paragraph in post #7. The one additional comment I can say regards the games that did not use the Exec for character movement, but rather stole every interrupt and handled it themselves. As part of the interrupt processing they would have to explicitly call the Exec's sound processing function.

 

Interesting, so the EXEC's sound processing function could be called by itself without having to setup extensive data structures or relying on other facilities of the EXEC's framework. That's neat!

 

-dZ.

[David Rolfe]

The Exec included a sound code routine that processed inline macros that defined a sound sequence. Here's a messy, complex example of an often-used sound that we built into the Exec, the crowd sound. The "funny" opcodes you see below are macros. Hal Finney and I worked together on the design of this system, and then I wrote the sound processor while Hal wrote the macro sequences for early sound, including this great crowd sound. I remember Hal paying special attention to the then-current (1978) film "Heaven Can Wait", listening carefully to the football crowd scenes in order to analyze what he could and would put into this crowd sound. Some noise mixed with a whistle, a trill, an air horn...we know a crowd sound when we hear it, but what's really in it anyway? The following block of code is from the Exec, and could be invoked by any game:

 

TITLE "CROWD SOUNDS"

;SOUND OF A ROARING CROWD OF SPECTATORS

CROWD:: BEGIN

CROWD0::CALL SCODE ;DO THIS SOUND :

ENABLE NCH1&NCH2 ;NOISE

NFREQ &37 ;LOW

VOL CH1,&4 ;VOL SOFT

VOL CH2,&6

VOLV CH1,&6 ;BUT GETTING LOUDER

VOLV CH2,&6

PAUSE &10 ;LET VOLUME GROW

VOLV CH1,0 ;HOLD VOLUME STEADY

VOLV CH2,0

NFREQV -1 ;THEN GO UP SLOWLY

PAUSE &24 ;MAKE SOUND

NFREQV 0 ;HOLD SOUND TONE STEADY NOW

;THIS PART MAKES WHISTLES, ETC:

WBLP:

;FIRST MAKE 0 OR 1 WHISTLE

RSETR SR3,1,2

PDJNZ 0,SR3,WLPDN

WLP: ENABLE NCH2&TCH1 ;USE CHANNEL 0

FREQ CH1,&120,&12 ;FAIRLY SOFT VOLUME

RFREQ 6 ;QUITE RANDOM IN PITCH

;THIS PART MAKES REPEATED WAVER AT PEAK OF WHISTLE

FREQV CH1,-2,0 ;GO UP FIRST

PAUSE &20

RSETR SR2,2,5 ;FROM 0 TO 3 WAVERS

PDJNZ 1,SR2,WLP2DN

WLP2: FREQV CH1,3,0 ;GO DOWN

PAUSE 6

FREQV CH1,-3,0 ;THEN BACK UP

WLP2DN: PDJNZ 6,SR2,WLP2 ;KEEP DOING THIS SOME

FREQV CH1,2,0 ;THEN A FINAL FALL OFF

PAUSE &20

;TURN OFF WHISTLE FOR A RANDOM LENGTH OF TIME

ENABLE NCH2 ;JUST NOISE

RPAUSE 5,&60 ;FOR QUITE A RANDOM LENGTH OF TIME

WLPDN:

;THIS PART MAKES SOME BUZZES

RSETR SR3,1,2 ;0 OR 1 BUZZ

PDJNZ 0,SR3,BZZDN

BUZZLP: ENABLE NCH2&TCH1&TCH2 ;TWO TONE CHANNELS

FREQ CH1,&1000,&12

FREQ CH2,&1100,&14

PAUSE &20 ;TURN ON SOUND FOR A WHILE

ENABLE NCH2 ;JUST NOISE FOR NOW

RPAUSE &10,&30 ;FOR A RANDOM LENGTH

BZZDN:

;HERE, WE GO BACK AND DO SOME MORE WHISTLES

PDJNZ 0,SR1,WBLP ;LOOP TILL DONE

;HERE, WE TERMINATE THE CROWD ROAR

VOLV CH1,-&1

VOLV CH2,-&1

NFREQV &2

PAUSE &50

ENABLE NONE

FIN ONS,NRET

; RETURN

[+DZ-Jay]

Thanks for posting that, Mr. Rolfe. I'll admit that I've read the full EXEC document supplement which you posted (I found it on the Internet! I'm sorry, I was weak!) and I found it fascinating. Of course, I do not have source code nor the macro library so I can't play with it to experiment, but the facilities provided by the macros strike me as brilliantly conceived. It is essentially a sound effect "scripting engine," much more sophisticated than anything we currently use in home-brewed games.

 

For all its faults and perhaps primitive quality, the EXEC is indeed an admirable piece of engineering. I do not mean that in any small way: the more I learn about it, the more I am enthralled by the notion that it was more than just a collection of common routines, but a real generalized game programming platform -- something that up until IntyBASIC came along very recently, we've sorely lacked in the home-brew world. Even then, with 30 years of collective wisdom and industry experience at its disposal, IntyBASIC lacks automatic object motion control, a true object-oriented or event-driven framework, and a sophisticated sound effects processor. All things that the EXEC did (to perhaps varying degrees of success) 30 years ago.

 

Sound processing is something that I personally find interesting, mostly because I used to play with early synths back in the 1980s and remember the thrill of "designing" sounds. I have trouble "visualizing" ("audioalizing"?) sounds as discrete programming steps; I think more in terms of tones, envelopes, filters, layered signal modulators, LFOs, etc. To me, the SCODE sound processor of the EXEC comes close to this sort of paradigm, if still just a bit too low-level.

 

I would love to read anything else that you have to share on the subject of the EXEC.

 

Thanks,

-dZ.

[daniel3302]

The strengths of the Exec's sound code (from this game programmer's perspective) were the macros - which allowed a much more natural way to control the "knobs & widgets" provided by the hardware sound chip, and the "set & forget" nature of the code. Keep in mind, your sound/music is going on over many seconds or more of game time, and you don't want to be worried about controlling all the sound changes while running the actual game play.

 

The down side that I was addressing w/Mr. Sound is that tuning and tweaking all those controls was very laborious without any kind of emulator or IDE

[Blimpers]

 

The Exec included a sound code routine that processed inline macros that defined a sound sequence. Here's a messy, complex example of an often-used sound that we built into the Exec, the crowd sound. The "funny" opcodes you see below are macros. Hal Finney and I worked together on the design of this system, and then I wrote the sound processor while Hal wrote the macro sequences for early sound, including this great crowd sound. I remember Hal paying special attention to the then-current (1978) film "Heaven Can Wait", listening carefully to the football crowd scenes in order to analyze what he could and would put into this crowd sound. Some noise mixed with a whistle, a trill, an air horn...we know a crowd sound when we hear it, but what's really in it anyway? The following block of code is from the Exec, and could be invoked by any game:

Wow, that has to be one of the iconic Intellivision sounds. And funny story about the movie! I would ask why the team didn't just listen to an NFL game, but I bet that would have resulted in a less interesting sound.

[+DZ-Jay]

The strengths of the Exec's sound code (from this game programmer's perspective) were the macros - which allowed a much more natural way to control the "knobs & widgets" provided by the hardware sound chip, and the "set & forget" nature of the code. Keep in mind, your sound/music is going on over many seconds or more of game time, and you don't want to be worried about controlling all the sound changes while running the actual game play.

 

The down side that I was addressing w/Mr. Sound is that tuning and tweaking all those controls was very laborious without any kind of emulator or IDE

 

Absolutely agree. That's why I mentioned that it is a "scripting engine" more than just a programming library: You call the the SCODE and the EXEC will return immediately and process the sound "script" automatically, on its own, running concurrently to your program.

 

Plus of course, as you rightly point out, the macros turn the esoteric hardware features into more intuitive controls reminiscence of the control surfaces on old synths.

 

Still, for someone like me, I would need something like your Mr. Sound, since I work more effectively by tweaking knobs and moving sliders than by specifying these things in code. The work you guys were doing back then was very sophisticated. It's too bad we don't have something like that for our current work.

 

-dZ.

[David Rolfe]

FWIW, here's a photo of me (center) and Hal Finney (left), from probably 1978, early in the era of Intellivision development. Note the bike and cinderblock shelves at left and adjacent desks; this was very much of a shoestring operation, both us and the business. Note what you *don't* see: No desktop computers or even monitors. We had paper on our desks, and we actually used it! Imagine that!

[+DZ-Jay]

FWIW, here's a photo of me (center) and Hal Finney (left), from probably 1978, early in the era of Intellivision development. Note the bike and cinderblock shelves at left and adjacent desks; this was very much of a shoestring operation, both us and the business. Note what you *don't* see: No desktop computers or even monitors. We had paper on our desks, and we actually used it! Imagine that!

 

Wow! Thanks for sharing that, Mr. Rolfe. I recall debugging my micro-computer code printed out on reams of track-paper, stretched out on the floor, but I actually wrote it on the machine.

 

Did you guys actually write your code on paper first?

 

-dZ.

[Humblejack]

FWIW, here's a photo of me (center) and Hal Finney (left), from probably 1978, early in the era of Intellivision development. Note the bike and cinderblock shelves at left and adjacent desks; this was very much of a shoestring operation, both us and the business. Note what you *don't* see: No desktop computers or even monitors. We had paper on our desks, and we actually used it! Imagine that!

 

They look like old government surplus desks, I sat at one for many years.

[mr_me]

In Dave's linked photo, he says the other guy leaning back in his chair is Will McCown "a hardware guy". I'm guessing he helped out with creating the Intellivision development system hardware. In a Tom Loughry interview, Tom says Will was involved in the development of the Intellivision III when they all decided to quit APh. Perhaps another reason the project was delayed.

 

I'm guessing once APh hired more programmers for the Intellivision games, they would each have a terminal. At Mattel they tried to give every programmer a terminal. At Atari, the programmers would leave their office/desk for the computer lab/room to program. At Imagic the Atari guys were setup like they were at Atari while the Intellivision guys had terminals at their desks. Either way the programmers probably spent more time reviewing their code before attempting to assemble and test than a programmer would today.

 

Wow, that has to be one of the iconic Intellivision sounds. And funny story about the movie! I would ask why the team didn't just listen to an NFL game, but I bet that would have resulted in a less interesting sound.

That work was probably done in the NFL offseason, maybe spring 1978. The football scenes in Heaven Can Wait were nicely done. Had he gone to see Slap Shot instead we might have had some organ music in those games. Edited March 12, 2018 by mr_me

[daniel3302]

So I found a folder with design notes from Loco-Motion as well as the internal game reviews done by fellow BSRs. I have scanned in a sampling in my gallery.

[Intymike]

Awesome documents!

[+intvsteve]

So I found a folder with design notes from Loco-Motion as well as the internal game reviews done by fellow BSRs. I have scanned in a sampling in my gallery.

 

Awesome! I had the exact same graph paper as on the Loco2 sheet! As a kid, I recall designing some graphics for a game I wanted to call 'Asteroid Battle' - it had to fit into the 'Battle' series of games after all.

[daniel3302]

On to Tower of Mystery memorabilia. Just uploaded to my gallery are the room maps in ToM. Each tower level was created randomly by first selecting a matrix of (I believe it was 5 vertical by 3 wide) of room connections, starting with the room with the stairs to the level above. Each room could have, or not have, a connection on the West, East, North, and South walls (referenced as bits 1, 2, 4, 8 ) thus giving 15 possible configurations. Once the matrix of connection configurations was made, one of the 8 pre-designed rooms for each configuration was selected.

 

In this way, a fully connected semi-random level would be created. By using a pre-set random seed, the exact same "random" level could be created if one returned to a previously explored level, without having to actually save any configuration information in the 147 bytes of RAM available to use in the Exec.

 

If you look carefully at these room maps, you will notice a few that have the shapes "D" and "B", and pair that when connected shows "dhb" Yes, I was a subversive.

There is also an "M" (sideways) that could connect too the sideways "B". That was for fellow BSR Mark Buchignani, who helped me design the rooms and play test the game.

Edited April 4, 2018 by daniel3302

[mr_me]

Can you comment on the screen below (if you remember). Was it meant to be part of the final game. How are id and password used.

[daniel3302]

Yes, this is one feature I was particularly proud of, and was quite disappointed when I saw that John T had taken it out of the Tower of Doom released version.

Recognizing that playing through a single game could take a very long time, I wanted to put in some kind of game save/game restore feature, something unheard of in the videogame technology of the time, as there was no non-volatile RAM available on either the cartridge or the console.

My scheme was to output the current game stats (as shown in the first four lines) plus encoded values for the item in your hand, the game type (difficulty, etc) and the initial random seed. Finally, a checksum value that tied all these data together.

 

The player would be responsible for recording these values on non-volatile media (paper and pencil). To resume the game, the player could enter the values for the saved game. The Password (checksum) would prevent "cheating" by modifying stats (setting your strength to 18 say) or trying to "create" a killer character. Also, only the item in hand could be saved - the pack in a resumed game would be empty.

[Blimpers]

Yes, this is one feature I was particularly proud of, and was quite disappointed when I saw that John T had taken it out of the Tower of Doom released version.

Recognizing that playing through a single game could take a very long time, I wanted to put in some kind of game save/game restore feature, something unheard of in the videogame technology of the time, as there was no non-volatile RAM available on either the cartridge or the console.

 

Oh man, why, John T, why!?!? Were there memory constraints?

 

It would have been a fantastic feature, perhaps even patentable for you. The feature did appear in 1986's Metroid for the NES -- was that the first?

[daniel3302]

My latest additions to my Gallery are some design notes from ToM that reference one of my other innovations. As you may know, the Exec provides programmers with a grand total of 147 bytes of RAM for all of your game's state storage. Now, if you handle your own interrupts and object motion, you can also grab some of the 16-bit memory dedicated to the moving objects, but that still is a pretty tight squeeze for any kind of complicated game. Now ToM had a lot of binary state to keep track of, with whether the player was affected by magic items. You can see in ToM-flags3 a matrix of magic items, many of which would change character state for either a time period or while the item was in use. For example, small potion 2, Fire Resistance, would set the flag POT.Asbes[tos], and similarly the Ring of Fire Resistance would (while worn) set the flag RG.Asbes[tos].

 

This meant I needed a lot of bits for all these flags. I grabbed them out of the background graphics RAM (BackTab). BackTab was located in the 16-bit RAM chip, but the video processor would only read and use the lower 14 bits. The upper 2 bits were don't-cares as far as the video was concerned. So, why let 2bits x 12 x 20 entries = 480 bits go to waste? I wrote macros and code to store and read bit-addressable state flags, as well as code to protect these bits when re-drawing the screen (e.g. when going down stairs between levels).

 

So you can see in the other two scans some of the accumulated logic between all of the different magic item effects and the global state flags, as well as a piece of code to perform the logical accumulation.

[+DZ-Jay]

This meant I needed a lot of bits for all these flags. I grabbed them out of the background graphics RAM (BackTab). BackTab was located in the 16-bit RAM chip, but the video processor would only read and use the lower 14 bits.

Wow! That's very cool!

 

I did a similar thing in Christmas Carol, where I stored the state of having picked up a candy or snowflake in the card's BACKTAB word. This was implemented absolutely independently, without any knowledge of its prior use.

 

I further took advantage of using Color Stack and only GRAM cards in the maze, which freed up two additional bits in the "card number" field of the word.

 

Since Color Stack supports GROM extended cards, it allows for an 8-bit index. However, when the GRAM bit is set, only the lower-order 6-bits are read by the STIC. Since I knew I only used GRAM cards, the two most-significant bits were free to use.

 

Thus I got to employ a 4-bit vector in each walkable BACKTAB word in the maze to store the state of various items.

 

Like you, I implemented a set of macros to encode and decode these bits so that i could treat them as a 4-bit vector of item state.

 

It's very interesting to see that advanced techniques such as these were in used back in the early days of the Intellivision, to overcome the system's limitations.

 

I also feel a sense of pride and honour to have come up with a strategy that has been employed by someone as experienced and admired as you.

 

dZ.

[First Spear]

Wow! I am basically doing exactly that for a game I am developing. Until I saw this, I thought that I made up the idea myself (don't know whether I should smile or frown). Well, at least I know I am following something tried and true. Very cool!

 

 

On to Tower of Mystery memorabilia. Just uploaded to my gallery are the room maps in ToM. Each tower level was created randomly by first selecting a matrix of (I believe it was 5 vertical by 3 wide) of room connections, starting with the room with the stairs to the level above. Each room could have, or not have, a connection on the West, East, North, and South walls (referenced as bits 1, 2, 4, 8 ) thus giving 15 possible configurations. Once the matrix of connection configurations was made, one of the 8 pre-designed rooms for each configuration was selected.

 

In this way, a fully connected semi-random level would be created. By using a pre-set random seed, the exact same "random" level could be created if one returned to a previously explored level, without having to actually save any configuration information in the 147 bytes of RAM available to use in the Exec.

 

If you look carefully at these room maps, you will notice a few that have the shapes "D" and "B", and pair that when connected shows "dhb" Yes, I was a subversive.

There is also an "M" (sideways) that could connect too the sideways "B". That was for fellow BSR Mark Buchignani, who helped me design the rooms and play test the game.

[daniel3302]

I can't tell you how many brilliantly creative new ideas I have had, ... only to discover that it wasn't so new.

[+JasonlikesINTV]

 

Oh man, why, John T, why!?!? Were there memory constraints?

 

It would have been a fantastic feature, perhaps even patentable for you. The feature did appear in 1986's Metroid for the NES -- was that the first?

I'll have to see if I still have my handwritten save codes from Metroid and Kid Icarus. I'm sure I have them somewhere...Probably in a box with my (heavily used) Nintendo Powers.

[+JasonlikesINTV]

I can't tell you how many brilliantly creative new ideas I have had, ... only to discover that it wasn't so new.

You and me both. Just the other day I invented a new word. I call it "plagiarism"

[daniel3302]

Here are the official documents I saved from my time at ME. Starting off with my Annual Performance review:

Clearly this was after Loco-Motion was complete, and I was busy finishing up Mr. Sound, and the nature of my second game (which was to be Tower of Mystery) had not yet been determined.

 

Later that year, after much lobbying from Keith, Don, and others, and also due to brain drain to other game companies, Mattel finally put together an incentive program. The details were presented to us here:

 

A few weeks later we had to sign release waivers, cause that what corporate lawyers are for.

But even with that, there were more rounds of layoffs, morale fell through the floor, and those who were left were looking to leave on their own terms, rather than wait for the next round of RIFs. As a last-ditch effort to keep the core of talent that remained, additional incentives were added to keep the remaining staff.

To no avail. The end was coming anyway. Note the irony of the date of this last notice, compared to the date of my next annual review as noted on the first document!

 

Thanks for letting me share an all-too-brief period that brings me much joy in its remembrance.