PowerPC asm programming

[xeron]

The PowerPC has 32 64bit integr registers, which can be used as 8, 16, 32 or 64bit depending on what you specify with the instruction. They are named R0 to R31.

It also has 32 floating point registers. I can't remember if these are internally 64 or 80bits wide, you'll have to look that up.

There is no "PowerPC equivalent of interrupt 10h". Interrupt 10h is not an "x86" thing, its an "MS-DOS" thing, and the calls to set up displays will be totally different in other operating systems, even under x86.

For setting up and using displays under AmigaOS, may I recommend purchasing the Amiga DevCD v2.1, which contains a lot of documentation for all the Amiga's APIs. Also, consult the developer guide for Picasso96, which will detail things like highcolour and truecolour modes.

I suggest you get some free books from motorola. I can't remember the URL where you order them, but they're totally free including postage.

[xeron]

heh, ok. I sit corrected  :-D

[xeron]

OK OK thats enough corrections I've already admitted to being wrong.

[xeron]

AmigaOS has a dedicated graphics subsystem called, strangly enough, the graphics.library which as a programmer you probably won't need very much. It is more common now to use the GUI system known as the intuition.library. This provides the programmer full graphics functions but keeps them in the context of the GUI, which users and graphics cards like!

Thats not quite true. Intuition.library provides commands for setting up displays and windows, and graphics.library provides the routines for rendering graphics into them. Intuition doesn't, for example, provide text, line drawing, area filling, or other graphics functions. As a programmer, you'll probably use both a lot, unless you go via toolkit such as ReAction or MUI. Even then, if you write custom classes, you'll probably use graphics.library to render them.

In fact, intuition calls graphics.library functions to render its own graphics.

I would also suggest you forget about PPC asm (porting x86 Code to that will be hell) and switch to C which is portable across systems (remember to abstract out the system depandant stuff to allow quicker and easier porting).

To an extent I agree; however I really enjoy assembler programming, and if this guy does too, well, theres nothing wrong with that.

[xeron]

I just prefered to used the inutition library for as much as possible as that allowed me to support graphics cards without modification

That doesn't make any sense! Using graphics.library doesn't exclude graphics cards at all! And there are NO intuition routines for line drawing or filled poly's, THAT is graphics.libraries job!

If you want to draw graphics into a rastport, you use graphics.library. That is what it is for.

[xeron]

Karlos wrote:
Tickly must be climbing the walls by now :lol:

Thats OK.. he can carry on being wrong, it doesn't really matter  :-D Suffice to say that there ARE no graphics drawing routines in intuition.library; it isn't a case of choosing to use graphics.library or intuition.library, as they do different things. If you need to draw graphics, you use graphics.library, if you need to open a window, you use intuition.library. The two are used together. If you want to use highcolour, then you use either cybergraphics.library or Picasso96API.library.

[xeron]

Well, OK, i concede the Intuitext stuff  ;-) but the whole idea that you can use either graphics.library or intuition.library to achieve the same results is a flawed one.

Right, having downloaded and browsed the intuition autodoc (didn't have them to hand at work), intuition provides DrawBorder(), DrawImage() and PrintIText() all of which are only really present to aid the rendering of gadgets, and all of which call graphics.library to do the actual rendering. This hardly makes it a substitute for graphics.library  :-D In fact, you'd be pretty daft to use them for general purpose graphics rendering.

Also, programs using graphics.library do NOT need "modification" to work with graphics cards, otherwise pretty much nothing would work with graphics cards.

[xeron]

(for rendering to windows, not bitmaps..blah..)

Windows have rastports with attached bitmaps. The rastports tell graphics.library how the data is stored in its bitmap. To render graphics into a window, you call graphics.library functions, specifying the windows rastport (usually as the first argument). For example:

[color=006600]
Move( window.rport, win.borderleft+xoffset, win.bordertop+yoffset+font.baseline );
SetAPen( window.rport, obtainedpens[2] );
Text( window.rport, "Hello everyone!", strlen( "Hello everyone!" ) );
[/color]

Uses graphics.library, renders in a window, and works on graphics cards.

*phew*

[xeron]

I like to try to stay far away from any proprietary code. This allows me to port my code to other operating systems written for the PowerPC.

Even if you could use some magical BIOS int calls to make os-portable code under PowerPC (which you can't), that really isn't a good way to achieve it. For starters, you are excluding yourself from any niceties that the operating system provides; such as screens in AmigaOS, or multiple shells (with desktops) under linux.

The trick is to keep your display code seperate from your core code.

For example, I have written an OpenGL application. It easily compiles for Win32, Linux x86, LinuxPPC, and various other operating system, without changing a SINGLE line of the core code.

You simply provide an OS-specific front end, which calls the routines in the main program. For example, there is a windows.c for Win32 OpenGL, and a glut.c for all operating systems that support glut.

This approach also translates to assembler; there is nothing stopping you seperating up your assembler program into objects and linking them depending on your target platform.