Mike wrote: ↑Wed Nov 04, 2020 3:56 pm
I'd presume quite a lot of fellow coders try to optimize their code for size or speed ... and never finish it.
I think that, for me at least, this is as more about learning, about process and about engineering and optimizing code to the nth degree.
I've got a big ol CRT monitor, real 1541, crappy old ribbon printer etc. wAx is my only contemporary indulgence.
For me, if I wanted all singing and dancing code then I'd be looking at RISC-V. This is about turning an ornate newell post using nothing but a bit of bit of string and a nail!
Mike wrote: ↑Wed Nov 04, 2020 3:56 pm
I'd presume quite a lot of fellow coders try to optimize their code for size or speed ... and never finish it.
I think that, for me at least, this is as more about learning, about process and about engineering and optimizing code to the nth degree.
I really enjoy the process of optimizing 6502 code. I find it relaxing, like a nice puzzle. Usually, I'm trying to find a very specific number of bytes so that I can add or improve an unrelated feature. By the time I start doing this, the project is essentially functional.
During this process, frankly, the biggest source of bytes isn't from "optimization" tricks; it's from correcting mistakes. There are lots of mistakes I make that don't affect the execution, like erroneously setting a register or flag when it's not necessary, or repeating code. I make a ton of mistakes. If I need three bytes to set something, I'll probably find them.
VIC-20 Projects: wAx Assembler, TRBo: Turtle RescueBot, Helix Colony, Sub Med, Trolley Problem, Dungeon of Dance, ZEPTOPOLIS, MIDI KERNAL, The Archivist, Ed for Prophet-5
I agree, coding sharps thinking.
Here’s a tiny help for reducing size and rise the execution speed of some filling loop.
Prerequisite the X reg. moving in a positive range.
Yeah, I use the DEX/BPL loop pretty frequently. I learned it from some KERNAL code.
The important thing about this optimization is that X must start between $00-$80 (because X is decremented before the first check). You can't use this technique to iterate over an entire page, for example. For doing an entire page, INX is usually exactly as good as DEX.
VIC-20 Projects: wAx Assembler, TRBo: Turtle RescueBot, Helix Colony, Sub Med, Trolley Problem, Dungeon of Dance, ZEPTOPOLIS, MIDI KERNAL, The Archivist, Ed for Prophet-5
chysn wrote: ↑Mon Dec 07, 2020 1:46 pm
(...) You can't use this technique to iterate over an entire page, for example. For doing an entire page, INX is usually exactly as good as DEX.
Are you sure?
Valid rule today as earlier: 1 Byte = 8 Bits
-._/classes instead of masses\_.-
chysn wrote: ↑Mon Dec 07, 2020 1:46 pm
(...) You can't use this technique to iterate over an entire page, for example. For doing an entire page, INX is usually exactly as good as DEX.
Are you sure?
Sure about which part of it?
VIC-20 Projects: wAx Assembler, TRBo: Turtle RescueBot, Helix Colony, Sub Med, Trolley Problem, Dungeon of Dance, ZEPTOPOLIS, MIDI KERNAL, The Archivist, Ed for Prophet-5
chysn wrote: ↑Mon Dec 07, 2020 1:46 pm
Yeah, I use the DEX/BPL loop pretty frequently. I learned it from some KERNAL code.
The important thing about this optimization is that X must start between $00-$80 (because X is decremented before the first check). You can't use this technique to iterate over an entire page, for example. For doing an entire page, INX is usually exactly as good as DEX.
For more then $80 the common way to cover the full byte range one could use
X counts from COUNT to 1 and with the adjusted address base RAM-1 the range RAM ... RAM+COUNT-1 is covered.
Alas, this method cannot be easily used for STA (ZP),Y ... in this case we can still use counting the index from COUNT-1 to 1, exit on 0 and after the loop do an extra STA (ZP),Y while Y=0.