[CSDb] - User Forums - Sine sprites in the sideborder. VSP garbage and more

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Sine sprites in the sideborder. VSP garbage and more

2018-01-22 11:35

Golara
Account closed

Registered: Jan 2018
Posts: 212

Sine sprites in the sideborder. VSP garbage and more

Hello everyone. I'm working on my first C64 demo / intro. I managed to open the sideborder at the top and obviously I immediately put some X-sinus sprites there (I'm still trying to figure out how a DYSP works, right know i have opened lines with 0 and 8 sprites). I noticed that the positioning of the sprites on the X axis is a bit weird. Position 0 is slighty on the left border, but if you want to go all the way to the left you have to use X 500 or there about. My question is, is there some sinus maker or converter that would take care of this ? (so it goes from 0 to ~500 looking like smooth movement to the left). Another question, what is the good way of handling the 9th bit of X position ? What I do is generate a 256 words sinus with values 0 to 500 and use c++ program to split that into 2 256 bytes tables like

sin_1:
1,2,3,4,5,6,7,55,33,....
sin_2:
1,0,0,0,0,1,0,0,1.... where 1 means to set the bit and 0 to not do that.
My sprite 0 is bugging out in the right most border while other sprites display just fine. Why is that ? I've read somewhere that sprite 0 is evil, but could not find any details on why.

I also do VSP by turning on the screen at the right moment together with XSCROLL for smooth scrolling. I see few pixel lines of garbage just above the image, I cover that with the illegal screen mode, disable it at line 56. Is that a good idea ? Another thing about VSP is that it seems to move the whole screen down by one char on the scrolled side (makes sence I guess, as the part of the chars that are outside of the image are displayed on the next text line). So should I copy the 25 lines of graphics in each column when scrolling for seamless scroll or do people not do that ?

Here's a picture of what it looks right know. A big mess !
(PETSCII picture by Archmage as a placeholder. I can't find any pics in binary and that was the easiest to take out of a compiled prg) Hope you have the patience to help a lamer out.
https://i.imgur.com/byWFRsH.jpg[/url]

HughJass from Poland

2018-01-22 12:17

Oswald

Registered: Apr 2002
Posts: 5017

"is there some sinus maker or converter that would take care of this ? "

no. you have to write your own.

"what is the good way of handling the 9th bit of X position ?"

handle sprite x pos as a 16bit number.

"My sprite 0 is bugging out in the right most border while other sprites display just fine. Why is that ?"

iirc because sprite gfx is being read exactly at that pos where you display it.

"I cover that with the illegal screen mode, disable it at line 56. Is that a good idea ? "

yes

"So should I copy the 25 lines of graphics in each column when scrolling for seamless scroll or do people not do that ?"

yes

2018-01-22 12:30

Golara
Account closed

Registered: Jan 2018
Posts: 212

But if I just use 16bit numbers I also need a 16 bit counter or ? Cuz right know I have just one counter and i use it to read from two tables

ldx sin_counter
lda sin_1, x
sta $d000
lda sin_2, x
beq skip_9th_bit
lda $d01d
ora #$01
sta $d01d
skip_9th_bit:
inc sin_counter
....

2018-01-22 12:52

Trash

Registered: Jan 2002
Posts: 122

X-positions in sideborder work like this:
position 0 is right of the the left-most position, between 0 and -248 (the position just one pixel to the left of 0) there is a gap of 8 pixels that essentially just hides your sprite.

I usually for simplicity use two sin-curves and a look up table for calculating sprites x-position.

According to how a DYSP work, they can work in any number of ways, I recommend using the easiest variant to start with: load the value 63 in dc04 and start a clock at the right moment, use $dc04 to know how many cycles you need to waste...

2018-01-22 13:02

Golara
Account closed

Registered: Jan 2018
Posts: 212

What you see in the first post is result of about 40 hours of coding, I didn't try anything with CIA yet. I was reading about cycle tables and how to calculate that... I'm trying to understand that first.

Well I have another question now. Right know I open about 10 lines of 0 sprites and then 21 with 8 sprites (with 7 sprites the timing is the same, but at least i don't have that bug). I'm just using macros like this (for ACME)

!macro MSideBorder8sprites{
	dec sideborder_color_counter
	sta $d021
	nop
	nop
	nop
	ldx sideborder_color_counter
	lda colors, x
	
	nop
	nop
	nop
	nop
	nop
	dec $d016
	inc $d016
}

!macro MSideBorder0sprites{
	sta $d021
	ldx sideborder_color_counter
	lda colors, x
	inc sideborder_color_counter
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	
	nop
	nop
	bit $88
	nop
	nop
	nop
	dec $d016
	inc $d016
}

and call it like that

_stable:
	lda #$c8
	sta $d016
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	bit $ea
	nop
	;inc $d021
	nop
	nop
	nop
	dec $d016
	inc $d016
	+MSideBorder0sprites
	+MSideBorder0sprites
	+MSideBorder0sprites
	+MSideBorder0sprites
	+MSideBorder0sprites
	+MSideBorder0sprites
	+MSideBorder0sprites
	+MSideBorder0sprites
	+MSideBorder0sprites
	+MSideBorder0sprites
	+MSideBorder0sprites
	+MSideBorder0sprites
	+MSideBorder0sprites
	
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	+MSideBorder8sprites
	lda #$00
	sta $d021
	dec sideborder_color_counter
	dec sideborder_color_counter
	dec sideborder_color_counter
	dec sideborder_color_counter

As you can see I also do some scrolling rasterbars. For the lines with 0 sprites it looks great, the color changes way back to the left (you can barely see it with debug borders in VICE) but on the lines with 8 sprites it changes somewhere in the middle of the screen, so I have this 1 pixel high split... Is there a way to fix it or should i just go for a full blown raster split.

2018-01-22 13:34

Mixer

Registered: Apr 2008
Posts: 422

Try changing the border color between dec $d016 and inc $d016.

You have between cycles 56 and 17 next line to do the border opening and other stuff. The sprite data fetching happens during those cycles too and take away many of those cycles from cpu, so not all timings are possible.

2018-01-22 13:34

Mr. SID

Registered: Jan 2003
Posts: 421

Quote: But if I just use 16bit numbers I also need a 16 bit counter or ? Cuz right know I have just one counter and i use it to read from two tables

ldx sin_counter
lda sin_1, x
sta $d000
lda sin_2, x
beq skip_9th_bit
lda $d01d
ora #$01
sta $d01d
skip_9th_bit:
inc sin_counter
....

I think you want $d010 instead of $d01d.

2018-01-22 13:39

Oswald

Registered: Apr 2002
Posts: 5017

the way it works its that the video chip stops the cpu to read sprite gfx data, with all 8 sprites on the cpu is stopped on the sideborder completely, you can only change color mid screen.

google for "vic article c64" for details.

sprite x pos, for just demo usage your table approach is fine. also you are mixing things up, 16 bit numbers can be stored in tables that have only 255 entries, you dont need 16 bit table pointer automatically.

2018-01-22 14:15

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: the way it works its that the video chip stops the cpu to read sprite gfx data, with all 8 sprites on the cpu is stopped on the sideborder completely, you can only change color mid screen.

google for "vic article c64" for details.

sprite x pos, for just demo usage your table approach is fine. also you are mixing things up, 16 bit numbers can be stored in tables that have only 255 entries, you dont need 16 bit table pointer automatically.

Yes you're right, I was just typing from memory and got the wrong HW register address.

I thought about 16bit counter because then you have to read every second byte, but just now i realised that i could still only increment the index by 1 and do a left shift to multiply the number by 2 to read the next byte. Well now I'll just have to figure out these left side border positions so I can convert my sinuses.

Mixer: Why would I change the border color if the border is open on that line ? Did you mean the background color ? I did that and it did help, the color change is more to the right, but still visible. I kinda figured out the sprite fetching is happening at the right border and continues to the next line, I guess I'll have to do a raster split then for it to look good.

https://i.imgur.com/Ji9ju5s.jpg[/url]

2018-01-22 15:44

Mixer

Registered: Apr 2008
Posts: 422

Yes, background color. My bad.

2018-01-23 11:05

Golara
Account closed

Registered: Jan 2018
Posts: 212

I always wondered how people find these VIC tricks, they seem very specific and hard to come by by accident, but I think I just accidentaly started stretching my sprites.... At line 250 I disable the bottom border, set the sprite position to 255 and calculate their X from the sinus, call the music (which takes a bunch of lines) and then set the sprites Y to 10 for the top border. That worked fine, but I thought I'll make the sprites at the bottom expanded in Y on the bottom and normal on the top. I disable Y expansion after the music and because the ammount of raster the music takes is kinda random i started stretching sprites on my bottom border lol.

That made me want to do a proper sprite stretching, I'm just thinking how to go about it... This is what I came up with, tell me if it's a good approach.

I'd need let's say 40 lines of stable raster, on each line i'd read from a 40 elements table in which i decide if I should do the stretching or not. Now I'm thinking how to fill up such a table... Let's say a sinus with values from 0 to 3, whatever the number I read i put as many 1s into the table.... HMMM

Btw. How far can i put a sprite on the lower border before it starts to appear on the top ? It seems like there's some position on which I see the sprite both on top and bottom border, really weird !

2018-01-23 12:38

Mixer

Registered: Apr 2008
Posts: 422

Answer to all of your current and future VIC questions :) VIC Article [english]

2018-01-23 15:41

TWW

Registered: Jul 2009
Posts: 541

I used this to generate the horizontal sine-values:


    .var sinus = 0

SinusXLo:
    .for (var i = 0 ; i < 256 ; i++) {
        .eval sinus = RadiusX - 7 + RadiusX*sin(toRadians(i*360/256))
        .if (sinus < 0) .eval sinus = sinus - 9
        .byte sinus
    }

SinusXHi:
    .for (var i = 0 ; i < 256 ; i++) {
        .eval sinus = RadiusX - 7 + RadiusX*sin(toRadians(i*360/256))
        .if (sinus < 0) .eval sinus = 256
        .byte >sinus
    }

2018-01-23 16:04

JackAsser

Registered: Jun 2002
Posts: 1989

This is all there is to it. When you really understand this chart it will explain almost everything: https://www.linusakesson.net/programming/vic-timing/victiming.p..

2018-01-23 20:13

Oswald

Registered: Apr 2002
Posts: 5017

sprite stretching is very easy, just turn on/off y stretch bit on each line. horizontal timing is doesnt matter except the 1 cycle where it results in another trick called sprite crunch.

2018-01-24 10:32

Golara
Account closed

Registered: Jan 2018
Posts: 212

Aha, that's really great. I must have missunderstand the article on sprite stretching, I thought it was cycle accurate and sprite crunching is the same trick but in a different cycle. I made a simple loop of various lenghts like this:

	ldx .xPosCounter
	lda sprite_stretch, x
	adc #10
	tay
	lda #$ff
l1:	
	inc $d021
	sta $d017
	eor #$ff
	sta $d017
	dec $d021
	dey
	bne l1

And it seems like I do a sprite crunch at some frames, can you confirt that it is in fact sprite crunch ? My sprites appear twice.

I also decided to do a logo instead of DYSP for now, it's made out of 6 sprites. I swing it from 0 to 255 and set the 9th bit at the correct position, or so I think... It blinks sometimes, do you see anything I do wrong ?

	lda #$00
	sta $d020
	sta $d021
	sta $d010 ; 9th X bit
	
	ldx .xPosCounter
	lda sprite_border_sin_1, x
	cmp #230
	bcc skip5
	tay
	lda #%01111100
	sta $d010
	tya
skip5:
	cmp #230-24
	bcc skip4
	tay
	lda #%00111100
	sta $d010
	tya
	jmp skip1
skip4:
	cmp #230-24-24
	bcc skip3
	tay
	lda #%00011100
	sta $d010
	tya
	jmp skip1
skip3:
	cmp #230-24-24-24
	bcc skip2
	tay
	lda #%00001100
	sta $d010
	tya
	jmp skip1
skip2:
	cmp #230-24-24-24
	bcc skip1
	tay
	lda #%00000100
	sta $d010
	tya
skip1:
	clc
	sta $d00e
	adc #24
	sta $d00c
	adc #24
	sta $d00a
	adc #24
	sta $d008
	adc #24
	sta $d006
	adc #24
	sta $d004

I'll try to make it the last question.

2018-01-24 14:20

Oswald

Registered: Apr 2002
Posts: 5017

just keep asking :)

1. for proper sprite stretch u have to make sure on/off exactly per line, thats why it doesnt always stretch

2. might be not proper d010 setting and sprite teleporting under border or writing X in a magical cycle when sprite is being displayed iirc then sprite disappears. you should handle 9th bit per sprite and ora into d010, something is probably bugged in there

2018-01-24 15:14

Golara
Account closed

Registered: Jan 2018
Posts: 212

I'm setting the X and $d01d registers at line 251 and set sprites Y at 255, so there's no way I'm writing X register while displaying the sprite. I've made this ff->d017 00->d017 loop just to see if the stretching works, I assumed it would just randomly spaz out (which it did) but I also get sprites drawn twice which is the effect of sprite crunching from what I've read. (because the internal byte counter gets incremented by 1 instead of 3 once and so the counter doesn't reach 63 and the sprite gets drawn again).

Btw, does sprite stretching steal more cycles ? That is, on each line where a sprite is drawn, even when using the stretching bug, it still takes away the cycles ? Does that mean I have to trigger the stretching bug before the sprite DMA or after ? or it doesn't matter ?

2018-01-24 16:26

Oswald

Registered: Apr 2002
Posts: 5017

ah, yes you are right. then I guess it must be buggy d010 usage.

yep, if you do stretching sprites steals same amount of cycles as if displayed normally.

2018-01-25 14:35

Golara
Account closed

Registered: Jan 2018
Posts: 212

Damn, I didn't realise you can change the X register while displaying a sprite, I thought it was locked like Y. Makes it very easy to do a sprite TECH-TECH, dude nice.

6 sprites on the line, I change the first 4 sprites's X on one line and the other two on the other while opening the borders. It was rather easy, but I can't figure out how to make it go all the way to the right border, damn, this 9th bit makes it tricky and the fact that 0 position is not the top most left position makes it even harder.

2018-01-25 16:13

Golara
Account closed

Registered: Jan 2018
Posts: 212

Stretching side border tech tech, am I pro or what ? :v

That reminds me a bit of the super stretching in the DEMODE, is it the same thing, just, you know, much better ? (d017 stretches and changing X for tech-tech)

2018-01-25 17:48

ChristopherJam

Registered: Aug 2004
Posts: 1378

Huh. So I know the gap in X position comes from there being 63 cycles per line, hence 63*8=504 possible sprite start locations, but this thread got me wondering about NTSC.

I was worried that our friends across the pond might not be able to smoothly scroll an x-expanded sprite off the screen, as there are 8 positions for which no register value exists (65*8=520 locations, and you only get 512 from MSB+xpositionregister).

Going by a quick test in VICE however, it seems that position 511 is one pixel to the left of position 0, and position 0x1e9 covers all but the rightmost pixel of an x-expanded sprite. All is good, and those slackers across the ocean can just use 16 bit positions without any fuss.

I'm assuming vic artikel covers where the gap is, I'm just amused that it's not where I was concerned it might have been.

2018-01-25 17:50

ChristopherJam

Registered: Aug 2004
Posts: 1378

Gnarly tech tech, HughJass!

2018-01-25 18:01

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: Gnarly tech tech, HughJass!

If you're talking about gaps in my sprites it's in the sprite definition, I drew them for multicolor but didn't switch to multicolor and I thought they looked kinda neat. I only spend about an hour each week day (when tired of coding enterprise(tm) c++ code), but I'll spend some more time on the weekend. I decided to start from scratch, because first I started with vsp and then multiplexer and opening borders, interrupts all over and no usefully code between them. Now I do a stable raster at line 250, disable bottom border and open the sides for bottom and top. Filling the nops with what I can (like this stretcher) and then I'll do smooth vsp again at line $30 and something cool in the middle again.... I like these old-school demos like raster blast or the demos from Upfront with lots of sprites and nice rasters etc. The part in Insomnia with tech tech image and dysp over it is super cool. I've been following the c64 and Amiga demoscene since 2013 or so, I never owned either computer (born in the 90s) but now I own both and finally started coding some shit on c64 last week.

2018-01-25 18:55

ChristopherJam

Registered: Aug 2004
Posts: 1378

Haha sorry, talking Australian. Gnarly = so good that it attracts the viewers attention and earns their respect.

Yes, the gaps are cool!

2018-01-25 19:01

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: Haha sorry, talking Australian. Gnarly = so good that it attracts the viewers attention and earns their respect.

Yes, the gaps are cool!

This was my first go at drawing sprites (by typing bytes myself before finding a sprite editor, doh) I'll try to make a better logo, but I'm so inept in any form of arts haha. I'd like to make it as wide as the screen, but I don't think I'll have enough raster time to toy with 9th bit. Although definitely there's a way because people did full screen stretching scrollers with lots of colors so... I'm just missing out on something

2018-01-25 19:31

Mixer

Registered: Apr 2008
Posts: 422

Good work if just one week of c-64 coding!

2018-01-25 19:41

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: Good work if just one week of c-64 coding!

thanks, but for the record, I've read lots of stuff on the c64, I knew most of the Vic tricks already how they work in theory, but it's always super exciting when it actually works. And I know x86 assembly, so jumping to 6502 wasn't that much harder. My colleagues at work are all high level c++ python etc, they don't care or get why I like the c64 so much lel.

EDIT. Progress on the wobbly sprite logo. I think it looks very nice, still no 9th bit manipulation, 4 sprites are always on the left and 2 on the right, but it already looks much better. I have 2 sin tables for the tech-tech, I replace them with self modyfing code, incrementing the high byte of the lda $xxxx, x instruction.

EDIT2. For some reason I thought ZP indirect reading from table would be much slower, but actually is only 1 cycle more than normal indexed read, so now I just change the pointer to the table. I also figured that if I wanted to smoothly move this logo (or even a scroller) I'd need to compute a table of X cords and $d010 vales for each sprite and each line (6 sprites, 42 lines) hmmmm

2018-01-27 01:07

Golara
Account closed

Registered: Jan 2018
Posts: 212

I mamanged to squize in the d010 writes so now I have the logo swinging in both borders (although the first sprite never goes further to the left than 0). But now I have some bugs, I think it's these late d010 and X write, that wasn't visible when the logo didn't occupy that much screen. Damn man.

2018-01-27 07:50

Oswald

Registered: Apr 2002
Posts: 5017

nice progress, you got this :)

2018-01-27 13:10

Digger

Registered: Mar 2005
Posts: 421

Hujas? The bug looks like you are off with $d010 table.

2018-01-27 13:17

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: Hujas? The bug looks like you are off with $d010 table.

yeah it seems like it, but if I use a sinus with smaller steps there's no bug, even on the same position. Code is the same I only change the table... Oh well, I'll figure it out eventually, I'll start on some other effect. Btw. What would I have to do to consider it a crack intro ? does it have to relocatable or ?

EDIT. Hugh Jass is pronouced like Huge Ass, that's the epic joke.

EDIT2. I just fixed it, no more bugs :D
EDIT3. I've tried to expand this tech-tech into the left border, but because of this 8 pixels gap I find it impossible (no cycles left to check and do adc #8) Unless I reduce the number of sprites (6 right now.) I guess i'll leave it as is right now.

2018-01-27 23:36

Golara
Account closed

Registered: Jan 2018
Posts: 212

Alright, I'll try to make it the last picture, I want to suprice you all ;) Last couple of questions

1. Where can I find some sprite fonts ? I remember I had one from csdb (I didn't use it for C64 though) and I can not find it.... I've found lots of char fonts, but not sprite ones.

2. How to chose good colors for flashing, color bars etc. I have the worst case of coder colors, is there any guide on that ?

3. Where can I get some C64 pictures (chars or bitmap) ? Obviously there's a great selection on csdb but these are all compiled prgs. Do I have no choise but to just disassemble them ? (I did that with one petscii picture, but that was easy...)

4. About credit... Is it fine for me to use random graphics or sid or should I ask the author ? I don't intend on sending this to any compo, just to release it on csdb. Of course the credits will be in the demo

5. Greetings. As someone new who has no contacts with anyone is it fine for me to greet all the damn elite of C64 ? haha. I find it kinda silly, but I'd like to mention the groups I like, I don't know how that works....

I'm not embeding the gif cuz it's almost 10mb, so to not slow down the loading of this page, click the link bellow

(these colors, that font, it hurts!)
https://i.imgur.com/zjvrQbw.png[/url]

2018-01-28 00:27

Mixer

Registered: Apr 2008
Posts: 422

Nowadays it is simple to convert any font or other graphics from PC using Python scripts or converter applications. Ask around, perhaps some artist will do some pixeling.

2018-01-28 10:52

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: Nowadays it is simple to convert any font or other graphics from PC using Python scripts or converter applications. Ask around, perhaps some artist will do some pixeling.

Oh damn, why did I not think of that... Yeah, I just converted a PC font, looks very nice.

2018-01-28 11:47

Oswald

Registered: Apr 2002
Posts: 5017

btw how do you create these nice gifs?

2018-01-28 12:01

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: btw how do you create these nice gifs?

It's this program. https://github.com/NickeManarin/ScreenToGif/releases/download/2..

Works like a normal screen recording software, but saves the video as gif or other animated formats. I actually posted .apng here because their size is much smaller than the old .gif

After recording you can view all the frames, so the last few animations i posted i actually took care to remove the excess frames to make it wrap seamless. It has a nice editor for that. It's a great program and it's less than 1MB

2018-01-28 13:44

Golara
Account closed

Registered: Jan 2018
Posts: 212

2018-01-28 18:40

Golara
Account closed

Registered: Jan 2018
Posts: 212

What do you guys think ?
https://i.imgur.com/NQ8Bkgk.mp4[/url]
I still have about 180 lines of raster time (with bad lines) free, so i'll put something nice on the screen yet. The graphic will be replaced with some nice bitmap, since it's VSP movement, overkill for just PETSCII. I also decided to do some design, not just an intro, so this is a screen you'll see after some time, it has to build up somehow... I have couple of ideas already.

2018-01-28 18:53

Oswald

Registered: Apr 2002
Posts: 5017

nice stuff, I'd double/triple the sine frequency to make it look more pleasing, and a nice multicolor logo wouldnt hurt either :)

2018-01-28 19:05

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: nice stuff, I'd double/triple the sine frequency to make it look more pleasing, and a nice multicolor logo wouldnt hurt either :)

Yep, definitely a multi color logo would look better, but it's harder to get one, this is just some PC font converted to sprites.. Right now I have 4 sinus tables, but maybe i'll add more, we'll see how good i'm on memory. Right know i'm almost at 16kb

2018-01-28 19:58

Oswald

Registered: Apr 2002
Posts: 5017

doublesin would be even better ( add up some sines)

2018-01-29 18:39

Digger

Registered: Mar 2005
Posts: 421

how many sprites are you squeezing into the bottom border? 6? :)

2018-01-29 21:33

Compyx

Registered: Jan 2005
Posts: 631

I'd say no more than five. $d017 stretch takes at least 8* cycles and opening the border takes at least another 8*. That leaves 47 cycles of which quite a few are consumed by the VICII. So to move 5 sprites we need 5 x LDA#/STA$ (6 cycles), another 30 cycles:

8+8+30 == 46 which according to victimer might work.

* = this assumes having registers preset (for example X=0 and Y=8) for quick $d016/$d017 writes, and unrolled code.

I could very well be wrong though. Haven't done any sprite tech-tech stuff for a long while.

2018-01-30 06:41

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: I'd say no more than five. $d017 stretch takes at least 8* cycles and opening the border takes at least another 8*. That leaves 47 cycles of which quite a few are consumed by the VICII. So to move 5 sprites we need 5 x LDA#/STA$ (6 cycles), another 30 cycles:

8+8+30 == 46 which according to victimer might work.

* = this assumes having registers preset (for example X=0 and Y=8) for quick $d016/$d017 writes, and unrolled code.

I could very well be wrong though. Haven't done any sprite tech-tech stuff for a long while.

I'm doing 6 sprites. I have 4 cycles left too (after opening the second line of border). I don't update all the sprite registers on the same line, but it works fine as you can see, although I had to fiddle around with the order of instructions until I got rid of the bugs. The SS is not supposed to flash, I just don't update the colors for it yet, althought I have plenty of time for that, I just forgot. In this screen you see couple of posts above I have free raster time from about line 56 to line 250, so I can do some other cool stuff too. I don't know what to do next right know though. I'm also thinking if I should make it a tiny demo in this intro like format (where only the middle of the screen changes with some new pictures or some other effect), or to do a multi prg press-space-to-continue kind of demo. I definitely don't know how to do stuff like one-der or dawnfall in onefile yet.

2018-01-30 13:38

Golara
Account closed

Registered: Jan 2018
Posts: 212

Can you do VSP and FLD at the same time ? Both effects work for me individually, but I can't do both at the same time. I have a big square on the left going left and right. Am I accidentally doing FLI or something ? Can't be, as i'm doing the FLD the slow but sure way of reading the current line and setting Yscroll to something different.

same code moves the whole screen without vsp. I do vsp at line 47 and fld at 56

EDIT. I've fixed that, the code for enabling illegal screen mode to cover VSP garbage was causing the problem.

2018-01-30 18:12

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: Can you do VSP and FLD at the same time ? Both effects work for me individually, but I can't do both at the same time. I have a big square on the left going left and right. Am I accidentally doing FLI or something ? Can't be, as i'm doing the FLD the slow but sure way of reading the current line and setting Yscroll to something different.

same code moves the whole screen without vsp. I do vsp at line 47 and fld at 56

EDIT. I've fixed that, the code for enabling illegal screen mode to cover VSP garbage was causing the problem.

Ok I got the vsp+fld working reasonably well (although very slow, it's all lousy test code now) and I blank the bytes that go beyond the screen to make it look like it doesn't wrap and that gave me an idea to try to make the image scroll into the border on both sides... Although I don't see it being possible with the logo and music taking away all my top and bottom raster time. SO. I'll try to make that effect in the other part and for this i'll come up with something else, but still kooool

2018-01-31 15:24

Oswald

Registered: Apr 2002
Posts: 5017

looks like d011 write is horizontally on wrong cycle and you have accidental fli (lt red checkers)

2018-01-31 21:05

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: looks like d011 write is horizontally on wrong cycle and you have accidental fli (lt red checkers)

Yeah man. I sorted it out and it works fine. A different question... and sorry for just throwing it into this single thread but I don't know if making several threads would be better. And this is mostly because durrinf the weekday I'm like 2 hours a day at home and I'm just constantly thinking about trying something out but I have no time lol.

About line crunch. I understand it's about "undoing" a bad line which forces Vic to draw another text line right away and because of that the screen is shorter and it will wrap around putting that line at the bottom. Cause that 25 times and you scroller the entire screen. There's 25 lines of these 1st pixel lines of each row, so it's usually covered with the illegal screen mode (rocketry has a full screen but that's out of question for me)

I'm just thinking... if you always cover the 25 pixel lines with black pixels but crunch only let's say 5 lines, some of the scrolled image will be covered too, right ? and the sprite pointers will be drawn as chars too ? How do people work around it ? or is that normal and you can't do anything about it ?

Is there a way to load a file before address $0801? Or do I have to copy my stuff to the lower memory if I want to use it ?

I noticed that the background colour under the side borders of while displaying bitmap is different on every line (the colour of the most right pixel ?) Is there a way to change that other than making the picture have the desired colour as the last pixel on the line (if it even comes from the bitmap colour)

2018-01-31 21:47

Oswald

Registered: Apr 2002
Posts: 5017

I'm not the best person to answere these, but here are my educated guesses:

linecrunch: use fld to keep the area 25 lines high. never used linecrunch to scroll picture, so take this with a grain of salt..

load before $0801: the kernal (built in) load routine doesnt stop you from loading anywhere, however sideffects of sta to various locations might, also if you load to screen mem, the basic ready prompt printing after load will ruin your day :) similar applies to custom load routines. you can load anywhere, but nothing saves you from the possible bad side effects of overwriting memory :)

"I noticed that the background colour under the side borders of while displaying bitmap is different on every line "

this might be the hires bitmap thing I only heard of, one of the colors of the 2 possible per char of the rightmost char will be used as "sideborder" color if you remove the sideborder.

2018-01-31 22:34

Golara
Account closed

Registered: Jan 2018
Posts: 212

Yeah I know you're the speedcode and math kind of guy, but you still know way more about the Vic than me at this point... FLD. I didn't think about it, although I don't think it would solve the problem, because say you do one line crunch. That would make the lines 2-25 on top and line 1 on the bottom, but if I do 18 lines of fld to show the second line as the first visible (at pixel line 25) the bottom line will go beyond the screen... Hmm But I'm just guessing I'll try to allocate some time tomorrow to check it. With char based pictures it wouldn't be such a big problem perhaps because you can copy the graphics around, but bitmap is too big. Unless maybe I split copying over say 4 frames and scroll by 2 pixels per frame max, but that's not cool it has to go all over haha

2018-02-03 21:25

Golara
Account closed

Registered: Jan 2018
Posts: 212

Darn, I didn't want to post here anymore till I realease the demo, but I came across a problem I can't solve, and it can't be too hard, I'm just missing something.... Can someone explain this garbage in FLD area ?

https://i.imgur.com/Y1VQX6D.mp4
I'm doing FLD on am unstable raster (by 0-3 cycles) but that shouldn't be a problem, eh? This is the same interrupt that changes from bitmap to char mode.

irq_line_209:
	pha
	txa
	pha
	tya
	pha
	!for inner, 0, 10{
	nop
	}
	lda #$65
	sta $d018
	lda #$1b
	sta $d011
	ldy fld_counter
	ldx fld_sin, y
-:	
	lda $d012
	cmp $d012
	beq *-3
	clc
	lda $d012
	adc #1
	and #7
	ora #$18
	sta $d011
	dex
	bne -
	inc flc_counter
	lda scroller_d016_counter
	sta $d016
	dec scroller_d016_counter
	bne +
	lda #7
	sta scroller_d016_counter
+:

Thanks for your help guys!

2018-02-04 04:16

ChristopherJam

Registered: Aug 2004
Posts: 1378

Easiest way to hide the garbage is to just blank the area by setting an illegal mode such as ECM+bitmap, ie just ORA#$78 instead of #$18 in your FLD loop.

Then regardless of what your d018 value and last row of characters read, VIC-II will just display black pixels.

But as to where it's coming from in the first place.. maybe ADC 2 or 3 instead of just 1? You're currently repeatedly saying "do a badline on the next raster" then waiting for the beginning of the next raster to start working out the value to use to avoid the DMA you've just queued. It's due only a few cycles into the line you've waited for; suspect you're doing a badline on most lines at the moment rather than a traditional "gap between the char rows" FLD per se.

2018-02-04 07:28

Oswald

Registered: Apr 2002
Posts: 5017

yeah at fld badlines happen naturally when you stop the scrolling, no need to force em.

2018-02-04 10:39

Golara
Account closed

Registered: Jan 2018
Posts: 212

Am I doing FPP effect here ? This is still the bugged FLD. If I had 8 copies of this charset with each starting a line below and if I'd swap between them on each line... or am I thinking about something else.

https://i.imgur.com/9c7fRBC.png

Anyway, I've fixed my FLD. The problem was that I wanted to do too much on the same line... change from bitmap to text, scroll it, calculate the d011... I rearanged some of the code and now it works fine. But I'm still curious about the effect in the picture above.

2018-02-04 20:41

Oswald

Registered: Apr 2002
Posts: 5017

almost fpp... it is possible to repeat a char line like that, any nr of rows, you can repeat every 1st 4 row, every 1st 6 row, and every 1st 1 row is fpp... it doesnt even need cycle exact timing just a so-so.

2018-02-04 22:34

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: almost fpp... it is possible to repeat a char line like that, any nr of rows, you can repeat every 1st 4 row, every 1st 6 row, and every 1st 1 row is fpp... it doesnt even need cycle exact timing just a so-so.

Alright, I'll try some FPP in the next part. Your chessboard in Soiled Legacy is done using FPP, right ?

2018-02-05 09:12

Oswald

Registered: Apr 2002
Posts: 5017

yep :)

2018-02-05 17:42

Golara
Account closed

Registered: Jan 2018
Posts: 212

I have a very strange thing going on... I'm trying to code an intro for the part where the sprite logos scroll from the left side of the screen one after another. This is done with 4 interrupts, on line 50, 100, 150, 200 with this code

intro_logo_1_x !byte 0
intro_logo_2_x !byte 0
intro_logo_3_x !byte 0
intro_logo_4_x !byte 0
intro_fld_counter !byte $ff

logo1_d010:
!byte 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!byte 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!byte 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!byte 0,0,0,0,0,0,0,0,0,128,128,128,128,128,128,128
logo1_d015:
!byte 128,128,128,128,128,128,128,128,128,128,128,192,192,192,192,192
!byte 192,192,192,192,192,192,224,224,224,224,224,224,224,224,224,224
!byte 240,240,240,240,240,240,240,240,240,240,240,248,248,248,248,248
!byte 248,248,248,248,248,248,252,252,252,252,252,252,252,252,252,252
logo1_d000:
!byte 0,5,9,14,18,23,27,32,36,41,45,50,54,59,63,68
!byte 72,77,81,86,90,95,99,104,108,113,117,122,126,131,135,140
!byte 144,149,153,158,162,167,171,176,180,185,189,194,198,203,207,212
!byte 216,221,225,230,234,239,243,248,252,1,5,10,14,19,23,28


intro_1_irq:
	inc $d020
	pha
	txa
	pha
	lda #01
	!for inner, 0, 5{
		sta $d029+inner
	}
	lda #$fc
	sta $d01d
	sta $d017
	ldx #6
	!for inner, 0, 5{
		stx $4ffa + inner
		inx
	}
	lda #52
	sta $d005
	sta $d007
	sta $d009
	sta $d00b
	sta $d00d
	sta $d00f
	
	ldx intro_logo_1_x
	lda logo1_d010, x
	sta $d010
	lda logo1_d015, x
	sta $d015
	lda logo1_d000, x
	!for inner, 0, 4{
		sta $d00e - (inner*2)
		clc
		sbc #47
	}
	sta $d00e - 10
	cpx #63
	beq +
	;dec intro_fld_counter
	inx
+:	
	stx intro_logo_1_x
	lda #<intro_2_irq
	sta KERNALIRQServiceRoutineLo
	lda #>intro_2_irq
	sta KERNALIRQServiceRoutineHi
	lda #100
	sta VIC2Raster
	
	
	+MACROAckRasterIRQ_A
	pla
	tax
	pla
	dec $d020
	rti

intro_2_irq:
	inc $d020
	pha
	txa
	pha
	lda #02
	!for inner, 0, 5{
		sta $d029+inner
	}
	lda intro_logo_1_x
	cmp #63
	bne +
	lda #$fc
	sta $d01d
	sta $d017
	ldx #0
	!for inner, 0, 5{
		stx $4ffa + inner
		inx
	}
	lda #102
	sta $d005
	sta $d007
	sta $d009
	sta $d00b
	sta $d00d
	sta $d00f
	
	ldx intro_logo_2_x
	lda logo1_d010, x
	sta $d010
	lda logo1_d015, x
	sta $d015
	lda logo1_d000, x
	!for inner, 0, 4{
		sta $d00e - (inner*2)
		clc
		sbc #47
	}
	sta $d00e - 10
	cpx #63
	beq +
	dec intro_fld_counter
	inx
+:	
	stx intro_logo_2_x
	lda #<intro_3_irq
	sta KERNALIRQServiceRoutineLo
	lda #>intro_3_irq
	sta KERNALIRQServiceRoutineHi
	lda #150
	sta VIC2Raster
	
	
	+MACROAckRasterIRQ_A
	pla
	tax
	pla
	dec $d020
	rti
	
intro_3_irq:
	inc $d020
	pha
	txa
	pha
	lda #03
	!for inner, 0, 5{
		sta $d029+inner
	}
	lda intro_logo_2_x
	cmp #63
	bne +
	lda #$fc
	sta $d01d
	sta $d017
	ldx #12
	!for inner, 0, 5{
		stx $4ffa + inner
		inx
	}
	lda #152
	sta $d005
	sta $d007
	sta $d009
	sta $d00b
	sta $d00d
	sta $d00f
	
	ldx intro_logo_3_x
	lda logo1_d010, x
	sta $d010
	lda logo1_d015, x
	sta $d015
	lda logo1_d000, x
	!for inner, 0, 4{
		sta $d00e - (inner*2)
		clc
		sbc #47
	}
	sta $d00e - 10
	cpx #63
	beq +
	dec intro_fld_counter
	inx
+:	
	stx intro_logo_3_x
	lda #<intro_4_irq
	sta KERNALIRQServiceRoutineLo
	lda #>intro_4_irq
	sta KERNALIRQServiceRoutineHi
	lda #200
	sta VIC2Raster
	
	
	+MACROAckRasterIRQ_A
	pla
	tax
	pla
	dec $d020
	rti
	
intro_4_irq:
	inc $d020
	pha
	txa
	pha
	lda #05
	!for inner, 0, 5{
		sta $d029+inner
	}
	lda intro_logo_3_x
	cmp #63
	bne +
	lda #$fc
	sta $d01d
	sta $d017
	ldx #18
	!for inner, 0, 5{
		stx $4ffa + inner
		inx
	}
	lda #202
	sta $d005
	sta $d007
	sta $d009
	sta $d00b
	sta $d00d
	sta $d00f
	
	ldx intro_logo_4_x
	lda logo1_d010, x
	sta $d010
	lda logo1_d015, x
	sta $d015
	lda logo1_d000, x
	!for inner, 0, 4{
		sta $d00e - (inner*2)
		clc
		sbc #47
	}
	sta $d00e - 10
	cpx #63
	beq +
	dec intro_fld_counter
	inx
+:	
	stx intro_logo_4_x
	lda #<intro_1_irq
	sta KERNALIRQServiceRoutineLo
	lda #>intro_1_irq
	sta KERNALIRQServiceRoutineHi
	lda #50
	sta VIC2Raster
	
	
	+MACROAckRasterIRQ_A
	pla
	tax
	pla
	dec $d020
	rti

And now look at what happens... the first logo is flickering, it looks like the d015 writes that happen at lines 100,150,200 have an affect on sprites on line 52... How is that possible ?

Another interesting thing is that the rasters seem to be stable (no flickering on the border colors) even though it's not a stable routine. Sure, the cpu i just executing a busy loop outside of the interrupt, but it should still be able to interrupt between the opcode sometimes (as it always did when I set up a simple raster interrupt)

https://i.imgur.com/jTBQxv8.png

(code like this will be converted to speedcode generator ofcourse later on)

2018-02-05 19:27

Mixer

Registered: Apr 2008
Posts: 422

lda logo1_d015, x
sta $d015

Perhaps that write takes place too late and it is already line 52.

2018-02-05 19:36

Golara
Account closed

Registered: Jan 2018
Posts: 212

Mixer. I've tried putting sprites much lower than 2 lines and the effect is still the same

2018-02-05 19:56

Rastah Bar

Registered: Oct 2012
Posts: 336

Perhaps you get another irq at line 256+50? I don't see an acknowledgement of the interrupt by writing to $d019.

2018-02-05 20:05

Golara
Account closed

Registered: Jan 2018
Posts: 212

+MACROAckRasterIRQ_A
Acknowledges irq
EDIT. Changing the first logo from Y 52 to 53 fixed the flicker ! Damn man, I'm 110% sure I made bigger gaps between and interrupt and sprite position before and that didn't work. I feel stupid

Now I'm just thinking how to neately scroll in the sprites, since they are double wide, they pop up... And how to do full screen FLD and scroll it back up slowly as the logos fly in without doing interrupts every 7 lines (is that even possible ?)

EDIT. And I made it scroll smoothly from behind left border. This computer is the best, the smallest thing is so satisfying once it works.

2018-02-06 10:26

Mixer

Registered: Apr 2008
Posts: 422

There is a nice monitor feature in Vice. Give command "until <address>", and return from monitor, and it runs the code until PC is in that address and then enters the monitor again. It is setting a break point in a dynamic way.

Then give command r, and you can see the line and cycle where the vic is drawing currently. That is an excellent way to trace raster issues.

2018-02-06 11:08

Dano

Registered: Jul 2004
Posts: 226

First of all, really impressive what you're up to already. Kudos for that!

As for more visually debugging c64 code there is also a REALLY nifty and nice tool i actually use every day now and i could not live without:

C64 Debugger V0.64

takes the pain out of going through vice mon. although for pros it might not be as mighty as vice mon is.

2018-02-06 16:40

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: There is a nice monitor feature in Vice. Give command "until <address>", and return from monitor, and it runs the code until PC is in that address and then enters the monitor again. It is setting a break point in a dynamic way.

Then give command r, and you can see the line and cycle where the vic is drawing currently. That is an excellent way to trace raster issues.

I was looking for this r command for a long time, I know vice monitor shows line and cycle when hitting a breakpoint, but doesn't on step. Thanks. With all the tools we have now, instant compilation, nice editors, freezer with no side effects, even showing on which cycle we are, vice with debug border mode.... And it's still pretty hard. I have more and more respect for the guys of the early days more each day I do more coding.

Thanks dano and all others in this thread. I'm surpriced myself that it is going so well, I honestly expected to code some raster bards and 1x1 scroller at best for my first prod, but it all goes rather smoothly for me and in fact I wasn't so invested into something in a long time. This is really fucking cool man.

Refresh

Subscribe to this thread: