Can I save any memory here, please?

Hugh

Hi,

I am playing with Rayman's excellent PTP, which was working as a rather spiffing display for another Prop-based project - until I ran out of memory as I started to play with cicrular buffers et al.

I would be extremely grateful if anyone could offer any suggestions as to how I might free up some memory from the attached project. (Though I can't remember how!), I have got the graphics part to be half the size of the screen (in the hope it would save some memory) but I am not sure I have realised any savings.

Though 'F8' suggests there is program space, I think the stack is sufficient that the memory is actually 'full' as variables appear to be starting to trample over each other.

Suggestions on a postcard or back of a stuck-down envelope to....!

Thanks

Hugh

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.

Cluso99

Have you re-used the hub memory occupied by cog (DAT) code after they are loaded?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

Ariba

Don't use double buffering for the display. This needs 2x 12kB buffers so you have only 8kB left for the Spin code.
You can draw your white scale once and then only update the blue needle if the angle changes. If the needle not overlaps the white scale, you can draw the needle first black at the old position and then draw it new in blue at the new position. So you get no flickering also with a single display buffer.

Andy

Harley

Hugh,

I too have nearly run out of RAM. If I make some additions it appears the stack begins to show up on the upper left. The photo shows my debug info over the o'scope type display (sigma-delta A/D to monitor a heart pulse; simulate with a 4-bit D/A w/ 1,2,4,8 R ladder. Wave form not yet smoothed w/cap so appears very stepped.

Good to see what some are doing with their LCDs. I'm totally satisfied with the 3.5" & PTP board.

I may find some code that isn't being used; at least I'm hoping. Been too busy coding; time to determine stuff left over from Paint! demo, my starting point.

ps Thanks to Cluso99 and Ariba for your hints.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

Post Edited (Harley) : 7/27/2010 1:57:19 AM GMT

Hugh

Thanks Cluso99 and Ariba for your suggestions.

Harley, that looks very cool... My ECG is very unusual, so I could do with one of those!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.

Hugh

Ariba said...
Don't use double buffering for the display. This needs 2x 12kB buffers so you have only 8kB left for the Spin code.
You can draw your white scale once and then only update the blue needle if the angle changes. If the needle not overlaps the white scale, you can draw the needle first black at the old position and then draw it new in blue at the new position. So you get no flickering also with a single display buffer.

Andy

Sorry to be a thickie, but where is the double-buffering going on - in the Graphics.spin or the top object file? I expected to see two arrays - one that was modified and then copied onto the 'live' data - but I can't for the life of me see where that is going on.

Sorry if it is obvious, but it may be I just can't see the wood for the trees!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.

potatohead

There are two addresses. Bitmap base, and display base. In the double buffer scenario those are different. Graphics get drawn to the bitmap base, then are copied to the display base, and that's the buffer. It all happens really quick.

In the single buffer scenario, you make bitmap base and display base the same, and eliminate the copy from buffer to buffer that happens. When you draw stuff, it appears on the screen right away then. If it's a smaller object, probably it will get drawn quickly enough to not flicker.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!

potatohead

  bitmap_base = $2000
  display_base = $5000

Instead of building arrays, Chip just picked locations in higher memory.

   gr.copy(display_base)   

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!

Hugh

potatohead said...

  bitmap_base = $2000
  display_base = $5000

Instead of building arrays, Chip just picked locations in higher memory.

   gr.copy(display_base)   

Aha! It all makes sense now. Thanks, Potatohead!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.

Ariba

Hugh

Yes, you set bitmap_base and display_base both to $5000, so you get the space from $2000..$5000 free for Spin.
But you must also change the _stack definition, which tells the compiler that 2x 12k is reserved. Just remove the "+ $3000" for the second buffer ($3000 bytes = 12kBytes).
And as Potatohead says the copy from the bitmap to the display buffer is obsolet, because it's the same now.

Andy

potatohead

Good catch! I always miss that one.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!