| | 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 |
|
| | Oswald
Registered: Apr 2002
Posts: 5094 |
"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 |
| | 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
.... |
| | 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... |
| | 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. |
| | Mixer
Registered: Apr 2008
Posts: 452 |
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. |
| | Mr. SID
Registered: Jan 2003
Posts: 424 |
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. |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
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. |
| | 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] |
| | Mixer
Registered: Apr 2008
Posts: 452 |
Yes, background color. My bad. |
| | 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 ! |
| | Mixer
Registered: Apr 2008
Posts: 452 |
Answer to all of your current and future VIC questions :) VIC Article [english] |
| | TWW
Registered: Jul 2009
Posts: 545 |
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
}
|
| | JackAsser
Registered: Jun 2002
Posts: 2014 |
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.. |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
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. |
| | 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. |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
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 |
| | 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 ? |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
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. |
| | 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.
 |
| | 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) |
| | ChristopherJam
Registered: Aug 2004
Posts: 1409 |
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. |
| | ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Gnarly tech tech, HughJass! |
| | 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. |
| | ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Haha sorry, talking Australian. Gnarly = so good that it attracts the viewers attention and earns their respect.
Yes, the gaps are cool! |
| | 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 |
| | Mixer
Registered: Apr 2008
Posts: 452 |
Good work if just one week of c-64 coding! |
| | 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 |
| | 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.
 |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
nice progress, you got this :) |
| | Digger
Registered: Mar 2005
Posts: 437 |
Hujas? The bug looks like you are off with $d010 table. |
| | 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. |
| | 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] |
| | Mixer
Registered: Apr 2008
Posts: 452 |
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. |
| | 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. |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
btw how do you create these nice gifs? |
| | 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 |
| | Golara
Account closed
Registered: Jan 2018
Posts: 212 |
<IGNORE> |
| | 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. |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
nice stuff, I'd double/triple the sine frequency to make it look more pleasing, and a nice multicolor logo wouldnt hurt either :) |
| | 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 |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
doublesin would be even better ( add up some sines) |
| | Digger
Registered: Mar 2005
Posts: 437 |
how many sprites are you squeezing into the bottom border? 6? :) |
| | 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. |
| | 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. |
| | 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. |
| | 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 |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
looks like d011 write is horizontally on wrong cycle and you have accidental fli (lt red checkers) |
| | 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) |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
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. |
| | 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 |
| | 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! |
| | ChristopherJam
Registered: Aug 2004
Posts: 1409 |
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. |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
yeah at fld badlines happen naturally when you stop the scrolling, no need to force em. |
| | 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. |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
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. |
| | 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 ? |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
yep :) |
| | 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) |
| | Mixer
Registered: Apr 2008
Posts: 452 |
lda logo1_d015, x
sta $d015
Perhaps that write takes place too late and it is already line 52. |
| | 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 |
| | Rastah Bar
Account closed
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. |
| | 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. |
| | Mixer
Registered: Apr 2008
Posts: 452 |
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. |
| | Dano
Registered: Jul 2004
Posts: 234 |
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. |
| | 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. |
|
