This is (of course) extremely cool. I was having a look over the code to see if I could find any micro-optimisations and I wonder if I've found a minor bug, or just don't understand the code (or both!). In voxasm.asm, we have:That adc #0 seems odd - should we be doing "lda oy+1:adc #0:sta datasource+1" instead? If so, since it obviously works pretty well anyway, could we in fact just get rid of this addition (accepting we might lose the carry occasionally) instead of fixing it, and make oy+1 and datasource+1 the same address?
To try to reduce egg on face if I've just misunderstood the code![:-)]( "Smile")
- my thinking is that the adc #0 changes A and C, but we immediately go on to do an LDA and shortly afterwards we do an SEC without AFAICS using the value in the carry first.
(I was tinkering with a micro-optimisation where we replace "adc oy" and "ldy oy+1" with "adc #" and "ldy #" respectively and modify the stores to oy and oy+1 to just patch those immediate operands. A bit of profiling suggests to me this would save cycles in a hot loop, but I wouldn't like to claim it would make a significant difference to the framerate.)
Code:
clc adc oy sta datasource ldy oy+1 adc #0 sty datasource+1datasource=P%+1 lda datasource ; V%=?B% sta value stx temp ; L% = ((H%-V%) * scale%)DIV256 + Z% lda height secTo try to reduce egg on face if I've just misunderstood the code
- my thinking is that the adc #0 changes A and C, but we immediately go on to do an LDA and shortly afterwards we do an SEC without AFAICS using the value in the carry first.(I was tinkering with a micro-optimisation where we replace "adc oy" and "ldy oy+1" with "adc #" and "ldy #" respectively and modify the stores to oy and oy+1 to just patch those immediate operands. A bit of profiling suggests to me this would save cycles in a hot loop, but I wouldn't like to claim it would make a significant difference to the framerate.)
Statistics: Posted by SteveF — Mon May 13, 2024 10:44 pm