That function need be NOT sensitive for file type xxxxx.bin, xxxxx.txt else other --- Need give me possibility to freely specify that BUT load all as if it was BINARY files
That function need be NOT sensitive for file type xxxxx.bin, xxxxx.txt else other --- Need give me possibility to freely specify that BUT load all as if it was BINARY files
Okay, I think I understand. You're sometimes loading text but it doesn't need to be interpreted by the loader. It just needs to be written to hub memory as if it were binary. Is that right?
Okay, I think I understand. You're sometimes loading text but it doesn't need to be interpreted by the loader. It just needs to be written to hub memory as if it were binary. Is that right?
Hi David, great app by the way
Quick question, can you specify a load address?
ie, could you p2load data.bin,8000
if not, would it be hard to add? as I think it would be useful, to others as well as myself.
Hi David, great app by the way
Quick question, can you specify a load address?
ie, could you p2load data.bin,8000
if not, would it be hard to add? as I think it would be useful, to others as well as myself.
Cheers,
Jim.
That is in fact what Sapieha has just been requesting and I told him I'd look at it this evening.
Are you both using Windows for development? I'm asking because I'll need to create an executable p2load for your platform unless you want to pull the sources from Google Code and build yourselves.
Are you both using Windows for development? I'm asking because I'll need to create an executable p2load for your platform unless you want to pull the sources from Google Code and build yourselves.
Thanks! That shouldn't be a problem. The only platform that will be a bit of a pain is Linux since I don't usually build on Linux. It isn't really difficult but I'll have to dust off my old Linux laptop.
Something else that I should point out is that I've moved my development over to propeller-load which currently knows how to load either P1 or P2. The advantage of propeller-load is that it knows how to write a bootable image to the SPI flash. The p2load program can't do that at present. Are current or perspective users of p2load willing to use propeller-load instead? Later this evening I'll make sure that propeller-load can handle the .BIN files produced by PNut. If there is still interest in p2load, I'll try to merge in the SPI flash writing code into that as well.
David: A few things to note from this post and others...
pnut outputs 2 files: xxxx.BIN and xxxx.obj
The xxxx.BIN file is truncated at the 2KB limit, so it is useless beyond 2KB. However, xxxx.obj is just fine. So provided we load the xxxx.obj everything works.
I have taken to using your -s option, and prefilling the space with $0's like you do. This is great as any hub references are correct without worrying about offsets like $e80.
I would also like the ability to load hub with multiple binary files, and an optional load hub address parameter for each file would be appreciated. I will shortly need to be able to load test spin binaries, so this would be a real help. BTW I use Windoze 7 so a compiled exe would be fantastic.
Can you elaborate on the -h option a little more? Does it just perform a coginit using hub address $1000, or does it also skip $e80 or $1000 bytes from the binary too? Do I also need to use the -s option as well?
You mention propeller-load. Would it be easier to add these options to propeller-load and dispense with p2load altogether or is propeller-load something different altogether? How does propeller-load operate/compare from a p2load users point of view?
Reserved hub space $0E80-$0FFF:
I would like to propose that $0E80-$0EFF be reserved for 8*4 longs = 128 bytes for each cog. i.e. each cog has a 4 long slot. This just fits nicely into that space, leaving the remaining 256 bytes to be divided up into other areas.
What I have in mind is that the 4 longs for each cog would be a similar combination of the first and second allocation that catalina does. The first long is used to identify an 8bit cog in use flag determining it's function. This way, we have a fixed base for the cogs, with just a single offset of cogid*4 (well cogid*16 for hub byte address which is cogid << 4). As you are most likely aware, catalina allocates a single long where the top 8 bits are for an in use identity function and the lower bits point to the second allocation of 2 longs. This makes 3 longs, but the code to get access to the pointed to 2 long buffer is pointless (it just wastes instructions and speed), so I think it would be better to just allocate 4 longs n the first place. If a larger buffer is required, then these longs can point to them, including size, etc. Anyway, I think their use is open for discussion.
A lot of work that I did in reserved hub space revolved around redirection of I/O (serial/keyboard/video) and of course file access via SD. So my allocation was use centered whereas catalina's was based on cog usage. I think there is synergy in both methods. Perhaps we all can come up with something really useful while still remaining quite small.
So I think that shortly we should open a whole thread to discuss the use of this reserved hub space.
David: A few things to note from this post and others...
pnut outputs 2 files: xxxx.BIN and xxxx.obj
The xxxx.BIN file is truncated at the 2KB limit, so it is useless beyond 2KB. However, xxxx.obj is just fine. So provided we load the xxxx.obj everything works.
Quite correct. I meant to say .OBJ in my earlier messages rather than .BIN.
I have taken to using your -s option, and prefilling the space with $0's like you do. This is great as any hub references are correct without worrying about offsets like $e80.
I would also like the ability to load hub with multiple binary files, and an optional load hub address parameter for each file would be appreciated. I will shortly need to be able to load test spin binaries, so this would be a real help. BTW I use Windoze 7 so a compiled exe would be fantastic.
Can you elaborate on the -h option a little more? Does it just perform a coginit using hub address $1000, or does it also skip $e80 or $1000 bytes from the binary too? Do I also need to use the -s option as well?
The -h option just says that the initial COG image is loaded from $1000 rather than $e80. It is independent of the -s option which strips the first $e80 bytes before loading. You need to use both. If we have general agreement about loading the COG image from $1000 and using the "byte 0[$e80]" scheme for making hub addresses come out right and leaving space for mailboxes etc then I'll make those options the default. Any objections?
You mention propeller-load. Would it be easier to add these options to propeller-load and dispense with p2load altogether or is propeller-load something different altogether? How does propeller-load operate/compare from a p2load users point of view?
If we're going to support loading multiple files at the same time then I think it will be difficult to add that feature to propeller-load. It already has way too many options. I've often thought of splitting it into multiple programs but that idea has been vetoed. For now, I'll update p2load to handle multiple files and we can later decide if we want that feature in propeller-load as well and how to do it.
Reserved hub space $0E80-$0FFF:
I would like to propose that $0E80-$0EFF be reserved for 8*4 longs = 128 bytes for each cog. i.e. each cog has a 4 long slot. This just fits nicely into that space, leaving the remaining 256 bytes to be divided up into other areas.
What I have in mind is that the 4 longs for each cog would be a similar combination of the first and second allocation that catalina does. The first long is used to identify an 8bit cog in use flag determining it's function. This way, we have a fixed base for the cogs, with just a single offset of cogid*4 (well cogid*16 for hub byte address which is cogid << 4). As you are most likely aware, catalina allocates a single long where the top 8 bits are for an in use identity function and the lower bits point to the second allocation of 2 longs. This makes 3 longs, but the code to get access to the pointed to 2 long buffer is pointless (it just wastes instructions and speed), so I think it would be better to just allocate 4 longs n the first place. If a larger buffer is required, then these longs can point to them, including size, etc. Anyway, I think their use is open for discussion.
A lot of work that I did in reserved hub space revolved around redirection of I/O (serial/keyboard/video) and of course file access via SD. So my allocation was use centered whereas catalina's was based on cog usage. I think there is synergy in both methods. Perhaps we all can come up with something really useful while still remaining quite small.
So I think that shortly we should open a whole thread to discuss the use of this reserved hub space.
My only problem with this is that I still think it might be best to have CLKFREQ and CLKMODE as the first two hub RAM locations. Maybe Chip will say how he expects to handle this in Spin2.
I use GAS to build the second-stage loader and then PropGCC to build any programs I'm working on. Both of those will run on OS X. Eric's spin2cpp can assemble PASM for P1. I'm not sure if he's added the ability to assemble P2 code yet. It also runs on OS X. Roy's Spin compiler does as well but, again, I'm not sure if Roy has added P2 support to its assembler.
The -h option just says that the initial COG image is loaded from $1000 rather than $e80. It is independent of the -s option which strips the first $e80 bytes before loading. You need to use both. If we have general agreement about loading the COG image from $1000 and using the "byte 0[$e80]" scheme for making hub addresses come out right and leaving space for mailboxes etc then I'll make those options the default. Any objections?
If we're going to support loading multiple files at the same time then I think it will be difficult to add that feature to propeller-load. It already has way too many options. I've often thought of splitting it into multiple programs but that idea has been vetoed. For now, I'll update p2load to handle multiple files and we can later decide if we want that feature in propeller-load as well and how to do it.
Now I understand the -s and -h options, they make perfect sense to me.
If you implemented optional parameters for -s [xxxx] (default $e80) and -h [xxxx] (default $1000) then perhaps we could just chain p2load multiple times (e.g. using a batch file) to load the multiple files. We would need to prevent reset and to prevent coginit as options as well then.
... re $e80-$fff:
My only problem with this is that I still think it might be best to have CLKFREQ and CLKMODE as the first two hub RAM locations. Maybe Chip will say how he expects to handle this in Spin2.
If CLKFREQ & CLKMODE are the first 2 longs, then the cog table would need to be at $0F80-$0FF, leaving $0E82-$0F7F for other uses. We probably also should add 1 or 2 longs for lower and upper hub limits for user code.
As for starting code at hub $1000, I noticed Bill is all for it, and it seems PropGCC is onboard too. So unless anyone objects, lets do it (at least for now anyway)?
I like Ray's proposal that $E80-$EFF allocate eight quad-longs for cog0-cog7 respectively.
Regarding $F00-FFF, maybe we reserve $F00-$F03 for CLKFREQ, CLKMODE, and two reserved longs?
Following it, $F10-$FFF could be 15 more quad-long mailboxes for "to be defined" functions.
We could have:
$F00 be the "system constants"
$F10 be the "console input/output" mailbox
$F20 be the FLASH mailbox
$F30 be the uSD mailbox
In general, a mailbox format I like is:
long 0 - function/status
long 1 - from pointer
long 2 - to pointer
long 3 - length/size
Obviously longs 1-3 may need to be defined differently for unusual drivers.
A few standad messages come to mind:
open
status
ioctl
read
write
close
These may seem familiar to some
This looks interesting except that I think we should be careful about trying to turn the P2 into a PC. While many of us like to try to run an OS-like program, that isn't really a common use of a microcontroller is it? We want to be careful not to hard-allocate resources to support OS-like behavior when that may be more of a hobbyist application than something that the commercial audience for the P2 will require. I think it might be best if the global variable space can be as flexible as possible and maybe used differently for different applications. Of course, there could be a standard for OS-like applications but I think it might be better to keep that separate from a standard across all P2 programs.
I like Ray's proposal that $E80-$EFF allocate eight quad-longs for cog0-cog7 respectively.
Yes, it just seems to fit here nicely. It would be something similar to your general mailbox format which makes sense.
Regarding $F00-FFF, maybe we reserve $F00-$F03 for CLKFREQ, CLKMODE, and two reserved longs?
Also makes sense.
IIRC CLKMODE does not need the full 32 bits so we may have a byte or 3 available here too.
We may need a lower and an upper hub address limit so that memory can be allocated.
Following it, $F10-$FFF could be 15 more quad-long mailboxes for "to be defined" functions.
We could have:
$F00 be the "system constants"
$F10 be the "console input/output" mailbox
$F20 be the FLASH mailbox
$F30 be the uSD mailbox
In general, a mailbox format I like is:
long 0 - function/status
long 1 - from pointer
long 2 - to pointer
long 3 - length/size
Obviously longs 1-3 may need to be defined differently for unusual drivers.
A few standad messages come to mind:
open
status
ioctl
read
write
close
These may seem familiar to some
Again, perfect sense.
As an alternative, for some mailboxes, where single characters would be passed...
long 0 - function/status
long 1 - tx char
long 2 - rx char
long 3 - unused or pins used
And another alternative definition...
long0 - function/status
long 1 - 4 byte tx buffer
long 2 - 4 byte rx buffer
long 3 - byte 0 & 1 tx buffer head & tail
long 4 - byte 2 & 3 rx buffer head & tail
A mailbox could also be used as a 14 byte buffer and 1 byte each for head & tail.
It may therefore make sense to have these 16 allocated by a bit in a word (say the CLKMODE spare word if available)
Anyway, these are just some thoughts.
We may also need some calls to a higher level driver for files (FAT32) such as Kye's FAT driver (or similar).
My thinking is that if someone wants to go to bare metal, they will ignore all of this.
- I'd think that normally the "console" mailbox would be mapped to serial rx/tx, which most (if not all) embedded code will use
- Most code would use Flash access, as a flash chip is required
- A lot of boards will use uSD as it is an inexpensive, standard way of providing large storage
Regarding the standard messages
- any unused message can be ignored
- these unix like messages will sure make porting code easier... and they make sense
- all FAT calls can be mapped to the standard messages
For bare metal code, they can obviously ignore the above - but it would sure be nice to have standard drivers, that can be used by any language...
This looks interesting except that I think we should be careful about trying to turn the P2 into a PC. While many of us like to try to run an OS-like program, that isn't really a common use of a microcontroller is it? We want to be careful not to hard-allocate resources to support OS-like behavior when that may be more of a hobbyist application than something that the commercial audience for the P2 will require. I think it might be best if the global variable space can be as flexible as possible and maybe used differently for different applications. Of course, there could be a standard for OS-like applications but I think it might be better to keep that separate from a standard across all P2 programs.
Yes, it just seems to fit here nicely. It would be something similar to your general mailbox format which makes sense.
Also makes sense.
IIRC CLKMODE does not need the full 32 bits so we may have a byte or 3 available here too.
We may need a lower and an upper hub address limit so that memory can be allocated.
Again, perfect sense.
As an alternative, for some mailboxes, where single characters would be passed...
long 0 - function/status
long 1 - tx char
long 2 - rx char
long 3 - unused or pins used
And another alternative definition...
long0 - function/status
long 1 - 4 byte tx buffer
long 2 - 4 byte rx buffer
long 3 - byte 0 & 1 tx buffer head & tail
long 4 - byte 2 & 3 rx buffer head & tail
A mailbox could also be used as a 14 byte buffer and 1 byte each for head & tail.
It may therefore make sense to have these 16 allocated by a bit in a word (say the CLKMODE spare word if available)
Anyway, these are just some thoughts.
We may also need some calls to a higher level driver for files (FAT32) such as Kye's FAT driver (or similar).
The single character version makes perfect sense to me!
Sorry, I don't like the 5 long special format for only four byte FIFO for rx/tx
Instead, how about:
long 0 - function/status
long 1 - from fifo base pointer (rx fif0)
long 2 - to fifo base pointer (tx fifo)
long 3 - lower word - index within rx fifo
long 3 - upper word - index within tx fifo
however I think it makes more sense to issue "read n bytes" and "write n bytes" and let the driver manage the fifo - heck we could have sync/async versions of read/write, checking the status as needed.
My thinking is that if someone wants to go to bare metal, they will ignore all of this.
- I'd think that normally the "console" mailbox would be mapped to serial rx/tx, which most (if not all) embedded code will use
- Most code would use Flash access, as a flash chip is required
- A lot of boards will use uSD as it is an inexpensive, standard way of providing large storage
Regarding the standard messages
- any unused message can be ignored
- these unix like messages will sure make porting code easier... and they make sense
- all FAT calls can be mapped to the standard messages
For bare metal code, they can obviously ignore the above - but it would sure be nice to have standard drivers, that can be used by any language...
Well, rather than saying "just ignore what you don't need", I still think it would be better to have multiple levels of standards. You're probably right that serial rx/tx should be part of the base standard but I'm not sure about flash I/O. I would guess that most programs will just boot from flash and never access it again. That's the way most P1 programs work as far as I can tell. Or, they might use flash to support an XMM program but that still won't require the program to access the flash directly. That access will be handled by the XMM memory driver.
So, the first level standard defines only system constants like CLKFREQ and CLKMODE and a console rx/tx.
The OS standard adds the rest of the stuff you mentioned.
I'm also not sure you necessarily want to force all mailboxes to be a standard size. There may be a reason for different allocation of the global space for different applications. You only need to enforce the "OS standard" for applications that need to adhere to that because they want OS-like services.
Well, rather than saying "just ignore what you don't need", I still think it would be better to have multiple levels of standards. You're probably right that serial rx/tx should be part of the base standard but I'm not sure about flash I/O. I would guess that most programs will just boot from flash and never access it again. That's the way most P1 programs work as far as I can tell. Or, they might use flash to support an XMM program but that still won't require the program to access the flash directly. That access will be handled by the XMM memory driver.
So, the first level standard defines only system constants like CLKFREQ and CLKMODE and a console rx/tx.
The OS standard adds the rest of the stuff you mentioned.
I'm also not sure you necessarily want to force all mailboxes to be a standard size. There may be a reason for different allocation of the global space for different applications. You only need to enforce the "OS standard" for applications that need to adhere to that because they want OS-like services.
No one can force any standard on anyone...
There are many advantages to a standard mailbox size, it makes writing/using standard drivers much easier, and much more "plug and play". If more storage is needed, the to/from pointers can point to them.
we could have:
Bare metal:
Cog 0-7 mailboxes (16 bytes each) from $E80-$EFF
$F00: CLKFREQ, CLKMODE, tx_long, rx_long for simple putchar/getchar console
$F10-$FFF - general use for "bare metal" applications; "bare metal" app writes who complain they can't use the nice standard drivers --> OS Style Standard
OS Style Standard:
Same as Bare metal for $E80-F1F
$Fn0-$FnF - 15 mailboxes following standard 4 long format whenver possible
This would also allow "bare metal" to have some of the 15 OSSS mailboxes; easy way is mail boxes grow up from $F10, non-mailboxes grow down from $FFF
I guess you can if it is enforced by the standard tools. My suggestion is just that this "standard" not be baked into the loader or any of the other tools. It is simply a standard for how to write programs. The loader just loads bits and doesn't really know anything about what they mean.
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.
I guess you can if it is enforced by the standard tools. My suggestion is just that this "standard" not be baked into the loader or any of the other tools. It is simply a standard for how to write programs. The loader just loads bits and doesn't really know anything about what they mean.
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.
That's not a problem for me as I am not ready just yet. Thanks for taking this on board.
I think the only part that really needs to be baked into the tools is the $1000 start address, and even that is potentially removable
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?
Comments
That function need be NOT sensitive for file type xxxxx.bin, xxxxx.txt else other --- Need give me possibility to freely specify that BUT load all as if it was BINARY files
YES -- that is correct --- As I never know what types will be mixed on particular load
How long do we have to wait until we know what mystery languages you're working on? I hope one is Lisp! :-)
Thanks.
I think before real P2 are out --- But who know?
Quick question, can you specify a load address?
ie, could you p2load data.bin,8000
if not, would it be hard to add? as I think it would be useful, to others as well as myself.
Cheers,
Jim.
Are you both using Windows for development? I'm asking because I'll need to create an executable p2load for your platform unless you want to pull the sources from Google Code and build yourselves.
My system are win XP
pnut outputs 2 files: xxxx.BIN and xxxx.obj
The xxxx.BIN file is truncated at the 2KB limit, so it is useless beyond 2KB. However, xxxx.obj is just fine. So provided we load the xxxx.obj everything works.
I have taken to using your -s option, and prefilling the space with $0's like you do. This is great as any hub references are correct without worrying about offsets like $e80.
I would also like the ability to load hub with multiple binary files, and an optional load hub address parameter for each file would be appreciated. I will shortly need to be able to load test spin binaries, so this would be a real help. BTW I use Windoze 7 so a compiled exe would be fantastic.
Can you elaborate on the -h option a little more? Does it just perform a coginit using hub address $1000, or does it also skip $e80 or $1000 bytes from the binary too? Do I also need to use the -s option as well?
You mention propeller-load. Would it be easier to add these options to propeller-load and dispense with p2load altogether or is propeller-load something different altogether? How does propeller-load operate/compare from a p2load users point of view?
Reserved hub space $0E80-$0FFF:
I would like to propose that $0E80-$0EFF be reserved for 8*4 longs = 128 bytes for each cog. i.e. each cog has a 4 long slot. This just fits nicely into that space, leaving the remaining 256 bytes to be divided up into other areas.
What I have in mind is that the 4 longs for each cog would be a similar combination of the first and second allocation that catalina does. The first long is used to identify an 8bit cog in use flag determining it's function. This way, we have a fixed base for the cogs, with just a single offset of cogid*4 (well cogid*16 for hub byte address which is cogid << 4). As you are most likely aware, catalina allocates a single long where the top 8 bits are for an in use identity function and the lower bits point to the second allocation of 2 longs. This makes 3 longs, but the code to get access to the pointed to 2 long buffer is pointless (it just wastes instructions and speed), so I think it would be better to just allocate 4 longs n the first place. If a larger buffer is required, then these longs can point to them, including size, etc. Anyway, I think their use is open for discussion.
A lot of work that I did in reserved hub space revolved around redirection of I/O (serial/keyboard/video) and of course file access via SD. So my allocation was use centered whereas catalina's was based on cog usage. I think there is synergy in both methods. Perhaps we all can come up with something really useful while still remaining quite small.
So I think that shortly we should open a whole thread to discuss the use of this reserved hub space.
Regarding $F00-FFF, maybe we reserve $F00-$F03 for CLKFREQ, CLKMODE, and two reserved longs?
Following it, $F10-$FFF could be 15 more quad-long mailboxes for "to be defined" functions.
We could have:
$F00 be the "system constants"
$F10 be the "console input/output" mailbox
$F20 be the FLASH mailbox
$F30 be the uSD mailbox
In general, a mailbox format I like is:
long 0 - function/status
long 1 - from pointer
long 2 - to pointer
long 3 - length/size
Obviously longs 1-3 may need to be defined differently for unusual drivers.
A few standad messages come to mind:
open
status
ioctl
read
write
close
These may seem familiar to some
Wine?
If you implemented optional parameters for -s [xxxx] (default $e80) and -h [xxxx] (default $1000) then perhaps we could just chain p2load multiple times (e.g. using a batch file) to load the multiple files. We would need to prevent reset and to prevent coginit as options as well then.
... re $e80-$fff: If CLKFREQ & CLKMODE are the first 2 longs, then the cog table would need to be at $0F80-$0FF, leaving $0E82-$0F7F for other uses. We probably also should add 1 or 2 longs for lower and upper hub limits for user code.
As for starting code at hub $1000, I noticed Bill is all for it, and it seems PropGCC is onboard too. So unless anyone objects, lets do it (at least for now anyway)?
IIRC CLKMODE does not need the full 32 bits so we may have a byte or 3 available here too.
We may need a lower and an upper hub address limit so that memory can be allocated. Again, perfect sense.
As an alternative, for some mailboxes, where single characters would be passed...
long 0 - function/status
long 1 - tx char
long 2 - rx char
long 3 - unused or pins used
And another alternative definition...
long0 - function/status
long 1 - 4 byte tx buffer
long 2 - 4 byte rx buffer
long 3 - byte 0 & 1 tx buffer head & tail
long 4 - byte 2 & 3 rx buffer head & tail
A mailbox could also be used as a 14 byte buffer and 1 byte each for head & tail.
It may therefore make sense to have these 16 allocated by a bit in a word (say the CLKMODE spare word if available)
Anyway, these are just some thoughts.
We may also need some calls to a higher level driver for files (FAT32) such as Kye's FAT driver (or similar).
- I'd think that normally the "console" mailbox would be mapped to serial rx/tx, which most (if not all) embedded code will use
- Most code would use Flash access, as a flash chip is required
- A lot of boards will use uSD as it is an inexpensive, standard way of providing large storage
Regarding the standard messages
- any unused message can be ignored
- these unix like messages will sure make porting code easier... and they make sense
- all FAT calls can be mapped to the standard messages
For bare metal code, they can obviously ignore the above - but it would sure be nice to have standard drivers, that can be used by any language...
The single character version makes perfect sense to me!
Sorry, I don't like the 5 long special format for only four byte FIFO for rx/tx
Instead, how about:
long 0 - function/status
long 1 - from fifo base pointer (rx fif0)
long 2 - to fifo base pointer (tx fifo)
long 3 - lower word - index within rx fifo
long 3 - upper word - index within tx fifo
however I think it makes more sense to issue "read n bytes" and "write n bytes" and let the driver manage the fifo - heck we could have sync/async versions of read/write, checking the status as needed.
So, the first level standard defines only system constants like CLKFREQ and CLKMODE and a console rx/tx.
The OS standard adds the rest of the stuff you mentioned.
I'm also not sure you necessarily want to force all mailboxes to be a standard size. There may be a reason for different allocation of the global space for different applications. You only need to enforce the "OS standard" for applications that need to adhere to that because they want OS-like services.
No one can force any standard on anyone...
There are many advantages to a standard mailbox size, it makes writing/using standard drivers much easier, and much more "plug and play". If more storage is needed, the to/from pointers can point to them.
we could have:
Bare metal:
Cog 0-7 mailboxes (16 bytes each) from $E80-$EFF
$F00: CLKFREQ, CLKMODE, tx_long, rx_long for simple putchar/getchar console
$F10-$FFF - general use for "bare metal" applications; "bare metal" app writes who complain they can't use the nice standard drivers --> OS Style Standard
OS Style Standard:
Same as Bare metal for $E80-F1F
$Fn0-$FnF - 15 mailboxes following standard 4 long format whenver possible
This would also allow "bare metal" to have some of the 15 OSSS mailboxes; easy way is mail boxes grow up from $F10, non-mailboxes grow down from $FFF
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?