Best practices for direct hardware programming ?

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