[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?

2003-01-30 21:20

Dr. Jay
Account closed

Registered: Jan 2003
Posts: 32

The border is still allowed a background color and a character color, but because it doesn't read character color data, the character is always black. My understanding is that if you reverse the characters, it will show them as the background color on a black background. You can change $3fff as fast as you like, but obviously since a cycle is several pixels, it's not character-precise. My guess is that XBOW rotated in/out reversed characters into $3fff, swapping them every 8 scan lines to emulate the smooth scroll, then covered the excess with a black sprite. There are rotating sprites on top to demonstrate that the characters are not sprites, but I suspect he needed *something* to cover the repeat characters or there would be multiple columns for the scroll.

Da Doc

2003-01-30 21:25

CyberBrain
Administrator

Posts: 392

Isn't there also a way to make the idle-gfx use multicolor? (think i saw that in an old fairlight demo (it looked like idle multicolor gfx) - damn why is my C128 broken, so i can't test?!)

2003-01-31 12:32

QuasaR

Registered: Dec 2001
Posts: 145

I think XBOX wrote an article in Go64 some time ago, stating who he managed to get the chars into border. When I remind right it has something to do with gaps, which are the chars. You could make this gaps with $d016 I think... There was also ONE YEAR CAMELOT which features this scroller aswell.

2003-01-31 13:43

fade
Account closed

Registered: Mar 2002
Posts: 290

xbox hah

2003-01-31 18:52

QuasaR

Registered: Dec 2001
Posts: 145

damn... I ment Crossbow ofcourse...

2003-01-31 19:54

Dr. Jay
Account closed

Registered: Jan 2003
Posts: 32

Is Crossbow from a different planet? Dane, too? Man those guys write some code. Makes my head spin. And to think how excited I was about FLD and having a stable raster ... LOL. I can't believe the new video modes, etc. they come up with. Nice stuff.

2003-02-01 13:28

Cybernator

Registered: Jun 2002
Posts: 154

How could I be so blind? Reversed chars? That's it! I guess I was confused because of the Marko's "PAL timing".

Quote:
"If you find a way to change its color, please tell me how. If you fiddle with the $D011 register near the bottom border, you might be able to use the colors of the last text row."

Well, I'm still not sure if it's possible. Btw, I don't think that XBOW used sprites to cover the other parts. It's possible that you change $3FFF. The problem is that you can't do it immedialtely in the next char. I've noticed that chaging $D021 and $3FFF value doesn't appear at the same place, even if you make the write access at the same cycle. That's one of the tricks. I'm not sure at all, but I suppose this could give you the possibility to show only 2 chars next to each other. To make that only 1 char, he probably used gaps ($D016).

These are just some ideas. I don't know the details about it. I'll need to study it.

@CyberBrain: Never seen a demo where the idle gfx is in multi-color. What was the demo you were talking about? You said your C128 is broken (sad to hear that), does this mean that it won't run on C64?

2003-02-02 18:17

Graham
Account closed

Registered: Dec 2002
Posts: 990

$3FFF color is hardwired to black. in fact it is supposed to be an #$FF pattern so that there is only black to be seen, but somehow the developers mixed something up. on C16 you can see how it was supposed to be.
about multicolor: multicolor will also only display black pixels, but ofcourse double-pixel width (01, 10 and 11).
and finally, it's not always $3FFF. if ECM is enabled the idle data will be read from $39FF. this is due to ECM forces two adress-lines to be always zeros when reading gfx data. this way they limit the characterset to 64 chars.

2003-02-03 09:44

Cybernator

Registered: Jun 2002
Posts: 154

Thanks for the info, master!

Things seem to be clearing up. So, for idle graphics, VIC reads the last character in the last charset area available at the segment. So $ff*8=$7f8 + $3800 = $3ff8... And because RC is 7, it reads from $3fff. If ECM is enabled, it reads $3f*8=$1f8 + $3800 = $39f8 (+7 for RC) which gives $39ff. I'm not sure why VIC picks the last charset, though.
Now let's say that we have normal (NOT ECM) mode, and if we have a way to reset RC, it would read from $3ff8. But is it possible to reset RC after the last rasterline?

Some behaviours of RC are not completely clear to me:

- It resets at phase 1 of cycle 14, in case there's a badline. That's ok.
- In the 1st ph. of cycle 58, VIC checks if RC=7. If so, the video logic goes to idle state. If the video logic is in display state afterwards, RC is incremented.

But how does VIC determine if it's in display state afterwards? Does it use RC? Eg. if RC != 7, then it's in display state afterwards. If it equals to 7, it goes to idle state. But what about RC? Does it remain 7?

Well, I'll give a FLI pic as an example: You generate badlines at cycle 14, every line. Except for the 1st, where you need to give a badline condition before cycle 14, so RC can reset. But as for the other lines, the badline is given at cycle 14, RC will not reset anymore, but rather increment. Then it will become 7, the sequencer goes to idle state. In the next line, there's another badline, so it goes to display state again, but RC will remain 7, right? Wrong, because FLIs work. But how does it overflow? How does VIC know that there will be another badline? Let's say: if there's a badline condition in the current line, RC increments (and thus overflows) no matter what its value is. But then, RC will overflow to 0, at the last rasterline. So I wouldn't have to generate the first badline before cycle 14. But in practise I have to. Doesn't make much sense... :(

Will you please give me some tips, Graham?

2003-02-03 14:24

Graham
Account closed

Registered: Dec 2002
Posts: 990

Cybernator wrote:
"Things seem to be clearing up. So, for idle graphics, VIC reads the last character in the last charset area available at the segment. So $ff*8=$7f8 + $3800 = $3ff8... And because RC is 7, it reads from $3fff. If ECM is enabled, it reads $3f*8=$1f8 + $3800 = $39f8 (+7 for RC) which gives $39ff. I'm not sure why VIC picks the last charset, though."

very simple: the VIC pulls all 14 adress lines to 1 when displaying idle, but ECM seems to have a hardwired logic even "before" that so it will pull those two lines to 0 again.

Cybernator wrote:
"Now let's say that we have normal (NOT ECM) mode, and if we have a way to reset RC, it would read from $3ff8. But is it possible to reset RC after the last rasterline?"

no, a reset of RC will only occur on badlines, and when a badline is started it will display a char until RC=7 is reached. you will always end up with the last line of a char.

Cybernator wrote:
"But how does VIC determine if it's in display state afterwards? Does it use RC? Eg. if RC != 7, then it's in display state afterwards. If it equals to 7, it goes to idle state. But what about RC? Does it remain 7?

Well, I'll give a FLI pic as an example: You generate badlines at cycle 14, every line. Except for the 1st, where you need to give a badline condition before cycle 14, so RC can reset. But as for the other lines, the badline is given at cycle 14, RC will not reset anymore, but rather increment. Then it will become 7, the sequencer goes to idle state. In the next line, there's another badline, so it goes to display state again, but RC will remain 7, right? Wrong, because FLIs work. But how does it overflow? How does VIC know that there will be another badline? Let's say: if there's a badline condition in the current line, RC increments (and thus overflows) no matter what its value is. But then, RC will overflow to 0, at the last rasterline. So I wouldn't have to generate the first badline before cycle 14. But in practise I have to. Doesn't make much sense... :("

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.

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.

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

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

Previous - 1 | 2 - Next

Refresh

Subscribe to this thread: