English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 31 October 2019, 16:58   #221
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,339
Blitter idle cycles need free cycle. I just rechecked.

Code:
B-B-B-B-B-B ->
BDB-BDB-BDB
Quoted part is blitter end special case. Idle cycle before last D write does not require free bus.
Toni Wilen is offline  
Old 31 October 2019, 17:23   #222
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 489
Quick question about something that was touched on a few pages ago:

When double buffering with normal, blitter-queue free code, where is the best / most correct place to update COP1LC to switch between two copper lists?

I know the vblank interrupt is too late, and I don't want to busy-wait until vertical blank, or change it at a dangerous time.

Should I set up a copper interrupt to happen when I'm close to the end of the screen, but before vblank has started?
deimos is offline  
Old 31 October 2019, 17:43   #223
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,374
Quote:
Originally Posted by Toni Wilen View Post
Blitter idle cycles need free cycle. I just rechecked.

Code:
B-B-B-B-B-B ->
BDB-BDB-BDB
Quoted part is blitter end special case. Idle cycle before last D write does not require free bus.
Thanks for clearing it up (again), next time I won't trust merely my eyes

Quote:
Originally Posted by deimos View Post
Quick question about something that was touched on a few pages ago:

When double buffering with normal, blitter-queue free code, where is the best / most correct place to update COP1LC to switch between two copper lists?

I know the vblank interrupt is too late, and I don't want to busy-wait until vertical blank, or change it at a dangerous time.

Should I set up a copper interrupt to happen when I'm close to the end of the screen, but before vblank has started?
That is certainly an option.

Another is to set the COP1LC values using the copper as the last thing before the copper list end. Then, during the vblank interrupt, update the values in the copperlist rather than directly updating the registers. When I use two or more copperlists I do it this way, but it is easy for me considering I so far have had to change copperlists every frame in this situation.

Note this does normally mean you have to know in advance when the lists needs to be changed.

Last edited by roondar; 31 October 2019 at 17:44. Reason: Spelling errors
roondar is offline  
Old 31 October 2019, 17:49   #224
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 197
Quote:
Originally Posted by Toni Wilen View Post
Blitter idle cycles need free cycle. I just rechecked.
Quoted part is blitter end special case. Idle cycle before last D write does not require free bus.
Thank you very much for checking!
chb is offline  
Old 31 October 2019, 17:54   #225
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,230
You can also update COP1LC in your normal code flow (not from VBI or IRQ).

COP1LC is buffered so any beam position of previous frame is good.
If you are concerned about an improbable "half update" you can:
Code:
move.w #$4000,$dff09a
check if you are before $138_y,$not-to-late_x
move.l #new_COP1LC,$dff080
move.w #$c000,$dff09a
Or, for a 64KB bound copper list, update only COP1LCL without protection.

Cheers.
ross is offline  
Old 31 October 2019, 17:56   #226
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,374
Yes, main loop will also work
roondar is offline  
Old 31 October 2019, 18:05   #227
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 489
Quote:
Originally Posted by roondar View Post
Yes, main loop will also work
I think though, as I need to know when it's safe to start drawing in the buffer that's been switched out, I need to time for when the screen is about to refresh, so main loop is probably not for me.

I'll have to learn that copper stuff again.
deimos is offline  
Old 31 October 2019, 18:07   #228
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,616
Hve you ever tried to go with one plane and see if cpu + blitter will catch up cpu only?
sandruzzo is offline  
Old 31 October 2019, 18:22   #229
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,230
Quote:
Originally Posted by deimos View Post
I think though, as I need to know when it's safe to start drawing in the buffer that's been switched out, I need to time for when the screen is about to refresh, so main loop is probably not for me.

I'll have to learn that copper stuff again.
Off course from when you 'switch' you can write in the disabled buffer from the next vertical blank (or if you want, after the last visible screen line).
ross is offline  
Old 31 October 2019, 18:22   #230
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 489
Quote:
Originally Posted by deimos View Post
I think though, as I need to know when it's safe to start drawing in the buffer that's been switched out, I need to time for when the screen is about to refresh, so main loop is probably not for me.

I'll have to learn that copper stuff again.
Does this look like the correct way to trigger an interrupt at the end of my display, if my DIWSTOP is 0x2cc1?

Code:
    0xffdf, 0xfffe, // handle rollover
    0x2cc1, 0xfffe, // wait for end of display
    intreq, intf_setclr | intf_coper, // trigger interrupt
    0xffff, 0xfffe // sleep
deimos is offline  
Old 31 October 2019, 18:25   #231
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 489
Quote:
Originally Posted by ross View Post
Off course from when you 'switch' you can write in the disabled buffer from the next vertical blank (or if you want, after the last visible line).
Yes, but I have to know that the last visible line has passed, so rather than wait I may as well have an interrupt. No?
deimos is offline  
Old 31 October 2019, 18:35   #232
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,230
Quote:
Originally Posted by deimos View Post
Yes, but I have to know that the last visible line has passed, so rather than wait I may as well have an interrupt. No?
No need to waste time with an IRQ (as well as to complicate the code).

With my last code snippet you know where you are.

So:
- normal flow ...
- if (y<$12C) {wait $12c};
- protect_write(COP1LC) and start new rendering;

if you have triple buffer you don't even have this problem.

EDIT.
This starts from the assumption that in any case in the main code you have to wait for the IRQ because you have already finished your task for that frame.
So this approach has the advantage that you save time if you are at the limit with the frame time, or you receive a higher level interrupt towards the end of the screen
(IRQ6 CIA module player?) and you delay it, slightly but fundamentally, by the protection code.

Last edited by ross; 31 October 2019 at 18:49.
ross is offline  
Old 31 October 2019, 18:49   #233
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 489
Quote:
Originally Posted by ross View Post
No need to waste time with an IRQ (as well as to complicate the code).

With my last code snippet you know where you are.

So:
- normal flow ...
- if (y<$12C) {wait $12c};
- protect_write(COP1LC) and start new rendering;

if you have triple buffer you don't even have this problem
But, I would know where I am because I'd waited until I got there. Maybe it doesn't matter, in the big scheme of things, but I'd rather, just, not.

And if I understand it correctly, I do still have this problem with triple buffering, just maybe in a different place.
deimos is offline  
Old 31 October 2019, 18:51   #234
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 489
Quote:
Originally Posted by ross View Post
EDIT.
This starts from the assumption that in any case in the main code you have to wait for the IRQ because you have already finished your task for that frame.
I don't think my frame rates will ever be high enough for this to be a concern.
deimos is offline  
Old 31 October 2019, 18:56   #235
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,230
Well, all these different approaches can work.

Use the one where you feel most comfortable.
In fact, since your FPS are low, you don't have big advantages saving few cycles from an IRQ
ross is offline  
Old 31 October 2019, 19:00   #236
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,230
Quote:
Originally Posted by deimos View Post
And if I understand it correctly, I do still have this problem with triple buffering, just maybe in a different place.
At some point yes, if you render very fast, but normally not!

EDIT:
I'll give you an example so you'll see that it will be clearer to you.
Suppose you already rendered two scenes and you are working on the third.
If I have the certainty that you code require more than one frame to render it, you always have a scene ready to display when you want, without checking where you are:
(1) display (2) ready (3) work
(1) work (2) display (3) ready
(1) ready (2) work (3) display
---

Yes, you reactivity at game controls are delayed..
But inertia is a component of a flight simulator

Last edited by ross; 31 October 2019 at 19:20.
ross is offline  
Old 31 October 2019, 19:34   #237
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 489
Quote:
Originally Posted by ross View Post
At some point yes, if you render very fast, but normally not!

EDIT:
I'll give you an example so you'll see that it will be clearer to you.
Suppose you already rendered two scenes and you are working on the third.
If I have the certainty that you code require more than one frame to render it, you always have a scene ready to display when you want, without checking where you are:
(1) display (2) ready (3) work
(1) work (2) display (3) ready
(1) ready (2) work (3) display
---

Yes, you reactivity at game controls are delayed..
But inertia is a component of a flight simulator
Yes, I think this is what I had with my first blitter queue implementation, except I called my buffers front, back and flipping, and the switching between front and flipping was always done at the right time by a vblank interrupt (I was modifying copper lists, not strobing copjmp). Swapping back and flipping happens whenever you're ready, but you need to know the raster is finished with the front before you swap front and flipping.

I even extended this concept to my copper list blitter queue, with front being what the copper was executing and back being the queue that was being built. That was when I started to run out of chip memory.
deimos is offline  
Old 31 October 2019, 21:46   #238
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,230
Quote:
Originally Posted by deimos View Post
That was when I started to run out of chip memory.
ross is offline  
Old 01 November 2019, 03:58   #239
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,616
Can you try to build a version were you enable Aga bandwidth?
sandruzzo is offline  
Old 01 November 2019, 10:53   #240
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,374
I don't think it'll make much of a difference for this particular game. AGA bandwidth features are mostly useful for the Blitter or when using lots of bitplanes. For anything 4 bitplanes and less, switching to higher fetchmodes should not affect the CPU much if at all.

This is because the CPU can still only access the bus every other cycle (that is, it can access any cycle on the bus, but not two cycles in a row). This is basically* the same CPU throughput as you'd get on an OCS 4 bitplane screen.

*) Barring contention from the copper and small edge cases where the CPU gets misaligned and misses two cycles. But that latter point is fairly rare and won't impact performance in a meaningful way.
roondar is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
So, I'd like to write a new Amiga game - what do you want to see? Graham Humphrey Amiga scene 88 26 February 2012 22:50
My sales over next couple of weeks emdxxxx MarketPlace 4 31 October 2007 11:17
AmigaSYS 1.7 Released ETA : 1-2 Weeks. Dary News 34 22 March 2005 20:51
HOL mentioned in this weeks Micro Mart fiath Amiga scene 8 07 June 2004 00:56

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 08:30.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.10178 seconds with 16 queries