forcing spin to not use the first 512 bytes

IncVoid

*edit* 06DEC2015 thank you kuroneko and phil and everybody else for awesome buffer routines.
forums.parallax.com/discussion/comment/1108886/#Comment_1108886
*end of edit*

I know spin vars are after the spin code in the generated memory map/object map but eventually they get pushed past 512 as the program grows. Also the first 16 are initialization data used by spin i believe.

I would like to make a "dummy" function that never gets used to push my actual spin code past address 512,so i can use the first 512 bytes when using RDLONG REG,#ADDRESS. I know this will not work if my spin object is not the top object but that is okay. So my mem read and writes wont fuss up the spin code.

Mostly so i can perform.

get_mem RDLONG reg,#mem
add get_mem, D0S2 '$204
DJNZ count,#get_mem

So rdlong loops only take the 16 ticks.

anybody actually take advantage reading or writing to a literal?

Electrodude

I see no reason this wouldn't work outside of the first Spin object, but don't expect the compiler to be of any help with assigning addresses for you. You'll need to do that manually

Try running this, replacing "realprogram" with the name of your spin program and adjusting it to call your program's real start method. You shouldn't experience any problems clobbering the first 512 bytes of hubram. But clkfreq is stored in the first 16 bytes of hubram (I think it's actually the very first 4 bytes), so make a copy of clkfreq if you need it. I don't think anything else in the 16 byte header is important after boot.

I have not tested this code, but I'm pretty sure it or something like it should work.

OBJ

  prog : "realprogram"

PUB start

  prog.start ' or whatever your start method is called

DAT

  long 0[$1FC] ' might be too big, but I don't think it's too small

All Spin objects (except for the first) are relocatable. This means that if you somehow insert (512-16 = 496) longs between bytes 15 and 16, it should theoretically work. You can do this with the above dummy spacer object.

The first Spin object is unfortunately not relocatable, since the validity of a program is determined by checking if the first Spin object is located in the ususal location, right after the 16 byte header. If it isn't, the Prop will simply shut down. That's why the dummy first object is necessary, as opposed to having an external program that processes your .binary file and moves all objects up (which wouldn't be that hard to do).

IncVoid

Beautiful and simple! Ill give it a go

Cluso99

Iirc there is an operation to reserve space in the bst compiler

Ariba

It's only 512 bytes and not 512 longs that you can address with # on rdlong/word/byte.
reserving the area at begin of a DAT section in the top object works, I have done this myself. But you should not use the first 24 bytes. At the 16th byte starts a table with object and function pointers.
If you have more than 1 methode in the top object the table is bigger, one long for every additional methode:

An object -

                        .----------.
        .---------------|__________|    +0      Pointer to next object
        |           .---|__________|    +1      Pointer to first PUB method
        |   .-------|---|__________|    +2      Pointer to second PUB method
        |   |   .---|---|__________|    +3      Pointer to first PRI method
        |   |   |   |   | DAT      |            Data Area
        |   |   |   |   |          |
        |   |   |   |   |----------|
        |   |   |   `-->| PUB a    |            First Method
        |   |   |       |          |
        |   |   |       |----------|
        |   |   `------>| PRI b    |            Second Method
        |   |           |          |
        |   |           |----------|
        |   `---------->| PUB c    |            Third method
        |               |          |
        |               `----------'
        `-------------->

Andy

IncVoid

Thank you kuroneko! and of course phil!
forums.parallax.com/discussion/comment/1108886/#Comment_1108886

sorry for the late reply Ariba. Thank you for the correction. I forgot that it was a byte address not a long address with the [1..0] bits zero'd out.

I remember seeing a post about the spin compiler being released after the forum cracked its bitswapping routines or something, but I don't remember where the exact spincode specification is, is that where you got the chart, or just from playing around?

I also notice there seems to be an extra long that mirrors the first long at $10, .
low word is the same, but high word mirrors the size of the var section in bytes i believe

I think you missed a list of object pointers after the method pointers. I found it out playing with number of objects and methods and seeing how the table grows. Stumbled on it when I added some dummy objects.

An array of objects(with no var section in them) all have the same long data. literally see the same 4 longs in memory, if they have a var section the high word changes to reflect where in the var table their var section starts I believe. That is how I noticed it. saw a bunch of longs all the same.







This code should work. just have to update objects and methods as you change the top level object, child objects do not affect these.

CON
        _clkmode = xtal1 + pll16x
        _xinfreq = 5_000_000

        objects = 1
        methods = 1
        init_size = 16
        table_size = 4 ' always 1 section?
        obj_size = objects * 4
        meth_size = methods * 4
        
   
OBJ
  ps4[1]      : "ps4modesr1"
PUB public_method_name
  ps4[0].main

DAT
name    byte $ff[512 -init_size -obj_size -meth_size - table_size]        

appears to work for me. I see the right amount of $FFs jumping out at me in the object info screen, ending at $200