Not sure anybody knows. I seconded the idea, "just in case" more than anything else. IMHO, the most likely case is P2 is released and "done" There won't be variants. That pointer might get wasted as efforts move on to P3, which either is a closer derivative with compatibility that might leverage the pointer, or it's new enough that it won't matter. If P2 does see a derivative or ROM updated version for some reason, existing code could have used it to avoid being unable to run. Not a lot of downsides on it, but nice potential upsides, IMHO.
I've been thinking about the auto-baud-detection problem and I think I came up with a solution:
<enter> / $0D would be the best value to auto-baud from because people will naturally hit the <enter> key initially and often.
Here it is serialized: 1..0_10110000_1..1
This could be detected by measuring incoming low and high times on RX into a circular buffer and looking for the following pattern:
1 for >8x clocks to ensure registration (dead time before $0D, could be generated by $FF)
0 for x clocks (start bit)
1 for x clocks (data bit 0)
0 for x clocks (data bit 1)
1 for 2x clocks (data bits 2 and 3)
0 for 4x clocks (data bits 4 through 7)
You would have to allow for maybe 1/4x slop in your detector, but once that pattern came in, you would know that you just got an $0D and you would be able to set the bit period (baud rate) right then. The detector would always be running as a task that would get switched to frequently. Any time a set of pulses came in that met the criteria, the baud rate would be set anew. The CTR now has mechanisms for measuring pulses, so it wouldn't require high-bandwidth task switching to pick up the values from it. At ~20MHz internal RC frequency and 115.2k baud, you would have 20M/115.2k = ~173 clocks per bit, or 0.576% error, not considering incoming jitter.
Does anyone see any weakness in this?
Chip: See my 1-bit TV & Keyboard code (under tools debug) in Obex. It uses the "space" character to determine the speed (baud) of the keyboard so that it can be used without the clock.
The Hayes style modems used "AT" and "at" to determine not only the buad, but the number of bits and parity - we don't need this nowadays. I have done a lot of autobauding in the 80's with modem code, including catering for off-standard (Apple //c) rates. If you need help please ask (extrememly busy until end August) so just concentrating of geting SD done first.
Would anyone have any opposition to putting the ROM at the BOTTOM of memory, so that it builds up from $00000?
This way, there's no ugly caveat at the end of memory which would inhibit one from allocating a huge top-justified block of RAM. I think this would lead to more efficient use of RAM. Also, RAM could begin right away after the bare necessities of ROM code, never minding any 2k rule.
Also, since immediate-address RDxxxx/WRxxxx would be pointless because of ROM, all immediate S values could be pointers, giving us one more bit of scaled offset, so instead of -16..+15 offsets, we could express -32..+31 offsets.
Not sure I like the idea of losing the direct access to lower hub Ram. I use this in my faster spin interpreter for the vector table to decode the spin bytecode. I am not sure of the impact if this cannot be done/used.
If you decide to place the ROM at hub $0 may I suggest you leave at least the first 16 bytes or 16 longs as RAM for such things as:
CLKFREQ
CLKMODE???
CRCC (some of us are using this)
and new things such as...
HUB_FREE (used by OS to allocate buffers/code space - now does this work top down or bottom up??? Do we need both???)
and the first ROM locations...
HUB_BOTTOM (points to first hub Ram after the ROM)
HUB_TOP (points to last hub Ram +1)
If you decide to place the ROM at hub $0 may I suggest you leave at least the first 16 bytes or 16 longs as RAM for such things as:
CLKFREQ
CLKMODE???
CRCC (some of us are using this)
and new things such as...
HUB_FREE (used by OS to allocate buffers/code space - now does this work top down or bottom up??? Do we need both???)
and the first ROM locations...
HUB_BOTTOM (points to first hub Ram after the ROM)
HUB_TOP (points to last hub Ram +1)
The down side of the whole ROM at, or near the bottom, is you need a run-time pointer add, if you want to be ROM-Size tolerant, and absolute locations are pretty much excluded.
Having at least a word of ROM at 0 (for a pointer to real ROM) may help catching null-pointer exceptions. If you could trap writes to ROM and run some sort of user code (a debug monitor), that would probably make a lot of programming tasks much easier.
Not sure I like the idea of losing the direct access to lower hub Ram. I use this in my faster spin interpreter for the vector table to decode the spin bytecode. I am not sure of the impact if this cannot be done/used.
There are a lot of ways to compute an address + offset. It might take one more instruction, but maybe less than before because PTRs don't suffer from self-modifying code delays.
Not sure anybody knows. I seconded the idea, "just in case" more than anything else. IMHO, the most likely case is P2 is released and "done" There won't be variants. [..]
In case there will be variants after all, is there any way (instruction, or something) to query the P2 for a revision identifier, from software? I briefly scanned through the preliminary specs and I didn't immediately see anything. Well, if the ROM can be found in a reliable way maybe it's just to put a version number somewhere in ROM. (Mostly I'm thinking about software which needs to know what parts of the memory area is unaccessible as RAM - particularly if the ROM grows in some later revision)
As for where to place the 'vector' for where ROM is - I don't know, but back in the old days I kind of preferred those micros which placed it at $FFFF ($FFFE-$FFFF), i.e. top of addressable memory. But that may be just me.
Unlikely but if so I'd prefer the ROM starting at 0 instead of ID's and pointers. Definitely don't want to creep over the 2kbytes. The new PTR special registers seem to be the fix for the zero page tricks. Revision detection will be pretty easy to pick from the ROM content.
I do hope we can leave the hub RAM starting at address 0 and put the ROM up high. It makes memory indexing easier and faster for software that needs very simple raw access to hub RAM and there's no messy offset needing to be added all the time to account for skipping past the ROM. I find having ROM low and essentially creating a gap in direct RAM addressing from zero is never pleasant if you are doing look up tables. I know the high level compiled languages will cope fine and you wont even be aware of this but when you are low level PASM programming for perfomance you always have to be aware of it and account for this gap/offset which can be a PITA.
Also couldn't the ROM bootloader which will know its starting address etc just write the size and/or offset of the ROM in some known low memory address for apps that may want to know where it is after bootup? I know they could then overwrite this value but that could also be their choice just like CLK_FREQ location. Just a thought...
The down side of the whole ROM at, or near the bottom, is you need a run-time pointer add, if you want to be ROM-Size tolerant, and absolute locations are pretty much excluded.
I'm thinking any Prop3 will have ROM at $FFFFFFFF and growing down. Chip has already said he wished he'd done it with the Prop2.
I'd hate to imagine Prop2 revisions with more than 2kbytes of ROM. Either way, revision detect can be done just by reading known unique ROM code.
I do hope we can leave the hub RAM starting at address 0 and put the ROM up high. It makes memory indexing easier and faster for software that needs very simple raw access to hub RAM and there's no messy offset needing to be added all the time ...
There are a lot of ways to compute an address + offset. It might take one more instruction, but maybe less than before because PTRs don't suffer from self-modifying code delays.
Also couldn't the ROM bootloader which will know its starting address etc just write the size and/or offset of the ROM in some known low memory address for apps that may want to know where it is after bootup? I know they could then overwrite this value but that could also be their choice just like CLK_FREQ location.
Those system values can be located from address $800, just after the ROM.
Cluso is travaling atm, he's planning to get stuck into it asap.
Great! Do you know what approach was agreed on? Are we planning on trying to find a file in the FAT32/FAT16 filesystem or just loading the MBR?
Edit: I guess using the MBR wouldn't help much since it has only a little over 400 bytes of space for boot code. Looks like scanning the first partition for a known filename is probably the best approach. I think I saw a discussion of that go by a while ago so maybe that was the plan anyway. The only other alternative that I can see is to write the cluster map for the file you want to boot in the MBR but then you need a special cross-platform utility to do that.
I do hope we can leave the hub RAM starting at address 0 and put the ROM up high. It makes memory indexing easier and faster for software that needs very simple raw access to hub RAM and there's no messy offset needing to be added all the time to account for skipping past the ROM. I find having ROM low and essentially creating a gap in direct RAM addressing from zero is never pleasant if you are doing look up tables. I know the high level compiled languages will cope fine and you wont even be aware of this but when you are low level PASM programming for perfomance you always have to be aware of it and account for this gap/offset which can be a PITA.
Also couldn't the ROM bootloader which will know its starting address etc just write the size and/or offset of the ROM in some known low memory address for apps that may want to know where it is after bootup? I know they could then overwrite this value but that could also be their choice just like CLK_FREQ location. Just a thought...
RL
I agree with this comment. There is some advantage to putting a lookup table at location 0 so that you don't have to add an offset to address the table. This is important on P1 where we can only execute two instructions between hub accesses, or 6 instructions between every other hub access window. In P2 we will be able to execute 6 instructions between every read operation, and a tight loop may not be able to accomadate adding a table offset.
I think RAM should start at location 0, and ROM at a known location in high memory.
... In P2 we will be able to execute 6 instructions between every read operation, and a tight loop may not be able to accomadate adding a table offset. ...
I've just dug up the Prop2 Specs sheet - I should have done that a little earlier. It documents an auto increment/decrement option on the PTRs. Can't beat that for fast loops through bulk data.
I can see there being demand for more than the two PTR registers ...
Great! Do you know what approach was agreed on? Are we planning on trying to find a file in the FAT32/FAT16 filesystem or just loading the MBR?
Edit: I guess using the MBR wouldn't help much since it has only a little over 400 bytes of space for boot code. Looks like scanning the first partition for a known filename is probably the best approach. I think I saw a discussion of that go by a while ago so maybe that was the plan anyway. The only other alternative that I can see is to write the cluster map for the file you want to boot in the MBR but then you need a special cross-platform utility to do that.
Filesystem booting is completely out of the question. He's really going to be pushing it to fit. I think Cluso is planning on having a developer tool to build a file with consecutive blocks within the regular FAT32 partition and then poke the start and end block numbers into the MBR. It'll **** on any pre-existing MBR boot code, that say was used for booting a PC from, but I doubt that'll bother anyone.
I've just dug up the Prop2 Specs sheet - I should have done that a little earlier. It documents an auto increment/decrement option on the PTRs. Can't beat that for fast loops through bulk data.
I can see there being demand for more than the two PTR registers ...
Yes, I'm well aware of the auto-increment/decrement feature of the PTR register, but my concern is with random access of a table where that feature doesn't help.
Zero page is an old term that I've prolly abused a little. It is in reference to the 6800s and 6502s having a fast immediate address mode that used only 8 bit addressing. So, the first 256 bytes were premium space.
As for the unlimited LUT. I'm sceptical of the need for starting at address 0.
So "zero page mode" on the Prop can be the first 512 Bytes of HUB memeory as accessed with rdbyte etc when using the 9 bit immediate address in the instruction. No faster but smaller code and without the need to add a table base offset.
Which reminds me. Zog will not like having RAM start anywhere else than address zero.
The ZPU byte code interpretter assumes code starts at zero. So having the bytecode located antwhere else impacts performance as we have to add an offset all the time.
Ah, you say, just locate C code to some non-zero address. Could do but ZPU also uses a few locations from zero up as fake CPU registers.
Does the same apply to LMM code?
As the ROM code is of little use to most apps just keep it high and out of the way.
Anyway you really don't want to upset Zog:)
I'd hate to imagine Prop2 revisions with more than 2kbytes of ROM. Either way, revision detect can be done just by reading known unique ROM code.
Bill Gates also hated to imagine anything over 640K once...
Revision detect is only part of the issue, that may be needed as well.
A ROM boundary word in a stable, known edge location (High or Low based does not matter), allows fast and compact run-time packing of Arrays/fifos etc, and you know any ROM change does not affect your Binary.
A revision number does not help there, if you hit an unknown number, you have no idea what to do...
It is sounding like a ROM at Zero is going to break too many working designs, so it sits at Top of RAM (which is what it really is..)
If I was Parallax, I'd research bonding-in a small i2c that would allow them to offer 'User ROM' to customers at lower volumes than a Mask Rom. Other vendors do dual-die offerings.
It occurs to me that, since the RAM/ROM only has 17 bits of address, it will be repeated over the 32-bit address range. So, RAM will grow up from 0, and ROM will grow down from %FFFFFFFF. It just so happens that they're both mirrored every 128K as well.
Comments
Chip: See my 1-bit TV & Keyboard code (under tools debug) in Obex. It uses the "space" character to determine the speed (baud) of the keyboard so that it can be used without the clock.
The Hayes style modems used "AT" and "at" to determine not only the buad, but the number of bits and parity - we don't need this nowadays. I have done a lot of autobauding in the 80's with modem code, including catering for off-standard (Apple //c) rates. If you need help please ask (extrememly busy until end August) so just concentrating of geting SD done first.
Across ROM variants, it certainly should be binary compatible. Parallax may have customers willing to fund their own ROMs.
Not sure I like the idea of losing the direct access to lower hub Ram. I use this in my faster spin interpreter for the vector table to decode the spin bytecode. I am not sure of the impact if this cannot be done/used.
CLKFREQ
CLKMODE???
CRCC (some of us are using this)
and new things such as...
HUB_FREE (used by OS to allocate buffers/code space - now does this work top down or bottom up??? Do we need both???)
and the first ROM locations...
HUB_BOTTOM (points to first hub Ram after the ROM)
HUB_TOP (points to last hub Ram +1)
The down side of the whole ROM at, or near the bottom, is you need a run-time pointer add, if you want to be ROM-Size tolerant, and absolute locations are pretty much excluded.
It wraps at $1FFFF, repeating 2^15 times. You could go crazy in there.
As for where to place the 'vector' for where ROM is - I don't know, but back in the old days I kind of preferred those micros which placed it at $FFFF ($FFFE-$FFFF), i.e. top of addressable memory. But that may be just me.
-Tor
Unlikely but if so I'd prefer the ROM starting at 0 instead of ID's and pointers. Definitely don't want to creep over the 2kbytes. The new PTR special registers seem to be the fix for the zero page tricks. Revision detection will be pretty easy to pick from the ROM content.
Also couldn't the ROM bootloader which will know its starting address etc just write the size and/or offset of the ROM in some known low memory address for apps that may want to know where it is after bootup? I know they could then overwrite this value but that could also be their choice just like CLK_FREQ location. Just a thought...
RL
I'm thinking any Prop3 will have ROM at $FFFFFFFF and growing down. Chip has already said he wished he'd done it with the Prop2.
I'd hate to imagine Prop2 revisions with more than 2kbytes of ROM. Either way, revision detect can be done just by reading known unique ROM code.
Cluso is travaling atm, he's planning to get stuck into it asap.
Those system values can be located from address $800, just after the ROM.
Edit: I guess using the MBR wouldn't help much since it has only a little over 400 bytes of space for boot code. Looks like scanning the first partition for a known filename is probably the best approach. I think I saw a discussion of that go by a while ago so maybe that was the plan anyway. The only other alternative that I can see is to write the cluster map for the file you want to boot in the MBR but then you need a special cross-platform utility to do that.
I think RAM should start at location 0, and ROM at a known location in high memory.
I've just dug up the Prop2 Specs sheet - I should have done that a little earlier. It documents an auto increment/decrement option on the PTRs. Can't beat that for fast loops through bulk data.
I can see there being demand for more than the two PTR registers ...
Filesystem booting is completely out of the question. He's really going to be pushing it to fit. I think Cluso is planning on having a developer tool to build a file with consecutive blocks within the regular FAT32 partition and then poke the start and end block numbers into the MBR. It'll **** on any pre-existing MBR boot code, that say was used for booting a PC from, but I doubt that'll bother anyone.
EDIT: Dang, Bill beat me.
As for the unlimited LUT. I'm sceptical of the need for starting at address 0.
Oui! What's this 10 char minimum post length.
The ZPU byte code interpretter assumes code starts at zero. So having the bytecode located antwhere else impacts performance as we have to add an offset all the time.
Ah, you say, just locate C code to some non-zero address. Could do but ZPU also uses a few locations from zero up as fake CPU registers.
Does the same apply to LMM code?
As the ROM code is of little use to most apps just keep it high and out of the way.
Anyway you really don't want to upset Zog:)
Yes, but the ROM as patched RAM, which works great for smallest ROM's, rather excludes that.
Bill Gates also hated to imagine anything over 640K once...
Revision detect is only part of the issue, that may be needed as well.
A ROM boundary word in a stable, known edge location (High or Low based does not matter), allows fast and compact run-time packing of Arrays/fifos etc, and you know any ROM change does not affect your Binary.
A revision number does not help there, if you hit an unknown number, you have no idea what to do...
It is sounding like a ROM at Zero is going to break too many working designs, so it sits at Top of RAM (which is what it really is..)
If I was Parallax, I'd research bonding-in a small i2c that would allow them to offer 'User ROM' to customers at lower volumes than a Mask Rom. Other vendors do dual-die offerings.