Mailbox (for comms between cogs)
Rayman
Posts: 15,625
Got some ancient code here that needs updating...
Was started back in the P123 days...
'Mailbox for USB keys
Mailbox3=$3FFF8
CON 'graphics constants
OffscreenBufferAddress=$40000 '320x240 =$12C00
DisplayBufferAddress=$50000+$3000 'size is 320x240=$12C00 (was 640x480=$4B0000)
It also has two big screen buffers that are towards the top of memory (want to update these as well, but maybe a different topic). Anyway, appears using a fixed memory address for a mailbox that is basically at the top of available memory (or thereabouts).
Kind of wishing there was some standard approach to this. Could use a smart pin in repository mode, but not really liking that idea...
Was just looking at Chip's PSRAM driver and see that he uses some longs in a DAT section as the mailbox:
DAT
cmd_list long 0[8*3] 'command list, one set of 3 longs for each cog
org 'PSRAM driver
Suppose this is as good a way as any. Seems like would make more sense to me to be in a VAR section, but guess that's nearly the same thing.
The other option might be to figure out where the actual top of memory is and use that. But, think there can be some debug stuff there and also some interrupt things. Maybe should look up where this interrupt stuff is and see if can use that... Most of my codes don't actually use interrupts....
Comments
DAT is global to the program.
VAR is per object instance, although when placed at top level a VAR is effectively a global too.
Using high memory like that does/should work.
Considering it says
Mailbox for USB keys, I would think the best course of action would be to take a flamethrower to anything related to that and replace it with the latest version of usbnew.Looked up where the debug stuff goes:
The debugging program occupies the top 16 KB of hub RAM, remapped to $FC000..$FFFFF and write-protected. The hub RAM at $7C000..$7FFFF will no longer be available.Don't understand that "remapped" business, but looks like mailbox should be just below $7C000 to avoid the risk of being clobbered by debug...
The p2 silicon says this about hub ram...
On hub RAM implementations of less than the full 1MB, the last 16KB of hub RAM is normally addressable at both its normal address range, as well as at $FC000..$FFFFF. This provides a stable address space for the 16KB of internal ROM which gets cached into the last 16KB of hub RAM on startup. This upper 16KB mapping is also used by the cog debugging scheme.
See that now. Guess there were dreams of a 1 MB P2 and guess wanted to use same exact ROM for some reason...
This arrangement does have the benefit that all that empty gap space exists.
Though one shalt normally mind what crawls out of a gap,
this allows for fast clears of cog or LUT memory with a block read.
Oh, was that the trick? Guess see how that can work now...