I am beginning to having a go at using the SXSim for some development work, and find it an incredibly useful tool. There is one annoyance however, everytime I "reset" the software, the memory contents are re-scrambled. I believe this was a feature to simulate real silicon from a cold boot. Of course real silcon does not re-scramble its contents·on a reset.
During debugging, I frequently·load some initializing parameters from memory which then get corrupted every time, and need to be reset by hand. ARGGGG!!!!
Is it possible to add a button that will disable the scrambling feature? It sure will save some time and aggravation.
And while I'm whining; when hand-entering values into memory could the arrow keys (rather than the inconvenient mouse) be used to navigate through the registers; that then also automatically locking in any new memory value on moving off that location?
Just some thoughts to make a great product even more convenient.
it's really funny - as far as I can remember, I have added this "scramble-on-reset" feature a while ago because some users were asking for it.
As you know, SXSim - for now - does not have a menu bar, or some "Configure" button with an associated dialog window - why? Because I prefer to show the user all possible options and settings in the default windows, instead of hiding them in some configuration pop-ups.
On the other hand, this means, I'm close to running out of buttons/options .
Nevertheless, your "feature request" makes a lot if sense, and will be useful for many other "SXSimmers" as well. How about "splitting" the "Reset" button into two buttons - a "Reset" button, issuing a reset w/o scrambling RAM data, and a "PWR" button, simulating a power-on reset with scrambling RAM data.
As you know, when SXSim is terminated, or when you load another LST file, many of the current session settings are stored in a SIM file. Do you think it makes sense to also save a full RAM image in that SIM file, allowing to completely restore a previous simulation session? If yes, I would make this the default, allowing the user to click "Reset", or "PWR" to get rid of this.
No reason for whining - let me have a look at the "hand-entering-values-into-memory" procedures, and how they can be made more user-friendly.
Thanks for such a handy utility. I'm using SXSim 2.07 to check the speed of code that I'm hoping to move from user space to ISR space, and it's working great.
But...
I have code that includes a macro. When I run it in SXSim, the macro is not expanded. When I single-step through the code to execute at the location of the macro, an incorrect instruction is listed, although the code cyclecounts and elapsed time do perform correctly.
Is this part of the SXSIM design?
I was hoping the macros would be expanded in the resulting code. Is my expectation unrealistic for some reason? I've searched the documentation and haven't seen any mention about how macros are (or aren't) treated.
Example code is shown below. In the example, I manually inserted the macro contents in one place to show that SXSim is performing the same cyclecounts for the macro code vs the actual code.
David
;
; send command byte and receive data byte from MAX186
; Calling code sets "outbyte" to desired value, calls "SendGetByte",
; then receives "inbyte".
fastbit macro
rl inbyte ; BIT n
movb inbyte.0, MAX_DOUT ;
movb MAX_DIN, outbyte.7 ;
setb MAX_CLK ; we need to shift the outgoing byte after use,
rl outbyte ; but lets do it between clocks to give the clock bit
clrb MAX_CLK ; that little extra settling time...
endm
Macros are expanded at assembly time, and not ar run-time (or simulation-time in case of SXSim). The problem here is that the assembler did not expand the macro code in the list file, i.e. SXSim does not "see" the instructions that are inserted in the code where the macro is invoked. Please add an EXPAND directive in your sorce code somewhere before the macro definition. This should fix the problem.
thanks to some users sending bug reports and making important suggestions for enhancements, I have prepared a new version of SXSim (2.08) with the following fixes/enhancements:
- RTCC timing on ISR entry/exit fixed.
- New "Watchpoint" feature. Instead of halting program execution in "Run" mode, the register display is updated whenever program execution "passes" a marked code line. With "Watchpoint mode" active, the register display will no longer be periodically updated every second.
- Improved editing of file register contents. The arrow keys can now be used to confirm the change of the current register and to navigate to another register to be modified next.
- New "PWR" button added. This simulates a power-on reset with random file register contents, where the "Reset" button now simulates a reset via /MCLR with the register contents being unchanged.
- Different file select dialog used, therefore OMDLG32.OCX is no longer required to run SXSim.
- Manual updated to describe the new features.
As usual, you will find the new version and the updated documentation for download attached to the first post in this thread.
I just recently hade to reload my SX_Key software and incountered the problem discribed in this post. when I use SX_Key 3.0 (I have updated to the latest compiler Version 1.42.02) I have no problem loading the editor/compiler. But when I update to SX_Key version 3.1 I get the message "SXSim on disk is version 0.00 Update to version 2.06.02 (recommended)."
I followed your instructions copied the sim files to another directory and all. SXSim will launch that way however!!!
when it loaded the SX_Key the next time and got the error message and said yes the next error was "RESOURCE PROBLEM SXSIM.EXE IS IN USE UNABLE TO SAVE TO DISK"
Weather I leave SXSim open or close it same result
If I do a <CTRL><ALT><DEL> I can see the SXSim program is running but no output to screen.
SX_Key always tries to load SXSim first and this causes my problem. I am new to SX and normly just use the SX_Key and not the SXSim program. can I still get a copy of SXKey 3.1 that does not need SXSim. Or is their not that much difference between 3.0 and 3.1
sorry for ignoring your post such a long time - somehow, I have missed it.
When SXKey 3.1 launches, it checks for the versions of SX/B (residing in the Compilers\SXB sub-folder, and for SXSim in the Tools\SXSim sub-folder. To figure out the SXSim version number, it starts SXSim in a special invisible mode, and queries the version number from SXSim. After this test, the invisible version of SXSim should be unloaded again automatically.
Here, I tried the following: I completely deleted the SXSim sub-folder, and then launched the SX-Key IDE. This shows a dialog "SXSim is not on disk. Version 2,0602 will be installed." I confirmed this with "OK". I did the same for the next dialog about the documentation. After this, the IDE sheoud start as usual, and when you close and re-launch it, no more complaints about SXSim should show up. When you launch SXSim from this IDE, SXSim Version 2.06.02 will start - the one the SX-Key IDE has installed.
You can't overwrite this version of SXSim in the Tools\SXSim sub-folder by a later version, like 2.08.03 because this no longer supports the "hidden mode", and the method of sending its version number to the IDE. So, this may explain the "Resource Problem..." error you get when the IDE tries to start SXSim in "hidden mode" - as it won't be unloaded correctly.
If you want to make use of a later SXSim version for now, please install the EXE file into any other subfolder but Tools\SXSim, or you may install it there under a different name, like SXSim08.EXE. In order to start this version, you may define a shortcut on the desktop, or in the Windows program menu.
I'm sure, the next version of the SX-Key IDE will support this later version of SXSim - until then, I'm sorry for the inconvenience that you can't launch the new version from the IDE.
I am using the SX-SIM to do some debugging, and I would like to have several of the as yet unimplemented "secret" instructions dealt with. These are $001 = mov w,option; $044 = mov debug,w; $045 = exchange carry with osc2; $046 = mov breakpoint,w ????.
Probably you can only implement $001, but for the other ones, could you effectively make them NOPs and hence unfreeze the simulation process so that one can continue to·step/run through the code.
Also, on power-up reset (only)·can you randomize the W register; RTCC; Status bits 2, 1, 0; WKPND_B; the 8 level call stack; all shadow registers; and the 8 level FIFO.
Furthermore in the IND window could you show the content of the location that FSR is pointing at.
In using the simulator some more, I note that only integer MHz values are permitted with FREQ directive, fractional Mhz, and (integer) values of Khz are not permitted.
Perhaps this can be changed so we can conveniently determine the cycle times of internal RC or other oscillators also.
It's me again. Filally I seem to be exercizing your simulator quite a bit; it's very helpful for some of the strange things I'm doing.
I note that in the register window, the default value for the port bits (inputs at reset) is zero, but when they become configured with pull-ups should they change to a one?
It would be wonderful if both, the input values AND pending output values could be shown, so when an output register gets assigned a value by the program, and (some) of the bits are input, and then the program changes them to output (I do this a lot), then the pre-loaded ouput values get presented on the port bits which have now become outputs.
Also, there is an incorrect operation when right or left shifting a port register. Shifts (right or left) out of a bit which is configured as an input should have a value of one. You provide a value of zero, and non-adjacent outputs should NOT ripple through the port display window; but adjacent ones should. In other words, at any bit where a port register contains a bit configured as an input, then a (left or right) shiftout from that bit should be a one. That is for between adjacent bits as well as the end bits to the carry.
seems as if you are beating SXSim quite a lot right now - nevertheless, all your suggestions are valuable as they help to make the simulation more realistic. I have added allof them to the TODO list (which is growing more and more), and will see what I can do.
I'm afraid that I'm having trouble on two of my windows xp boxes getting sxSim to run. (one is XP Professional, the other is simply XP, both current updated.) I'd started with the latest budle with the SX-Key IDE from the site. That gave me the "run-time error '339' for MSCOMCTL.OCX (not being correctly registered) that I've seen in other posts.
I've tried the current directions and download from the first post. But this gives the same error, even running entirely by itself. Even if I remove all other SX Key components, and just run the sxsim downloaded from the first post I get this error.
Does anyone have any other thoughts on what I could try, download, change in the registry, spoof, etc.?
MSCOMCTL.OCX is required for applications with serial communication but SXSim does not make use of it, so it looks strange to me that this error comes up, and it never has been reported before. Former versions (before 2.08) made use of the file select dialog contained in COMDLG32.OCX. In the new version, I use a different method so COMDLG32.OCX is no longer required. I'll double-check if there is any reference in SXSim to MSCOMCTL.OCX, and let you know the results.
its me again - I made a false statement in my last post, MSCOMCTL.OXC is not required for serial communication (this is MSCOMM32.OCX) but for common dialogs, and it is required by SXSim. I'm pretty sure you have it on your machines but possibly another version. Can you search for MSCOMCTL.OXC on your machine, and find out which version it has (in case it is there)?
Many thanks for looking into this. A quick search of my system did not find a local copy of this file. Is it part of a runtime package for VB or C#?
I tried installing the patch here: http://support.microsoft.com/?id=896559 but that also does not seem to have left a copy locally. Apologies for my lmited understanding of the windows libraries. I'm, by trade, primarily a Java developer.
Guenther, (and whomever else this may help at some point)
I've found a copy of mscomctl.ocx on Microsoft's site (via a 3rd party discussion page found on a search engine, by way of Hoboken)
And have installed it as a single file. Everything now works as described in your first post (eg.: it still complains about comdlg32.ocx in the ide, but the new sx sim file now runs standalone.)
Thanks for the assistance, putting me on the right track,
glad to hear that you got it up and running now. BTW: As there are various versions of OCXes around, it may be an idea to store the one that works fine for SXSim in the same directory where SXSim.EXE is installed, and not into the Windows directory. As Windows applications search for additional files, like OCXes, DLLs, etc. in the local path first, and then in the Windows path, SXSim will always find a working copy of the OCX locally, even when the one in the Windows path might be overwritten by another software installation later.
Right now, the IDE installs an older version of SXSim that still requires COMDLG32.OCX which can't be found on your machines either. Sorry for this inconvenience but this will be fixed with the next release of the IDE.
Try downloading and running the VB6 runtime package. This will contain the usual common dialog and the COM control (mscomctl.com) 's. Best take a copy of your working one first!
thanks for providing the URL - this is really valuable for SXSim users with missing, or non-matching VB runtime modules. As you have pointed out, it is important to save a copy of any existing modules before replacing them. As an alternative, you could place the new modules in the SXSim root directory, i.e. where SXSim.exe is stored, instead of placing them in the Windows directoy.
I'm sure your TODO list is growing by leaps and bounds, but I was wondering when the SXSim version supporting multi-purpose timers for the SX48/52 would be released? I'm sure I'm not the only one anxious to simulate it. I am an experienced programmer and could probably get away with simulating everything but the timers and spend a bit of time "in circuit" to reprogram for any errors. But, of course having the SXSim to test the timers would be great!
yes, the TODO list keeps growing, and it already contains the multi-purpose timers. Right now, I'm busy with a lot of other stuff, so it will take a while to get them going. At least, they are on the list, and I won't forget them.
Today I read your documantation on the SX-Sim for the first time. It is quite notable how intuitive the program is for someone to be able to use (most) of it without "reading the instructions". Good job!
I did note a couple of points that your users should be made aware of, and features you may wish to include in a later version.
Firstly I would like to correct a minor documentation error caused by myself when the "secret instructions" were revealed. It is the definition of the $045 instruction labeled "shift OSC pin in/out W" that is in error. It has nothing to do with the W register; Carry (C) is swapped out to the OSC2 pin, and the OSC2 pin is swapped into the carry. This is the method for the SX-Key and the SX chip to communicate. So instead should be undestood to be something like "exchange carry with OSC2 pin", and it would more appropriately be labelled as "OSC2<>C".
The other point is that for (only) the SX48/52 chips, on interrupt the MODE register is also saved in a single level shadow register. Alas, that register is not accessible by W so one cannot manually push or pop it.
thanks for the information about false clock counts on DECSZ - as far as I can remember, I've alreay fixed it but I'll double-check this again.
Seems as if the 3 instead of 2 cycles bug has found its way into the docs (including my book) a loong time ago. You can also find it in the SX datasheets - even in the new one recently released from Parallax.
Comments
I am beginning to having a go at using the SXSim for some development work, and find it an incredibly useful tool. There is one annoyance however, everytime I "reset" the software, the memory contents are re-scrambled. I believe this was a feature to simulate real silicon from a cold boot. Of course real silcon does not re-scramble its contents·on a reset.
During debugging, I frequently·load some initializing parameters from memory which then get corrupted every time, and need to be reset by hand. ARGGGG!!!!
Is it possible to add a button that will disable the scrambling feature? It sure will save some time and aggravation.
And while I'm whining; when hand-entering values into memory could the arrow keys (rather than the inconvenient mouse) be used to navigate through the registers; that then also automatically locking in any new memory value on moving off that location?
Just some thoughts to make a great product even more convenient.
Cheers,
Peter (pjv)
Post Edited (pjv) : 11/19/2005 10:26:24 PM GMT
it's really funny - as far as I can remember, I have added this "scramble-on-reset" feature a while ago because some users were asking for it.
As you know, SXSim - for now - does not have a menu bar, or some "Configure" button with an associated dialog window - why? Because I prefer to show the user all possible options and settings in the default windows, instead of hiding them in some configuration pop-ups.
On the other hand, this means, I'm close to running out of buttons/options
Nevertheless, your "feature request" makes a lot if sense, and will be useful for many other "SXSimmers" as well. How about "splitting" the "Reset" button into two buttons - a "Reset" button, issuing a reset w/o scrambling RAM data, and a "PWR" button, simulating a power-on reset with scrambling RAM data.
As you know, when SXSim is terminated, or when you load another LST file, many of the current session settings are stored in a SIM file. Do you think it makes sense to also save a full RAM image in that SIM file, allowing to completely restore a previous simulation session? If yes, I would make this the default, allowing the user to click "Reset", or "PWR" to get rid of this.
No reason for whining - let me have a look at the "hand-entering-values-into-memory" procedures, and how they can be made more user-friendly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I have no opionon the save file, as I'm not sure how it would apply to me.
Thanks for consideration on the other requests though.
Cheers,
Peter (pjv)
Thanks for such a handy utility. I'm using SXSim 2.07 to check the speed of code that I'm hoping to move from user space to ISR space, and it's working great.
But...
I have code that includes a macro. When I run it in SXSim, the macro is not expanded. When I single-step through the code to execute at the location of the macro, an incorrect instruction is listed, although the code cyclecounts and elapsed time do perform correctly.
Is this part of the SXSIM design?
I was hoping the macros would be expanded in the resulting code. Is my expectation unrealistic for some reason? I've searched the documentation and haven't seen any mention about how macros are (or aren't) treated.
Example code is shown below. In the example, I manually inserted the macro contents in one place to show that SXSim is performing the same cyclecounts for the macro code vs the actual code.
David
;
; send command byte and receive data byte from MAX186
; Calling code sets "outbyte" to desired value, calls "SendGetByte",
; then receives "inbyte".
fastbit macro
rl inbyte ; BIT n
movb inbyte.0, MAX_DOUT ;
movb MAX_DIN, outbyte.7 ;
setb MAX_CLK ; we need to shift the outgoing byte after use,
rl outbyte ; but lets do it between clocks to give the clock bit
clrb MAX_CLK ; that little extra settling time...
endm
SendGetByte
bank52 bank_max186
fastbit ; bit 8
rl inbyte ; bit 7
movb inbyte.0, MAX_DOUT
movb MAX_DIN, outbyte.7
setb MAX_CLK
rl outbyte
clrb MAX_CLK
fastbit ; bit 6
fastbit ; bit 5
fastbit ; bit 4
fastbit ; bit 3
...(and so on...)
Macros are expanded at assembly time, and not ar run-time (or simulation-time in case of SXSim). The problem here is that the assembler did not expand the macro code in the list file, i.e. SXSim does not "see" the instructions that are inserted in the code where the macro is invoked. Please add an EXPAND directive in your sorce code somewhere before the macro definition. This should fix the problem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
thanks to some users sending bug reports and making important suggestions for enhancements, I have prepared a new version of SXSim (2.08) with the following fixes/enhancements:
- RTCC timing on ISR entry/exit fixed.
- New "Watchpoint" feature. Instead of halting program execution in "Run" mode, the register display is updated whenever program execution "passes" a marked code line. With "Watchpoint mode" active, the register display will no longer be periodically updated every second.
- Improved editing of file register contents. The arrow keys can now be used to confirm the change of the current register and to navigate to another register to be modified next.
- New "PWR" button added. This simulates a power-on reset with random file register contents, where the "Reset" button now simulates a reset via /MCLR with the register contents being unchanged.
- Different file select dialog used, therefore OMDLG32.OCX is no longer required to run SXSim.
- Manual updated to describe the new features.
As usual, you will find the new version and the updated documentation for download attached to the first post in this thread.
Have fun!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Nice upgrades; makes things much more convenient; we appreciate the effort.
Cheers from Maui, Hawaii,
Peter (pjv)
I just recently hade to reload my SX_Key software and incountered the problem discribed in this post. when I use SX_Key 3.0 (I have updated to the latest compiler Version 1.42.02) I have no problem loading the editor/compiler. But when I update to SX_Key version 3.1 I get the message "SXSim on disk is version 0.00 Update to version 2.06.02 (recommended)."
I followed your instructions copied the sim files to another directory and all. SXSim will launch that way however!!!
when it loaded the SX_Key the next time and got the error message and said yes the next error was "RESOURCE PROBLEM SXSIM.EXE IS IN USE UNABLE TO SAVE TO DISK"
Weather I leave SXSim open or close it same result
If I do a <CTRL><ALT><DEL> I can see the SXSim program is running but no output to screen.
SX_Key always tries to load SXSim first and this causes my problem. I am new to SX and normly just use the SX_Key and not the SXSim program. can I still get a copy of SXKey 3.1 that does not need SXSim. Or is their not that much difference between 3.0 and 3.1
Thank You
Mike W
sorry for ignoring your post such a long time - somehow, I have missed it.
When SXKey 3.1 launches, it checks for the versions of SX/B (residing in the Compilers\SXB sub-folder, and for SXSim in the Tools\SXSim sub-folder. To figure out the SXSim version number, it starts SXSim in a special invisible mode, and queries the version number from SXSim. After this test, the invisible version of SXSim should be unloaded again automatically.
Here, I tried the following: I completely deleted the SXSim sub-folder, and then launched the SX-Key IDE. This shows a dialog "SXSim is not on disk. Version 2,0602 will be installed." I confirmed this with "OK". I did the same for the next dialog about the documentation. After this, the IDE sheoud start as usual, and when you close and re-launch it, no more complaints about SXSim should show up. When you launch SXSim from this IDE, SXSim Version 2.06.02 will start - the one the SX-Key IDE has installed.
You can't overwrite this version of SXSim in the Tools\SXSim sub-folder by a later version, like 2.08.03 because this no longer supports the "hidden mode", and the method of sending its version number to the IDE. So, this may explain the "Resource Problem..." error you get when the IDE tries to start SXSim in "hidden mode" - as it won't be unloaded correctly.
If you want to make use of a later SXSim version for now, please install the EXE file into any other subfolder but Tools\SXSim, or you may install it there under a different name, like SXSim08.EXE. In order to start this version, you may define a shortcut on the desktop, or in the Windows program menu.
I'm sure, the next version of the SX-Key IDE will support this later version of SXSim - until then, I'm sorry for the inconvenience that you can't launch the new version from the IDE.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I am using the SX-SIM to do some debugging, and I would like to have several of the as yet unimplemented "secret" instructions dealt with. These are $001 = mov w,option; $044 = mov debug,w; $045 = exchange carry with osc2; $046 = mov breakpoint,w ????.
Probably you can only implement $001, but for the other ones, could you effectively make them NOPs and hence unfreeze the simulation process so that one can continue to·step/run through the code.
Also, on power-up reset (only)·can you randomize the W register; RTCC; Status bits 2, 1, 0; WKPND_B; the 8 level call stack; all shadow registers; and the 8 level FIFO.
Furthermore in the IND window could you show the content of the location that FSR is pointing at.
These functions would be most useful.
Many thanks for your consideration,
Cheers,
Peter (pjv)
Post Edited (pjv) : 1/3/2006 4:27:57 AM GMT
thank you for your suggestions - I have added all of them to my SXSim TODO-List because I agree with you - these are useful enhancements.
I hope I'll find some time getting these enhancements implemented soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
In using the simulator some more, I note that only integer MHz values are permitted with FREQ directive, fractional Mhz, and (integer) values of Khz are not permitted.
Perhaps this can be changed so we can conveniently determine the cycle times of internal RC or other oscillators also.
Many thanks,
Peter (pjv)
again - added these to the TODO list.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
It's me again. Filally I seem to be exercizing your simulator quite a bit; it's very helpful for some of the strange things I'm doing.
I note that in the register window, the default value for the port bits (inputs at reset) is zero, but when they become configured with pull-ups should they change to a one?
It would be wonderful if both, the input values AND pending output values could be shown, so when an output register gets assigned a value by the program, and (some) of the bits are input, and then the program changes them to output (I do this a lot), then the pre-loaded ouput values get presented on the port bits which have now become outputs.
Also, there is an incorrect operation when right or left shifting a port register. Shifts (right or left) out of a bit which is configured as an input should have a value of one. You provide a value of zero, and non-adjacent outputs should NOT ripple through the port display window; but adjacent ones should. In other words, at any bit where a port register contains a bit configured as an input, then a (left or right) shiftout from that bit should be a one. That is for between adjacent bits as well as the end bits to the carry.
Cheers,
Peter (pjv)
seems as if you are beating SXSim quite a lot right now
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I'm afraid that I'm having trouble on two of my windows xp boxes getting sxSim to run. (one is XP Professional, the other is simply XP, both current updated.) I'd started with the latest budle with the SX-Key IDE from the site. That gave me the "run-time error '339' for MSCOMCTL.OCX (not being correctly registered) that I've seen in other posts.
I've tried the current directions and download from the first post. But this gives the same error, even running entirely by itself. Even if I remove all other SX Key components, and just run the sxsim downloaded from the first post I get this error.
Does anyone have any other thoughts on what I could try, download, change in the registry, spoof, etc.?
Help is greatly appreciated.
Thanks,
Bill McIntyre
MSCOMCTL.OCX is required for applications with serial communication but SXSim does not make use of it, so it looks strange to me that this error comes up, and it never has been reported before. Former versions (before 2.08) made use of the file select dialog contained in COMDLG32.OCX. In the new version, I use a different method so COMDLG32.OCX is no longer required. I'll double-check if there is any reference in SXSim to MSCOMCTL.OCX, and let you know the results.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
its me again - I made a false statement in my last post, MSCOMCTL.OXC is not required for serial communication (this is MSCOMM32.OCX) but for common dialogs, and it is required by SXSim. I'm pretty sure you have it on your machines but possibly another version. Can you search for MSCOMCTL.OXC on your machine, and find out which version it has (in case it is there)?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Many thanks for looking into this. A quick search of my system did not find a local copy of this file. Is it part of a runtime package for VB or C#?
I tried installing the patch here: http://support.microsoft.com/?id=896559 but that also does not seem to have left a copy locally. Apologies for my lmited understanding of the windows libraries. I'm, by trade, primarily a Java developer.
Thanks again,
Bill
I've found a copy of mscomctl.ocx on Microsoft's site (via a 3rd party discussion page found on a search engine, by way of Hoboken)
And have installed it as a single file. Everything now works as described in your first post (eg.: it still complains about comdlg32.ocx in the ide, but the new sx sim file now runs standalone.)
Thanks for the assistance, putting me on the right track,
Bill
glad to hear that you got it up and running now. BTW: As there are various versions of OCXes around, it may be an idea to store the one that works fine for SXSim in the same directory where SXSim.EXE is installed, and not into the Windows directory. As Windows applications search for additional files, like OCXes, DLLs, etc. in the local path first, and then in the Windows path, SXSim will always find a working copy of the OCX locally, even when the one in the Windows path might be overwritten by another software installation later.
Right now, the IDE installs an older version of SXSim that still requires COMDLG32.OCX which can't be found on your machines either. Sorry for this inconvenience but this will be fixed with the next release of the IDE.
Have fun with SXSim!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Try downloading and running the VB6 runtime package. This will contain the usual common dialog and the COM control (mscomctl.com) 's. Best take a copy of your working one first!
The URL is here: http://www.microsoft.com/downloads/details.aspx?FamilyID=bf9a24f9-b5c5-48f4-8edd-cdf2d29a79d5&DisplayLang=en
James
Post Edited (Javalin) : 2/6/2006 9:41:37 PM GMT
thanks for providing the URL - this is really valuable for SXSim users with missing, or non-matching VB runtime modules. As you have pointed out, it is important to save a copy of any existing modules before replacing them. As an alternative, you could place the new modules in the SXSim root directory, i.e. where SXSim.exe is stored, instead of placing them in the Windows directoy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I'm sure your TODO list is growing by leaps and bounds, but I was wondering when the SXSim version supporting multi-purpose timers for the SX48/52 would be released? I'm sure I'm not the only one anxious to simulate it. I am an experienced programmer and could probably get away with simulating everything but the timers and spend a bit of time "in circuit" to reprogram for any errors. But, of course having the SXSim to test the timers would be great!
Thanks
yes, the TODO list keeps growing, and it already contains the multi-purpose timers. Right now, I'm busy with a lot of other stuff, so it will take a while to get them going. At least, they are on the list, and I won't forget them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Today I read your documantation on the SX-Sim for the first time. It is quite notable how intuitive the program is for someone to be able to use (most) of it without "reading the instructions". Good job!
I did note a couple of points that your users should be made aware of, and features you may wish to include in a later version.
Firstly I would like to correct a minor documentation error caused by myself when the "secret instructions" were revealed. It is the definition of the $045 instruction labeled "shift OSC pin in/out W" that is in error. It has nothing to do with the W register; Carry (C) is swapped out to the OSC2 pin, and the OSC2 pin is swapped into the carry. This is the method for the SX-Key and the SX chip to communicate. So instead should be undestood to be something like "exchange carry with OSC2 pin", and it would more appropriately be labelled as "OSC2<>C".
The other point is that for (only) the SX48/52 chips, on interrupt the MODE register is also saved in a single level shadow register. Alas, that register is not accessible by W so one cannot manually push or pop it.
Cheers,
Peter (pjv)
thank you for your hints and comments - they definitely help me improving SXSim.
I'm pretty sure that we can discuss more details personally soon - guess why and where...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
thanks for the information about false clock counts on DECSZ - as far as I can remember, I've alreay fixed it but I'll double-check this again.
Seems as if the 3 instead of 2 cycles bug has found its way into the docs (including my book) a loong time ago. You can also find it in the SX datasheets - even in the new one recently released from Parallax.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G