Half bitmap mode

[Willsy]

Is it possible to have a bitmap screen whereby the colour data covers 1 8x8 pixel square? I'm looking at shoehorning bitmap mode in. Any suggestions for bitmap table layout would be greatly received. I think there are only a few combinations with bitmap mode.

 

IIRC half-bitmap mode has less colour information, which might make a useful first step for me.

 

Thanks

 

[Asmusr]

There is no mode like on the ZX Spectrum where you have a full bitmap with 8x8 color attributes. Half bitmap mode is more like normal graphics mode, i.e. only 256 characters on the screen, but with extended color information (individual background/foreground per pixel line). This reduces the memory use from 12K to 4K compared to full bitmap mode. Note that in half bitmap mode you can only use 8 sprites.

[Willsy]

Wow. How on earth do I arrange the various tables in VDP for bitmap mode?

[+adamantyr]

There's a combination you can use (detailed on the TI-99/4a Tech Pages) that describes how to set both bitmap AND text mode at the same time and get a two-color bitmap mode on the entire screen.

 

The only issue with it is that you technically only have 240x192 pixels (the first and last columns are ignored) and you have to do some tricky math with 6-pixel width characters. I'm not sure anyone's really tested this one out thoroughly to find all the bugs...

[+Vorticon]

Wow. How on earth do I arrange the various tables in VDP for bitmap mode?

 

I learned how to use bitmap mode by reading Bruce Harrison's Art of Assembly. His writing style is down to earth, understandable, with plenty of coding examples. He covers this topic in 1 or 2 articles I believe. The whole set of articles is under the Development Resources thread.

[+Lee Stewart]

Wow. How on earth do I arrange the various tables in VDP for bitmap mode?

 

There's a discussion in §21.5 “BIT-MAP MODE”, pp. 334 – 337 in the E/A Manual. Also, check Chapter 6, “An Introduction to Graphics” in my fbForth 2.0 Manual. fbForth (and TI Forth before it) have the following bitmap modes: Graphics2 (all bitmap), Split (top 2/3, bitmap; bottom 1/3, “text” à la graphics mode [8 lines, 32 columns]) and Split2 (top 1/6, “text” à la graphics mode [4 lines, 32 columns]; bottom 5/6, bitmap). You should be able to set up 32 sprites. The sprite limitation is on the available patterns: 59, with allowable open files = 2, and 124, with allowable open files = 1. There is no sprite automotion. Split2 mode only has room for font character patterns 0 – 127 for the text portion of the screen.

 

Here is the fbForth 2.0 ALC for all screen modes:

 

fbForth103_VDPModes.a99

 

The problem you will have with TurboForth is with the space in VRAM used for Forth blocks buffers. Bitmap mode uses nearly all of VRAM space. fbForth 2.0 has only 750 bytes of free VRAM space in bitmap mode.

 

...lee

[Willsy]

 

The problem you will have with TurboForth is with the space in VRAM used for Forth blocks buffers. Bitmap mode uses nearly all of VRAM space. fbForth 2.0 has only 750 bytes of free VRAM space in bitmap mode.

 

...lee

Thanks for this! Yes, block buffers are a problem for this. I think I'll just leave it as it is though - if you access blocks while bitmap mode is active you'll hose the screen. Hey ho. The block system will work just fine - it doesn't know anything about bitmap mode!

 

Looks like I have a lot of homework to do!

[senior_falcon]

For "The Missing Link" I discovered a hybrid half bitmap mode which uses 6K for the pattern tables and only 2K for the color table. You get full bitmap control over every pixel but can only use two colors. (you could probably use more colors if you were clever) I used this to gain 4K of stack space which is helpful when running bitmap with XB. If you are interested I can look up the information on how to set this up.

[Asmusr]

There's a combination you can use (detailed on the TI-99/4a Tech Pages) that describes how to set both bitmap AND text mode at the same time and get a two-color bitmap mode on the entire screen.

 

The only issue with it is that you technically only have 240x192 pixels (the first and last columns are ignored) and you have to do some tricky math with 6-pixel width characters. I'm not sure anyone's really tested this one out thoroughly to find all the bugs...

 

I don't think the F18A is implementing this mode.

[RXB]

Thanks for this! Yes, block buffers are a problem for this. I think I'll just leave it as it is though - if you access blocks while bitmap mode is active you'll hose the screen. Hey ho. The block system will work just fine - it doesn't know anything about bitmap mode!

 

Looks like I have a lot of homework to do!

I had thought ahead for RXB and reserved 32K of RAM from the SAMS for future use.

1 8K bank of lower 8k and 24K of upper RAM banks.

[Willsy]

For "The Missing Link" I discovered a hybrid half bitmap mode which uses 6K for the pattern tables and only 2K for the color table. You get full bitmap control over every pixel but can only use two colors. (you could probably use more colors if you were clever) I used this to gain 4K of stack space which is helpful when running bitmap with XB. If you are interested I can look up the information on how to set this up.

Yes please!

[senior_falcon]

OK, here is what I know about this:

In The Missing Link the VDP registers are as follows, starting at R0:

R0 >02 set the bitmapped mode

R1 >E0 the normal settings for R1

R2 >0E screen image table at >3800

R3 >7F color table is at >0000

R4 >07 pattern descriptor table is at >2000

R5 >78 sprite attribute list is at >3C00

R6 >07 sprite descriptor table is at >3800

R7 >17 background color

These register values give the normal full bitmapped mode, although I have reversed the color table and the screen image table compared to the usual practice.

If you change R3 to >1F then the color table still starts at >0000 but only uses the first >800 bytes. Those >800 bytes are used by the top third, the middle third, and the bottom third of the screen. But the pattern table still uses >1800 bytes which means that every pixel can be unique. When initializing, Missing Link sets all >800 bytes of the color table to the same foreground and background color.

 

(edit) This still lets you use all 32 sprites. As I remember, you could use different values for R3 which would let you use different parts of the color table like the first >800 bytes to set the colors. You could try >3F and >FF to see what happens.

Edited September 10, 2015 by senior_falcon

[Asmusr]

The different hybird modes are described on Thierry's page:

http://www.unige.ch/medecine/nouspikel/ti99/tms9918a.htm#hybrid%20bitmap

 

The mode with one color table and three pattern tables is the one I use in Titanium and Bouncy.

[RXB]

OK, here is what I know about this:

In The Missing Link the VDP registers are as follows, starting at R0:

R0 >02 set the bitmapped mode

R1 >E0 the normal settings for R1

R2 >0E screen image table at >3800

R3 >7F color table is at >0000

R4 >07 pattern descriptor table is at >2000

R5 >78 sprite attribute list is at >3C00

R6 >07 sprite descriptor table is at >3800

R7 >17 background color

These register values give the normal full bitmapped mode, although I have reversed the color table and the screen image table compared to the usual practice.

If you change R3 to >1F then the color table still starts at >0000 but only uses the first >800 bytes. Those >800 bytes are used by the top third, the middle third, and the bottom third of the screen. But the pattern table still uses >1800 bytes which means that every pixel can be unique. When initializing, Missing Link sets all >800 bytes of the color table to the same foreground and background color.

 

(edit) This still lets you use all 32 sprites. As I remember, you could use different values for R3 which would let you use different parts of the color table like the first >800 bytes to set the colors. You could try >3F and >FF to see what happens.

How much room is left for XB variables in this set up?

Can not be much space left.

[senior_falcon]

How much room is left for XB variables in this set up?

Can not be much space left.

You're probably thinking about stack space. Numeric variables are kept in RAM, so there is the same amount of room for your program and its variables. Bitmap mode does use up most of the VDP ram, hence there is not much stack space, which is where variable names (both string and numeric), subroutine names and the actual strings are kept. If you use full color mode there are only 1460 bytes of stack available (with CALL FILES(1). If you are in the "monocolor" mode there are 5212 bytes of stack available. There is a section in the manual with tips on how to save stack space. Proof of the pudding is that TMLDEMO is 24K long and works fine with only 1460 bytes of stack.

 

@Rasmus - good link to the ins and outs of bitmap. I found this hybrid mode almost by accident by experimenting with different values, but your list is WAY more complete!

[senior_falcon]

Rasmus, if I understand Thierry's information correctly, it is possible to have the 64 bytes starting at >0000 control the colors of all the characters in a bitmapped screen. (This assumes the color table starts at >0000 and the pattern table starts at >2000). If true, this goes way beyond what I did by using >800 bytes to control the colors in the 2 color mode. If true this sure frees up a lot of space in the VDP if you don't mind using only 2 colors.

[Tursi]

It's true (IIRC), my bitmap test application verifies most of those settings work on hardware.

[Asmusr]

As I understand it, with a color table smaller than 2K the patterns will also be duplicated, so it's no good for practical use. For instance, if you reduce the color table to 1K, the patterns from 128-255 will be duplicates of the patterns from 0-127 so you will no longer have a full bitmap screen.

[Asmusr]

It's true (IIRC), my bitmap test application verifies most of those settings work on hardware.

 

Very interesting to watch this video again. It would be great to see a follow up video that shows that with one color table and three pattern tables the sprite duplication problem disappears. I guess that it's the pattern table masking that's causing that problems, so two color tables would also be OK but not two pattern tables?

 

I don't have a real 9918A to test on - I only have a 9929A console where I guess the sprite problems are the same - but who knows?

 

It's a shame that emulators, not even MESS , emulates this issue since half bitmap mode appears to be such a useful mode. It was a big blow for me when I developed Titanium and discovered I had to reduce the update speed by half to make it work on real hardware.

 

Apparently Thierry Nouspikel was not aware if this issue, or I'm sure he would have documented it.

[Tursi]

 

Very interesting to watch this video again. It would be great to see a follow up video that shows that with one color table and three pattern tables the sprite duplication problem disappears. I guess that it's the pattern table masking that's causing that problems, so two color tables would also be OK but not two pattern tables?

 

I don't have a real 9918A to test on - I only have a 9929A console where I guess the sprite problems are the same - but who knows?

 

It's a shame that emulators, not even MESS , emulates this issue since half bitmap mode appears to be such a useful mode. It was a big blow for me when I developed Titanium and discovered I had to reduce the update speed by half to make it work on real hardware.

 

Apparently Thierry Nouspikel was not aware if this issue, or I'm sure he would have documented it.

 

Well, you can run the software and see. The 9928 does reproduce the issue (it was on the ColecoVision I first learned about it), so I expect that the 9929 would as well. I thought that combination was in the video though...

 

I took a stab at understanding it back when I wrote that, but I didn't get it. If we sat down and documented the sprites for each the bit patterns it probably would come into light.

[Opry99er]

The SPRITE behavior in that video is interesting... To say the least.

 

Wonder if it could be utilized in a game application... Even as a 'ghosted' enemy with unnatural and unpredictable behavior...

[RXB]

Gawd I miss my 9958 VDP TIM card. 256 Colors and 4 times larger screen with 4 time more pixels.

256 x 212 x 256 colors

256 x 424 x 256 colors

512 x 212 x 16 colors of a pallet of 256 colors.

512 x 424 x 16 colors

512 x 424 x 16 colors of a pallet of 256 colors.

 

So sad that we do not see anyone making these cards or emulation other than MESS.

[Asmusr]

I ran Tursi's BMPTEST program on my 9929A console last night, and I can confirm that the number of color tables did not seem to have have any affect on the sprite duplication (1-3 are fine) whereas either 1 and 2 pattern tables triggered the problem. Next step is to change the program to display a single sprite controlled by the joystick, this will help to describe the problem in more detail.

[artrag]

IIRC sprite planes 0-7 are immune by the cloning.

[RickyDean]

I ran Tursi's BMPTEST program on my 9929A console last night, and I can confirm that the number of color tables did not seem to have have any affect on the sprite duplication (1-3 are fine) whereas either 1 and 2 pattern tables triggered the problem. Next step is to change the program to display a single sprite controlled by the joystick, this will help to describe the problem in more detail.

The 9929A, is that the chip that was in the Coleco? If it is, I have one in one of my TI's and if I remember all I could get was a clear nice grayscale screen, good for text. No colors. If it is the same chip, where would I get the info to cause it to produce in color. Thanks for any info.