Debug Code Window

pjv

To PJ Monty;

I believe you are the person I need to direct these questions to:

Is it possible to·alter the working of the SX-Key debug code window while single stepping (or·for that matter at any time one is not running in real-time)·in such a manner as to keep the "next-to-execute" blue line near the middle of the window?

As I debug, I find it a pain to be not able to see the next snippit of code we are about to execute. In order to see this, and that is nearly all the time,·I always need to manually click the up or down scroll bar.

If the code could scroll in the window with the blue line remaining near the middle, it would save us all a significant amount of debugging time, not to mention the frustration.

Also, could scrolling·by moving the scroll handle be improved? The code lines move past a piece at a time while repainting the whole window, and makes moving long distances very tedious. In fact on my (relatively fast) PC, that process consumes so much resources that, unless I am careful not to overload it, the interrigation of the Key gets missed, and the unit bails out of the debug session. Luckily it will immediately restart using the "control D" sequence, but I have to go through all the sequences again to get me to the state of debug when the unit bailed.

Hope this is possible to make anotherwise godd product so much more convenient.

Many thanks,

Peter

·

PJMonty

Peter,

I'll have to look into what it would take to keep the blue execution line in the middle of the code window during debug. However, I hope you realize that the scroll wheel on the mouse will make that window scroll. I find during debugging that as I single step and the blue line gets toward the bottom, I just click on the code window (to give it the focus) and then use the scroll wheel on the mouse to scroll the window. By using the scroll wheel, I don't have to move the mouse again, and I don't have to aim at a tiny target like the scroll thumb.

As for the scrolling of the code window being slow, I'm not sure what the problem is. I use an Athlon 1800+ machine, and my window scrolls plenty fast. It doesn't peg the CPU meter at 100% or anything like that. What processor is your machine using?

Thanks, PeterM

Post Edited (PJMonty) : 1/16/2005 7:55:48 PM GMT

pjv

Hi Peter;

Thanks for your response.

I (almost) always use my Dell 8200 laptop, so I can easily transport my work home. So no scroll wheel. I fully agree about aiming on the tiny scroll bar target. That is exactly my frustration.

I'll have to look up the processor speed....

While I'm whining...... would it be difficult to change the way entering numbers into the registers during debug works? As I enter new values, the numbers change on the screen, but are not recogized by the system until an "enter" is pressed, eventhough moving to another register, the values are incorrectly left indicating the "unentered" value. A refresh of the register by re-focusing on it will show the proper previous value. At times this can be quite confusing.

It would be nice if a new value keyed in, even without pressing the "enter" key, would get locked in when focus is taken off that register. In this manner one could "arrow over" to a register, change it's contents (without pressing "enter") and then "arrow over" to another register etc. I use this method quite a lot, and am frequently pained by having the contents incorrectly displayed because I had forgotten to press "enter".

Many thanks for your consideration.

P.S. Are you also the person who wrote the assembler??? I need to report a rare assembler error involving PAGE statements near page boundaries, where the assembler loses address count by 1 for every such occurrence. I need to get my head wrapped around that with some more testing to definitively describe the circumstances. It was very tricky to discover, and caused me a lot of grief as it would only occur when the offending statement landed on a specific address. More on this later.

Peter

PJMonty

Peter,

I hear you on the laptop. Of course, I always hook up an external mouse since it's so much easier/faster to use than any trackpad.

Good question about entering of numbers. Again, no quick answer here as I have to look into what that would work would be required.

As for the assembler, the original Parallax assembler was written by Chip "Giant Brain" Gracey, and SASM was originally written by some collection of now faceless/nameless folks at Ubicom. I'm sure they know who they are, but I inherited the SASM codebase, so I have little more than a collection of programmer's initials in the source to tell me who wrote it.

However, if you have found a bug in SASM then please let me know. If you expect me to have any chance of fixing it, you need to provide a piece of source code that causes the bug to occur in SASM. The smaller the piece of source code, the better. In addition, it should be a piece of code that is ready to assemble, and not just a snippet that I have to flesh out just to get it to assemble. The code doesn't have to actually do anything useful (or anything at all) as long as it makes the bug happen when "Assemble" is pressed.

Thanks, PeterM

pjv

Hi Peter;

I will isolate the offending code, and wrap it all up so it will assemble without further work. It will be some effort to minimize it and delete all the non-essential stuff, but we'll get there.

When the problem happens, and it has something to do with a PAGE/JUMP instruction located at a page boundary it causes the assembler to mis-calculate the the subsequent addresses for the jump by one. So the jump land in the wrong spot and of course ugliness happens.

It may be a few days before I can get to this again.

Thanks for your interest.

Peter