Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > LDA (ZP,x)
2016-05-16 14:31
oziphantom

Registered: Oct 2014
Posts: 490
LDA (ZP,x)

Has anybody ever used this opcode and if so what for?
 
... 33 posts hidden. Click here to view all posts....
 
2016-05-17 19:08
lft

Registered: Jul 2007
Posts: 369
Here's another idea: In a sprite multiplexer, there are some things you need to update in registers that are spaced two bytes apart (x and y coords), and some things that are in consecutive locations (pointers in the vm, colour registers). If we keep the sprite number times two in x, we can access the coordinate registers using ordinary indexed addressing, and then we can have tables of addresses in zero-page for the colour registers, and for the sprite pointers of each vm, and update those values with the (zp,x) addressing mode.
2016-05-17 19:39
Rastah Bar
Account closed

Registered: Oct 2012
Posts: 336
Could the TAS opcode be useful for a multiplexer somehow too? For example, suppose you have a bunch of "objects" and have stored some properties (colors or positions, for instance) on the stack. You could access those by

lax #objectnum
tas $fe00,y

If you let y contain the actual spritenumber to which you want to assign the object with number #objectnum, then the store operation of TAS could be useful.

Sorry that this is not very concrete, but I don't have much experience with multiplexers.
2016-05-18 07:50
Fresh

Registered: Jan 2005
Posts: 101
Quote:

Here's another idea: In a sprite multiplexer, there are some things you need to update in registers that are spaced two bytes apart (x and y coords), and some things that are in consecutive locations (pointers in the vm, colour registers). If we keep the sprite number times two in x, we can access the coordinate registers using ordinary indexed addressing, and then we can have tables of addresses in zero-page for the colour registers, and for the sprite pointers of each vm, and update those values with the (zp,x) addressing mode.

Smart idea, that's probably the most useable solution.
2016-05-18 12:31
Krill

Registered: Apr 2002
Posts: 2980
Quoting lft
and update those values with the (zp,x) addressing mode.
I have a hunch that under normal demo conditions (TM), self-modifying and unrolled code will gain more. Also, one half of the "hot" sprite registers are in consecutive locations (colours, pointers) while the other half are not (x and y co-ordinates) - so 50% of those accesses when updating the "physical" sprites will be slower due to the extra indirection via ZP pointers.
2016-05-18 12:48
Oswald

Registered: Apr 2002
Posts: 5094
usually a plexer writes sprites in a fixed order, thus it can be unrolled. one excetion I know of cadaver's BOFH which assigns priority to virtual sprites and tries to pick a HW sprite based on that.
2016-05-18 14:12
Fresh

Registered: Jan 2005
Posts: 101
Yes, the multiplexer can surely be speedcoded with better performance.
Yet, among the proposed solutions, this use of (zp,x) is imho one of the most sensible. This and (zp)-like, when X is known.
2016-05-18 19:18
Skate

Registered: Jul 2003
Posts: 494
Not directly ZP,x related but recently i moved one of my effect loops to zeropage. When you run your code at zeropage, you have interesting cycle saving method alternatives. For instance if we need to do something like;

ora $xxxx
sta $xxxx


using

lda #<xxxx
sta lo1
sta lo2
lda #>xxxx
sta hi1
sta hi2


is a big waste. Instead we prefer;

lda #<xxxx
sta zp
lda #>xxxx
sta zp+1
ora (zp),y
sta (zp),y


right? If index is not required;

...
ora (zp,x)
sta (zp,x)


would be fine as well. But if your code itself is running on ZP;

lda #<xxxx
sta addr
lda #>xxxx
sta addr+1
ora $xxxx,y : addr = *-2
sta (addr),y ; or sta (addr,x) if suitable


is a nice method to save some cycles.
2016-05-18 20:46
Monte Carlos

Registered: Jun 2004
Posts: 359
It can be used for text scrollers with varying y-pos to fill in the rightmost char if addresses are prepared in zp
2016-05-19 08:50
oziphantom

Registered: Oct 2014
Posts: 490
If they just could have saved the metal on putting it on the LDA, STA, ORA, CMP etc ZP instructions put put it on

JMP( XXXX,x ) instead.

Or yes LDA ( ZP,x ),y would also be very handy.

What does TAS do?
2016-05-19 14:14
Rastah Bar
Account closed

Registered: Oct 2012
Posts: 336
Quoting oziphantom
If they just could have saved the metal on putting it on the LDA, STA, ORA, CMP etc ZP instructions put put it on

JMP( XXXX,x ) instead.

Or yes LDA ( ZP,x ),y would also be very handy.

What does TAS do?


A complete description of TAS and other undocumented opcodes can be found here
No More Secrets v0.9
Previous - 1 | 2 | 3 | 4 | 5 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Guests online: 107
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.047 sec.