Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: fatman2021 on February 25, 2003, 07:32:59 PM
-
I'm a x86 programmer. So when I do my asm programming I use the x86 8-bit, 16-bit, and 32-bit registers. Now what I need to know is the PowerPC equivalents of the x86 8-bit, 16-bit, and 32-bit registers. This will help me port my x86 VESA VBE programs over to AmigaOS. So if any one knows a table or any other infomation, let me know thanks
I also need to know the PowerPC equivalent to the x86 interrupt 10h
-
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.
-
http://www.innoidea.hu/subsites/amiga/developer/phpwebdev.php
:-D:-D:-D:-D
-
Interrupt 10h is not a msdos thing... It's a x86 video biso thing.
-
This won´t - unfortunately - be possible. VESA VBE is a standard for X86 BIOS, and does not exsist in PowerPC world.. Nor does simple mapping of register have any use.
If you though, still wan´t to learn PowerPC asm to write amiga apps, let us know. We can direct you to the needed manuals..
-
go to mot.com and you'll find all the information you need about ppc asm programming...
If you want to port your programs thank you, but programming a pc with x86 and an amiga has little in common. You'll have to use the OS to select the screenmode. In amiga you can have any resolution and it has a different ID. In Amiga you can have multiple "screens" and the address of the screen can be in any place of the gfx ram, it's not in a fixed position, so you again will need to use the OS to get that address if you plan to write directly to the gfx ram for example.
Don't fancy about porting your apps without learning a bit how the AmigaOS API works. This is not a pc with MSDOS... this is not a primitive 8bit computer...
If you are going to port programs and not games you shouldn't "draw" the interface writing to the gfx card, you should use the components of the OS.
-
The only computer I have at this time is a IBM ThinkPad 755CX with a P75 CPU. So I have no way to test my PowerPC apps
-
Tickly wrote:
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.
AFAIK, the integer register set are only 32-bits wide on 60x, 64-bit on G3 and above. Still, not sure, so don't take my word for it.
The FPU regs are 64-bit IEEE754 compatible, but I think the internal calculation goes higher.
-
All motorola 7xxx (G4), 7xx (G3) and 6xx (G2) processors in production are 32-bit implementations according to their website and thus, I assume, have 32-bit integer registers.
-
heh, ok. I sit corrected :-D
-
>The PowerPC has 32 64bit integr registers
Actually, these registers are only 32 bit on a 32 bit PPC...
-
OK OK thats enough corrections :) I've already admitted to being wrong.
-
fatman2021 wrote:
I'm a x86 programmer. So when I do my asm programming I use the x86 8-bit, 16-bit, and 32-bit registers. Now what I need to know is the PowerPC equivalents of the x86 8-bit, 16-bit, and 32-bit registers. This will help me port my x86 VESA VBE programs over to AmigaOS. So if any one knows a table or any other infomation, let me know thanks
I also need to know the PowerPC equivalent to the x86 interrupt 10h
A couple of things here, the PPc does not have 8bit,16bit and 32bit modes, instead it had a single set of 32, 32bit general purpose registers which will work in the size of the addressing mode of the instruction you are using.. Some registers are reserved for use by the OS (some registers don;t get saved in a context* switch,), and this depends on the OS you are using, so get a good book on the subject.
*Linux, BFD, MacOSX, AmigOS4,MorphOS and AROS are all multitasking OS's, so you must remember that your task is going to not going to have total control over the CPU and will be switched out quite regularly.
Doue to the design of MSDOS, System calls had to made made using an interupt, thus System calls and Interupt have become interchangeable for the MSDOS programmer.
This is not the case for Multitasking OS's, and system calls should not be confused with interupts. you will probably never need to invoke an interupt in AmigaOS.
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!
I suggest you buy/download some developer docs, AmigaOS is very different to MSDOS.
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).
Have fun :-D
-
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.
-
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...
-
Sorry, Tickly, didn't see that other post until it was too late :oops:
-
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.
-
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.
-
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.
-
Tickly must be climbing the walls by now :lol:
-
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.
-
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() =) =) =)
-
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
-
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! :)
-
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.
-
(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*
-
hmmm, ok then :-D
-
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.
-
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.
-
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.
-
Any good PowerPC emulators out for DOS/Windows
-
I´ve written my own. It doesn´t work 100% OK at the moment, but some testing would surely help, if anyones interested...
-
Hey Tickly...
Did you know that the integer registers on PowerPC are 32-bits? Thats 32, not 64...
:lol:
Sorry man, I just couldn't resist it :-D
-
fatman2021 wrote:
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.
You are already using proprietary code if you are using int10 and VBE. Not only proprietary, but also entirely non-portable.
Every OS will impose some API on you, there is simply no way to do otherwise. A portabillity layer is a good idea, something like libSDL for example.