| |
tonysavon
Registered: Apr 2014
Posts: 25 |
Different side border colors
I'm trying to obtain (what I thought was) a very simple effect. While displaying a bitmap, I need the side borders to be of different colors just for the 200 lines visible part of the screen (so top and bottom borders would be black). Say I want the left border to be white and the right border to be red.
I played a bit with timing and I kinda achieved something, but it's not really working very well yet. I was wondering if there was a pre-made piece of code somewhere for doing this kind of vertical splits, possibly with a LUT, so that I could have 200 different colors on the left and 200 different colors on the right. Right now I feel like if I keep hammering this spaghetti mess I have in front of me I'll eventually manage to do something, but I wouldn't want to re-invent the wheel and I'm sure there's a clean, short way of doing this
Thanks |
|
| |
Mixer
Registered: Apr 2008
Posts: 452 |
This is an interesting question and it may not be a trivial thing to do.
AFAIK, during bad lines, the cycles between 16 and 56 (the screen area) are stolen by VIC, and the free cycles for code are between cycle 56 of last line and 16 of next line. -> While left border color could be set hidden in the left border, the right side color change cannot take place during screen cycles and would therefore be visible on left or right border at least for a cycle.(8 pixels) I could be wrong though.
-> Solution,open sideborders and cover one side with sprites. |
| |
algorithm
Registered: May 2002
Posts: 705 |
You would need to update the border colors per rasterline in order to achieve this (stable raster is not needed as you can update the d020 register in the non-visible area's)
a simple delay loop taking into account badlines will work well but use up valuable cpu time. (using nmi or timers, or interleaving code inbetween can be done instead however) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Hmm. This is non-trivial/un-possible for bad lines. You don't have time to change the color before the right border on those.
I see two options:
1. Get rid of the bad lines.
2. Open the side border and use sprites to cover the left and right border area. Cleverly using MC-mode or overlapping sprites together with changing color regs should enable every line color changes left and right. |
| |
algorithm
Registered: May 2002
Posts: 705 |
ofcourse, what mixer said.. :-| |
| |
Dane
Registered: May 2002
Posts: 423 |
Cycle
Check the loader parts. |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
Dane: That demo is witchcraft! |
| |
tonysavon
Registered: Apr 2014
Posts: 25 |
Thanks everyone.I'll check the cycle demo and see if I can learn something from that. About opening the borders, wouldn't that be trickier than changing the border color? To open the side border you have to write to $d016 at a specific time for each scanline, including the badlines, at that point I might as well write to $D020.also, getting rid of the badlines is not really an option for me because I have to display an hires picture. On the other hand wasting cycles is not a big deal: I just have to display this hires picture and play a sid, nothing more.
I'll check the demo! Thanks for your support and sorry for the lame question :-P. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
It's one of those problems that seem simple, but are in fact tricker than you expect. Due to badline DMA you can't change the border color while the screen is being displayed, and the first write cycle is available too late:
https://www.dropbox.com/s/wzac1xmjy6iy2w2/lrborder.png |
| |
Dr.Science
Registered: Oct 2011
Posts: 41 |
In one of my last intros, I use different border colors. As it was only for a small area, the timing was done "by hand" for each rasterline: PETSCII Intro |
| |
ciccior2003
Registered: Jun 2012
Posts: 13 |
Shifting on the right the bitmap ( $D016 $0F ) you can put 2 sprites on the left one on the right to cover all the borders. So you have an other sprite to cover one side border with a new color. |
| |
tonysavon
Registered: Apr 2014
Posts: 25 |
Dr.Science, this is exactly the kind of effect I'm trying to obtain. It was very silly of me not to think your intro, since I've been staring at that petscii quite a bit when it came out.
Indeed, the current version of my attempt is exactly what you have done there: manual timing line by line for a small portion of the screen. Although your code looks way more polished :-P.
I think it must be possible to have it for generally long areas and with a LUT to change the colors at will, but perhaps I'm wrong. I'll keep researching and I'll post my findings if I ever land somewhere.
Thanks everybody for your support :-) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
cpu is too slow for LUT based timing on this IMHO.
here's a pointer: try to make it work for one character (8 lines including bad line on top)
then it should be possible to repeat this code (macro or copy paste) for every char row. |
| |
Mantiz
Account closed
Registered: Apr 2006
Posts: 36 |
You can do as above and load the colors directly from a color table somewhere in memory without indexing. Instead you manipulate the color table in the bottom and top border.
For 200 lines it will be 400 bytes at most to change, for which enough cpu time should be available in the top/bottom borders.
(unless the music takes too much time or you are doing something spectacular, then you have to do some of the manipulating during the rasterlines instead, or place some color data in ZP to save cycles.) |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
As Oswald stated, is possible to do this with a loop, or a macro, but timing should be "hand-made" for each "text" line:
https://dl.dropboxusercontent.com/u/93655104/border-poc.jpg
Colors may be loaded from a table... |
| |
Trurl
Registered: Mar 2002
Posts: 61 |
Another example: Mietaa |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Hmm, what am I missing in my test code? Ah, have to use an rmw op (e.g. sta $d020,x) to get it to write at the right cycle. Silly me. This works of course:
.macro delay
ldx #9
: dex
bne :-
bit $ea
.endmacro
lda #left
sta $d020
nop
nop
bit $ea
lda #right
sta $d020,x
lda #left
sta $d020,x
delay
lda #right
sta $d020,x
lda #left
sta $d020,x
delay
lda #right
sta $d020,x
lda #left
sta $d020,x
delay
lda #right
sta $d020,x
lda #left
sta $d020,x
delay
lda #right
sta $d020,x
lda #left
sta $d020,x
delay
lda #right
sta $d020,x
lda #left
sta $d020,x
delay
lda #right
sta $d020,x
lda #left
sta $d020,x
delay
lda #right
sta $d020,x |
| |
The Phantom
Registered: Jan 2004
Posts: 360 |
It can be a pain in the butt, for sure.
You can also see it here... Nightmare Intro
The code for the lower splits is somewhere around $5000... |
| |
tonysavon
Registered: Apr 2014
Posts: 25 |
OK, I think I got there. This is it for a block of 8 lines, the first one being a badline.
https://www.dropbox.com/s/urjdz6fkvvjd7h9/split.bmp?dl=0
The trick is to preload A and Y with the values you want to use, just before the badline, then stabilize the raster using only the x register, and shoot those two values straight away to $d020, with a nop in between. The remaining lines of the block are not badlines and can be done quite easily.
Here is my irq code for that. colortable and colortable+14 are the LUT for left and right borders. colortable is $100 aligned. I think from here it should be easy to extend it to the whole 200 lines that I need.
irq: pha
txa
pha
tya
pha
lda colortable
ldy colortable+14
:stabilize()
sta $d020
nop
sty $d020
ldy #$08
lda colortable+1
sta $d020
!:
dey
beq !skp+
ldx #$02
dex
bne *-1
inc smf + 1
inc smf2 + 1
smf: lda colortable + 14
sta $d020
smf2: lda colortable + 1
ldx $d012
cpx $d012
beq *-3
sta $d020
jmp !-
!skp:
lda #14
sta smf + 1
lda #1
sta smf2 + 1
lda #<irq
sta $fffe
lda #>irq
sta $ffff
inc $d019
lda #$31
sta $d012
pla
tay
pla
tax
pla
rti |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
well, its pretty, but i wish that i could add a spacebarcheck and keep the effect as it is.. :)
23 Byte Effect |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
I read the posts and was wondering: "What is going on here, how on earth it is doable...?" Then I had the major "Doh!" moment.
Since sideborders can be opened on a badline even with 4 sprites on with the first d016 write taking place at cycle 56 - a cycle before right border when screen is x expanded - then it is natural to assume that same is doable with any memory address or register. Done that dozens of times for checking the d016 timing and still I could not connect the dots here :). Fail. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
just do it the oldstyle way. look in some upfront demo. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
WAT. Of course it's trivial, and there are plenty of cycles left even with look-up table action including indexed table access and a loop.
Kompokürbis (Yes, i coded this on short notice, at a party, while having a couple of beers. Seems i have used an assembler, not a monitor, though.)
In which strange parallel dimension have i awoken today? Where have the skills of some of the best coders on this machine gone? Since when is "sta mem,x" a read-modify-write operation?
WHAT. THE. FUCK. |
| |
Peacemaker
Registered: Sep 2004
Posts: 275 |
irq1:
ldx #$20
jsr rasternail (make raster stable)
lda #$32
cmp $d012
bne *-3
ldy #$0b
dey
bne *-1
nop
nop
nop
.var count = 0
.for(var a=0;a<200;a++) {
.eval count = count +1
ldx color1+a
ldy color2+a
stx $d020
sty $d020
.if ( count <= 7 ) {
jsr delay
} else {
.eval count = 0
nop
nop
}
}
inc $d019
pla
tay
pla
tax
pla
rti
delay:
nop
nop
ldx #$06
dex
bne *-1
rts |
| |
Peacemaker
Registered: Sep 2004
Posts: 275 |
Quote: You would need to update the border colors per rasterline in order to achieve this (stable raster is not needed as you can update the d020 register in the non-visible area's)
a simple delay loop taking into account badlines will work well but use up valuable cpu time. (using nmi or timers, or interleaving code inbetween can be done instead however)
stable raster is ofcourse needed. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Hey Gunnar, I was reading the posts lazily and I thought LUT's would be for delays across bad / non bad lines :) I bet the other best coders have similarly good excuses :) |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Haha, well that's what happens when I do a quick forum check and throw together some broken test code before rushing off to work. :)
And yup, don't need RMW but you do need an op with more than one write cycle, lest DMA steals the cycle you need.
As an interesting side note of it'd be a challenge to do it with a 65C02 since extra write cycles in RMW and indexed ops have been replaced by read cycles. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
You guys are funny :) |
