I think it would be great if Parallax could integrate SXSim into the SX-Key IDE.
Assembler,Compiler,Debugger and Simulation all in one package... Ah a fellow can dream.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"
actually, this was the reason why I have added the command-line mode to SXSim, i.e. you can pass the list file name via the command line. So let's see...
Hi Gunther (and the simmer gallery),
I took a snippet of code I use to check alarms with a BS2P-24 Stamp and put it into SX/B. Compiled and copied the .lst to a special 'sim' directory because SX/B deletes the .lst files when it closes(?). Ran SXSim and (after a couple bug sessions) have SimLEDS blinking, SimButtons working and SimHorns blaring!.. I know you know how I feel when I say.."Gee, this might just work".
Just wanted to thank you again for a great product!
-Paul
I'm glad that you like SXSim, and that it is useful for you.
Hmmm... SX/B deletes the list file??? As far as I know, SX/B translates the SX-BASIC program into an assembly source file which is then passed through SASM, where SASM should generate the .lst file.
Did you check the options "SASM files to SASM Output dir" and "SX/B files to Output Files dir" in the SX-Key Configuration?
Yep, they are both checked! If I compile anything in SX-key, the .lst, .map, .obj, and .sym are created in SX-Key v3.0\SASM Output directory. If I quit SX-Key at this point these 4 files ( or 8 or 12 or 16...if I compile more than one) are gone forever.
in my configuration, I have un-checked both of them, leaving the various files in the source directories. Please give it a try. If this does not help, we should hope that "Mr. SX-Key" (PJMonty) bails in here with more information.
Yes, The IDE deletes all output files when it closes by design. In fact, I think it even clears out the directories when it starts as well. The idea is that if the IDE didn't do this, then you would accumulate more and more output files whose sole purpose is only to be used during the programming/debugging of a particular file. I can just imagine the number of complaints from people saying, "How come the IDE is so stupid it just leaves all the old .LST, .OBJ, and .MAP files lying around? Man, that directory had a ton of useless stuff in it that I have to clean out every month. Who wrote this stupid thing?" or words to that effect.
When you close the IDE, the files serve no purpose anymore. Given the huge number of people who complain about things like "bloated software" and the Windows registry getting full with unused entries (such as from uninstallers that don't remove everything), I felt that it made far more sense to be a good citizen and clear the directory at the end of every session. I'm pretty sure I also do the clear at the beginning to make sure that if the IDE crashed, it doesn't leave any junk files around any longer than needed.
If you need the files, just keep the IDE running for as long as it takes you to copy or move them somewhere else. You could also just leave the IDE running the whole time if want, and do your work out of the directory they are located in.
Oh, I see now. Negative logic rules. I don't WANT to save the .lst files in the "Output Dir." got it. Now I can save all the "tons of useless stuff" where ever I want AND Peter can sleep at night knowing he tried his level best to save me from the bloat of these 3 to 10K byte files. Hey, I still have most of my Qbasic 3.0 files on here somewhere! Thanks Peter for trying but once a packrat....
-Paul
Not quite sure about your point regarding negative logic. Just to clarify, the whole reason that I added support for the output directory is because I got complaints from users that the IDE was littering their source code directories with unwanted junkfiles. It wasn't a capricious whim on my behalf, nor a plot to annoy the users of SXSim, because SXSim didn't even exist when I added the output directory.
If you like having all the various junk files on your hard drive, then by all means, un-check the option to use the output directory and keep them. Other users don't like to have them, and they choose to use the output directory. That's why I went to the extra effort of keeping both options available.
As for my sleep habits, I also sleep well at night knowing that I take a lot of personal time to help out, answer questions, and provide tech support in this forum. I'm not a Parallax employee, but a freelance software developer, so anytime I post here in an effort to help people with the IDE I get zero compensation. In fact, it's ten to midnight as I write this and I am literally going to sleep now.
I have copied the device directive from your post into one of my test files for SXSim, assembled it, and loaded the list file with SXSim. Here, it reports SX28 and only shows 8 RAM banks. IOW, I can't reproduce your problem. Could you please eMail me a copy of one of your list files that causes this problem?
thanks for posting the list file. It helped me to fix another bug in SXSim.
When parsing the list lines I forgot to check for a leading "DEVICE" when looking for tokens like "SX28", "SX48", etc. This caused SXSim to assume an SX48 device when it came across one of the lines containing "ifdef SX48" or "ifndef SX48". I have fixed this in the meantime for the next release of SXSim.
For now, you could out-comment the "ifdef/ifndef SX48" lines as a workaround, and SXSim should correctly select the SX28 for simulation.
Gunther,
In my email I got this as part of your response:
The second problem is a severe one: Your list file was generated by the "Retargetable Concurrent Small C compiler", and the list file format is different from the list files generated by SASM. As SXSim relies on the SASM list file format, simulation fails - even with the first bug fixed.
The list file IS created by SASM. The RCSC only generates dw statements.
The total SASM file consists of a header file, the dw statements, and
a runtime module file. The header and runtime are simply included.
yes, I had posted such message but then noticed that your list file was actually generated by SASM, so I deleted this post again. Seems as if the forum eMail system was faster than I .
As I said in my "official" post, there was a bug in SXSim that caused the wrong device type selection. Here, SXSim could handle your list file after I had out-commented the lines containing "ifdef/ifndef SX48".
in the SX48/52 datasheet (Ubicom) I have here, it reads:
"Often it is desirable to set the bank select bits of the FSR
register in one instruction cycle. The Bank instruction
provides this capability. This instruction sets the upper 3
bits 4, 5 and 6 of the FSR to point to a specific RAM bank
without affecting the lower 4 FSR bits, in preparation for
using direct or semidirect addressing. Bit 7 of the FSR
register is used to select the lower or upper block of
banks."
In the section Data Memory - Addressing Mode, they also show a "Modified BANK instruction", affecting bits 6..4 an they flag bit 7 as "User Configured".
Hmm - who is wrong and who is right ?
I think it would be best to verify this with the SX-Key on a "real" SX 52 - I'll do this later today.
Guenther,
AFAIK the BANK instruction sets/clears bits 4,5 and 6 of FSR. If you want to access bank 8 or higher you must manually set bit 7 of FSR. Or you can just use MOV FSR to set the whole register (this sets/clears all bits of course).
I'm assuming by "User Configured" they mean you must manually set/clear that bit.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video Display Module" Available Now.
in the meantime, I have run a test on a "real" SX52, and it behaves like described in the original UBICOM docs, i.e. the BANK instruction affects FSR bits 6...4, and bit 7 must be set/cleared separately. I have run the same test program with SXSim to verify that it behaves similarly, and it does.
Peter, in Figure 27 (page 158), and Figure 29 (page 161) of the SX-Key manual, bits 7...4 are named "Bank Selection Bits" which is true but it does not specify which bits are affected by the BANK instruction. At the end of page 161, Sub-Chapter 15.2.12 The Bank Instruction reads:
"Often it is desirable to set the bank select bits of the FSR with one instruction cycle (the MOV FSR,
#literal commands above take two cycles). The SX instruction set offers such an instruction called Bank.
The Bank instruction sets the upper bits of the FSR to point to the RAM bank required. Note: On the
SX48/52, the BANK instruction only selects one of 8 banks in either the lower 8 or upper 8 banks. FSR.7 selects
the lower or upper group of 8 banks. To select a bank, use MOV FSR, #literal or add an SETB FSR.7 instruction
after the BANK instruction."
This indicates that FSR.7 is the bit to be handled separately, and not FSR.4 as you assumed. On the other hand, I must admit that this text does not clearly describe the situation.
On page 67 in the manual, you can find a sample for a macro with a formal parameter by count, the _bank macro with a comment reading
"; SX48BD and SX52BD bank instruction
; modifies FSR bits 4,5 and 6. FSR.7 needs to be set
; by software."
Again, this is a hint on how the bits are handled but again, I admit that this is not the right place to explain it.
I have added this matter to the TODO list for the next edition of the SX-Key manual.
BTW - as far as I can remember, the first engineering releases of the SX48/52 chips behaved like you assumed.
Guenther,
You are right. On the SX52 engineering samples BANK affected bits 5,6 and 7 and bit 4 had to be set manually. Maybe that is where some confusion is setting in.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video Display Module" Available Now.
This is the text from my printed v1.1 manual:
"Often it is desirable to set the bank select bits of the FSR with one instruction cycle (the MOV FSR,
#literal commands above take two cycles). The SX instruction set offers such an instruction called Bank.
The Bank instruction sets the upper bits of the FSR to point to the RAM bank required. Note: On the
SX48/52, the BANK instruction only selects even numbered·banks. To select an odd numbered bank
use MOV FSR, #literal or add an SETB FSR.4 instruction after the BANK instruction."
So I guess this references to the engineering samples!
So now, for the SX48/52
bank0 equ $00, up to bankF $F0 and bit7 must be seperately set for banks 8 to F after bank instruction.
For the SX18/28
bank0 equ $10, up to bank7 $F0 and bit4 must be set for all banks after bank instruction
it looks like the v1.1 manual referred to the engineering samples - fortunately I have at least fixed this in the v2.0 manual but as I mentioned before, I had better explained the bit-settings in more detail and will do in the next edition.
For the SX48/52 simply think of FSR.7 as a an "extra" selector between odd and even banks, required to be set separately from the BANK instruction which affects bits FSR.6...4.
For the SX18/28, you can simply ignore this "extra" bit. There is no need to explicitely set it after a BANK instruction which affects bits FSR.7...5 in this case.
Nevertheless, our discussion is good for an improvement of SXSim. So far, SXSim always highlights FSR bits 7...5 to mark the bits that are affected by the BANK instruction. I should change this so that bits 6...4 are highlighted instead, when an SX 48/52 is simulated.
Comments
Assembler,Compiler,Debugger and Simulation all in one package... Ah a fellow can dream.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"
www.sxvm.com
·
actually, this was the reason why I have added the command-line mode to SXSim, i.e. you can pass the list file name via the command line. So let's see...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
here comes a new version of SXSim (2.05). You can download it (plus the updated manual) from the first "sticky" post, as usual.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
could you please send me this .lst file via private e-mail so that I can check out what causes this error.
TIA
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I took a snippet of code I use to check alarms with a BS2P-24 Stamp and put it into SX/B. Compiled and copied the .lst to a special 'sim' directory because SX/B deletes the .lst files when it closes(?). Ran SXSim and (after a couple bug sessions) have SimLEDS blinking, SimButtons working and SimHorns blaring!.. I know you know how I feel when I say.."Gee, this might just work".
Just wanted to thank you again for a great product!
-Paul
I'm glad that you like SXSim, and that it is useful for you.
Hmmm... SX/B deletes the list file??? As far as I know, SX/B translates the SX-BASIC program into an assembly source file which is then passed through SASM, where SASM should generate the .lst file.
Did you check the options "SASM files to SASM Output dir" and "SX/B files to Output Files dir" in the SX-Key Configuration?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
in my configuration, I have un-checked both of them, leaving the various files in the source directories. Please give it a try. If this does not help, we should hope that "Mr. SX-Key" (PJMonty) bails in here with more information.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Yes, The IDE deletes all output files when it closes by design. In fact, I think it even clears out the directories when it starts as well. The idea is that if the IDE didn't do this, then you would accumulate more and more output files whose sole purpose is only to be used during the programming/debugging of a particular file. I can just imagine the number of complaints from people saying, "How come the IDE is so stupid it just leaves all the old .LST, .OBJ, and .MAP files lying around? Man, that directory had a ton of useless stuff in it that I have to clean out every month. Who wrote this stupid thing?" or words to that effect.
When you close the IDE, the files serve no purpose anymore. Given the huge number of people who complain about things like "bloated software" and the Windows registry getting full with unused entries (such as from uninstallers that don't remove everything), I felt that it made far more sense to be a good citizen and clear the directory at the end of every session. I'm pretty sure I also do the clear at the beginning to make sure that if the IDE crashed, it doesn't leave any junk files around any longer than needed.
If you need the files, just keep the IDE running for as long as it takes you to copy or move them somewhere else. You could also just leave the IDE running the whole time if want, and do your work out of the directory they are located in.
Thanks, PeterM
-Paul
Ouch! Somebody seems grouchy...
Not quite sure about your point regarding negative logic. Just to clarify, the whole reason that I added support for the output directory is because I got complaints from users that the IDE was littering their source code directories with unwanted junkfiles. It wasn't a capricious whim on my behalf, nor a plot to annoy the users of SXSim, because SXSim didn't even exist when I added the output directory.
If you like having all the various junk files on your hard drive, then by all means, un-check the option to use the output directory and keep them. Other users don't like to have them, and they choose to use the output directory. That's why I went to the extra effort of keeping both options available.
As for my sleep habits, I also sleep well at night knowing that I take a lot of personal time to help out, answer questions, and provide tech support in this forum. I'm not a Parallax employee, but a freelance software developer, so anytime I post here in an effort to help people with the IDE I get zero compensation. In fact, it's ten to midnight as I write this and I am literally going to sleep now.
Thanks, PeterM
This was fun for about 3 days..not anymore.
I downloaded the latest sxsim.
The first line in my listfile is
device···SX28,oschs1,turbo,stackx,optionx
Sxsim however reports SX48 at the upper left corner
and it consequentially displays·16 ram banks.
Shouldn't sxsim detect SX28 and display only 8 ram banks?
regards peter
I have copied the device directive from your post into one of my test files for SXSim, assembled it, and loaded the list file with SXSim. Here, it reports SX28 and only shows 8 RAM banks. IOW, I can't reproduce your problem. Could you please eMail me a copy of one of your list files that causes this problem?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Note that·the device directive is placed inside an include file.
regards peter
thanks for posting the list file. It helped me to fix another bug in SXSim.
When parsing the list lines I forgot to check for a leading "DEVICE" when looking for tokens like "SX28", "SX48", etc. This caused SXSim to assume an SX48 device when it came across one of the lines containing "ifdef SX48" or "ifndef SX48". I have fixed this in the meantime for the next release of SXSim.
For now, you could out-comment the "ifdef/ifndef SX48" lines as a workaround, and SXSim should correctly select the SX28 for simulation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
In my email I got this as part of your response:
The second problem is a severe one: Your list file was generated by the "Retargetable Concurrent Small C compiler", and the list file format is different from the list files generated by SASM. As SXSim relies on the SASM list file format, simulation fails - even with the first bug fixed.
The list file IS created by SASM. The RCSC only generates dw statements.
The total SASM file consists of a header file, the dw statements, and
a runtime module file. The header and runtime are simply included.
regards peter
·
yes, I had posted such message but then noticed that your list file was actually generated by SASM, so I deleted this post again. Seems as if the forum eMail system was faster than I
As I said in my "official" post, there was a bug in SXSim that caused the wrong device type selection. Here, SXSim could handle your list file after I had out-commented the lines containing "ifdef/ifndef SX48".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I replaced my SX48 by DEV_48 and now it is ok.
regards peter
In the attached .lst file for the SX48
reset, then singlestep until bank VM_BANK instruction.
The code value is displayed as 1Fh (VM_BANK equ $F0)
so that is correct. However the ram map shows bank7 is selected
and the bits 4-6 of fsr get set. I think the bits 5-7 should be set.
The manual states: On the SX48/52 the bank instruction only
selects even numbered banks. To select an odd bank (in my case bank F)
use setb fsr.4 after the bank instruction.
regards peter
thanks for the problem report - I'll take care of it, and hopefully come back with a new version soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
in the SX48/52 datasheet (Ubicom) I have here, it reads:
"Often it is desirable to set the bank select bits of the FSR
register in one instruction cycle. The Bank instruction
provides this capability. This instruction sets the upper 3
bits 4, 5 and 6 of the FSR to point to a specific RAM bank
without affecting the lower 4 FSR bits, in preparation for
using direct or semidirect addressing. Bit 7 of the FSR
register is used to select the lower or upper block of
banks."
In the section Data Memory - Addressing Mode, they also show a "Modified BANK instruction", affecting bits 6..4 an they flag bit 7 as "User Configured".
Hmm - who is wrong and who is right ?
I think it would be best to verify this with the SX-Key on a "real" SX 52 - I'll do this later today.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
AFAIK the BANK instruction sets/clears bits 4,5 and 6 of FSR. If you want to access bank 8 or higher you must manually set bit 7 of FSR. Or you can just use MOV FSR to set the whole register (this sets/clears all bits of course).
I'm assuming by "User Configured" they mean you must manually set/clear that bit.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video Display Module" Available Now.
www.sxvm.com
"A problem well defined, is a problem·half solved."
·
http://www.parallax.com/sx/downloads.asp
pages 156 to 161 list the addressing modes. The figures clearly indicate
bits 7,6,5 select the bank. The SX18/28 only has the upper banks (hence
bit4 must always be 1 on the SX18/28)
regards peter
in the meantime, I have run a test on a "real" SX52, and it behaves like described in the original UBICOM docs, i.e. the BANK instruction affects FSR bits 6...4, and bit 7 must be set/cleared separately. I have run the same test program with SXSim to verify that it behaves similarly, and it does.
Peter, in Figure 27 (page 158), and Figure 29 (page 161) of the SX-Key manual, bits 7...4 are named "Bank Selection Bits" which is true but it does not specify which bits are affected by the BANK instruction. At the end of page 161, Sub-Chapter 15.2.12 The Bank Instruction reads:
"Often it is desirable to set the bank select bits of the FSR with one instruction cycle (the MOV FSR,
#literal commands above take two cycles). The SX instruction set offers such an instruction called Bank.
The Bank instruction sets the upper bits of the FSR to point to the RAM bank required. Note: On the
SX48/52, the BANK instruction only selects one of 8 banks in either the lower 8 or upper 8 banks. FSR.7 selects
the lower or upper group of 8 banks. To select a bank, use MOV FSR, #literal or add an SETB FSR.7 instruction
after the BANK instruction."
This indicates that FSR.7 is the bit to be handled separately, and not FSR.4 as you assumed. On the other hand, I must admit that this text does not clearly describe the situation.
On page 67 in the manual, you can find a sample for a macro with a formal parameter by count, the _bank macro with a comment reading
"; SX48BD and SX52BD bank instruction
; modifies FSR bits 4,5 and 6. FSR.7 needs to be set
; by software."
Again, this is a hint on how the bits are handled but again, I admit that this is not the right place to explain it.
I have added this matter to the TODO list for the next edition of the SX-Key manual.
BTW - as far as I can remember, the first engineering releases of the SX48/52 chips behaved like you assumed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
You are right. On the SX52 engineering samples BANK affected bits 5,6 and 7 and bit 4 had to be set manually. Maybe that is where some confusion is setting in.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video Display Module" Available Now.
www.sxvm.com
"A problem well defined, is a problem·half solved."
·
This is the text from my printed v1.1 manual:
"Often it is desirable to set the bank select bits of the FSR with one instruction cycle (the MOV FSR,
#literal commands above take two cycles). The SX instruction set offers such an instruction called Bank.
The Bank instruction sets the upper bits of the FSR to point to the RAM bank required. Note: On the
SX48/52, the BANK instruction only selects even numbered·banks. To select an odd numbered bank
use MOV FSR, #literal or add an SETB FSR.4 instruction after the BANK instruction."
So I guess this references to the engineering samples!
So now, for the SX48/52
bank0 equ $00, up to bankF $F0 and bit7 must be seperately set for banks 8 to F after bank instruction.
For the SX18/28
bank0 equ $10, up to bank7 $F0 and bit4 must be set for all banks after bank instruction
Is that correct?
regards peter
·
If you clear bit 4 in the FSR, then it will point you back into the global bank.
Peter (pjv)
it looks like the v1.1 manual referred to the engineering samples - fortunately I have at least fixed this in the v2.0 manual but as I mentioned before, I had better explained the bit-settings in more detail and will do in the next edition.
For the SX48/52 simply think of FSR.7 as a an "extra" selector between odd and even banks, required to be set separately from the BANK instruction which affects bits FSR.6...4.
For the SX18/28, you can simply ignore this "extra" bit. There is no need to explicitely set it after a BANK instruction which affects bits FSR.7...5 in this case.
Nevertheless, our discussion is good for an improvement of SXSim. So far, SXSim always highlights FSR bits 7...5 to mark the bits that are affected by the BANK instruction. I should change this so that bits 6...4 are highlighted instead, when an SX 48/52 is simulated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G