GAS colorr pixel problem

GAS colorr pixel problem

[A D]

Hello there! I'm new to x86 gnu assembly language and
trying to learn it. I've a question: is it possible to draw
a filled rectangle on monitor using gas? How do i
color individual pixel on my monitor? If anyone can
just give me the theory behind it or be kind enough to
write the source code I would appreciate it. Thanks.

--STeve

_________________________________________________________________
Experience Live Search from your PC or mobile device today. 
http://www.live.com/?mkt=en-ca

Re: GAS colorr pixel problem

[Robert Plantz]

Given that everything ultimately resolves to assembly
language (try the -S gcc option when compiling), yes,
you can do graphics on the monitor.

On the other hand, I've been an assembly language programmer
for 30 years, and I would not even consider doing this
in assembly language. In my view, the main reason for
learning assembly language these days is to gain an
understanding of how computers actually work.

Bob


On Wed, 2006-11-22 at 13:54 -0500, A D wrote:
> Hello there! I'm new to x86 gnu assembly language and
> trying to learn it. I've a question: is it possible to draw
> a filled rectangle on monitor using gas? How do i
> color individual pixel on my monitor? If anyone can
> just give me the theory behind it or be kind enough to
> write the source code I would appreciate it. Thanks.
> 
> --STeve

Re: GAS colorr pixel problem

[Jean-Yves Lamoureux]

A D wrote:
> Hello there! I'm new to x86 gnu assembly language and
> trying to learn it. I've a question: is it possible to draw
> a filled rectangle on monitor using gas? How do i
> color individual pixel on my monitor? If anyone can
> just give me the theory behind it or be kind enough to
> write the source code I would appreciate it. Thanks.
gas is just an assembler. You can do whatever you want with an 
assembler, as every single executed bit on your processor is the output 
of an assembler (ok purists, I just simplified).
"Filling a rectangle" means nothing. You have to draw something that 
will be interpreted as a bunch of pixels having the sahpe of a 
rectangle. You can do that in ascii (libcaca for example, 
http://libcaca.zoy.org ), or in graphic mode (SVGAlib, old as hell but 
works on most PC cards, without X), X11 (which itself has dozen of low 
(xlib) and high (sdl, ptc, gtk, qt, whatever) level libraries to do that).

I suggest you to learn how to call C-like functions (pushing arguments, 
calling function), how to work with memory (lea, syscalls, brk, etc), 
then to use something like SDL for example, which does most of the work 
for you.

Good luck.

-- 
Jean-Yves Lamoureux
Software Developper

Re: GAS colorr pixel problem

[Markus Rechberger]

On 11/22/06, Robert Plantz <plantz@sonoma.edu> wrote:
> Given that everything ultimately resolves to assembly
> language (try the -S gcc option when compiling), yes,
> you can do graphics on the monitor.
>
> On the other hand, I've been an assembly language programmer
> for 30 years, and I would not even consider doing this
> in assembly language. In my view, the main reason for
> learning assembly language these days is to gain an
> understanding of how computers actually work.
>

depends, if you apply at Intel or AMD you might need it.. AMD is
looking for people at the moment who have indepth knowledge about
kernel development and who also know about ASM...

jobs are just more rare in that area but they exist.

cheers,
Markus

Re: GAS colorr pixel problem

[Jean-Yves Lamoureux]

Markus Rechberger wrote:
> jobs are just more rare in that area but they exist. 

Real-time stuff, kernel development, heavy graphical proggies, and 
everything that can be a bit system-related, security (anti-copy 
protections, exploits, etc), reverse engeenering, etc etc. There is a 
load of these, that's just hidden into the flood of java and .NET job 
offers. That's quite cool, asm-aware people can get (well) paid for 
doing (sometimes) interresting work ;)

-- 
Jean-Yves Lamoureux
Software Developper

Re: GAS colorr pixel problem

[A D]

>Jean-Yves Lamoureux wrote:
>gas is just an assembler. You can do whatever you want with an assembler, 
>as every >single executed bit on your processor is the output of an 
>assembler (ok purists, I just  > simplified).
>"Filling a rectangle" means nothing. You have to draw something that will 
>be >interpreted as a bunch of pixels having the sahpe of a rectangle. You 
>can do that in >ascii (libcaca for example, http://libcaca.zoy.org ), or in 
>graphic mode (SVGAlib, old as >hell but works on most PC cards, without X), 
>X11 (which itself has dozen of low (xlib) >and high (sdl, ptc, gtk, qt, 
>whatever) level libraries to do that).

>I suggest you to learn how to call C-like functions (pushing arguments, 
>calling function), >how to work with memory (lea, syscalls, brk, etc), then 
>to use something like SDL for >example, which does most of the work for 
>you.

Thanks to all for your input. I guess it would be really difficult to color 
pixels in assembly language. Can anyone tell me what steps are involved in 
that(color pixels in assembly)? Just for my knowledge. Thanks.

--STeve

_________________________________________________________________
Buy, Load, Play. The new Sympatico / MSN Music Store works seamlessly with 
Windows Media Player. Just Click PLAY. 
http://musicstore.sympatico.msn.ca/content/viewer.aspx?cid=SMS_Sept192006

Re: GAS colorr pixel problem

[Jean-Yves Lamoureux]

A D wrote:
>> Jean-Yves Lamoureux wrote:
>> gas is just an assembler. You can do whatever you want with an 
>> assembler, as every single executed bit on your processor is the 
>> output of an assembler (ok purists, I just simplified).
>> "Filling a rectangle" means nothing. You have to draw something that 
>> will be interpreted as a bunch of pixels having the sahpe of a 
>> rectangle. You can do that in ascii (libcaca for example, 
>> http://libcaca.zoy.org ), or in graphic mode (SVGAlib, old as hell 
>> but works on most PC cards, without X), X11 (which itself has dozen 
>> of low (xlib) and high (sdl, ptc, gtk, qt, whatever) level libraries 
>> to do that).
>>
>> I suggest you to learn how to call C-like functions (pushing 
>> arguments, calling function), how to work with memory (lea, syscalls, 
>> brk, etc), then to use something like SDL for example, which does 
>> most of the work for you.
>
> Thanks to all for your input. I guess it would be really difficult to 
> color pixels in assembly language. Can anyone tell me what steps are 
> involved in that(color pixels in assembly)? Just for my knowledge. 
> Thanks.
>

http://www.google.com/codesearch?q=show:GtRjeWKEOlc:2P9VXd642nk:3e2ZV6Tu0vo&sa=N&ct=rd&cs_p=http://allergy.alrj.org/Code/xtest.tgz&cs_f=xtest/PTC4k.asm

May seem hard to understand, it is a "complete" graphical library in 
asm, using xlib. That's not the easiest way, but hey, you wanna learn !

(Wrote by me yeaaaars ago, when I was a young padawan, rewritten from 
scratch by a friend later)



-- 
Jean-Yves Lamoureux
Software Developper

Re: GAS colorr pixel problem

[Claudio Fontana]

--- A D <a_d_249@hotmail.com> wrote:

> >Jean-Yves Lamoureux wrote:
> Thanks to all for your input. I guess it would be
> really difficult to color 
> pixels in assembly language. Can anyone tell me what
> steps are involved in 
> that(color pixels in assembly)? Just for my
> knowledge. Thanks.
> 
> --STeve

You could use/read the source code of the libraries
you have been presented with. Probably you will find
the source code of svgalib satisfying enough.
Just do it in assembly instead of C.

Claudio



__________________________________________________
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 

Re: GAS colorr pixel problem

[A D]

Again my thanks goes to Jean-Yves Lamoureux and all the forum members. That 
is all i wanted to know.

--STeve

_________________________________________________________________
Off to school, going on a trip, or moving? Windows Live (MSN) Messenger lets 
you stay in touch with friends and family wherever you go. Click here to 
find out how to sign up!  http://www.telusmobility.com/msnxbox/

Re: GAS colorr pixel problem

[Robert Plantz]

On Wed, 2006-11-22 at 16:08 -0500, A D wrote:
> Again my thanks goes to Jean-Yves Lamoureux and all the forum members. That 
> is all i wanted to know.
> 
> --STeve

Also, if you use C libraries for your I/O, you can assemble your
assembly language source files with
   as --gstabs -o foo.o foo.s
where --gstabs gives you debugging symbols. Then use gcc to
link your object file(s), even if you have only one file:
   gcc -o myProg foo.o

gcc recognizes that the input file is already an object file,
so it goes directly to the linking phase. The advantage of
doing it this way instead of using ld is that gcc will
automatically find the C libraries for you. If you use
ld, you need to explicitly list the C libraries.

Re: GAS colorr pixel problem

[Frank Kotler]

Jean-Yves Lamoureux wrote:
> A D wrote:
> 
>>> Jean-Yves Lamoureux wrote:
>>> gas is just an assembler. You can do whatever you want with an 
>>> assembler, as every single executed bit on your processor is the 
>>> output of an assembler (ok purists, I just simplified).
>>> "Filling a rectangle" means nothing. You have to draw something that 
>>> will be interpreted as a bunch of pixels having the sahpe of a 
>>> rectangle. You can do that in ascii (libcaca for example, 
>>> http://libcaca.zoy.org ), or in graphic mode (SVGAlib, old as hell 
>>> but works on most PC cards, without X), X11 (which itself has dozen 
>>> of low (xlib) and high (sdl, ptc, gtk, qt, whatever) level libraries 
>>> to do that).
>>>
>>> I suggest you to learn how to call C-like functions (pushing 
>>> arguments, calling function), how to work with memory (lea, syscalls, 
>>> brk, etc), then to use something like SDL for example, which does 
>>> most of the work for you.
>>
>>
>> Thanks to all for your input. I guess it would be really difficult to 
>> color pixels in assembly language. Can anyone tell me what steps are 
>> involved in that(color pixels in assembly)? Just for my knowledge. 
>> Thanks.
>>
> 
> http://www.google.com/codesearch?q=show:GtRjeWKEOlc:2P9VXd642nk:3e2ZV6Tu0vo&sa=N&ct=rd&cs_p=http://allergy.alrj.org/Code/xtest.tgz&cs_f=xtest/PTC4k.asm 
> 
> 
> May seem hard to understand, it is a "complete" graphical library in 
> asm, using xlib. That's not the easiest way, but hey, you wanna learn !
> 
> (Wrote by me yeaaaars ago, when I was a young padawan, rewritten from 
> scratch by a friend later)

Very nice! I hadn't seen that one. Thanks!!!

Other possible ways to plot a pixel... If you enable the "frame buffer 
device" at bootup ("vga=769" or somesuch), you can open "/dev/fb0" and 
write to it (need root access). This is fairly easy, but requires that 
the user enable the device.

Richard Cooper/PJ (you still around?) wrote a thing called "softer", 
which acquires access to the ports, and does vga (yuck) graphics by 
diddling the ports. I find this quite impressive, but it isn't a 
"Beginner Project"!!! *Using* softer from your own code - as it's 
intended - is fairly easy. (so easy that Richard provide examples in 
Perl!!!)

Even crazier, I'm in the midst of an experiment to use the X windows 
system without using Xlib - int 80h only. It's in a very early stage, 
but "seems to work".

This is assembly language! We can do anything that *can* be done, and 
usually several different ways. The "right" way to do it - "The Unix 
Way" - is to use the library(s). But there are options, if you want to 
see "what we can get away with".

Any examples I could provide would be in Nasm syntax. Mostly easy enough 
to "translate" to Gas. More Nasm examples (glut, SDL, etc.) can be found 
  in the "files" section of the !Yahoo! group 
http://groups.yahoo.com/group/linux-nasm-users

I don't suppose I could interest you in any hot stock tips? :)

Best,
Frank

Re: GAS colorr pixel problem

[Hendrik Visage]

On 11/22/06, A D <a_d_249@hotmail.com> wrote:
> Hello there! I'm new to x86 gnu assembly language and
> trying to learn it. I've a question: is it possible to draw
> a filled rectangle on monitor using gas? How do i
> color individual pixel on my monitor? If anyone can
> just give me the theory behind it or be kind enough to
> write the source code I would appreciate it. Thanks.

Now that everybody else gave there answers, and I'm lonely on this
new years eve, hear is some other opinions/views ;^P

The biggest single problem with "graphics", is to get the
information out of the chipset manufacturers how to program that
interesting piece of silicon :( They don't like those "proprietary information"
to be leaked [Note1], so they typically provide very limited information,
other than drivers that have a standard set of interfacing etc.

In Windows I believe you have the options of using the GDI or the DirectX
routes as calls to get things done on the screen, but let's look at
the Linux world
for a moment and it's "options" I recall:

Raw Access:
 Here I assume there is nothing else having access to the display like X/fb/etc.
You'll need the chip set's port information to (a) setup the graphics mode
(b) to actually tell the chipset to lit up a pixel and typically to
(c) draw fancy
stuff etc.

 In this "mode" you'll typically look at things on a device by device setup to
do things... not that "nice" IMO unless you are doing embedded stuff
and have the
producers by the balls to release that info ;^P

 Usig "generic" (S)VGA:
See the SVGA lib for examples etc. and this might be a library to investigate to
use... again assuming no X/fb/etc.

 VESA:
This is a standardization "effort" to get the first things going, so almost all
(S)VGA adapters lately support that and it's modes. I believe you'll
find code snippets etc. on using it inside Linux in both SVGAlib and X, but
sometimes the "problem" might be that you'll need to do a realmode BIOS call
(yuck) to get things initialized... correct me if I'm wrong here...

 SDL:
I'm sometimes surprised on how long this has survived!! (given that OpenGL
got opened up by SGI) but that's another "layer" like SVGAlib/Xlib to get to the
display, sound etc.

 X:
Okay, this is one of those subjects that can become very interesting, but it's
allso one of those things that I'm sorry to have been bastardized to make things
fit for the proprietary guys :(

 First I'll have to mention that there are several "libraries" to talk to
Xservers, the simplest and rawest is Xlib, followed by Xaw (Athena Widgets..
is something still using this??) and previously licensed Motif and then the
latest Qt and GTK forming the base of KDE and GNOME respectively.

However, X consists of a protocol (There is/was an O'Reilly book out
in a series of X that described that protocol fairly in depth...) to tell the
Xserver/display what to do/display etc.
This protocol can be run over Unix Domain sockets (typically :0.0 with
the socket
in /tmp/.X/...) or over TCP/IP (hostname:0.0) with the TCP socket listening on
6000+0 and :1 on 6000+1 etc. Note that lately the TCP sockets in X is
off by default and have to be enabled explicitly for security reasons.

So simply speaking, you can then communicate with the Xserver using those
sockets to display things, and this I wouldn't be surprised to find
some Assembly
libraries to assist in talking "sockets" ;^P


However!!!! Enters FAST OpenGL:
 To get the performance out of the OpenGL chipsets, X's standard methods have
to be circumvented, and that's where DRI ec. enters, so you have a
direct connection
to the chipset/GPU to make things faster than the X protocol (Yes, X might
be in need for a redesign to help in this regard...IMHO). To make
things even more
complicated, ATI & nVidia have their own libraries that talk
secretively to their
own kernel modules (which is sorted closed sourced :() to be able to talk
to their GPUs :(

 The only way I currently see you having access to those ATI & nVidia
GPUs is via the
cg stuff where you can download a small cg program on to the GPU(s),
but that's a
different kettle of fish...

Hope that is a tad informative :)

Note1: These guys like ATI and nVidia, implement *LOTS* of stuff in
software, and
then only hand certain stuff to the processing units on the GPU(s) to
do, depending
on the GPUs abilities, and they don't even tell you always the exact
abilities of each
GPU all the time :( it's all about marketing etc. etc. etc. and finetuning
libraries to make benchmarks go faster etc. etc. etc.... but it appears to
be a neccesary evil we'll have to be content with for now :(

-- 
Hendrik Visage

Re: GAS colorr pixel problem

[Claudio Fontana]

Hello,

--- Hendrik Visage <hvjunk@gmail.com> wrote:

> I believe you'll
> find code snippets etc. on using it inside Linux in
> both SVGAlib and X, but
> sometimes the "problem" might be that you'll need to
> do a realmode BIOS call
> (yuck) to get things initialized... correct me if
> I'm wrong here...

Source code of SVGAlib shows how it is done.

>  SDL:
> I'm sometimes surprised on how long this has
> survived!! 

I am not. SDL is likely to stay.
OpenGL is not a replacement for SDL, they are
different things.
You can use both, and typically this is what happens
for graphic-intensive 3D games (for example
Neverwinter Nights, or UT-200x).

> However, X consists of a protocol (There is/was an
> O'Reilly book out
> in a series of X that described that protocol fairly
> in depth...) 

http://www.sbin.org/doc/Xlib/

Happy new year,

Claudio


__________________________________________________
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it