Best practices for direct hardware programming ?

[weiju]

Hi,

when I programmed the Amiga the first time around, I always had been using it with the operating system turned on. I was now interested into poking into the hardware registers directly. Since I often read about that you have to deactivate the operating system, I was wondering what would be the best approach to do that so I can still do something like starting the program from DOS, work directly on the hardware and after exiting, I can continue using the system again. Do I really have to deactivate everything (e.g. Exec and DOS) or only parts ?

Thanks,

Wei-ju

[pmc]

I tend to forbid multitasking (ie. take over the whole system) and save the state of the essential bits of the system so that I can restore them before permitting multitasking again. This seems to work fine for me - my code works on most systems I've ever tried it on.

You'll need to save things like, the system copper list addresses, the state of the any dma and interrupt registers etc. etc. If you want startup code I can give you some, or there are others out there who can too (Hi Stinger )

There are cleaner ways to take over the system than I use though which, as someone who normally does their code with the OS enabled, you might find more to your taste.

See here: http://www.mways.co.uk/amiga/howtoco...tupandexit.php
and here: http://www.mways.co.uk/amiga/howtoco...ce/startup.asm

[freehand]

I used to go in with all guns blazing and just save a handful of states copper list e.t.c but just recently i wish to show some peeps my uridum soft-scroll routine so i have cleaned it up a little, all so i have taken a snippet of code from some guy called stingray so people can few on the 1200.

[pmc]

Originally Posted by freehand

from some guy called stingray

LOL

[Geijer]

The problem with taking over the system totally is that you can not load data from hard drive, the days of trackdisk loading routines are unfortunantely over
I need a good way to bang the hardware and still load data from the hard drive or is it best practice to use "loading scenes" where the system is temporarily enabled.
(let me know if you think I am stealing your thread)

[pmc]

@ Geijer - check the first link I posted above: quoting directly from the page it links to:

Instead of using Forbid() and Permit() to prevent the OS stealing time from your code, you could put your demo or game at a high task priority.

Now, only essential system activity will dare to steal time from your code. This means you can now carry on using dos.library to load files from hard drives, CD-ROM, etc, while your code is running.

[weiju]

Thanks for the advice and pointers, I'll probably try both the Forbid()/Permit() and the high-priority approach. Another interesting thing to know would be memory allocation. Do you allocate all your mem at the beginning (before Forbid()) and use that for the entire runtime of the program or rather allocate on the fly ?

[pmc]

Personally, I don't really allocate memory at all. Instead, I just ask the assembler to reserve memory in my code for my use.

For example, if I wanted to have space for a standard 320*256 bitplane I would usually do something like:

bitplane:           dcb.b               10240,0

Then, at run time, I can just use this space as bitplane data.

[Photon]

With regards to the original question, it's really a decision whether you want/need to have the system on [all the time in the background] or not.

If you're doing a system-friendly utility or game, the answer is obviously yes. If you're doing a regular demo or game and need full CPU time to make sure it runs as smooth as possible, the answer's as obviously no.

If yes, then you're already there, nothing special needs to be done, just write the library code from scratch.

If no, then there are plenty of simple Startup Routines that you could use. You can use libraries while the system is on, and some parts even when the system is off.

System off really only means disabling some interrupts, not shutting it down completely and removing it from memory.

You can turn the system on and off for portions of your program, such as 'in-game' (off) and 'loading files' (on). You need to switch the system on and off wisely (ie. not while the OS finishes a write of file to disk) and correctly, but there's nothing stopping you from doing it anytime you like. If you catch my drift.

There's no real need for Forbid/Permit on original HW/OS [in order to manage system on/off], I never use it. But you WILL need to lock/alloc/own resources shared by the system, even if the system is off, if you plan to return to the OS that is. Ie. alloc memory, OwnBlit etc.

[Minuous]

Originally Posted by pmc

Personally, I don't really allocate memory at all. Instead, I just ask the assembler to reserve memory in my code for my use.

For example, if I wanted to have space for a standard 320*256 bitplane I would usually do something like:

bitplane:           dcb.b               10240,0

Then, at run time, I can just use this space as bitplane data.

Wouldn't this be better as ds.b? Won't dcb.b bloat the size of the executable?

[pmc]

Minuous: Same difference. Using ds.b still makes 10240 bytes of space available.

To test, assemble just dcb.b 10240,0 or ds.b 10240 - either way, size of assembled code: 10240 bytes

Also remember that, for this example, any cruncher is going to squeeze 10240 contiguous bytes of 0's down to virtually nothing.

[StingRay]

Originally Posted by Minuous

Wouldn't this be better as ds.b? Won't dcb.b bloat the size of the executable?

Depends where you use it. Outside of a BBS section, ds.b and dcb.b is exactly the same, the size of the allocated memory will be added to the executable. In a BSS section (where you can only use ds.b) only the size of the allocated memory will be stored (hunk header), i.e. size of the executable won't change except for the entries in the hunk header.

Originally Posted by weiju

Thanks for the advice and pointers, I'll probably try both the Forbid()/Permit() and the high-priority approach.

The high priority approach is rather pointless IMHO. Either you want to kill the system or you don't. That's just my opinion anyway, I never liked that approach. And you can load files even with disabled system, you just need to make sure that you re-enable the ports/timers interrupt before loading a file. I can post the code of my file loader that uses exactly this approach if you want. But try to do it yourself first.

[pmc]

Nice one for that explanation Stinger - I learned something new today

[Photon]

I type too much, Stingray summarizes my post nicely: just decide if and when you want the system off. This can be tricky to know if you're new or unfamiliar with such practices of course, but I hope my longer post gives some tips on how to know when turning off the system is useful. Either way, turn it off by disabling ints like all the proven startup sources do.

[Leffmann]

I would disable multitasking, suppress all requesters and add an input handler with highest priority that just returns 0. This way your code runs almost exclusively on the system, you've full control over the screen and you've got file I/O, and any mouse clicks, keyboard presses and other user input will not reach the Workbench to possibly glitch something up.

This sort of game and demo programming is a bit like a realtime system where you want to control exactly what code runs and when, so from here you can also prevent the system interrupts from running by just disabling them or removing them from the interrupt chain, and temporarily enable them again whenever you need file I/O.

Originally Posted by StingRay

Depends where you use it. Outside of a BBS section, ds.b and dcb.b is exactly the same, the size of the allocated memory will be added to the executable. In a BSS section (where you can only use ds.b) only the size of the allocated memory will be stored (hunk header), i.e. size of the executable won't change except for the entries in the hunk header.

Actually that's not entirely correct, the allocate size of a hunk can be different from the size of its contents in the file. It's possible to f.ex have a 10K executable load into 20K of allocated space.

[pmc]

I have a question. As a test, I did this:

                    section             data,bss
bitplane:           dcb.b               10240,0

Which assembled with no errors and a code size of 10240 bytes.

I also did this:

                    section             data,bss
bitplane:           ds.b                10240

Which again assembled with no errors but again with a code size of 10240 bytes.

Now, bearing in mind this:

Originally Posted by StingRay

Outside of a BBS section, ds.b and dcb.b is exactly the same, the size of the allocated memory will be added to the executable. In a BSS section (where you can only use ds.b) only the size of the allocated memory will be stored (hunk header), i.e. size of the executable won't change except for the entries in the hunk header.

I would've expected to get an error for using dcb.b on the first test and a code size of 0 on the second test. Or have I missed something or done something wrong...?

[Lonewolf10]

Originally Posted by pmc

I would've expected to get an error for using dcb.b on the first test and a code size of 0 on the second test. Or have I missed something or done something wrong...?

Did you turn off optomisations and such-like? Theres a good chance that Devpac (or whatever you are using) has corrected it without telling you.


Regards,
Lonewolf10

[pmc]

No, no optimisations enabled.

[StingRay]

Originally Posted by Leffmann

Actually that's not entirely correct, the allocate size of a hunk can be different from the size of its contents in the file. It's possible to f.ex have a 10K executable load into 20K of allocated space.

What I wrote is completely correct. The question was about ds.b vs. dcb.b and what happens to the executable size. That there are lots of other ways to deal with hunks is irrevelant here.

Originally Posted by pmc

I would've expected to get an error for using dcb.b on the first test and a code size of 0 on the second test. Or have I missed something or done something wrong...?

My guess is that Devpac silently removed the BSS section (maybe because there wasn't any code?), check the executable in a disassembler. dcb.b doesn't make sense in a BSS section because BSS data is uninitialised, i.e. dcb.b 10240,$ff won't work in a BSS section. BSS = B.lock S.torage S.ection and ds.b = d.efine s.torage. dcb = d.efine c.onstant b.lock which, as said, won't make sense in a BSS section.

[pmc]

You're right Stinger - Devpac was silently substituting dcb.b for ds.b on assembly.

Assembled size as reported by Devpac is 10240 bytes but the size on disk is 108 bytes.

I *hate* it when it does things like that. It should at least warn about the fact it's making a substitution!

[Leffmann]

Originally Posted by StingRay

What I wrote is completely correct. The question was about ds.b vs. dcb.b and what happens to the executable size. That there are lots of other ways to deal with hunks is irrevelant here.

Except that it's not correct.

AmigaOS has always had support for uninitialized space in executables not just as BSS (the correct meaning is Block Started by Symbol) but after any code and data as well.

Corresponding source and 48 byte executable below, try it yourself and check memory usage while it's running.

wait   btst   #6, $bfe001
       bne    wait
       rts

       ds.b   1000000

[pmc]

While I'm about and I think of it - is there a best single resource for learning more about the OS and how it functions and file loading / hunks etc. etc.

It's the stuff I know least about - I understand the hardware fairly well I think but not the OS and how to interact with it or how it itself interacts with the hardware.

That's probably a very stupid question and more than likely I'll be admonished to look at RKRM Libraries & Devices or Includes & Autodocs or something but I've got those books and to be honest I find them to be a little too "C-centric" for my tastes. Any decent docs / tutorials about that explain this stuff nicely in an assembly language context...?

[StingRay]

Originally Posted by Leffmann

Except that it's not correct.

What I wrote is perfectly correct as much you dislike it. That I didn't mention every OS detail to keep things simple doesn't automatically mean it's incorrect what I wrote.

Originally Posted by Leffmann

AmigaOS has always had support for uninitialized space in executables not just as BSS

Did I write the opposite anywhere in this thread?

Originally Posted by Leffmann

(the correct meaning is Block Started by Symbol)

That's not the "correct" meaning. But since it's quite pointless to discuss this (and won't help anyone here in this thread) I'll just say that all you wrote here is correct and everything I wrote is incorrect so you'll be happy.

[h0ffman]

Hey stinger, so with the loading from hard drive, I could have complete control of the system, copper, blitter etc. As long at the port timer int is reactivAted, it will work. As thats a level two int, I take it running that with a CIA music timer at the same time is goon to cause an issue? Or am I thinking of a level 3 int?

[phx]

Originally Posted by StingRay

In a BSS section (where you can only use ds.b)

That's an interesting question, BTW. Should it be disallowed to use anything but DS in a BSS section? I made no such restriction in vasm, so all directives are allowed, but just their size is recognized. The contents is lost as everything will turn to zero.

For example AsmOne will also accept DCB with a nonzero contents (like vasm), while Devpac doesn't allow DCB, just DS. What is most compatible?

Probably to allow everything, to make all sources assemble...?

[phx]

Originally Posted by Leffmann

AmigaOS has always had support for uninitialized space in executables not just as BSS (the correct meaning is Block Started by Symbol) but after any code and data as well.

That's true. Important to know is that this area (I often call it a data-bss section), is only cleared beginning with Kickstart 2.0. Before you had to clear it yourself.

BTW, this feature is quite common in other file formats as well (e.g. ELF).

[Nut]

Originally Posted by Geijer

The problem with taking over the system totally is that you can not load data from hard drive, the days of trackdisk loading routines are unfortunantely over
I need a good way to bang the hardware and still load data from the hard drive or is it best practice to use "loading scenes" where the system is temporarily enabled.
(let me know if you think I am stealing your thread)

Disable level6 interrupt. That will disable system. When you need to load something enable I/O and level3 (needed for blitter, disk loading uses blitter). After you've loaded you can disable I/O and replace level3 vector for your own again. I never attach my vectors to system the proper way. I just change the vectors on the fly. Needless to say my programs don't multitask.

If you don't use blitter yourself then you can do your own level3 interrupt routine which checks if it was blitter that called, and in that case traps the system level3 vector. So you don't necessarily have to shuffle I/O and level3 all the time. You can keep them ON all times this way.

Or you can do stuff the proper way. But that's not cool

[Wepl]

Originally Posted by weiju

Hi,

when I programmed the Amiga the first time around, I always had been using it with the operating system turned on. I was now interested into poking into the hardware registers directly. Since I often read about that you have to deactivate the operating system, I was wondering what would be the best approach to do that so I can still do something like starting the program from DOS, work directly on the hardware and after exiting, I can continue using the system again. Do I really have to deactivate everything (e.g. Exec and DOS) or only parts ?

For starting developing hardware related code I can recommend WHDLoad. You will get disable/restore of the system, simple api to load/save files and if you have an mmu many valuable debugging support like memory protection, custom/cia register snoop/check and more.
If you want to release it without WHDLoad later you could encapsulate the api-calls using macros.