Was The "Running Man" Pre-Stored on the Console?

[SpicedUp!]

I read somewhere that the Intellivision running man was part of the built-in tile set (built in to the console). However when I looked it up and I couldn't see him there. Is he in there at all? A lot of games did seem to use a running dude at least. Thank you.

 

Also is it possible to see a full set of the built-in tiles(cards)? I googled but I couldn't find an image with all of them in.

[mr_me]

The running man graphics is on the cartridge not the grom.  You can see what's on the grom at this link.

http://wiki.intellivision.us/index.php/Graphics_ROM

[SpicedUp!]

Thank you. Oh ok I have seen all of the tiles. I just thought there were more than that. They should have put that running man on there It seemed to be the same running animation on a lot of games

[mr_me]

The graphics are actually different in various cartridges.  Football players have shoulder pads and helmets.  Baseball players have baseball caps.  Their legs might all be the same.

[carlsson]

Each GRAM definition is 4 DECLEs, so even on those 4 kilodecle cartridges, storing an animation of 8 frames only takes 32 DECLEs or 0.78% of the total cartridge capacity. While I'm in the camp that is not super impressed by the GROM line drawing graphics (which other people tell me is because I don't understand how to use them), I think those generic shapes have more use than an animated stick figure.

 

Sure, if there was a super-GROM with multiple banks they could have incorporated more graphics internally. See for example the Sharp MZ computers which have such functionality and include a lot of graphic symbols in the ROM. On the other hand those computers have no GRAM/UDG capacity at all (nor bitmapped mode as far as I understand) so in that case you're stuck with the graphic characters the manufacturer installed. Obviously that is a much worse option, though some of the MZ games look pretty cool despite this limitation.

[+DZ-Jay]

10 hours ago, carlsson said:

While I'm in the camp that is not super impressed by the GROM line drawing graphics (which other people tell me is because I don't understand how to use them).

That is a cheap shot, mate.  I don't recall anybody ever saying that at all.

 

If it was directed at me, the most I remember is you saying something like "I can't see why GROM would be of any value at all," and me responding something to the effect, "some of us find them useful, it depends on your choices and priorities"; and ultimately, "horses for courses."

*shrug*

[carlsson]

More than one person has indicated how useful the graphics symbols are once you have learned how to construct screens based on those. I really tried but find that many basic shapes are missing while other less generic are included.

[+DZ-Jay]

7 hours ago, carlsson said:

More than one person has indicated how useful the graphics symbols are once you have learned how to construct screens based on those. I really tried but find that many basic shapes are missing while other less generic are included.

That's fair.  To each his own, as I've said before.

[Zendocon]

On 11/20/2021 at 7:30 PM, carlsson said:

While I'm in the camp that is not super impressed by the GROM line drawing graphics (which other people tell me is because I don't understand how to use them), I think those generic shapes have more use than an animated stick figure.

I've put them to some use.  The large blue sphere in my standard title animation sequence is composed entirely of GROM characters.  Also in Hunt The Wumpus, the teeth of the wumpus in the "eaten" animation are composed of GROM cards, until both rows of teeth meet in the middle.

[SpicedUp!]

On 11/20/2021 at 9:44 PM, mr_me said:

The graphics are actually different in various cartridges.  Football players have shoulder pads and helmets.  Baseball players have baseball caps.  Their legs might all be the same.

That's true but I thought they might have overlaid a sprite on top of them, although I guess that would be a bit pointless/wasteful in many cases.

 

It does seem like they mainly put in tiles that could be used to make backgrounds (platforms or landscapes) rather than actual game sprites. Probably because they didn't want everyone to be using the same missile or spaceship sprite in their games. Would make games look a bit too identikit.

[mr_me]

It only has eight sprites and with a ball that leaves four on three for team sports.

 

And yes, the Intellivision was about graphics.  Might not look like it now but it was in the 1970s.  The expectation was that each cartridge would have the best graphics possible, so programming graphics for each cartridge was a must.  Common sound effects were implemented in the exec rom however.

[carlsson]

By the way, here are the four pages (4x256 characters) of symbols on the Sharp MZ-700. Plenty of line drawing graphics like the Commodore PETSCII, but also plenty of custom game related symbols, much due to that computer as far as I know has no means of user defined graphics.

http://text-mode.org/?tag=mz-700

[Brian's Man Cave]

I find the grom characters quite useful, especially with the intymapper tool. I made the mouth drawing for my fast food game that way ?

[Mik's Arcade]

45 minutes ago, Brian's Man Cave said:

I find the grom characters quite useful, especially with the intymapper tool. I made the mouth drawing for my fast food game that way ?

I'll have to look more into this IntyMapper tool.  I'm terrible at graphics.

 

I need to take a deep dive on the foreground/backgroud mode because I am 100% clueless on how it works.  I'd love to actually be able to make more colorful graphics and not be limited to the first 8 colors....lol.   There are plenty of demos and code samples out there. It's on the to-do list after I finish this game and figure out how to make music....

[MattPilz]

It is possible you may be thinking of Mattel Aquarius, which has a fixed character set that includes it's own interpretation of the running man. He was used in many Aquarius games because, well, it's almost all developers had to work with for a character.

 

[SpicedUp!]

Matt - Yes maybe that was what I read about. Did they use that man a lot in the games then?

[carlsson]

To be honest, the built-in character set seems to have had quite some clever usage, though I do believe that by reducing block resolution from 80x72 to 80x48 and add a few more other graphic symbols, even more variation could have been had.

https://www.vdsteenoven.com/aquarius/software.php

[Walter Ives]

On 11/20/2021 at 4:30 PM, carlsson said:

Each GRAM definition is 4 DECLEs, so even on those 4 kilodecle cartridges, storing an animation of 8 frames only takes 32 DECLEs or 0.78% of the total cartridge capacity.

Moving objects were generally two cards tall. Each object thus required SIXTEEN decles per frame, so storing each eight-frame animation took 128 decles, or 3-1/8 % of a 4K cartridge. Every cartridge had multiple animation sequences; for example, Baseball had not only the horizontally running man but also the vertically running man, the pitching sequence and the batting sequence. A few percent here and a few percent there quickly added up to 120%.

 

WJI

[Walter Ives]

On 11/20/2021 at 4:30 PM, carlsson said:

While I'm in the camp that is not super impressed by the GROM line drawing graphics (which other people tell me is because I don't understand how to use them), I think those generic shapes have more use than an animated stick figure.

    The Responsible System Architect in his semi-infinite wisdom laid down a rule that GROM would contain only characters that could be used by multiple games. Since the running man animations for all the contemplated games were different, there was no point in storing any of them in GROM. Indeed, since all the object animations for all the cartridges were different, that applied to all other object animations as well—tanks, gorillas, dealer facial expressions, spinning card backs, Cylon fighters, cherries, watermelons, biplanes, racehorses, killer beasties, gunfighters, puppets, Arcadians, backgammon pieces and race cars.

    The situation was complicated by the fact that while all of GROM is addressable in Color Stack mode, only the first 64 characters in are addressable in Foreground/Background mode.

    So what to store in GROM? The first 96 characters were obvious: the ASCII character set. Next were simple slopes: 1:1, 2:1, 3:1, etc. Now what? There just weren't any more identifiable characters that had a significant chance of being used on multiple cartridges. "Ah," said the Responsible System Architect. "How about the strings 'Mattel-Electronics-------presents' and 'Copr @ 19---Mattel'? We don't need access to those strings except during startup." And so it was decreed, and so it was done. And fifty-plus decles were saved from the main EXEC ROM in the process—over one and a quarter percent!

    There was still GROM space left. Then the Responsible System Architect said, "Our backgrounds are made up mostly of characters with very little information content. And most games use Foreground/Background mode, so we need the characters in GRAM, not GROM. So why don't we add a little feature to the EXEC to algorithmically generate 8x8 GRAM characters from two decles of information before starting the game?" And so it was decreed, and so it was done. You can read all the details of the implementation in the seven-page long explanation given in Appendix C of "Your Friend the Exec."

    Where to put that subroutine? The EXEC was already bursting at the seams, so every new feature required the sacrifice of an old one. Well, you only need this particular routine on startup or between game phases, so why not store it in GROM? But GROM is only eight bits wide. And so the Responsible System Architect said, "No problem, we'll store the routine in GROM in packed form and unpack it into the 16-bit System RAM for execution." And so it was decreed, and so it was done. And it worked just fine, and all was well with the world.

    Well, that is to say it worked just fine in the emulator. It so came to pass that, unlike the emulator, the real AY-3-9600 System RAM didn't correctly implement the dreaded cycle ADAR, and the scheme didn't work on the real chipset. When the Great Chip Designer Harrower discovered this he, adhering to the old adage that "to someone with a hammer, everything looks like a nail," resolved the issue by decreeing and doing in typical Great Chip Designer fashion. Thanks to the Great Chip Designer Harrower, the Responsible System Architect was spared the agony and suffering of having to order the excise of the algorithmic GRAM loading capability from the EXEC.

 

    WJI

[Walter Ives]

On 11/21/2021 at 5:31 AM, carlsson said:

More than one person has indicated how useful the graphics symbols are once you have learned how to construct screens based on those. I really tried but find that many basic shapes are missing while other less generic are included.

    You have to design your graphics around the available characters rather than design your graphics first and look for characters that work.

    Did you notice that it takes one card to draw 1:1 slopes, four to draw 2:1 slopes, three to draw 3:1 slopes and four to draw 4:1 slopes and that GROM contains the cards needed to do this? Add the inverse slopes 1:2, 1:3 and 1:4, and some verticals and horizontals and you've pretty much described the graphics characters in GROM.

    In practice you had 48 GRAM characters with which to create your backgrounds (the other 16 were needed for moving objects) and, if you were lucky enough to be able to render your background in color stack mode, you were thankful for each and every additional GROM character you could find to supplement that. If you could find five you were in heaven. [Yes, DZ-Jay, the constraints are more complicated/flexible than that, but that's the gist.]

    Mattel recognized from the start that GROM was not going to be very useful for the level of graphics Mattel envisioned. The lore that Dave James insisted on GRAM makes it sound like he was the only one who noticed or that there were others at Mattel who needed convincing, but that's not at all true. Neither Chang nor Chandler were that dense. APh even recommended bringing the STIC graphics bus to the edge connector so that there could be supplemental GROM in the cartridges—such a GROM could have held all the moving object sequences for a game without having to copy them into GRAM. That could have been done by expanding the cartridge connector from 44 to 56 pins.

 

    WJI

[+DZ-Jay]

2 hours ago, Walter Ives said:

Moving objects were generally two cards tall. Each object thus required SIXTEEN decles per frame, so storing each eight-frame animation took 128 decles, or 3-1/8 % of a 4K cartridge. Every cartridge had multiple animation sequences; for example, Baseball had not only the horizontally running man but also the vertically running man, the pitching sequence and the batting sequence. A few percent here and a few percent there quickly added up to 120%.

 

WJI

Apart from the double vertical resolution, I believe @carlsson also forgot that DECLE originally meant 10 bits, so no packed picture cards.

 

2 hours ago, Walter Ives said:

    The Responsible System Architect in his semi-infinite wisdom laid down a rule that GROM would contain only characters that could be used by multiple games. Since the running man animations for all the contemplated games were different, there was no point in storing any of them in GROM. Indeed, since all the object animations for all the cartridges were different, that applied to all other object animations as well—tanks, gorillas, dealer facial expressions, spinning card backs, Cylon fighters, cherries, watermelons, biplanes, racehorses, killer beasties, gunfighters, puppets, Arcadians, backgammon pieces and race cars.

    The situation was complicated by the fact that while all of GROM is addressable in Color Stack mode, only the first 64 characters in are addressable in Foreground/Background mode.

    So what to store in GROM? The first 96 characters were obvious: the ASCII character set. Next were simple slopes: 1:1, 2:1, 3:1, etc. Now what? There just weren't any more identifiable characters that had a significant chance of being used on multiple cartridges. "Ah," said the Responsible System Architect. "How about the strings 'Mattel-Electronics-------presents' and 'Copr @ 19---Mattel'? We don't need access to those strings except during startup." And so it was decreed, and so it was done. And fifty-plus decles were saved from the main EXEC ROM in the process—over one and a quarter percent!

    There was still GROM space left. Then the Responsible System Architect said, "Our backgrounds are made up mostly of characters with very little information content. And most games use Foreground/Background mode, so we need the characters in GRAM, not GROM. So why don't we add a little feature to the EXEC to algorithmically generate 8x8 GRAM characters from two decles of information before starting the game?" And so it was decreed, and so it was done. You can read all the details of the implementation in the seven-page long explanation given in Appendix C of "Your Friend the Exec."

    Where to put that subroutine? The EXEC was already bursting at the seams, so every new feature required the sacrifice of an old one. Well, you only need this particular routine on startup or between game phases, so why not store it in GROM? But GROM is only eight bits wide. And so the Responsible System Architect said, "No problem, we'll store the routine in GROM in packed form and unpack it into the 16-bit System RAM for execution." And so it was decreed, and so it was done. And it worked just fine, and all was well with the world.

    Well, that is to say it worked just fine in the emulator. It so came to pass that, unlike the emulator, the real AY-3-9600 System RAM didn't correctly implement the dreaded cycle ADAR, and the scheme didn't work on the real chipset. When the Great Chip Designer Harrower discovered this he, adhering to the old adage that "to someone with a hammer, everything looks like a nail," resolved the issue by decreeing and doing in typical Great Chip Designer fashion. Thanks to the Great Chip Designer Harrower, the Responsible System Architect was spared the agony and suffering of having to order the excise of the algorithmic GRAM loading capability from the EXEC.

 

    WJI

 

Very interesting.  Thanks for sharing.

 

2 hours ago, Walter Ives said:

    You have to design your graphics around the available characters rather than design your graphics first and look for characters that work.

 

Although that is true in the general case, it is not so for every case.  I am one of those to which @carlsson was referring.  In the past, I have commented that "designing for GROM" results in scenes with very regular patterns, resembling what we tend to call "programmer art."  This may be perfectly acceptable for some games, but precludes most sense of organic vibrancy in the artwork.

 

I have promoted the opposite idea:  design for art and visual style, then compromise as you need to fit within the limitations.  This requires some clever application of simple techniques, but results in much more organic, fluid, and potentially more interesting scenes.

 

Among these techniques are:

• the alignment of elements to the card grid to exploit color and shape transitions via their boundaries.
• reverse-video (reversing the background and foreground bit patterns) in order to take advantage of the limited Color Stack background color set by hiding stack advances.
• seeking for, and replacing, GRAM pictures with a closely, if imperfectly, matched GROM picture.
• strategically using geometric shapes in GROM to create patterns where regular tiling adds, instead of subtract, from the visual style.

I know I've even used a strategically placed GROM apostrophe as a serif on a GRAM font character.

 

Let's face it, if some people can make beautiful, fluid art with a typewriter, we can use GROM for more than merely platforms and grids.

 

2 hours ago, Walter Ives said:

    Did you notice that it takes one card to draw 1:1 slopes, four to draw 2:1 slopes, three to draw 3:1 slopes and four to draw 4:1 slopes and that GROM contains the cards needed to do this? Add the inverse slopes 1:2, 1:3 and 1:4, and some verticals and horizontals and you've pretty much described the graphics characters in GROM.

    In practice you had 48 GRAM characters with which to create your backgrounds (the other 16 were needed for moving objects) and, if you were lucky enough to be able to render your background in color stack mode, you were thankful for each and every additional GROM character you could find to supplement that. If you could find five you were in heaven. [Yes, DZ-Jay, the constraints are more complicated/flexible than that, but that's the gist.]

 

I think you are making my point.  Also, those five GROM cards may be different in each scene, so thank goodness for the variety.
 

But I'm also obsessive and perfectionist, so the extra level of detail afforded by those extra five GRAM cards now freed, even if small, is significant enough for me.

 

2 hours ago, Walter Ives said:

    Mattel recognized from the start that GROM was not going to be very useful for the level of graphics Mattel envisioned. The lore that Dave James insisted on GRAM makes it sound like he was the only one who noticed or that there were others at Mattel who needed convincing, but that's not at all true. Neither Chang nor Chandler were that dense. APh even recommended bringing the STIC graphics bus to the edge connector so that there could be supplemental GROM in the cartridges—such a GROM could have held all the moving object sequences for a game without having to copy them into GRAM. That could have been done by expanding the cartridge connector from 44 to 56 pins.

 

    WJI

That would have been a treat, for sure!  In the modern Intellivision home-brew programming world, where ROM size is not really a problem, GRAM seems to me to be one of the top limitations of the platform.  (Well, that, and only 8 single-color movable objects.)

 

    dZ. 

[Walter Ives]

27 minutes ago, DZ-Jay said:

But I'm also obsessive and perfectionist, so the extra level of detail afforded by those extra five GRAM cards now freed, even if small, is significant enough for me.

Exactly. And the Responsible Systems Architect was fully cognizant of the value of having those ~five extra cards.

Edited April 25, 2023 by Walter Ives

[mr_me]

2 hours ago, DZ-Jay said:

That would have been a treat, for sure!  In the modern Intellivision home-brew programming world, where ROM size is not really a problem, GRAM seems to me to be one of the top limitations of the platform.  (Well, that, and only 8 single-color movable objects.)

Extending the graphics bus to the cartridge would not only have allowed for cartridge grom but also cartridge gram that could be manipulated with an on cartridge graphics processor.  It's what nintendo did with the famicom.

[+DZ-Jay]

6 hours ago, mr_me said:

Extending the graphics bus to the cartridge would not only have allowed for cartridge grom but also cartridge gram that could be manipulated with an on cartridge graphics processor.  It's what nintendo did with the famicom.

 

That would certainly be cool, but even if no additional GRAM were available, imagine the wondrous possibilities that a custom GROM set would afford:  bespoke character font sets, for starters, to avoid the ugly and blocky built-in set.  (For those of us who detest the built-in font and do everything in our power to avoid it, that's a significant chunk of GRAM freed for scene graphical detail!)

 

Then, of course, even thought it is Graphics ROM, the ability to customize it per program, sort of serves to expand the total number of pictures available to your particular program at once.  You could reserve GRAM specifically for dynamic cards for animations and such.

 

I would be happy as a clam if that were available to me.

 

     -dZ.

 

[+Lathe26]

Take things one step further and imaging having bank-switched Graphics ROM in the cartridge.  🤔