HScroll: Very Technical Question...

[OldMan]

Does anyone here know if it is possible to change the hscroll register -in the middle of a scanline- ?
Everything I've seen does it relatively immediately after the hsync; what I want to know is if it is possible to delay for X cycles and change it, to get a different portion of the BAT displayed.
(think split screen, vertically, using different sides of a large BAT).
Assuming it is possible, does/would this cause graphics glitches? (smearing, dots, etc)

[Arkhan Asylum]

CharlieMac would be the person to ask, probably.

I thought you could, and thought there was a demo showing it...from CCovell maybe.

can't seem to find it though.

[TurboXray]

Unfortunately not. There's a point where BXR and BYR are latched once per VDC scanline. I say VDC scanline because you can have multiple VDC scanlines inside a single NTSC scanline (VCE). If you setup the VDC for this, you'll get a split display (independent left and right sides, including sprites), but the draw back is that there's a gap between each VDC scanline (left/right). IIRC, all the VDC regs are either latched once per VDC scanline or once per VDC 'frame'.

[touko]

Does anyone here know if it is possible to change the hscroll register -in the middle of a scanline- ?
Everything I've seen does it relatively immediately after the hsync; what I want to know is if it is possible to delay for X cycles and change it, to get a different portion of the BAT displayed.
(think split screen, vertically, using different sides of a large BAT).
Assuming it is possible, does/would this cause graphics glitches? (smearing, dots, etc)

It s probably possible,but you need a stable irq for That .

[TurboXray]

Does anyone here know if it is possible to change the hscroll register -in the middle of a scanline- ?
Everything I've seen does it relatively immediately after the hsync; what I want to know is if it is possible to delay for X cycles and change it, to get a different portion of the BAT displayed.
(think split screen, vertically, using different sides of a large BAT).
Assuming it is possible, does/would this cause graphics glitches? (smearing, dots, etc)

It s probably possible,but you need a stable irq for That .

Feel free to try, but I've tried writing to any regs during all parts of the active part of the scanline and nothing is updated. I'm not the only one though, I believe Charles has tried as well as research/tests by emulation authors. Some VDC regs are latched once per scanline (the ones that usually pertain to horizontal frame settings and X/Y regs) and some are only latched once per frame(map width and regs that handle the 'frame' size).

[OldMan]

Some VDC regs are latched once per scanline

That might explain what I was seeing.
I tried using the timer irq to split the scanline. I came to the conclusion that it probably doesn't have enough resolution to hit a particular spot in every scanline.
However, it was enough hit about every other scanline. Yet I still wasn't seeing what I expected. So I figured something was only getting latched at the beginning of the scanline. Nice to know for future reference.

I think I may try a timed loop in the timer irq, just to make sure.

(Just trying to figure out how the four-screen stuff in some games was done. And why <lol> )

[TurboXray]

(Just trying to figure out how the four-screen stuff in some games was done. And why <lol> )

It has to do with the VDC and the VCE.

 The VCE has a fixed NTSC frame. 262 or 263 scanlines (depends on the filter bit you select) and fixed 15.7khz hsync. The VCE provides both the vsync and hsync triggers for the VDC, but originally the VDC can be setup to build out all sorts of resolutions. But as is, it's running in slave mode. There are VDC regs to change this, but you'll get screen roll since it won't read VCE timings anymore and thus out of sync.

 Even though the VDC is running in slave mode, you still have to define a 'VDC' frame inside the VCE frame work.
 
 HSW = horizontal sync pulse width (in VDC pixel clocks)
 HDS = horizontal display start ( offset to the active part of scanline for BG/SPRITE output)
 HDW = the width of the active VDC displayable part of the scanline
 HDE = the ending gap between HDW and HSW.

 So it works like this: HSW is a period where the VDC waits (does nothing) for the hsync trigger from the VCE. Once the trigger is initiated from the VCE, the VDC immediately leaves HSW state and goes into HDS phase. So you can put a large number in HSW and it shouldn't effect the active displacement of the visible VDC data on the scanline (bg/sprite). If for some reason the VDC doesn't get a trigger from the external device (VCE) by the time HSW ends, it automatically goes to HDS phase. Like wise, if the VDC gets an hsync trigger from the VCE anywhere else in the scanline position, it will end the display of the scanline and start a new one.

 Thus, you can have more than 1 VDC active scanline per 'VCE' scanline. But don't forget, the RCR counter also gets incremented. Thankfully the VDC can be setup for up to a total of 512 scanlines, so you have enough logic to display 480 scanlines. The vertical height of the frame works in the same way. If the VDC ends the frame height earlier than the VCE defines, It'll start to draw the next frame on the same window until the VCE comes along and forces the VDC current state to end the frame (vsync).

 Most games set the horizontal resolution of the VCE to 10.74mhz dot clock but with the standard 5.37mhz dot clock frame settings on the VCE, to get the famous 4 screen mode. But you don't need to do that. I mean, you have to rely on the VCE higher dot clock setting to setup all sorts of combinations on the VDC output. You could change the resolution of the VCE mid scanline too, but that's more complicated as you then need to sync the CPU exactly with the VDC (even 1 cpu cycle jitter will be noticed). The only way I know of doing that is to get the VDC to stall the CPU. During sometime in hblank of the VDC, it's processing sprite data and fetching from vram. If the cpu writes more than the 1 WORD fifo, the VDC stalls the CPU. It gets pretty complicated to setup (I've only generalized the details).

 There's also something else to make note on; the VDC doesn't take the whole scanline to fetch and setup the sprites for the next scanline (like the Genesis and SNES do). It does ALL of it in the hblank time of the scanline. That's pretty damn impressive in itself, but that's not the point. The point is, if you start to shorten that time/window - the VDC won't process all the sprites for that scanline. It'll start dropping them in pairs (IIRC, not single 16x16 cells). Just something to keep in mind if you plan on doing dual VDC scanline  setup.

 The other thing to make note of, is that the SATB entries apply to both 'scanlines' on the VCE scanline. So you can't change any X/Y positions between scanlines (only when SATB dma happens in vblank do they get changed). The way around this is to have every other 'row' of sprite pixels as transparent (all 00's). Use even Y coords for the right side and off Y coords for the left side. That way right side sprites won't show on the left side and vice versa (I've messed around with this quite a bit). The down side is that you still have to deal the 256 sprite pixel limit over both windows (this becomes more clear once you start messing with this).


 (Please forgive any typos. Don't have time to go over the post at the moment)

[touko]

It seems that VDC is not very flexible ..
Some classical effects aren't possible like split raster, or sprites multiplexing .

But good explanation tom,and very informative  

[spenoza]

It seems that VDC is not very flexible ..
Some classical effects aren't possible like split raster, or sprites multiplexing .

But good explanation tom,and very informative 

Sounds more like the VDC is just fine, but rather it is the VCE, and the VDC's reliance on the VCE, that is the limiting factor.