| |
andym00
Registered: Jun 2009
Posts: 45 |
$d013 sync ??
Okay, be nice, I've been away from the C64 for over 20 years and I thought this would be easy having seen it mentioned once on here... I cobbled this together a few weeks ago, and now when I've just tried it out again I'm getting variable results, regards getting to a stable clock cycle..
lda #16
sta $dc01
lda #0
sta $dc01
lda $d013
lsr
lsr
adc #17+13
lsr
sta bm + 1
bm: bne *
!for .count, 30 {
nop
}
bcs + ; if carry set 3 cycles, if clear 2 cycles..
Okay, so maybe it might be out by a constant amount of cycles, but it's all over the place..
Does this technique actually work (by creating a button press to trigger the light-pen) or have I misunderstood from what little tidbits have been mentioned here ?
I examined a load of demos and don't see much messing with $d013, so I'm guessing maybe I've got the wrong end of the stick, but this should work in theory right ?
I only want it for stablising some CIA IRQs, and I know there's other ways to do it, but this just seemed like something I should give a go, but it's borked :) |
|
... 6 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:I've first seen it in 64'er magazine issue 11/88.
hannes sommer .... (and the routine above is exactly his, copied from said 64er =)) |
| |
andym00
Registered: Jun 2009
Posts: 45 |
Thanks Groepaz, that works a treat, and I hunted high and low for that original article from Hannes curious to see how he originally wrote it.. Now I know :)
I just wanted a nice clean way to setup CIAs at startup to the exact cycle I wanted, and if the users presses space then woe betide them ;)
I only wanted to try this way because I never had done before and I liked the idea of it.. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
I am coding a full screen sprite mux, showing sprites on char screen+upper+lower border (not the side boreders) and I need to have a stable raster even in the lower border area where $d011 MSB is at 1.
I think this $d013 stabilizing code is much more handy than double-irq for working in the raster area over $0ff to $137, since you don't need to care about setting $d011. Usually double-irq method just calls for inc $d012, for triggering stable irq on next line, but this does not work in the lower border.
|
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Of course it works in the lower border. The only time it doesn't work is if you're putting the initial IRQ on line $ff - then you need to set $d011 as well. Workaround: don't do that. Other than that, inc $d012 will work just as fine in the lower border as anywhere else on the screen. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: I am coding a full screen sprite mux, showing sprites on char screen+upper+lower border (not the side boreders) and I need to have a stable raster even in the lower border area where $d011 MSB is at 1.
I think this $d013 stabilizing code is much more handy than double-irq for working in the raster area over $0ff to $137, since you don't need to care about setting $d011. Usually double-irq method just calls for inc $d012, for triggering stable irq on next line, but this does not work in the lower border.
Off-topic (or on topic why you don't need $d013-sync):
Not quite sure why you need stable rasters when sprite multiplexing though... perhaps you switch colors or mode extremly exact? If you just want back to back sprites you can just aswell waste some more memory and save yourself the mess of tight timing. Double the amount of sprites and create intermediate sprites like this:
Normal sprite A:
AA
aa
Normal sprite B:
BB
bb
Intermediate sprite AB:
BB
aa
So, trigger an irq some 10-11 lines after sprite A starts to display and switch to sprite AB and multiplex it in y, then after another 10-11 lines switch to sprite B. Thus you get tight back to back multiplexing without the need for stable rasters or other tight timing.
Use $d012 to multiplex your sprites and fire up an NMI timer to remove the upper and lower border (preferably let timer A trigger in the upper border and timer B at raster line #$f8). By using NMI it will have priority over the sprite multiplexer (which isn't timing critical anymore) and the border will always open.
Just my 2 cents for keeping things simple (assuming my assumptions about your needs are correct). |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
Another much used trick if you need to multiplex several sprites, is to toggle between two or more copies of the screen ($d018 bit 4-7). That gives you some extra flexibility for timing sprite pointer updates.
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
not much of a trick tho, I've 'invented' it myself when I was 15 or so. |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
 |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Such wastage, JackAsser - you only need to duplicate the last couple of lines of the sprites - you just update every 18-20 lines instead of every 21 :)
I agree it's simpler to explain the data requirements if you double your data usage mind. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
thanks for your feedback. Actually what I am working on is a full screen upscroller, similar to Royal Arte last part, but without interlace and without gfx on the background.
I will most probably go for the stable IRQ/$d018 method which eats less memory and will let me put some text/gfx behind the sprites.
Thanks to Oswald for inspiring me to synch every frame individually (suggestion done in another thread).
But I am going off topic now. |
| Previous - 1 | 2 - Next |
