Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user ibux ! (Registered 2020-09-25) 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: 27
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: 4608
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: 27
This sounds very promising. Will try this out... Appreciate your reply.
2019-07-18 10:11

Registered: Apr 2002
Posts: 4608
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: 1522
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
Harry Potthead
DJS/Silicon Ltd
Guests online: 117
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.6)
3 Coma Light 13  (9.6)
4 Memento Mori  (9.6)
5 Unboxed  (9.6)
6 Comaland 100%  (9.6)
7 The Shores of Reflec..  (9.6)
8 Lunatico  (9.6)
9 Remains  (9.5)
10 C=Bit 18  (9.5)
Top onefile Demos
1 Dawnfall V1.1  (9.5)
2 Gumbo Revised  (9.5)
3 Smile to the Sky  (9.5)
4 Daah, Those Acid Pil..  (9.5)
5 Listen to Your Eyes  (9.5)
6 Bad Boy  (9.5)
7 Crystal Gazer  (9.5)
8 Cuarentenauta  (9.5)
9 Instinct  (9.5)
10 The Tuneful Eight [u..  (9.5)
Top Groups
1 PriorArt  (9.4)
2 Booze Design  (9.4)
3 Censor Design  (9.4)
4 Fossil  (9.4)
5 Performers  (9.3)
Top Sysops
1 Optic Freeze  (10)
2 pcollins  (9.9)
3 Pudwerx  (9.8)
4 Aycee  (9.6)
5 Taper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2020
Page generated in: 0.033 sec.