TV_Text Video Memory

CassLan

I'm working on a game called Text Action:

http://forums.parallax.com/showthread.php?p=732155

Its a Text-based side-scroller.

I'm happy with it at this point, however in order for me to take it where it needs to go, I need a faster way to read the contents of the screen (or its memory I suppose) because of collisions and smooth animations with no flickering. I believe if I can directly alter the memory that pertains to what characters are on the screen, then I can get instant scrolling action with no "left-overs" that I have to print blank characters on, becuase in essence the entire screen will have been updated since the contents of the memory locations has been shifted.

This is how I'm thinking about it anyway. I also think this will lead me to much faster routines for characters with multiple frames of animation instead of 6 lines of spin to print the " * " character in the right spot.

I'm sure I'm not using the right words to describe these techniques which are usually used for graphical situations I think.

Is what I'm saying making any sense?

Does anyone know if there are "constant" memory locations for the display of on-screen characters with TV_Text?

Thanks,

Rick

Mike Green

The TV_Text buffer is not in a constant location. It would be very easy though to add a method (routine) to TV_Text that would return the address of the start of the text buffer which is called "screen". Something like this could be added:

PUB screenAddress
   return @screen

CassLan

Thanks Mike,

I'm going·do some memory dumps and see what I can about the structure of this buffer.

Rick

Mike Green

I believe it's straightforward, 13 rows of 40 columns each.

CassLan

Hey,

Thanks for your input. I tried using Gear to look at the memory while I had Characters on screen but it was confusing to me and just took too long, so instead I decided to go the other way around and write to the memory and see what happens. I have posted screenshots. The reference.jpg shows what my screen looks like with no bytefill commands.

Mike Green said...
I believe it's straightforward, 13 rows of 40 columns each.

Well· its close to that. 13 x 40 = 520 so I did this - CASE1:

bytefill (text.screenAddress,2,520)

Result: as you can see from the Case1 Screenshot it only printed to half of the screen.
So I went a head and doubled it - CASE 2:

bytefill (text.screenAddress,2,1040)

Result: and it filled the entire screen with the char that represents $02 according to the character chart.
so far things are pretty good accept, I'm using 1040 Bytes to fill up a space that should only need 520 Bytes of data.
I'm figuring that its 2 byte sequences where one byte is the character and one byte is the color?

so I go ahead and do this - CASE 3:

repeat OSCounter from 0 to 1039 step 2
···· bytefill (text.screenAddress+OSCounter,$10,1)

Result: OK things look good, I'm skipping one byte per write and getting the character I expect as it matches up with the chart etc.

So I'm just trying to find out what the reason for the other byte is as well as how I can set the colors of each of these characters via the memory writing method. so I try this - CASE4:

repeat OSCounter from 0 to 1039 step 2
···· bytefill (text.screenAddress+OSCounter,$10,1)
···· bytefill (text.screenAddress+OSCounter+1,0,1)

I dont know what to make of it, I'll tell you this since I've reached my attachment limit, when I write the second byte as a "1" the screen looks like the reference image, when I write the second byte as a "2" it looks just like CASE 3, when I write the second byte as a "4" it looks like a variation of CASE 4.

Anyone know what this byte is for? Anyone know how to set the colors of the characters using these memory writing methods?

I'm already happy with this method because I can write to the last line of the screen without causing a scroll upward.

Thanks,

Rick

Baggers

CassLan
the screen isn't bytes, it's stored as words ( 16bits )

pppppC10cccccccc

p = Colour palette

C = Character number ( lowest bit ie AND #1 )

c = Character number AND $FE

eg, in the print routine it does this
screen[noparse][[/noparse]row * cols + col] := (color << 1 + c & 1) << 10 + $200 + c & $FE


hope this helps, if you need more help, let me know.

Baggers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

CassLan

Baggers,

Great info! Thanks much, I'm going to make lots of use out of it!!

Rick

Baggers

No probs Rick, anytime, and enjoy [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

CassLan

Baggers said...
(replace this text with what was said)

pppppC10cccccccc

p = Colour palette

C = Character number ( lowest bit ie AND #1 )

c = Character number AND $FE

eg, in the print routine it does this
screen[noparse][[/noparse]row * cols + col] := (color << 1 + c & 1) << 10 + $200 + c & $FE

Thanks again, I think I've almost got it.
I'm not understanding the color situation... Why would they chop off· the most significant 3 bits?
I'm assuming this palette is·pertaining to the·listing (max 8 colors?) of 8 defined colors consisting of a Fore and a Background color?
Or is it some other means to derive a color.

lastly why the C and also the cccccccc?
You already have the 8 bits (cccccccc) you need so why the C?

Thanks,

Rick

Mike Green

This is kind of complicated. Look at the description of the font tables in ROM. You'll see that there are two overlapped characters entries per 16 x 32 bit cell. The LSB of the character code is split out for this reason. The color palette table entry is indexed by the color palette number in the 16 bit value. This entry consists of 4 bytes and is used for the odd/even characters' foreground and background colors.

If you can go through the code in the video driver, you'll see how the various bits are moved around and used to index into the ROM font tables.

CassLan

Thanks Mike,

My hope with understanding this is not only for the game, but for other text/ascii based programs that may have layers or moveable windows like in the late DOS days.
I'd LOVE to see a QuickBASIC style IDE running on the Prop FOR the Prop (or another Prop).

Rick

Oldbitcollector (Jeff)

Actually, I'm working on that, but my Full Page Text editor has a serious flaw
that I haven't managed to work my brain around. (Anyone else is welcome to try!)

I'm thinking that if I used Propellent and a script to catch the spin file (text) from
the Propeller's editor (a small spin file) then I could compile and send it back
to the prop's memory.

This doesn't eliminate the need for a PC running Propellent, but would be a
very cool step forward!

But I've got to resolve some serious issues with my Full Page text editor first.
(Although I might write a simpler editor just to see if I can make it work.)

OBC

Edit: Sorry if the reply hi-jacked your thread...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange

stevenmess2004

Sorry for hi-jacking the thread more. If you want I'll ask this in a new thread.

OBC, whats the problem with your Full Page Text editor?

Oldbitcollector (Jeff)

I've replied in the "Full Screen Text Editor" thread...

[noparse]:)[/noparse]

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange