Multicolor mode - the mode everybody wants

[Asmusr]

 

Is it really that bad, or could it be use for a game? Perhaps even for vector graphics?

 

Multicolor.zip

 

Edit: One of the source files (map.a99) was missing. This is included here:

Multicolor.zip

Edited December 10, 2022 by Asmusr

[+OLD CS1]

I think multi-color is exceptionally portable and usable. In my earlier trials with 9900 programming on the Mini Memory, I converted a number of BASIC sample programs for the Atari and Apple to the TI using multi-color mode. It is very similar to the Apple LORES mode. I see great and surprising potential in the right hands.

 

IIRC, MC mode allows for sprites. Given that, you could use a multi-color background for something like Xevious, Zaxxon, or even 1942 where the ground and water do not really need to be in high resolution, but the game pieces can be. Might make text difficult, though, but with a good guess as to the raster position you could quickly shift mode and name table to give a couple of lines of text.

[ti99_forever]

I remember writing assembly routines for use with XB giving MC mode. It gave VLIN, HLIN and a DRAW that used Bresenham's routine.

[am1933]

Was the Lines demo that came with the Mini Memory module in multicolor mode?, it's been so long since I've seen it. If so-would it not provide a decent starting point for a Qix type game?

[+hloberg]

Lines was bit-map, I believe.

[majestyx]

After viewing the demo, I thought exactly what OLD CS1 said - it looks a lot like the Apple ]['s LORES mode, although I don't believe it could scroll, or at least not that smoothly (it's been at least 2 decades), plus the Apple didn't have sprites. What's funny is that a board released for it used a TI TMS 9918A chip which of course did have sprites.

 

http://www.bluerwhite.org/2012/08/sprite-boards/

[+Vorticon]

Rock Runner by Eric LaFortune was written in multicolor mode and it is an excellent piece of software.

Rockrun.zip

[+Lee Stewart]

Multicolor (MC) mode is available in fbForth (and its predecessor, TI Forth) with MULTI , MINIT and MCHAR . Sprites can also be used, though there never was any guidance in TI Forth and I have not done anything with them in fbForth. Once the 4A is in MC mode, you can place a 4x4 MC character on the screen at any MC column (0 – 63) and row (0 – 47) with MCHAR , which expects the color, column and row of the "character" on the stack. I have actually had looking into MC sprites in mind for a long time. Once I get the fbForth 2.0 cartridge off the ground (soon), I may look into MC sprites a little more closely.

 

...lee

[Tursi]

Rock Runner by Eric LaFortune was written in multicolor mode and it is an excellent piece of software.

 

This is "half-bitmap". Multicolor is the 64x48 mode.

[potatohead]

Do Flappy Bird with it.

[TheMole]

Well, on the MSX you have Insect's Planet...

[TheMole]

Having said the above, your demo does look quite smooth. A multicolor nametable is roughly 1.5kb (64 x 48 / 2), right? Are you uploading a completely new one every frame for your demo? Are you getting 60fps with that?

[Asmusr]

Having said the above, your demo does look quite smooth. A multicolor nametable is roughly 1.5kb (64 x 48 / 2), right? Are you uploading a completely new one every frame for your demo? Are you getting 60fps with that?

 

Yes I'm updating the entire table, but it's only 30 FPS. It takes about 61000 clock cycles to update the table, and it would have to be reduced below 50000 for 60 FPS. But I think I'm already doing it the fastest way possible with 8 consecutive MOVBs from PAD. Anyway, in a game you would probably want 15 FPS or even lower.

[Asmusr]

Do Flappy Bird with it.

 

Been there, done that..

 

[senior_falcon]

Nice demo, Rasmus! I have always thought that multicolor mode would be a good fit for Conway's game of Life. Comparing with graphics mode there are 4 times as many cells and the TI should be able to keep up with that, especially with some clever coding. Often Life changes the color to show the different generations and that too would work well in multicolor mode. Of course, the bitmapped mode would be best, but with 64 times the number of cells there would be many seconds for each screen update and that seems too slow to me.

[+Vorticon]

 

This is "half-bitmap". Multicolor is the 64x48 mode.

 

Ah yes. My mistake...

[artrag]

IMHO the critical problem is the vram layout of multicolor mode.

It seems very hard to be efficiently exploited: it is not a true bitmap, but 4x4 tiles are too low res to be used as tiles...

Maybe I am missing something but willing to have low res images one can use screen 2 splitting in two columns of 4 pixel the tiles: you get a resolution of 64x192 and you still can move tiles to scroll

[sometimes99er]

IMHO the critical problem is the vram layout of multicolor mode.

It seems very hard to be efficiently exploited: it is not a true bitmap, but 4x4 tiles are too low res to be used as tiles...

Maybe I am missing something but willing to have low res images one can use screen 2 splitting in two columns of 4 pixel the tiles: you get a resolution of 64x192 and you still can move tiles to scroll

It depends on what you want. Factors are speed, layout, access (auto-increment), memory, fps (frames per second), size and other stuff and constraints to do/have. I probably missed something.

 

I most definitely think it is other factors than "vram layout" that became critical factor when choosing mode. I think the "low resolution" was what most often let it down. One should of course not forget the sprite overlay option.

 

The mode was definitely more attractive before the 9918A came out, but then the 9918 probably, overall, sold less than 2 percent compared to the 9918A (remember other systems used the latter).

 

Edited August 7, 2014 by sometimes99er

[+OLD CS1]

I do not want to make promises to break, but if I can find them in my storage diggings, I have some rather intricate designs I made many moons ago for multi-color mode, inspired to some degree by BBS game titles and the associated Commodore graphics screens, and some sci-fi of the era. I even toyed with a honey-comb design (something like in Insect's Planet above) for one of the COMPUTE! conversions. The simplicity of the mode intrigued me greatly at the time and I had hoped to exploit it while I was learning on the Mini Memory. I will make a concerted effort while I am in there this weekend to find and scan them.

[Asmusr]

IMHO the critical problem is the vram layout of multicolor mode.

It seems very hard to be efficiently exploited: it is not a true bitmap, but 4x4 tiles are too low res to be used as tiles...

Maybe I am missing something but willing to have low res images one can use screen 2 splitting in two columns of 4 pixel the tiles: you get a resolution of 64x192 and you still can move tiles to scroll

 

An advantage of multicolor mode over bitmap mode is that you can easily double buffer the whole screen. And it uses only 1536 bytes compared to 12K of full bitmap mode. But the mode would definitely be easier to use and understand if 8 bytes of the pattern table corresponded to 16 multicolor pixel in a row instead of 8 rows of 2 columns.

 

The standard name table layout, which I also use in the demo (see http://nouspikel.group.shef.ac.uk/ti99/tms9918a.htm#Multicolor), is not optimal for calculating the address of a pixel.

>00 >01 >02 ...
>00 >01 >02
>00 >01 >02
>00 >01 >02
>20 >21 ...
>20 >21
>20 >21
>20 ...
>30

With this layout the address of a pixel (x [0-63], y [0-47]) can be calculate as: (x >> 1) << 3 + (y >> 3) << 8 + (y & 7). Note: >> and << are shift operations.

 

 

If you use this name table layout instead you will waste a bit of VDP RAM, but the calculation will be much simpler: (x >> 1) << 6 + y

>00 >08 >10
>00 >08 >10
>00 >08 >10
>00 >08 >10
>01 >09 ...
>01 >09
>01 >09 
>01 ...
>02

[artrag]

With screens of 1536 one could store many frames of an animated background (e.g. a tunnel) and get animation by pointing to the different frames

 

Amiga Stardust used only 6 frames of animation for the tunnel

http://www.codetapper.com/amiga/sprite-tricks/stardust/

[Asmusr]

With screens of 1536 one could store many frames of an animated background (e.g. a tunnel) and get animation by pointing to the different frames

 

Amiga Stardust used only 6 frames of animation for the tunnel

http://www.codetapper.com/amiga/sprite-tricks/stardust/

 

Cool. How do we make the 3D graphics? I don't know any tools that can produce low-res indexed color 3D graphics, but I have often wanted one, for instance to rotate a sprite in 3D.

[artrag]

This could be of some help, but it is far from being a tool

http://lodev.org/cgtutor/tunnel.html

[sometimes99er]

I took the Stardust 6 frame animation and did a quick (and dirty) reduction. Better care of stretching, equalizing, mapping etc. could/should produce better results. Since the mode offers more than 2 colors, that's what I went for here.

 

 

And then reducing further to get what I think would be a better background animation from the above. Probably not the best but at least shows that a certain 3D-effect can be obtained.

 

 

Going for only 2 colors could make one go back to standard graphic mode and maybe alter the 2 by 2 pixel definition to get maybe an overall grid effect. It would only need 16 character patterns. You'd have plenty for score, scroll effects, colors and more. 6 frames of 768 bytes fits fine.

 

 

[+Vorticon]

How fast can the entire multicolor screen be updated? The way I see it, the best and simplest use of the multicolor mode would be as a scrolling background for a sprite based game as long as it's not too choppy. What is generally considered the minimum acceptable frame rate which does not degrade the user experience?