| |
lft
Registered: Jul 2007
Posts: 369 |
Useless coding riddle: Stable raster without I/O
Hi!
I came up with a technique to synchronise code to the raster position without accessing any I/O registers. It is not very efficient, and hence not very useful, but it was a nice intellectual exercise.
This is the premise: Provide a small piece of code (less than a page) that may start executing at any time. When execution reaches the end of the code, the current rasterline and cycle will be known. You may assume that sprites and interrupts are off, and that d011 has its default value (9b).
See if you can figure out how it's done! |
|
... 14 posts hidden. Click here to view all posts....
|
| |
lft
Registered: Jul 2007
Posts: 369 |
@Freshness79:
It's great to see some actual code! This looks rather similar to my own solution (which happens to be 63 bytes). And the I/O registers d020 and d021 in your code can obviously be changed to addresses in RAM, for strict compliance.
I'm curious about one thing: In the large waiting loop (>7000 cycles) there's a write cycle. Did you make sure that it won't interfere with the synchronisation? |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
Yes, of course I've put $d020 and $d021 just to show it works. But, now that I'm thinking about it, with a longer code I may be able to show it without touching I/O.
You're way smarter than me so I'm sure you know how, or maybe that's the way you've already implemented it. :)
About the write cycle (stx $d021), it shouldn't cause any trouble as it's misadligned compared to the INCs. |
| |
ruk
Registered: Jan 2012
Posts: 43 |
Boo! I thought that looping about $100 times would suffice, but no... 62 bytes though :)
https://gist.github.com/p-a/38abcb0091019743d55a |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
Ok, this one does its job by using only two W cycles per frame. I think that's the minimum number, I doubt you can sync with one.
http://pastebin.com/HTuu4KPP
(48 bytes)
Beware, this is S*L*O*W!!! Use warp!
@ruk: hope you won't mind, I've borrowed something from your routine.
@lft: thanks for this nice challenge. And I'm still waiting a code that shows stability w/o I/O (ie no $d020 or such). |
| |
ruk
Registered: Jan 2012
Posts: 43 |
@Freshness, np, sharing is caring =)
Impressed by the size of your code! |
| |
lft
Registered: Jul 2007
Posts: 369 |
Here's my solution. I've squeezed it down a bit to 59 bytes, and it doesn't clobber S.
The code reaches "done" at the last rasterline, cycle 62, so one extra nop would bring you to the top of the screen.
I have verified that 385 iterations are enough through simulation. This gives a total execution time of about 7.7 seconds.
sei
lda #0
ldy #129 ; 385 = 256 + 129
loop0
ldx #169 ; 2
loop3
cmp (0,x) ; \_ 3210
cmp (0,x)
nop
dex
bne loop3 ; /
beq *+2 ; 3
and #1 ; 2
ora #48 ; 2
sec ; 2
loop1
jsr sub ; rrrwwr
sbc #2 ; 2
bcs loop1 ; 3/2
ldx #166 ; 2
loop4
cmp (0,x) ; \_ 3817
cmp (0,x)
cmp (0,x)
dex
bne loop4 ; /
cmp (0,x) ; 6
dey ; 2 \_ 11 (9 when leaving)
bne not0 ; 2/3
lsr ; 2
bcs done ; 2/3
back
jmp loop0 ; 3
not0
bne back ; 3 /
sub
ldx #89 ; 2
loop2
dex ; 2 \_ 444
bne loop2 ; 3/2 /
rts ; 6
done
|
| |
Fresh
Registered: Jan 2005
Posts: 101 |
This is my last one, I don't want to flood the thread. :)
It uses brk and converges a bit faster: 262 frames, about 5.2s.
Too bad that I couldn't bring it down to 256 or less...
One more thought: adding other misaligned write cycles, even though it doesn't ruin the sync process, has the side effect of slowing it down because those writes get "randomly" absorbed by the badlines.
http://pastebin.com/rLNaayPz
(63 bytes) |
| |
ruk
Registered: Jan 2012
Posts: 43 |
@lft: Brilliant as always :) I would never have thought of using JSR in favour of a plain old INC. 10/10 |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
For the record, Quiss's method with Copyfault's refinements solves the problem in 8 bytes, so it does have useful properties for sizecoding. =) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting KrillFor the record, Quiss's method with Copyfault's refinements solves the problem in 8 bytes, so it does have useful properties for sizecoding. =) Oh nice, thanks Krill for the mention. This brought the whole thread here to my notice for the first time, so I really *do* wonder how this could have slipped through my radar for coding riddles.
Nice approaches in here, so thanks also for the pointer! |
| Previous - 1 | 2 | 3 - Next |
