DZ-Jay

Looks great!! It seems a little slow to me, though. -dZ.

The size of the segments is measured in Kilo-words (16-bit), while the file size is declared in Kilo-bytes (8-bit). This means that a full 42K (words, not bytes) will take 84Kb on a file. If your file is 42Kb in size, then you're just half-way. When you say that the game "wouldn't load in jzIntv," what specifically happened? Did you get an error message? A few things to keep in mind about the Intellivision memory map: The memory map is fractured into multiple "segments" which are not contiguous. The "ASM ORG" statement is an Assembly Language directive that instructs the assembler to store the program at a specific memory address. The "standard" memory map we use in home-brewed games (and supported by IntyBASIC) is one offering 42K (words, not bytes!) spread throughout 5 segments. If your game program overflows the default segment #0 of 8K (again, words, not bytes!), then you can either optimize it for size, or split the code with "ASM ORG" statements, and put the overflow in another segment. Each procedure and data table must fit within a single segment, so you cannot just split wherever you wish.

The funniest thing is that the "Intellivision II" was not even the "launch" console. It was the cost-cutting follow-up to the original "Master Component." -dZ.

I would imagine that proving "false or misleading description" is a lot easier and requires less effort that proving "copyright infringement." Just because they are slow to address one does not necessarily mean the same for the other. They may not care either way, but I do not think that one follows the other. -dZ.

The Dispatch Table is just an array of addresses to the individual procedures. Basically, you are using the value of a variable as an index into the array, and jumping to that address.

If you're using Assembly Language, then you should be able to do something similar to the "Select Case" or "On X Goto" statement in BASIC dialects. As a matter of fact, such "switch" statements are just very slightly removed from Assembly's dispatch tables. I do not know your specific Assembly dialect, but the typical construct is something like this (in pseudo code): 1. Move In Value to Register 2. Add base address of dispatch table to Register 3. Move In address pointed to by Register (indirect mode) to Program Counter If your language does not support moving an address from a Register to the Program Counter then: 3. Move In address pointed to by Register (indirect mode) to Index Register 4. Branch to Index Register I hope that helps! -dZ.

Ah, but what you didn't know is that these are rare pygmy monkeys, no bigger than a pea. -dZ.

What the heck is a "Launch Edition"? Does it come with a rocket? -dZ.

Sorry, the "stic.txt" is also included as part of the SDK-1600, the distribution of the jzIntv emulator and as1600 assembler. That's actually where it comes from originally. Check the "doc/programming" folder of the SDK-1600 for it. It's my pleasure. By the way, just a word of advice from my experience -- but feel free to let your mileage vary: FG/BG mode allows for more colourful scenes because of its individual application of foreground and background colours per card. However, it limits your graphics to the 64 custom GRAM cards and the "low-end" GROM (mostly ASCII characters). This is suitable for many uses, but the 64 custom cards and ASCII characters limit the graphical expressivity of the scene. Color Stack mode gives you access to the full GROM set, which includes many geometric shapes that can be used judiciously in place of custom cards, extending your graphical abilities of expression. It, however, trades that graphical flexibility for access to colors. Your GRAM cards can use as foreground any of the 16 colors, but the GROM cards are limited to only the lower 8 (the extra bit is used to enable Coloured Squares). The background colour of either is then limited to the four-colour stack, which can only be used in sequence by advancing one slot per card. In my opinion, the biggest limitation of the Intellivision is in its graphics resolution, and how 64 custom cards are hardly enough to express much graphical detail in a 20x12 card scene. Therefore, my preference has always been to use Color Stack and mix my scene with GROM and GRAM cards in interesting ways. Do not be afraid of the 4-color Color Stack itself -- it is much more versatile than most people give it credit for, and many colourful scenes can, and have been, created. All it takes is clear understanding of the techniques and some creativity and hard work. -dZ.

Oh, I forgot a bit of warning. Be aware of the following caveats mentioned in the "stic.txt" document: Colors 0 through 6 display directly from the Primary Color Set. Color 7 actually displays the current color on the top of the color-stack. Colors 0 through 6 behave as "on" pixels that will interact with MOBs. Color 7 behaves as "off" pixels and does not interact with MOBs.

There's also a sample program created by user Catsfolly that attempts to make use of the Coloured Squares mode for making large sprites. It's quite amusing, if limited in its practicality. I'll try to find it in the forum and post a link later. -dZ.

Ah yes, GroovyBee provided that example with some re-usable functions that encapsulate "plotting" bloxels, treating the screen as a large blocky area. -dZ.

Coloured Squares mode is not strictly a screen mode at all, but like you suggest, an extension of Color Stack mode. You apply "Coloured Square" to each individual background card by setting two bits, #11 and #12. Essentially, it takes the place of a Color Stack card with a "pastel" color (values higher than 7, i.e., bit #12 set to "1") on a GROM card (i.e., bit #11 set to "0"). (That means that one of the limitations of Color Stack mode is its inability of using "high color" on GROM cards.) Enabling Coloured Squares on a card treats it as a block of four large pixels (affectionally called "bloxels" for blocky pixels): 8x8 pixel card ____|____ / \ +----+----+ | | | | 0 | 1 | +----+----+ | | | | 2 | 3 | +----+----+ The color and card information fields on the BACKTAB word then split into groups of 3-bits (0 to 7) for the colors of each one of the bloxels (except for the last bloxel, who only gets two bits): 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +----+----+----+----+----+----+----+----+----+----+----+----+----+----+ |Pix3| 1 | 0 | Pix. 3 | Pix. 2 color | Pix. 1 color | Pix. 0 color | |Bit2| | | bit 0-1 | (0-7) | (0-7) | (0-7) | +----+----+----+----+----+----+----+----+----+----+----+----+----+----+ For more information, check out the file "stic.txt" included with the IntyBASIC SDK in the "Documents/Tech" folder. -dZ.

It's up to the programmer to do as he or she wishes. I do not think there's any problem in publishing newer versions while the judges deliberate. It won't influence us. Your mileage may vary, though. -dZ.

Good question. We had a debate over this when discussing the SDK years ago. The consensus then was that, even though sprites are half the resolution of background cards, they are their own thing, and exist in their own space. In other words, that "half resolution" is actually the true vertical resolution of a sprite. Thus, ZoomY2 doubles its vertical resolution, ZoomY4 quadruples it, and ZoomY8 multiplies it by eight. Horizontal resolution, on the other hand, can only be doubled. We didn't wish to complicate matters by trying to describe things in terms of the overall pixel area (and in fact, the STIC nomenclature actually treats the flags as multipliers), so the constants describe zoom factors of the base resolution of a sprite, which just happens to stand at half the height of background cards. I hope that clears it up. -dZ.

By the way, although we will publish the final submitted entries in order for the entire community to experience the games as they were judged, you are all encouraged to continue working on your games and publishing new versions in their respective threads (or create a new thread, if you haven't already). -dZ.

I see a similar trend in some home-brewers' games, especially one-hit wonders who wish to milk more dough out of collectors pockets for their star title. -dZ.

I'll let nanochess respond to the first questions, I can answer this: Yes, that's the idea. -dZ.

Sounds good!