Chip, now is the time for us to work out these addresses which could be $04,$08 or $F8 and $FC even as it is still easily reached with un-augmented rdlong imediate. P1 Spin reserved the first 16 bytes anyway.
My original addresses were mainly for some functionality and I always had the option of changing it later. This has nothing to do with the ROM though, because what's in ROM, stays in ROM.
We've got a Las Vegas ROM, I agree.
It seems that people really want $00 allocated as a warm reset start or null pointer trap. To me, once booting has occurred, there's no going back. If you want to reboot, you need to reset the chip, not just launch a cog again from $00. Corrupted memory is probably why somebody would want to do a warm reset, but without a reboot, the memory remains corrupted.
Thanks, I had missed that. I should have read it more carefully. I think I quit reading it after the first couple of lines where it looked like he was still pushing his proposal. My previous response was actually more about evanh's proposal to change loadp2. I don't understand the need for the change. Maybe he'll explain it when he has a chance.
I was pretty much against any change at the outset.
It wasn't until I realised how separate the two issues really were, by Chip presenting a way to disentangle them, that I felt any desire for a change. You'd have to read all I've written in this conversation, and you can clearly see my only focus was the handover issue - https://forums.parallax.com/discussion/comment/1474393/#Comment_1474393
EDIT: The nice thing with doing the RCFAST handover is it has no impact on any mailbox proposals, because it eliminates the loader's dependence on the mailboxes.
It seems that people really want $00 allocated as a warm reset start or null pointer trap. To me, once booting has occurred, there's no going back. If you want to reboot, you need to reset the chip, not just launch a cog again from $00. Corrupted memory is probably why somebody would want to do a warm reset, but without a reboot, the memory remains corrupted.
Yes and no. A full chip reset, takes a long time. There are cases where someone may want to reload a memory image, and re-launch without having the whole P2 grind to a halt.
With 8 COG's I'd have expected being able to (re)start any cog is an important sales feature.
It seems that people really want $00 allocated as a warm reset start or null pointer trap. To me, once booting has occurred, there's no going back. If you want to reboot, you need to reset the chip, not just launch a cog again from $00. Corrupted memory is probably why somebody would want to do a warm reset, but without a reboot, the memory remains corrupted.
Yes and no. A full chip reset, takes a long time. There are cases where someone may want to reload a memory image, and re-launch without having the whole P2 grind to a halt.
With 8 COG's I'd have expected being able to (re)start any cog is an important sales feature.
You can always restart a cog. This has to do with restarting the central application.
We now can't fully use the low memory for larger directly indexed tables if we want compatibility with SPIN2 and the clock frequency long storage. Not ideal but looks like we will just need to live with it. Any custom system independent of SPIN2 can still obviously fully use this memory for its own purposes at least, so all is not lost.
TBH I don't think the low memory is very useful for tables. The main advantage of the low memory (below $100) is that it's directly addressable by immediate rdlong and wrlong instructions. The whole point of a table, on the other hand, is to look something up with a calculation, which would not be immediate.
Yep @ersmith, its advantage is when used for directly addressed lookup data using immediates which is a more specific case where this "table" index (from zero) is now really just the fixed address in the instruction. Mentioning using it for tables generically was not really the right term for what I meant.
I sort of wonder what the low memory addressing benefit now is going to be when running SPIN2. I guess if more "system" type longs are defined they could go there, but any agreement will obviously be difficult...
We now can't fully use the low memory for larger directly indexed tables if we want compatibility with SPIN2 and the clock frequency long storage. Not ideal but looks like we will just need to live with it. Any custom system independent of SPIN2 can still obviously fully use this memory for its own purposes at least, so all is not lost.
TBH I don't think the low memory is very useful for tables. The main advantage of the low memory (below $100) is that it's directly addressable by immediate rdlong and wrlong instructions. The whole point of a table, on the other hand, is to look something up with a calculation, which would not be immediate.
I'd agree, and do languages even currently make use of the more compact HUB VAR access allocations ?
Ideally, that needs a new memory segment (HUB_SHORT or HUB_NEAR or similar?) and because that space is 'community commons', a means to link across multiple languages is needed.
That would allow mail boxes to be placed anywhere in that space, but users are going to need to be frugal in use.
let me raise a possible alternative location for discussion....
What’s in the top of hubram? I know there are some interrupt vectors there. Is there a place just below them for the clock free and clock Mode? This of course can be write protected too.
Remember, the top of hubram is dual-mapped, but that is fine to address $F_FFxx or wherever.
The ROM code may just not use all of this and there could be a sore slot or two.
Chip, now is the time for us to work out these addresses which could be $04,$08 or $F8 and $FC even as it is still easily reached with un-augmented rdlong imediate. P1 Spin reserved the first 16 bytes anyway.
My original addresses were mainly for some functionality and I always had the option of changing it later. This has nothing to do with the ROM though, because what's in ROM, stays in ROM.
Yes @"Peter Jakacki" to the help.
Thankfully Chip agreed on $14 and $18 that opens up a discussion about $4-$10 for other agreed Mailboxes, or not.
let me raise a possible alternative location for discussion....
What’s in the top of hubram? I know there are some interrupt vectors there. Is there a place just below them for the clock free and clock Mode? This of course can be write protected too.
Remember, the top of hubram is dual-mapped, but that is fine to address $F_FFxx or wherever.
The ROM code may just not use all of this and there could be a sore slot or two.
I would really like to leave the top HUB untouched. it might change in future versions so placing something there is simply WRONG.
But having some agreed upon mailboxes below $14 could make sense everything above $1A is free for the application/whatever
let me raise a possible alternative location for discussion....
What’s in the top of hubram? I know there are some interrupt vectors there. Is there a place just below them for the clock free and clock Mode? This of course can be write protected too.
Remember, the top of hubram is dual-mapped, but that is fine to address $F_FFxx or wherever.
The ROM code may just not use all of this and there could be a sore slot or two.
I would really like to leave the top HUB untouched. it might change in future versions so placing something there is simply WRONG.
But having some agreed upon mailboxes below $14 could make sense everything above $1A is free for the application/whatever
Mike
If you recall, the top 16KB of hub ($FFC00+) initially gets loaded with a copy of the ROM. We can optionally write protect this.
This area is preferred for protected resident code, of which, interrupt vectors, code constants such as clockfreq, and other OS style routines such as SD drivers.
So for me, this seems like the logical place to put clockfreq, but we would need to avoid overwriting TACHYON which lives near the top. Of course, once something is running (besides the booter, the monitor/debugger, or Tachyon, then this area is free for any use.
FWIW, the my rom monitor/debugger overwrites Chip’s booter code for its input buffer (as agreed with Chip). And Tachyon copies itself down to hub $0, and thereafter its top hub ram is free for use.
So, the only reentrant rom code that survives post boot is my monitor/debugger and SD code, although missing write commands (which is minor, but missing as there was insufficient rom space).
BUT, I can live with wherever it is placed, as long as its there!
I'm wondering if below $200 should be kept free for use as fast and direct hub access...
This is where you can do a rdlong, for example, with immediate addressing.
Between $200 and $400 is a strange place.
Maybe system settings should go there...
Uh oh, now I've confused myself...
If you do rdlong with a 9-bit literal, does that 9-bit literal represent a long or a byte?
I think it's a byte...
In that case, it's just below $80 that you can use literal addressing on...
Manual says " #$00..$FF - 8-bit immediate hub address".
Why is it only 8 bits? Shouldn't it be 9?
So, I guess it's only below $100 that you can do immediate, "literal", hub access on...
rdlong immediate only uses 8-bits now (indexed modes) and hub is always byte addressed, whether that be bytes, words, or longs, so that means addresses $00..$FF where $FF can be a long from $FF..$102
Are you saying rdlong is 8-bits now due to the addition of indexed modes?
Also, what does "where $FF can be a long from $FF..$102" mean?
Ok, I think I see what you mean now with $FF..$102.
If you read a long from literal hub address of $FF, that long stretches over byte addresses of $FF to $102.
David Betz,
PropTool is written in Delphi and uses some closed source libs or something. Porting it out to a reasonable language would be kind of silly. The better path to take would be to make something new from scratch using Qt. You can get a reasonable IDE up and running in Qt in a couple days, I've done the basics a couple times but then gave up because it was easier to just use VS Code or notepad++ for myself.
There needs to be an open source cross platform IDE/compiler that is official, and it needs to be available at launch.
Yes, a clean implementation would probably be best. I was just thinking that many people here seem to love the PropellerTool and it's simple enough that it might not be too hard to translate it from Delphi into C and use the Qt widgets to implement the UI. On the other hand, the fact that it's simple probably means recreating it from scratch wouldn't be that hard either. I don't suggest starting with either SimpleIDE or PropellerIDE though.
I wonder, why the Delphi Pascal dialect is not considered a "reasonable language". Wouldn't cross-platform and open-source Free Pascal (https://freepascal.org/) and Lazarus (https://www.lazarus-ide.org/) be the first candidates to be looked at, when considering an update of a Delphi application?
By "reasonable", Roy probably meant unencumbered. I hacked up a FreePascal port of Chip's PX, which is also written in Delphi, for downloading the prop2 FPGA image files before realising I'd just messed up with Wine - it was working all along.
Even without having ever written a line of Pascal before, the only challenge was finding and interfacing a suitable cross-platform replacement for the comport libs. I struggled with the comport error handling but got it working by ignoring that part mostly.
Comments
Yes, but then each language would require its own function. It's much simpler if we just put it in a fixed location.
We've got a Las Vegas ROM, I agree.
It seems that people really want $00 allocated as a warm reset start or null pointer trap. To me, once booting has occurred, there's no going back. If you want to reboot, you need to reset the chip, not just launch a cog again from $00. Corrupted memory is probably why somebody would want to do a warm reset, but without a reboot, the memory remains corrupted.
I was pretty much against any change at the outset.
It wasn't until I realised how separate the two issues really were, by Chip presenting a way to disentangle them, that I felt any desire for a change. You'd have to read all I've written in this conversation, and you can clearly see my only focus was the handover issue - https://forums.parallax.com/discussion/comment/1474393/#Comment_1474393
EDIT: The nice thing with doing the RCFAST handover is it has no impact on any mailbox proposals, because it eliminates the loader's dependence on the mailboxes.
Yes and no. A full chip reset, takes a long time. There are cases where someone may want to reload a memory image, and re-launch without having the whole P2 grind to a halt.
With 8 COG's I'd have expected being able to (re)start any cog is an important sales feature.
You can always restart a cog. This has to do with restarting the central application.
TBH I don't think the low memory is very useful for tables. The main advantage of the low memory (below $100) is that it's directly addressable by immediate rdlong and wrlong instructions. The whole point of a table, on the other hand, is to look something up with a calculation, which would not be immediate.
I sort of wonder what the low memory addressing benefit now is going to be when running SPIN2. I guess if more "system" type longs are defined they could go there, but any agreement will obviously be difficult...
I'd agree, and do languages even currently make use of the more compact HUB VAR access allocations ?
Ideally, that needs a new memory segment (HUB_SHORT or HUB_NEAR or similar?) and because that space is 'community commons', a means to link across multiple languages is needed.
That would allow mail boxes to be placed anywhere in that space, but users are going to need to be frugal in use.
let me raise a possible alternative location for discussion....
What’s in the top of hubram? I know there are some interrupt vectors there. Is there a place just below them for the clock free and clock Mode? This of course can be write protected too.
Remember, the top of hubram is dual-mapped, but that is fine to address $F_FFxx or wherever.
The ROM code may just not use all of this and there could be a sore slot or two.
Yes @"Peter Jakacki" to the help.
Thankfully Chip agreed on $14 and $18 that opens up a discussion about $4-$10 for other agreed Mailboxes, or not.
why I think about Vegas right now?
Mike
I would really like to leave the top HUB untouched. it might change in future versions so placing something there is simply WRONG.
But having some agreed upon mailboxes below $14 could make sense everything above $1A is free for the application/whatever
Mike
If you recall, the top 16KB of hub ($FFC00+) initially gets loaded with a copy of the ROM. We can optionally write protect this.
This area is preferred for protected resident code, of which, interrupt vectors, code constants such as clockfreq, and other OS style routines such as SD drivers.
So for me, this seems like the logical place to put clockfreq, but we would need to avoid overwriting TACHYON which lives near the top. Of course, once something is running (besides the booter, the monitor/debugger, or Tachyon, then this area is free for any use.
FWIW, the my rom monitor/debugger overwrites Chip’s booter code for its input buffer (as agreed with Chip). And Tachyon copies itself down to hub $0, and thereafter its top hub ram is free for use.
So, the only reentrant rom code that survives post boot is my monitor/debugger and SD code, although missing write commands (which is minor, but missing as there was insufficient rom space).
BUT, I can live with wherever it is placed, as long as its there!
This is where you can do a rdlong, for example, with immediate addressing.
Between $200 and $400 is a strange place.
Maybe system settings should go there...
If you do rdlong with a 9-bit literal, does that 9-bit literal represent a long or a byte?
I think it's a byte...
In that case, it's just below $80 that you can use literal addressing on...
Why is it only 8 bits? Shouldn't it be 9?
So, I guess it's only below $100 that you can do immediate, "literal", hub access on...
RDLONG from $FF address
Where @ is a RDLONG..
Also, what does "where $FF can be a long from $FF..$102" mean?
Ok, I think I see what you mean now with $FF..$102.
If you read a long from literal hub address of $FF, that long stretches over byte addresses of $FF to $102.
I wonder, why the Delphi Pascal dialect is not considered a "reasonable language". Wouldn't cross-platform and open-source Free Pascal (https://freepascal.org/) and Lazarus (https://www.lazarus-ide.org/) be the first candidates to be looked at, when considering an update of a Delphi application?
Even without having ever written a line of Pascal before, the only challenge was finding and interfacing a suitable cross-platform replacement for the comport libs. I struggled with the comport error handling but got it working by ignoring that part mostly.