Jump to content

Photo

Intellivision Memorabilia


59 replies to this topic

#26 daniel3302 OFFLINE  

daniel3302

    Space Invader

  • Topic Starter
  • 37 posts

Posted Thu Mar 8, 2018 6:45 AM

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.



#27 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,066 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Thu Mar 8, 2018 6:48 AM

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.



#28 David Rolfe OFFLINE  

David Rolfe

    Space Invader

  • 22 posts

Posted Fri Mar 9, 2018 12:57 AM

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
 
Sound doc page 05


#29 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,066 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Fri Mar 9, 2018 4:32 AM

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.



#30 daniel3302 OFFLINE  

daniel3302

    Space Invader

  • Topic Starter
  • 37 posts

Posted Fri Mar 9, 2018 7:47 AM

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



#31 Blimpers OFFLINE  

Blimpers

    Space Invader

  • 20 posts

Posted Fri Mar 9, 2018 4:29 PM

 

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.



#32 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,066 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Sat Mar 10, 2018 10:04 AM

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.



#33 David Rolfe OFFLINE  

David Rolfe

    Space Invader

  • 22 posts

Posted Sun Mar 11, 2018 1:23 AM

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!

Game Design circa 1978


#34 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,066 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Sun Mar 11, 2018 6:11 AM

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.



#35 Humblejack OFFLINE  

Humblejack

    Dragonstomper

  • 508 posts

Posted Sun Mar 11, 2018 11:44 AM

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.



#36 mr_me OFFLINE  

mr_me

    River Patroller

  • 3,092 posts
  • Location:Ontario

Posted Mon Mar 12, 2018 5:35 AM

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 by mr_me, Mon Mar 12, 2018 5:49 AM.


#37 daniel3302 OFFLINE  

daniel3302

    Space Invader

  • Topic Starter
  • 37 posts

Posted Tue Apr 3, 2018 11:17 AM

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.



#38 Intymike OFFLINE  

Intymike

    River Patroller

  • 2,973 posts
  • Location:Rhine Valley

Posted Tue Apr 3, 2018 1:09 PM

Awesome documents!



#39 intvsteve OFFLINE  

intvsteve

    River Patroller

  • 3,035 posts
  • Location:At the keyboard

Posted Wed Apr 4, 2018 11:23 AM

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. ;)



#40 daniel3302 OFFLINE  

daniel3302

    Space Invader

  • Topic Starter
  • 37 posts

Posted Wed Apr 4, 2018 12:44 PM

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 by daniel3302, Wed Apr 4, 2018 12:45 PM.


#41 mr_me OFFLINE  

mr_me

    River Patroller

  • 3,092 posts
  • Location:Ontario

Posted Wed Apr 4, 2018 3:20 PM

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.

Attached Thumbnails

  • int_tower.png


#42 daniel3302 OFFLINE  

daniel3302

    Space Invader

  • Topic Starter
  • 37 posts

Posted Wed Apr 4, 2018 3:53 PM

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.



#43 Blimpers OFFLINE  

Blimpers

    Space Invader

  • 20 posts

Posted Wed Apr 4, 2018 6:41 PM

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?



#44 daniel3302 OFFLINE  

daniel3302

    Space Invader

  • Topic Starter
  • 37 posts

Posted Thu Apr 5, 2018 9:07 AM

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.



#45 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,066 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Thu Apr 5, 2018 9:21 AM

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.

#46 First Spear OFFLINE  

First Spear

    Stargunner

  • 1,286 posts
  • Location:Somewhere in Uptown

Posted Tue May 1, 2018 10:35 AM

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.



#47 daniel3302 OFFLINE  

daniel3302

    Space Invader

  • Topic Starter
  • 37 posts

Posted Tue May 1, 2018 2:11 PM

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



#48 JasonlikesINTV OFFLINE  

JasonlikesINTV

    Quadrunner

  • 9,089 posts
  • Location:Midwest

Posted Tue May 1, 2018 6:32 PM

 
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.

#49 JasonlikesINTV OFFLINE  

JasonlikesINTV

    Quadrunner

  • 9,089 posts
  • Location:Midwest

Posted Tue May 1, 2018 6:34 PM

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" :lolblue:

#50 daniel3302 OFFLINE  

daniel3302

    Space Invader

  • Topic Starter
  • 37 posts

Posted Thu May 17, 2018 8:08 AM

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

perfReview

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:

 

Incentive
 
A few weeks later we had to sign release waivers, cause that what corporate lawyers are for.
 
release
 
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.
 
drainCircling
 
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!
 
WereClosedNow

 

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

 






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users