PSM wierd issue

rogersyd

I have a strange issue with either my code, or the PSM module that has this novice prop programmer stumped. I would appreciate some advice from anyone familiar with the prop and the PSM.

I have what essentially amounts to a demo program for the PSM. In this top object file I have ran into what is manifesting itself as an issue with the amount of code lines I have in the top object.

In the attached application I have added a handful of wait statements in the PUB START section of the code to demonstrate the issue. If the application is ran with the wait statements commented out the application runs fine. When I un-comment the wait statements a bit of "digital noise" appears in the upper left hand corner of the PSM display.

Is there some obscure memory issue I am running into here? When I compile the application there is plenty of free space left.

I ran into this issue earlier when I was adding some code further down in the demo. With the extra lines of code the application would actually crash and the PSM would reboot. For the sake of argument I added the multiple wait commands near the top of program just to clearly demonstrate the issue.

A mighty thanks is due to anyone who can shed some light on this one. I feel like a dolt... there must be something silly I do not understand here...

-rogersyd

wjsteele

It appears that you're simply overrighting the video buffer memory, which is causing the random characters to appear.

If you overright other more important memory locations, you can easily cause it to crash.

Try to make your program smaller in some way by eliminating redundant code, unneeded code and unneeded variables and DAT space.

Another option is to reduce the size of your screen resolution (but still keep it displayed correctly on the PSM LCD.)

Bill

rogersyd

Thanks Bill. That is pretty much what I figured. If I stay interested in this thing I will go down the path of code optimization. Perhaps I should reconsider my use of global vars in lieu of local ones.

I assumed I was stepping on a variable or something somewhere but my prop powers are far too humble to figure out where or why that is happening. I think I may be misunderstanding a fundamental part of this chip's memory design. This code is using 4,398 longs of program space, and 670 longs of variable space. Accordingly there are 3,120 longs of free space remaining. The prop has 8,000 longs of ram if I am not mistaken. Ill hit the books a little more closely before moving on with this one. Funny what you can do with this thing by just 'winging it'.

Thanks again for the insight.

-rogersyd

Rayman

rogersyd,

Just like the regular TV version of "Graphics Demo" from which this was derived, there's very little extra RAM left... It may be a little misleading because the graphics buffered aren't really formally reserved...

This statement forces the compile to make sure there's room for the graphics buffer:

_stack = (x_tiles*y_tiles*16*4 + 128) >> 2   'accomodate display memory and stack

But, it may appear that you have lots of room left, when really you don't...

wjsteele

The PSM actually has a different kind of display with it's own memory, if I remember correctly, so you don't actually use double buffered the memory. That saving you quite a bit of memory right there, so you should have plenty of RAM.

Ray, that line of code only protects against just the allocation of that memory. I'm guessing that somewhere in his code he is overrighting a buffer/variable that is running over that video memory which is corrupting the display.

Bill

rogersyd

I cleaned up a few redundant long variables to prevent the overwrite. I will run into that limitation again soon as I continue to tweak this thing.

Thanks again for the input Bill and Rayman !

Rayman

Glad you figured it out...

As Bill pointed out the PSM Graphics saves a lot of RAM because it uses the display as the second buffer. But, I've taken a lot of that away by making the graphics full screen. If you need more memory, you can just make the graphics area smaller than full screen...