English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 23 November 2022, 02:49   #1
DanielAllsopp
Registered User

DanielAllsopp's Avatar
 
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 223
Quick Interrupt Question

I have a level 3 interrupt setup like this:

Code:
*******************************************************************************
* InitDisplayInterrupt
*   - Initialise interrupt
*
*   - trashes:
*   - input:
*   - return:
*
InitDisplayInterrupt:
  movem.l a0,-(sp)

  move.l VBRPtr,a0
  move.l #VerticalBlankInterrupt,INTVECTORL3(a0)
  move.w #$c020,INTENA(a6)

  movem.l (sp)+,a0
  rts

*******************************************************************************
* InterruptVerticalBlank
*   - blank template VERTB interrupt
*
*   - trashes:
*   - input:
*   - return:
*
VerticalBlankInterrupt:
  movem.l d0/a6,-(sp)

  lea CUSTOM,a6

  btst #5,$1f(a6)
  beq.s .exit
	
  *--- do stuff here ---*

  bsr SwapBuffers
  bsr UpdateFrame

  *--- do stuff here ---*
  moveq #$20,d0
  move.w d0,INTREQ(a6)
  move.w d0,INTREQ(a6)

.exit:
  movem.l (sp)+,d0/a6                                                           ;restore
  rte
1. Should the 'UpdateFrame' routine take longer than 1/50th will the interrupt fire again before it's finished, i.e. will it stack up the interrupts. Or, like I suspect, do I have to acknowledge the current interrupt before the system will fire again, and thus drop a frame?

2. I read in the HRM that you shouldn't perform any memory allocations, or access the disk from an interrupt. Stupid question maybe, but does that apply to a L3 interrupt like this? I obviously load and allocate files in from the disk, after re-enabling the OS, and then return which obviously takes longer than 1/50th to complete, but it seems to work fine.

I have a slightly different issue I'll get into later, but wanted to ask these questions first so I can wrap my head around things.

Thanks for any help.
DanielAllsopp is offline  
Old 23 November 2022, 03:30   #2
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 741
1. INTREQ bit will be set to 1 (again), and in general interrupt won't activate because it's the same level (=3). Since you are clearing the bit at the end, you will most likely clear "both" triggers, but it's theoretically possible that the new trigger will happen between you clearing it and rte, so in that case your interrupt code will be called again immediately after rte.
2. Yeah, AllocMem() clearly states: do not call from interrupts (doesn't matter the level). Reads/writes are an even bigger no-no. Interrupts are not meant to be used for intensive task (loading, memalloc, and similar...).
Since you have a lengthy interrupt handler, I would suggesting using a manually triggered (with copper, e.g at line 0 to emulate VBL, or right after last display line) lvl1 (software) interrupt instead, because of lower priority so it doesn't interfere with real hardware interrupts at lvl2/3.
a/b is offline  
Old 23 November 2022, 09:15   #3
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 2,125
Quote:
Originally Posted by DanielAllsopp View Post
2. I read in the HRM that you shouldn't perform any memory allocations, or access the disk from an interrupt. Stupid question maybe, but does that apply to a L3 interrupt like this? I
Yes, it does. There are only very limited calls you can make during an interrupt. First call allowed is Cause() to defer your interrupt to a software interrupt which is a good idea if your interrupt is lengthy, but anything can be handled within the interrupt handler - then same restrictions apply to the interrupt handler of the software interrupt. Second is Signal() to get a signal delivered to your task to wake it up from a Wait(). The latter is the design to go: To the buffer swapping, reading and memory allocation in your task, in user level. That is, your main task should wait for a signal for frame syncrhonization, then peform its action. In worst case, your signal is sent twice, but that does not cause any harm because you are in worst case then dropping a frame.



BTW, waiting for a vertical blank can also be done through graphics/WaitTOF(). It does pretty much what I sketched above: It runs into a Wait(), waiting for the graphics.library VBLank interrupt to deliver a signal, so it's quite lightweight.
Thomas Richter is offline  
Old 25 November 2022, 19:40   #4
DanielAllsopp
Registered User

DanielAllsopp's Avatar
 
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 223
First off, thanks for the tips and information above guys. Very helpful.

So, back to my reason for asking these questions. When I start RoboCop up from the CLI, as I have been doing for months now, then I have no issues with the "Loading" copper list that I poke into the COP1LCH register.

However, when I start from a startup-sequence which boots the game directly, then the copper list is displayed for a microsecond until I jump back to the system to use DOS to load my files, at which point it disappears, and then when I disable the system again it briefly flashes up before my scene changes:

[ Show youtube player ]

I've looked online for the past few days to see if other people have had the same issue, they have (see http://eab.abime.net/showthread.php?t=100936, but the solutions aren't working for me, i.e. the LoadView(NULL) etc etc.

I thought it originally had something to do with my VBI but if I remove that completely then I get the same result. I have also noticed that the system must change COP2LCH register as that gets updated.

Here's my start up code: startup.s

Any help would be appreciated

Thanks!
DanielAllsopp is offline  
Old 25 November 2022, 20:16   #5
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,267
I'm pretty sure the OS does indeed change Copperlists etc 'whenever it feels like it', which is what you'd expect given it's the OS after all

You could try saving more of your game state and restoring it and to prevent the screen flashes you could put a system-configuration file on the disk with all colours set to black (then it will still flash, but at least to a black screen). Another option (which may or may not be possible for you) might be to simply pre-load all assets prior to killing the OS and never do a OS-on/OS-off during game.
roondar is offline  
Old 25 November 2022, 21:07   #6
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 52
Posts: 3,852
Quote:
Originally Posted by DanielAllsopp View Post
However, when I start from a startup-sequence which boots the game directly, ...
Do you use a 'new' standard KS2.0+ bootblock or the old KS1.x one?
Try with the old version, the reason could be that with the new one if you don't use the console to write something, the CLI will not be 'opened'.

Your youtube video is private and does not open, so I can't tell you if I understand the problem correctly
ross is offline  
Old 25 November 2022, 21:22   #7
DanielAllsopp
Registered User

DanielAllsopp's Avatar
 
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 223
Just a quick update as the match is on… YouTube link should now be public. I’ll come back with some full answers ASAP. Thanks again all.
DanielAllsopp is offline  
Old 25 November 2022, 22:07   #8
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 741
It feels as if the OS hasn't fully finished with the display initialization (it's kind of async with the rest of the proces/task starting), so when it finally gets the control back from you, it resumes with it which causes your copper list to be nuked.
a/b is offline  
Old 26 November 2022, 15:47   #9
paraj
Registered User

 
Join Date: Feb 2017
Location: Denmark
Posts: 445
The system vblank interrupt always writes COP2LCH so that's not too surprising.
I think it's likely related to what Ross mentions. When you boot with a black screen, bitplane dma is disabled (this is not the case if the shell window has been shown, even after LoadView(NULL)), so when you restore systemDMACON the screen will go blank. As a hack you can try to add:
or.w #$100,systemDMACON
somewhere and see if that fixes it.

P.S. this part in your system restore (before exiting) is wrong:
Code:
  move.l systemOSScreenView,a1 ; <-- Move this

  jsr _LVODisownBlitter(a6)

  jsr _LVOWaitTOF(a6)
  jsr _LVOWaitTOF(a6)
  ; to here
  jsr _LVOLoadView(a6)
EDIT: Another issue with your code is that you retain ownership of the blitter after reenabling the system. This will cause a hang if e.g. trackdisk.device needs it. You should also call WaitBlit before putting the system back to sleep (as called out by the documentation).

This zombie system stuff is really tricky to get right, so make sure you test with a wide range of configurations...

Last edited by paraj; 26 November 2022 at 17:48.
paraj is offline  
Old Yesterday, 19:12   #10
DanielAllsopp
Registered User

DanielAllsopp's Avatar
 
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 223
So, it's been a hectic couple of weeks and I've only just got around to looking into this with any great detail. Thanks to everyone who put suggestions forward, as always I really appreciate the help!

First off the fixes; what I've ended up doing is removing most/all of my code from the VBI and only use it to set a flag which I then check for in my main loop to trigger the screen update (tip was found here: https://eab.abime.net/showpost.php?p...9&postcount=69).

Second fix was the issues paraj mentioned above; restoring the OS screen in the correct place when exiting, and owning/disowning the blitter when jumping between the system and back to the game.

That all works great.

Regarding the missing graphics when jumping to the system, of course ross and paraj were spot on with their analysis and when I think about it, it makes total sense. Adding the hack did solve the issue, but the final fix I applied was just enabling the bitplane DMA pretty much straight away, before I store the system DMA in any case, so switching between the game and the system always leaves it enabled.

Problem solved, and once again, many thanks to the people who made suggestions and fixes. On we plod...
DanielAllsopp 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
Question for Toni: What was Marvin Marvellous interrupt fix? rsn8887 support.WinUAE 13 30 November 2018 22:17
Quick question zerohour1974 project.WHDLoad 2 18 March 2015 23:14
Quick question AliasXZ New to Emulation or Amiga scene 1 21 January 2008 17:46
Just a quick Question ! RetroMan project.SPS (was CAPS) 4 08 April 2003 12:00
Quick question kemppe New to Emulation or Amiga scene 2 30 April 2002 01:25

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 05:25.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.
Page generated in 0.10285 seconds with 14 queries