Quick Interrupt Question

[DanielAllsopp]

I have a level 3 interrupt setup like this:

*******************************************************************************
* 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.

[a/b]

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.

[Thomas Richter]

Originally Posted by DanielAllsopp

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.

[DanielAllsopp]

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!

[roondar]

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.

[ross]

Originally Posted by DanielAllsopp

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

[DanielAllsopp]

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.

[a/b]

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.

[paraj]

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:

  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...

[DanielAllsopp]

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...