| | 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? |
|
... 6 posts hidden. Click here to view all posts....
|
| | 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? |
| | 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.
|
| | 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? |
| | 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.
|
| | 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!
|
| | 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? :) |
| | 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 :) |
| | Krill
Registered: Apr 2002
Posts: 2969 |
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. |
| | 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? |
| | WVL
Registered: Mar 2002
Posts: 899 |
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 | |
