ASM: why "banging the metal"?

[jman]

Hello,

while I'm waiting for some spare time to start up again the Amiga emulator o_0 I was thinking about the last bit of (huge) help provided by Stingray concerning the startup code needed in order to have something to work reliably while banging the "metal" (btw thanks again to everyone for your ever useful contributions).

When I started fiddling with ASM I said to myself - no custom chip hitting, I'd like to understand how things work without ending up hacking the hardware (I'm think I'm no experienced programmer for such a task). Nonetheless I've found myself doing it that way.

To be honest, manually fiddling with the hardware is *fun*, but back in the day, did really any game developer did it what way?

My question (after this boring stream of conscience): is there an alternate way to program the Amiga in ASM without resorting to manually defined copperlists and strobe register triggering?

Thanks for whoever would like to share his thoughts on this topic and please excuse my naive question in advance.

[Thorham]

Originally Posted by jman

To be honest, manually fiddling with the hardware is *fun*, but back in the day, did really any game developer did it what way?

Most commercial games shut down the OS and bang the hardware. It's a good way to ensure games work properly on unexpanded machines. It basically used to be the norm.

Originally Posted by jman

My question (after this boring stream of conscience): is there an alternate way to program the Amiga in ASM without resorting to manually defined copperlists and strobe register triggering?

Yes, you can use the OS routines to do things such as open a screen. You can then access the screen memory directly for good performance, instead of using the OS graphics routines (do this properly, and it's certainly not hacking of any sorts).

You can take a look at the Rom Kernel Reference Manual here: Amiga Developer Docs

To do this properly, you'll need the right include files. I can upload them to the zone for you if you want.

[Lonewolf10]

I think shutting down the OS (in a friendly manner) and banging the hardware directly is the best way to ensure your game/demo/whatever runs as expected with no hiccups.

Running software whilst the OS (and other OS based software) is running in the background ensures that not only will your program not always perform as desired, but it will make debugging a nightmare. Sure, it'll work as desired on your machine, but I'd guarantee that others will find ways to break your software. One example is that I have trouble running Octamed 5 on Workbench 2.05, sometimes it runs ok and others it starts to run and then crashes. That's probably the main reason why I haven't composed any music since 2007 (err...I'm no musician, just one 'tune' so far - Jungle Beat, available on Aminet).

There are so many good/bad software out there that you can't ensure your software works as desired without taking over your target Amiga(s).


Regards,
Lonewolf10

[Thorham]

For demos it's perhaps good enough to bang the metal, but for games and applications it's not, in my opinion. Writing OS software simply has to be done properly. If some program breaks your properly written code, then it's because the offending program does things it shouldn't. Not at all a reason to sacrifice using the OS.

Using the OS for the basic setup and IO, means you don't have to rely on hacky routines, and this is much preferable. Just try to get proper file system access while the OS has been shut off. You now have to turn it back on again, access the file system and then turn it back off. A huge pain, and a truely crappy way of doing things. Not to mention you can't do anything else with your machine.

It's time people started to forget about banging the metal, and write their software using the OS (not using the crappy graphics routines, of course ).

[jman]

Originally Posted by Thorham

To do this properly, you'll need the right include files. I can upload them to the zone for you if you want.

Hi Thoram,

thanks for your thoughts.
I'm afraid that what you say hides the fact that many Amiga developers back then weren't able to figure out how to program a real multitasking machine that was too permissive (until the 68010 at least), thus all that conflicting software, thus more people using exclusively the hardware, thus no forward compatibility, thus etc. etc.
This said, squeezing the hardware for that last CPU cycle is a clever way when one may want to overcome the machine's limit. And it's fun.

Now concerning the files, I have the 3.1 sdk. It should contain all that is needed, right? If not, which files are you talking about?

thanks

[Thorham]

Originally Posted by jman

I'm afraid that what you say hides the fact that many Amiga developers back then weren't able to figure out how to program a real multitasking machine that was too permissive (until the 68010 at least), thus all that conflicting software, thus more people using exclusively the hardware, thus no forward compatibility, thus etc. etc.

Really? When you have the right documentation it's not so difficult.

Originally Posted by jman

This said, squeezing the hardware for that last CPU cycle is a clever way when one may want to overcome the machine's limit. And it's fun.

And probably necessary for machines such as the A500 without a faster CPU.

Originally Posted by jman

Now concerning the files, I have the 3.1 sdk. It should contain all that is needed, right? If not, which files are you talking about?

If you have that, then there may still be missing LVO includes (missing on purpose ). I've asked about this, and using separate LVO includes is easiest way. They're in the zone, and you can just put the directory in the include directory.

[jman]

Originally Posted by Thorham

Really? When you have the right documentation it's not so difficult.
And probably necessary for machines such as the A500 without a faster CPU.
If you have that, then there may still be missing LVO includes (missing on purpose ). I've asked about this, and using separate LVO includes is easiest way. They're in the zone, and you can just put the directory in the include directory.

Oh, ok silly me, those files are more or less the same of the "Includes" disk of Devpac I use. Funny how those were distributed by third party publishers rather than C= itself. A quick googling around shows that you had your share of head scratch too (http://goo.gl/aohjg).

Thanks!

[hitchhikr]

Arcade games were primary made in asm with direct hardware access (a game like sidewinder is mostly using the os libraries but use OwnBlitter/DisownBlitter functions prior and after accessing the blitter directly), more ambitious software like simulations or RPGs etc, were made in C with use of system libraries (that's slower than hw access especially on 68000 machines and it can be a bit tricky to understand how the graphics.library works at first but once you made your wrapper functions it's just a breeze).

I find the "Programmers Guide to the Amiga" book by Robert Peck relatively clear & well made regarding the matter of using system libraries to program a game.