6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 23, 2024 1:26 am

All times are UTC




Post new topic Reply to topic  [ 413 posts ]  Go to page Previous  1 ... 11, 12, 13, 14, 15, 16, 17 ... 28  Next
Author Message
PostPosted: Thu Apr 01, 2021 5:33 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
8BIT wrote:
I would rather force 16 bit mode and keep the plain '#' reserved for 8 bit use. ... just my thoughts.

I agree. The C32 assembler is non-standard in that regard.

The Kowalski assembler will automatically assemble a 16-bit immediate mode operand if it naturally resolves to 16 bits, assuming the assembler is configured to operate in 816 compatibility mode. By default, I routinely preface an immediate mode operand with !# when I want a 16-bit field assembled, even if it is certain the operand will always resolve to 16 bits. It's my way of making it known to me what the state of m and x is expected to be when that particular code segment is executed.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Fri Apr 23, 2021 7:14 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
Okay, I ran into an interesting issue.

I was test-assembling some code and accidentally triggered an error due to an illegal character being present in a label name. The error reported was An invalid argument was encountered., with an OK button to click to clear the error. However, the assembler got stuck in a loop and clicking OK would not clear the error, instead reiterating it. It was necessary to kill Kowalski from within the Windows task manager to break out of the loop.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Mon Apr 26, 2021 5:11 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
BigDumbDinosaur wrote:
Okay, I ran into an interesting issue.

I was test-assembling some code and accidentally triggered an error due to an illegal character being present in a label name. The error reported was An invalid argument was encountered., with an OK button to click to clear the error. However, the assembler got stuck in a loop and clicking OK would not clear the error, instead reiterating it. It was necessary to kill Kowalski from within the Windows task manager to break out of the loop.


Can you post a copy of the line that caused the error? That way I can trace its path through the code.

thanks!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Mon Apr 26, 2021 5:19 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
8BIT wrote:
BigDumbDinosaur wrote:
Okay, I ran into an interesting issue.

I was test-assembling some code and accidentally triggered an error due to an illegal character being present in a label name. The error reported was An invalid argument was encountered., with an OK button to click to clear the error. However, the assembler got stuck in a loop and clicking OK would not clear the error, instead reiterating it. It was necessary to kill Kowalski from within the Windows task manager to break out of the loop.


Can you post a copy of the line that caused the error? That way I can trace its path through the code.

thanks!

Daryl

I was afraid you'd ask. :D

I lost the piece of code that caused the error when I had to forcibly terminate the assembler and now can't recall precisely what it was I did to provoke the problem. However, I seem to recall that the same error could be triggered by passing too many arguments in a macro invocation. I will try that and report back.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Mon Apr 26, 2021 4:49 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
So far, that appears to be a C language library generated error vs. an error generated by the simulator. It will take some time to trace down the source.

Thanks for pointing it out.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Sat May 01, 2021 4:57 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
I have found the code that is causing the error and added a test that will generate the following Simulator Error and stop assembly:
"ERROR E043: Referenced parameter not exist--param number out of range"

I have posted the updated files to my website as version 1.3.4.2.

https://sbc.rictor.org/kowalski.html

Thanks!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Sat May 01, 2021 5:59 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
8BIT wrote:
I have found the code that is causing the error and added a test that will generate the following Simulator Error and stop assembly:
"ERROR E043: Referenced parameter not exist--param number out of range"

I have posted the updated files to my website as version 1.3.4.2.

https://sbc.rictor.org/kowalski.html

Thanks!

Daryl

Excellent! I've downloaded it and will give it a spin.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Sun May 02, 2021 9:06 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
8BIT wrote:
I have found the code that is causing the error and added a test that will generate the following Simulator Error and stop assembly:
"ERROR E043: Referenced parameter not exist--param number out of range"

I have posted the updated files to my website as version 1.3.4.2.

https://sbc.rictor.org/kowalski.html

Thanks!

Daryl

Looks as though the problem is fixed. Good job!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Last edited by BigDumbDinosaur on Mon May 03, 2021 5:15 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Mon May 03, 2021 3:34 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
BigDumbDinosaur wrote:
Looks as though the problem is fixed. God job!


Daryl might be a super-hero, but I would pull-up short of handing him "God" status. :lol:

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
PostPosted: Mon May 03, 2021 5:15 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
barrym95838 wrote:
BigDumbDinosaur wrote:
Looks as though the problem is fixed. God job!


Daryl might be a super-hero, but I would pull-up short of handing him "God" status. :lol:

I demoted him back to regular status. :D

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Tue May 04, 2021 8:22 am 
Offline

Joined: Wed Feb 17, 2021 6:54 am
Posts: 69
Hi Daryl, Folks,

Can I view different memory locations in different windows? Say, watch $1000 and also $2000

And also, how can I jump to a memory location without having to scroll the window?

Thanks.


Top
 Profile  
Reply with quote  
PostPosted: Tue May 04, 2021 11:48 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
There is only one Memory window, so can only view 1 range. There is also a separate zero-page display.

If you right click on that window, there is an option to "Display from address", which allows you to enter a specific address. You can also modify memory from here, which is useful for debugging.

Thanks!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Tue May 04, 2021 4:21 pm 
Offline

Joined: Wed Feb 17, 2021 6:54 am
Posts: 69
8BIT wrote:
There is only one Memory window, so can only view 1 range. There is also a separate zero-page display.

If you right click on that window, there is an option to "Display from address", which allows you to enter a specific address. You can also modify memory from here, which is useful for debugging.

Thanks!

Daryl


Thanks Daryl! And let me be yet another person to thank you for sharing your passion. I won't say "work" because it probably isn't work for you, but all of it is fantastic!


Top
 Profile  
Reply with quote  
PostPosted: Tue May 04, 2021 7:34 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
BigDumbDinosaur wrote:
barrym95838 wrote:
BigDumbDinosaur wrote:
Looks as though the problem is fixed. God job!


Daryl might be a super-hero, but I would pull-up short of handing him "God" status. :lol:

I demoted him back to regular status. :D



You guys are killing me :lol:

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Tue May 04, 2021 9:07 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
Interesting note. With the assembler now fully understanding the 65C816, I am finding that my code has become more compact and readable due to not having to invoke the macros I had developed to implement 816-specific instructions and addressing modes. This is especially the case with macros with unwieldy names, such as STAILY, which implements STA [<dp>],Y.

Furthermore, assembly is quicker with large programs. For example, POC V1.2's firmware, currently at 12,887 lines of source code, assembles in about a second, with the assembler running on my old Windows XP SP3 machine (powered by an AMD Athlon X2 dual-core MPU). The final version of the firmware that used the 816 macros required about five seconds to assemble. In both cases, the firmware has a bunch of INCLUDE files, which means multiple disk accesses that affect assembly time. That variable hasn't changed, which suggests the assembly performance gain is due to not having to repeatedly look up and expand the 816 macros.

Also very useful are the new pseudo-ops that accomplish things that required macros in the past, such as embedding the assembly date and time, as well as 24- and 32-bit constants. Again, code becomes more compact and readable.

Once again, thank you, Daryl, for expending your time and effort on this software. I'm hoping that having a freely-available 65C816 assembler will encourage others to get involved with the 816 and all that it has to offer.

Attachment:
File comment: POC V1.2 Firmware Assembly Listing (generated by assembler version 1.3.4.2)
aout.txt [590.11 KiB]
Downloaded 71 times

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 413 posts ]  Go to page Previous  1 ... 11, 12, 13, 14, 15, 16, 17 ... 28  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: