What do tiles represent in terms of characters?

LoopyByteloose

Are tiles equal to one character image each?
I am trying to grasp how one chooses 'x_tiles' and 'y_tiles' in TV Terminal.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)

······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

cgracey

Tiles are either 16x16 pixel blocks or 16x32 pixel blocks which have one color pattern associated with them. This is explained tersely in tv.spin and vga.spin where the screen memory is mentioned. The Propeller's internal character set contains 16x32 pixel blocks for each character. This means that each character requires 32 scan lines to display. On a TV, this only gives you 6 visible rows of text without interlacing·- that's why interlacing was used.

If we want to stay in the flicker-free progressive mode (non-interlaced), and get a decent number of rows on the screen, then we need a more compact font. The current ROM font of 256 characters (each 16x32 pixels) fills 16KB of ROM - half the ROM!. An 8x8 character set, limited to characters $20-$7E (95 total) would take only 760 bytes! This could easily show 26 rows on·a tv (52 rows interlaced). It would look much coarser, though. I'm thinking that by loading the font into the COG, itself (since it would fit), we could streamline the scan-line construction so that we could·achieve a full 640x480 VGA mode with 80x60 characters. That would be great for text editing. Maybe I'll do this next.

Kramer said...
Are tiles equal to one character image each?
I am trying to grasp how one chooses 'x_tiles' and 'y_tiles' in TV Terminal.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

rokicki

Wow, that would be excellent! I was just gonna try building that 8x8 font myself. It's hard to think
that my mind runs along the same channels as yours.

cgracey

Well, I looked into it and it seems to me that things cannot be sped up much faster than vga.spin already goes. It all comes down to how fast can you prepare data for the WAITVID instructions. It doesn't matter if you have 32 bits at a whack or just 8 bits - it comes down to reading in a character, shifting it left, adding in the chr-line offset, reading the pixel pattern, and then doing the WAITVID. This is hard to speed up. Going to internal COG memory doesn't do anything, because it takes more clocks to break down the bitfields than it does to just read exactly what you want from the main memory via a RDBYTE, RDWORD, or RDLONG instruction. You could use multilple COGs to prepare scanlines to get a big improvement, but using a single COG, it's already about as fast as it could possibly be.

rokicki said...
Wow, that would be excellent! I was just gonna try building that 8x8 font myself.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

rokicki

I wonder if you could pipeline it, so you do multiple rows at a time with respect to preparing the data to be sent out,
all the while shifting out data from the previous row (where the row data is cog memory). That is, you could prepare
scanlines 4, 5, 6, and 7 all at the same time, while shifting out scanlines 0, 1, 2, and 3.

In any case, I want the 8x8 for tv anyway where the timing is not quite so tight.

Kaos Kidd

If I'm understand this right, it's not just the size of the tiles, it's also becomming a speed issue as well?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

parsko

Is my girlfriend writing posts here?!?

Chris Savage

parsko,

·· Perhaps you should ask her directly so we can keep this thread on topic.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com