07 April 2024, 20:13 | #1 |
Registered User
Join Date: Apr 2021
Location: Kingston / UK
Posts: 105
|
Changing Bitplane Pointers Mid-Scanline
Has anyone here played around with this?
It appears I can get a stable 3 bitplane image to restart midline but not 4. I'm wondering whether it's merely a timing issue or just impossible. Just looking to void wasting any more time on this. Cheers. |
07 April 2024, 20:35 | #2 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,214
|
Description sounds a bit suspicious, but maybe I'm misunderstanding it. Sounds like a timing issue.
If you post copper and CPU code that's making these changes we can say for certain. If CPU isn't involved in changes you can omit that, but copper (or CPU) setup of screen is needed. (Or just a binary of whole thing) |
07 April 2024, 21:07 | #3 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,573
|
Most likely reason is this chipset behavior: any DMA pointer modification exactly 1 cycle before DMA transfer that uses same pointer: pointer modification write goes nowhere.
EDIT: there was thread about mid scanline change here somewhere. |
08 April 2024, 01:22 | #4 | |
Registered User
Join Date: Apr 2021
Location: Kingston / UK
Posts: 105
|
Quote:
This is the code that sets it up. I'm also reusing the first hardware sprite so it's a bit more complicated than in might be but this is literally what I'm using. Code:
initCopScrollView lea copView,a0 destination in copperlist move.w #12*16-1,d7 height of viewport move.l #$3861fffe,d0 wait for sprite change move.l #$3899fffe,d1 wait for bitplane change move.l #$38f1fffe,d2 wait for sprite reset move.l #$3801fffe,d4 move.l #scrollView+3*26,d5 scrollView is interleved bitplanes to display move.l #scrollView-6+3*26,d6 with horizontal wraparound .icLoop move.l d6,d3 move.l d4,(a0)+ bitplanes move.w #$00ee,(a0)+ move.w d3,(a0)+ sub.w #26,d3 move.w #$00ea,(a0)+ move.w d3,(a0)+ sub.w #26,d3 move.w #$00e6,(a0)+ move.w d3,(a0)+ sub.w #26,d3 move.w #$00e2,(a0)+ move.w d3,(a0)+ move.l d0,(a0)+ sprite change move.l #$014000c8,(a0)+ move.l #$0146007f,(a0)+ move.l #$014400ff,(a0)+ move.l d5,d3 move.l d1,(a0)+ bitplanes change move.w #$00ee,(a0)+ move.w d3,(a0)+ sub.w #52,d3 move.w #$00e6,(a0)+ move.w d3,(a0)+ add.w #26,d3 move.w #$00ea,(a0)+ move.w d3,(a0)+ sub.w #52,d3 move.w #$00e2,(a0)+ move.w d3,(a0)+ move.l d2,(a0)+ sprite reset move.l #$01400050,(a0)+ add.l #$01000000,d0 add.l #$01000000,d1 add.l #$01000000,d2 add.l #$01000000,d4 add.l #26*4,d5 add.l #26*4,d6 dbra d7,.icLoop rts |
|
08 April 2024, 01:26 | #5 |
Registered User
Join Date: Apr 2021
Location: Kingston / UK
Posts: 105
|
Yes. I'm seeing that when I vary the order of the pointers in the copperlist or change the wait position. I get BPxPTL writes having no effect and the plane in question that should 'restart' from the left side just carries straight on.
|
08 April 2024, 18:46 | #6 |
Registered User
Join Date: Apr 2021
Location: Kingston / UK
Posts: 105
|
OK. I give up. I really don't think it's possible.
I've tried all 24 combinations of writing the bitplanes at each DMA slot on the line and none of them result in 4 planes lining up at once. I'll just have to fall back to a more tried and tested technique for my scroll routine. One that won't be a complete nightmare to blit sprites to, at least. |
09 April 2024, 18:58 | #7 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,214
|
Sorry, I had missed that it was mid-scaline, that's indeed more tricky (and maybe not possible).
|
09 April 2024, 20:28 | #8 |
Registered User
Join Date: Jan 2012
Location: USA
Posts: 373
|
Keep this in mind: in four plane mode there is a BP DMA cycle every other cycle. The copper will use the cycles in between. The trouble is that it takes two DMA slots for one copper move. BP DMA is essentially running twice as fast as the copper.
|
10 April 2024, 16:08 | #9 |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 49
Posts: 198
|
to change the bitplanepointer maybe for a 2nd playfield on a middle of a scanline:
- it is possible to change up to 2 bitplanepointer on a scanline for the next 16pixel bpl fetch for a correct change without loosing or destroying bitplanedata when changing bitplanepointer are realized with only two copper-moves by changing only the BPLxPTL and if the changing the pointer is not directly 1 cycle before his BPLx DMA cycle. in copperlist copper-moves series: change first bpl2 pointer before bpl1 - if more then 2 bitplanepointer: from 3 to 4 bitplanes the changing starts 16pixel later to the bitplanes 1 and 2, so the bitplanepointer for bitplanes 3 and 4 have to set 16pixel later for every line (2bytes) this leaves a not correct displayed area in the beginning from 16pixel idea: put a 16x256pixel attached sprite over this lack of playfield with the bitplanedata from this area |
11 April 2024, 02:13 | #10 |
Registered User
Join Date: Apr 2021
Location: Kingston / UK
Posts: 105
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Behavior with BPLCON1 shifts and mid-scanline BPLCON0 change | losso | support.WinUAE | 11 | 21 November 2021 13:46 |
Multiplexing sprites By changing pointers | sandruzzo | Coders. Asm / Hardware | 17 | 26 August 2021 18:51 |
Copper changing sprite pointers | Muzza | Coders. General | 7 | 30 July 2021 13:58 |
When is the modulo added to the bitplane pointers? | DanScott | Coders. Asm / Hardware | 3 | 07 March 2016 18:24 |
Mid-line bitplane pointer change? | NorthWay | Coders. Asm / Hardware | 10 | 26 September 2015 13:45 |
|
|