| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Picture without badlines.
In the last part of Time Machine by Booze Design HCL says that the picture looks very colorful despite not having any badlines. How is that possible to have pictures without badlines ? Lack of badlines causes FLD effect, right ? |
|
... 39 posts hidden. Click here to view all posts....
|
| |
Peacemaker
Registered: Sep 2004
Posts: 248 |
Quote: In bitmapmode you can stretch the last badline read by the VIC without distorting the bitmap. This is done by doing a "fld" at the right cycle, the downside is that that cycle is used for reading sprite 0 resulting in that you can only have seven sprites in the border and two colors (or three + d021 in multicolor) per column on the bitmap.
There is an early example of this effect made by a swedish group (I think it was Triad or Horizon) containing a seven sprite scroller over the Tetris-image. someone else might remember what it is called.
do you remember the demoname now? would be nice. thanks |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
If i'm not mistaken, that's just so-called linecrunching, but with bitmap mode.
Every lines has 63 cycles, the bitmap pointer advances as normal, the colours repeat, all the while the colour/screen pointer is stealthily advanced by 40 bytes each rasterline.
An example is Camel Park - the part in the screenshot. Note how you can also put in empty lines. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
Quote: I tried to display a bitmap without badlines as described above: I have the following code running inside a stable IRQ, with $dc04 timer counting rasterline cycles from 62 to 0 (62 is in the leftmost positon, 0 on the right):
lda #$3a ;%010
sta $d020
ldx $dc04
;raster = $033 (%011), $d011 = $3b (%011), $dc04 = 5 --> 62-5 = 57--> means cycle of rasterline 57+1=58
sta $d011
lda $d012
cmp $d012
beq *-3
lda #$3b
sta $d011
sta $d020
following the above linked thread I understood that $d011 should be changed around cycle 57 of a badline so that least significant bits of $d011 do not match with $d012 same bits.
As first test I tried to get rid of one badline only, but all I get is a black line 8 pixels high right below raster $033. I expected it to be filled with previous colors fetched by preceeding badline, instead.
What I am doing wrong?
in my experience these things never work without trial and error. try changing value written to d011 +-1, cycle of write , etc. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
Tried already, I wrote a flexible code so that I can move along the rasterline and between rasterlines, but without success. I'll investigate Krill's suggetion as next step. |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
One Year Camelot 3 (part in the screenshot) has another example, probably with code that's a tad easier to follow in the monitor. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
All right , I got it to work. Now if I have just 1 badline per screen and change just the 40 values of screen chars (interpreted as color in Bmp mode) corresponding to the area where the badline is, the whole Bmp changes colors. I will post how it's done as soon as I arrange the code in a cleaner shape. |
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
I used the same trick in my REU movie player a while back. Having one or no badlines/frame in order to be able to play samples at 31.2kHz with bitmap video without skipping samples. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
Yup, if you don't want to change the colours per frame, then once you've had one frame in which you load the desired data into the VIC's internal buffer you don't need any badlines at all in subsequent frames. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
here's my IRQ to avoid ALL badlines but still show bitmap:
IRQ0
PHA
lda $01
pha
lda #$35
sta $01
LDA $DC04 ;inverted CIA timer raster stabilizer to compensate jitter
EOR #63
LSR
STA *+4
BPL *+2
.FILL 30-14, $EA
BCC *+2
BIT $EA
lda $dc04
lda #$3e ;$3a
sta $d011
CLC
bit $ea
INC $D019
d012_pointer
lda d012_pointer_tbl ;4
sta $d012 ;4
lda #$3f ;$3b
dec d012_pointer+1 ;6
.fill 9, $ea
sta $d011
bpl IRQ0_000 ;2
lda #d012_pointer_max ;2
sta d012_pointer+1 ;4
dec frame_update_delay ;6
bne IRQ0_000 ;2
lda #frame_update_delay_max
sta frame_update_delay
cli
lda $d018
eor #BMP_OFFS/$0400^BMP_OFFS_A/$0400
sta $d018
dec $01
jsr FRAME_UPDATE
inc $01
IRQ0_000
pla
sta $01
IRQ0_A
PLA
RTI
d012_pointer_max= 24
.ALIGN (* & $FF00) + $0100
d012_pointer_tbl
.for N=25, N>=0, N=N-1
.byte $25+N*8+1
.next
frame_update_delay .byte frame_update_delay_max
frame_update_delay_max = 10
there are some part not really needed to avoid badlines, but are needed in the rest of my code. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
investigating deeper into what really happens, I found that the badline kind of starts, so that it steals the cycles from the CPU but then it is aborted by $d011 first write, so that the VIC does not get color info from the screen. This can be checked by running the code above. IRQ starts with $d012=N and $DC04 = $3f or so depending on the jitter given by last instruction executed outside of IRQ. Note: $DC04 = $3f means raster is on the left of screen. Then $d012 becomes N+1 before executing LDA #$3E, but in such moment $DC04=$0a, so raster is almost at the right side of screen. All cycles in between were stolen from CPU. So we get a half badline. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
