| Posted By
Sandor
on 2024-04-11
11:49:30
|  linecrunch VSP with maximum possible usable screen height
I am playing around with this, I got the theory for 232 scanlines, I wanted to get to 256, but unless some of my assumptions are wrong, I don't think I can get there.
First this is the setup for 320x232:
we have a screen buffer with 320x200 and a buffer with 320x40. This way we can do fine scrolling without any issues. The screens are normally aligned ($000-$3e7 for 1st screen and $000-$0c8), so there is no need for a full screen redraw ever, you can do infinite scroll with this. If I get to 320x256 somehow, the 2nd buffer would be 320x64 and the same rules would go.
Here is what I figured out (and please correct me if I am wrong) for PAL systems:
1) if there is no badline and ff1f is at value 6 mid scanline, the current character pointer will be increased by 40 when it switches to value 7. If we keep doing an inc on the y scroll register, we can do this in every single scanline, so we can shift the whole screen up/down in 24 scanlines maximum.
2) if we jump to scanline 204 mid scanline, at the moment it increases to 205 it resets the character pointer to 0 - if we swap screen pointers at this time, we can have a seamless connection between the 2 screens. If this is done just after the last 2 badlines happened, we don't need to be precise - we have 6 scanlines until the next fetches
3) we need to have the screen in default mode by the time we reach scanline 251 or bad things will happen
4) we can't start the screen before we reach scanline 270 or bad things will happen
Knowing this, we can do the following:
scanline 271 -> jump to scanline 311 with y scroll set to anything but 0, we set mcm and ecm on to hide the mess
scanline 0 -> we set ff1f to 6 and inc the y scroll <-- we keep doing this until we make sure we will have the scanline we want to be on top at scanline 24
once we are done with ff1f and y scroll inc, we set the ff1f and y scroll to the values for the fine scroll
scanline 23 -> we set the ecm or mcm (or both) flag(s) off after the beam is out of the screen
- when the badlines for character row 24 happen, we jump the scanline to 204 and at 205 we jump back (we might need to do this twice for a 320x232 screen in some cases)
- we don't ever allow scanline 203/204 to occur until we reach the real (original) scanlines 219/220
- after the actual screen is over, at scanline 205, we go back to scanline 221 and we are ready for the next screen.
Am I wrong with any of this? All the tests I have done so far seem to confirm all of this, and if this is true, we can't have anything bigger than 320x232 that's nicely centered. I would really like to get to 320x256, but I don't see how. Anyone have any ideas?
btw: This is not for any specific project, but I will publish the full source code if I get this working.
|
|
Posted By
Sandor
on 2024-04-12
00:03:58
| Re: linecrunch VSP with maximum possible usable screen height
Still not 100% sure if all of my assumptions are correct, but I think I got the way to do full 320x256 VSP.
If we keep the screen running, by skipping scanlines 203-205, we can reset the character counter before the vblank for large Y shifts and after the vblank for low Y shifts. We do the ECM + MCM turn off at the end of scnanline 231 and turn on at the end of scanline 287. Then we do 1-2 more character conunter resets and page swaps on screen, and it should work.
Will probably take me a few days, especially because the different fine scroll values will make it way more complicated, but I think I can get this done. If anyone can confirm if my assumptions are correct, or tell me where I am wrong before I waste too much time on a dead end, I'd be thankful.
|
|
Posted By
LBM
on 2024-04-12
03:25:44
| Re: linecrunch VSP with maximum possible usable screen height
Why do you need to reset the character position? Wouldn't it be simpler to shift the second screen to start from the $3e8 offset?
|
|
Posted By
Sandor
on 2024-04-12
04:18:21
| Re: linecrunch VSP with maximum possible usable screen height
The issue is that to get back to $000 from $3e8, it would take us 128 screens or 3200 scanlines. I guess if we would also have HSP, we could shift it directly to $000, but I didn't really understand how bubis' code worked for HSP, and VSP seems much more lenient in timings compared to that. Plus I like the idea of reseting the scanlines after each 1000 pixels because then we never need to full copy frames, we can just scroll infinitely with a buffer that's 320x264. (well a 320x200 and a 2nd 320x64 buffer)
|
|
Posted By
LBM
on 2024-04-12
04:59:17
| Re: linecrunch VSP with maximum possible usable screen height
I don't know how do you calculate this 3200 scanlines, but after 0x3ff the next character position will be 0.
So, what I advised, that at the end of the first screen, just switch to the second screen and start the content of the second screen at 0x3e8.
|
|
Posted By
Sandor
on 2024-04-12
05:28:48
| Re: linecrunch VSP with maximum possible usable screen height
Ah, I see what you're saying. I thought you were talking about the first reset (when we switch back to screen 0). There are 2 reasons why I wouldn't start the 2nd screen at 0x3e8.
1) we would end up with 24 bytes of data at the end and 296 bytes at the start, which might make copying that characterline more tedious (we couldn't just do an sta $addr,x for 40 bytes, we would need to do it in 2 runs)
2) if we do the 0x3e8 method, we will need more linecrunching if the start character line is above 25. If we reset every time, we don't care if it's screen2 -> screen1 or screen1 -> screen2 after the scroll, the maximum number of lines we need to crunch is 18. (would be 24, but it's 18 because of the pre-vblank trick)
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
