Hi all

I updated the vga driver, made some bugfixes, added a stop routine that
switches to the previous video mode and a bitblt to draw sprites (I  hate
bit shiftings *g*). Found 2 bugs in the jvm -> idiv and irem. 

I will update (send code to John-> still no cvs access) the code when
the general driver implementation is done (end of this week, I guess).

The problem is the speed: I think we (Hilary?, you have done something
similar) should implement a native memcopy to speed up the vga output. 

vga and speed:
To avoid flickering, you have to write into the vga-mem when the vertical
retrace is active. the memcopy should be finished before the vertical
retrace ends. If not, you will see the sprite flickering. The current
speed of the write8/16/32 is to slow to finish before the vertical retrace
gets inactive.


Thomas Bocek


On Wed, 25 Aug 1999, Todd L. Miller wrote:

>       Implemented synchronized methods; implemented virtual consoles in
> a java daemon, `consoled', though I've decided against implementing a
> screen-redraw hack, waiting for the VGA driver to mature instead.  Began
> to implement throws/exceptions for the native code, within interp.cc.
> Tried to do a little housecleaning w.r.t. to the tools/ directory in CVS.
> 
>       Hopefully, I didn't break anything.  Added a few builtins for
> keyboard emulation (very basic) and to allow the vga driver to 'run.'  (At
> least, with 24 MB on the emulation's heap, until the JVM halts, out of
> memory.)
> 
>       Up next is testing checking if a method is native before trying to
> look it up in the builtins hash, which may lead to classpath integration
> (and a fully functional class library!).  Or maybe getting GC to work, but
> we'll see.
> 
> -_Quinn
> 
> 
> _______________________________________________
> Kernel maillist  -  [EMAIL PROTECTED]
> http://jos.org/mailman/listinfo/kernel
> 


_______________________________________________
Kernel maillist  -  [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel

Reply via email to