public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Software interrupt
@ 2008-02-28 20:02 Antoine.Amirault
  2008-02-28 20:19 ` Andrew Lunn
  0 siblings, 1 reply; 5+ messages in thread
From: Antoine.Amirault @ 2008-02-28 20:02 UTC (permalink / raw)
  To: ecos-discuss

Hi!

I'm trying to write on the VGA buffer of a PC at the 0xa0000 address  
on graphical mode (and not text).

I wrote a C program using interruption in ASM, trying to switch into  
graphical mode :

asm volatile ( " movl $0x0013,%eax; int $0x10; " )

But apparently, it doesn't work.
  I think it's because the int mnemonic hasn't any effect.

Do you know how to use software interrupt under eCos (with or without  
the HAL)?

Or do you know another way to write something on a screen by writing  
on the video buffer?
I've managed to print some characters by writing directly in the text  
buffer at the 0xb8000 address, but it doesn't work for the video buffer.

In summary, is there another way to emit software interruption ?

Thank you for your help.
Regards.
Antoine AMIRAULT


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [ECOS] Software interrupt
  2008-02-28 20:02 [ECOS] Software interrupt Antoine.Amirault
@ 2008-02-28 20:19 ` Andrew Lunn
  2008-02-29 16:21   ` Antoine.Amirault
  0 siblings, 1 reply; 5+ messages in thread
From: Andrew Lunn @ 2008-02-28 20:19 UTC (permalink / raw)
  To: Antoine.Amirault; +Cc: ecos-discuss

On Thu, Feb 28, 2008 at 09:01:44PM +0100, Antoine.Amirault@esial.uhp-nancy.fr wrote:
> Hi!
>
> I'm trying to write on the VGA buffer of a PC at the 0xa0000 address on 
> graphical mode (and not text).
>
> I wrote a C program using interruption in ASM, trying to switch into  
> graphical mode :
>
> asm volatile ( " movl $0x0013,%eax; int $0x10; " )
>
> But apparently, it doesn't work.
>  I think it's because the int mnemonic hasn't any effect.
>
> Do you know how to use software interrupt under eCos (with or without  
> the HAL)?
>
> Or do you know another way to write something on a screen by writing on 
> the video buffer?
> I've managed to print some characters by writing directly in the text  
> buffer at the 0xb8000 address, but it doesn't work for the video buffer.
>
> In summary, is there another way to emit software interruption ?

Is this to do with real and protected mode? I no nothing about this,
but there has been some discussion about similar things in the
past. So check the email archive. But i think the processor is in the
wrong mode to be able to call the BIOS.

      Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [ECOS] Software interrupt
  2008-02-28 20:19 ` Andrew Lunn
@ 2008-02-29 16:21   ` Antoine.Amirault
  2008-03-01 11:32     ` Bart Veer
  0 siblings, 1 reply; 5+ messages in thread
From: Antoine.Amirault @ 2008-02-29 16:21 UTC (permalink / raw)
  To: ecos-discuss

Hello,

First, thank you for answer.

I studied the question : how to switch in real mode ? but it seems to  
be hardest than switching into protected mode. I found a trick about  
real mode : when CPU is in protected mode, we have to save all CPU  
registers and reset it. Is it normal to be obliged to do this kind of  
operation ?

I've an other idea, but it's very brutal : it's to do the work of the  
0x10 interruption, and go write directly in the VGA control registers.  
I suppose this works, but it's very heavy to do.

I read and read again the eCos documentation, but I don't undestand if  
there's any function or macro (using HAL or kernel functions) allowing  
me to emit software interruption rather than using ASM.

An other question, CPU isn't supposed to start in real mode ? If this  
is wrong, it's seems to be very hard to come back in real mode ! It's  
strange to go write directly in CPU or VGA card register, i think  
(hope) that there's some methods doing this difficult job.

My aim is simply to display pixel on screen, by all way. this one of  
my ideas, if you have another one, fell free to explain it

Regards.
Antoine


Andrew Lunn <andrew@lunn.ch> a écrit :

> On Thu, Feb 28, 2008 at 09:01:44PM +0100,   
> Antoine.Amirault@esial.uhp-nancy.fr wrote:
>> Hi!
>>
>> I'm trying to write on the VGA buffer of a PC at the 0xa0000 address on
>> graphical mode (and not text).
>>
>> I wrote a C program using interruption in ASM, trying to switch into
>> graphical mode :
>>
>> asm volatile ( " movl $0x0013,%eax; int $0x10; " )
>>
>> But apparently, it doesn't work.
>>  I think it's because the int mnemonic hasn't any effect.
>>
>> Do you know how to use software interrupt under eCos (with or without
>> the HAL)?
>>
>> Or do you know another way to write something on a screen by writing on
>> the video buffer?
>> I've managed to print some characters by writing directly in the text
>> buffer at the 0xb8000 address, but it doesn't work for the video buffer.
>>
>> In summary, is there another way to emit software interruption ?
>
> Is this to do with real and protected mode? I no nothing about this,
> but there has been some discussion about similar things in the
> past. So check the email archive. But i think the processor is in the
> wrong mode to be able to call the BIOS.
>
>       Andrew
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>




--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [ECOS] Software interrupt
  2008-02-29 16:21   ` Antoine.Amirault
@ 2008-03-01 11:32     ` Bart Veer
  2008-03-01 14:51       ` [ECOS] Ix86 Multi Processor Steve West
  0 siblings, 1 reply; 5+ messages in thread
From: Bart Veer @ 2008-03-01 11:32 UTC (permalink / raw)
  To: Antoine.Amirault; +Cc: ecos-discuss

>>>>> "Antoine" == Antoine Amirault <Antoine.Amirault@esial.uhp-nancy.fr> writes:

    Antoine> Hello,
    Antoine> First, thank you for answer.

    Antoine> I studied the question : how to switch in real mode ? but
    Antoine> it seems to be hardest than switching into protected
    Antoine> mode. I found a trick about real mode : when CPU is in
    Antoine> protected mode, we have to save all CPU registers and
    Antoine> reset it. Is it normal to be obliged to do this kind of
    Antoine> operation ?

    Antoine> I've an other idea, but it's very brutal : it's to do the
    Antoine> work of the 0x10 interruption, and go write directly in
    Antoine> the VGA control registers. I suppose this works, but it's
    Antoine> very heavy to do.

    Antoine> I read and read again the eCos documentation, but I don't
    Antoine> undestand if there's any function or macro (using HAL or
    Antoine> kernel functions) allowing me to emit software
    Antoine> interruption rather than using ASM.

    Antoine> An other question, CPU isn't supposed to start in real
    Antoine> mode ? If this is wrong, it's seems to be very hard to
    Antoine> come back in real mode ! It's strange to go write
    Antoine> directly in CPU or VGA card register, i think (hope) that
    Antoine> there's some methods doing this difficult job.

    Antoine> My aim is simply to display pixel on screen, by all way.
    Antoine> this one of my ideas, if you have another one, fell free
    Antoine> to explain it

There are a number of ways to approach this, but none of them are
straightforward.

The int10 video bios calls can only be made in 16-bit real mode. eCos
runs in 32-bit protected mode, so cannot access the video bios
directly. If you must invoke int10 then there are two approaches:

  1) set up a 16-bit virtual machine within the 32-bit protected mode
     and use that to invoke the video bios. This is hard, not to
     mention nearly impossible to debug. You will need to study some
     books like Mindshare's "Protected Mode Software Architecture" and
     maybe a couple of others in the series to understand what is
     involved. Linux already has code to do this and BSD may have as
     well, but eCos does not. Before trying to use any existing code
     you will want to check licensing issues, e.g. I suspect the Linux
     code will be vanilla GPL.

  2) an alternative way of running the 16-bit video bios code would be
     to include an x86 instruction set simulator in your application
     and execute the bios call inside the simulator. I suspect there
     is some suitable code out there already, dosbox may be worth a
     look.

The next approach is to try to access the video bios in 32-bit
protected mode. In theory this is supposed to be supported by modern
graphics cards, but when I tried it back in 2002 it did not work on
the card I was using. You may have more luck nowadays, depending on
the vintage of your graphics card. If you want to investigate further,
a starting place is http://en.wikipedia.org/wiki/VESA_BIOS_Extensions

A third approach is to access VGA hardware directly. Unfortunately the
VGA standard is probably one of the most convoluted hardware designs
ever. You will probably need a book like Ferraro's "Programmer's Guide
to the EGA and VGA Cards" to make any sense at all out of the
hardware. You will probably want to concentrate on mode 13, giving you
a 320x240 8bpp paletted display. Again you should be able to find
existing code for this. If you need a higher resolution then you are
going to need code specific to your graphics card, and you may find it
difficult to get hold of the required documentation.

Another approach is to use the existing configuration option
CYGNUM_HAL_I386_PC_STARTUP_VIDEO_MODE. The idea here is that a very
small part of RedBoot still runs in 16-bit real mode, prior to
switching to 32-bit protected mode, so that code can make an int10
video bios call. If you rebuild RedBoot with that option enabled and
set to a suitable mode, when you next reboot the PC using that RedBoot
the display should be set appropriately and an application run on top
of RedBoot can access it. Exactly what video modes are available and
the layout and location of display memory will depend on your graphics
hardware, so some experimenting will be needed.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [ECOS] Ix86 Multi Processor
  2008-03-01 11:32     ` Bart Veer
@ 2008-03-01 14:51       ` Steve West
  0 siblings, 0 replies; 5+ messages in thread
From: Steve West @ 2008-03-01 14:51 UTC (permalink / raw)
  To: ecos-discuss

I am interested in running a dual core Pentium with eCos. I have a few 
questions. I am running Intel Pro 1000 and an IDE driver. What would you 
suspect would need spinlocks for the dual proc? How many CPUs will eCos 
handle.

Steve 


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2008-03-01 14:51 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-28 20:02 [ECOS] Software interrupt Antoine.Amirault
2008-02-28 20:19 ` Andrew Lunn
2008-02-29 16:21   ` Antoine.Amirault
2008-03-01 11:32     ` Bart Veer
2008-03-01 14:51       ` [ECOS] Ix86 Multi Processor Steve West

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).