| |
Flashback
Registered: Dec 2009
Posts: 4 |
Want to understand this way of looping through a table
Hi,
I would like some explanation about this way of looping a colour table:
colourcycle.asm
Basically it's this section I can't wrap my head around:
...
txa ; select next colour index
adc #01
and #07 ; loop colour index
tax
...
colours .byte 09, 08, 05, 13, 01, 13, 05, 08 ; colour table
As far as I understand, the start color is saved in a ZP address (startcol) which will is changed each frame. This is done by txa/ adc #$01 I guess. (BTW, why is there no clc before adc here?) But why do we need the and #$07?
Regards |
|
... 27 posts hidden. Click here to view all posts....
|
| |
TheRyk
Registered: Mar 2009
Posts: 2071 |
@Rastah Bar yeah... and more often than not - after spending hours or evenings of cleaning up the mess that once went through as good code for your past self, you just regret not having started from scratch again (which might have even saved time and a bunch of bugs resulting only from messing around with old messy code) :) |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Recoding part of it can definitely help. Instead of looking at the screen and trying to figure it out, recoding may tell you quicker what you were doing and perhaps show some bugs, too. |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Quoting Oswaldthis label: is horrible :P Indeed.
The point of a colon after a label definition is to tell it apart from references to that label.
So you can easily search for that label while conveniently not having to skip over all the references to that label.
Having to add the colon to all references as well is pointless, could just as well have everything without colons, like the OG Turbo Assembler did. =) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Quoting Oswaldthis label: is horrible :P Indeed.
The point of a colon after a label definition is to tell it apart from references to that label.
So you can easily search for that label while conveniently not having to skip over all the references to that label.
Having to add the colon to all references as well is pointless, could just as well have everything without colons, like the OG Turbo Assembler did. =)
ah I didnt know this! finally colon makes sense, but one clever text editor could just show the label without any preceeding characters, I prefer turbo asm way till death :) |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Quoting Oswaldah I didnt know this! finally colon makes sense, but one clever text editor could just show the label without any preceeding characters, I prefer turbo asm way till death :) You'll quickly end up with an IDE again, and i love me my not-too-smart text editors (like KATE aka KEdit). :) |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Quote: Quoting Oswaldthis label: is horrible :P Indeed.
The point of a colon after a label definition is to tell it apart from references to that label.
So you can easily search for that label while conveniently not having to skip over all the references to that label.
Having to add the colon to all references as well is pointless, could just as well have everything without colons, like the OG Turbo Assembler did. =)
If you want to make clear the difference between labels and memory addresses, how do yo do that? For example, labels all in lowercase letters and memory addresses start with a capital? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11116 |
but labels are memory addresses?
*runs* |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Quoting Rastah BarIf you want to make clear the difference between labels and memory addresses, how do yo do that? For example, labels all in lowercase letters and memory addresses start with a capital? Yes, by convention, if need be. It's nothing that needs to be enforced by the toolchain.
My personal convention is all-lower-case for regular labels and allcaps for labels with literally assigned addresses (either by asm source or via linker script). The latter are constants, after all. |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
@chatGPZ: yes, that's true, but I find code a bit easier to read when I see immediately what everything is. But maybe it does not matter in this case.
@Krill: thanks, I will try out some naming conventions. |
| |
Frostbyte
Registered: Aug 2003
Posts: 167 |
This discussion should really be under its own topic (maybe moderators can move it?), but anyway, my 2 eurocents. I've tried a few naming conventions in KickAssembler, and pretty much settled with the following.
Address pointers (i.e. labels), variables and constants are all lowercase, words separated by underscore. E.g.
jsr reticulate_splines
......
reticulate_splines:
lda #next_spline_to_reticulate
Zero page labels are wrapped under "zp" namespace:
.namespace zp {
.label current_player_state = $02
.label spline_tbl_ptr = $03
}
.......
lda #0
sta zp.current_player_state
I use namespaces (even recursive ones) for other special addresses too, e.g. sid and vic and other fixed addresses. This allows me to use dot notation, which imho is very readable, e.g.
lda freq_table_lo, y
sta sid.ch1.freqlo
For macros I use PascalCasing:
MoveCursorTo(15, 13)
...and that's about it. Very simple, really. Namespaces are a godsend, I can easily assign the same context to a bunch of labels or values, and while using them, dot notation separates them clearly from the usual labels or variable names. I don't know how many other dialects have namespaces or a similar concept, unfortunately. Some dialects probably allow adding dots to label names, making naming nearly as neat as using namespaces.
Earlier I tried using all uppercase for ZP variables, constants etc., but ditched it later as it made the code messier to read. |
| Previous - 1 | 2 | 3 | 4 - Next |
