Skip to contentSkip to conversation

Using asm to develop GUI under framebuffer environment

DISCUSSION Lawrence 2 participants 4 messages Feb 25, 2004 – Feb 29, 2004 1 message not in the archive

lore
Share & tools
lore

Lawrence

author
#0 lore raw

Hi Linux Assembly Gurus,

I have some experience in developing a desktop environment using PharLap's asm toolkit. I am very interested in doing the same thing under Linux.

Because of the GUI nature, I usually redirect the output of the debugger into another computer's terminal, so that the UI being debugged can be seen.

I would like to know if there is a nasm specialized debugger that can do such remote debugging under Linux, or are there any workaround for this issue.

Thanks and Regards,
Lawrence

#1 lore raw

hum, what about working with SSH ?
I think it may be the best choice!
You may also use a deported X screen (no X serveur on the computer on which you are working for your GUI, but on an other machine on which you can deport your screen, to debug, play with tetris and send mails... ;) ) If you come from windows and are not aware of the power of unix, ask me precisions...

Fred

Quoted 23 lines · Lawrence

Hi Linux Assembly Gurus,

I have some experience in developing a desktop environment using PharLap's asm toolkit. I am very interested in doing the same thing under Linux.

Because of the GUI nature, I usually redirect the output of the debugger into another computer's terminal, so that the UI being debugged can be seen.

I would like to know if there is a nasm specialized debugger that can do such remote debugging under Linux, or are there any workaround for this issue.

Thanks and Regards,
Lawrence

-
To unsubscribe from this list: send the line "unsubscribe linux-assembly" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

#3 lore raw

Hi Lawrence,
telnet is a 'unsecure' 'old' way of connecting to a remote host. I guess you are at home, so security is not the priority, and you are using windows in your second host, so, the 'old' side of telnet is not a problem. (plus, if you use windows, security seems not to be your priority too...) ;) I must admit that I don't use ald.

See following comments...

Selon Lawrence <[email protected]>:

Quoted 7 lines

Hi Frederic,

Thanks for your kindly reply. I keep thinking about your inspiration these days (and that's the reason for my late reply). Since I am not quite familiar with SSH, I tried to telnet into my linux box under MS Windows, and debug the attached framebuffer example asm file I found on

Quoted 7 lines

http://www.nk.rim.or.jp/~jun/lxasm/exasm.tar.gz

using ald. the screen do appear rightly on the linux console, while the debugging process is shown on my telnet window.

I don't know if this operation is right, as I only step over a few command, then I pass the 'continue' command to ald and let it run.

It seems to do what you want, so it seems to be right, no? ;) That's the way I suggested, with SSH.

Quoted 3 lines

Moreover, the example open /dev/fb0 directly, I am not sure if it is
because this act that make the output rightly go into the linux console but not on my telnet screen.

In Unixes (and so, Linux), "all is file" (the primary rule of Unix). In fact, /dev/fb0 is a file that has no physical reality on disk. It is just an entry in the filesystem that point to a kernel API. If you write something to this 'file', in fact, it send the data to the associated driver. The driver (in the kernel) can be accessed that way, very easily! There is nothing magic, you can read what drivers do in the kernel sources.
In general, you send command to the driver with ioctl (Input/Ouput ConTroL, see the related man page), and large data with regular read/writes. For FrameBufer, for exemple, you send change modes request thru IOCTL, and graphic data thru writes.

The FrameBuffer acts directly on your graphic card, so, on the host that is running the prog hardware. The telnet is just a terminal emulation. It a very simple protocole that works in lot of TEXT termials (VT100 for exemple).

Quoted 2 lines

Would you please be so kind as to tell me if I am wrong?

Is what you do not what you wanted to do? If it is, you are right! ;)

Fred

Quoted 47 lines

Thanks and Regards,
Lawence

Quoted 41 lines

hum, what about working with SSH ?
I think it may be the best choice!
You may also use a deported X screen (no X serveur on the computer on which you are working for your GUI, but on an other machine on which you can deport your screen, to debug, play with tetris and send mails... ;) )
If you come from windows and are not aware of the power of unix, ask me precisions...

Fred

Quoted 25 lines · Lawrence

Hi Linux Assembly Gurus,

I have some experience in developing a desktop environment using PharLap's asm toolkit. I am very interested in doing the same thing under Linux.

Because of the GUI nature, I usually redirect the output of the debugger into another computer's terminal, so that the UI being debugged can be seen.

I would like to know if there is a nasm specialized debugger that can do such remote debugging under Linux, or are there any workaround for this issue.

Thanks and Regards,
Lawrence

-
To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

author
#4 lore raw

Hi Frederic,

Thank you very much for your comment and time. This way I can start to experiment with the linux framebuffer!

Best Regards,
Lawrence

[email protected] ??:

Quoted 86 lines

Hi Lawrence, telnet is a 'unsecure' 'old' way of connecting to a remote host. I guess you are at home, so security is not the priority, and you are using windows in your second host, so, the 'old' side of telnet is not a problem. (plus, if you use windows, security seems not to be your priority too...) ;) I must admit that I don't use ald.

See following comments...

Selon Lawrence <[email protected]>:

Quoted 11 lines

Hi Frederic,

Thanks for your kindly reply. I keep thinking about your inspiration these days (and that's the reason for my late reply). Since I am not quite familiar with SSH, I tried to telnet into my linux box under MS Windows, and debug the attached framebuffer example asm file I found on

http://www.nk.rim.or.jp/~jun/lxasm/exasm.tar.gz

using ald. the screen do appear rightly on the linux console, while the debugging process is shown on my telnet window.

I don't know if this operation is right, as I only step over a few command, then I pass the 'continue' command to ald and let it run.

It seems to do what you want, so it seems to be right, no? ;) That's the way I suggested, with SSH.

Quoted 3 lines

Moreover, the example open /dev/fb0 directly, I am not sure if it is because this act that make the output rightly go into the linux console but not on my telnet screen.

In Unixes (and so, Linux), "all is file" (the primary rule of Unix). In fact, /dev/fb0 is a file that has no physical reality on disk. It is just an entry in the filesystem that point to a kernel API. If you write something to this 'file', in fact, it send the data to the associated driver. The driver (in the kernel) can be accessed that way, very easily! There is nothing magic, you can read what drivers do in the kernel sources. In general, you send command to the driver with ioctl (Input/Ouput ConTroL, see the related man page), and large data with regular read/writes. For FrameBufer, for exemple, you send change modes request thru IOCTL, and graphic data thru writes.

The FrameBuffer acts directly on your graphic card, so, on the host that is running the prog hardware. The telnet is just a terminal emulation. It a very simple protocole that works in lot of TEXT termials (VT100 for exemple).

Quoted 4 lines

Would you please be so kind as to tell me if I am wrong?

Is what you do not what you wanted to do? If it is, you are right! ;)

Fred

Quoted 37 lines

Thanks and Regards, Lawence

Quoted 28 lines

hum, what about working with SSH ? I think it may be the best choice! You may also use a deported X screen (no X serveur on the computer on which you are working for your GUI, but on an other machine on which you can deport your screen, to debug, play with tetris and send mails... ;) ) If you come from windows and are not aware of the power of unix, ask me precisions...

Fred

Quoted 17 lines · Lawrence

Hi Linux Assembly Gurus,

I have some experience in developing a desktop environment using PharLap's asm toolkit. I am very interested in doing the same thing under Linux.

Because of the GUI nature, I usually redirect the output of the debugger into another computer's terminal, so that the UI being debugged can be seen.

I would like to know if there is a nasm specialized debugger that can do such remote debugging under Linux, or are there any workaround for this issue.

Thanks and Regards, Lawrence

-
To unsubscribe from this list: send the line "unsubscribe linux-assembly" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/