[CSDb] - User Forums - Picture without badlines.

Welcome to our latest new user Harvey ! (Registered 2024-11-25)

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Picture without badlines.

2018-02-08 10:15

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 ?

2018-02-08 12:07

Trash

Registered: Jan 2002
Posts: 122

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.

2018-02-08 12:13

AmiDog

Registered: Mar 2003
Posts: 97

I was actually thinking about this myself a while ago for totally different reasons. I think one badline/frame is the minimum to show a bitmap. After the first badline, it should be possible to change the yscroll just as for FLI, but instead to make sure there never is a match and thus no more badlines, right? Would result in the same colors for the entire picture I guess. I wonder if that first badline could be avoided too somehow... (Not for the first frame since the color data needs to be fetched alteast once, but for the following frames.)

2018-02-08 12:28

Trash

Registered: Jan 2002
Posts: 122

Quote: I was actually thinking about this myself a while ago for totally different reasons. I think one badline/frame is the minimum to show a bitmap. After the first badline, it should be possible to change the yscroll just as for FLI, but instead to make sure there never is a match and thus no more badlines, right? Would result in the same colors for the entire picture I guess. I wonder if that first badline could be avoided too somehow... (Not for the first frame since the color data needs to be fetched alteast once, but for the following frames.)

Like this one: Just an Illusion

2018-02-08 12:39

Golara
Account closed

Registered: Jan 2018
Posts: 212

That's cool. I Guess then you can display fullscreen grayscale pics with lots of free cycles.

2018-02-08 12:56

Golara
Account closed

Registered: Jan 2018
Posts: 212

Semi related question... Let's say normal badline starts at line 1, then 9. If I cause a badline at line 4 doing FLI, will the next badline still happen at line 9, or does the counter restart and it will happen at 12 ?

2018-02-08 13:11

lft

Registered: Jul 2007
Posts: 369

There are two different things in play. There's a counter (called RC in the vic article) going from 0 to 7 during each character row. Then there's the current Y-position (in d012).

Badlines occur when YSCROLL (low bits of d011) matches d012.

RC is reset if there's a badline condition on cycle 14. When doing FLI, you change YSCROLL to create a badline condition just after that, so the counter doesn't reset. But if you then leave YSCROLL at the new value, it's gonna match d012 eight lines later, i.e. at line 12 in your example.

VIC timing chart

2018-02-08 14:29

Golara
Account closed

Registered: Jan 2018
Posts: 212

So if I cause badline at exactly cycle 14 (the last sta $d011 cycle is at cycle 14) then I'll cause a badline and reset RC at the same time, correct ? Will I read the next text line from pixel 0 or the same text line from 0 ?

2018-02-08 14:45

Oswald

Registered: Apr 2002
Posts: 5086

basicly you are repeating the first screen row.

similar topic:

https://csdb.dk/forums/index.php?roomid=11&topicid=119133&first..

also the bitmap is not restricted to 4 colors, only each char column is restricted to 4 colors, because of displaying the same row of color attributes in all rows.

2019-11-05 15:33

ready.

Registered: Feb 2003
Posts: 441

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?

2019-11-05 16:14

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

2019-11-05 18:29

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.

2019-11-05 21:48

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.

2019-11-05 22:23

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.

2019-11-05 23:05

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.

2019-11-06 09:28

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.

2019-11-06 11:40

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.

2019-11-06 12:06

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.

2019-11-12 11:18

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.

2019-11-12 13:05

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.

2019-11-12 13:44

Krill

Registered: Apr 2002
Posts: 2969

Quoting ready.

So we get a half badline.

Seems like you're inadvertently triggering delayed DMA. If done right, every line really has the full 63 cycles.

2019-11-12 14:02

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: 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.

This is a piece of code from my part that does this effect. There's 4 sprites on the line

!for line,0,164{
stx $d017
!if (line >= 250-135){
lda #$0 + ((line + 7 ) & 7 )
}else{
lda #$38 + ((line + 7 ) & 7 )
}
sta $d011

lda sinus_read + (((line*4) + 0)&255)
sta $d000
lda sinus_read + (((line*4) + 1)&255)
sta $d002
lda sinus_read + (((line*4) + 2)&255)
sta $d004
lda sinus_read + (((line*4) + 3)&255)
sta $d006

lda #3 //free 6 cycles
sta $d021 //for something....
sty $d017

}

My loop is 52 cycles, exactly how many cycles the CPU has on a non-badline line with 4 sprites enabled. Not sure why are you losing some cycles.

BTW. This is different kind of "picture without badlines", the Booze part I mentioned in the first post does FPD, so I think it's different (repeating the last line of a char ?)

2019-11-12 19:42

ready.

Registered: Feb 2003
Posts: 441

I still can get it right then. I understood I must trigger a badline at RC=7. Using screen position = %011, RC=7 at raster $37, $3F, $47,... I guess that if screen position changes, also the condition RC=7 happens at a different rasterline, because the end of a char block is moved vertically.
So I set my first IRQ to set $d011=$3F at raster=$037 and cycle 55. This forces a badline.
Next thing is to restore $d011 to $3b, which ensures that RC=7 happens at raster $37, $3F, $47,.... But it will also provide a badline at raster $3b, $43,.... which is unwanted of course.
So I can't get out of it. What I am missing? Tried to analyze some code of demos posted above but I couldn't really get into it, since there were also other $d011 tricks mixed in the middle.

2019-11-12 23:58

ready.

Registered: Feb 2003
Posts: 441

I also tried to use this approach in my code:
https://codebase64.org/doku.php?id=base:repeating_char-lines&s[..

Also Oswald seems to use the same, as stated in a post from this:
https://csdb.dk/forums/index.php?roomid=11&topicid=119133&first..

The problem is that the code I linked doubles both text screen and bitmap screen, so all I get is the first 8 piexls line of the bitmap repeated through the whole screen. I want to repeat just the text (thus color in bimtap mode) screen.

2019-11-13 08:17

Oswald

Registered: Apr 2002
Posts: 5086

the greetings part in here Smart Girls Hate Booze has such a bitmap screen, maybe you can peek from it.

2019-11-13 09:23

Krill

Registered: Apr 2002
Posts: 2969

Quoting ready.

I understood I must trigger a badline at RC=7. Using screen position = %011, RC=7 at raster $37, $3F, $47,...

The fake badline condition must be triggered in every line (within the correct cycle window), thus $d011 needs to be written to in every line, just as Golara does. See also https://codebase64.org/doku.php?id=base:linecrunch.

2019-11-13 09:49

ready.

Registered: Feb 2003
Posts: 441

ok, I was expecting it could be done just for a few lines, triggering an irq every 8 rows. Since I need to run a background program, I need the irq to steal as little cycles as possible. Then I guess my first approach will just do fine. The whole need for this effect was to save memory getting rid of the screen RAM, to be able to alternate 2 bitmaps in the same bank.
Thanks a lot for the support!

2019-11-13 10:00

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: ok, I was expecting it could be done just for a few lines, triggering an irq every 8 rows. Since I need to run a background program, I need the irq to steal as little cycles as possible. Then I guess my first approach will just do fine. The whole need for this effect was to save memory getting rid of the screen RAM, to be able to alternate 2 bitmaps in the same bank.
Thanks a lot for the support!

This effect only makes sense if you need all the cycles every line, like me, I needed to change 4 sprite X positions and stretch them (2 writes to d017), had to get rid of the badlines. I don't think you can manipulate badlines just to avoid them stealing cycles from your non-irq code. Besides, if you add up all the cycles the badline takes, you get 1000 cycles per frame. A full frame has 19656 cycles, so all the badline steal only 5% of the raster time

2019-11-13 12:48

ready.

Registered: Feb 2003
Posts: 441

In fact, Golara, I was not seeking for extra cycles by removing badlines. My goal is to get rid of screen RAM due to memory constraints, so I can use 1 single VIC bank for 2 bitmaps, without screen RAM. And with the code I posted I succeeded in that. On the practical side, I have half badlines allover the screen.

2019-11-13 12:59

Krill

Registered: Apr 2002
Posts: 2969

Something doesn't quite add up then. If you're getting any kind of badline DMA, colour information should be read and applied. Can you post a binary of your code?

2019-11-13 13:59

JackAsser

Registered: Jun 2002
Posts: 2014

Just take a look at LFT's timing diagram.

In normal display the VIC will go to IDLE after RC=7 so what you wanna do is do bring in into bad line STATE (not trigger an actual badline). This has to be done after cycle 55 and before 58. This will increment RC and make it wrap to 0. During the next raster line the badline condition isn't set anymore and it will simply display the next row of bitmap using the old char data.

2019-11-13 15:11

Oswald

Registered: Apr 2002
Posts: 5086

Quote: Something doesn't quite add up then. If you're getting any kind of badline DMA, colour information should be read and applied. Can you post a binary of your code?

he can have a bad line from some other bank buffered by the VIC forever.

2019-11-13 15:13

Oswald

Registered: Apr 2002
Posts: 5086

btw I have code somewhere to repeat first char row's full 8 lines somewhere,would that be useful ? (not sure if works in bitmap mode) there must be even a topic about it, I asked here a few years ago.

2019-11-13 16:03

JackAsser

Registered: Jun 2002
Posts: 2014

Quote: he can have a bad line from some other bank buffered by the VIC forever.

Indeed, if you constantly avoid the bad line condition the char pointers are the same forever.

2019-11-13 16:13

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: In fact, Golara, I was not seeking for extra cycles by removing badlines. My goal is to get rid of screen RAM due to memory constraints, so I can use 1 single VIC bank for 2 bitmaps, without screen RAM. And with the code I posted I succeeded in that. On the practical side, I have half badlines allover the screen.

Oh ok, then it makes some sense.. I actually tried doing it just now and I think it's possible. You need to make a badline condition when RC=7 on cycles 55-58. That will cause the last charline to be repeated. You then need to set the YSCROLL back to some other value... easier to explain in steps, so here's the recipe:

Get at least one badline in a frame to read in one line of chars (even from previous frame)!

Start with Y scroll 0 (badline at line $30, $38 etc..)
IRQ at line $30 + 7
set Y scroll to 7 (make badline) but at cycle 55-58
wait for line 30 + 8 + 1
set Y scroll to 0
IRQ at line $30 + 8 + 7
set y scroll to 7 (make badline) but at cycle 55-58
wait for line 30 + 16 + 1
set Y scroll to 0

see the pattern ? Still, not sure how viable it is, since you need to waste some cycles to stabilize the raster IRQ.

2019-11-13 16:31

Krill

Registered: Apr 2002
Posts: 2969

Quoting Oswald

he can have a bad line from some other bank buffered by the VIC forever.

Quoting JackAsser

Indeed, if you constantly avoid the bad line condition the char pointers are the same forever.

My point was that if there is badline DMA as ready. claims, the buffer (or parts thereof) will get updated pretty much by definition.

2019-11-13 18:17

ready.

Registered: Feb 2003
Posts: 441

well, I posted above the irq code that does it. It lacks of course the rest of the code like stabilized irq and so on. Irq is stabilized via CIA timer, basically CIA timer is the inverted horizontal raster position in terms of O2 cycles. Should you need more I can provide.

2019-11-14 08:56

HCL

Registered: Feb 2003
Posts: 727

The demo you're looking for is Bonanza.

Something that confuses this topic is that there are two different techniques to do pictures without badline, as was the original question:

First LineCrunch, which is used in the demo above, enables you to have open sideborders with up to 7 sprites, but needs to be triggered every rasterline. This effectively *eats* up the image, displaying only line 7 of each char. Thus you can also use it for moving pictures vertically, which is also displayed in the demo above.

Then you have the RepeatingChar, where you need only 2 writes to $d011 for each char-line. Not combinable with open sideborders, but sprites of course. I use this always! ..unless i need more than 4 color.. or i need open sideborder ..or i need more char buffers .. or..

2019-11-14 09:02

Oswald

Registered: Apr 2002
Posts: 5086

so no way to have *any* kind of gfx for a bigger area (stretched or not whatever) and open sideborder and 8 sprites ?

2019-11-14 11:03

HCL

Registered: Feb 2003
Posts: 727

Nope.. 3:rd part of Time Machine is pretty maxed out.. Different colors in each char "column", extended into sideborder using sprites and 12 moving sprites on top.

The last part looks similar, only the graphics is FPD-stretched there. Helluvalot more complicated :P

2019-11-15 03:39

Peacemaker

Registered: Sep 2004
Posts: 248

have a part that exacatly does what the threadcreator is asking for plus some "effect" on it.
maybe one day ill release the little demo along some other parts.

2019-11-15 10:03

Krill

Registered: Apr 2002
Posts: 2969

Quoting Oswald

so no way to have *any* kind of gfx for a bigger area (stretched or not whatever) and open sideborder and 8 sprites ?

Pretty sure it's one of the things that are possible on machines with 65 cycles per line, i.e., new NTSC and PAL N, but not on Euro-PAL.
The following is a conjecture, i'm not aware of existing productions and haven't tested it myself yet.

The two extra cycles go there: in the right border, sprite 0 fetch starts one cycle later than on 63-cycles PAL (thus no need for RMW $d016 instructions to have 8 sprites and open sideborders), and in the left border on the next rasterline, sprite 7 fetch ends one cycle earlier with regard to the clear-RC condition, as a rasterline has 2 more cycles and sprite fetches are back to back.

Due to the latter extra cycle, there are 4 and not just 3 cycles between sprite 7 fetch and the clear RC condition check. A store to $d011 would neatly fit in there to abort the badline condition and cause RC not to be reset, effectively triggering linecrunch.

So, open sideborders with 8 sprites AND linecrunching should be possible, just not on Euro-PAL.

2019-11-15 12:23

Rastah Bar
Account closed

Registered: Oct 2012
Posts: 336

According to http://unusedino.de/ec64/technical/aay/c64/victnl.htm both extra cycles are just before the sprit 0 fetch.

2019-11-15 13:15

Krill

Registered: Apr 2002
Posts: 2969

Quoting Rastah Bar

According to http://unusedino.de/ec64/technical/aay/c64/victnl.htm both extra cycles are just before the sprit 0 fetch.

This assertion appears to stem from Christian Bauer's venerated VIC article, which claims the same.

However, according to VICE sourcecode found in https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/sr.. we see

PAL: 3 cycles between sprite 7 fetch and UpdateVC

    { Phi1(10), 0x1dc, None,    SprDma1(7), BaSpr1(7),       None                 },
    { Phi2(10), 0x1e0, None,    SprDma2(7), BaSpr1(7),       None                 },
    { Phi1(11), 0x1e4, None,    Refresh,    None,            None                 },
    { Phi2(11), 0x1e8, None,    None,       None,            None                 },
    { Phi1(12), 0x1ec, None,    Refresh,    BaFetch,         None                 },
    { Phi2(12), 0x1f0, None,    None,       BaFetch,         None                 },
    { Phi1(13), 0x1f4, None,    Refresh,    BaFetch,         None                 },
    { Phi2(13), 0x000, None,    None,       BaFetch,         None                 },
    { Phi1(14), 0x004, None,    Refresh,    BaFetch,         None                 },
    { Phi2(14), 0x008, None,    None,       BaFetch,         UpdateVc             },

NTSC: 4 cycles between sprite 7 fetch and UpdateVC

    { Phi1(9),  0x1dc, None,    SprDma1(7), BaSpr1(7),       None                 },
    { Phi2(9),  0x1e0, None,    SprDma2(7), BaSpr1(7),       None                 },
    { Phi1(10), 0x1e4, None,    Idle,       None,            None                 },
    { Phi2(10), 0x1e8, None,    None,       None,            None                 },
    { Phi1(11), 0x1ec, None,    Refresh,    None,            None                 },
    { Phi2(11), 0x1f0, None,    None,       None,            None                 },
    { Phi1(12), 0x1f4, None,    Refresh,    BaFetch,         None                 },
    { Phi2(12), 0x1f8, None,    None,       BaFetch,         None                 },
    { Phi1(13), 0x1fc, None,    Refresh,    BaFetch,         None                 },
    { Phi2(13), 0x000, None,    None,       BaFetch,         None                 },
    { Phi1(14), 0x004, None,    Refresh,    BaFetch,         None                 },
    { Phi2(14), 0x008, None,    None,       BaFetch,         UpdateVc             },

and

PAL: No extra cycle before sprite 0 fetch

    { Phi1(54), 0x144, Vis(37), FetchG,     BaFetch,         None                 },
    { Phi2(54), 0x148, Vis(38), FetchC,     BaFetch,         None                 },
    { Phi1(55), 0x14c, Vis(38), FetchG,     BaSpr1(0),       ChkSprDma            },
    { Phi2(55), 0x150, Vis(39), None,       BaSpr1(0),       None                 },
    { Phi1(56), 0x154, Vis(39), Idle,       BaSpr1(0),       ChkSprDma            },
    { Phi2(56), 0x158, None,    None,       BaSpr1(0),       ChkBrdR0 | ChkSprExp },

NTSC: One extra cycle before sprite 0 fetch

    { Phi1(54), 0x144, Vis(37), FetchG,     BaFetch,         None                 },
    { Phi2(54), 0x148, Vis(38), FetchC,     BaFetch,         None                 },
    { Phi1(55), 0x14c, Vis(38), FetchG,     None,            None                 },
    { Phi2(55), 0x150, Vis(39), None,       None,            None                 },
    { Phi1(56), 0x154, Vis(39), Idle,       BaSpr1(0),       ChkSprDma            },
    { Phi2(56), 0x158, None,    None,       BaSpr1(0),       ChkBrdR0 | ChkSprExp },
    { Phi1(57), 0x15c, None,    Idle,       BaSpr1(0),       ChkSprDma            },
    { Phi2(57), 0x160, None,    None,       BaSpr1(0),       ChkBrdR1             },

These days, i'm trusting VICE more on these matters than the VIC article.

But ultimately, real hardware is the authority there. =)
(Now, if i only had a 65-cycle machine and not just the 64-cycle old NTSC one and plenty of Euro-PAL machines...)

2019-11-15 13:28

Rastah Bar
Account closed

Registered: Oct 2012
Posts: 336

Interesting. Does this mean that 7 sprites over FLI is not possible on NTSC?

2019-11-15 13:34

Krill

Registered: Apr 2002
Posts: 2969

If anything, i'd expect NTSC to allow for more sprites over FLI than PAL, not fewer. :)

2019-11-15 14:58

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: Quoting Rastah Bar
According to http://unusedino.de/ec64/technical/aay/c64/victnl.htm both extra cycles are just before the sprit 0 fetch.
This assertion appears to stem from Christian Bauer's venerated VIC article, which claims the same.

However, according to VICE sourcecode found in https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/sr.. we see

PAL: 3 cycles between sprite 7 fetch and UpdateVC
{ Phi1(10), 0x1dc, None, SprDma1(7), BaSpr1(7), None }, { Phi2(10), 0x1e0, None, SprDma2(7), BaSpr1(7), None }, { Phi1(11), 0x1e4, None, Refresh, None, None }, { Phi2(11), 0x1e8, None, None, None, None }, { Phi1(12), 0x1ec, None, Refresh, BaFetch, None }, { Phi2(12), 0x1f0, None, None, BaFetch, None }, { Phi1(13), 0x1f4, None, Refresh, BaFetch, None }, { Phi2(13), 0x000, None, None, BaFetch, None }, { Phi1(14), 0x004, None, Refresh, BaFetch, None }, { Phi2(14), 0x008, None, None, BaFetch, UpdateVc },
NTSC: 4 cycles between sprite 7 fetch and UpdateVC
{ Phi1(9), 0x1dc, None, SprDma1(7), BaSpr1(7), None }, { Phi2(9), 0x1e0, None, SprDma2(7), BaSpr1(7), None }, { Phi1(10), 0x1e4, None, Idle, None, None }, { Phi2(10), 0x1e8, None, None, None, None }, { Phi1(11), 0x1ec, None, Refresh, None, None }, { Phi2(11), 0x1f0, None, None, None, None }, { Phi1(12), 0x1f4, None, Refresh, BaFetch, None }, { Phi2(12), 0x1f8, None, None, BaFetch, None }, { Phi1(13), 0x1fc, None, Refresh, BaFetch, None }, { Phi2(13), 0x000, None, None, BaFetch, None }, { Phi1(14), 0x004, None, Refresh, BaFetch, None }, { Phi2(14), 0x008, None, None, BaFetch, UpdateVc },
and

PAL: No extra cycle before sprite 0 fetch
{ Phi1(54), 0x144, Vis(37), FetchG, BaFetch, None }, { Phi2(54), 0x148, Vis(38), FetchC, BaFetch, None }, { Phi1(55), 0x14c, Vis(38), FetchG, BaSpr1(0), ChkSprDma }, { Phi2(55), 0x150, Vis(39), None, BaSpr1(0), None }, { Phi1(56), 0x154, Vis(39), Idle, BaSpr1(0), ChkSprDma }, { Phi2(56), 0x158, None, None, BaSpr1(0), ChkBrdR0 | ChkSprExp },
NTSC: One extra cycle before sprite 0 fetch
{ Phi1(54), 0x144, Vis(37), FetchG, BaFetch, None }, { Phi2(54), 0x148, Vis(38), FetchC, BaFetch, None }, { Phi1(55), 0x14c, Vis(38), FetchG, None, None }, { Phi2(55), 0x150, Vis(39), None, None, None }, { Phi1(56), 0x154, Vis(39), Idle, BaSpr1(0), ChkSprDma }, { Phi2(56), 0x158, None, None, BaSpr1(0), ChkBrdR0 | ChkSprExp }, { Phi1(57), 0x15c, None, Idle, BaSpr1(0), ChkSprDma }, { Phi2(57), 0x160, None, None, BaSpr1(0), ChkBrdR1 },
These days, i'm trusting VICE more on these matters than the VIC article.

But ultimately, real hardware is the authority there. =)
(Now, if i only had a 65-cycle machine and not just the 64-cycle old NTSC one and plenty of Euro-PAL machines...)

At least we have (almost) 1:1 pixel aspect ratio :P NTSC is gross... 60FPS is nice though, especially on any emulator, 50FPS on a 60Hz monitor sucks ass :/

2019-11-15 15:24

Krill

Registered: Apr 2002
Posts: 2969

PAL N then, best of all worlds! (Except 60 Hz.) =)

2020-11-05 23:25

Copyfault

Registered: Dec 2001
Posts: 475

Quoting Rastah Bar

Interesting. Does this mean that 7 sprites over FLI is not possible on NTSC?

I pretty much think so! At least it will not be possible with Ninja's routine in its current form.

We are in C64-world, so using the phrase "impossible" is dangerous, but I deeply dought that it can be done with the other additional NTSC-cycle sitting at cycle-position 10, right after the sprite-fetches.

2020-11-07 03:00

Zibri
Account closed

Registered: May 2020
Posts: 304

Quoting Copyfault