6502.org • View topic - tricks to avoid imm v abs/zp addressing bugs in ca65?

View unanswered posts | View active topics

Board index » 6502.org Users Forum » Programming

All times are UTC

tricks to avoid imm v abs/zp addressing bugs in ca65?

Page 2 of 2

[ 20 posts ]

Go to page Previous 1, 2

Previous topic | Next topic

Author

Message

Proxy

Post subject: Re: tricks to avoid imm v abs/zp addressing bugs in ca65?

Posted: Fri Jan 26, 2024 6:40 am

Joined: Fri Aug 03, 2018 8:52 am
Posts: 745
Location: Germany

Tbh I personally don't think you should be using raw hex addresses in the first place. Always use symbols, makes the code more readable, allows you to change addresses without modifying hundreds of lines of code, and can also help in this case to distinguish between addressing modes.

Just compare:

Code:

LDA #$6F
STA $6F00

With this:

Code:

variable = $6F00

LDA #$6F
STA variable

Though ideally even specific immediate values should be symbols.

Top

GARTHWILSON

Post subject: Re: tricks to avoid imm v abs/zp addressing bugs in ca65?

Posted: Fri Jan 26, 2024 7:19 am

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California

In the cases of hardware addresses of I/O ICs, you'll usually want to just give the base address of the IC, for example $6000, and then make each register be the base address plus the offset. If you change your address decoding, you'll only need to change the one line telling the base address. You could have for example,

Code:

;                           +----------------------+
;                           |   General Equates    |
;                           +----------------------+

ACIA:       EQU  $9000    ; The base address of the 6551 Asynchronous Communications Interface Adapter is $9000.
ACIA_DATA:  EQU  ACIA+0   ; Its data I/O register is at $9000.
ACIA_STAT:  EQU  ACIA+1   ; Its  status  register is at $9001.
ACIA_COMM:  EQU  ACIA+2   ; Its command  register is at $9002. 
ACIA_CTRL:  EQU  ACIA+3   ; Its control  register is at $9003.

VIA:        EQU  $A000    ; The base address of the 6522 Versatile Interface Adapter is $A000.
PB:         EQU  VIA      ; Its port B is at that address.
PA:         EQU  VIA+1    ; Its port A is at address $A001.
DDRB:       EQU  VIA+2    ; Its data-direction register for port B is at $A002.
DDRA:       EQU  VIA+3    ; Its data-direction register for port A is at $A003.
T2CL:       EQU  VIA+8    ; Its timer-2 counter's low  byte is at $A008.
T2CH:       EQU  VIA+9    ; Its timer-2 counter's high byte is at $A009.
SR:         EQU  VIA+10   ; The shift register is at $A00A.
ACR:        EQU  VIA+11   ; The auxiliary  control register is at $A00B.
PCR:        EQU  VIA+12   ; The peripheral control register is at $A00C.
IFR:        EQU  VIA+13   ; The interrupt  flag  register is at $A00D.
IER:        EQU  VIA+14   ; The interrupt enable register is at $A00E.

(Note that I did not assign anything for addresses $A004 through $A007, which was because I didn't use those registers in the project I copied this from. Note also that the addresses are in hex, with the dollar sign to tell the assembler that, but the offsets are in decimal. You can leave it in hexadecimal all the time if you like, with an assembler directive like RADIX HEX (although it might be different on yours—you'll have to check the manual), but then if you want to use a decimal number, you might have to express it something like D'231' since D231 and 231D are valid hex numbers. It's probably best to leave it in decimal and specify hex with the leading "$" or trailing "H".

Also, let the assembler assign the variable addresses. As long as they fit in the allotted space (like ZP, or a portion of it), the programmer shouldn't care what they are. Just give them names that are meaningful to humans, and let the assembler substitute-in the appropriate address.

Another thing I do is use macros to shorten the code, reduce errors, make it more readable, more maintainable, etc. So for the above example

Code:

   LDA  #$6F
   STA  variable

I might have instead,

Code:

PUT $6F, in, variable

The # is not needed because that's already what PUT is about. If I wanted to copy the contents of ZP address $6F, I'd use COPY instead of PUT:

Code:

COPY $6F, to, variable

(although the $6F address should also have a name that's meaningful to humans).

For a 16-bit variable, it could be something like,

Code:

PUT2 $6F14, in, variable

which is only one line instead of four. The macro definition has conditional assembly such that if the two bytes are the same, the value in only loaded once; and if a byte is 00, STZ is used, avoiding the LDA #0. If the accumulator is not available but X is, you could have something like

Code:

PUT $6F, in, variable, using_X

I feel myself wanting to delve further into the use of macros to make the errors less likely; but I've probably gone off-topic far enough already.

Welcome gilhad. Do what works for you; but those colors are awfully hard for me to read.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Top

gilhad

Post subject: Re: tricks to avoid imm v abs/zp addressing bugs in ca65?

Posted: Fri Jan 26, 2024 11:39 am

Joined: Fri Jan 26, 2024 5:47 am
Posts: 37
Location: Prague; Czech Republic; Europe; Earth

GARTHWILSON wrote:

Welcome gilhad. Do what works for you; but those colors are awfully hard for me to read.

Thank you, GARTHWILSON. I have read many of your pages, and they were very inspiring for me, leading me here. I will write a longer introduction later in the appropriate section when I have more time.

The colors are just my personal settings and serve me well, but I may change them a little after some time of use. I've included them here as an illustration of the principle: using different colors for different addressing modes helps spot missing or misplaced '#' easily. I assume everyone has their preferred colors (bolds, inverse, or whatever else) and will set their preferred editor to their liking.

I have read about not posting poorly colored schematics and preferentially using black and white, as it is a common ground. I will use BW for my schematics as well. The previous illustration was just to show that there is a less intensively used tool that may help if used creatively.

_________________
http://micro-corner.gilhad.cz/, http://8bit.gilhad.cz/6809/Expanduino/Expanduino_I.html, http://comp24.gilhad.cz/Comp24-specification.html, and many others

Top

BigEd

Post subject: Re: tricks to avoid imm v abs/zp addressing bugs in ca65?

Posted: Fri Jan 26, 2024 3:17 pm

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England

Indeed, welcome! I like the idea of getting the editor to help, by one form or another of syntax highlighting. I can imagine bold or inverse, or even italic, might help.

Top

BigDumbDinosaur

Post subject: Re: tricks to avoid imm v abs/zp addressing bugs in ca65?

Posted: Fri Jan 26, 2024 7:13 pm

Joined: Thu May 28, 2009 9:46 pm
Posts: 8144
Location: Midwestern USA

Amplifying what Garth posted (which was an expansion of something I had earlier posted), most of the time I let the assembler do the work for me by not getting too specific on things such as defining run-time variables. Also, as Garth noted, macros can be your friend in helping you to avoid silly errors.

For example, I use a macro called res (reserve) to allocate run-time variable space, e.g., res s_timet, which allocates space for a binary sequential time variable. res s_timet never goofs, but typing *=*+6 to allocate variable space opens the door to an error that may be difficult to catch if I fat-finger the numeric keypad during code entry. Furthermore, if I mistype s_timet, the assembler will complain and refuse to assemble the program statement.

In another example, in much of my software, parameter-passing into called functions is through the stack. Some functions may require as many as five parameters, a mixture of pointers and constants, on the stack, something that is ripe for entry errors. Use of macros helps to make sure a stack frame is properly organized and populated.

As does Garth, I set a base address for any hardware device, e.g., a UART, and then refer to registers with a usually-decimal index from the base address. The base address plus index scheme essentially guarantees addressing errors will be avoided. See attached for how I do it with the 28L92 dual UART (DUART). This file also refers to the vQUART (virtual quadruple UART) scheme I use, which during assembly, makes the four UARTs in the system appear to be parts of a single device.

Attachment:

File comment: NXP 28L92 Register “Map”

registers.asm [4.94 KiB]
Downloaded 42 times

In my POC unit’s serial I/O driver, the above scheme is used to build the physical address tables that get loaded into direct page during POST. Those tables are structured so I can take advantage of that totally useless (<dp>,X) addressing mode.

Once again, I will say that the best defense against errors, such as forgetting # in front of an immediate-mode-addressing operand, is diligence and proofreading. Tools such as color syntax highlighting may help, but ultimately, being meticulous is the best defense against editing-induced errors.

gilhad wrote:

(I use Linux Gentoo, edit nearly everything in Vim, have a half-transparent picture in the background, and use tabs for indenting, shown as blue "|----" marks.)

First off, welcome to 6502-land.

I do all my editing and assembling in the Kowalski simulator, which supports colored syntax highlighting in the editor. I only use a couple of colors, and mostly just to differentiate comments from “live text.” That is useful when I comment out some code during testing—the code stands out in the editor. Being partially color-blind (tritanomaly), I generally stick to colors that have high contrast and are in the lower end of the spectrum.

Although I do take advantage of vim’s syntax highlighting (great for identifying code blocks with unbalanced curly braces or square brackets—I write quite a bit in BASH’s native tongue, as well as in PHP), I have it mostly set up in two colors via my .vimrc file. Some of the default color combinations in vim with syntax highlighting turned on are eye-watering and in a particular case, blue on the default black background, the text is completely invisible.

I also can’t read color schematics because certain color combinations, especially green or yellow on a light-colored background, are invisible to me. Plain old black-on-white works every time!

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

Top

Page 2 of 2

[ 20 posts ]

Go to page Previous 1, 2

Board index » 6502.org Users Forum » Programming

All times are UTC

Who is online

Users browsing this forum: No registered users and 27 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