Why does the tv_terminal take so much memory?

CJ

while the graphics demo takes so little

graphics demo 1500 longs of code and 226 longs of variables vs. terminal 1200 of code and 3500 for variables

just wondering why.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?

I've killed a fly with my bare mind.

cgracey

The graphics_demo actually took a lot more, but you didn't see it in the compiler's bar graph because it was not reserved using VAR statements. Instead, it used a _stack directive to reserve a big chunk of RAM·biased from the end of memory ($7FFF downward):

CON

· _stack = ($3000 + $3000 + 100) >> 2·· 'accomodate display memory and stack

The $3000's are for the display buffers (in bytes). One of the $3000's is for the working bitmap, and the other $3000 is for the display bitmap, so the image is double-buffered, making it flicker-free. The $100 is for the initial COG's stack space. These all get shifted right by 2 (>>2) to get the equivalent long count.

CJ said...
while the graphics demo takes so little

graphics demo 1500 longs of code and 226 longs of variables vs. terminal 1200 of code and 3500 for variables

just wondering why.

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


Chip Gracey
Parallax, Inc.

lardom

Chip Gracey (Parallax) said...

The graphics_demo actually took a lot more, but you didn't see it in the compiler's bar graph because it was not reserved using VAR statements. Instead, it used a _stack directive to reserve a big chunk of RAM·biased from the end of memory ($7FFF downward):

CON

· _stack = ($3000 + $3000 + 100) >> 2·· 'accomodate display memory and stack

The $3000's are for the display buffers (in bytes). One of the $3000's is for the working bitmap, and the other $3000 is for the display bitmap, so the image is double-buffered, making it flicker-free. The $100 is for the initial COG's stack space. These all get shifted right by 2 (>>2) to get the equivalent long count.

CJ said...
while the graphics demo takes so little

graphics demo 1500 longs of code and 226 longs of variables vs. terminal 1200 of code and 3500 for variables

just wondering why.

I was browsing near the final pages of the forum to see what was being discussed. Please help me understand what was being said. If you think I would do better to make a focused study of propeller architecture at least I will know where to find the answers.

1)Chip replied; "double-buffered, making it flicker-free." Has eeprom memory been reserved here? Why does 'buffering' make something 'flicker-free'?

2)What is a compiler's bar graph?

jazzed

lardom said...

I was browsing near the final pages of the forum to see what was being discussed. Please help me understand what was being said. If you think I would do better to make a focused study of propeller architecture at least I will know where to find the answers.

1)Chip replied; "double-buffered, making it flicker-free." Has eeprom memory been reserved here? Why does 'buffering' make something 'flicker-free'?

2)What is a compiler's bar graph?

1) With double buffering, the TV screen can display one buffer that does not change while the program is changing the other buffer (the source of changes can be EEPROM or any other memory). Once the other buffer is ready, the TV screen can be "switched" to display it. The result is a smoothly updated display for animations, etc....

2) In the Propeller Tool, you can find out how much free HUB memory is available in the Propeller by compiling the program with the F8 key. F8 causes a window to display that shows a color coded bar graph of HUB memory usage. The buffer may not be shown in the graph as Chip explains unless "stack" space is reserved.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers? Not available at this time since I think you deserve more information than you requested.

potatohead

The compiler bar graph is seen when you ask the Prop tool, using F10 for example, to build a binary image of your product to be sent to the Propeller.

EEPROM memory was not reserved. What did get reserved is two pages of HUB memory for use by the graphics functions.

When a bitmap screen is displayed, there needs to exist a buffer of memory to hold the state of the bitmap. This is like "graphics memory", or known as a graphics page, or just "bitmap". $3000 bytes of RAM were reserved for this purpose in the graphics demo, $3000 per page actually, which is most of the 32K ($7fff) HUB memory available.

This was done, in this case, so that the Propeller has a place to draw an image to be displayed on the screen. One COG is doing the screen display, another COG is executing fast graphics library functions, and another COG is running the demo program that makes use of both to do the demo.

Buffering makes something flicker free due to how graphics are drawn. On an ordinary TV or computer monitor, the image is rasterized, and that means a structured scanning of the image occurs, from top to bottom. This happens quickly enough that our eye sees one picture, due to persistence of vision. When a graphical image changes, while this raster scanning is occuring, the image will tear, or flicker, depending on the degree of change present at the time.

A buffer is used to draw the image off screen, so that the entire image can be built with out worrying about the state of the raster beam, then when it's time to show that image, the Propeller is instructed to display the contents of that buffer. The other buffer is then used to draw in the same fashion, with the display state of the two toggling rapidly to display moving images.

This is a common computer graphics technique used to present viewers with stable, no flicker images that feature motion and animation.

There are other means to display flicker free images, that do not require such a large quantity of RAM to be present, but they are more complex. The idea behind this demo program was to introduce the Propeller user to graphics technology in an easy to use and consume fashion. Once a user has understood how graphics can be generated with a Propeller, they then can move on to other means and methods that may better fit their project requirements.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!

potatohead

The colored regions in the bar graph shown in the screen shot above tell the developer what the HUB memory allocation picture looks like. How much is code, variables, and "free".

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!

lardom

Thanks for clearing that up.I·told myself·understanding prop architecture was not critical·because I only wanted to learn to control motors.·I'm adding a settings function to my project. I·now see the need.·

potatohead

Yeah, understanding that stuff is necessary. The upside is the architecture being unique and powerful opens a hell of a lot of doors with very little real cost, only time and materials to get your brain wrapped around it, and that's mostly time, frankly.

Have fun!!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!

evanh

Double buffering is a simple mechanism, and highly effective, for parallel processing. You'll see it pop up in all sorts of places in computer hardware where there is DMA transfers happening (DMA engines are a basic processor) but can apply equally to multi-threaded apps running on SMP ("multi-core") systems too.

Double buffering provides a safe working space for each of the two processors where, when both are finished with their respective tasks, the two can exchange places and continue on the other's buffer without messing with a half finished massage.

This can be extended to multiple buffers allowing one processor to run far ahead of the other.

Dual-ported RAM was developed for this very purpose.

potatohead

That's a great extension of the concept. I never really thought about it that way before.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!

evanh

[noparse]:)[/noparse]

From there, one can build a chain of such links between many threads - Building a production line like setup that can handle really tough streams of data.

There is limits on effectiveness though (Off the top of my head):
- Each added stage in the line adds lag into the system. If lag is a concern then that bounds the complexity of processing.
- Shared RAM bandwidth can also define a performance limit.

Ken Peterson

As mentioned, there are other techniques as alternatives to double buffering to avoid flicker that don't use so much RAM. One such approach that I've done in the past is to wait until the vertical blanking interval occurs and do all graphics updates there. As long as your updates can all be done within that amount of time, you can avoid the need for double buffering.

I also worked on a project where I ran out of RAM, resulting in my graphics getting messed up. It turned out I was overwriting the memory set aside in the _stack directive. If you set aside memory for your graphics buffers in VAR or DAT sections, you can better keep track of how much memory you have and avoid such bugs. You must remember, however, that the graphics and TV drivers expect the buffers to be aligned on a 64-byte (16-long) boundary, so you need to allow a little extra space and create a pointer to the buffer that you round off to the nearest boundary.

For example:

CON
  x_tiles = 19
  y_tiles = 13
  bitmap_size = x_tiles * y_tiles * 16

VAR
  long display_base

PUB  init
  '...
  display_base := @display_base_d & $FFFF_FFC0 ' align display_base to 16-long boundary
  '...


DAT
padding                 long    0[noparse][[/noparse]15]

display_base_d          long    0[noparse][[/noparse]bitmap_size]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A government big enough to give you everything you want, is big enough to take away everything you have. "
- Thomas Jefferson

lardom

I have to comment even though the topic has moved way out of my league. I have dreamed of a robot that could recognize my face. I sent a PM to Mike Green because I wanted to know if computer vision could compare an image based on a bitmap stored in memory. The short answer is that the bitmap would consume way too much memory. OK. Sometimes I can't get a song out of my head. "What about a coprocessor?" "Why not a vector image?" "Hanno Sander must be close." etc.· etc. What's going on with, I guess you call it, 'object recognition' in the world of MCUs?

evanh

Ask it as a new thread. You'll get more useful answers if you word the title well. Something along the lines of is there such a thing as descriptive image recognition.

The discussion will inevitably lead on to PropII suggestions. [noparse]:)[/noparse]