Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user hllerena78 ! (Registered 2019-08-20) You are not logged in 
CSDb User Forums

Forums > C64 Coding > Better ways to stabilizing raster when sprite multiplexing
2019-07-18 03:38

Registered: Feb 2004
Posts: 14
Better ways to stabilizing raster when sprite multiplexing

This is an odd one. I am trying to get cycle timing correct on lines that have multiple sprites at different locations in different 'frames' of screen update. It's a repetitive multiplexer effect, so every $12 screen updates I have the same configuration of sprites cutting a given raster location.

By just using a $d012 compare (instead of the second IRQ) the variability of the initial IRQ invocation (background code is running) combined with the lower cycle count per line due to sprites makes timing variability *massive* and *inconsistent* - especially when I am trying to hit a color change on a badline.

How would one get a stable raster in this situation? Is the only answer to trigger a second IRQ during the first IRQ and then on the second IRQ lookup a preconfigured delay based on the 'frame' of sprite configuration or am I missing a simpler solution?

Appreciate any ideas.
2019-07-18 07:48

Registered: Apr 2002
Posts: 4431
faster methods use the cia timer. CIA timers count 1 tick per cpu cycle, and can count downwards continously from a given number without intervention, so if you start them at the right time they can be used to see where you are within a rasterline.

shortest CIA-stable raster

you can use then the timer value as a selfmod value to a branch, to skip the nr of cycles needed to stabling. or you can form a jmp $xxyy from the cia registers, so the irq will jump to a routine that has the exact needed delay built int.
2019-07-18 08:16

Registered: Feb 2004
Posts: 14
This sounds very promising. Will try this out... Appreciate your reply.
2019-07-18 10:11

Registered: Apr 2002
Posts: 4431
btw if you only have $12 type of sprite configurations you can "simply" just code a different routine set for each of the $12 possible frames.
2019-07-18 23:02

Registered: Apr 2002
Posts: 1241
If there is enough memory for two sets of sprites, i'd always go for the half-sprite technique or similar.
These allow for switching sprite patterns anywhere within the top and bottom 10 lines, without the need for cycle-exact register writes.

Doubly so for concurrent writes to switch colours, which generally does not mix well with badlines AND sprites.
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Users Online
Speedball/Cyber Design
Don Kichote/Samar Pr..
MaD ][/Starship
Guests online: 55
Top Demos
1 Unboxed  (9.7)
2 Uncensored  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 The Shores of Reflec..  (9.6)
7 Lunatico  (9.6)
8 Wonderland XII  (9.5)
9 C=Bit 18  (9.5)
10 Old Men in Used Cars  (9.5)
Top onefile Demos
1 LSR 64 V0.31  (10)
2 Smile to the Sky  (9.5)
3 Dawnfall V1.1  (9.5)
4 Crystal Gazer  (9.5)
5 Daah, Those Acid Pil..  (9.5)
6 Rewind  (9.5)
7 Instinct  (9.5)
8 Pandemoniac Part 5 o..  (9.5)
9 Innervasion  (9.4)
10 Bad Boy  (9.4)
Top Groups
1 Fossil  (9.8)
2 PriorArt  (9.7)
3 Performers  (9.6)
4 Oxyron  (9.4)
5 Censor Design  (9.4)
Top Logo Graphicians
1 Pal  (9.5)
2 Mermaid  (9.2)
3 Yazoo  (9.1)
4 Elko  (9.1)
5 Compyx  (9.0)

Home - Disclaimer
Copyright © No Name 2001-2019
Page generated in: 0.049 sec.