lately i have restarted to work at my own OS :). i have a vorking version with INTs for timer and keyboard and memory segments in PM but now i face a new problem:
-S(VGA) grafix and the mouse

I know i can look or c/p some code from Menuet or other Open Source OS but i kind of like to make my own stuff and to deeply understand everyting i do.

So any o you guys have any low level hardware/software info on:

1.Interfaceing with the mouse both serial and PS2 at IRQ level

2.Standard Hardware video acceleration for cursor placement (ie no xor draw if possible)

3.Getting and setting video modes in Protected Mode, eventually not using VESA? or switching back to 16 bits real/V86 mode to do it?

4.What do you think is "safe mode" for current video adapters? Should i use 640x480x16colors as windows does (vga mode 12 i belive)? or go for 800x600x256 colors from start?

I was also thinking to make the new OS able to load/run standard PE files?

Thx a lot,
Posted on 2002-01-12 11:33:47 by BogdanOntanu
have you tried looking at the message boards at programmers haven? they have alot of good info on low level programming. i did a search for mouse driver and.. wow there is alot of info. also i noticed one thread that ill post here:

Go to the Simtel site (below) and search in the DOS area for "CTMOUS". Download the Cute Mouse Driver - it contains source code for PS/2 and Serial mouse drivers. It uses the BIOS to detect and control the PS/2 mouse, rather than direct interrupt control, though.

kinda interesting that one can use the bios to control the mouse.
Posted on 2002-01-12 14:57:04 by smurf
Some time ago I have written a DPMI server (stands for dos protected mode interface, as you probably know). So I know some of the problems arising. I also had implemented a PE loader and a kernel32.dll "simulator" (sounds like the TNT dos extender and it really had some similarities).

The source for the dpmi server itself (with interrupt handling, mode switching and memory manager) is a mess now and cannot be reused.

But for graphics mode switching I see no other possibility as to switch to real mode.
Mouse handling I would also do via switching to real mode.

How will you implement HD access? Just curious.

Posted on 2002-01-12 15:58:30 by japheth
Posted on 2002-01-12 19:17:33 by bitRAKE
Thx all

Smurf: i do not want to use BIOS (unless it has PMode extensions). I do not mind using the BIOS in the 16 bit section of the system loader fo detecting confihuration/memory etc; but once i switch to PMode i do not want to leave it anymore :)

So i need to manage ALL hardware in PMode

Yup... I will check the programmers heaven MB

Japeth: For HD acces i will use IDE/ATA drivers i guess that is easy. The hard part is designing a filesystem that is super fast and still easy to use/recover :). Anyway i will provide interfaces to FAT16/32 and Unix inode style filesystems also (maybe even NTFS)

Bitrake: Thx man i losted track of the UUU OS an now i found it again, but of course i do not agree with them :); i also found very little data on their site that could help me ... but its a nice looking site ;)
Posted on 2002-01-13 06:07:29 by BogdanOntanu
Bogdan, I urge you very much to use VESA, even if you have to
use V86 (there's pmode extension to vesa though, but I can't remember
if that's any more than bank switching). Programming graphics chipsets
directly will require drivers for many different cards, and... bleh :).
If you use the linear framebuffer feature of vesa2, you should only
need v86 for mode-information-query and mode-set, so this is not
too bad imo.

Concentrate more on solid fat16/fat32 (with VFAT long file names)
than making your own filesystem. Once VFAT system works good
(and you have a well-working cache system), you can think about
your own filesystem.

Using PE as the native executable format is a nice idea, since you
can reuse a lot of good existing tools (masm, C compilers, etc).
Perhaps you might want ELF support as well, but PE is nicer imo.

The information I've found on my (lazy) searches on mouse programming
have been sort of poor. It's easier to get wellworking sourcecode
than a good description :(.

Also, focus more on a robust kernel than mouse and graphics and
all that fluffy stuff ;). How does your system work? Segmenting (yeccch),
or flat protected mode?
Posted on 2002-01-13 07:25:52 by f0dder
Yup, i will use VESA for a start, do not know about V86 mode yet.

Memory model is indeed "Flat protected mode", but i guess it will be with paging disabled.

PE support will be ok but again i guess i will not support kernel32.dll imports :) so i do not know if MASM will work?

I also think i will do cooperative multitasking, as preemptive is too damn slow esp because it trashes the cache both secondary and TLB's (hehe but i will not have TLB's)

It will be mostly a full speed OS for GFX/games/demos/critical speed applications ;) so at the end i will have to use my own filesystem and Graphics/Mouse is a must from the start

Sad i can not get VESA acceleration standards dl without paying damn too much money that i will eventually not have for all of my life :( but i have the normal VBE 3.0 ones ;)
Posted on 2002-01-13 08:51:08 by BogdanOntanu
I have found what i needed about serial/mouse here:


may others need it too ;)
Posted on 2002-01-13 08:58:39 by BogdanOntanu
Bogdan, why no paging? It shouldn't slow down stuff (well, okay,
setting up paging takes a little more time, but that should sort of
only be at process-creation. From what I know, running with paging
enabled doesn't make the processor slower (except of course if
you rely heavily on pagefaults to do "stuff")).

Paging is imo very nice - separate processes in memory, allow only
linear space to be fragmented (easier to deal with than physical
fragmentation), and you can do nice stuff, like mapping the textmode
screenbuffer at the same address in all apps, and when an app
loses fullscreen control, you can point the buffer to a memory
buffer instead of direct control. When an app regains fullscreen
access, you can easily copy the memory buffer to the real screen
buffer. This would also make it easy to handle console apps running
under a windowed system :). Of course there are other ways to
handle this, but you can do nifty stuff with paging. Nobody says
you have to support swap/virtual memory if you don't want to :).

PE support... well, if you don't emulate/re-implement some standard
windows DLLs, masm will definitely not run under your OS. But masm-produced
apps certainly can. Re-implementing some of the base services of
some base DLLs is a good idea imo, because it's a familiar interface,
and the base Windows API is quite nice actually.

Cooperative multitasking... well, I think you can get quite efficient
preemptive multitasking, as long as your scheduler is properly coded.
Of course there's a speed loss compared to single-tasking (or coop
multitasking), but I think the benefits outweigh this. You should
really experiment with both forms, and see if there's any reasonably
measurable performance difference. Theory is one thing, real-life
is something else :). If you go for cooperative, at least make sure
it's always possible to interrupt the running task and kill it, so you
don't get a system that breaks down just because one app breaks down.

Vesa acceleration standards... hm, perhaps you should take a look
at allegro, I think it implements some VBE3 stuff, also acceleration?
You might want to have a look at the sources.

Also... shouldn't this thread be moved to The Heap? :).
Posted on 2002-01-13 09:08:14 by f0dder
There are some video cards that do not have vesa bios anymore. They rely on drivers.

I know because when I have a TNT2 card it had Vesa 3 on the bios, however the Gforce and GForce 2 that I have now don't have it.

So nowadays reliying on vesa bios on every card is not a sure thing. The only common denominator is VGA. So if vesa is not detected you will need to make a driver for the video card, or fallback to VGA mode.
Posted on 2002-01-13 13:11:10 by dxantos
I'm pretty sure my GF2 has a VESA bios on it...
Posted on 2002-01-13 13:17:17 by f0dder