OK, i know how to plot pixels using the dos interupt

int 10h

but its damn slow, how do i plot pixels on the screen, in a graphics mode tahtas much faster!!????? i read somewhere you can directly acces the video ram, is this os, and if so can someone point me in the irght direction, ???

Thanks
Leon

: OK, i know how to plot pixels using the dos interupt
:
: int 10h
:
: but its damn slow, how do i plot pixels on the screen, in a graphics mode tahtas much faster!!????? i read somewhere you can directly acces the video ram, is this os, and if so can someone point me in the irght direction, ???
:
: Thanks
: Leon

Easiest is to call in 10h to set screen mode, preferably mode 13h, because it has 8-bit colors, with bits in a 'normal' bitmap order. (byte 1 is pixel (0,0), byte 2 is pixel (1, 0), byte 3 (2, 0) etc tilll byte 64000 which is (319, 199) The screen buffer is allocated at 0A000h:0000h in the memory (in real mode adress...) under most real mode OSses (All ??) you can directly access it. in the windows dos-box you can also do so, but you can not do so in most Protected mode OSses. (windows outside dos-box, all UNIXes, etc.)

You can also directly programm the video card to set modes/plot pixels, but that seems pretty insane to me, if you don't exactly know what you are doing ... no debugger can help you with that But that would be even faster than using the frame buffer ...

an example code to plot a pixel would be: (Mode should already be set to 13h)

plot_pixel:

   ; let es:di point to the screenbuffer    
   mov ax, 0A000h
   mov es, ax
   mov di, 0

   ; clear ax, set cx to number of pixels, to clear the screen
   mov ax, 0
   mov cx, 64000

   ; clear screen
   rep stosb   

   ; plot a red pixel at (10, 10)
   mov al, 04h 
   mov di, 10+(200*10) ; (column+(row*200)) is offset in buffer...
   stosb

   ; done ...
   

Just try it out, and read some documentation! there is plenty of good docs on this website ...


SUSE LINUX 7.3 PRO - The world starts behind windows

if you want to use greater resolutions than 320x200x8 you need either protected mode or an API running on a protected-de OS.the last way is the easier way,because nearly all modern 32-bit OSes use a flat memory model which means you could access mor graphics-memory for greater resolutions.one of the most popular ways under win32-platforms is DirectDraw,which allow you to switch to ANY supported graphicsmode and write directly to video-memory.further you could use backbuffering for flicker-free animations and some (very) basic hardware-acceleration.

: if you want to use greater resolutions than 320x200x8 you need either protected mode or an API running on a protected-de OS.the last way is the easier way,because nearly all modern 32-bit OSes use a flat memory model which means you could access mor graphics-memory for greater resolutions.one of the most popular ways under win32-platforms is DirectDraw,which allow you to switch to ANY supported graphicsmode and write directly to video-memory.further you could use backbuffering for flicker-free animations and some (very) basic hardware-acceleration.
:
As untrue as possible! You can of course switch to any graphics mode you want to in real mode! The only problem is the memory. you have to switch the parts of graphics memory 'mapped' in the accessible parts of memory all the time, to acces all the video-ram. (the so-called 'bank-switching') even early pm-OS'ses used that technique, simply because it is a lot easier to implement! accessing the complete video-ram as a linear piece is rather hard except you have a driver which does the dirty work ... u need mainbord-chipset dependant code to map video memory into your 'normal' memory space ... It is not connected to your processor like the other RAM, so u need tricks to access it! Besides: 'video modes' are just a nasty thing of graphics drivers: most graphicscards support setting width and height per 8 pixels or so ! Just Direct draw hides that from you cause there are some (historically,and memory-amount based) 'nice' modes and a whole bunch of ugly modes (imagine: 808x392 pixels

SUSE LINUX 7.3 PRO - The world starts behind windows

sure,you could switch to every mode in realmode by using Int10h or accessing the graphicscard directly via ports.but its hard make it work with all posible graphics-cards.my old matrox-card doesnt support the "Mode-X" correctly.and bank-switching could be very slow at greater resoltuions.imaging youre running at 1024*768*32:

you have 3145728 bytes (3mb) and have to do at least 48 bank-switches to write one screen.and its impossible to use a backframe at those resoltutions in realmode.or do you want to use a compressed backframe? :)

of course its theoreticly possible to switch to those modes,but there is no waranty that your init-code will work on other systems.and drawing in those modes wont work in real-world programs.(did you ever write a DOS-proggie using hi/true-color and higher resoltions?)
the only compatible,fast way to use higher resoltions with more colors is to use some kind of api,which accesses the graphicscard for you.

: sure,you could switch to every mode in realmode by using Int10h or accessing the graphicscard directly via ports.but its hard make it work with all posible graphics-cards.my old matrox-card doesnt support the "Mode-X" correctly.and bank-switching could be very slow at greater resoltuions.imaging youre running at 1024*768*32:
:
: you have 3145728 bytes (3mb) and have to do at least 48 bank-switches to write one screen.and its impossible to use a backframe at those resoltutions in realmode.or do you want to use a compressed backframe? :)
:
: of course its theoreticly possible to switch to those modes,but there is no waranty that your init-code will work on other systems.and drawing in those modes wont work in real-world programs.(did you ever write a DOS-proggie using hi/true-color and higher resoltions?)
: the only compatible,fast way to use higher resoltions with more colors is to use some kind of api,which accesses the graphicscard for you.
:

Just beside: did not say it was easy. I just said it was possible.

Assuming you do the same in Protected mode WITHOUT an API, does not make it any easier ... it rather makes it harder because the BIOS won't work. You are definitely right in it being rather hard to use high resolution xcept u have an api (like VESA, direct-X, X-server, whatever)
and that goes for Protected Mode and Real Mode! Andusing your nice framme buffer makes it even harder (for the api to caary out your requests) cause it needs code not only for your gfx-card but also for yout mainboard-chipset, to enable linear-frame-buffer ...

SUSE LINUX 7.3 PRO - The world starts behind windows

From my own investigation I found out that DirectX technology (using
C++ or even Visual Basic) works much faster then any INT 10h or INT 13h...

Those modern Video Cards are simply optimized for it.

Actualy this has nothign at all to do with modern video cards, it has everythig to do with the fact that the 'int' command in asembelr uses INTERUPTS and just by that name you can tell thet interupts take time. Asembelr graphics are faster then any other programming language even direct x stuff. Direct x is however good fi you don twana screw aaorund with making the base case scenarios and for 3d graphics.

i think directx is still a little faster,because all modern cpus are designed for protected mode and runs faster in a true 32bit enviroment with flat-memory model than realmode or v86-mode.and dont forget the hardware-support for faster blitting-operations which could use the dma-chip without any additional coding.the speed of 2d-graphics is mainly based on the speed of mem-copy operations from system-ram to vram (and back)

however,today it doesnt matter what graphics-card you have,when you only use 2d-graphics.modern graphic-cards only advantage is the possibility to calculate some parts of a 3d-pipeline in hardware.butusing 3d-features of a graphicscard is a very difficult task,because there are no standarts on how to do that,you have to write rendering-code for every single 3d-card.in fact its nearly impossible to use any of the newer features without a API like opengl,direct3d or whatever.