initstabilise lda $d012 ldx #10 ; 2 - dex ; (10 * 5) + 4 bpl - ; 54 nop ; 2 eor $d012 - $ff,x; 5 = 63 bne initstabilise; 7 = 70 [...]; timer setup
HH0c shx $HH00,Y HH0f lda #any_value HH11 bpl *-5
loop: lda $a6,x shx $00a0,y beq loop
entry: ldx $9e ldy #$00 beq loop
Nice, but it would be quite a coincidence that you would need exactly these presettings in the rest of the intro or demo. Perhaps there are ZP adresses that normally (I mean, after a cold start), have the required values.
shx $HH00,y BYTE any_value bne *-4
I know almost nothing about decrunchers, so I don't have a clue what they can do in terms of "initial conditions" of ZP-adresses or registers, etc.
If they can, for example, give you a desired value of X and Y (without increasing net code size), then perhaps a 6-byte loop is possible with something like this: shx $HH00,y BYTE any_value bne *-4 The code location and $HH should be such that X & {H+1} is the opcode for instructions like TXA, TYA, while X should contain the opcode for a 3-byte instruction. So without DMA, the byte after the SHX instruction is replaced by e.g. TYA ensuring the branch is taken, and with DMA the loop exits with the 3-byte instruction whose opcode was in X. But this is stretching it really far!
SHX $HH00,Y CLC BCC *-4
ldy #init_value ;Init code sync: lax $dc04 sbx #51 sty ZP ;RRW instruction. Part of init code. cpx $dc04 bne sync:
Quoting CopyfaultQuoting Rastah BarIf they can, for example, give you a desired value of X and Y (without increasing net code size), then perhaps a 6-byte loop is possible with something like this: shx $HH00,y BYTE any_value bne *-4 [...] Yes this should work. But you're right, it's really shifting *a lot* of preparations to the reign of decruncher & init code. Still quite doable I think. Time to dig out the shortest-code-medal and polish it for the new owner;)The code cannot be freely placed in memory, so you may keep that medal :-)[...]
Quoting Rastah BarIf they can, for example, give you a desired value of X and Y (without increasing net code size), then perhaps a 6-byte loop is possible with something like this: shx $HH00,y BYTE any_value bne *-4 [...] Yes this should work. But you're right, it's really shifting *a lot* of preparations to the reign of decruncher & init code. Still quite doable I think. Time to dig out the shortest-code-medal and polish it for the new owner;)
If they can, for example, give you a desired value of X and Y (without increasing net code size), then perhaps a 6-byte loop is possible with something like this: shx $HH00,y BYTE any_value bne *-4 [...]
$fdfc 9E D0 FD shx $fdd0,y $fdff D0 FC bne $fdfd
Well, in large parts it's the same as what I proposed in post#86.
But now that we entered the territory of over-stretching, here a version that does it in only 5 bytes (again putting all required reg settings on the decruncher's bill) : $fdfc 9E D0 FD shx $fdd0,y $fdff D0 FC bne $fdfd Comes with all constraints one could think of: mem loc fixed, y=$2f fixed val mandatory, x=$d1 fixed val mandatory, setting of vector $fc/$fd has influence on the no. of cycle that are taken when the loop is left, to be started with z-flag=0, ... maybe more! Ok. it's possible to do it with any branch-opcode, but this doesn't really make it any better;)
