Using INT 0x10 gives a way for the driver to be implemented in very
"portable" code though it would run much slower. Using the Mode 0x13
frame buffer over INT 0x10 usually yields 2x speed improvement
(minimal). However, the portable code look a little like this:
/*
This is not a real method in NanoX but has the same functionality
as one that is in NanoX.
Would set a pixel "portably"
*/
void NG_PutPix( GRAPHICS g, unsigned short x, unsigned short y,
COLOR c )
{
if( g == VIEWABLE_SCREEN )
{
union regs r;
r.x.ax = DRAW_PIXEL_FUNCTION;
r.x.bh = VIDEO_PAGE_0;
r.x.bl = c->toInt();
r.x.dx = ( ( x < SCREEN_WIDTH ) ? x : SCREEN_WIDTH );
r.x.cx = ( ( y < SCREEN_HEIGHT ) ? y : SCREEN_HEIGHT );
int86( VIDEO_INTERRUPT, &r, &r );
}
else
{
g->buffer[ y ][ x ] = c->toInt();
}
}
/*
I cant tell you if this code actually works...but similar would
probly be best
*/
Louis
On Tue, 11 May 1999, Luke (boo) Farrar wrote:
>
>
>
> On Tue, 11 May 1999, Eric J. Korpela wrote:
>
> >
> > > o MSDOS driver support. I wrote a 640x480x16 color driver in about 45 minutes.
> > >NanoX now runs on DOS! (OK, I did this only to see how portable nanoX
> > >is, and the
> > >mouse driver still isn't written) This still uses MSC graphics library.
> > >I'll have the bios
> > >int10 version driver done shortly, which will allow nanoX to run on
> > >ELKS! We should
> > >have an ELKS version shortly... BTW, the nanoX kernel is around 20k on DOS...
> >
> > Does anyone else agree with me that direct int 10 access is a mistake?
> > Wouldn't access through a device driver be a bit more unixy? It would
> > be able to prevent multiple processes from trying to access int 10 services.
> >
> > Eric
> >
> >
> >
> What are the major bonuses of Int10 over the device driver? (If any).
> Luke(Boo) Farrar.
>
>
>
>
