Horizontal split screen with modulo trick

[Toni Wilen]

If DDFSTRT == DDFSTOP: stop never happens, you get max overscan.

There is always at least two "bitplane blocks" because DDFSTOP means "one more block to go before end".

[NorthWay]

Originally Posted by Toni Wilen

If DDFSTRT == DDFSTOP: stop never happens, you get max overscan.

Erm... no. I did say AGA though. See my poor mobile snap. (I haven't fixed the modulos to make it look right as I was only looking for the effect. EDIT: modulo 24 corrects it)

Originally Posted by Toni Wilen

There is always at least two "bitplane blocks" because DDFSTOP means "one more block to go before end".

I guess I can live with that as I more or less intended to allow for scrolling anyway.

But how did you set up the copper for the split testing then?

[Toni Wilen]

I used ECS, lores, single bitplanes (to make it easier to position copper moves when testing)

$8001,$fffe
DDFSTRT=$40
DDFSTOP=$70
$8071,$fffe
DDFSTRT=$7a ($78 is too small)
DDFSTOP=$c8

[aros-sg]

horizontal split: what about dual playfield and changing playfield priority mid screen?

[idrougge]

Excuse the OT, NorthWay, but is that a multisync screen you've got there?

[NorthWay]

Originally Posted by idrougge

Excuse the OT, NorthWay, but is that a multisync screen you've got there?

An old Nokia 447M I blagged from work. 20+ years? Connected to an AMON scandoubler.
I.e. yes. But not 15KHz. AFAIK.

(I'll do some more testing when my sleeping pattern isn't so fucked up and I have the energy to think clear. Tired but can't get proper sleep...)

[NorthWay]

Welcome to Weirdness, population >=1.

From 38 to D8 with STRT=STOP I see fetches from left overscan to STOP. I.e. at B8/B8 I need modulo -8, D8/D8 -16. D8/F8 same as D8/D8.
With 18/18 I get _full_ overscan (so including right side) and need -16 modulo.
(Still showing a 320 pixel wide picture.)
Checking when the values are looked at with $38/$58 seems to give (subtract 8 to get wait for copper position):
STRT changed (to $78) earlier than $XX79 will combine with the old (to give the full overscaneffect ). Setting it back to $38 has no effect!!! (Wrong position I set it?)
STOP changed (to $9a?) earlier than $XX59 will always replace the old one.

I get the same result as Toni; there needs to be one idle fetch cycle if not then the logic will join together the display settings.
Is it possible to find any way of reseting the logic behaviour? Change fetchmode? Toggle DMA? Write bitplane data registers? Bueller?

[NorthWay]

Sometimes a picture says more than 1K words.

[ovale]

Wow!
Success?
How small you managed to get the gap?
Code?

[NorthWay]

No gap. I had more or less surrendered. I don't really know what I did to make it work. Split -16 / +24 modulo IIRC.

Source and exe attached.

Wait, this is a new effect so I get to name it, right?
In that case, please meet "Tech-Tech-Tech". (Isn't that an appropriate name? Any sideways shift, repeating.)

WinUAE 3.5.0 does not replicate the way it looks on my 4000.
Also, I am getting a white colour instead of black that I don't understand. (Down left side and at the bottom. Not in WinUAE.) EDIT: Bug in PicCon - it says 69 colours, but wont save or edit more than 64. Some colour data is $DEADF00D... If I force conversion to 8 planes it saves everything.

The source has lots of stuff from something else I did at one point in time so you can strip out a whole lot.

[NorthWay]

Did anyone test the executable or make their own?
Does it work for you, do you see the same effect as me?

[robinsonb5]

Originally Posted by NorthWay

Did anyone test the executable or make their own?

I'll definitely take a look when time allows - nice work!

[Toni Wilen]

AGA probably allows it in higher fetchmodes if DMA is considered stopped after first 8 DMA slots of "bitplane block" after DDFSTOP. (not full 16 or 32 slots, depending on FMODE)

This would make it possible to restart DMA during following idle slots = no gap. (This is my guess, nothing tested yet)

EDIT: I am now 99.9% sure that this explains it. There must be some extra logic in AGA that stops the DMA "early", probably because without it active DMA would wrap around to next line which most likely would cause side-effects even when DMA does not do any fetches.

EDIT2: Emulation code updated to support this situation and display appears to be identical to your screenshot (except that one color but I think it is uninitialized palette entry)

[dissident]

Originally Posted by NorthWay

No gap. I had more or less surrendered. I don't really know what I did to make it work. Split -16 / +24 modulo IIRC.

Source and exe attached.

Wait, this is a new effect so I get to name it, right?
In that case, please meet "Tech-Tech-Tech". (Isn't that an appropriate name? Any sideways shift, repeating.)

WinUAE 3.5.0 does not replicate the way it looks on my 4000.
Also, I am getting a white colour instead of black that I don't understand. (Down left side and at the bottom. Not in WinUAE.) EDIT: Bug in PicCon - it says 69 colours, but wont save or edit more than 64. Some colour data is $DEADF00D... If I force conversion to 8 planes it saves everything.

The source has lots of stuff from something else I did at one point in time so you can strip out a whole lot.

Definitely a very cool trick. Thanks for sharing your code, NorthWay. I will play a little bit with this feature on my A1200.

[NorthWay]

Originally Posted by dissident

Definitely a very cool trick. Thanks for sharing your code, NorthWay. I will play a little bit with this feature on my A1200.

If anyone has looked at this then I'm sorry for the borked logic that hoisted the right hand split one line above the left. I finally got my head on the right way and saw how I had swapped modulos.
I also can't find the graphics files I originally used - I think they are on an IDE drive (I'm using a lovely silent SATA SSD on my cybscsi) so the copperlist is still missing some colours. I think I have the original files at work, and if not I'll see if I can get the IDE disk to talk to something or other (I have an original X-Surf with IDE but I'm not 100% sure if it is possible to use the cable the wrong way around, and where the driver is. Sits in my 3000 which has the lid off.)
I'll pack up everything needed to make it assemble (own includes and all) when I find the files.

Funny how you can't move onto the next thing until you are satisfied with the old one...

[wodan]

Could this be used to create a tiled screen? (so rather than blitting your background, just change the dma pointers to the right tiles)

[mr.spiv]

Originally Posted by aros-sg

horizontal split: what about dual playfield and changing playfield priority mid screen?

Works.. done in some demos successfully.

[NorthWay]

Originally Posted by wodan

Could this be used to create a tiled screen? (so rather than blitting your background, just change the dma pointers to the right tiles)

At least 64 pixels wide tiles with FMODE 3. Maybe 32 pixels if FMODE 1/2 ???

[dissident]

Originally Posted by dissident

Definitely a very cool trick. Thanks for sharing your code, NorthWay. I will play a little bit with this feature on my A1200.

Well, it took some time, but now I've got a nice exmple for AGA machines how this horizontal screen split could look like (see screenshot).

I have a display with two identical images, each "viewport" has a size of 144x256 pixels and a depth of four bitplanes. The gap is larger then 16 pixels, 32 pixels, but that's because of the fact that the images are aligned to the left & right border. A gap of 16 pixels is also possible.

I used Toni's hint and did a little modification of the copperlist. To display the bitplanes correctly, I initializer the BPL1MOD/BPL2MOD registers after the datafetch registers. The copperlist looks like this:

$2c01,$fffe
$0092,$0038
$0094,$0078
$0108,-18
$010a,-18
$2c79,$ffffe
$0092,$0090
$0094,$00d0
$0108, 32*3+(32-18)
$010a, 32*3+(32-18)
$2d01,$fffe
...

Bandwidth: 1x, 16 Pixels datafetch

Explanation for the moduli value -18: For the left image the hardware reads 18 Bytes or 9 words as a data fetch. After that we have to point to the start of the bitplane again and substract these 18 bytes again.

The right image starts also at the beginning of the bitplane and 18 bytes are read. I use the RAWMODULO format and the bitplanes are stored parallel. First line bitplane 0..3, then second line bitplane 0..3 and so on.

We already read one line, so to get to the next line of the bitplane we need to skip the other lines of the bitplanes (plane_width*depth-1).

My source bitplane is much bigger with a width of 256 pixel for the use of AllocBitmap(). This is not really necessary. You could also use AllocRaster() for a bitplane of 144 pixels width. Due to the fact my source bitplane has a different width, I add the difference (plane_width-data_fetch_width) additionally. For the second line we point the beginning of the second line of the bitplane and the process repeats.

I enclosed the executable file. All is written for an AGA machine and only runs on this config.

How could this be used in a game? For sure for a shoot'em'up or racing cars game with a vertical scroll in a two player splitscreen mode. Caution has to be taken for a collision detection with sprites. To detect a collision for each "viewport" sprites 0-3 could be used for the first player and sprites 4-7 for the second player.

[ross]

Originally Posted by dissident

Well, it took some time, but now I've got a nice exmple for AGA machines how this horizontal screen split could look like (see screenshot).

It's never too late

Nice!