DAT file include question

Cluso99

Has anyone used the DAT File command?

Since it does not appear to copy in pasm statements for compiling, what is it's use?? The manual is quite skimpy in this section.

I am trying to put the debug block of code (for my debugger) into a separate file that can be simply included into the users top level object.

CJ

I'm pretty sure it includes the file as binary data and doesn't do any further processing on it

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.

BradC

Absolutely correct. It simply imports a byte aligned binary blob.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!

Erik Friesen

It is straight in as far as I know. You can take a black and white bmp file and with a little juggling ouput it to an lcd or whatever.

Cluso99

Thanks guys. Can you tell me how to get a binary output from the compiler into this "file" input format ?

Mike Green

You can use the binary output file from the compiler directly in a FILE statement. What you get in your new program is the entire binary file as a block of data. If that's not what you want, you will need to make your own program to extract the portions you want from the binary output file and copy them to another file which is what you include with the FILE statement.

Note that there's an example from Chip of a Propeller loader that uses a FILE statement to include a complete binary output file that's used to download to another Propeller.

Rayman

You could probably extract cog assembly code from the compilers binary output, like jazzed does for the ICC C compiler, and then include it with the FILE statement in order to load a cog with pre-build code...

Cluso99

Thanks Mike,
That's exactly what I want. Hopefully the compiler will place it at the beginning. It is the debug block that must be in hub < $200. It makes it easier for users of my debugger to be able to just add a line in the DAT section of the top object to include the data.

Cluso99

Disasterous. It doesn't do what I require. It has overhead byes and compiles to an address which is different when it is included with the file command. Oh well, at least I tried. Now I know the new compilers require a file include function (just imports source data).

hippy

I'm not sure what "overhead bytes" you're seeing but I don't get any (*). What I'm seeing is what's in the file exactly as if it had been specified as a sequence of 'byte' commands, one byte per byte there is in the file used.

Where it is placed seems to follow the same rules of DAT as usual, as if those 'byte' commands were placed where the FILE statement appears. I'll admit I only did limited testing. My FILE appeared immediately after the 'method link table' and before the first Spin method in the object it's used in just as DAT normally does.

(*) Added : There may be some $00 padding added after FILE to make anything which follows word or long aligned as required.

More added : Reading another thread it seems you may be using FILE "xxx.binary" in which case that will have all the prefix and postfix data bytes with the executable PASM which a normal Spin executable has. That's what was meant by having to run a utility to just strip out the bytes you need to create a file to use with the FILE command, or write your code which uses the FILE data to take that into account.

Post Edited (hippy) : 9/22/2008 2:26:30 PM GMT

Cluso99

Thanks Hippy. Even stripping the bytes will not work as the code assembles (pasm) to a different location to where it then gets embedded. Yes, what I need is an #include.

Anyway, I have just embedded the source in a demo file and that code will need to be cut and pasted into any user code. Just a restriction I can't get around. I've posted all the debuggers today - 3 in all. One does PASM and the other two do SPIN (optionally with pasm of the Interpreter on the fly) using different methods. One patches the Rom Interpreter on the fly, but it is more messy. The other loads two RamInterpreters and the user code must be in cog 7. The debugger is common to all 3 modes.