I think I might have found another bug in SX-Sim. Suppose the simulation is running, and you reach a breakpoint. If you click back and end up back in an interrupt, the shadow registers will not be loaded with the correct values,·but they will all contain zero. When you step forward and reach a reti or retiw, the execution jumps at 000h, and when it reaches reti or retiw the second time, it generates a "reti without interrupt" error.
Please, if you can, take the time to review this matter, and perhaps release a fix, as I rely completely on SX-Sim for debugging.
I assume that you launch SXSim from the SX-Key IDE by clicking the IDE's SXSim button. In this case, the IDE re-assembles the source code to make sure that the list file is up-to-date, and then launches SXSim with the command line containing the list file name. SXSim then checks the list file's time/date stamp if this file is "younger" than the associated SIM file it has saved before. When this is the case, the "Restore Breakpoint" dialog is opened, as the breakpoints stored in the SIM file might no longer match in case you have removed or added instructions from/to the source code.
If I got you right, I assume you want to test a program with SXSim, switch back to the SX-Key IDE from time to time (or by accident), and then return to SXSim. You can do this by clicking into the IDE window (or hit Alt-Tab). As I have defined the SXSim Commands window to always stay on top, this will hide parts if the IDE's Edit window but you should be able to return to SXSim by either hitting Alt-Tab again, or by clicking into the SXSim Commands window. In this case, you should be able to continue the simulation from the most recent point on. When you quit SXSim to restore the IDE windows, and click the IDE's SXSim button later, SXSim is re-launched again, and it re-loads the list file, so you can't continue the simulation but have to re-start it again. To avoid this, I could add an option to "freeze" the current status of all SX registers in the SIM file so that they can be restored for the next session. I'll add this to my TODO list.
2. Undoing shadow registers
Congratulations - you have found a bug! Thanks to your report, I found that the shadow registers and the FIFO were not always correctly restored when the "Back" button was clicked. I have fixed this in the meantime, and will release a new version soon.
Thank you for taking the time to review this matter. I am looking forward to a new version of SX-Sim. In the meantime, I will be careful when running my simulations.
I would like to suggest that you also compile and release SX-Sim for x64 systems. Although there is no problem in running SX-Sim on x64 OS's, the larger instructions will speed up the simulation, and reduce the execution time in most cases.
Sincerely,
Alex
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Fear not that your project does not work, for it will,
Fear not if you see·a long dark path ahead, but follow it,
Fear not if what worked now refuses to,
For the only thing that's perfect is imperfection.
Add a control button or a drop down menu· to·reduce the amount of information displayed by sx sim for newbies like me, that are using it for mainly timing issues with SX/B. Because I still don't understand what everything in the display window does, I find it overwhelming, there is a lot of stuff is going on in a very small space. I didn't use the program for sometime because of that,·now I find it invaluable to determine the order in which I place my time based SX/B functions.
I used the latest sxsim to test some taskswitching code using the secret instructions.
3 observations:
a)
When I enter the isr routine for the first time, I see the 1st entries of the shadow stacks
loaded with the·states prior to the interrupt, with the 2nd entries 0.
b)
To perform a switch I then use the secret pop instructions. I see the 1st level entries
being copied to W, but I don't see the 2nd level entries being copied·to the 1st level entries,
which I think should be the case.
c)
When I use the secret push instructions, I see the 1st level entries being copied to the
2nd level entries, and W being copied to the 1st level entries, as it should.
Questions:
Can we assume that the shadow stack holds all 0's upon reset?
If not, why not leave the fields blank, as with the call stack.
A blank field would indicate a void value (location has never been accessed).
Could we also have blank fields in the ram area? Now they are filled with random values,
but do we really need to see these values while locations never have been accessed?
You could keep the values hidden until a location is accessed, then display it.
thank you for the bug report. Yes, you are right, RTCC interrupts are enabled with OPTION.6 clear, and disabled with the bit set. In the meantime, I have fixed the tooltip text. It will be published with the next version of SXSim I'll release.
I believe SxSim does not handle ret and retp correctly in respect
to the displayed active line.
Single step the attached program and observe stack, PC and PAx whenever
there is a call or ret or retp.
There are deliberate errors in the listing, that is some ret's must be retp
but the point here is that although the PC and PAx are set corectly
after a ret (PAx unchanged) or retp (PAx updated) the active line
jumps to the correct line as the program was intended but I believe
the active line is not at the correct page.
Hi Gunther,
Forget my last bug report. SxSim handles ret and retp correctly.
I thought that ret only restored the lower bits of PC, but in fact
ALL bits from the shadow stack are moved back into PC, wether
I use ret or retp. In addition retp copies the topbits to the
page bits.
don't worry about your last bug report. It made me double-check if SXSim handles RET and RETP correctly, and I verified that it does. Nevertheless, before posting an answer, I wanted to do the same tests with the SX-Key Debugger, just to be sure, but I did not have the time so far to do it.
Therefore, your new message came in just in time .
As with everyone thanks for the simulator tool for the SX. I just have a couple of thing that would be nice.
1) The Command window is defined as Stay On Top of EVERYTHING and not just on top of the SxSim window. It gets in the way when I am debugging and need to look at the documentation to figure out what is suppose to be happening.
2) Can you add a keyboard interface for SxSim? I am a keyboarder not a mouse fan when debugging. The typical keys from MPLAB would be nice
F9 = Run
F5 = Stop
F7 = Single Step
F8 = Step over
F? = Back (pick one!)
3) In Vista the scrollbar for the Listview is partially under the right side main window frame. (the calculation for the listview width is not correct for a Vista main window).
I appreciate your SXSIM efforts. I have a request. I'm probably the only one who uses the SX in non-turbo mode, but is it possible to have a turbo/ non-turbo selection? Simply decreasing the FREQ directive by 4 doesn't completely take care of the timing differences. For instance, the JMP command takes 8 cycles in non-turbo (1:4 execution) compared to 3 cycles (1:1 execution) .
Thanks, Kevin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Bad spellers of the world untie!
yes, indeed, this is on my TODO list since a long time. My idea is to implement the watch directives similar to the SX-Key IDE plus some more "sophisticated" methods. Unfortunately, some other projects keep me really busy right now, so it will take a while until I can come back to do some more work on SXSim. Nevertheless, the "Watch" is on the list, and I won't forget it.
Gunther,
I have found a quirk in SX-Sim 2.08.06.
Pin RB.1 was·an input and I right clicked it to make it read high.
Then in the code RB.1 was made an output and low.
Later in the code RB.1 was made an input again. But it still reads as low even though on the I/O panel it is green.
If i click on RB.1 and turn it off then back on again, it works correctly (until the next loop).
You can see in the picture that RB.1 is green, but in the registers window it says RB is $00 (all off).
thank you for the bug report. I'm pretty sure that the I/O panel in not updated correctly when a port pin is toggled to be an output or input within a running program.
I have added this to my SXSim TODO list. As you know, I'm pretty busy with some other project right now, so I will start working on SXSim again once this project is finished.
Did you ever find a cause for the RunTime 339 error involving mscomCtl.ocx? I am encountering the same error with SXSIM version 2.08.06 downloaded from this thread.
The previous poster was running Win2000 and thought that may have contributed to the problem. I think he is right. It seems to be OS level related. I am running on Vista-64-bit and am getting the same error. I have tried copying the mscomCtl.ocx file from the windows\sysWOW64 directory where is normally resides to each of the windows\system32, Parallax\SX-Key\Tools\SXSim, and Parallax\SX-Key directories all to no avail. Any other ideas?
Nevermind. I have it figured out -- at least for Vista-64bit. I found a reference to a (what is thought to be a) bug with UAC in 64-bit Vista installations. The problem supposedly only shows up if the user has turned off UAC (as I have). The installation and registration of any VB runtime ocx files must be done with UAC enabled or else they will fail silently. I actully had multiple VB application failing -- not just SXSIM.
To correct the problem for my istallation, I copied the VB6 runtime ocx files from the Windows\sysWOW64 directory to the Windows\system32 directory. I then created a batch file to unregister each ocx and then re-register it. Each file would have lines like the following:
regsvr32 /u /s mscomCtl.ocx
regsvr32 /s mscomCtl.ocx
Next you must turn on UAC in the control panel and reboot the system. Once rebooted, select Start | Accessories | Command_Prompt and right click on it selecting Run As Administrator. In the Administrator Command Prompt window, run the batch file with the unregister, register commands for all the ocx files. Close the Command window. Finally, go back to the Control Panel and turn UAC back off (assuming that is your preference). Reboot and the VB applications should now work without the runtime errors. This fixed the 339 error with SXSIM for me and also got my other VB applications running error free.
thank you for investigating the mscomCtl problem. In the meantime, I found another pretty simple solution: Getting rid of mscomCtl.ocx at all. After checking the SXSim code, I found that I only derived a progress bar from that OCX to show the UnDo buffer "gauge". I have replaced this by a simple label showing the number of free items in the buffer. This is even more informative for the user, and a reference to mscomCtl.ocx is no longer made. So the next release of SXSim will come with this problem solved.
Good to know that your investigations also helped you to run other VB applications error free, so all your work was not in vain.
Gunther,
Attached is a .lst file generated by the sx/b beta.
It only defines a few pins as input or output.
After clearing the memory the pin direction register is set,
without
MOV W,#$1F
MOV M,W
prior to
MOV !RE,W
According to Bean upon powerup/reset the M register is initialized
to $1F (48/52) or $0F (18/20/28). SxSim however does not show
the output pins in the I/O panel. I see M loaded with $1F after
clicking reset (sx48).
sorry, I'm not sure if I fully understand your problem.
I agree with Bean that the M register will be initialized to $1F (for the SX48), or to $0f (for the "small" SXes), and so does SXSim. When you click the Reset button, M will be reset accordingly, and the I/O panel will show all pins as inputs.
In the sample code you have attached, M is loaded with $1E which selects the pull-up configuration registers in the SX48 but not the direction registers. So this does not influence the I/O panel by any means. When you load M with $1F before writing to the !Rx registers, you will notice that the I/O panel changes as expected.
Nevertheless, I found another bug in the I/O panel: It does not show captions for the RD and RE ports when an SX48/52 is simulated. I'll fix that for the next version.
Hey Guenther,
Your posted SX SIM Manual Zip won't open in WinZip.
It it possible it has become corrupted?
Any other documentation available?
Please advise.
Thanks
Comments
I think I might have found another bug in SX-Sim. Suppose the simulation is running, and you reach a breakpoint. If you click back and end up back in an interrupt, the shadow registers will not be loaded with the correct values,·but they will all contain zero. When you step forward and reach a reti or retiw, the execution jumps at 000h, and when it reaches reti or retiw the second time, it generates a "reti without interrupt" error.
Please, if you can, take the time to review this matter, and perhaps release a fix, as I rely completely on SX-Sim for debugging.
Sincerely,
Alex.
let me address both of your problem reports here:
1. "List file has been modified":
I assume that you launch SXSim from the SX-Key IDE by clicking the IDE's SXSim button. In this case, the IDE re-assembles the source code to make sure that the list file is up-to-date, and then launches SXSim with the command line containing the list file name. SXSim then checks the list file's time/date stamp if this file is "younger" than the associated SIM file it has saved before. When this is the case, the "Restore Breakpoint" dialog is opened, as the breakpoints stored in the SIM file might no longer match in case you have removed or added instructions from/to the source code.
If I got you right, I assume you want to test a program with SXSim, switch back to the SX-Key IDE from time to time (or by accident), and then return to SXSim. You can do this by clicking into the IDE window (or hit Alt-Tab). As I have defined the SXSim Commands window to always stay on top, this will hide parts if the IDE's Edit window but you should be able to return to SXSim by either hitting Alt-Tab again, or by clicking into the SXSim Commands window. In this case, you should be able to continue the simulation from the most recent point on. When you quit SXSim to restore the IDE windows, and click the IDE's SXSim button later, SXSim is re-launched again, and it re-loads the list file, so you can't continue the simulation but have to re-start it again. To avoid this, I could add an option to "freeze" the current status of all SX registers in the SIM file so that they can be restored for the next session. I'll add this to my TODO list.
2. Undoing shadow registers
Congratulations - you have found a bug! Thanks to your report, I found that the shadow registers and the FIFO were not always correctly restored when the "Back" button was clicked. I have fixed this in the meantime, and will release a new version soon.
Please stay tuned...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Thank you for taking the time to review this matter. I am looking forward to a new version of SX-Sim. In the meantime, I will be careful when running my simulations.
I would like to suggest that you also compile and release SX-Sim for x64 systems. Although there is no problem in running SX-Sim on x64 OS's, the larger instructions will speed up the simulation, and reduce the execution time in most cases.
Sincerely,
Alex
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Fear not that your project does not work, for it will,
Fear not if you see·a long dark path ahead, but follow it,
Fear not if what worked now refuses to,
For the only thing that's perfect is imperfection.
Add a control button or a drop down menu·
·
I used the latest sxsim to test some taskswitching code using the secret instructions.
3 observations:
a)
When I enter the isr routine for the first time, I see the 1st entries of the shadow stacks
loaded with the·states prior to the interrupt, with the 2nd entries 0.
b)
To perform a switch I then use the secret pop instructions. I see the 1st level entries
being copied to W, but I don't see the 2nd level entries being copied·to the 1st level entries,
which I think should be the case.
c)
When I use the secret push instructions, I see the 1st level entries being copied to the
2nd level entries, and W being copied to the 1st level entries, as it should.
Questions:
Can we assume that the shadow stack holds all 0's upon reset?
If not, why not leave the fields blank, as with the call stack.
A blank field would indicate a void value (location has never been accessed).
Could we also have blank fields in the ram area? Now they are filled with random values,
but do we really need to see these values while locations never have been accessed?
You could keep the values hidden until a location is accessed, then display it.
regards peter
When using indirect addressing on the ports, eg.
mov fsr,#$05
mov w,maintemp
or indf,w
followed by setting the port direction
mov w,#$1F
mov m,w
mov w,/mask ;bitmask: 1 identifies output pin
mov !ra,w
I noticed the RA latch register did not update on the screen
until I made the pin an output.
Is there a special reason why the latches are not directly updated?
I rather see the actual content of the latches, regardless of pin output state.
regards peter
thank you for the bug report. Yes, you are right, RTCC interrupts are enabled with OPTION.6 clear, and disabled with the bit set. In the meantime, I have fixed the tooltip text. It will be published with the next version of SXSim I'll release.
-G
I believe SxSim does not handle ret and retp correctly in respect
to the displayed active line.
Single step the attached program and observe stack, PC and PAx whenever
there is a call or ret or retp.
There are deliberate errors in the listing, that is some ret's must be retp
but the point here is that although the PC and PAx are set corectly
after a ret (PAx unchanged) or retp (PAx updated) the active line
jumps to the correct line as the program was intended but I believe
the active line is not at the correct page.
regards peter
thanks for the info - I'll check this out, and let you know...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Forget my last bug report. SxSim handles ret and retp correctly.
I thought that ret only restored the lower bits of PC, but in fact
ALL bits from the shadow stack are moved back into PC, wether
I use ret or retp. In addition retp copies the topbits to the
page bits.
regards peter
don't worry about your last bug report. It made me double-check if SXSim handles RET and RETP correctly, and I verified that it does. Nevertheless, before posting an answer, I wanted to do the same tests with the SX-Key Debugger, just to be sure, but I did not have the time so far to do it.
Therefore, your new message came in just in time
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
As with everyone thanks for the simulator tool for the SX. I just have a couple of thing that would be nice.
1) The Command window is defined as Stay On Top of EVERYTHING and not just on top of the SxSim window. It gets in the way when I am debugging and need to look at the documentation to figure out what is suppose to be happening.
2) Can you add a keyboard interface for SxSim? I am a keyboarder not a mouse fan when debugging. The typical keys from MPLAB would be nice
F9 = Run
F5 = Stop
F7 = Single Step
F8 = Step over
F? = Back (pick one!)
3) In Vista the scrollbar for the Listview is partially under the right side main window frame. (the calculation for the listview width is not correct for a Vista main window).
Thanks,
Jim Kueneman
I appreciate your SXSIM efforts. I have a request. I'm probably the only one who uses the SX in non-turbo mode, but is it possible to have a turbo/ non-turbo selection? Simply decreasing the FREQ directive by 4 doesn't completely take care of the timing differences. For instance, the JMP command takes 8 cycles in non-turbo (1:4 execution) compared to 3 cycles (1:1 execution) .
Thanks, Kevin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Bad spellers of the world untie!
Wouldn't it be great if SXSim could "Watch" like the real debug IDE?· It wouldn't hurt my feelings if it did.
yes, indeed, this is on my TODO list since a long time. My idea is to implement the watch directives similar to the SX-Key IDE plus some more "sophisticated" methods. Unfortunately, some other projects keep me really busy right now, so it will take a while until I can come back to do some more work on SXSim. Nevertheless, the "Watch" is on the list, and I won't forget it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I have found a quirk in SX-Sim 2.08.06.
Pin RB.1 was·an input and I right clicked it to make it read high.
Then in the code RB.1 was made an output and low.
Later in the code RB.1 was made an input again. But it still reads as low even though on the I/O panel it is green.
If i click on RB.1 and turn it off then back on again, it works correctly (until the next loop).
You can see in the picture that RB.1 is green, but in the registers window it says RB is $00 (all off).
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.iElectronicDesigns.com
Post Edited (Bean (Hitt Consulting)) : 3/12/2008 2:34:44 PM GMT
thank you for the bug report. I'm pretty sure that the I/O panel in not updated correctly when a port pin is toggled to be an output or input within a running program.
I have added this to my SXSim TODO list. As you know, I'm pretty busy with some other project right now, so I will start working on SXSim again once this project is finished.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Did you ever find a cause for the RunTime 339 error involving mscomCtl.ocx? I am encountering the same error with SXSIM version 2.08.06 downloaded from this thread.
The previous poster was running Win2000 and thought that may have contributed to the problem. I think he is right. It seems to be OS level related. I am running on Vista-64-bit and am getting the same error. I have tried copying the mscomCtl.ocx file from the windows\sysWOW64 directory where is normally resides to each of the windows\system32, Parallax\SX-Key\Tools\SXSim, and Parallax\SX-Key directories all to no avail. Any other ideas?
John
Nevermind. I have it figured out -- at least for Vista-64bit. I found a reference to a (what is thought to be a) bug with UAC in 64-bit Vista installations. The problem supposedly only shows up if the user has turned off UAC (as I have). The installation and registration of any VB runtime ocx files must be done with UAC enabled or else they will fail silently. I actully had multiple VB application failing -- not just SXSIM.
To correct the problem for my istallation, I copied the VB6 runtime ocx files from the Windows\sysWOW64 directory to the Windows\system32 directory. I then created a batch file to unregister each ocx and then re-register it. Each file would have lines like the following:
regsvr32 /u /s mscomCtl.ocx
regsvr32 /s mscomCtl.ocx
Next you must turn on UAC in the control panel and reboot the system. Once rebooted, select Start | Accessories | Command_Prompt and right click on it selecting Run As Administrator. In the Administrator Command Prompt window, run the batch file with the unregister, register commands for all the ocx files. Close the Command window. Finally, go back to the Control Panel and turn UAC back off (assuming that is your preference). Reboot and the VB applications should now work without the runtime errors. This fixed the 339 error with SXSIM for me and also got my other VB applications running error free.
John
thank you for investigating the mscomCtl problem. In the meantime, I found another pretty simple solution: Getting rid of mscomCtl.ocx at all. After checking the SXSim code, I found that I only derived a progress bar from that OCX to show the UnDo buffer "gauge". I have replaced this by a simple label showing the number of free items in the buffer. This is even more informative for the user, and a reference to mscomCtl.ocx is no longer made. So the next release of SXSim will come with this problem solved.
Good to know that your investigations also helped you to run other VB applications error free, so all your work was not in vain.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Attached is a .lst file generated by the sx/b beta.
It only defines a few pins as input or output.
After clearing the memory the pin direction register is set,
without
MOV W,#$1F
MOV M,W
prior to
MOV !RE,W
According to Bean upon powerup/reset the M register is initialized
to $1F (48/52) or $0F (18/20/28). SxSim however does not show
the output pins in the I/O panel. I see M loaded with $1F after
clicking reset (sx48).
regards peter
sorry, I'm not sure if I fully understand your problem.
I agree with Bean that the M register will be initialized to $1F (for the SX48), or to $0f (for the "small" SXes), and so does SXSim. When you click the Reset button, M will be reset accordingly, and the I/O panel will show all pins as inputs.
In the sample code you have attached, M is loaded with $1E which selects the pull-up configuration registers in the SX48 but not the direction registers. So this does not influence the I/O panel by any means. When you load M with $1F before writing to the !Rx registers, you will notice that the I/O panel changes as expected.
Nevertheless, I found another bug in the I/O panel: It does not show captions for the RD and RE ports when an SX48/52 is simulated. I'll fix that for the next version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
This is the section of interest:
· 112·················································· ;' =========================================================================
·· 113· 0FFF· 0A1A····· RESET __PROGSTART··············· ;· PROGRAM Start
·· 114· =0000001A······ __PROGSTART:···················
·· 115· 001A· 0C05······· MOV FSR,#RA··················
······· 001B· 0024
·· 116· 001C· 0060······· CLR IND······················
·· 117· 001D· 03E4······· IJNZ FSR,@$-1·
······· 001E· 0010 0A1C
·· 118················· ;SET BREAKPOINT HERE, then single step, RE.4, RE.5 and RE.6 outputs are not displayed on I/O panel··············
·· 119· 0020· 0C8F······· MOV !RE,#143·· ; this should make RE.4-RE.6 low outputs, but are not shown
······· 0021· 0009
·· 120· 0022· 0C88······· MOV !OPTION,#__INTOPTION·····
······· 0023· 0002
·· 121· 0024· 006F······· CLR __STACKPTR···············
·· 122· 0025· 0C10······· MOV FSR,#$10·················
······· 0026· 0024
·· 123· 0027· 0010······· JMP @Start···················
······· 0028· 0A2B
·· 124· =0000002B········ ORG $+2· ; FOR DEBUGGER······
Regards peter
Post Edited (Peter Verkaik) : 7/30/2008 9:51:00 PM GMT
I have been trying to download the manual for SX-SIM and get a missing or corrupt file error message, would you check it?
Thanks
RS_jim
Your posted SX SIM Manual Zip won't open in WinZip.
It it possible it has become corrupted?
Any other documentation available?
Please advise.
Thanks
http://forums.parallaxinc.com/forums/default.aspx?f=7&p=1&m=53539