| |
gregg
Account closed
Registered: Apr 2005
Posts: 56 |
HSP/DMA delay and screen corruption
I'm currently experimenting with HSP/DMA delay e.g. horizontal scrolling with $d011. I'm doing it by switching on the DEN bit at the right time in line $30. So far, so good, but there's screen corruption in the first line:
It looks like the VIC doesn't fetch the correct color data. I don't understand why this is happening. Can anyone explain, please? And is it possible to avoid this? |
|
... 8 posts hidden. Click here to view all posts....
|
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Hey, this is funny. There are just so many names for this effect that I was unsure how it is called. Thanks for the advice, JackAsser and HCL.
@\^_^/
Testing it on real hardware was the first thing I did after noticing this behaviour. And it look (quite) similar there...
@HCL
So you've been actually using these "crap colors" for effects?
Quote:Add a first line of linecrunch to make that bug compress in to one raster line hidden below the upper border, then simply max out the DMA delay to restore the screen. And it's called VSP... VSP! VEE ESS PEE!!!! :D
OK, that's good since this way not much screen real estate is lost. By the way, what does VSP really stand for? I thought it was "vertical screen position(ing)" or something, which of course makes no sense in the context of *horizontal* scrolling. :)
As Graham usually posts when people ask why it's called what it is; it's called VSP because the inventors decided. Please check out the original:
VSP&IK+
Variable Screen Position!
Also using an initial line crunch, then max out the dma-delay to 40 you'll get back the original screen. I.e. no data is lost. |
| |
HCL
Registered: Feb 2003
Posts: 716 |
Quote: JackAsser, HCL: are there any examples avaialable for these colours emulated incorrectly? Id like to check them on a real C64/in Hoxs64. cheers.
Hmm.. don't think so. In Tsunami the problem usually was that there was no bug in Vice, but still bugs on the real thing. Since I managed to get rid of those bugs, i guess that's not a good example. I think generally you can just throw up a few sprites on the screen and do a VSP right there and see what happens :). Possibly the sprites don't affect the result at all. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
if I havent seen this screenshot I'd have said its impossible to have this with a vsp effect.I have coded a vsp on a c128dcr and have never seen this bug showing up. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: if I havent seen this screenshot I'd have said its impossible to have this with a vsp effect.I have coded a vsp on a c128dcr and have never seen this bug showing up.
@Oswald: That's because most VSP routine does sta $d011, inc $d011 or similar directly after each other. The second STA will produce the line crunch I mentioned. If you leave out the inc $d011 and reset $d011 somewhere in the border instead u'll have Gregg's bug. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
I did it with a dec/inc d011 pair. I dont understand you, resetting d011 only later will cause the vsp creating d011 write do a linecrunch aswell? |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: I did it with a dec/inc d011 pair. I dont understand you, resetting d011 only later will cause the vsp creating d011 write do a linecrunch aswell?
The DEC triggers the VSP-effect by forcing a bad line. The INC resets $d011 to it's original state, however since it's done immediately after the DEC the timing is correct for a line crunch.
However if you reset $d011 to it's original state somewhere much later, like in the bottom border you'll have the problems gregg is experiencing. |
| |
HCL
Registered: Feb 2003
Posts: 716 |
@Oswald: You probably made your VSP on the very first line on top of the screen, and there you can (of some reason) perform this *glitch* without getting crap colors. Try somewhere else on the screen and you'll get it ;). |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: @Oswald: You probably made your VSP on the very first line on top of the screen, and there you can (of some reason) perform this *glitch* without getting crap colors. Try somewhere else on the screen and you'll get it ;).
Doing VSP somewhere else on the screen of course involves at least two lines of crap. First you must force the VIC into idle state $3fff-gfx using a simple inc $d011 (FLD). Then immediately dec $d011 + x-timing to force the VSP which will produce the crappy colors. Then to remove most of the crap, another inc $d011 (line crunch). This will give two very crappy raster lines that of course depending on situation can be quite nightmarish to fix.
Then again, I've never actually coded a VSP somewhere else on the screen and you have HCL. So hats of for the Tsunami XFLI AGSP mover. ;)
Practice vs Theory, Real men vs Wimps, 1337 vs Lamers etc... =)
Also one note on the "crap". It's basically the first gfx row repeated but with reusing the last char fetch. I.e. the bottom row's chars from the previous frame. This is emulated quite properly by VICE imo, it's how and where the FLI bug appears and in what color that's a bit uncertain. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
thanx, now its more clear.
btw.
"It's basically the first gfx row repeated but with reusing the last char fetch."
new screenmode ? ;) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: thanx, now its more clear.
btw.
"It's basically the first gfx row repeated but with reusing the last char fetch."
new screenmode ? ;)
@Oswald: Used many times. F.e. if you want the same type of chars over and over again but only change the gfx in them and still use all 200 lines you can use this trick to prevent badlines alltogether for all frames. I.e. only one initial badline then NONE. I used it in Panta Rhei f.e.
It's also commonly used for kefrens bars.
Btw, it's the exact same trick to enable char row #26. |
| Previous - 1 | 2 - Next |
