assembler
Jacob Dawid

hi @ all

How can I directly compile asm commands?

I tried it with asm("<command>");, but every time MingW complains that ( in this special case here following ), "mov has got too many parameters":

...
asm("mov ah, 4fh "); /* mode 13h */
asm("mov al, 02h ");
asm("mov bx, 104h");
asm("int 10h "); /* 10h */
...
asm("mov ah, 08h ");
asm("int 21h "); /* wait for keypress */
...

this should normally switch the screen mode to 320x200...

Can anybody help me?

X-G

GCC uses AT&T syntax. What you have there is Intel syntax.

gillius

You won't be able to run that with mingw anyway. Mingw only generates Windows applications.

Jacob Dawid

X-G

What exactly is AT&T syntax ( where are the differences, how does it look like )? thx for ur help

Radagar

I don't have an answer for you (and I'm not X-G) but that sure sounds like a Google question to me.

X-G

Yes, Google is the answer. I can't possibly even begin to describe all the differences here.

Jacob Dawid

Ok thx anyway, at least I won't sit in front of my pc and ask myself what I might have to do thx again

Oscar Giner

But anyway, gillius is right. Even if that would compile it won't run with mingw, because mingw is a windows compiler. You'll need a DOS compiler, like djgpp, but this compiler seems not to work propertly/at all under XP.

Bob

On top of that, it's 16-bit real mode code, which will not run under DJGPP anyway, at least, not without some heavy hacking.

gillius

Why do I have this bad feeling that this ASM code is directly related to the "let's make an API to replace D3D" post made earlier by the same poster.

Somehow I don't feel that the next generation to replace Direct3D lies in "13h" graphics modes.

Thomas Fjellstrom
Quote:

GCC uses AT&T syntax. What you have there is Intel syntax.

These days GAS does both. Theres a command... Probably in tfm.

Jacob Dawid

btw, this is just one available gfx mode, gillius... just laugh, but I don't really need your help, there are others that share my view

CGamesPlay

The others won't work either ::)

Jacob Dawid

I will have a closer look on it, thx. I am posting this message from school and downloading files is forbidden. Unfortunately, I won't have oppportunity to take a closer look on it, but be sure I will do this when I got home this evening.

Evert
Quote:

Somehow I don't feel that the next generation to replace Direct3D lies in "13h" graphics modes.

He's not even setting mode 13h (although his comment claims that he is) - he's setting a VESA mode.

Quote:

this should normally switch the screen mode to 320x200...

Not quite.
AH=4F/AL=02 is the VESA set video mode function, not the standard VGA set videomode function (Ah=0). Moreover, BX=104 selects a 1024x768 video mode. (Just checked against Ralph Brown's interrupt listing).

Videomode 13h is called 13h for a reason: it is the mode number passed to the VGA interrupt handler. You set it by

mov ax, 0013h
int 10h

Word of advice: learn what that code actually does before you try to use it. I could tell you that

mov ah, 05h
int 13h

is a bright idea, but you wouldn't want to do that without knowing what it did, would you? (Hint: DON'T try that!)

gillius

Jacob, not matter what you do, the API won't matter too much unless you implement hardware rendering, which is basically required these days for any serious work.

But that's not the real concern. You can't set 13h or VESA or whatever hardware graphics modes from inside a Win32 application, which is what mingw32 generates.

As I stated in another thread, if you want to implement a new API you need to do it as a wrapper around either D3D or OpenGL, or convince all hardware manufacturers to implement drivers for your API (you could provide a simple software driver or D3D/OGL wrapper for those who don't), but attempting to compete directly with D3D/OGL probably isn't going to work too well, so the wrapper option (as Allegro uses) will be your best bet if you are serious about making a new API.

EDIT: heh looked up that interrupt call... "Format Track" (of the hard drive)

Jacob Dawid

ok, evert, now I've set the VESA mode 1024x768...
I didn't actually knew what this code does exactly, I just had in mind that it switches to a graphics mode, I began to program in assembler a few weeks ago... but everyone was a beginner once :-) hey it seems that you know more about assembler,... erm, excuse me for that stupid question, but after I have set the graphics mode, how can I access the ( video ) memory?

gillius

Did you just set VESA mode from a Win32 executable (you initially said you were using mingw)? Can you even do that? I'd be absolutely floored if Win NT let you do that, and quite surprised even if Win9x let you do that.

Jacob Dawid

No, gillius, normally then you would get a general protection fault. I proceeded this code with debug... But according to your statement, is there any way to get around this?

Nah here you are, a tets program. 68 Bytes: Sets VESA mode 1024x768 and draws two lines with a simple putpixel-loop

Evert
Quote:

I didn't actually knew what this code does exactly, I just had in mind that it switches to a graphics mode, I began to program in assembler a few weeks ago...

That was my point. You're calling interrupts without knowing, or having verified, what they do. That is a very dangerous thing to do. Make sure you get a copy of the interrupt functions you want to use (hardcopy if you can get it) and read it before actually using it.

Quote:

but everyone was a beginner once :-)

Indeed. Once, I thought it'd be cool to figure out what all those nifty interrupts did and started calling them at random. Thank god I somehow managed to kill the DOS kernel, effectively disabeling all disk access and forcing me to reboot before I actually formatted my harddisk.
Morale: be careful and know what you're doing.

Quote:

hey it seems that you know more about assembler,...

I haven't really used it much for about six or seven years and I know next to nothing about protected mode.

Quote:

erm, excuse me for that stupid question, but after I have set the graphics mode, how can I access the ( video ) memory?

In real mode, there's a 64kb block starting at segment A000 (the first past the 640kb real-mode limit) where you write all your data. To write to different portions of the screen, you have to call a VESA function to do a bank switch.

In protected mode, there are no memory segments and the framebuffer may be linear. You either need to figure out where the extender has relocated the real-mode A000 segment, or find the addres of the linear framebuffer. I can't help you with either of those.

Note that all of that really applies to DOS only.

Quote:

Nah here you are, a tets program. 68 Bytes: Sets VESA mode 1024x768 and draws two lines with a simple putpixel-loop

That is NOT a Windows executable, it's a DOS executable. This will work from a DOS executable. You can't use that code from a native Windows executable - that's what DirectX is for.

gillius

You could always look at the Allegro source code, which already does this for DOS.

Jacob Dawid

Ok then, let us assume I would just like to write an engine for MS-DOS. I am using a86 to compile my asm files to obj files. Now I would like to correspond to the methods I have defined before in the asm file. But MinGW complains that it (= the obj file ) has got an unknown file type. Can someone give me a concrete example of how I could manage this task? thx for all replies

Bob
Quote:

...an engine for MS-DOS....But MinGW complains

Obviously. Mingw is a Windows compiler. Secondly, make sure a86 outputs a compatible object file for GCC. There ought be output switches for that. Thirdly, make sure the code outputted by a86 is compatible with your protected mode compiler (ie: the code is p-mode friendly). Fourthly, why not use the GNU assembler? And finally, Allegro already does this for you, and Allegro is Open Source. So dive in!

nshade

Jacob:
I think I have figured out where you are getting confused. You don't understand how an x86 CPU operates.

An x86 has two modes. "Real mode" and "Protected mode". Think of "Real mode" as DOS and "Protected mode" as Windows.

These two modes are incompatible with each other. One of the most drastic changes is the memory management and how data is accessed.

In Real Mode, (Or DOS mode), you only have direct access to 640k of ram. (You really have access to 1024K, or 1 MB, but the other 384K is taken by the system) To make matters worse, you really can only access this though 64k segments, even more confusing is that the segemts aren't liniar, and can actually overlap each other. You can point a segment anywere in in the 1MB of addrssable memory and then access data within that segment using a pointer. Most of the memory management is taken care of by the compiler.

Now, at the veeeeery bottom of the memory, there is something called a "vector table". All it is is a list of addresses to jump to when you make an interupt call. There are 256 entries, one for each int call. Then you make an int call, your current place in the program is "bookmarked" on the stack and the int is ran. When the init is done, it will "pop" your last state off of the stack and return to your program.

That's why it's called an "interrupt" it's job is to interrupt your program for a little bit and then allow it to continue.

You can change the addresses in the vector table to point to you own programs. This is called "masking" and creates a kind of psudo-multitasking environment.

Aha! You say. djgpp allows you to allocate all of your memory. Not just 640k.

That's because when you run a program made by djgpp, there is an intrupt vector installed that opens a "window" into the 16 bit address space. This is done with a DOS Protected Mode Interface (Or DPMI)

You can't run a djgpp program without a DPMI manager.
Period.

Windows 9x comes on one, or you can use CWSDPMI.

Now about Protected mode.

When you switch a computer into protected mode, (You can't run both modes at the same time), you gain all kinds of cool benifits.

- You have more registers that hold more data
- You have the ability to keep programs seperated so they don't write all over each other.
- You're memory is no longer segnmented and goes from 0 to however much you have.

Windows runs in protected mode. When you put your fingers into parts of memory that doesn't belong to you, you generate a general protection fault. The program is then teminiated as it can no longer continue.

But here's the problem, and here is the sad thing.

When you go into protected mode, you loose your vector table. It's GONE All those cute things like int 33h for mouse, int 21h for dos functions, and int 10h for graphics are ALL GONE!

The real mode intrrupt system only works with segemnted memory and you gave that up when you switched modes.

When you use a compiler like MingW, you are using a full protected mode compiler that must run it's code NATIVELY in protected mode. It generates windows .EXE files, not dos .EXE files. These two formats are different! It's better to call them by thier real names. a DOS executable, and a Windows PE executable. PE executables are a lot like an ActiveX control. Worlds of diffrence.

So how do you access things without interupts?
You use the Windows API or talk with the hardware directly, but you arn't going to do the later without communicating though a windows driver of some sort. The hardware is protected anyway windows doesn't allow you to directly access it.

All your graphics hardware is ran by a windows driver. Not only that, many graphics cards now a days have low level functions that are SECRET and you MUST access them though a windows driver. Some graphic card companies will even take you to court for violation of trade secrets of you discolse how thier cards work on a low level.

Don't think this is a Windows thing. You can't directly access hardware on Linux either. You have to go through the kernel. The Nvidia driver for Linux is secret. There is no code avilable for it, just the wrapper.

Well, if you are root on linux, you have direct access to hardware, but then no one else can run your program. When using Linux, you also loose your ability to do intrrupts as well.

So how does windows run DOS programs?

It uses a psudo-emulator that catches the calls and tries it's best to handle them. It's not perfect. Windows NT/XP has stricter control over memory management than Win9x and that why it runs less DOS programs.

Pick a mode a stick with it. If you want DOS interrupts, use djgpp. if you want windows protected mode, use MingW, but you can't have both.

Sorry, that's the way the system works.

Do you have any questions?

Oscar Giner

I may be wrong, since I learned this some time ago, but I think you confused some things in your post (the final result is the same though: that code can't be run if compiled with mingw).

Quote:

- You have more registers that hold more data

You're confusing real vs protected mode with 16 vs 32 bit. the eax/ebx... registers are available under 32bit real mode.

Quote:

When you go into protected mode, you loose your vector table. It's GONE All those cute things like int 33h for mouse, int 21h for dos functions, and int 10h for graphics are ALL GONE!

No. The interrupt table is there and you, in theory, can touch it. It's Windows who doesn't let you touch it. Starting from the 80386, the intel processors have 4 execution levels (if running in protected mode). All user code is executed under level 3, the most restrictive. The interrupt table is not accessible under this execution level.

Quote:

- You have the ability to keep programs seperated so they don't write all over each other.

It's perfectly possible to write a multitasking SO that runs in 16bit real mode (I have done it at university). Programs can mess up the SO, since there's no protection, thought.

Quote:

So how does windows run DOS programs?

It uses a psudo-emulator that catches the calls and tries it's best to handle them. It's not perfect. Windows NT/XP has stricter control over memory management than Win9x and that why it runs less DOS programs.

I'm not very sure about this one, but IIRC you can run real mode programs under a protected mode environment.

X-G

IIRC, there's a mode that's sort of like "real mode under protected mode", too ... I forget what it's called though.

imaxcs
Quote:

It's perfectly possible to write a multitasking SO that runs in 16bit real mode (I have done it at university). Programs can mess up the SO, since there's no protection, thought.

IMHO true for windows, but not for linux.

Evert
Quote:

I'm not very sure about this one, but IIRC you can run real mode programs under a protected mode environment.

Yes - virtual 86 mode. Your computer appears to each real-modeprogram running as a unique system.

Oscar Giner
Quote:

Quote:
--------------------------------------------------------------------------------
It's perfectly possible to write a multitasking SO that runs in 16bit real mode (I have done it at university). Programs can mess up the SO, since there's no protection, thought.
--------------------------------------------------------------------------------

IMHO true for windows, but not for linux.

You didn't understand me. I'm talking about writing a 16bit multitasking SO. An SO is 100% standalone, it doesn't run over another SO (it may use it to boot, like that DOS linux boot loader, and in our case we used DOS to boot our SO. Probably Windows won't let you boot another SO).

Evert

Oscar: do you mean Operating System (OS)...? Otherwise I'm not sure I understand what you mean by SO...
Are you Spanish the same as French in having all your abbreviations andacronyms the other way round from the rest of the world? ;D

X-G

Silly spaniards. :P

Oscar Giner
Quote:

Oscar: do you mean Operating System (OS)...? Otherwise I'm not sure I understand what you mean by SO...

Ah, sorry. Yeah, I mean OS. SO in Spanish (Sistema Operativo).

nshade

Thanks for the corrections. I haven't touched real mode in years. I'm running linux so I don't have access to the vector table anyway.

Also I know that when you are in protected mode. the vector table is still at the bottom of memory. When you switch modes, the memory isn't erased. When you go to and from any mode, the data is still there. I was tought that calling an interrupt in protected mode was a fruitless thing to do and to simply not do it

Side note:

Remember on a 286 when you switched into protected mode you coudn't switch back into real mode? Intel thought that no one would ever want to switch back to such a wonky memory system. Anyways UNIX was becoming popular around that time and it was more powerful than DOS anyway. Whay would you want to run a monolithic OS when you have protected mode, which was better.

That's to show how long Microsoft's been stangnating the computer software industry.

You could actually go back into real mode on a 286. You have to RESET THE CPU on the fly and code in such a way that you didn't trip the computer into doing a BIOS self-test on restart.

Good Times.

That's why the 286 has such a short lifesycle.

Thread #338808. Printed from Allegro.cc