[CSDb] - User Forums - Idle state ($3FFF) color

You are not logged in - nap

CSDb User Forums

Forums > C64 Productions > Idle state ($3FFF) color

2003-01-30 20:53

Cybernator

Registered: Jun 2002
Posts: 154

Idle state ($3FFF) color

I was wondering, is there any way to change the $3FFF color? I mean the char that is displayed at IDLE state, is always black.
I noticed that Krestage, has a border scroller not done with sprites. So I wonder how XBOW did that... $3FFF is the only thing that crossed my mind. But the chars weren't black.

Anyone?

... 10 posts hidden. Click here to view all posts....

2003-02-04 08:26

Cybernator

Registered: Jun 2002
Posts: 154

Graham wrote:
"you should really take a look at C16 machines since that makes the entire behaviour a lot clearer. anyway: the reason why fli works is, that RC is not bound to the end of a char as much as you think. the end-of-charline detection is done in this way: the VIC checks if the y-scroll register matches to $D012 and will end the last charline. a badline is issued a few cycles later, so RC is not resetted but incremented."

When y-scroll matches $D012, there's a badline condition, right?

Graham wrote:
"to make it short: "end of charline" is not related to RC-reset or badline."

Or maybe there's something I don't understand?

Graham wrote:
"on C16 this is much clearer since badlines have nothing to do with RC-reset there. RC is resetted on rasterline 0 and will start incrementing on the first badline. if you change y-scroll on C16, you will change the positions of the badlines, but RC will keep incrementing, so you can update the screen/color data in the middle of the char without any "after cycle 14"-tricks."

I only have a C64. But the behaviour of RC on C16, differs a bit... That also means it won't give me the details about RC on C64.

Another theory: I was thinking about that 40x26 IFLI by HCL. Leave that 40, we are interested in the nr. of rows.
According to the "VIC article": In the first phase of cycle 58, the VIC checks if RC=7. If so, the video logic goes to idle state and VCBASE is loaded from VC (VC->VCBASE). If the video logic is in display state afterwards (THIS IS ALWAYS THE CASE IF THERE'S A BADLINE CONDITION), RC is incremented.

So, we have a badline on every line. At cycle 58, VIC always increments RC (and thus overflows to 0). But this also means that it will show 26 char-lines, right? It didn't seem so.
I thought that if you make 26 rows, the border would move a bit. Heh, how silly. :) So I took a look at the routine that comes with Frodo. The lower (and upper) borders were open. Which means that (I)FLI pics are always 26 rows tall. I'll need to open the border in my IFLI routine to confirm this. Now, in the last (26th) row, badlines cannot be generated since this one is outside the badline-range ($30-$F7). That means the 26th row will finish when RC=7, there's no badline, so the sequencer goes into idle state. RC remains 7 until the next frame.

This one makes sense. I'll have to do some testings to confirm this. This also means that the last row (26th) in HCL's piccy is not FLI, just interlaced.

Now, I need to study horizontal stretchers ;)
Seems a bit insane: VIC tricks won't help, precalculation consumes memory, real-time calc. consumes rastertime. Hmmmmm... And the stretchers seem to be quite fast... What could it be?
And when I think about the rotating up-scroller in Dawnfall... Now, I know that I don't know anything ;)

Thanks again, Graham, and the others too!

2003-02-04 09:35

TDJ

Registered: Dec 2001
Posts: 1879

You guys give me a headache .. this is the reason why I never did any technical coding on the c64. Who needs badlines anyway? :)

2003-02-04 12:16

Graham
Account closed

Registered: Dec 2002
Posts: 990

Cybernator wrote:
"I only have a C64. But the behaviour of RC on C16, differs a bit... That also means it won't give me the details about RC on C64."

C16's TED is based on VIC-II... it is very similar BUT they needed to drop that RC-reset to badline connection, because c16 has two badlines for one character row. this way you see the "real" conditions about characters and RC etc... c16 definitely helps understanding but ofcourse it's not 100% the same. on c16 you can do 40 characters wide FLI very easy :)

Cybernator wrote:
"This one makes sense. I'll have to do some testings to confirm this. This also means that the last row (26th) in HCL's piccy is not FLI, just interlaced."

i would think so... perhaps he uses sprites to enhance the last row.

Cybernator wrote:
"Now, I need to study horizontal stretchers ;) Seems a bit insane: VIC tricks won't help, precalculation consumes memory, real-time calc. consumes rastertime. Hmmmmm... And the stretchers seem to be quite fast... What could it be?"

vic tricks help atleast to make em fullscreen 50 fps :) to confuse you even more: the fullscreen zoomers in deus ex machina hardly take any rastertime and also don't consume much memory. during this effect the loader is loading a packed UIFLI and a packed IFLI picture (still about 120 blocks) and depacks it... all while the zoomer is running :)

2003-03-20 22:03

Krill

Registered: Apr 2002
Posts: 2940

Quote: You guys give me a headache .. this is the reason why I never did any technical coding on the c64. Who needs badlines anyway? :)

The best thing is to perform any kind of code.

2003-03-21 09:09

HCL

Registered: Feb 2003
Posts: 727

> This one makes sense. I'll have to do some testings to confirm this. This also means that the last row (26th) in HCL's piccy is not FLI, just interlaced.

Confirmed. Interlaced but not FLI. No sprites are used there, only on the left 3 chars.

I thought this discussion was about 3fff though ;). That Krestage scroller part is *not* made with $d016, but $d011 (!). Seems like $d011 changes are a bit delayed, so you only get a one-cycle bug when writing to $d011 and then some other register. i can't remember 100%, but i think xbox first writes #$7f to $d011 and then sets $d021, this will make just black to be shown. Then he writes #$1b to $d011 and then black to $d021. Because $d011 is delayed, only one colored $3fff byte will be shown! So, by setting $3fff as well, you can have any 8-pixels wide gfx there. He manages to do this twice per rasterline -> two scrolls.

Ok?

2003-03-21 16:17

WVL

Registered: Mar 2002
Posts: 889

correct. xbow is using $d011, not $d016.. I remember reading one of his articles in go64, where he describes the effects of delays in several different VIC registers (does anyone have the complete article lying around?).. GAPS (such as the ones in the camelot demo (was it One year camelot III or produkthandler kom her? don't remember ;-).) can only be used to make graphics without black pixels

so

..*****. is possible
.*.....* is not

Previous - 1 | 2 - Next

Refresh

Subscribe 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

Advanced

Users Online

megasoftargentina
DuncanTwain
Alakran_64
Xidex/7-Inch
Ghost/Quantum
Edhellon/Resource
swasti
Sentinel/Excess/TREX
The Human Co../Maste..
CreaMD/React
Guests online: 179

Top Demos

1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 Uncensored  (9.6)
7 Wonderland XIV  (9.6)
8 Comaland 100%  (9.6)
9 No Bounds  (9.6)
10 Unboxed  (9.6)

Top onefile Demos

1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Rainbow Connection  (9.5)
6 It's More Fun to Com..  (9.5)
7 Morph  (9.5)
8 Dawnfall V1.1  (9.5)
9 Onscreen 5k  (9.5)
10 Daah, Those Acid Pil..  (9.5)

Top Groups

1 Booze Design  (9.3)
2 Oxyron  (9.3)
3 Nostalgia  (9.3)
4 Censor Design  (9.3)
5 Performers  (9.3)

Top NTSC-Fixers

1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Page generated in: 0.041 sec.