Shop OBEX P1 Docs P2 Docs Learn Events
Modifying a RES directive before cog launch (or otherwise defining buffer sizes before cog launch) — Parallax Forums

Modifying a RES directive before cog launch (or otherwise defining buffer sizes before cog launch)

escherescher Posts: 138
edited 2017-11-19 02:16 in Propeller 1
Hey all.

For my VGA driver I'm passing in a couple variables from the Graphics wrapper: number of tiles per line, and number of lines per render.

Basically, using chip's same multi-cog methodology, I'm having n cogs each render interlacing lines of video, with a customizable number of lines per "render" (so @ 4 lines per render, cog 1 will render display 4 lines, then cog 2 will display 4 lines, then cog 1 will display 4 lines, etc.).

While cog 1 is displaying its 4 lines, cog 2 is populating its scanline buffer with data for the 4 lines it will display once cog 1 is done.

In order to reserve enough cog RAM for these buffers, I need to be able to RES numTiles x numLinesPerRender longs.

The problem is, it appears that RES amounts have to be either hard-coded inline or defined in the CON block. But if I'm passing these values in from the parent object, neither of these is viable.

Is there a way to define the size of a data buffer in a cog based on values passed to the containing object file? Or potentially by using the long declaration w/ a count modifier? To be clear I'm not attempting to dynamically allocate memory here; the size of the buffer will be known before cog launch.

Thanks!

Comments

  • escher wrote: »
    In order to reserve enough cog RAM for these buffers, I need to be able to RES numTiles x numLinesPerRender longs.

    I'm trying to figure out what you mean by "cog RAM". Do you want to use a buffer withing the cog or do you want to allocate a set amount of hub RAM for the cog to use?

    "it appears that RES amounts have to be either hard-coded inline or defined in the CON block."

    If I understand you correctly, you're right, you can't change the size of an array after compile whether is identified with RES or long.

    Which VGA driver are you using? Can you tell us which line the RES variable is defined so we can follow along better?

  • Why even bother?

    Your program loads into the COG. Put a label at the end of your program and start your buffers there.

    The COG RAM is seperate and always there. If you know you arent using that RAM, you also know nothing else will. It's private to the COG.



  • You can use the long with a count modifier, but it's a compile time, not run time definition.

    Long[50] 0

  • Actually, if this needs to be done before cog start you can patch the PASM code.

    But like Duane I am slightly confused what you are asking for.

    res does reserve space in a COG, but does not assign any values, so if you need to have a variable length of COG ram just use the last res and any COG memory left will be behind the last used COG address.

    Mike
  • escherescher Posts: 138
    edited 2017-11-19 06:07
    Alright guys apparently I didn't explain this well enough, so here goes:

    I need to define a buffer of size x in cog RAM (not Hub RAM).

    As far as I am aware, I can do this by either doing:
    buffer     res     x
    

    or

    long     buffer     0[x]
    

    I am passing the value of x to the .spin object which starts this cog.

    As far as I know, the only way the x value can be defined is by explicitly setting it in the .spin object's con block (or obviously just hard-coding it inline).

    Is there a way to have a value that is passed to a .spin object file be used to create a buffer of that value's size?
    Duane Degn wrote: »

    If I understand you correctly, you're right, you can't change the size of an array after compile whether is identified with RES or long.

    If this is the case, then I'm simply going to set them to the max size I would possibly require.
  • Whatever value you use to set the size of a res buffer will not affect the memory requirements of your program. So you might as well set it to the largest value possible, then use just part of the buffer if your main program doesn't need all of it.

    By contrast, doing this with a long buffer does affect your memory requirements.

    Remember, though, that a res buffer can only be used by the PASM program that contains it. It will not work with Spin.

    -Phil
  • escherescher Posts: 138
    edited 2017-11-19 06:28
    Whatever value you use to set the size of a res buffer will not affect the memory requirements of your program. So you might as well set it to the largest value possible, then use just part of the buffer if your main program doesn't need all of it.

    By contrast, doing this with a long buffer does affect your memory requirements.

    Remember, though, that a res buffer can only be used by the PASM program that contains it. It will not work with Spin.

    -Phil

    Thanks for the response; I think that's what I'm going to go with. Last question:

    Given the following code:
    foo        res       500
    bar        res       500
    

    If I use bar as an immediate value (e.g. mov test, #bar), will it be the same as #foo + 500?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-11-19 06:40
    escher wrote:
    If I use bar as an immediate value (e.g. mov test, #bar), will it be the same as #foo + 500?
    Yes. But don't forget that a cog has room for only 512 longs, including your PASM code and the 16 special registers at the end. If you try your statement with an address value of bar that's beyond 511, you will get a compile error.

    -Phil
  • escher wrote:
    If I use bar as an immediate value (e.g. mov test, #bar), will it be the same as #foo + 500?
    Yes. But don't forget that a cog has room for only 512 longs, including your PASM code. If you try your statement with a value of bar that's beyond 511, you will get a compile error.

    -Phil

    Great thank you; the API makes it clear that the PC is affected by the res directive, but makes no mention of the effect it has on addressing. Yeah I picked some random numbers for the example without thinking about their legitimacy haha.

  • The effect is only on addressing. It only indirectly affects the PC by changing the addresses of jmp targets. It's up to you to actually make sure code gets loaded into the right place in cog RAM.
Sign In or Register to comment.