Non OS friendly C and other stuff...

[MrZammler]

Hi,

I'm trying to wrap my head around how some things work, and could use some guidance. I'm tinkering with some non os friendly C code, but this subject seems to not be as widespread as asm. Sadly my asm understanding is very low.

Right now (based on other peoples source), I can "close" the os and take over the machine as soon as it boots. Poking a color register I can turn the background black, and that's that. Nothing much, but a small win for me. :-) I stopped there and started reading.

So, let's say one would like to program a *ahem* game with C and non OS functions.

There should be a loop where everything happens:

<pre>
while(!end_game)
{
DoStuff();
}
</pre>

1) How do you check the keyboard? I know the data is on CIAA on ciasdr register. I can take a look there, and get the raw keycode. So with some tinkering, I can get a function on the loop to check the register contents at each loop. Seems to work, and I can get the keys. However, I feel it's not the best solution. Do I need to setup my own interrupt (level 2?) handler to manage it, or would the simpler solution do? I assume that when I have an interrupt handler, it will get called each time a keyboard interrupt fires, and then I can go on my way (no "CheckKeyb()" in the loop). Would I then have enough 68000 time to do things?

2) On the loop itself: Does it need to wait for a scanline to reach the end of the display and then "DoStuff()" ? Or any other way to sync on the display? Otherwise the same loop would run much fuster on say an 020 vs a 00, right? I think I saw somewhere that copper could be setup to raise an interrupt when it reaches a specific line, and that could be used as a "Delay" function?

3) The copper. Read a bit, but can't really tell where it fits on the big picture. You basically load it with a copperlist (ie. a copper program) using the only three commands (MOVE, WAIT, SKIP). Does it always run? Does it always need to do something?

4) Besides the Amiga Hardware Reference Manual, and the RKMs, are there any other books in a "guide" rather than reference format? AHRM seems great for e.g. Hardware playfields, but totally lost it with the copper chapter.

6) Am I mad for trying these with C?

Sorry if these sound dumb.
Many thanks.

[kamelito]

You can look at Deluxe Paint I source code to see how the Blitter is used by banging the HW for a start. (http://www.computerhistory.org/atchm...y-source-code/)
Yoy can also check how does perform a demo using the graphics.library an C : https://github.com/voitureblanche/projet-secret

You can also look at the Star Frontiers demo there : http://ftp.amigascne.org/pub/amiga/G...QuarkDemo1.lha
Kamelito

[kamelito]

Example from Aminet to read joystick

http://aminet.net/dev/src/joystick.lha

Kamelito

[meynaf]

Originally Posted by MrZammler

1) How do you check the keyboard? I know the data is on CIAA on ciasdr register. I can take a look there, and get the raw keycode. So with some tinkering, I can get a function on the loop to check the register contents at each loop. Seems to work, and I can get the keys. However, I feel it's not the best solution. Do I need to setup my own interrupt (level 2?) handler to manage it, or would the simpler solution do? I assume that when I have an interrupt handler, it will get called each time a keyboard interrupt fires, and then I can go on my way (no "CheckKeyb()" in the loop). Would I then have enough 68000 time to do things?

Interrupts are more tricky to do in C than in ASM. Personnally i would stick to some simple CheckKeyb() - at least for a start.
What's sure is that you won't overload a 68000 with that.

Originally Posted by MrZammler

2) On the loop itself: Does it need to wait for a scanline to reach the end of the display and then "DoStuff()" ? Or any other way to sync on the display? Otherwise the same loop would run much fuster on say an 020 vs a 00, right? I think I saw somewhere that copper could be setup to raise an interrupt when it reaches a specific line, and that could be used as a "Delay" function?

The copper can trigger an interrupt. Or you can use the vertical blank interrupt.
Otherwise, indeed, the loop will run faster on 020 than 000.

Originally Posted by MrZammler

3) The copper. Read a bit, but can't really tell where it fits on the big picture. You basically load it with a copperlist (ie. a copper program) using the only three commands (MOVE, WAIT, SKIP). Does it always run? Does it always need to do something?

The copper doesn't always run. Nor is it absolutely necessary to let it run.
It will be stopped if its DMA channel is turned off. It will also do nothing while in a WAIT instruction, the end of a copperlist being a special form of WAIT.
Its program is automatically restarted at each vblank, and it can also be started manually.

Originally Posted by MrZammler

6) Am I mad for trying these with C?

Yes
But if you like it just do it

[xArtx]

Of course if you launch it from Workbench the hardware will catch fire

Just wanted to also thank for the information. The links there, I never knew existed.

[phx]

Originally Posted by MrZammler

Right now (based on other peoples source), I can "close" the os and take over the machine as soon as it boots.

When you cannot read the numerous example startup-codes in assembler, make sure to take over the machine in the correct way, which works on all models (with and without RTG). Basically it's this:

1. Open graphics.library: Load a NULL-View: LoadView(NULL); WaitTOF(); WaitTOF();
2. Get the blitter: OwnBlitter(); WaitBlit();
3. Disable all interrupts (custom->intena=0x7fff). Disable all DMA (custom->dmacon=0x7fff). Disarm the mouse sprite.
4. Disable AGA or ECS features, when not needed. Set FMODE.
5. Set up your own display and interrupt vectors.

Everything can be done in C. You might need a small assembler stub to determine the VBR on 68010+ systems (movec vbr,d0), which you need as a base to write new interrupt vectors.

1) How do you check the keyboard? I know the data is on CIAA on ciasdr register. I can take a look there, and get the raw keycode.

Probably that works because you didn't take over the system completely (interrupts). Don't forget that you have to do handshaking (set CIA-A SP to output for about 100us) with the keyboard controller.

Do I need to setup my own interrupt (level 2?) handler to manage it, or would the simpler solution do?

I would recommend that.

Although interrupts in C are compiler specific and even impossible with some. An M68k interrupt function ends with an RTI (return from interrupt) instruction and not with an RTS (return from subroutine), which a compiler usually generates.

Some compilers offer a special attribute for such functions, like __interrupt. Otherwise you have to make a small assembler stub routine which you link to the main program.

3) The copper. Read a bit, but can't really tell where it fits on the big picture.

It is difficult to set up a new display without the copper. At least you need it to set the bitplane pointers (BPLxPT), so they are reset to the beginning of your bitmap every new frame.

BTW, you may want to use the hardware/custom.h header file in C, when accessing custom chip registers. Define a pointer to the custom chip base:

#include <hardware/custom.h>
volatile struct Custom *custom = (struct Custom *)0xdff000;

Then you can access the hardware with, for example, custom->color[0] = 0xfff;

6) Am I mad for trying these with C?

Not really. The results will be quite close to average assembler code.
C is just a very comfortable macro assembler.

It is not uncommon to write larger parts of a game in C. Look at Lazycow's Powerglove, for example.

[MrZammler]

Woah, guys, many thanks for your answers. Will need some time to digest all this, esp. the source codes.

@phx

Indeed, I'm using the stuff under hardware/custom.h.

Thanks!