PowerPC asm programming

[bloodline]

as I said, he probably wouldn't need the Graphics.library very much. I didn't mean to make it sould like I was excluding it altogether!!!  :-D

I just prefered to used the inutition library for as much as possible as that allowed me to support graphics cards without modification. And the guy did say he wanted to program the PPC, so I'm guessing he isn't going to be using AmigaOS on an Amiga Classic (yes, yes, yes, I have a BlizzPPC... :-P )

I loved ASM coding... on the 68k... but the PPC is really quite boring (loved all those regs though!!!!). I've done very little x86 coding though.
I'm no fan of C... but it is probably the best language available (C/C++ ...Blah...)

P.S. I'm sure there's an intuition function for line drawing and filled polys...etc...!!! But it has been 5 years, I may have forgoten a few things...

[EntilZha]

Sorry, Tickly, didn't see that other post until it was too late  :oops:

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

[bloodline]

Tickly wrote:

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.

I mean for rendering directly to a GUI window.   I'm sure window drawing was in intuition. I stoped working on bitmaps, screens and rastports, when I switched to CGX.

[Rogue]

The PowerPC has 32 registers with 32 bit each, named R0, R1.. up to R31. I doubt that you will have much fun converting x86 assembler to PowerPC - the two models are radically different. You should look for a high-level language like C, for example.

There is no equivalent to interrupt 10h, as much as there isn't on e.g. Linux. If you are looking at AmigaOS, you should use graphics.library or Picasso96API.library and its functions to perform graphics operations, and intuition.library for user interface stuff.

[Karlos]

Tickly must be climbing the walls by now :lol:

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

[itix]

fatman2021 wrote:

I also need to know the PowerPC equivalent to the x86 interrupt 10h

I think the equivalent for x86 interrupt 10h is OpenScreenTagList() =) =) =)

[bloodline]

Tickly wrote:

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

I'll be reading the Tech docs tonight... But I'm sure there were drawing functions in intuition (for rendering to windows, not bitmaps..blah..) . :-D

I know I'm probably gonna be proved wrong.. but at will stand by my views. :-P  

[itix]

Tickly wrote:

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.

To be honest you are wrong here =) There are some (bit stupid) functions for rendering. One of them is PrintIText(). However it calls gfx lib functions for rendering but...

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

Just making you crazy!

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

[bloodline]

hmmm, ok then  :-D

[itix]

Tickly wrote:

Right, having downloaded and browsed the intuition autodoc (didn't have them to hand at work), intuition provides DrawBorder(), DrawImage() and PrintIText()

And to be honest.. those functions are crap.

[fatman2021]

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.

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