Are you thinking about adding support for external events?

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.

Hi Darell,
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?

New SXSim 2.06 Version posted.

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!

Hi again,

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:

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.

Hi Folks,
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.

Hi 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!

Sent the files as requested.

Hi Paul,
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.

Thanks Gunther... but does this explain why I'm getting 50/10 = 2 remainder 10 on the SX28... not 5 remainder 0?

Paul,
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.

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.

Günther,
 Is there anyway to "WATCH" a variable ? Like the debugger does ?
 Bean.

Terry,
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...

King,
Had you taken a moment read the first post in this thread you would find:

KN,
You were told to read the SxSim sticky in your original post which I see you have now asked to be removed.  Instead you came to the SxSim sticky and posted your complaint/question again.  Stop asking for help and then ignoring the answer.  The answer given was not, "Please post your question in the sticky thread."  The answer from Bean was, "Read through the SXSim "sticky" post...".  
If someone says to read the sticky, then read the damn sticky.  I was going to cut and paste the part of the sticky with the answer to show that the answer is there, but then I decided against it.  If you're too lazy to do your part to help yourself then I'm far too busy to waste my time holding your hand and spoon feeding you the answer to your problem.

I have used all my restraint to not unleash a torrent on invective on you the likes of which would melt your CRT.

Sorry but you thought wrong.  I felt it would be more appropiate here.  I also have second thoghts.  If I had the authority I would remove it myself.  STOP MOUTHING OFF.  :mad:   :mad:   :mad:   :mad:   :mad:   :mad:   :devil:   :devil:   :devil:   :mad:   :mad:   :mad:   :mad:   :mad:   :mad:

Hi SXSimmers,
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!

Hi Günther,

I've gotten back into doing some testing of code with SXSim.  What a wonderful job you have done with this tool!  Terrific for making quick tests without having to break out the SX key, proto board, etc.

I have a feature request.

With the SX key debugger in polled mode, it will update the display when it hits the breakpoint then keep going.  It would be nice if in RUN mode of SXSim, you could set a break point where the display would be updated, but keep running.  To make this useful you would have to be able to turn on and off the 1 second automatic update.

The reason I would like this is that I've been playing with routines to convert binary to BCD.  There are some very nice ones on SXlist.  I wanted to test what the minimum and maximum execution times were for all two byte numbers from 0 to 65535.

So I wrote a little test program to run through the conversion of all the numbers and using the RTCC keeps track of the number of cycles, and saves the min and max.

Seems to be working OK with SXsim.  But, when running the program, it would be very nice to have it update the display after every conversion, in stead of every second.  I could see even adding another counter to provide a break point to update the display every 10 or 100 numbers to speed up the testing.

Hi Mike,
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!

Hello Guenther;
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 scramble its contents from a reset.

Frequently I 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; while 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.

Hello Peter,
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.

Hello Guenther;
I vave no opionon the save file, as I'm not sure how ir would apply to me.

Thanks for consideration on the other requests though.

Hi Gunther,
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".

Hi David,
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.

That did it, thanks.

Hello "SXSim-ers",
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!

Hi Guenther;
Nice upgrades; makes things much more convenient; we appreciate the effort.

Hi Guenther
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 I can see the SXSim program is running but no output to screen.

Mike,
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.

Hello Peter,
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.

Hello Guenther;
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.

Hello Peter,
again - added these to the TODO list.

Hi Guenther;
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.

Hi Peter,
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.

Hi Guenther and Team,
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.

Bill,
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.

Bill,
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)?

Guenther,
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.

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!

Hello,
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!

James,
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 Guenther,
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!

CJM,
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.

Hello Guenther;
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.

Peter,
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... :-) .

Günther,
 I didn't see this posted as a found bug so I will mention it.
 When DJNZ does NOT jump the cycle counter increases by 3 instead of by 2
 MOV __PARAM1,#1
 DJNZ __PARAM1,$+10 ' This should be 2 cycles but SxSim make it 3 cycles
BTW I'm using version 2.08.04
Bean.

Terry,
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.

Guenther,
 It's a great tool and I look forward to the next release. It has been very helpful in my testing.
 It's amazing sometimes how incorrect information propagates and it's hard to stamp it out.
 Is 2.08.04 the latest release ?
Bean.

Terry,
yes, 2.08.04 is the latest released SXSim version. New features and fixes are in the pipeline - if I only had some more time...

And no - by no means is it true that I'm planning to write PropSim :-) .

Hi to all...!!

i'm a new entry.
i'm italian, and i'm working to develop a C compiler for scenix.

i like scenix processor but i have some problems with developing software for this processor, and for this reason i decided to write my C compiler.

Actually i have a problem with SXSim
look to these instructions (_AX is a general register)
       mov _AX,#08
       mov w,#08
       mov w,_AX-w at the end, register w must be zero, but w is FF
why?

someone can help me?

thanks!

M.Z.

Hi Marco,
I have tested your sample code snippet with the latest released version of SXSim, and here the code results in W being set to 0 (as it should) but not to $FF as you have mentioned.

Do you have the DEVICE CARRYX option active in your program? In this case, the status of the C flag will influence the result of mov w,_AX-w, so you will have to set C before the subtraction.

many thanks Gunter,
just when i  understand the problem i reading your correct advice.

i'm working with CARRYX and then i must set carry before any subtraction.

thank you.

Hi everyone,

Re: Lost view of "Command Box" (panel)

I'm new to this forum and this is my first post.  I just purchased the SX Tech Tool Kit Professional and I'm going over all the manuals, etc.

I loaded SK-Key v3.1 software and SXSim program and wrote a simple Basic program.  I compiled it and ran it on the simulator.  All worked fine and the Command and I/O panels displayed correctly.  I have been using the SXSim program for the past several days, but, yesterday the Command panel did not display when the SXSim was re-run.  The "Command" box on the bottom tray showed that it was running.  I toggled the box but the Command Panel did not display.  I also right clicked on it but nothing diplayed.  The last time I used the SXSim, when everything was working,  I did remember clicking the "Quit" button on the Command Panel to remove the display, after ending the SXSim program.

Today I did downloaded and installed the latest version of SXSim (v2.08.04).  I ran it under SX-Key v3.1 and this did not help.

Any idea on how to restore the view of the "Command Panel".

Eric,
when your program file is named test.sxb, for example, there should be a file test.sim in the same directory. Please try to delete this sim file - this should bring back the Command window.