| |
crl
Registered: Mar 2020
Posts: 19 |
Lda $d012 And #$07 ora #18 sta $d011
The title says it all. I learned this raster timing trick in 1988, but I never understood why and how it works.
I understand that we in step 1 take the current raster line and AND it by %00000111. In step 2, we OR by %00011000. And then, we store that in $d011.
But when I look at the specific bits in d011, I get confused.
In step 1, we shift the screen downwards by x lines, x being equal to $d012 and %00000111.
But why do we then turn bits 4 and 5 on in d011 in step 2?
Bit 5 = high resolution graphics on
Bit 4 = screen area is visible or not
Can someone explain this 32 years old mystery to me? |
|
| |
Krill
Registered: Apr 2002
Posts: 2940 |
The value only becomes effective with the actual sta $d011.
Bits 4 and 5 need to be set (and bit 6 clear in your case), well, because those control the display mode.
You may change them mid-screen, but the result might not be what you want.
And what you want appears to be display on (bit 4) and bitmap mode enabled (bit 5) and ECM off (bit 6).
You can use other combinations for different screen modes, some of them invalid (black pixels).
Actually i'm not quite sure where your confusion lies. |
| |
crl
Registered: Mar 2020
Posts: 19 |
Ok, so the part that allows me to do raster splits is part 1, i.e. skipping bad linea? |
| |
Copyfault
Registered: Dec 2001
Posts: 468 |
Hmm, looks like setting up a badline condition for the current rasterline. Assuming this "trick" is repeated (in some kind of loop with fixed timing), it should make up FLI = flexible line interpretation.
Short explanation (as addon to Krill's lines;)): a badline is created whenever the lower 3 bits of $D011 match with the lower three bits of $D012 (=current rasline). So your opcodes basically "cut out" the lower bits of $D012, set up some other bits relevant for the gfx mode you want to display (see Krill's post above) and write this to $D011 to "force" the badline condition.
Maybe it was used for smth else, but I strongly guess this was a FLI-routine. |
| |
crl
Registered: Mar 2020
Posts: 19 |
I used this when I did raster splits, meaning that it did occur in a loop |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Sort of. You prevent a bad line condition, effectively turning them off.
However, the bad line condition is precisely that the low 3 bits of $d012 (current rasterline) and $d011 (YSCROLL) match.
So for this to be stable (and not depend on the beam's position within the current rasterline), better add 1 or so before the AND. |
| |
Copyfault
Registered: Dec 2001
Posts: 468 |
Yes;) Wanted to wait for the reply of crl to add this: depending on the timing this "trick" could also be used to _avoid_ badlines: if you made sure that the STA $D011 happens not before the rasterline in which the LDA $D011 was executed, you'd make sure that the rasterline in which the STA $D011 is executed is not a badline. Putting this in a loop makes the VIC continously avoiding a badline.
As always in c64 coding, it all depends on the timing;) |
| |
crl
Registered: Mar 2020
Posts: 19 |
Interesting. Thanks for explaining |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
And btw, it's bit 3 and bit 4 that are turned on when or-ing with $18. Which are:
Bit 4 = enable screen
Bit 3 = 25 rows
Those are pretty essential, in most cases, so it's a good idea to have them set... :) |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Hah, good catch.
But both bits don't mean much until you get close to the lower border and then vertical blank.
Meaning if you set them only some way down the screen, no problem. :) |
| |
crl
Registered: Mar 2020
Posts: 19 |
Mr. Sid, correct. Somewhere in the process, I confused 0-7 with 1-8.
I played a bit my code again, and it seems that bit 3 isn't important to the intended outcome, which in this case is to make some nicely timed rasterbars without badlines.
But what I still don't understand is why I need to keep setting bit 4 (enable screen) every rasterline in order to ensure timing.
Another question I would like to ask is why I get a chessboard pattern on top of my rasterbards when I do this.
I'm sorry if these are stupid questions but I haven't coded for 30 years :-) |
| |
oziphantom
Registered: Oct 2014
Posts: 488 |
are you in default font? probably because you are messing with the bad lines and the VIC is getting char FF which is the checkerboard char in the default font. Change the last byte in the bank ($3fff probably for you at the moment) and see if the pattern changes. |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
crl, have a look at the VIC-article:
VIC Article [english]
Sections 3.5-3.7 and 3.14 are particularly interesting for what you are doing.
It is not that you have to keep setting bit 4, but rather that you don't want to set it to 0. |
| |
tlr
Registered: Sep 2003
Posts: 1762 |
In my earliest side border stuff I used things like this:
.C:464b A0 2F LDY #$2F
.C:464d EE 16 D0 INC $D016
.C:4650 CE 16 D0 DEC $D016
.C:4653 AE 11 D0 LDX $D011
.C:4656 E8 INX
.C:4657 8A TXA
.C:4658 29 07 AND #$07
.C:465a 09 00 ORA #$18
.C:465c 8D 11 D0 STA $D011
.C:465f EA NOP
.C:4660 EA NOP
.C:4661 EA NOP
.C:4662 EA NOP
.C:4663 EA NOP
.C:4664 24 FC BIT $FC
.C:4666 88 DEY
.C:4667 10 E4 BPL $464D
.C:4669 A9 1B LDA #$1B
.C:466b 8D 11 D0 STA $D011 Changing the ORA #$18 -> ORA #$00 makes no difference. I guess I just added it because you're "supposed" to set those bits. |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Actually, doing INC $d011 once per rasterline is sufficient to avoid badlines in that scenario (with a proper initial value).
They are "shoved" to the next line continuously. |
| |
tlr
Registered: Sep 2003
Posts: 1762 |
Quote: Actually, doing INC $d011 once per rasterline is sufficient to avoid badlines in that scenario (with a proper initial value).
They are "shoved" to the next line continuously.
Yes, or modify it to use the loop counter. I wasn't really looking for optimizations here I guess. I remember being quite content just making it work. :) |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Quoting tlrYes, or modify it to use the loop counter. I wasn't really looking for optimizations here I guess. I remember being quite content just making it work. :) Wasn't quite aiming at your old code but at OP's educational benefit. :) |
| |
tlr
Registered: Sep 2003
Posts: 1762 |
Another approach is to just change Y-scroll when absolutely necessary to avoid a bad line. No need to change it every line. |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Quoting tlrAnother approach is to just change Y-scroll when absolutely necessary to avoid a bad line. No need to change it every line. Yes, or open the Y-border but actually clear DEN ($d011 bit 4). Screen remains on, but without any badlines at all! \=D/ |
| |
tlr
Registered: Sep 2003
Posts: 1762 |
Quote: Quoting tlrAnother approach is to just change Y-scroll when absolutely necessary to avoid a bad line. No need to change it every line. Yes, or open the Y-border but actually clear DEN ($d011 bit 4). Screen remains on, but without any badlines at all! \=D/
Good point, forgot about that. Though then you are restricted to idle fetch and sprites only for the full screen. |
