| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
D011 scrolling
Hi,
What is the best rasterline to flip the D011, when
scrolling the screen ?
No FLD!
Plain old scrolling ?
I have timing error, so the text jumps a bit.
Scroll the colorram too in same scan, takes a lot
of time..
Thanks for ANY help!!
|
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
change $d011 anywhere outside the text window. that is, in the border, not in the area of lines $30-$f7. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Thanks Krill!
I do it at FD so now it flows. :-)
|
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Krill ?
How much time does FLD take, compared to screen+colorram copy ?
|
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
The Vic fetches new colours and chars when the 3 lowest bits of the scrollregister and the rasterregister are equal. If you can avoid that, because you change the scroll-position continously, blank lines will be inserted, and thats called FLD. Unlike scrolling by copying memory you have to invest rastertime every frame, and the graphics you scroll out at the bottom will not become visible at the top of the screen. Its just inserting blank lines, you can only move rows of chars to the bottom of the screen. Theres another effect called linecrunching, in combination you can do something more similar to regular scrolling. |
| |
CyberBrain
Administrator
Posts: 392 |
Hmm... my vic-trick memory is a bit rusty..
But you're doing an upscroll right?
The fastest you can upscroll the colorram without using any tricks at all (are there any?) is something like this:
LDA $D800+40
STA $D800
LDA $D801+40
STA $D801
LDA $D802+40
STA $D802
...
...
LDA $D827+40
STA $D827
(and the same for the other 23 lines)
Don't put the code into any loops. It'll just slow it down a lot. Make a small routine to generate the code.
since LDA $xxxx and STA $xxxx both takes 4 cycles, and there are 40 chars on each line, and there are 24 lines to be upscrolled, it will take:
4*2*40*24=7680 cycles to upscroll the colorram.
(that is ~122 rasterlines, or ~15 charlines)
(ofcause you also gotta put the new colors on the 25th line, so it'll take a little longer)
(you can use the same method on upscrolling the screen too, but i guess you can speed it up by doing some tricks there)
I'm not sure how you would use FLD by itself to make an upscroller? (unless the text is only one screen high) |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Cyberbrain:
I've done this..
LDA $0428
LDY $D828
STA $0400
STY $D800
LDA $0429
LDY $D829
STA $0401
STY $D801
etc..
I'm going to use the 26th line too.. hehe
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
nah, you can do it faster
lda #xx
sta $0400
lda #xx
sta $d800
=) |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Hmm, but my way the char+color get updated closer to eachother, isn't that to prefer ? or why not ? |
| |
CyberBrain
Administrator
Posts: 392 |
i think it was a joke. :) if you had unlimited memory, you could make one piece of code for each frame - but that could be done twice as fast as oswald does it.. :) |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
I read though that a couple of times before I realised it must be a joke to.
I remember reading a C64 mag where one of the Rowlands? said that they used some super duper trick (which I guess is some secret they only know) to do really fast color scroll (horizontal I think), I think he said it was a fault in the VIC chip that they were exploiting. Does anyone know if this was just talking up there game (Mayhem) or does anyone know what this super duper trick was? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
I bet that was horizontal hardware scrolling :)
just do a dec/inc d011 (or inc dec ? cant recall) on the last top border rasterline, and the 1st column of the screen will start where you do the trick, needs cycle exact timing. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Thanks, sounds like you get horizontal scrolling by inc/dec vertical scroll bits. Have I got that right cause that sounds pretty freaky. So you just chuck new bytes down either far left or far right (depending on which way you are scrolling) column of the screen once you've scrolled eight bits?
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
here is how it works:
http://www.minet.uni-jena.de/~andreasg/c64/vic_artikel/vic_arti...
generally it juts moves the place of the first column of the screen, and the screen will wrap around, so before the first coulmn you get the last. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
oops, I thought the link will jump to the right place, but it does not.
read under:3.14.6. DMA DELAY |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Thanks, had a quick read of it, sounds pretty complex to. If the screen can only wrap around I can't see how it could have been used in a game like Mayhem, unless there is a way of changing only the bytes in the first or last column. Even if it's not the trick they used it's still pretty freaky. |
| |
CyberBrain
Administrator
Posts: 392 |
DMA DELAY has often been used in the good old wanker-effect. You know... Where you move a logo left/right by a sinus movement. It's called wanker-effect because the movement looks like.. err... wanking. (if you use double-sinus it looks like drunk wanking) |
| |
Puterman
Account closed
Registered: Jan 2002
Posts: 188 |
For more advanced wanking techniques, please consult the ever popular Wank Article. |
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
Well, not that I know what I'm talking about but anyway. I assume that by using DMA delay, one only need to copy 25 bytes rather than 1000 when scrolling a "full column"? I.e. replace the column which wraps? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
stingray: the explanation is complex, the theory codewise is simple: do a dec d011 inc d011 on the last top border rasterline in the middle of the screen with a straight irq, and you will see how it works.
or to explain it in another way:
lets say the screen has just 10 columns:
default state:
0123456789
dma delay:
dec d011
inc d011
\/
6789012345
to update the screen you just change the columns that are actually at the leftmost, rightmost on the screen.
amidog: right. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
ofcourse csdb was "wise" enough to remove the necessary spaces.. argh.. once again:
dec d011
inc d011
____\/____
6789012345 |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Thanks again Oswald. I get the wrapping part, thats not the part i'm having trouble understanding. What I wont to know is how you change just the new column so you arn't just continuesly wrapping round or is that just not possible? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quote: Thanks again Oswald. I get the wrapping part, thats not the part i'm having trouble understanding. What I wont to know is how you change just the new column so you arn't just continuesly wrapping round or is that just not possible?
you scroll say one char left and have to put a new column in to the right. that can be at any offset of $00-$27 into a char line, depending on the current x-offset. so you just need to get you x hardscroll value, add some constant value and do mod 40 on it. |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
I'm still confused on how to use DMA delay for >80 char wide screens (ie, when you've already delayed 40 cycles and need to go more). I don't need it for anything that I'm currently writing, but I tried to mess with it and got stumped, besides either doing a full redraw every 40 chars, or doing multiple delay lines to line things up (which loses more and more display lines). How wide do levels max out at in games like Mayhem in Monsterland? It looks like it's a flush 24 chars tall, so giving 8 lines of delay, I'm guessing 40+40*8=360. But IIRC, some levels are like 13 screens wide or more... bleargh! |
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
Well, look at this column display (read as 2 number values from top to bottom):
start:
00...34
12...90
rotated a lot left:
3400...
9012...
one more:
400...3
012...9
one more:
00...34
12...90
and what do we have? The start position!
So, when you have scrolled the screen 40 chars, you are back at the start position and have changed all columns, so I assume you just start over, i.e. set DMA delay to zero and repeat the procedure... Not that I know for sure, since I've not tried anything like this myself... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
amidog: you're almost right, except that if you have scrolled the screen by 40 columns, it also moves one char row UP. So when starting the process again, you will have to change to another screen, built up while scrolling, to hide the jump one row down, when starting over.
for example at soiled legacy there's a loader part wich swings in a bitmap gfx in from the left, and then it goes out to right, I had to copy the gfx to another bitmap shifted by one char row, and change the display to it, when it started to move its next 40 char. |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
...plus a full copy of colorram if you're using it, which is the real killer. |
| |
raven
Account closed
Registered: Jan 2002
Posts: 137 |
@White Flame:
Check out the end-part of Insomnia.
There's a continuous fullscreen bitmap scroll using
DMA delay, including color-ram.
|
| |
White Flame
Registered: Sep 2002
Posts: 136 |
Yeah, works great when you can pause the screen for a couple of seconds every 40 chars... ;) |
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
Well, the only real problem as I see it is the color-ram copy. After all, by using simple double buffering, when you copy a column to the visible screen (it being text, bitmap or whatever), just copy the same column to your second buffer. This will double the amount of bytes to copy for each char scrolled (from 25 to 50 for text), but after you've scrolled 40 chars, you have already prepared the next screen and can easily just switch to it without any overhead what so ever (except for color-ram).
As I found this VSP discussion rather interesting, I've now written my very first VSP routine using the method above (only for text yet though and without using color-ram, but the theory is the same) and it's working nicely. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
AmiDog, any chance of posting your code here, or is it to long to post? |
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
The source is a bit long... 16kb actually. But you can get it here:
http://user.tninet.se/~cqj150m/vsp.s
But remember a few things. The sources should be assembled with tass, has very few comments, has only been tested on PAL VICE, has not been optimized at all and doesn't handle smooth scrolling (well, there's some code in there you can enable, but it doesn't set things up properly so you never see the first column etc.).
Also, I'm not very good at 6502 asm so some things are probably done in a far from optimal way. And I've borrowed the stable raster routine from... The Fridge I think it was... |
| |
Dane
Registered: May 2002
Posts: 423 |
VSP is fun indeed - did my first ever in Game Over, where the last picture of the exlosion is 48x24 chars in FLI. And yes, I'd say that is solved in a rather spiffy way. Bankswitching halfway through the vsp.
Only prob is d800 has to be copied, but then again we're only talking about 24 bytes or so.
I'm sure others have done even neater tricks, but this was just my way of not having to copy lots of graphics to both bitmap, screens and colram. |
| |
bOOZElEE
Registered: Dec 2002
Posts: 35 |
@amidog
hope you wont mind about my mail...
next time i read everything twice or even thrice to make sure who wants da stuff ;) |
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
@bOOZElEE
Well, I just noticed that the email address I've got registered here is long gone, so I didn't get any email anyway... |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Thanks AmiDog. 16k, alright so posting it on the forum was a bit out of the question. |
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
I've spent some more time on the VSP routine, you can get it here:
http://user.tninet.se/~cqj150m/vsp.zip
This have changed:
1. Added smoothscrolling.
2. Joystick controlled scrolling.
3. Lores multicolor bitmap scrolling including color-ram.
4. Requires 64tass to compile now (uses macros and such).
Basically, I've converted a 1024x192 bitmap (part of a wallpaper with the famous swedish moose Hälge) to C64 lores using Paint Shop Pro and the ConGo Photoshop plugins. I then used a small piece of code to convert the resulting bmp bitmap to something more C64 friendly.
With VICE, you should be able to just autostart the VSP.P00 file and it should load the graphics and VSP routine and start it.
This is the memory layout of the 1024x192 image (just consider it to be an normal C64 lores bitmap, just a little wider and not as tall):
$6400 - $C3FF bitmap
$C400 - $CFFF screen ram
$E000 - $EBFF color ram |
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
A small update with a new image (made of 3 intro screens from three great C64 games), back/border colors are now stored in the image files and debuging (border color changes) is disabled. Get it here:
http://user.tninet.se/~cqj150m/vsp1.zip
Addition to the memory layout:
$EC00 background
$EC01 border
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Coming soon VSP mega demo by AmiDog, well if you keep going at this rate :) |
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
LOL! :) Well, I just moved the second bitmap to the very end of the RAM and fiddled with $01 to access the RAM below the IO area at $d000. So now I've got no less than 39KB ($4000-$dc00) for the image, or 1664x192 pixels if using just 2 colors (like a dithered b&w image). Working nicely :)
I guess one would have to play with some kind of realtime decompression or something to be able to use a larger image. (Or use a SCPU/REU, but that's cheating.) |
| |
bOOZElEE
Registered: Dec 2002
Posts: 35 |
why is realtime decompression considered as cheating?
its nothing else than converting your more memory friendly picture data to a vic usable format.
or is there some point ive missed?
|
| |
Spinball
Registered: Sep 2002
Posts: 88 |
i think amidog means that using scpu or reu would be cheating NOT realtime decopression. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
rayden, you should really read everything twice or thrice =) |
| |
bOOZElEE
Registered: Dec 2002
Posts: 35 |
oh... ;) |
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
Another update, in case anyone still cares :)
http://user.tninet.se/~cqj150m/vsp2.zip
I'm now using $4000-$dc00 for the image which give the following resolutions:
b&w: 1664x192
hires: 1472x192
lores: 1328x192
(Example images, ugly closeups of a flower, are included.) |
