Can you clear memory from VGA driver

T Chap

I am using a VGA type driver ( NH4_LCDdriver ) that is an adaptation of one of the old VGA drivers. I have almost maxed out $8000 - $FFFF on the EEPROM with data that gets sent as needed to the LCD. Some locations on the LCD are overwritten with other data as graphics change, so that the same memory locations are used in some cases. What is happening is that I can barely get the program to compile even using optimizing with .bstc. I have hit a wall and can't complete the code due to needing more graphics memory. It appears that if you load in a bitmap (from .dat file), it gets loaded to a memory block in the VGA driver. There are cases where I "blank" out a graphic with a solid black overlay to remove the original graphics. This overlay "mask" still takes up the same amount of memory so that you never get that memory back even if the graphic area is no longer needed. There are sections of the graphics that I can sacrifice temporarily to load other graphics for certain menus, then go back to the original graphics. The problem is that there seems to be no way to reclaim any memory areas that can be muted temporarily. I have tried stopping the LCD driver cog and restarting, thinking it would clear out any unused memory but this does not work, the screen just goes crazy when you try to relaunch it.

Obviously I don't have a clear understanding the VGA engine, and am hoping someone can shed some light on how to possibly clear out old graphic data blocks. The graphics engine seems to let you add graphics up to a point, then it crashes. Typically what happens is, to load a graphic you would read the eeprom into a location in DAT like this:

ReadPage(EEPROM1, epawatch, @graphic47_data & $FFC0, 256) ' epawatch is the address in EEPROM.
DrawBitmap(@graphic47_data, @graphics47_info)

The goal is to find a few hundred longs so that the I2C_PASM object can be used, as the current slow boat I2C is painful. Even finding 200 longs, I am still back against the wall. I included the main program. One last resort is to store some status values onto eeprom, then reboot when I need to gain some memory back, the eeprom values will then be read and tell the graphics which mode to be in. Then the eeprom status values are reset to normal and rebooted in standard mode. This could be too slow for a user to wait for are reboot just to flip a screen to see a different set of values. Ideally a memory wipe method would be preferred over rebooting.


Any suggestions would be greatly appreciated!

Electrodude

The easiest solution I've found to this is keeping all PASM images in upper EEPROM or on an SD card (except the ones that read EEPROM or SD) and loading them into a temporary buffer (usually the graphics buffer before the display is enabled) and passing a pointer to them to their object's start methods. Every PASM image gets loaded into the same buffer - load an image, call its object's start method, load the next image into the same place, call its object's start method, etc. This usually involves making two new versions - an installer version that has an extra method that returns a pointer to the PASM image, and a version for use in your program that doesn't include the PASM image but instead has a start method that takes an extra parameter to where its PASM image is. All of the installer versions are used in an installer program that writes all of the PASM images to upper EEPROM or to the SD card or somewhere. This can theoretically save up to 2KB per offloaded PASM image.

If you write your own custom compiler, you can have the PASM images occupy the space that will later be used for the graphics driver. I'm writing a Spin compiler that will be able to do this (and will also allow offloading whole Spin objects or placing them in graphics buffers), but don't expect it to be done for a long long time - if the P2 comes out before I finish my compiler, I might not even release a P1 version (but I'd still like to).

Rayman

I think you should be able to reclaim graphics memory you don't need anymore...

The VGA graphics is a tile-based system, where the screen is made up of 16x16 pixel tiles. There is a screen array that maps tiles to memory.
Usually, the tiles are mapped to ROM font characters. But, you can create your own tiles using RAM and thereby create graphics.
If you are done with a graphic, you can just print the space character all over the screen where the graphic was.
Then, that RAM is free.

T Chap

Thanks Ray, all the graphics are different sizes and shapes. I will test it but I don't know if I can go to the row/col and erase graphics properly with a space since a ROM font area is larger than some of the graphics, and in some cases smaller so there is not a clear 1:1 ration of ROM font size. I will let you know what happens. Ideally, a method to purge the memory and then redraw the screen would be best, then you wipe the slate clean as needed to free up memory versus having to use bitmap "black space" to clear graphics as a masking method. Unless, you are referring to clearing the entire screen with a string of spaces for every row? Does this reclaim all memory that was take when graphics were added in? I wonder if this is different from print $100.

Rayman

Yes, I think print $100 does a "clear screen" which here means pointing every tile to the space character.
Your graphics memory is then not being used at all and you can do whatever you want with it.

I don't know how sophisticated a solution you need, but I've seen people posting memory management program here from time to time.
You could check OBEX for something that would let you dynamically allocate and free memory...

Or, you could manually decide where to place graphics in memory for each page you want to show...

Ariba

I'm not sure if this helps you, but you can make a methode that clears a bitmap you have drawn before, by using the same bitmap-info structure as you have used to draw it:

PRI ClearBitmap2(pInfo)|i,j,xPos, yPos, xSize, ySize
  pInfo++
  xSize:=byte[pInfo++]
  ySize:=byte[pInfo++]
  xPos:=byte[pInfo++]
  yPos:=byte[pInfo++]
  row:=yPos
  col:=xPos
  repeat j from 0 to ySize-1 step 1
    repeat i from 0 to xSize-1
      screen[row * cols + col] := $220   'set space char
      col++
    row+=2
    col:=xPos

Andy

T Chap

Thanks Ariba, I will test that out.