Character sets in assembly?

[jchase1970]

In standard mode we can have 3 sets of 256 characters for a total of 768 characters?

 

We can write all 768 characters to the screen?

[+adamantyr]

In standard mode we can have 3 sets of 256 characters for a total of 768 characters?

 

We can write all 768 characters to the screen?

 

No, there's only a maximum of 256 characters in standard mode.

 

In bitmap mode, you do have 768 characters, but each set is restricted to 1/3 of the screen, so you technically only have 256 characters, you can just have them vary between the three screen sections.

 

Adamantyr

[jchase1970]

In standard mode we can have 3 sets of 256 characters for a total of 768 characters?

 

We can write all 768 characters to the screen?

 

No, there's only a maximum of 256 characters in standard mode.

 

In bitmap mode, you do have 768 characters, but each set is restricted to 1/3 of the screen, so you technically only have 256 characters, you can just have them vary between the three screen sections.

 

Adamantyr

 

Ah that must have been where I remember that 768 from.

[sometimes99er]

In ordinary graphic mode we often have the character patterns stored in the VDP. While our game is running, we only need to update one byte in the screen image table to change a character on the screen.

 

In bitmap mode, one can use a similar method (as mentioned in this thread). There would be pros and cons.

 

In bitmap mode, one could however think of the VDP as only holding a display (the screen). All characters could be held (during gameplay) outside the VDP for example in ROM, RAM or GROM. You could have more than 768 characters - of course the screen can only show 768. Any of the 768+ characters can be displayed anywhere on screen. You would have to move 16 bytes, pattern and colors from outside the VDP, to update one character on the screen. Yes, it's about 16 times slower to move 16 bytes than one byte. Again pros and cons. If you have been putting the same character to many different screen locations using this method, you can't change them all instantly like in ordinary graphic mode (moving only 8 bytes to update the pattern). However if you want to draw a thin line (pixels) through 43 characters on screen, you just do it (having to respect color restrictions one way or another). Pros and cons.

 

In the popular hybrid bitmap mode, often named half bitmap, it's much like working with ordinary graphic mode, only thing is, that each of the 256 characters has individual colors - a foreground and a background color for each scanline/horizontal line. That's actually each byte of pattern having one byte of color (foreground and background).

 

 

Edited July 30, 2010 by sometimes99er

[marc.hull]

If you have been putting the same character to many different screen locations using this method, you can't change them all instantly like in ordinary graphic mode (moving only 8 bytes to update the pattern).

 

 

 

This isn't quite true. It is possible the change the pattern of many screen locations instantly in bit map mode. The fact is that there is no bit map mode (in the traditional sense) on the TI. As far as the patterns are concerned "bit map mode" is almost identical to graphics 1 mode. The difference being that the PDT is 3 times the size (3 tables really) and the SIT is divided into thirds (3 smaller SIT's.) If you change the pattern of any character then that corresponding character in the SIT will change regardless of it's location. Hmmmm that even confused me....

 

Lets say you write the value 65 to every byte in the first third of the screen. Any change in the first PDT that effects the character 65 will effect every character on the first third of the screen but not in the other two thirds.

 

A good way to look at it is this. Consider that there are 3 SIT's and 3 PDT's. The screen just has the SIT's stacked one atop the other. When you change a bit you are simply redefining a character and this redefinition effects every position of the corresponding character on the corresponding SIT.

 

I really hope that made sense

[sometimes99er]

1)

In bitmap mode, one can use a similar method (as mentioned in this thread). There would be pros and cons.

 

2)

In bitmap mode, one could however think of the VDP as only holding a display (the screen). All characters could be held (during gameplay) outside the VDP for example in ROM, RAM or GROM. You could have more than 768 characters - of course the screen can only show 768. Any of the 768+ characters can be displayed anywhere on screen. You would have to move 16 bytes, pattern and colors from outside the VDP, to update one character on the screen. Yes, it's about 16 times slower to move 16 bytes than one byte. Again pros and cons. If you have been putting the same character to many different screen locations using this method, you can't change them all instantly like in ordinary graphic mode (moving only 8 bytes to update the pattern). However if you want to draw a thin line (pixels) through 43 characters on screen, you just do it (having to respect color restrictions one way or another). Pros and cons.

I was trying to hint two different ways to go about bitmap. 1) One a bit like ordinary graphic mode using the SIT actively, 2) the other leaving the SIT at an initialized state (>00 through >FF repeated 3 times).

 

[sometimes99er]

The fact is that there is no bit map mode (in the traditional sense) on the TI.

Well, it's called bitmap mode. There might not be a bitmap as one would like it, but if you initialize the SIT (screen image table) with >00 through >FF repeated 3 times, and then forget about the SIT - then the PDT (pattern descriptor table) is indeed a bitmap (=any pixel seen on screen can be set and reset) ? If this is not true, then the Amiga didn't have bitmaps either.

 

Edited August 2, 2010 by sometimes99er

[marc.hull]

1)

In bitmap mode, one can use a similar method (as mentioned in this thread). There would be pros and cons.

 

2)

In bitmap mode, one could however think of the VDP as only holding a display (the screen). All characters could be held (during gameplay) outside the VDP for example in ROM, RAM or GROM. You could have more than 768 characters - of course the screen can only show 768. Any of the 768+ characters can be displayed anywhere on screen. You would have to move 16 bytes, pattern and colors from outside the VDP, to update one character on the screen. Yes, it's about 16 times slower to move 16 bytes than one byte. Again pros and cons. If you have been putting the same character to many different screen locations using this method, you can't change them all instantly like in ordinary graphic mode (moving only 8 bytes to update the pattern). However if you want to draw a thin line (pixels) through 43 characters on screen, you just do it (having to respect color restrictions one way or another). Pros and cons.

I was trying to hint two different ways to go about bitmap. 1) One a bit like ordinary graphic mode using the SIT actively, 2) the other leaving the SIT at an initialized state (>00 through >FF repeated 3 times).

 

 

I got you brother, don't want to start a war here. It was worth the addendum though as you yourself stated moving one byte in the SIT is much faster than moving 8 bytes in the PDT and it can be done easily. As far as my bit map comment. Yea I agree it is our bit mapped mode but not as we would like it especially considering the arrangement of the bits in the PDT relative to the SIT.