Startup code, taking over the system

[deimos]

So, I've decided the startup code I've been using is not the best. Is there an accepted standard piece of code that everyone is using to take over and return the system?

For context, this is what I'm currently using:

void TakeSystem(void) {
    KPrintF("In TakeSystem.\n");

    AndTen();

    ActiView = GfxBase->ActiView; // store current view

    OwnBlitter();
    WaitBlit();

    Disable();
    
    systemADKCON = custom->adkconr;
    systemINTENA = custom->intenar;
    systemDMACON = custom->dmaconr;

    custom->intena = INTF_INTEN | INTF_ALL; // disable all interrupts
    custom->intreq = INTF_INTEN | INTF_ALL; // clear any interrupts that were pending
    
    WaitVbl();
    WaitVbl();

    custom->dmacon = DMAF_SPRITE;

    LoadView(NULL);

    WaitTOF();
    WaitTOF();

    WaitVbl();
    WaitVbl();

    // save system interrupt handers
    for (int i = 0; i < 6; i++)
        systemInterruptHandlers[i] = VBR[25 + i];

    WaitVbl();
    
    custom->intena = INTF_INTEN | INTF_ALL; // disable all interrupts
    custom->intreq = INTF_INTEN | INTF_ALL; // clear any interrupts that were pending
}

Obviously I'm into C at the moment, I'll probably translate any assembly into that.

[phx]

Looks good so far, although I don't know why you disable interrupts twice.

Additionally you may want to reset FMODE and BPLCONx to standard values, in case you have to disable AGA/ECS.

[deimos]

Originally Posted by phx

Looks good so far, although I don't know why you disable interrupts twice.

Additionally you may want to reset FMODE and BPLCONx to standard values, in case you have to disable AGA/ECS.

I disabled them twice because LoadView(NULL) seemed to reenable the VERTB interupt. That's something I need to check again.

I'll add the code to reset FMODE and BPLCONx.

[Toni Wilen]

Don't disable interrupts before calling waittof() or loadview(). It most likely causes a hang if system has active RTG board that use hardware vertical blank interrupts.

[deimos]

Originally Posted by Toni Wilen

Don't disable interrupts before calling waittof() or loadview(). It most likely causes a hang if system has active RTG board that use hardware vertical blank interrupts.

Do I even need to call LoadView(NULL) if the first thing I'm going to do is disable interrupts and load my own copperlist?

[ross]

Originally Posted by deimos

Do I even need to call LoadView(NULL) if the first thing I'm going to do is disable interrupts and load my own copperlist?

Sure. How could you switch from a graphics card to the default chipset video output?

[Toni Wilen]

Yeah, without LoadView(NULL) RTG mode stays active, unless you have separate monitor connected to Amiga's built-in video out. And even if you have separate monitor, native refresh rate may not be standard PAL or NTSC without LoadView(NULL).

Something like this should be safe:

Forbid() (so that no other task can change graphics modes etc before interrupts get disabled)
loadview/waittof stuff
OwnBlitter()
WaitBlitter()
Disable interrupts

the rest

Enable interrupts
DisownBlitter()
loadview back to original
Permit()

[ross]

Originally Posted by Toni Wilen

Forbid() (so that no other task can change graphics modes etc before interrupts get disabled)
loadview/waittof stuff
OwnBlitter()
WaitBlitter()
Disable interrupts

the rest

Enable interrupts
DisownBlitter()
loadview back to original
Permit()

I was wondering.. Is OwnBlitter() essential?

What are the possible contraindications to use this?:

Forbid()
loadview / waittof stuff
Disable interrupts
myWaitBlitter()

Yes, it's a simple call that certainly doesn't hurt, it's just curiosity

EDIT: hmm, perhaps the answer is simple, another process that has a blitter-chain that absolutely cannot be interrupted, under penalty of data corruption
the partial results are always valid, unless we refer to pre-set and shared registers between operations

[a4k-oerx]

The CD32 Developer Notes (pdf at kaiiv.de) have hints on what to use when and why e.g. Q4 page 91 "Which of the following ... can we safely take over and hit directly?"

[hooverphonique]

Originally Posted by deimos

So, I've decided the startup code I've been using is not the best. Is there an accepted standard piece of code that everyone is using to take over and return the system?

Short answer is no - there will be hundreds of variants over the same concepts..

[Hewitson]

Originally Posted by hooverphonique

Short answer is no - there will be hundreds of variants over the same concepts..

Exactly. But as a starting point maybe check out startup code posted by StingRay and/or Photon. Hope this helps.

[Photon]

Here's mine - it's divided into a wrapper and a startup. The wrapper is what turns off and on the OS and the startup starts a template screen once you've take over that you can flesh out and customize as you want - I used to have it as one file, but the reason for the separation into two files is this customization.

So you only need translate the wrapper. It returns to RTG on exit.

It has a few hardcoded offsets to not immediately require dependencies. -222 is LoadView(), -408 is OldOpenLib(), and offset 297 in Exec is to check for 68000, to detect VBR safely.

[deimos]

Originally Posted by Photon

Here's mine - it's divided into a wrapper and a startup. The wrapper is what turns off and on the OS and the startup starts a template screen once you've take over that you can flesh out and customize as you want - I used to have it as one file, but the reason for the separation into two files is this customization.

So you only need translate the wrapper. It returns to RTG on exit.

It has hardcoded offset to not immediately require dependencies. -222 is LoadView(), -408 is OldOpenLib(), and offset 297 in Exec is to check for 68000, which means it's not safe to detect VBR with movec.

Thank you. If I'd known that was there I would have gone straight to it.