Most of the units may be partially completed such as Mouse and Keyboard handler.
This is expected for now and will be fixed nearing version 1.0. Most extra
keypresses(though known internally) are passed onto user mode apps and have no
low-level function to catch the keypress.
This is why most dos apps hook the keyboard vector or use readkey(or variants
of it) instead.This is ok, but the interrupt will fire anyways, so it better be
handled.
Mouse has partial cursor support for this reason as it depends on INT 10 video
updating to occur, which is not currently implemented due to DPMI issues with
FPC in *NIX. For FREEDOS this requires a full non-macroed isr hook, a lengthy
process on all 256 vectors. So if this code looks familiar it is because it IS
familiar. This is how you do it without using assembler macros.
Other units are in flux awaiting dependency units, such as USB waiting on PCI
waiting on Heap/memory allocator/virtual memory manager(paging).
Do not expect detailed hardware specs, like Linux' C kernel. Generic functions
work just as well and save a TON of time and headache. I will only look at
hardware that does not fall into this bracket otherwise.
and for those that care:
VESA is as slow as YOU want it to be. VESA is slow with X11 because of the piss
poor implementation of VESA and OpenGL and crappy way X11 interfaces to the
hardware. DOS has much better support. We are ignoring windows code as it does
not apply.
You can test this on a 32-bit DPMI dos application that uses VESA. If I can
trip the VESA modes in 32-bit DOS, SO CAN YOU. Linux in this case is just a
different way of building the rest of the OS into existance. A more efficient
way, as it were.
--Jazz
Original issue reported on code.google.com by frazzled...@gmail.com on 19 Jun 2011 at 8:27
Original issue reported on code.google.com by
frazzled...@gmail.comon 19 Jun 2011 at 8:27