startup/system takeover

Hello,

I'm in need of some assistance in taking over my Amiga from the OS so that I can bang the hell out of the hardware. I'd like to do this in as kind a way as possible for the poor OS, since I'd like it to remain friendly after I'm done abusing it.

My current idea is to save the current machine state (all the CPU and custom registers) and the restore them when I'm completed. What else do I need to worry about?

Is there already well used startup code that does this?

Thanks.

[Nostalgeek]

Hi sidewinder and welcome!


Yup, that's exactly what you should do.

Here's a snippet from one of this board's Gurus:

Originally Posted by Stingray

Correct way to do it is like this:
- store current DMACON settings (read register DMACONR, $dff002) so you can
- write this value back to DMACON ($dff096) upon exit (don't forget to set BIT #15 (SET/CLR) before)

I don't give any code example because it is a good exercise for you to do it yourself.

Give the Hardware Reference Manual a read about these registers ($DFF002 aka DMACONR and $DFF096 aka DMACON) and you should be ready to get started!

An online HRM as well as other useful docs can be found on elowar's great website:

http://amigadev.elowar.com/

Then don't ask me much more, because I'm still a total beginner trying to learn, but if you have any question feel free to post, there's a lot of experts willing to help! The only rule is "think first, then ask" nobody likes to give straight solutions, but they will be more than pleased to give you hints to find the solution yourself!


Good luck and have fun with your coding!

[Lonewolf10]

If you intend to use interrupts (I intend to in my demo, purely for the music) you also need to save INTENAR ($DFF01C) to write the value back to INTENA ($DFF09A) when you are done.

If you are writing a demo, then you don't need to worry about this as many demo's don't allow you to exit them (presumably to help against hacking images and code that may otherwise remain in memory).

My demo currently disables interrupts on start-up and enables them on exiting. I haven't got far, just about halfway through doing the title screen!


Regards,
Lonewolf10

[Plagueis/KRX]

Well, whether you write your own startup routine or learn by studying a piece of source, I wish both of you luck in your first demo project. I too am working on mine at the moment...as soon as it's finished I will release it here first. I'm often delayed by my participation in the c64 scene...which is huge. But this time I plan on really setting aside as much time as it takes for my Amiga projects.

[StingRay]

Originally Posted by sidewinder

My current idea is to save the current machine state (all the CPU and custom registers) and the restore them when I'm completed. What else do I need to worry about?

The idea is correct. What you need to do is this:

- save current view and flush it so your code will work from non-native screen modes too (think graphics cards)
- store the system copperlists so you can restore them later
- if you want to use interrupts, check if your code is runnning on a CPU >68000, if so get the VBR (v.ector b.ase r.egister) since IRQ vectors can be relocated, i.e. they don't start at $0 anymore
- store custom regs (INTENA, DMACON, ADKCON

I'll attach my ministartup code which does all that, feel free to use/modify it.

Originally Posted by Lonewolf10

If you are writing a demo, then you don't need to worry about this as many demo's don't allow you to exit them (presumably to help against hacking images and code that may otherwise remain in memory).

I'm sorry but this is 1988 style! Nowadays almost all demos exit cleanly to DOS so saying "you don't have to worry about this" is simply wrong.

Thanks everyone for the great tips and responses.

@Lonewolf10 - Yes, I intend to use interrupts, so your advice is well taken.

@StingRay - Thanks for the example code, that certainly helps clarify a number of things. One questions though. Why do you only save the 3rd interrupt autovector?

[musashi5150]

Writing a good, solid demo shell is a rite of passage for every Amiga coder While trying to get it working you will learn so much - its an invaluable experience. IMHO it would be best to work the basics out for yourself and then take a peek at others code for refinement later once its pretty much there.

Yes, you may get going quicker by "borrowing" someone elses shell, but in the long run I dont think you are doing yourself any favours

[StingRay]

Originally Posted by sidewinder

Why do you only save the 3rd interrupt autovector?

Because I only use the Level3 (VBI) irq there, thus no need to save other interrupt vectors. Since this is my mini-startup it only does the really necessary things, I usually use my full-blown demo OS which stores/restores all used interrupt vectors automagically.

Originally Posted by musashi5150

Yes, you may get going quicker by "borrowing" someone elses shell, but in the long run I dont think you are doing yourself any favours

I totally agree. However, when it comes to coding system takeover/restores routines I'll make an exception. It's quite a boring task to code things like these so using someone else's code is OK for the beginning. Sooner or later you'll code your own system anyway.

[Lonewolf10]

Originally Posted by StingRay

I totally agree. However, when it comes to coding system takeover/restores routines I'll make an exception. It's quite a boring task to code things like these so using someone else's code is OK for the beginning. Sooner or later you'll code your own system anyway.

I agree, creating your own code means you know what it does and how it does it. I have borrowed some code from the Danish Assembly Course (see appropriate thread in Coders Tutorials forum) to turn off the disk drive motors, as the first thing I do is turn off interrupts. My question is, does this code work and how can I test any disk drive operations as all I have is WinUAE at present? (Both my A600's are down still)

    move.w    #$4000,$dff09a        ;INTENA, disable interrupts
    or.b    #%10000000,$BFD100    ;as interrupts are off, we manually
    and.b    #%10000111,$BFD100    ;switch off disk drive motor

Regards,
Lonewolf10

[pmc]

Originally Posted by Lonewolf10

how can I test any disk drive operations as all I have is WinUAE at present? (Both my A600's are down still)

WinUAE emulates the disk drives and disks just fine so you can definitely use WinUAE to test that your drive routines work. Just make an .adf and use that as your disk for testing read / write operations, moving the drive heads etc.

When I did a trackloader I did the whole thing using WinUAE to test - bonus is no real disk or drives to kill if your code does any weird stuff at first.

[Plagueis/KRX]

Originally Posted by musashi5150

Writing a good, solid demo shell is a rite of passage for every Amiga coder While trying to get it working you will learn so much - its an invaluable experience. IMHO it would be best to work the basics out for yourself and then take a peek at others code for refinement later once its pretty much there.

Yes, you may get going quicker by "borrowing" someone elses shell, but in the long run I dont think you are doing yourself any favours

Well, PMC was generous enough to lend me his shell around this same time last year...the first time I started playing with the 68K and the Amiga's chipset. It's a rather full blown demo shell, and is based largely on things Paul learned from Stingray. To me, at the time it seemed huge and bloated and understanding it 100% looked like a rather intimidating task. I've also done things like copper bars and displaying bitplanes just with the bare minimum (and I know, not compatible) method of stopping multitasking, and then slamming my own copperlist in.

I can't help but wonder if relying on PMC's shell has done a little damage to me, in that I have been making small tweaks and changes to his shell if I need to set up sprite pointers, or change BPLCON or something similar. Because it may have kept me from seeing the big picture of what happens in the chipset as the frame is being drawn from the VBL to the last PAL line. However, if it did stunt my comprehension, I think I am now starting to recover, and the only way to fully get over that first hill is through playing with code, experimenting with the registers, and re-reading the HRM and the PDF of register info that Photon gave me.

I do think though, that if the other beginners are anything like me, in retrospect, a smaller more condensed shell is probably the way to go, since if you need to add more interrupts and more functionality...you will be forced to code it yourself and you'll understand at least that part already. Plus out of the box, the smaller shell is easier to take in and comprehend as a whole.

One last thing...on WinUAE I've been using Devpac, but on my A500 (which unfortunately is NTSC) I use AsmOne 1.06. Stingray, do I need an include file in order to assemble your shell? Or do I need to use 1.48?

EDIT: Well...2nd thought a lot of the uses of the registers are coming back to me, plus I'm glad that PMC shows how to set up a copper interrupt in his shell. Part of this was from walking away for around a year and then trying to come right back into it. After this/last week's work, I'm really feeling more confident that I will be able to put all the pieces for an intro together very soon. It could come even sooner if I wussed out and did a CPU only scroller, but I don't think that's the thing to do. I've been advised by most coders that I'll be better off on the Amiga if I dive right into the blitter. So far I've only used a straight copy from src A to dest D to slap some pre filled data onto the screen. So all I need to do is extend that to a cset I guess. The rest is just figuring out modulos, shifts and masks.

[Wepl]

you could use whdload for this, SCNR

[Asman]

I know it a bit rusty thread but I have some question(s).
1. Is it necessary to store copperlists ( $26 and $32 offsets in GfxBase) or is enough to save current view, display no view (LoadView(0)) and later (when enabling) do LoadView(oldView) ?

I think that LoadView(oldView) should also set copperlists, or I'm missing something ?

Edit: I forget to ask about storing the intreqr.

2. Should I store current intreq or is enough to store current intena ?

3. Also I think that is not necessary to wait for vblank before we stop ints and dma because just few instructione earlier we do gfx WaitTOF, right ?

Edit2:
I just checked my question number 1 and is necessary to store copperlists. What a day I should first check and then ask questions

Edit3:
4. For what we should store gb_LOFlist (offset $32 in gfxBase ) as second copperlist ? I checked and is enough to just set value from gb_copinit (offset $26 in GfxBase) to cop1lc. Can someone explain or give me example when we should set second copperlist with value from gb_LOFlist ? Thank you.

[meynaf]

Originally Posted by Asman

2. Should I store current intreq or is enough to store current intena ?

I personnally would only store intena. I would even clear current intreq both at entry and upon exit.

[Wepl]

You should do LoadView(NULL) then wait for vblank before doing direct access to gfx custom registers.
To renable copy gb_copinit to cop1lc and wait for vblank.

[jotd]

Taking down properly a "modern" system with MMU active is not that easy. I had trouble with JST on high-end systems until Ralf implemented MMU (something like zero page relocation).
Regardess of MMU, save DMA/INTENA/ADK... all control registers + the CIAs (check JST source code for SaveCIARegs/RestoreCIARegs) + VBR + system copperlist.

I first thought of WHDLoad myself. But a demo would like to start without any other extra program.