I would disagree with your words "an ""extra"" selector between odd and even banks" ...... this is still confusing. I believe you don't mean "odd and even banks" but instead mean low group of eight and high group of eight banks.
it is just a point of view - I don't remember where I found it in the UBICOM docs - but somewhere I read that actually the RAM is organized in odd and even banks but that this organization could also be thougt to be a construct of eight low and eight high groups of banks. In the end, this does not really matter, as long as we are able to uniquely select the various blocks of RAM.
So I agree with you - just let`s name the "extra" FSR.7 bit as a selector for the low and high group of eight banks each in the SX 48/52 devices because this is the way how they are visualized in the SX-Key IDE and in SXSim.
yes - this is a problem with SXSim. For now, I parse the list file lines from top to bottom checking for directives like DEVICE SX?? to determine the controller type but I do not handle conditional assembly, i.e. ifdef/ifndef - else - endif. As SXSim "sees" the DEVICE SX28 directive last in your code, it assumes an SX28 to be simulated.
Let me see how much work it is to implement conditional assembly in SXSim. I think it is not neccessary that I parse the list file for symbols in a first pass. Instead, I can read the Cross Reference section because this actually is a symbol table. I already do read the Cross Reference section but for now, I do it after having loaded the rest of the file. For handling conditional assembly, I would have to read it in a first pass, and the first part of the list file in a second pass.
For now, commenting out the offending DEVICE SX?? directives is the ony solution. Sorry for this inconvenience.
in the meantime, I have found a much simpler solution to figure out the selected device type from the list file without the need to parse it while handling conditional assembly stuff.
When you look at a list file, you will notice that SASM generates hex values starting at column 9 in a line containing a DEVICE SX?? directive only in the true section of a conditional assembly.
So I have modified SXSim to only accept a DEVICE SX?? directive when it finds such hex values there. I have tried this new SXSim version with the test3.lst file you had sent me before, and it now works as expected. This "feature" will be available in version 2.6 to be posted soon.
You might ask: "What means soon" - well I have added some more "internals" to SXSim for a special purpose called "Integration" - guess what this means .
Is it me or is there really a bug on the Sxsim when using PC+W on a page other than page 0? Sxsim seems to add the current page to PC and PAx which is already holding the correct page say, page 1. The page·becomes doubled (page 1 + page 1), thus pointing the next instruction·to·a wrong page (page 2). There is no problem if the PC+W is on page 0 as only zero is added. I know my code is correct as it runs on the Sxkey but it hangs on the SXsim. Any similar experience?
This is kind of related to what redspy was saying so forgive me if it's already fixed. The problem I found is with using·"ADD PC,W" in the high part ($100-$1ff) of each page·on the·SX28A.·In SXsim, it actually·works·like you'd want·it to and jumps ahead but·it shouldn't as it's my understanding that any operation with PC as the destination clears PC bit 8, just like·a CALL. I know the 16C54 works like this at least, and I have a program·that hangs on the SX with an "ADD PC,W" in the high part of page -·when it's fine with it in the low part· (it's not jumping across a page or anything).
Apart from that - great util, keep up the good work [noparse]:)[/noparse]
thanks for the info - yes, this problem is already fixed in the new version I'm currently preparing. I'll need to do some more testing and other stuff before releasing it. I expect that it will take me another week (besides my "real" work) before I post the new version.
well, I'm thinking of an enhanced I/O panel which allows to set input pins to some certain state after a definable number of simulated clock cycles has been elapsed, i.e. some kind of "stimulus generator".
SXSim also already has code built in for a new logic analyzer window that displays the states of port pins as function of elapsed time or clock cycles. I still have a lot of work to do on this - therefore, it is hidden for now, and there is no button in the control panel to activate it.
I'm open to dicuss your ideas in more detail - could you please specify what you mean with "external events". Do you mean "real" level changes imported into SXSim via some kind of an interface, or "stimulated" events injected by some software?
Please check the first post in this thread for the new version of SXSim that I have just uploaded. As usual, comments, suggestions and bug reports are always welcome.
I can confirm my previously reported bug is now fixed - thanks for the update.
I've still got a slight issue with the "JMP PC+W" command in SXsim 2.06 though:
With·a program running in turbo mode, the cycle counter increments by 4 when
a "JMP PC+W" is executed, but according to the SX datasheet it·takes 3 cycles,
same as a "JMP"·(I've not timed it on a real SX however..)
thanks for the new bug report - you are right, like a JMP, the JMP PC+W takes three clock cycles instead of four as in the current version of SXSim. I have already fixed this - it will be available in the next version.
this is just to let you know that I did not forget about SXSim. I do have a new version in the pipeline.
As you may have noticed, SXSim has now been integrated into the SX-Key IDE. For this integration, Peter and I had to add some internal code to both programs, and currently, we are working on a different method how both programs communicate with each other. Therefore, I don't feel happy releasing an intermediate new version of SXSim right now, as this might cause compatibility problems. Therefore, please be patient, and stay tuned.
Hi Gunther,
I'm stumped! I added the following lines to "Toggle.SXB" and tried to run it with SXsim 2.06.02. I get the wrong results on two different computers.
TEMP1 VAR Byte
TEMP2 VAR Byte
MAIN:
TEMP1 = 50/10
TEMP2 = __REMAINDER
With Device SX18..., I get TEMP1 as $07, TEMP2 as $14.
With Device SX28..., I get TEMP1 as $02, TEMP2 as $0A.
I tried the Temp2=50//10 with the same results.
Running it on a SX28 works just fine. I'm probably missing something simple..I just cant figure it out.
as you know, SXSim reads the LST files generated by SASM. So could you please eMail (g.daubach@mda-burscheid.de) me both list files (the one for the SX18 and the one for the SX28). This would be of great help for me to fix any possible SXSim bug.
When SX/B generates code for an SX18/20, it defines addresses $07 for __PARAM1, $08 for __PARAM2, etc. When generating code for the SX28, the addresses have an offset of 1, i.e. __PARAM1 is located at $08, etc. This is because the SX28 maps port C into address $07, where an SX18/20 device, not supporting port C allows to use address $07 as a "regular" register. I did not check the SXSim code in detail do far, but I'm pretty sure that I forgot to handle address $07 correctly. IOW, for now, SXSim assumes that $07 is mapped to port C even when it simulates an SX18/20. Because of this, you may write to $07 whatever you want but when reading $07, SXSim will return the status of the (non-existing) simulated port C bits instead of what you have written to $07 before.
Having noticed that, I'll also have to check if this is handled correctly for the simulated SX48/52 devices with the additional ports D and E mapped into $08 and $09.
I have added this topic to my SXSim TODO list, and I'll take care of it as soon as possible.
you are right, this does not explain why you are getting 50/10 = 2 remainder 10 on the SX28. So I checked the SXSim code in more detail, just to find out that the SKIP instruction was not always handled correctly.
When you look at part of the SX/B generated code for the division, it contains the following instructions:
The SKIP instruction causes the next RL __PARAM2 instruction to be skipped when the code is executed "straight through". Later, the JNB __PARAM2.7, @$-2 causes a jump back to the RL instruction if necessary.
In SXSim, the SKIP did not perform as expected here, i.e. it did _not_ skip the RL __PARAM2 which caused the wrong result. I have fixed this in SXSim, and I'm now getting 5 remainder 0 as expected.
Nevertheless, there is still the problem with address $07 when SXSim simulates an SX18 or 20. Before releasing a new version of SXSim, I want to get that fixed as well, so please be patient.
No worries, Gunther.
As you know I'm still pretty green at this stuff. I was just suprized that _divide_ had an erronious results when running it in SXsim. Surely I'm not the first to divide something. But I'm glad it's fixed and look forward to the results. Have a great weekend.
When I run the SX key software how come SXSim throws runtime error '339'.· At the same time a yes/no messagebox pops up and says, "Do you want to update version 0.0 to 2.something.something".
Had you taken a moment read the first post in this thread you would find:
Some users hat trouble running SXSim due to a missing or incompatible COMDLG32.OCX file on their Windows machine. If you have similar trouble, download the OCX file attached to this post, and copy it into the folder containing SXSim. Please do NOT copy this file into the Windows\System32 folder as this would overwrite a version eventually required for other applications.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Jon Williams Applications Engineer, Parallax
I have uploaded a new version of SXSim (2.7) - you'll find it in the topmost post of this thread. In this version various bugs have been fixed, and I did some "fine-tuning". Have fun!
Please read the IMPORTANT NOTE in the "sticky" post concerning compatibility issues between the SX-Key IDE, and SXSim!
in my opinion, this is one of the most valuable feature requests I ever got!
As you know, I use these little check boxes at the beginning of the list lines to mark a breakpoint. What you are suggesting is kinda "watchpoint" or "pollpoint" for the run mode. I.e. instead of halting program execution, the display would be refreshed instead when coming across a breakpoint. With the "watchpoint" mode active, the one-second display refresh would be disabled.
I think this feature will not be too hard to implement - let me see...
Comments
I would disagree with your words "an ""extra"" selector between odd and even banks" ...... this is still confusing. I believe you don't mean "odd and even banks" but instead mean low group of eight and high group of eight banks.
Peter (pjv)
it is just a point of view - I don't remember where I found it in the UBICOM docs - but somewhere I read that actually the RAM is organized in odd and even banks but that this organization could also be thougt to be a construct of eight low and eight high groups of banks. In the end, this does not really matter, as long as we are able to uniquely select the various blocks of RAM.
So I agree with you - just let`s name the "extra" FSR.7 bit as a selector for the low and high group of eight banks each in the SX 48/52 devices because this is the way how they are visualized in the SX-Key IDE and in SXSim.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I have the following at the start of my file
;uncomment following line if SX48/52
DEV_48
ifdef DEV_48
device···SX48,oschs1
id···'RCSCSX48'
else
device···SX28,oschs1,turbo,stackx,optionx
id···'RCSCSX28'
endif
No matter wether I uncomment DEV_48 or not, sxsim detects a SX28.
With DEV_48 commented out sxsim sees a SX28 at starts to point at reset declaration.
With DEV_48 uncommented sxsim also sees a SX28 but then starts at line 1 and STEP and BACK
keys are greyed out.
I must comment out the ifdef construct to have sxsim detect a SX48.
regards peter
yes - this is a problem with SXSim. For now, I parse the list file lines from top to bottom checking for directives like DEVICE SX?? to determine the controller type but I do not handle conditional assembly, i.e. ifdef/ifndef - else - endif. As SXSim "sees" the DEVICE SX28 directive last in your code, it assumes an SX28 to be simulated.
Let me see how much work it is to implement conditional assembly in SXSim. I think it is not neccessary that I parse the list file for symbols in a first pass. Instead, I can read the Cross Reference section because this actually is a symbol table. I already do read the Cross Reference section but for now, I do it after having loaded the rest of the file. For handling conditional assembly, I would have to read it in a first pass, and the first part of the list file in a second pass.
For now, commenting out the offending DEVICE SX?? directives is the ony solution. Sorry for this inconvenience.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
in the meantime, I have found a much simpler solution to figure out the selected device type from the list file without the need to parse it while handling conditional assembly stuff.
When you look at a list file, you will notice that SASM generates hex values starting at column 9 in a line containing a DEVICE SX?? directive only in the true section of a conditional assembly.
So I have modified SXSim to only accept a DEVICE SX?? directive when it finds such hex values there. I have tried this new SXSim version with the test3.lst file you had sent me before, and it now works as expected. This "feature" will be available in version 2.6 to be posted soon.
You might ask: "What means soon" - well I have added some more "internals" to SXSim for a special purpose called "Integration" - guess what this means
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
you are right, this is (was) really a bug in SXSim. I found it recently, and it will be fixed in the next version to be released soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
This is kind of related to what redspy was saying so forgive me if it's already fixed. The problem I found is with using·"ADD PC,W" in the high part ($100-$1ff) of each page·on the·SX28A.·In SXsim, it actually·works·like you'd want·it to and jumps ahead but·it shouldn't as it's my understanding that any operation with PC as the destination clears PC bit 8, just like·a CALL. I know the 16C54 works like this at least, and I have a program·that hangs on the SX with an "ADD PC,W" in the high part of page -·when it's fine with it in the low part· (it's not jumping across a page or anything).
Apart from that - great util, keep up the good work [noparse]:)[/noparse]
Post Edited (Phil47) : 6/3/2005 2:31:49 PM GMT
thanks for the info - yes, this problem is already fixed in the new version I'm currently preparing. I'll need to do some more testing and other stuff before releasing it. I expect that it will take me another week (besides my "real" work) before I post the new version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
It would be nice if I could get time events from SXsim.
Then return events that update external pins of the part.
The RPC interface could be a socket.
This would allow a more extensive simulation and a scope trace generation.
I would code my piece in python, making it very simple to create new sims.
I'm very impressed by the amount of effort you've put into this.
Thanks for a nice tool
well, I'm thinking of an enhanced I/O panel which allows to set input pins to some certain state after a definable number of simulated clock cycles has been elapsed, i.e. some kind of "stimulus generator".
SXSim also already has code built in for a new logic analyzer window that displays the states of port pins as function of elapsed time or clock cycles. I still have a lot of work to do on this - therefore, it is hidden for now, and there is no button in the control panel to activate it.
I'm open to dicuss your ideas in more detail - could you please specify what you mean with "external events". Do you mean "real" level changes imported into SXSim via some kind of an interface, or "stimulated" events injected by some software?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Please check the first post in this thread for the new version of SXSim that I have just uploaded. As usual, comments, suggestions and bug reports are always welcome.
Have Fun!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I can confirm my previously reported bug is now fixed - thanks for the update.
I've still got a slight issue with the "JMP PC+W" command in SXsim 2.06 though:
With·a program running in turbo mode, the cycle counter increments by 4 when
a "JMP PC+W" is executed, but according to the SX datasheet it·takes 3 cycles,
same as a "JMP"·(I've not timed it on a real SX however..)
Regards,
Phil
·
thanks for the new bug report - you are right, like a JMP, the JMP PC+W takes three clock cycles instead of four as in the current version of SXSim. I have already fixed this - it will be available in the next version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
this is just to let you know that I did not forget about SXSim. I do have a new version in the pipeline.
As you may have noticed, SXSim has now been integrated into the SX-Key IDE. For this integration, Peter and I had to add some internal code to both programs, and currently, we are working on a different method how both programs communicate with each other. Therefore, I don't feel happy releasing an intermediate new version of SXSim right now, as this might cause compatibility problems. Therefore, please be patient, and stay tuned.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I'm stumped! I added the following lines to "Toggle.SXB" and tried to run it with SXsim 2.06.02. I get the wrong results on two different computers.
With Device SX18..., I get TEMP1 as $07, TEMP2 as $14.
With Device SX28..., I get TEMP1 as $02, TEMP2 as $0A.
I tried the Temp2=50//10 with the same results.
Running it on a SX28 works just fine. I'm probably missing something simple..I just cant figure it out.
Paul·
as you know, SXSim reads the LST files generated by SASM. So could you please eMail (g.daubach@mda-burscheid.de) me both list files (the one for the SX18 and the one for the SX28). This would be of great help for me to fix any possible SXSim bug.
Thanks in advance!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
this is a tricky one...
When SX/B generates code for an SX18/20, it defines addresses $07 for __PARAM1, $08 for __PARAM2, etc. When generating code for the SX28, the addresses have an offset of 1, i.e. __PARAM1 is located at $08, etc. This is because the SX28 maps port C into address $07, where an SX18/20 device, not supporting port C allows to use address $07 as a "regular" register. I did not check the SXSim code in detail do far, but I'm pretty sure that I forgot to handle address $07 correctly. IOW, for now, SXSim assumes that $07 is mapped to port C even when it simulates an SX18/20. Because of this, you may write to $07 whatever you want but when reading $07, SXSim will return the status of the (non-existing) simulated port C bits instead of what you have written to $07 before.
Having noticed that, I'll also have to check if this is handled correctly for the simulated SX48/52 devices with the additional ports D and E mapped into $08 and $09.
I have added this topic to my SXSim TODO list, and I'll take care of it as soon as possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
you are right, this does not explain why you are getting 50/10 = 2 remainder 10 on the SX28. So I checked the SXSim code in more detail, just to find out that the SKIP instruction was not always handled correctly.
When you look at part of the SX/B generated code for the division, it contains the following instructions:
141 0048 006B CLR __PARAM4
142 0049 0403 CLC
143 004A 0702 SKIP
144 004B 0369 RL __PARAM2
145 004C 02AB INC __PARAM4
146 004D 07E9 JNB __PARAM2.7,@$-2
The SKIP instruction causes the next RL __PARAM2 instruction to be skipped when the code is executed "straight through". Later, the JNB __PARAM2.7, @$-2 causes a jump back to the RL instruction if necessary.
In SXSim, the SKIP did not perform as expected here, i.e. it did _not_ skip the RL __PARAM2 which caused the wrong result. I have fixed this in SXSim, and I'm now getting 5 remainder 0 as expected.
Nevertheless, there is still the problem with address $07 when SXSim simulates an SX18 or 20. Before releasing a new version of SXSim, I want to get that fixed as well, so please be patient.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
As you know I'm still pretty green at this stuff. I was just suprized that _divide_ had an erronious results when running it in SXsim. Surely I'm not the first to divide something. But I'm glad it's fixed and look forward to the results. Have a great weekend.
watching variables in SXSim is an important feature on my personal wish list. IOW, I'll work on it if I only had the time...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Thank You
Had you taken a moment read the first post in this thread you would find:
Some users hat trouble running SXSim due to a missing or incompatible COMDLG32.OCX file on their Windows machine. If you have similar trouble, download the OCX file attached to this post, and copy it into the folder containing SXSim. Please do NOT copy this file into the Windows\System32 folder as this would overwrite a version eventually required for other applications.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
I have uploaded a new version of SXSim (2.7) - you'll find it in the topmost post of this thread. In this version various bugs have been fixed, and I did some "fine-tuning". Have fun!
Please read the IMPORTANT NOTE in the "sticky" post concerning compatibility issues between the SX-Key IDE, and SXSim!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
in my opinion, this is one of the most valuable feature requests I ever got!
As you know, I use these little check boxes at the beginning of the list lines to mark a breakpoint. What you are suggesting is kinda "watchpoint" or "pollpoint" for the run mode. I.e. instead of halting program execution, the display would be refreshed instead when coming across a breakpoint. With the "watchpoint" mode active, the one-second display refresh would be disabled.
I think this feature will not be too hard to implement - let me see...
Thanks a lot for this hint!
G