SX-Key Debug Window seems not big enough
LoopyByteloose
Posts: 12,537
Most of my SX-Key software is fine, but I seem to have a problem with truncated windows in the Debug Mode, so I cannot see the last few lines of Memory.· This is rendering my Debug Mode useless as I need to observe the $0F, $1F, etc. registers.
It could be my display font in XP is too big as I have a similar problem with the clock verification Window [noparse][[/noparse]but that is merely trivial].
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
It could be my display font in XP is too big as I have a similar problem with the clock verification Window [noparse][[/noparse]but that is merely trivial].
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
···················· Tropically,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
Can you post a screenshot of the debug and clock windows so I can see what they look like on your machine? If you're not familair with the process, here's how:
1 - With the clock window open, hit ALT-Print Screen
2 - Start MS Paint, the paint program that comes with all versions of Windows.
3 - In the paint window, hit CTRL-V. This will paste your screen capture into MS Paint.
4 - Save the file, preferably as a PNG or JPG to keep the size down.
Repeat this for the debug window.
Also, can you tell me the font and font size you are using in XP? Not the font the IDE uses, but the font XP uses as the font for displaying things like message box text, menu text, etc. Did you change the DPI setting for Windows? What value do you have on your machine?
Thanks,
PeterM
In general, I stay to WindowXP provide defaults as anything else ends up messing with a lot of different software vendors assumptions about what a program will do.
I am using the most recent SX-Key version.
The font size in the WindowsXP display configurations are all default size and NORMAL. I believe I am using·TAHOMA Font and size 8 everywhere·different contexts require. I tried reductions of what was available without sucess.
I have to locate and figure out the DPI settings. I am at 10xx by 7xx pixels. I cannot recall the exact value. I have tried going to 10xx by 10xx with no change.
If I am really the only one with this problem, I can reinstall the software to verify whether it is in Windows or SX-Key.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
Post Edited (Kramer) : 2/19/2008 11:21:37 AM GMT
This is quite odd as it is only a graphic issue in Debug. It seems obvious that it was compiled in a different way or from a different source.
I'll stay with the 96DPI default.
Thanks ever so much as I prefer to use the SX-Debug with the SX-Key instead of the SX-Sim. At times, the SX-Sim stops and I don't really understand why. It has something to do with the RTCC options configuration. I will eventually figure it out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
it would be helpful for me to know if SXSim simply stops without any notification, or does it show an error message? Some sample code demonstrating the problem you encountered could also help a lot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Glad to hear you got it sorted out. Changes in DPI can make GUI programs get weird sometimes.
Thanks,
PeterM
I really hate to bother you as I have been such a slow learner. SX_Sim stops with a message window. The comment is something about the RTI. I am trying to study the RTO.src by Peter V and have compiled sucessfully and have it operating on a board. The only thing I changed was the I/O assignments to 4x Seven segment display.
I strongly suspect that I've just never fully learned to use it correctly as there is little documentation of all the features. So, some of the features are unclear to me. I thought by getting the Debug to run properly, I could compare the two and figure out what I don't understand.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
when designing SXSim, I did not have in mind to create a tool that would be a replacement for the SX-Key debugger, as this is not possible - especially speed-wise. On the other hand, I found it helpful adding some analyzing features that are not available in the "real" degugger.
One of these features is the RETI checking (you wrote RTI but I assume you mean RETI). The RETI (as well as the RETIW) instruction must always be the last instruction of the code for an ISR, i.e. an Interrupt Service Routine. After the tasks to be handled by the ISR are all done, the RETI brings back program execution to "normal", i.e. it restores the contents of the shadowed registers, enables interrupts again, and sets the program counter to have the instruction following the last completed instruction before the interrupt will be executed next.
When you place a RETI instruction somewhere else in your code, i.e. not as terminator of the ISR, the assembler will not complain but when you run such a program, it will do weired things when it comes across this RETI instruction. Yes - I know - we all are well-educated programmers, and we never do something like this, and we also newer place a RET or RETP instruction somewhere in the code except for terminating a subroutine.
Nevertheless, the paged SX program memory can cause strange results when pages are not selected correctly prior to a JMP, or CALL instruction. In such cases, program execution can run into "Nirwana", and chances are good that RETI, RETIW, RET or RETP instructions are executed without a prior interrupt or subroutine call.
Therefore, SXSim allows you to activate checks for RETI/RETIW instructions being executed without a prior interrupt, or for RET/RETP instructions without prior subroutine calls. In a "regular" program, such errors should never happen, so you normally should keep these checks active in SXSim. Nevertheless, there are some programs that make use of the SX secret instructions together with RETI instructions at places where you (and SXSim) normally would not expect them. So when you try to run such code with SXSim - especially when it is originated by Peter V - the "King of multitasking"
BTW: You can find a description of the "Check RETI", and "Check RTCC" features on page 16 in the most recent SXSim documentation available for download from the "sticky" SXSim thread at top of this forum section.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Peter V's 'RTO' or Real Time Operating system is really quite beautiful and educational. I am running it on a SX-28 Protoboard from ports B and C. One doesn't need to replicate his board as presented in the contest entry.
Yes, I believe it is RETI. Thanks for your explanation - thorough as usual. RTI was mentioned from memory as I am further embarassed that my Debug is now fine, but I cannot get the SX-Sim to start. I may have to reload the SX-Key software.
Debug is good for some things, but SX-Sim is very handy too. With SX-Sim, the code's binary image remains entirely intact and I don't have to plug in a board to study operation.
It seems to me, the big advantage of the SX-Sim is that it does NOT require modification of the SXes program memory space in order to run. That at least imposes an ocassional size limitation problem on the program and it seems like in might move the PAGE boundary in an unfortunate manner.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······