Jump to content
IGNORED

Multicolor mode - the mode everybody wants


Asmusr
 Share

Recommended Posts

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.

  • Like 3
Link to comment
Share on other sites

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/

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by sometimes99er
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

stardust.anim.01.gif

 

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.

 

stardust.anim.02.gif

 

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.

 

stardust.anim.03.gif

 

:)

  • Like 5
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

  • The title was changed to Multicolor mode - the mode everybody wants

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...