Request for details on memory map

[GoogleCodeExporter]

Loopy's request from 
http://forums.parallax.com/showthread.php/148249-PropForth-V5.5-any-memory-map

I want to set aside a section of memory either in CogRam, HubRam, or EEPROM for 
a look up table.

It seems if would be easiest to have 134 or so items using unused locations in 
CogRam for the task, but there is no memory map to show which actual 
contiguious memory locations are available.

Data would be written to and read with Cog! and Cog@.

Original issue reported on code.google.com by prof.bra...@gmail.com on 29 May 2013 at 8:40

[GoogleCodeExporter]

 It seems to spread out in a couple spots in the manual, as it fits into the narrative. I don't think there has been a specific requrest yet, but I thought I saw one in the comments during th build process review. But here the parts in the propforth.htm manual for starters

The first bit is inSection3.6

The next bit is in section 6.2 Technical Details (for I/O)

Next is Section 7.1 Assembler and Kernel Words

7.3 is The Stack in Detail.

I think 7.1 is the section that has the most of what you are looking for, but 
you might need the other section to make better sense of it.

9.3 starts the description of EEprom

Original comment by prof.bra...@gmail.com on 29 May 2013 at 8:40

[GoogleCodeExporter]

Well, I am working through this on a basis that I want... CogRam first.

With the Cog Ram...
Both the front end and back end are used, so it is important to locate the area 
between.

$000-$139 320 longs of PropForth v5.5 code
$140-$1EF 176 longs of empty space to be used via Cog! and Cog2
$1F0-$1FF 16 longs of Cog specific registers

This map only applies to Cog0 throuhg Cog6 as Cog7 is the Serial Console and 
has an entirely different code element loaded. It is best not to fool with that 
and I doubt one can reach it via PropForth. You would have to read and re-write 
the Source Code

I am sure I could break out some more about the 320 longs, but what I really 
want is to use those 176 longs for a look-up table of constants in the fastest 
loop possible.

HubRam, aka Main Memory, would seem to offer more space for a much longer table 
and I think I could work off the backend as it seems the Forth Dictionary is 
starting at 0 and going higher, but the Cogs have 8 224byte (56 long) regions 
that appear to break up contiguious address.

So one does have to be careful to work around those.

These facts can be confirmed by doing data dumps with Cog@ and L@.

I actually have gotten my information from Source code in the ForthKernel.spin 
file. But the PropForth.htm confirms the 176 longs available in CogRam... just 
doesn't give an actual address range.

Original comment by prof.bra...@gmail.com on 29 May 2013 at 8:41

[GoogleCodeExporter]

Loopy,

did you check out this variable: (as defined in PropForthStartKernel.f and 
StartKernel.f)

\ coghere ( -- addr ) access as a word, the first unused register address in 
this cog
: coghere
hD8 _p+

It is the start of the 176 Long space (the 176 could change with future 
versions) - this is how the SD code used to decide where to put it's I/O buffer 
for the COG.

From coghere up to par should be good to use as long as you don't have SD words 
loaded (and haven't done an sd_init on the COG you are interested in). 

Original comment by prof.bra...@gmail.com on 29 May 2013 at 8:41