No, I'm sorry. That is not true. I'll just stand on my post, not contributing any more to an already ugly and expensive discussion. We don't agree, but that's ok. We don't have to. Parallax was gracious enough to ask for our consideration. They have it and can do the right thing for them.
On SDHC spare area from 1800 Hex have place for 384000 KBytes
On <2GB it have 3136 KBytes on that spare space starting from Sector 1 to end of 49
BUT to that it require SD Formater 3.1 program.
I don't know well the SD internals, but on the HDD there is a spare area to use when the HDD firmware recognize a damaged sector: it replaces it with one from the spare area. You will find many utilities that can add immediately the spare area to the storage space giving you more space on the HDD but preventing it to recover bad sectors.
Are you sure that there isn't the same mechanism on the SDs?
I'm going to finish the ROM without attempting any form of SD boot.
We've got over a month before the synthesis guys will deliver the final GDSII block containing all the guts, so there may be time to add some extra ROM functionality towards the end.
I can't promise this would work out, but if any of you who would like to see SD boot could present a flow-chart or code for a simple, universal FAT-compatible, perhaps pointer-to-contiguous-block method that may require some simple partitioning, I could see about integrating it in. It would be good if that contiguous block could be up to 128KB, but it must be at least 4KB. I would code it to use the same pins as the SPI flash would normally talk on, so that the ROM code doesn't disturb any more pins than it already does. I don't want for any of you to feel obliged to get involved in this because of your stance up to this point. As I said, I can't promise I would be able to integrate it, anyway, but if it was some simple firmware that talked over the four SPI flash pins, it might be low-impact enough to implement. I would do a boot order of: Serial, SPI flash, SD card. We could even inhibit the SD option with a fuse bit, in case it didn't work out (like Jazzed said above).
Thanks for all your thought on this matter, Everyone.
I have already posted that pointers.
But SD and SDHC need diferent pointers.
Only requirement is that SD-SDHC are formated by this software --- https://www.sdcard.org/downloads/formatter_3/ --- in stages I described in previous post on that subject.
And as Loader Ariba's code for raw loader.
Edit
To that You only test If SD is FAT else FAT32 formated
I'm going to finish the ROM without attempting any form of SD boot.
We've got over a month before the synthesis guys will deliver the final GDSII block containing all the guts, so there may be time to add some extra ROM functionality towards the end.
I can't promise this would work out, but if any of you who would like to see SD boot could present a flow-chart or code for a simple, universal FAT-compatible, perhaps pointer-to-contiguous-block method that may require some simple partitioning, I could see about integrating it in. It would be good if that contiguous block could be up to 128KB, but it must be at least 4KB. I would code it to use the same pins as the SPI flash would normally talk on, so that the ROM code doesn't disturb any more pins than it already does. I don't want for any of you to feel obliged to get involved in this because of your stance up to this point. As I said, I can't promise I would be able to integrate it, anyway, but if it was some simple firmware that talked over the four SPI flash pins, it might be low-impact enough to implement. I would do a boot order of: Serial, SPI flash, SD card. We could even inhibit the SD option with a fuse bit, in case it didn't work out (like Jazzed said above).
Thanks for all your thought on this matter, Everyone.
2KB is currently loaded from flash ($1F8 cog longs, plus 8 longs of SHA-256/HMAC signature).
For SD boot, we'd need to load much more than that because it must be FAT-aware.
There's no great need for the ROM to load all of the filesystem support in a single burst. The initial loaded code can continue it's own loading to bring in further blocks for full filesystem support.
It's probably easier for flexibility of placement if the initial block count is small. Cluso is comfortable with just two blocks. That said, having a small table (For holding the eight block numbers) in the MBR would fit okay.
Use the formatting program because it doesn't format to exFAT? Or use exFAT because it's okay?
EDIT: Ah, maybe it formats to FAT32 for SDHC cards. And exFAT is only used for SDXC cards. That might explain things.
EDIT2: I see you've added a picture now. Looks like I guessed right. Of course, no need for a special program when everyone already has FAT32 formatting tools.
I'm going to finish the ROM without attempting any form of SD boot.
We've got over a month before the synthesis guys will deliver the final GDSII block containing all the guts, so there may be time to add some extra ROM functionality towards the end.
I can't promise this would work out, but if any of you who would like to see SD boot could present a flow-chart or code for a simple, universal FAT-compatible, perhaps pointer-to-contiguous-block method that may require some simple partitioning, I could see about integrating it in. It would be good if that contiguous block could be up to 128KB, but it must be at least 4KB. I would code it to use the same pins as the SPI flash would normally talk on, so that the ROM code doesn't disturb any more pins than it already does. I don't want for any of you to feel obliged to get involved in this because of your stance up to this point. As I said, I can't promise I would be able to integrate it, anyway, but if it was some simple firmware that talked over the four SPI flash pins, it might be low-impact enough to implement. I would do a boot order of: Serial, SPI flash, SD card. We could even inhibit the SD option with a fuse bit, in case it didn't work out (like Jazzed said above).
Thanks for all your thought on this matter, Everyone.
Chip, I appreciate your best effort try, to make SD boot work! This is a feature that little ole' selfish me happens to think would be valuable. Like I said before, No need to worry about FAT or anything else. Just enough to get us to the point where we can chain load a larger boot image that resides on the SD card.
Cluso, Andy et al, thanks for your efforts as well! To me, you are going in the right direction.
And if SD boot does not work out, so be it. It's just a nicety that would make the P II even more unique.
No other MCU boots off SD so why waste time on this feature...
Imagine if Chip & Parallax had taken this attitude back in 2000-2006 with the idea of a uController doing full color graphics. I don't think ANY other chip in the class did Graphics at that time and very few even do today. And I'm pretty sure the task was not easy and it slowed down the release of the P1.
I see the value in SD booting, but if it can still be achieved with use code in SPI flash, then I agree get the chip done. Just don’t want to throw it out because we can’t all agree 100% on how it should be done.
Imagine if Chip & Parallax had taken this attitude back in 2000-2006 with the idea of a uController doing full color graphics.
That was more a matter of "With this tiny bit of hardware, we can do some amazing things." Now, it's used for full-color graphics, and high-resolution PWM, and high frequency synthesis/radio transmission, etc. The video generators are very minimal bits of hardware that can do a lot. SD booting is not a very general-purpose bit of code.
Get some type of SD boot in there, If the final rom code can be worked on while hardware testing is still being made.
If you don't want to use it due to not following official fat32 rules then don't, just make sure you have a SPI-flash in place simple as that.
Once they decide to not have SD boot, there is no going back.
SD wouldn't be a issue if Chip used a technology that allowed the use of Flash memory, so the Prop 2 is stuck with booting externally.
In addition there is no need for SD booting on a MCU. The people pushing this want to run a full blown OS like Linux or NetBSD on it. This is such a tiny minority of the market it's not worth it. Let these hobbyists whine or migrate to a Raspberry if they want to play with a OS.
About being first. Parallax is a small company, the sales of the BasicStamp are keeping the Prop alive. They can't afford to be too risky. They are not Microchip or NXP and cannot afford to screw up very often.
AS different size SD cards can use different amount of sectors at start after MBR- master boot record.
Simplest way to find for saver on That spare space for first FREE sectors that can be used
IF no --- Sector 1 safe to 49 --- (that is on my 32MB SD) other ones can have biger space)
that You can to calculate from --- Reserved Sectors value -1 ---> Position --- "E - Hex" in table
IF Yes -- First Safe sector 6*512+512. to Reserved Sectors value ---> 1 Position --- "E - Hex" in table ( On my 4GB it is sector 6304 - 1)
From that sector it is safe to use as BOOT.binar file area.
And on attached picture You can see what place You can look after if Format on SD use more that ONE sector --
.. The memory exists as four instances of an 8192 x 32 SRAM that we designed. ...So, we have byte addresses $00000..$1FFFF that wrap around, effectively giving us a 17-bit address bus. ..
Right now, we are set up to have RAM from $00000..$0000F, then ROM from $00010..$00xxx, then SRAM from $00xxx+1..$1FFFF. It's looking like without SD boot, $00xxx will be equal to $007FF. With SD boot, it would get a little higher.
Thanks, so it is a simple 2^N, and a read of $ffffffff would give [$1FFFF].
I'm not seeing how
RAM:$0000..$0010; ROM:$00010..$00xxx; RAM ($00xxx+1)..$1FFFF.
buys you anything in silicon over
RAM:$0000..($1FFFF-$00xxx-1); ROM$($1FFFF-$00xxx-1)...$1FFFF.
(read of $ffffffff can give ($1FFFF-$00xxx-1) )
but I can see a lot of users will bang their shins on that Low ROM ?
- and it will make porting Prop 1 code more of a manual task.
A mistake would not be easy to debug, as writes would simply not update, but read would return something.
I'm still puzzled as to why everybody (even Chip) is insisting on dealing with FAT... You can access SD in "raw" mode with physical addresses and make things much simpler...
Do we have to invoke Godwin's Law in order to settle this discussion? I don't want to, but it seems that the same 4 people keep rehashing the same argument every 3 pages.
I'm still puzzled as to why everybody (even Chip) is insisting on dealing with FAT... You can access SD in "raw" mode with physical addresses and make things much simpler...
Correct, I think TWO forks would be needed at full release :
a) A ROM fork, which is 'Size paranoid', and can place caveats on SD card. It does not have to be universal.
b) A FAT fork, which can be loaded from ANY of the Loader paths, (most common would be SPI Flash pre-boot)
To avoid confusing users, both should be offered, so it is clear what ROM-SD does, and does not, do.
a) A ROM fork, which is 'Size paranoid', and can place caveats on SD card. It does not have to be universal.
b) A FAT fork, which can be loaded from ANY of the Loader paths, (most common would be SPI Flash pre-boot)
To avoid confusing users, both should be offered, so it is clear what ROM-SD does, and does not, do.
We're not choosing just one path here. That's the whole point of what's being repeatedly said here by at least myself and Cluso, many implementations are provided for. It can be had by all with the smallest of ROM code.
Thanks, so it is a simple 2^N, and a read of $ffffffff would give [$1FFFF].
I'm not seeing how
RAM:$0000..$0010; ROM:$00010..$00xxx; RAM ($00xxx+1)..$1FFFF.
buys you anything in silicon over
RAM:$0000..($1FFFF-$00xxx-1); ROM$($1FFFF-$00xxx-1)...$1FFFF.
(read of $ffffffff can give ($1FFFF-$00xxx-1) )
but I can see a lot of users will bang their shins on that Low ROM ?
- and it will make porting Prop 1 code more of a manual task.
A mistake would not be easy to debug, as writes would simply not update, but read would return something.
It's got nothing to do with the silicon. I just figured, since we are all practically inclined to build software from low-memory upwards, that it would be good to get all the mucky-muck out of the way so that you get blue sky overhead as early as possible (while still allowing for a few pointers to be settable at the bottom ($0..$F).
It's got nothing to do with the silicon. I just figured, since we are all practically inclined to build software from low-memory upwards, that it would be good to get all the mucky-muck out of the way so that you get blue sky overhead as early as possible (while still allowing for a few pointers to be settable at the bottom ($0..$F).
Thanks. I'm glad I was not missing something subtle here..
So it comes down to essentially personal preference ? No Code-Size change either way ?
My personal preference would be to allow easiest porting of Prop 1 code, and given the difference between $1FFFF and ($1FFFF-$00xxx-1) is largely hidden anyway (just a single equate is needed, or it can be Read from ROM, if you choose to allow run-time apply of RomSize ) then I would put the ROM at the top.
A Prop 1 porting tool, could also clone any of all of the Prop 1 ROM, into $8000..$ffff, and have all existing indexing work into RAM [0..$7fff] and 'Prop1_ROM' unchanged ?
Prop 1 equivalent RAM would simply map 0..$7fff, and not need any RAM access touch-ups at all.
A Prop 2 Assembler with some equivalent of a smart macro IQ, should be able to accept Prop 1 PASM code ?
eg I can see
mov phx,phsa 'Prop 1 ASM
' would be identified and assemble as
GETPHSA phx 'Prop 2 opcode
' and
mov frqb,phx 'Prop 1 ASM
' would be identified and assemble as
SETFRQB phx 'Prop 2 opcode
I'm still puzzled as to why everybody (even Chip) is insisting on dealing with FAT... You can access SD in "raw" mode with physical addresses and make things much simpler...
Me too. The only thing that needs to deal with FAT is the thing(I call it installboot from my fondness for SunOS) that writes the MBR to make the card bootable.
The other thing that I don't get is the wrong assumption that the blocks have to be contiguous. It just ain't so. All that is needed is a list of blocks and runlengths to load. These will be read out of the FAT by "installboot" that puts them into the MBR. The file you are booting is fully allocated in the FAT so it won't get trounced by the OS(whatever flavor), and is readable & writable. There's plenty of room in the MBR for such a table, and a full 128KB could be loaded.
BTW Chip: what happens when you try to do a wrlong to a ROM location?
Chip:
All that being said, I think your idea of a small ROM monitor might be a better option(than SD boot) because it allows you to load manually over serial. That way, you could disable the SPI flash with a swich, and after quickly failing automatic serial boot(like from PropTool), and SPI boot, it will be waiting for you, over zigbee transceiver, or cellular modem, etc, to load it over serial. This feature might also greatly help with testing the prop2 and it's boards, which could speed up production. It may also help recover from a bad SPI load without having to be there if you are Zigbee or cell modem connected.
Finally, I would rather have the ROM at the top of the address map and be exactly 2K, to leave zero page open like Jazzed was saying for immediate addressing.
Me too. The only thing that needs to deal with FAT is the thing(I call it installboot from my fondness for SunOS) that writes the MBR to make the card bootable.
The other thing that I don't get is the wrong assumption that the blocks have to be contiguous. It just ain't so. All that is needed is a list of blocks and runlengths to load. These will be read out of the FAT by "installboot" that puts them into the MBR. The file you are booting is fully allocated in the FAT so it won't get trounced by the OS(whatever flavor), and is readable & writable. There's plenty of room in the MBR for such a table, and a full 128KB could be loaded.
BTW Chip: what happens when you try to do a wrlong to a ROM location?
Chip:
All that being said, I think your idea of a small ROM monitor might be a better option(than SD boot) because it allows you to load manually over serial. That way, you could disable the SPI flash with a swich, and after quickly failing automatic serial boot(like from PropTool), and SPI boot, it will be waiting for you, over zigbee transceiver, or cellular modem, etc, to load it over serial. This feature might also greatly help with testing the prop2 and it's boards, which could speed up production. It may also help recover from a bad SPI load without having to be there if you are Zigbee or cell modem connected.
Finally, I would rather have the ROM at the top of the address map and be exactly 2K, to leave zero page open like Jazzed was saying for immediate addressing.
Doug
I agree that the blocks wouldn't need to be contiguous. They just need to be easy to identify.
If you do a WRLONG to ROM, nothing happens.
I've been working on the ROM code, by the way. I never thought about using it to load the chip over Zigbee, but that would definitely work. Here is the command set:
PROP II MONITOR COMMANDS
------------------------
>[space] 'recalibrate baud
>TB 'byte data (default)
>TW 'word data
>TL 'long data
>[enter] 'view more data
>address 'view data
>address.address 'view data range
>:data data.. 'write more data
>address:data data.. 'write data
>address.address:data data.. 'write data range (fill)
>/ 'search next
>/data data.. 'search data from current
>address/ 'search from address
>address/data data.. 'search data from address
>address.address/ 'search in range
>address.address/data data.. 'search data in range
>address.address>address 'move from range to address
>address.address<address 'move from address to range
>G code parm 'start new cog
>G code parm cog 'start cog
>X cog 'stop cog
>P value 'set config
>M 'show cog usage (8 bits)
>' 'repeat last command (no need for [enter])
it needs to be disabled when encryption is activated, I agree with you there. But while programming/testing?
even the aborts of spin ... not captured they could jmp there. nice forensic. And you could patch something in HUB and restart a cog ...
and what you do not need of the rom can be ram for special purpose stuff like cluso asked for.
As other said I also would like to have ram from 0 to 126K then rom then (maybe) some longs ram for special use. NOT loaded on loading a HUB-image of 126K
with rom down there below $100 things will be less easy to port from P1 to P2. Like jmg said.
I guess I have to state that it is impossible to do so, to get it done. And then cluso or somebody else will write a P1 emulator for the P2 ...
Comments
I don't know well the SD internals, but on the HDD there is a spare area to use when the HDD firmware recognize a damaged sector: it replaces it with one from the spare area. You will find many utilities that can add immediately the spare area to the storage space giving you more space on the HDD but preventing it to recover bad sectors.
Are you sure that there isn't the same mechanism on the SDs?
I'm going to finish the ROM without attempting any form of SD boot.
We've got over a month before the synthesis guys will deliver the final GDSII block containing all the guts, so there may be time to add some extra ROM functionality towards the end.
I can't promise this would work out, but if any of you who would like to see SD boot could present a flow-chart or code for a simple, universal FAT-compatible, perhaps pointer-to-contiguous-block method that may require some simple partitioning, I could see about integrating it in. It would be good if that contiguous block could be up to 128KB, but it must be at least 4KB. I would code it to use the same pins as the SPI flash would normally talk on, so that the ROM code doesn't disturb any more pins than it already does. I don't want for any of you to feel obliged to get involved in this because of your stance up to this point. As I said, I can't promise I would be able to integrate it, anyway, but if it was some simple firmware that talked over the four SPI flash pins, it might be low-impact enough to implement. I would do a boot order of: Serial, SPI flash, SD card. We could even inhibit the SD option with a fuse bit, in case it didn't work out (like Jazzed said above).
Thanks for all your thought on this matter, Everyone.
I just wanted to say thanks for all the effort that you and the Parallax team put into everything you do.
Your effort and enthusiasm in working with customers helps us all push boundaries that lead to bigger and better things.
Chris Wardell
Cluso was under impression that 1kB is all that is being initially loaded from SPI flash by the ROM, is that not so? 4kB is fine though.
2KB is currently loaded from flash ($1F8 cog longs, plus 8 longs of SHA-256/HMAC signature).
For SD boot, we'd need to load much more than that because it must be FAT-aware.
I have already posted that pointers.
But SD and SDHC need diferent pointers.
Only requirement is that SD-SDHC are formated by this software --- https://www.sdcard.org/downloads/formatter_3/ --- in stages I described in previous post on that subject.
And as Loader Ariba's code for raw loader.
Edit
To that You only test If SD is FAT else FAT32 formated
http://forums.parallax.com/showthread.php?141706-Propeller-II&p=1120310&viewfull=1#post1120310
http://forums.parallax.com/showthread.php?141706-Propeller-II&p=1120352&viewfull=1#post1120352
There's no great need for the ROM to load all of the filesystem support in a single burst. The initial loaded code can continue it's own loading to bring in further blocks for full filesystem support.
It's probably easier for flexibility of placement if the initial block count is small. Cluso is comfortable with just two blocks. That said, having a small table (For holding the eight block numbers) in the MBR would fit okay.
Use it before You say that.
Picture show type of format Left side of HEX table
EDIT: Ah, maybe it formats to FAT32 for SDHC cards. And exFAT is only used for SDXC cards. That might explain things.
EDIT2: I see you've added a picture now. Looks like I guessed right. Of course, no need for a special program when everyone already has FAT32 formatting tools.
To BAD question
Chip, I appreciate your best effort try, to make SD boot work! This is a feature that little ole' selfish me happens to think would be valuable. Like I said before, No need to worry about FAT or anything else. Just enough to get us to the point where we can chain load a larger boot image that resides on the SD card.
Cluso, Andy et al, thanks for your efforts as well! To me, you are going in the right direction.
And if SD boot does not work out, so be it. It's just a nicety that would make the P II even more unique.
--Terry
Imagine if Chip & Parallax had taken this attitude back in 2000-2006 with the idea of a uController doing full color graphics. I don't think ANY other chip in the class did Graphics at that time and very few even do today. And I'm pretty sure the task was not easy and it slowed down the release of the P1.
I see the value in SD booting, but if it can still be achieved with use code in SPI flash, then I agree get the chip done. Just don’t want to throw it out because we can’t all agree 100% on how it should be done.
If you don't want to use it due to not following official fat32 rules then don't, just make sure you have a SPI-flash in place simple as that.
Once they decide to not have SD boot, there is no going back.
In addition there is no need for SD booting on a MCU. The people pushing this want to run a full blown OS like Linux or NetBSD on it. This is such a tiny minority of the market it's not worth it. Let these hobbyists whine or migrate to a Raspberry if they want to play with a OS.
About being first. Parallax is a small company, the sales of the BasicStamp are keeping the Prop alive. They can't afford to be too risky. They are not Microchip or NXP and cannot afford to screw up very often.
Addendum to my previous post.
AS different size SD cards can use different amount of sectors at start after MBR- master boot record.
Simplest way to find for saver on That spare space for first FREE sectors that can be used
IF no --- Sector 1 safe to 49 --- (that is on my 32MB SD) other ones can have biger space)
that You can to calculate from --- Reserved Sectors value -1 ---> Position --- "E - Hex" in table
IF Yes -- First Safe sector 6*512+512. to Reserved Sectors value ---> 1 Position --- "E - Hex" in table ( On my 4GB it is sector 6304 - 1)
From that sector it is safe to use as BOOT.binar file area.
And on attached picture You can see what place You can look after if Format on SD use more that ONE sector --
Thanks, so it is a simple 2^N, and a read of $ffffffff would give [$1FFFF].
I'm not seeing how
RAM:$0000..$0010; ROM:$00010..$00xxx; RAM ($00xxx+1)..$1FFFF.
buys you anything in silicon over
RAM:$0000..($1FFFF-$00xxx-1); ROM$($1FFFF-$00xxx-1)...$1FFFF.
(read of $ffffffff can give ($1FFFF-$00xxx-1) )
but I can see a lot of users will bang their shins on that Low ROM ?
- and it will make porting Prop 1 code more of a manual task.
A mistake would not be easy to debug, as writes would simply not update, but read would return something.
Correct, I think TWO forks would be needed at full release :
a) A ROM fork, which is 'Size paranoid', and can place caveats on SD card. It does not have to be universal.
b) A FAT fork, which can be loaded from ANY of the Loader paths, (most common would be SPI Flash pre-boot)
To avoid confusing users, both should be offered, so it is clear what ROM-SD does, and does not, do.
We're not choosing just one path here. That's the whole point of what's being repeatedly said here by at least myself and Cluso, many implementations are provided for. It can be had by all with the smallest of ROM code.
I listed a small selection, in post #1072, of ready to go implementations that can all be available together - http://forums.parallax.com/showthread.php?141706-Propeller-II&p=1120385&viewfull=1#post1120385
PS: SPI flash boot is a separate option altogether. Of course it's always available. I was one of the first proponents of it.
It's got nothing to do with the silicon. I just figured, since we are all practically inclined to build software from low-memory upwards, that it would be good to get all the mucky-muck out of the way so that you get blue sky overhead as early as possible (while still allowing for a few pointers to be settable at the bottom ($0..$F).
Thanks. I'm glad I was not missing something subtle here..
So it comes down to essentially personal preference ? No Code-Size change either way ?
My personal preference would be to allow easiest porting of Prop 1 code, and given the difference between $1FFFF and ($1FFFF-$00xxx-1) is largely hidden anyway (just a single equate is needed, or it can be Read from ROM, if you choose to allow run-time apply of RomSize ) then I would put the ROM at the top.
A Prop 1 porting tool, could also clone any of all of the Prop 1 ROM, into $8000..$ffff, and have all existing indexing work into RAM [0..$7fff] and 'Prop1_ROM' unchanged ?
Prop 1 equivalent RAM would simply map 0..$7fff, and not need any RAM access touch-ups at all.
A Prop 2 Assembler with some equivalent of a smart macro IQ, should be able to accept Prop 1 PASM code ?
eg I can see
mov phx,phsa 'Prop 1 ASM ' would be identified and assemble as GETPHSA phx 'Prop 2 opcode ' and mov frqb,phx 'Prop 1 ASM ' would be identified and assemble as SETFRQB phx 'Prop 2 opcodeMe too. The only thing that needs to deal with FAT is the thing(I call it installboot from my fondness for SunOS) that writes the MBR to make the card bootable.
The other thing that I don't get is the wrong assumption that the blocks have to be contiguous. It just ain't so. All that is needed is a list of blocks and runlengths to load. These will be read out of the FAT by "installboot" that puts them into the MBR. The file you are booting is fully allocated in the FAT so it won't get trounced by the OS(whatever flavor), and is readable & writable. There's plenty of room in the MBR for such a table, and a full 128KB could be loaded.
BTW Chip: what happens when you try to do a wrlong to a ROM location?
Chip:
All that being said, I think your idea of a small ROM monitor might be a better option(than SD boot) because it allows you to load manually over serial. That way, you could disable the SPI flash with a swich, and after quickly failing automatic serial boot(like from PropTool), and SPI boot, it will be waiting for you, over zigbee transceiver, or cellular modem, etc, to load it over serial. This feature might also greatly help with testing the prop2 and it's boards, which could speed up production. It may also help recover from a bad SPI load without having to be there if you are Zigbee or cell modem connected.
Finally, I would rather have the ROM at the top of the address map and be exactly 2K, to leave zero page open like Jazzed was saying for immediate addressing.
Doug
I agree that the blocks wouldn't need to be contiguous. They just need to be easy to identify.
If you do a WRLONG to ROM, nothing happens.
I've been working on the ROM code, by the way. I never thought about using it to load the chip over Zigbee, but that would definitely work. Here is the command set:
haha ... MONITOR ... yes. Forget about that sd-thing...
one nice command would be something like watch
W adress,#count - will wait for #count change of long in adress and output cnt and value on each change ..
or
LB - will wain for serial transmission of prop-binary and put it in HUB
LH - will wait for serial transmission of HEX-binary and put it in HUB
please ... a nice MONITOR would be so helpful.
don't overwork yourself on the last leg of your journey.
take Ken or your family and some 5th-wheel - leave all electronics at home and go for a weekend to the russian river or so
Enjoy!
Mike
it needs to be disabled when encryption is activated, I agree with you there. But while programming/testing?
even the aborts of spin ... not captured they could jmp there. nice forensic. And you could patch something in HUB and restart a cog ...
and what you do not need of the rom can be ram for special purpose stuff like cluso asked for.
As other said I also would like to have ram from 0 to 126K then rom then (maybe) some longs ram for special use. NOT loaded on loading a HUB-image of 126K
with rom down there below $100 things will be less easy to port from P1 to P2. Like jmg said.
I guess I have to state that it is impossible to do so, to get it done. And then cluso or somebody else will write a P1 emulator for the P2 ...
Enjoy!
Mike