|
| |
|
Slow Sierpinskiplot [76 bytes] [2016] |
Released At :
Spontaneous Sierpinski Triangle Funcompo
Credits :
Download :
Look for downloads on external sites:
Pokefinder.org
User Comment
Submitted by Skate on 11 July 2016
I just noticed a copy of 71b version on my desktop today. Gave it a second look and found another dirty trick. It's 70 bytes now. :)
* = $032d
!byte $03
- jsr $e416
lda $2c
bpl -
...
|
User Comment
Submitted by Skate on 28 April 2016
ok i found a real clean solution this time.
ldy #$1f
sty $d018
jsr $e0fd
it's kind of a clever solution.
$a667 has
sta $33
sty $34
but the problem is x register is zero, not accumulator. if we use txa together with jsr, it's 4 bytes again, no gain there.
if we look at $a663,
lda $37
ldy $38
clears accumulator since $37 is zero by default but this time it reads $38 to y and things get messed up again, we need to keep y unchanged. luckily $a663 is called from kernel address $e101 and it has a nice sty $38 before the call at $e0fd.
basicly it works like;
sty $38
...
lda $37 ; clear accu
ldy $38
sta $33 ; set zero to $33
sty $34 ; set kept y register value to $34
...
rts
voila :D
also we now have new return values (y:$fa etc) which can be useful for some other size optimization which i couldn't see yet at the first peek. |
User Comment
Submitted by Fresh on 28 April 2016
-2 bytes
lda #$18
...
and $dc04
-and #$03
...
adc $a4,x
...
adc $57,x
...
It's clearly missing the tip because it starts drawing really outside ($1800 vs $1f00) but still it works. |
User Comment
Submitted by Mixer on 28 April 2016
| Discussion forum would be better suited for this. Anyway, I believe one can now add the timed pattern change and full 320 X range and remain <96 bytes length easily. I predict synergy with other bits of the code. |
User Comment
Submitted by Krill on 28 April 2016
Skate: Alright, i stand corrected :)
Your improvement crashes at some point, as the memory will be filled with 0s. |
User Comment
Submitted by Skate on 27 April 2016
even slower now but 71b reached, 7 bytes to go. :)
ldy #$1f
sty $d018
jsr $e412 |
User Comment
Submitted by Skate on 27 April 2016
@Krill: two reasons buddy.
1) Even if CSDb doesn't care much about tiny code categories, Pouet like scene sites has 256b, 128b, 64b, 32b categories. So, 64b is a level up (or down?) in this case.
2) This Sierpinski crap compo all started with my answer to Volcano's release, remember? Check my latest comment there.
Sierpimini [128 bytes]
Submitted by Skate [PM] on 21 March 2016
96b would be too easy. 64b? anyone? :)
I knew 96b limit was easily reachable which we passed already. I also knew 64b would be a miracle to reach which we are 11 bytes away at the moment.
As conclusion, i like 2^n scene limits and i can read the future. :p
ps: nobody would blame you if you make a 63b or a smaller one. ;) |
User Comment
Submitted by Krill on 27 April 2016
| Er, i mean, i'd understand "Make it as small as possible!", but not "Make it 64 bytes!" |
User Comment
Submitted by Krill on 27 April 2016
| Jackasser: Question is "Why 64 bytes?" rather than "Why as small as possible?", which i'd perfectly understand :D |
User Comment
Submitted by JackAsser on 27 April 2016
| @Krill: Why?!? That's the dumbest question I've ever heard from a C64 Scener. ;) |
User Comment
Submitted by Krill on 27 April 2016
| \:D/ So, goal is 64 bytes, or what? And why? :D |
User Comment
Submitted by Mixer on 27 April 2016
So, 72 bytes now :)
lda #$1f
sta $d018
stx $33
sta $34
..
ldy #$28
-
jsr $b6cb ; has pha pla
and #$f8 ; <- very clever!
dey
bne -
...
ora ($33),y
sta ($33),y |
User Comment
Submitted by Krill on 27 April 2016
Hmm, i'm at 74 bytes now as well, but with that mul bit changed yet another time. Maybe a combined approach saves more bytes? :)
lda #$1f
sta $d018
stx $7a ; bitmap pointer lo
sta $7b ; bitmap pointer hi
...
sta $02
ldy #$28
mul pha
jsr $a8fc ; (y and f8) *40
pla
and #$f8
dey
bne mul
|
User Comment
Submitted by Mixer on 27 April 2016
Once Krills comment is factored in, the length is 74 bytes. Which is nice. :)
; i = rnd(2)
; x=(x+tx) >>1
; y=(y+ty) >>1
; addr=bitmapstart + (y and f8) *40 + (y and 07) + (x and f8)
; mask=1 << (x and 07)
; addr=(addr) or mask
; repeat
b699, b6cb, ba65 could be useful, zp indirect x could be useful...
Don't give up yet. |
User Comment
Submitted by Zyron on 26 April 2016
User Comment
Submitted by Skate on 26 April 2016
Ok, let's play our last trump card. Even Crossbow can't fit this routine in 64 bytes.
Now, just wait for it. :D |
User Comment
Submitted by JackAsser on 26 April 2016
| Indeed hard! Have been staring at the code for hours.. |
User Comment
Submitted by Skate on 26 April 2016
| 64b is possible... just haven't figured out it how, yet. :) |
User Comment
Submitted by Krill on 26 April 2016
Hmm....
sta $7a ; row in char to bitmap pointer lo
eor $02 ; and #$f8
+ tay
- ldy #$28
-mul pha
+mul lda #$28
jsr $a8fc; (y and f8) *40
- pla
dey
bne mul
But now it starts to get real hard to find more bytes to squeeze out... :D |
User Comment
Submitted by Krill on 26 April 2016
| Oh, that was supposed to go to the goofs section. But now that you can neither edit nor delete comments... :) |
User Comment
Submitted by Krill on 26 April 2016
| Also typing while it renders. But that's a feature, not a bug! :) |
User Comment
Submitted by mankeli on 25 April 2016
User Comment
Submitted by Didi on 25 April 2016
| That's what I call teamwork. ;) |
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs (1)
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
 |  |
|
![Slow Sierpinskiplot [76 bytes]](/gfx/releases/147000/147755.png)
