Sorry, I didn't get the p2load changes done tonight to allow multiple files to be loaded. It turned out to be a bit harder than I thought since the second-stage loader program has to be modified to accept a start address and byte count for each different area of memory to be loaded. I also have to modify the code that writes to SPI flash and the flash loader in a similar fashion. I'll work on this more tomorrow.
If I understand it correct You use 2 stage loader that load Prop2 --- As it is good for end programs with know structure -- It is BAD for experiments.
My thinking with that Loader mode I said with multiple files was ---- Use of Monitor input mode --- Same type as Ariba use in its Terminal program.
That give possibility to made any structure I will have TO test reliable structures.
I see discussions on that Structures in previous posts --- BUT before we can AVIATE we need learn GO
If you need this multi-file loader just for experimentation and not to load complete programs then I think we should probably leave the feature out of p2load and propeller-load entirely and have it handled by a debugger. The loaders I'm working on will not be using the monitor input mode. They use the P2 ROM serial loader. Thanks for pointing this out before I got too far!
I agree. While it could be the default for loading/starting at $1000, it certainly should not be enforced. Users will ultimately decide what they do.
However, we should at least have a standard way of interfacing drivers. Currently in the P1 there is no standard way, which makes it nearly impossible to substitute drivers and interface the various languages to them. We don't even have consistent naming for calls (serial is tx and rx, VGA Text is out, cannot what the keyboard is, just to name a few simple ones).
Surely we want to avoid this mistake for the P2?
I agree that some standard interface to drivers would be helpful although there are always likely to be exceptions. Take, for instance, FullDuplexSerial. Once the driver has been loaded and started there is no mailbox interface to it. All interaction is handled by manipulating shared pointers in hub memory. The same is true of most of the video drivers I think. So a simple Unix-like open/close/read/write/seek/ioctl interface wouldn't really work for that kind of driver.
You say DEBUGER ---- That is one of parts I need to load with RUN code and its parts.
So it is still to route 1. Load parts RUN and Debug.
Before that You can't never have complete programs --- So I still think that that Complete Programs as You say are AVIATE before anyone have learned GO --- As I think NOT You else other on Forum (exclusively Chip) can program that complete programs --- without errors.
Even Debugging are not so simple that You can have common one that can debug all types of programs. As I can see You need write Yours own debugger every time -- And edit it every compiling to show problems of parts You are interested of.
As I see it now p2load are maybe good for GCC -- Maybe not --- As we still don't know much of how Programs need be structured.
But as I said Thanks for answer -- NOT one I wanted but give me way I need go
If you need this multi-file loader just for experimentation and not to load complete programs then I think we should probably leave the feature out of p2load and propeller-load entirely and have it handled by a debugger. The loaders I'm working on will not be using the monitor input mode. They use the P2 ROM serial loader. Thanks for pointing this out before I got too far!
You say DEBUGER ---- That is one of parts I need to load with RUN code and its parts.
So it is still to route 1. Load parts RUN and Debug.
Before that You can't never have complete programs --- So I still think that that Complete Programs as You say are AVIATE before anyone have learned GO --- As I think NOT You else other on Forum (exclusively Chip) can program that complete programs --- without errors.
Even Debugging are not so simple that You can have common one that can debug all types of programs. As I can see You need write Yours own debugger every time -- And edit it every compiling to show problems of parts You are interested of.
As I see it now p2load are maybe good for GCC -- Maybe not --- As we still don't know much of how Programs need be structured.
But as I said Thanks for answer -- NOT one I wanted but give me way I need go
PropGCC will support debugging through gdb and will use propeller-load for loading programs that don't require a debugger. I think gdb will probably let you write a script to load data into any area of memory you want. If you need to dynamically load data for debugging then I think you will be able to do that. At this point, it seems there is no demand for multiple file loading to be added to p2load based on the ROM serial loader. Someone could pretty easily write a simple command line program to do that using the monitor I guess. I haven't done anything with the monitor yet but I imagine it would be fairly easy.
That is good for GCC users. But GCC is mostly to convert P2 to PC type sequential CPU with some I/O's --- It is not what I'm working on.
First of all I'm not planing use of GCC at all. P2 are Micro-controller and in my applications used as that one --- So no place for GCC as it can't write optimized code for it.
If I shall use all new possibility's with new instructions --- Only PASM can that.
PropGCC will support debugging through gdb and will use propeller-load for loading programs that don't require a debugger. I think gdb will probably let you write a script to load data into any area of memory you want. If you need to dynamically load data for debugging then I think you will be able to do that. At this point, it seems there is no demand for multiple file loading to be added to p2load based on the ROM serial loader. Someone could pretty easily write a simple command line program to do that using the monitor I guess. I haven't done anything with the monitor yet but I imagine it would be fairly easy.
That is good for GCC users. But GCC is mostly to convert P2 to PC type sequential CPU with some I/O's --- It is not what I'm working on.
First of all I'm not planing use of GCC at all. P2 are Micro-controller and in my applications used as that one --- So no place for GCC as it can't write optimized code for it.
If I shall use all new possibility's with new instructions --- Only PASM can that.
Okay, I understand. Good luck with your project. I'm looking forward to hearing about what you're doing when you're ready to make it public.
Before I abandon my modifications to p2load, is it generally agreed that there is no need for a version of p2load that can load multiple files to different addresses if it isn't based on the monitor? I can modify p2load to do what we discussed yesterday but it will still reset the P2 at the start, then load each of the files to the required addresses, and finally start the COG image at $0e80 or $1000 depending on the -h option. This is pretty much what p2load already does except for the part about loading more than one file in a single invocation.
Here is what I had planned:
1) Reset the P2 to start the ROM loader
2) Load a second-stage loader that can handle the rest of the load
3) Load each file mentioned on the command line to the required address
4) Start the program at either $0e80 or $1000 depending on the presense of the -h option
If you have a command line tool (P2load) which can load one file into P2's hubmemory at a specifc address, then you just need to make a batch file to load more than one file. Or are there any problems with P2load in batch files?
If you have a command line tool (P2load) which can load one file into P2's hubmemory, then you just need to make a batch file to load more than one file. Or are there any problems with P2load in batch files?
Andy
You can do that except for one detail. The current version of p2load always starts the program after doing the load. I'd have to modify it to require the -r option to start the program so you could do multiple loads and start the program on the last one. Also, p2load always resets the P2 first. Will that cause problem for multiple invocations? I guess I could also add an option to tell it not to do that but to assume that the second-stage loader was already running. You'd end up with something like this:
p2load -a 0x1000 file1.obj
p2load -x -a 0x2000 file2.obj
p2load -x -a 0x3000 file3.obj -r -t
Here I'm assuming that -x inhibits resetting the P2 and loading the second-stage loader since it should already be running from the previous command.
Sound good, -x and -r would make the loader more universal.
I think in the near future we also need a way to load files into the big SDRAM.
Andy
Another thing I forgot to mention is that once you issue a command with -r, you can't load any more files without resetting the P2 and loading the second-stage loader again. In other words, your next invocation of p2load can't use -x.
Also, adding the -a support will allow loading more than one file on a single command line. The internal changes needed are the same. That's what I started last night but put on hold when it seemed peopel really wanted a loader that used the ROM monitor.
...That's what I started last night but put on hold when it seemed peopel really wanted a loader that used the ROM monitor.
Loading with the ROM monitor will be much slower than loading with the primary boot loader. With the monitor you need to send 3 ASCII bytes for every byte plus a new address in ASCII every 8..16 bytes, to make it readable. It's in fact a hexdump over serial.
The big advantage with the ROM monitor is you don't need a reset line and you have no timing limits, so it is possible to load files with a Bluetooth module, or an XBEE for example. But the prefered way will always be the first stage boot loader, invoked by a reset.
Loading with the ROM monitor will be much slower than loading with the primary boot loader. With the monitor you need to send 3 ASCII bytes for every byte plus a new address in ASCII every 8..16 bytes, to make it readable. It's in fact a hexdump over serial.
The big advantage with the ROM monitor is you don't need a reset line and you have no timing limits, so it is possible to load files with a Bluetooth module, or an XBEE for example. But the prefered way will always be the first stage boot loader, invoked by a reset.
Andy
Yes, that is my thought as well. Since I'm part way into this loader change I think I'll probably finish it. It has the advantage that it is more extensible than what I was doing before which only really allowed loading starting at 0xe80.
All of the cases you mention can map easily onto a mailbox/ioctl interface, and we should not have to be shackled by previous ad-hoc interfaces to drivers in Obex p1 drivers.
Taking your examples, a new serial driver could take simple "read n bytes" and "write n bytes" messages, allowing client programs to totally ignore circular buffer pointer manipulations; the details of the buffer implementations would thus be encapsulated within the driver cog/thread. The same interface would also support non-buffered drivers... without the client needing to know about the difference. Much simpler for clients than manipulating pointers.
Most video drivers could similarly either use the information in the mailbox, or have the mailbox point to a larger initialization table if required. For a simple case, specifying the bitmap address and palette address, using the to & from pointers with an "open" message fits like a glove.
I agree that some standard interface to drivers would be helpful although there are always likely to be exceptions. Take, for instance, FullDuplexSerial. Once the driver has been loaded and started there is no mailbox interface to it. All interaction is handled by manipulating shared pointers in hub memory. The same is true of most of the video drivers I think. So a simple Unix-like open/close/read/write/seek/ioctl interface wouldn't really work for that kind of driver.
Because our tools are limited, I've sometimes used Pnut to build some larger data sets in addition to a COG program or two. I'll take the object listing, use the labels to understand what is where, then build an upload file that contains the real target addresses where ever they may be, kind of like what a linker would have done. One big file can populate everything.
Because data persists, I can upload various things again and again, avoiding having to move the data, and if some of it needs to be initialized, I just upload that piece.
When it's all done, ask the monitor for the binary, right out of the P2 RAM, save to file, done. A couple of short programs would deal with the text, making binary files, etc...
I must confess, I don't have much interest in C right now. Maybe that will change with the big memory options coming, and depending on what happens with SPIN and larger programs and or potentially in-line assembly.
There will be a few development styles. Some will want C and that chain will just upload the whole thing to the P2, and it goes, done! Others will want SPIN, and it's largely the same.
Both could use the monitor some to "build on chip" or "preserve big data" so that program delta build, upload, run cycles are fast!
Honestly, I kind of want a killer macro assembler that can do LMM. Got a coupla projects in mind that would be great to use that on. (another discussion, another day)
It would be great to see the loader have the options needed to just load, however people get there. I think that's a best case scenario for a basic low level tool like the loader is. One of those options someday might be, use text representation to feed the monitor directly and allow the specification of segmented files as detailed above, but some other utility can always do that too. Just sharing how I've done things, that's all.
Yes, that is my thought as well. Since I'm part way into this loader change I think I'll probably finish it. It has the advantage that it is more extensible than what I was doing before which only really allowed loading starting at 0xe80.
All of the cases you mention can map easily onto a mailbox/ioctl interface, and we should not have to be shackled by previous ad-hoc interfaces to drivers in Obex p1 drivers.
Taking your examples, a new serial driver could take simple "read n bytes" and "write n bytes" messages, allowing client programs to totally ignore circular buffer pointer manipulations; the details of the buffer implementations would thus be encapsulated within the driver cog/thread. The same interface would also support non-buffered drivers... without the client needing to know about the difference. Much simpler for clients than manipulating pointers.
Most video drivers could similarly either use the information in the mailbox, or have the mailbox point to a larger initialization table if required. For a simple case, specifying the bitmap address and palette address, using the to & from pointers with an "open" message fits like a glove.
I agree that it would be possible to force everything into this standard interface but I thought there were efficiency reasons why it was done differently for some drivers on the P1. I suppose this standard mailbox interface could be mandated by the P2 version of OBEX. Is that your intent?
Very usable if in last Load I can Start Monitor with any flag on command line
That would be possible by just selecting another start address than 0xe80 or 0x1000. I could add an option for that I guess. Of course,now p2load is getting as complicated as propeller-load ... :-)
Frankly, the loader should be pure. It loads stuff with options with or without the monitor. Done. Anything above that is another layer. However people get to something they want to load, the loader will provide some nice options to load it.
I've been thinking about program start at $1000, and the "zero page" that happens below that. The minimum would be the clock specification, and having that at low RAM makes a lot of sense. Agreed. Beyond that?
Here's what I think. Early on in P1 history, Chip wrote some "standard" drivers. Those more or less worked together and they offered a nice set of P1 capability. Lots of things got written to those, and those things worked together. So far, so good.
Divergence happened as we learned to better use P1. Standard drivers worked, unless somebody wanted to push it somewhere, then maybe doing it that way, or working with the standard drivers did not make sense.
Additionally, P1 "basic" capability was fairly limited. Truth is, that set of capability was great for a micro, but not so great for people wanting to push it beyond being a micro. Some other synergy and resonance happened as those drivers ended up in projects too. This resulted in a few "standards" depending on what people were doing.
With P2, it's not going to be any different, and in fact SPIN was standard on P1, and it's something easily modified now for P2, which will extend that dynamic to SPIN as well as just drivers and how they communicate.
IMHO, the best way to get some solid core capability means generating a set of standard drivers much like we saw with P1, and for C building all of that as a nice library that people can access quick and easy. That will be a great center of gravity, and it will be compelling to add new capability to it too. Because a lot of this stuff is MIT, conversion and additions can be done to extend that library as people see fit.
But... there will be more than one core library, depending on how people want to use the chip. This is unavoidable. And there is SPIN, and whatever else people can and will develop with.
Use the center of gravity principle with all these specs. If there is enough value behind them, they will get far more use than if they are positioned as "this makes sense" only, or with a limited set of things that are there actually making sense.
Additionally, "forcing this" by way of it being a barrier to inclusion in the OBEX is probably not a bad idea, but if that is done, I would suggest an extremely conservative specification. If it's too complex, or onerous, there is always github and friends...
I would do this with SPIN. At some point, standard SPIN will be settled. Soon after that point, there should be some standard SPIN stuff to work with too, just like we had last time. Adding something to the OBEX that isn't standard spin might not be best for OBEX. I feel good about that. Extending that idea to things that don't work in the same way or with the standard things I don't feel good about. One can always edit the code, and I'm a fan of seeing more code rather than less, particularly MIT code because it can always be used with some effort.
With C, there is the standard distribution, and it will (it should!) include a standard library, demos, etc... In that respect, it's kind of flipped. C is C, and so C programs can go into the OBEX. If they do not use the standard libraries, the barrier should be to not allow upload to OBEX, unless it's complete. We don't want a bunch of "go and get this too, and get it from here" stubs sitting in there. If it's there, you build it, load it, wire it up, and it works.
Taking your examples, a new serial driver could take simple "read n bytes" and "write n bytes" messages, allowing client programs to totally ignore circular buffer pointer manipulations; the details of the buffer implementations would thus be encapsulated within the driver cog/thread. The same interface would also support non-buffered drivers... without the client needing to know about the difference. Much simpler for clients than manipulating pointers.
Using the center of gravity idea, the best way to get this adopted is a working code set, and or docs that get people running quick and in that way; otherwise, they may well determine something they know how to do, or invent makes more sense. I think this makes sense, BTW. I'm not arguing otherwise. Just highlighting the dynamics that will be in play, that's all.
While "forcing" this standard was not my intent, having as "the" obex2 standard would solve PropGCC/Spin/other/driver compatibility issues.
The reason for the many different interfaces for the P1 were due to a lack of a standard, a lack of need - as originally there was only Spin, so the Spin wrapper around the pasm code was all the standard that was needed.
In a later post in this thread, Potatohead makes a good argument re/ "center of gravity".
I agree that it would be possible to force everything into this standard interface but I thought there were efficiency reasons why it was done differently for some drivers on the P1. I suppose this standard mailbox interface could be mandated by the P2 version of OBEX. Is that your intent?
Now obviously if during implementation issues arise the spec may need to be modified a bit, but for me at least, it is a good starting point.
The reason I proposed that layout and messages is that it is easy to read, easy to conform to, requires little code to implement - and maps nicely to C / Unix ways of doing things.
Next week I will modify my 256x144x15bpp 720p HDTV and 256x192x15bpp XGA drivers to follow it - the "from" pointer will point at the bitmap.
Using the center of gravity idea, the best way to get this adopted is a working code set, and or docs that get people running quick and in that way; otherwise, they may well determine something they know how to do, or invent makes more sense. I think this makes sense, BTW. I'm not arguing otherwise. Just highlighting the dynamics that will be in play, that's all.
Now obviously if during implementation issues arise the spec may need to be modified a bit, but for me at least, it is a good starting point.
The reason I proposed that layout and messages is that it is easy to read, easy to conform to, requires little code to implement - and maps nicely to C / Unix ways of doing things.
Next week I will modify my 256x144x15bpp 720p HDTV and 256x192x15bpp XGA drivers to follow it - the "from" pointer will point at the bitmap.
I still think it would be better to put system globals like CLKFREQ at the start of RAM. Otherwise, you leave a hole in the global space for applications that don't want to use your mailbox scheme. Otherwise, your scheme looks okay.
I still think it would be better to put system globals like CLKFREQ at the start of RAM. Otherwise, you leave a hole in the global space for applications that don't want to use your mailbox scheme. Otherwise, your scheme looks okay.
Comments
If I understand it correct You use 2 stage loader that load Prop2 --- As it is good for end programs with know structure -- It is BAD for experiments.
My thinking with that Loader mode I said with multiple files was ---- Use of Monitor input mode --- Same type as Ariba use in its Terminal program.
That give possibility to made any structure I will have TO test reliable structures.
I see discussions on that Structures in previous posts --- BUT before we can AVIATE we need learn GO
Thanks,
David
Thanks for reply.
You say DEBUGER ---- That is one of parts I need to load with RUN code and its parts.
So it is still to route 1. Load parts RUN and Debug.
Before that You can't never have complete programs --- So I still think that that Complete Programs as You say are AVIATE before anyone have learned GO --- As I think NOT You else other on Forum (exclusively Chip) can program that complete programs --- without errors.
Even Debugging are not so simple that You can have common one that can debug all types of programs. As I can see You need write Yours own debugger every time -- And edit it every compiling to show problems of parts You are interested of.
As I see it now p2load are maybe good for GCC -- Maybe not --- As we still don't know much of how Programs need be structured.
But as I said Thanks for answer -- NOT one I wanted but give me way I need go
That is good for GCC users. But GCC is mostly to convert P2 to PC type sequential CPU with some I/O's --- It is not what I'm working on.
First of all I'm not planing use of GCC at all. P2 are Micro-controller and in my applications used as that one --- So no place for GCC as it can't write optimized code for it.
If I shall use all new possibility's with new instructions --- Only PASM can that.
Here is what I had planned:
1) Reset the P2 to start the ROM loader
2) Load a second-stage loader that can handle the rest of the load
3) Load each file mentioned on the command line to the required address
4) Start the program at either $0e80 or $1000 depending on the presense of the -h option
None of this makes use of the ROM monitor.
Andy
I think in the near future we also need a way to load files into the big SDRAM.
Andy
Also, adding the -a support will allow loading more than one file on a single command line. The internal changes needed are the same. That's what I started last night but put on hold when it seemed peopel really wanted a loader that used the ROM monitor.
The big advantage with the ROM monitor is you don't need a reset line and you have no timing limits, so it is possible to load files with a Bluetooth module, or an XBEE for example. But the prefered way will always be the first stage boot loader, invoked by a reset.
Andy
All of the cases you mention can map easily onto a mailbox/ioctl interface, and we should not have to be shackled by previous ad-hoc interfaces to drivers in Obex p1 drivers.
Taking your examples, a new serial driver could take simple "read n bytes" and "write n bytes" messages, allowing client programs to totally ignore circular buffer pointer manipulations; the details of the buffer implementations would thus be encapsulated within the driver cog/thread. The same interface would also support non-buffered drivers... without the client needing to know about the difference. Much simpler for clients than manipulating pointers.
Most video drivers could similarly either use the information in the mailbox, or have the mailbox point to a larger initialization table if required. For a simple case, specifying the bitmap address and palette address, using the to & from pointers with an "open" message fits like a glove.
Any line can have an address, and optionally, a byte, word, long specification:
2000: AA BB CC DD
n2000: FFFF000 AAAABBBB CCCCDDDD
w2000: ABCD DEF0
Once an address is given, a colon will continue on regardless of the bytes specified on the address line:
2000: 11 22 33
: 44 55 66
is the same as
2000: 11 22 33 44 55 66
If you want an upload to sprinkle data in various places in the HUB, you simply put an address on each block of data:
2000: 11 22 33 44
: 55 44 22
: 33 44 55
w3000: FFFF AAAA CCCC
: DDDD EEEE
...and so on.
Because our tools are limited, I've sometimes used Pnut to build some larger data sets in addition to a COG program or two. I'll take the object listing, use the labels to understand what is where, then build an upload file that contains the real target addresses where ever they may be, kind of like what a linker would have done. One big file can populate everything.
Because data persists, I can upload various things again and again, avoiding having to move the data, and if some of it needs to be initialized, I just upload that piece.
When it's all done, ask the monitor for the binary, right out of the P2 RAM, save to file, done. A couple of short programs would deal with the text, making binary files, etc...
In this way, one just builds right on the chip.
There will be a few development styles. Some will want C and that chain will just upload the whole thing to the P2, and it goes, done! Others will want SPIN, and it's largely the same.
Both could use the monitor some to "build on chip" or "preserve big data" so that program delta build, upload, run cycles are fast!
Honestly, I kind of want a killer macro assembler that can do LMM. Got a coupla projects in mind that would be great to use that on. (another discussion, another day)
It would be great to see the loader have the options needed to just load, however people get there. I think that's a best case scenario for a basic low level tool like the loader is. One of those options someday might be, use text representation to feed the monitor directly and allow the specification of segmented files as detailed above, but some other utility can always do that too. Just sharing how I've done things, that's all.
Very usable if in last Load I can Start Monitor with any flag on command line
Frankly, the loader should be pure. It loads stuff with options with or without the monitor. Done. Anything above that is another layer. However people get to something they want to load, the loader will provide some nice options to load it.
I've been thinking about program start at $1000, and the "zero page" that happens below that. The minimum would be the clock specification, and having that at low RAM makes a lot of sense. Agreed. Beyond that?
Here's what I think. Early on in P1 history, Chip wrote some "standard" drivers. Those more or less worked together and they offered a nice set of P1 capability. Lots of things got written to those, and those things worked together. So far, so good.
Divergence happened as we learned to better use P1. Standard drivers worked, unless somebody wanted to push it somewhere, then maybe doing it that way, or working with the standard drivers did not make sense.
Additionally, P1 "basic" capability was fairly limited. Truth is, that set of capability was great for a micro, but not so great for people wanting to push it beyond being a micro. Some other synergy and resonance happened as those drivers ended up in projects too. This resulted in a few "standards" depending on what people were doing.
With P2, it's not going to be any different, and in fact SPIN was standard on P1, and it's something easily modified now for P2, which will extend that dynamic to SPIN as well as just drivers and how they communicate.
IMHO, the best way to get some solid core capability means generating a set of standard drivers much like we saw with P1, and for C building all of that as a nice library that people can access quick and easy. That will be a great center of gravity, and it will be compelling to add new capability to it too. Because a lot of this stuff is MIT, conversion and additions can be done to extend that library as people see fit.
But... there will be more than one core library, depending on how people want to use the chip. This is unavoidable. And there is SPIN, and whatever else people can and will develop with.
Use the center of gravity principle with all these specs. If there is enough value behind them, they will get far more use than if they are positioned as "this makes sense" only, or with a limited set of things that are there actually making sense.
I would do this with SPIN. At some point, standard SPIN will be settled. Soon after that point, there should be some standard SPIN stuff to work with too, just like we had last time. Adding something to the OBEX that isn't standard spin might not be best for OBEX. I feel good about that. Extending that idea to things that don't work in the same way or with the standard things I don't feel good about. One can always edit the code, and I'm a fan of seeing more code rather than less, particularly MIT code because it can always be used with some effort.
With C, there is the standard distribution, and it will (it should!) include a standard library, demos, etc... In that respect, it's kind of flipped. C is C, and so C programs can go into the OBEX. If they do not use the standard libraries, the barrier should be to not allow upload to OBEX, unless it's complete. We don't want a bunch of "go and get this too, and get it from here" stubs sitting in there. If it's there, you build it, load it, wire it up, and it works.
My .02
Using the center of gravity idea, the best way to get this adopted is a working code set, and or docs that get people running quick and in that way; otherwise, they may well determine something they know how to do, or invent makes more sense. I think this makes sense, BTW. I'm not arguing otherwise. Just highlighting the dynamics that will be in play, that's all.
The reason for the many different interfaces for the P1 were due to a lack of a standard, a lack of need - as originally there was only Spin, so the Spin wrapper around the pasm code was all the standard that was needed.
In a later post in this thread, Potatohead makes a good argument re/ "center of gravity".
some great feedback in your messages :-)
To help start the "center of gravity", my drivers and apps will follow the minimal spec I posted in
http://forums.parallax.com/showthread.php/144384-p2load-A-Loader-for-the-Propeller-II?p=1172924&viewfull=1#post1172924
Now obviously if during implementation issues arise the spec may need to be modified a bit, but for me at least, it is a good starting point.
The reason I proposed that layout and messages is that it is easy to read, easy to conform to, requires little code to implement - and maps nicely to C / Unix ways of doing things.
Next week I will modify my 256x144x15bpp 720p HDTV and 256x192x15bpp XGA drivers to follow it - the "from" pointer will point at the bitmap.
All mailbox aware code then can have 23 mailboxes:
E9x - EFx (7 mailboxes), F0x-FFx (16 mailboxes)