Phil,
PropTool being windows only is the biggest reason to not do anything more with it. If it was cross platform already then the closed source aspect wouldn't matter as much, but that it it windows only it the deal breaker.
I think Chip's first task with Spin2 is to make it a command line compiler that just takes spin2 source and produces compiled binaries. Everything else can build from that.
Having the only official compiler being locked away as part of an IDE that only works on windows AND is closed source is a deadend and waste of time/money.
If the propeller tool is going to be revisited in code, might there be time to investigate the long standing bug that prevents large programs from being uploaded to a propeller over anything other than a FutureTech FT23x chip?
I am willing to supply Parallax with a prop-plug based on the CH340 UART for testing.
What does 'large' mean here ?
Do you have more details on what fails, and how it fails ?
Using USB-UARTs, I've only seen one issue with download size, and that is in EXAR drivers themselves, with a single file send of > 500kBytes.
There are of course issues with download speed, and half duplex vs full duplex vs echo.. but usually you have to be well over 1MBd to hit those.
A program (as viewed in the object info window) of 4195 longs or less works fine when uploading to a propeller.
A program of 4196 or greater throws up a "Write Failure on COMx".
Other propeller programming tools don't have this problem with the CH340.
If memory serves, the SiLabs CP2102 exhibits the same behavior when used with Propeller Tool.
There have been several discussions about this over the years in the Prop 1 forum.
Chip, let me know where and to who's attn to send one of these prop plugs to. I'll have it in the mail tomorrow.
If it's on Amazon, just send me a link and I'll buy it. Otherwise, you can send it to:
Parallax, attn: Jeff Martin
599 Menlo Drive, #100
Rocklin CA 95765
Does Pnut run (compile code) when working under Wine or whatever on other platforms ? I know there might be serial load issues, but what about just compiling (pasm2 now, spin2 soon) code?
Pnut already loads a file when you type it on the command line, eg PNUT MYFILE.SPIN2
I think this was thanks to Peter's requests, and some from others too
We were originally chasing the next step, which was a command line argument (eg /RUN) to also try and load the code (like pressing F11 key).
I guess a /COMPILE command would be the most useful at this point
At the risk at repeating myself again, what is wrong with Visual Studio Code?
This (from wikipedia):
Visual Studio Code collects usage data and sends it to Microsoft, although this telemetry reporting can be disabled. The data is shared among Microsoft-controlled affiliates and subsidiaries and with law enforcement, per the privacy statement.
I won't use Windows 10 for the same reason. Sure, you are supposed to be able to disable such things, but in practice you find you cannot. Every time you turn your back you find it has re-enabled itself somehow
I'm thinking I'll rearrange the RESULT, parameters, and local variables as such:
PRI method(a,b,c,d) : w,x,y,z | i,j,k,l,m,n,o,p
index: 0 1 2 3 4 5 6 7 8 9 A B C D E F
type: params results local variables
initial: caller zero'd unknown
No reason to front-load RESULT when it could be more than a long.
ABORT will only return a single value, in this scheme, and it can always be some error code.
At the risk at repeating myself again, what is wrong with Visual Studio Code?
This (from wikipedia):
Visual Studio Code collects usage data and sends it to Microsoft, although this telemetry reporting can be disabled. The data is shared among Microsoft-controlled affiliates and subsidiaries and with law enforcement, per the privacy statement.
I won't use Windows 10 for the same reason. Sure, you are supposed to be able to disable such things, but in practice you find you cannot. Every time you turn your back you find it has re-enabled itself somehow
I don’t know if this is true or not. However, since the source is out there, I would have thought there would be information on disabling it. Somehow, I just think it’s scaremongering on VSC. W10 is a different matter tho.
But my point is that there are now many open source and cross-platform editors. Too many in fact. Everyone has their favourite and that’s fine. I just don’t see any point in resurrecting an archaic piece of software (PropTool) which has been described as unmaintainable when simple basic fixes or enhancements have been requested over the past 10 years. We need to support the guys that are doing the work, not resurrect garbage.
I do agree with @Cluso99, but I am not in the 'either or group'.
Let chip write in 86 assembler, build a PropTool, finalize his thoughts about how spin2 needs to work, in his flavor.
Once there Roy will take over, he already knows the 20+ year old source and chips thinking/way of programming. My guess is that Roy will need less time to produce openspin2 than he needed for openspin1.
Let chip work in what he feels fine with, the result is what matters, it will get cross-platform later.
Does P2load currently support the WIFI loading option used by Blockly and the WX boards? If not this should be merged from the P1loader to make this available for future P2 boards.
No, it doesn't. The WX firmware will also have to be changed to allow wifi loading of the P2 since the WX firmware handles the P1 loader protocol and doesn't support the P2 loader protocol.
I'm thinking I'll rearrange the RESULT, parameters, and local variables as such:
PRI method(a,b,c,d) : w,x,y,z | i,j,k,l,m,n,o,p
index: 0 1 2 3 4 5 6 7 8 9 A B C D E F
type: params results local variables
initial: caller zero'd unknown
No reason to front-load RESULT when it could be more than a long.
The syntax is the same (except that multiple return values are allowed), you're just proposing to change where they're stored on the stack? That sounds good to me. fastspin put the return values in memory first (for Spin1 compatibility) but I can change it and it's a corner case anyway: normally all the values are kept in registers.
This is a cool feature in Spin1 I learned reading code written by kye (Fat32_engine). Using the Parameter as Array. Eric does not like it because he want to be able to keep some parameter in registers, not HUB. Not sure about his current set of mind there.
I like it to provide Parameter Blocks to PASM functions, not just at start, also later.
Are they available in hub so that long[@a+index] will work like in spin1?
I really like and use that in Spin1
I'd like to put a big warning here that doing that kind of thing can really hurt performance in compiled code, because memory accesses are slow and they interfere with optimization. For example, here are two very similar Spin functions. The first uses regular variable names, the second uses memory offsets:
PUB sum1(a, b, c) : r
r := a
r += b
r += c
PUB sum2(a, b, c) : r
r := a
r += long[@a + 4]
r += long[@a + 8]
Here's the P1 code that is produced by fastspin for these. "sum2" is very much larger and slower.
Are they available in hub so that long[@a+index] will work like in spin1?
I really like and use that in Spin1
I'd like to put a big warning here that doing that kind of thing can really hurt performance in compiled code, because memory accesses are slow and they interfere with optimization. For example, here are two very similar Spin functions. The first uses regular variable names, the second uses memory offsets:
PUB sum1(a, b, c) : r
r := a
r += b
r += c
PUB sum2(a, b, c) : r
r := a
r += long[@a + 4]
r += long[@a + 8]
Here's the P1 code that is produced by fastspin for these. "sum2" is very much larger and slower.
I'm thinking I'll rearrange the RESULT, parameters, and local variables as such:
PRI method(a,b,c,d) : w,x,y,z | i,j,k,l,m,n,o,p
index: 0 1 2 3 4 5 6 7 8 9 A B C D E F
type: params results local variables
initial: caller zero'd unknown
No reason to front-load RESULT when it could be more than a long.
The syntax is the same (except that multiple return values are allowed), you're just proposing to change where they're stored on the stack? That sounds good to me. fastspin put the return values in memory first (for Spin1 compatibility) but I can change it and it's a corner case anyway: normally all the values are kept in registers.
Yeah, just stored differently. I think ABORT will become an instruction which requires an argument and returns it to the root caller. Good for error trapping. We can't be returning different numbers of arguments on an ABORT, because it would mismatch the expectation of the root caller.
If the propeller tool is going to be revisited in code, might there be time to investigate the long standing bug that prevents large programs from being uploaded to a propeller over anything other than a FutureTech FT23x chip?
I am willing to supply Parallax with a prop-plug based on the CH340 UART for testing.
What does 'large' mean here ?
Do you have more details on what fails, and how it fails ?
Using USB-UARTs, I've only seen one issue with download size, and that is in EXAR drivers themselves, with a single file send of > 500kBytes.
There are of course issues with download speed, and half duplex vs full duplex vs echo.. but usually you have to be well over 1MBd to hit those.
A program (as viewed in the object info window) of 4195 longs or less works fine when uploading to a propeller.
A program of 4196 or greater throws up a "Write Failure on COMx".
Other propeller programming tools don't have this problem with the CH340.
If memory serves, the SiLabs CP2102 exhibits the same behavior when used with Propeller Tool.
There have been several discussions about this over the years in the Prop 1 forum.
Chip, let me know where and to who's attn to send one of these prop plugs to. I'll have it in the mail tomorrow.
If it's on Amazon, just send me a link and I'll buy it. Otherwise, you can send it to:
Parallax, attn: Jeff Martin
599 Menlo Drive, #100
Rocklin CA 95765
(916) 624-8333
Thanks, Martin.
Package sent, should have two units on Thursday. It's an actual prop plug I designed with reset circuit and compatible pinout, so it's not on Amazon. It's a low priority issue, but it would be nice to be able to use USB UART chips other than FT with Propeller Tool.
Are they available in hub so that long[@a+index] will work like in spin1?
I really like and use that in Spin1
I'd like to put a big warning here that doing that kind of thing can really hurt performance in compiled code, because memory accesses are slow and they interfere with optimization. For example, here are two very similar Spin functions. The first uses regular variable names, the second uses memory offsets:
PUB sum1(a, b, c) : r
r := a
r += b
r += c
PUB sum2(a, b, c) : r
r := a
r += long[@a + 4]
r += long[@a + 8]
Here's the P1 code that is produced by fastspin for these. "sum2" is very much larger and slower.
Are they available in hub so that long[@a+index] will work like in spin1?
I really like and use that in Spin1
I'd like to put a big warning here that doing that kind of thing can really hurt performance in compiled code, because memory accesses are slow and they interfere with optimization. For example, here are two very similar Spin functions. The first uses regular variable names, the second uses memory offsets:
PUB sum1(a, b, c) : r
r := a
r += b
r += c
PUB sum2(a, b, c) : r
r := a
r += long[@a + 4]
r += long[@a + 8]
Here's the P1 code that is produced by fastspin for these. "sum2" is very much larger and slower.
Package sent, should have two units on Thursday. It's an actual prop plug I designed with reset circuit and compatible pinout, so it's not on Amazon.
It's a low priority issue, but it would be nice to be able to use USB UART chips other than FT with Propeller Tool.
Yes, certainly needs to be portable across USB-COM ports, and CP2102N / EFM8UB3 / VCPXpress from Silabs are on P2D2 as the Serial Bridge. (same Silabs driver )
The Eval boards for CP2102N are CP2102N-MINIEK, CP2102N-EK, mikroElektronika MIKROE-3063 etc.
Addit : https://www.electrodragon.com/product/cp2102-usb-ttl-uart-module-v2/ is just $2.20, and brings out all pins. Less clear if that is CP2102N chip. (N suffix is newer revision part)
If the propeller tool is going to be revisited in code, might there be time to investigate the long standing bug that prevents large programs from being uploaded to a propeller over anything other than a FutureTech FT23x chip?
I am willing to supply Parallax with a prop-plug based on the CH340 UART for testing.
What does 'large' mean here ?
Do you have more details on what fails, and how it fails ?
Using USB-UARTs, I've only seen one issue with download size, and that is in EXAR drivers themselves, with a single file send of > 500kBytes.
There are of course issues with download speed, and half duplex vs full duplex vs echo.. but usually you have to be well over 1MBd to hit those.
A program (as viewed in the object info window) of 4195 longs or less works fine when uploading to a propeller.
A program of 4196 or greater throws up a "Write Failure on COMx".
Other propeller programming tools don't have this problem with the CH340.
If memory serves, the SiLabs CP2102 exhibits the same behavior when used with Propeller Tool.
There have been several discussions about this over the years in the Prop 1 forum.
Chip, let me know where and to who's attn to send one of these prop plugs to. I'll have it in the mail tomorrow.
If it's on Amazon, just send me a link and I'll buy it. Otherwise, you can send it to:
Parallax, attn: Jeff Martin
599 Menlo Drive, #100
Rocklin CA 95765
(916) 624-8333
Thanks, Martin.
Package sent, should have two units on Thursday. It's an actual prop plug I designed with reset circuit and compatible pinout, so it's not on Amazon. It's a low priority issue, but it would be nice to be able to use USB UART chips other than FT with Propeller Tool.
...
I am willing to supply Parallax with a prop-plug based on the CH340 UART for testing...
It's an actual prop plug I designed with reset circuit and compatible pinout, so it's not on Amazon..
Curious if you did any sustained speed/throughput tests on that CH340 ?
It seems to support only a few higher baud choices ? (921600, 1500000, 2000000 baud)
Hi Chip
I finally got my debugger working with your spin2 interpreter.
It's still a work in progress but is showing good results now.
Here's a sneak peek at some debug output of your pin toggle test code.
...
I am willing to supply Parallax with a prop-plug based on the CH340 UART for testing...
It's an actual prop plug I designed with reset circuit and compatible pinout, so it's not on Amazon..
Curious if you did any sustained speed/throughput tests on that CH340 ?
It seems to support only a few higher baud choices ? (921600, 1500000, 2000000 baud)
I have not. I'll send one to you if you care to run those tests.
Hi Chip
I finally got my debugger working with your spin2 interpreter.
It's still a work in progress but is showing good results now.
Here's a sneak peek at some debug output of your pin toggle test code.
One question: Why does the '_RET_ SETQ #$D1' show a NOP after, but the other _RET_'s don't?
Ah yes,
The disassembler normally assumes a SETQ/2 is paired to the following instruction in a step cycle.
I will tweak that to test the top of stack for a $1FF and ignore the following instruction.
One question: Why does the '_RET_ SETQ #$D1' show a NOP after, but the other _RET_'s don't?
Ah yes,
The disassembler normally assumes a SETQ/2 is paired to the following instruction in a step cycle.
I will tweak that to test the top of stack for a $1FF and ignore the following instruction.
Chip,
I happen to be looking at the interpreter source code and it looks like you may have a bug with the "clkset" routine.
test w,#%10 wz 'if xtal or pll then switch to 20MHz for ~10ms
if_nz mov y,w
if_nz andn y,#%11
if_nz hubset y
if_nz waitx ##20_000_000/100
hubset w 'set final mode
That looks to be the new target setting being used as basis of switch to RCFAST. What's needed is the prior clock setting for basis of switchover to prevent the flaw from triggering.
EDIT: Err, it's dawned on me you've not attempted the workaround at all. Might be a good idea to add it at some stage.
Comments
PropTool being windows only is the biggest reason to not do anything more with it. If it was cross platform already then the closed source aspect wouldn't matter as much, but that it it windows only it the deal breaker.
I think Chip's first task with Spin2 is to make it a command line compiler that just takes spin2 source and produces compiled binaries. Everything else can build from that.
Having the only official compiler being locked away as part of an IDE that only works on windows AND is closed source is a deadend and waste of time/money.
If it's on Amazon, just send me a link and I'll buy it. Otherwise, you can send it to:
Parallax, attn: Jeff Martin
599 Menlo Drive, #100
Rocklin CA 95765
(916) 624-8333
Thanks, Martin.
Pnut already loads a file when you type it on the command line, eg PNUT MYFILE.SPIN2
I think this was thanks to Peter's requests, and some from others too
We were originally chasing the next step, which was a command line argument (eg /RUN) to also try and load the code (like pressing F11 key).
I guess a /COMPILE command would be the most useful at this point
This (from wikipedia):
I won't use Windows 10 for the same reason. Sure, you are supposed to be able to disable such things, but in practice you find you cannot. Every time you turn your back you find it has re-enabled itself somehow
No reason to front-load RESULT when it could be more than a long.
ABORT will only return a single value, in this scheme, and it can always be some error code.
Are they available in hub so that long[@a+index] will work like in spin1?
I really like and use that in Spin1
Enjoy!
Mike
I don’t know if this is true or not. However, since the source is out there, I would have thought there would be information on disabling it. Somehow, I just think it’s scaremongering on VSC. W10 is a different matter tho.
But my point is that there are now many open source and cross-platform editors. Too many in fact. Everyone has their favourite and that’s fine. I just don’t see any point in resurrecting an archaic piece of software (PropTool) which has been described as unmaintainable when simple basic fixes or enhancements have been requested over the past 10 years. We need to support the guys that are doing the work, not resurrect garbage.
Let chip write in 86 assembler, build a PropTool, finalize his thoughts about how spin2 needs to work, in his flavor.
Once there Roy will take over, he already knows the 20+ year old source and chips thinking/way of programming. My guess is that Roy will need less time to produce openspin2 than he needed for openspin1.
Let chip work in what he feels fine with, the result is what matters, it will get cross-platform later.
Mike
Yes. And they are in exact order of declaration.
The syntax is the same (except that multiple return values are allowed), you're just proposing to change where they're stored on the stack? That sounds good to me. fastspin put the return values in memory first (for Spin1 compatibility) but I can change it and it's a corner case anyway: normally all the values are kept in registers.
This is a cool feature in Spin1 I learned reading code written by kye (Fat32_engine). Using the Parameter as Array. Eric does not like it because he want to be able to keep some parameter in registers, not HUB. Not sure about his current set of mind there.
I like it to provide Parameter Blocks to PASM functions, not just at start, also later.
instead of having
VAR LONG ringnetAddress LONG ringnetSize LONG outPinData LONG outPinMode LONG outPinBitclocks LONG inPinData LONG inPinMode LONG inPinBitclocks LONG lockNumber '- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - LONG lockId LONG cogId '----------------------------------------------------------------------- PUB Stop if cogId cogstop(cogId-1) Release '----------------------------------------------------------------------- PUB Start(ringBufferHubAddress, ringBufferSizeInLongs, outPin_data, outPin_mode, outPin_bitclocks, inPin_data, inPin_mode, inPin_bitclocks, lockToUse) Stop ringnetAddress := ringBufferHubAddress ringnetSize := ringBufferSizeInLongs outPinData := outPin_data outPinMode := outPin_mode outPinBitclocks := outPin_bitclocks inPinData := inPin_data inPinMode := inPin_mode inPinBitclocks := inPin_bitclocks lockNumber := lockToUse '- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - cogId := cognew(@ringnet_ptr, @ringnetAddress)+1 lockId := lockToUsejust have
VAR LONG lockId LONG cogId '----------------------------------------------------------------------- PUB Stop if cogId cogstop(cogId-1) Release '----------------------------------------------------------------------- PUB Start(ringBufferHubAddress, ringBufferSizeInLongs, outPin_data, outPin_mode, outPin_bitclocks, inPin_data, inPin_mode, inPin_bitclocks, lockToUse) Stop cogId := cognew(@ringnet_ptr, @ringBufferHubAddress)+1 lockId := lockToUsenicer,
Mike
Here's the P1 code that is produced by fastspin for these. "sum2" is very much larger and slower.
What a difference!
Yeah, just stored differently. I think ABORT will become an instruction which requires an argument and returns it to the root caller. Good for error trapping. We can't be returning different numbers of arguments on an ABORT, because it would mismatch the expectation of the root caller.
Package sent, should have two units on Thursday. It's an actual prop plug I designed with reset circuit and compatible pinout, so it's not on Amazon. It's a low priority issue, but it would be nice to be able to use USB UART chips other than FT with Propeller Tool.
I admit that this is not a good idea and will stop using it.
Enjoy!
Mike
I think this must be the secret sauce in these modern 1GB installs. I think they've even found a way to exponentialize it.
Yes, certainly needs to be portable across USB-COM ports, and CP2102N / EFM8UB3 / VCPXpress from Silabs are on P2D2 as the Serial Bridge. (same Silabs driver )
The Eval boards for CP2102N are CP2102N-MINIEK, CP2102N-EK, mikroElektronika MIKROE-3063 etc.
Addit :
https://www.electrodragon.com/product/cp2102-usb-ttl-uart-module-v2/ is just $2.20, and brings out all pins. Less clear if that is CP2102N chip. (N suffix is newer revision part)
Super! Thanks, Martin.
Curious if you did any sustained speed/throughput tests on that CH340 ?
It seems to support only a few higher baud choices ? (921600, 1500000, 2000000 baud)
I finally got my debugger working with your spin2 interpreter.
It's still a work in progress but is showing good results now.
Here's a sneak peek at some debug output of your pin toggle test code.
~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000004 %00000000_00000000_00000000_00000100 4 w COG $145: $000011D0 %00000000_00000000_00010001_11010000 4560 ptra COG $1F8: $000011F4 %0000_0000000_000_000001000_111110100 4596 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Cog #5 FLAGS: nc nz BRK:$00 RDFAST:$011D9 Description: ??? PA = $1AA807 (bytecode) PB = $00000 RFVARS: 39 1E0: 0D65A228 buff _RET_ SETQ #$d1 1E1: 00000000 wr NOP <LOG>[Hex](step) > ~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000004 %00000000_00000000_00000000_00000100 4 w COG $145: $000011D0 %00000000_00000000_00010001_11010000 4560 ptra COG $1F8: $000011F4 %0000_0000000_000_000001000_111110100 4596 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Cog #5 FLAGS: nc Z BRK:$00 RDFAST:$011DA Description: "bc_con_0" PA = $39 (bytecode) PB = $011DA RFVARS: 2e 317: FC668D61 const WRLONG x,PTRA++ <LOG>[Hex](step) > ~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000004 %00000000_00000000_00000000_00000100 4 w COG $145: $000011D0 %00000000_00000000_00010001_11010000 4560 ptra COG $1F8: $000011F8 %0000_0000000_000_000001000_111111000 4600 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Cog #5 FLAGS: nc Z BRK:$00 RDFAST:$011DA Description: "bc_con_0" PA = $39 (bytecode) PB = $011DA RFVARS: 2e 318: F6028DF6 MOV x,PA <LOG>[Hex](step) > ~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000039 %00000000_00000000_00000000_00111001 57 w COG $145: $000011D0 %00000000_00000000_00010001_11010000 4560 ptra COG $1F8: $000011F8 %0000_0000000_000_000001000_111111000 4600 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Cog #5 FLAGS: nc Z BRK:$00 RDFAST:$011DA Description: "bc_con_0" PA = $39 (bytecode) PB = $011DA RFVARS: 2e 319: 01868C39 _RET_ SUB x,#$39 <LOG>[Hex](step) > ~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000000 %00000000_00000000_00000000_00000000 0 w COG $145: $000011D0 %00000000_00000000_00010001_11010000 4560 ptra COG $1F8: $000011F8 %0000_0000000_000_000001000_111111000 4600 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 SKIP pattern: %1110 SKIPM:0 CALL depth = 0 Cog #5 FLAGS: C nz BRK:$00 RDFAST:$011DB Description: "bc_pinnot" PA = $2E (bytecode) PB = $011DB RFVARS: f 2E9: FD628C5F pinnot_ DRVNOT x <LOG>[Hex](step) > ~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000000 %00000000_00000000_00000000_00000000 0 w COG $145: $000011D0 %00000000_00000000_00010001_11010000 4560 ptra COG $1F8: $000011F8 %0000_0000000_000_000001000_111111000 4600 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Cog #5 FLAGS: C nz BRK:$00 RDFAST:$011DB Description: "bc_pinnot" PA = $2E (bytecode) PB = $011DB RFVARS: f 2ED: 0B068D5F _RET_ RDLONG x,--PTRA <LOG>[Hex](step) > ~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000004 %00000000_00000000_00000000_00000100 4 w COG $145: $000011D0 %00000000_00000000_00010001_11010000 4560 ptra COG $1F8: $000011F4 %0000_0000000_000_000001000_111110100 4596 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 SKIP pattern: %1111011111110 SKIPM:0 CALL depth = 0 Cog #5 FLAGS: C Z BRK:$00 RDFAST:$011DC Description: "bc_jmp" PA = $0F (bytecode) PB = $011DC RFVARS: 7d 2D3: FD628A14 branch RFVARS w <LOG>[Hex](step) > ~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000004 %00000000_00000000_00000000_00000100 4 w COG $145: $FFFFFFFD %11111111_11111111_11111111_11111101 4294967293 ptra COG $1F8: $000011F4 %0000_0000000_000_000001000_111110100 4596 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 SKIP pattern: %11110 SKIPM:0 CALL depth = 0 Cog #5 FLAGS: C Z BRK:$00 RDFAST:$011DD Description: "bc_jmp" PA = $0F (bytecode) PB = $011DC RFVARS: 0 2DB: F103EF45 ADD PB,w <LOG>[Hex](step) > ~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000004 %00000000_00000000_00000000_00000100 4 w COG $145: $FFFFFFFD %11111111_11111111_11111111_11111101 4294967293 ptra COG $1F8: $000011F4 %0000_0000000_000_000001000_111110100 4596 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Cog #5 FLAGS: C Z BRK:$00 RDFAST:$011DD Description: "bc_jmp" PA = $0F (bytecode) PB = $011D9 RFVARS: 0 2E0: 0C7801F7 _RET_ RDFAST #clkfreq_hub,PB <LOG>[Hex](step) > ~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000004 %00000000_00000000_00000000_00000100 4 w COG $145: $FFFFFFFD %11111111_11111111_11111111_11111101 4294967293 ptra COG $1F8: $000011F4 %0000_0000000_000_000001000_111110100 4596 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Cog #5 FLAGS: nc Z BRK:$00 RDFAST:$011DA Description: "bc_con_0" PA = $39 (bytecode) PB = $011DA RFVARS: 2e 317: FC668D61 const WRLONG x,PTRA++ <LOG>[Hex](step) > ~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000004 %00000000_00000000_00000000_00000100 4 w COG $145: $FFFFFFFD %11111111_11111111_11111111_11111101 4294967293 ptra COG $1F8: $000011F8 %0000_0000000_000_000001000_111111000 4600 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Cog #5 FLAGS: nc Z BRK:$00 RDFAST:$011DA Description: "bc_con_0" PA = $39 (bytecode) PB = $011DA RFVARS: 2e 318: F6028DF6 MOV x,PA <LOG>[Hex](step) > ~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000039 %00000000_00000000_00000000_00111001 57 w COG $145: $FFFFFFFD %11111111_11111111_11111111_11111101 4294967293 ptra COG $1F8: $000011F8 %0000_0000000_000_000001000_111111000 4600 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Cog #5 FLAGS: nc Z BRK:$00 RDFAST:$011DA Description: "bc_con_0" PA = $39 (bytecode) PB = $011DA RFVARS: 2e 319: 01868C39 _RET_ SUB x,#$39 <LOG>[Hex](step) > ~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000000 %00000000_00000000_00000000_00000000 0 w COG $145: $FFFFFFFD %11111111_11111111_11111111_11111101 4294967293 ptra COG $1F8: $000011F8 %0000_0000000_000_000001000_111111000 4600 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 SKIP pattern: %1110 SKIPM:0 CALL depth = 0 Cog #5 FLAGS: C nz BRK:$00 RDFAST:$011DB Description: "bc_pinnot" PA = $2E (bytecode) PB = $011DB RFVARS: f 2E9: FD628C5F pinnot_ DRVNOT x <LOG>[Hex](step) > ~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000000 %00000000_00000000_00000000_00000000 0 w COG $145: $FFFFFFFD %11111111_11111111_11111111_11111101 4294967293 ptra COG $1F8: $000011F8 %0000_0000000_000_000001000_111111000 4600 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Cog #5 FLAGS: C nz BRK:$00 RDFAST:$011DB Description: "bc_pinnot" PA = $2E (bytecode) PB = $011DB RFVARS: f 2ED: 0B068D5F _RET_ RDLONG x,--PTRA <LOG>[Hex](step) > ~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000004 %00000000_00000000_00000000_00000100 4 w COG $145: $FFFFFFFD %11111111_11111111_11111111_11111101 4294967293 ptra COG $1F8: $000011F4 %0000_0000000_000_000001000_111110100 4596 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 SKIP pattern: %1111011111110 SKIPM:0 CALL depth = 0 Cog #5 FLAGS: C Z BRK:$00 RDFAST:$011DC Description: "bc_jmp" PA = $0F (bytecode) PB = $011DC RFVARS: 7d 2D3: FD628A14 branch RFVARS w <LOG>[Hex](step) > ~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000004 %00000000_00000000_00000000_00000100 4 w COG $145: $FFFFFFFD %11111111_11111111_11111111_11111101 4294967293 ptra COG $1F8: $000011F4 %0000_0000000_000_000001000_111110100 4596 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 SKIP pattern: %11110 SKIPM:0 CALL depth = 0 Cog #5 FLAGS: C Z BRK:$00 RDFAST:$011DD Description: "bc_jmp" PA = $0F (bytecode) PB = $011DC RFVARS: 0 2DB: F103EF45 ADD PB,w <LOG>[Hex](step) > ~~~~~~~~~~~~~~ Propeller 2 Debugger 5.2 - 4th July 2019 ozpropdev ~~~~~~~~~~~~~~ x COG $146: $00000004 %00000000_00000000_00000000_00000100 4 w COG $145: $FFFFFFFD %11111111_11111111_11111111_11111101 4294967293 ptra COG $1F8: $000011F4 %0000_0000000_000_000001000_111110100 4596 TOS: 000001FF 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Cog #5 FLAGS: C Z BRK:$00 RDFAST:$011DD Description: "bc_jmp" PA = $0F (bytecode) PB = $011D9 RFVARS: 0 2E0: 0C7801F7 _RET_ RDFAST #clkfreq_hub,PB <LOG>[Hex](step) >hexb @pb 011D9: 39 2E 0F 7D 00 00 00 D6 11 00 00 E0 11 00 00 F0 011E9: 11 00 00 D0 11 00 00 00 00 00 00 04 00 00 00 00 011F9: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01209: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00I have not. I'll send one to you if you care to run those tests.
Looks great, Brian!
One question: Why does the '_RET_ SETQ #$D1' show a NOP after, but the other _RET_'s don't?
The disassembler normally assumes a SETQ/2 is paired to the following instruction in a step cycle.
I will tweak that to test the top of stack for a $1FF and ignore the following instruction.
That should do it.
Great.
I happen to be looking at the interpreter source code and it looks like you may have a bug with the "clkset" routine. That looks to be the new target setting being used as basis of switch to RCFAST. What's needed is the prior clock setting for basis of switchover to prevent the flaw from triggering.
EDIT: Err, it's dawned on me you've not attempted the workaround at all. Might be a good idea to add it at some stage.