I just wanted to know if there are any libraries with a keyboard driver in c that I could just link into the kernel source.
And does anyone know how to set up the irqs in c?
keyboard driver in c
-
Chris Giese
RE:keyboard driver in c
>On 2001-03-07 12:41:51, coindood wrote:
>I just wanted to know if there are any libraries with a keyboard driver in c that I could just link into the kernel source.
Hi,
You can use the keyboard code in my OS if you want:
http://www.execpc.com/~geezer/os/index.htm#cosmos
It's about 300 lines of commented C, not counting
the scancode #defines in conio.h
>And does anyone know how to set up the irqs in c?
It depends on the compiler. I can help you if
you are using any of these:
- Turbo or Borland C (16-bit real mode)
- DJGPP (GCC for DOS; 32-bit pmode; DPMI)
- x86 GCC (DJGPP or Linux; 32-bit pmode; no OS)
>I just wanted to know if there are any libraries with a keyboard driver in c that I could just link into the kernel source.
Hi,
You can use the keyboard code in my OS if you want:
http://www.execpc.com/~geezer/os/index.htm#cosmos
It's about 300 lines of commented C, not counting
the scancode #defines in conio.h
>And does anyone know how to set up the irqs in c?
It depends on the compiler. I can help you if
you are using any of these:
- Turbo or Borland C (16-bit real mode)
- DJGPP (GCC for DOS; 32-bit pmode; DPMI)
- x86 GCC (DJGPP or Linux; 32-bit pmode; no OS)
-
coindood
RE:keyboard driver in c
>On 2001-03-08 21:54:35, Chris Giese wrote:
>>On 2001-03-07 12:41:51, coindood wrote:
>>I just wanted to know if there are any libraries with a keyboard driver in c that I could just link into the kernel source.
>
>Hi,
>
>You can use the keyboard code in my OS if you want:
>http://www.execpc.com/~geezer/os/index.htm#cosmos
>
>It's about 300 lines of commented C, not counting
>the scancode #defines in conio.h
>
>>And does anyone know how to set up the irqs in c?
>
>It depends on the compiler. I can help you if
>you are using any of these:
>- Turbo or Borland C (16-bit real mode)
>- DJGPP (GCC for DOS; 32-bit pmode; DPMI)
>- x86 GCC (DJGPP or Linux; 32-bit pmode; no OS)
>
I am using gcc, and one last thing, how do you get headerfiles
to get included? the only way I got them to work was to compile
them into .o files and link them in. I know it sounds stupid, but
I've been doing all the compiling and linking by hand because
I don't know how to make makefiles well enough toactually be useable.
I'm going to download cosmos right away and try it out! thanks,
and I hope you read this!
>>On 2001-03-07 12:41:51, coindood wrote:
>>I just wanted to know if there are any libraries with a keyboard driver in c that I could just link into the kernel source.
>
>Hi,
>
>You can use the keyboard code in my OS if you want:
>http://www.execpc.com/~geezer/os/index.htm#cosmos
>
>It's about 300 lines of commented C, not counting
>the scancode #defines in conio.h
>
>>And does anyone know how to set up the irqs in c?
>
>It depends on the compiler. I can help you if
>you are using any of these:
>- Turbo or Borland C (16-bit real mode)
>- DJGPP (GCC for DOS; 32-bit pmode; DPMI)
>- x86 GCC (DJGPP or Linux; 32-bit pmode; no OS)
>
I am using gcc, and one last thing, how do you get headerfiles
to get included? the only way I got them to work was to compile
them into .o files and link them in. I know it sounds stupid, but
I've been doing all the compiling and linking by hand because
I don't know how to make makefiles well enough toactually be useable.
I'm going to download cosmos right away and try it out! thanks,
and I hope you read this!
-
Chris Giese
RE:keyboard driver in c
>On 2001-03-10 19:12:40, coindood wrote:
>>On 2001-03-08 21:54:35, Chris Giese wrote:
>>>On 2001-03-07 12:41:51, coindood wrote:
[setting up IRQs with GCC]
DJGPP has some functions for handling interrupts
under DOS/DPMI. GCC in general, however, has no
built-in support for interrupts, so you must use
some assembly language. Here is some skeleton
code:
http://www.execpc.com/~geezer/osd/intr/idt.asm
Watch out for these potential problems:
1. The argument to LIDT is unusual. It's the
address of a 6-byte "pseudo-descriptor". The
pseudo-descriptor contains the 2-byte IDT size
followed by 4-byte IDT linear address.
2. The IDT address in the pseudo-descriptor is a
LINEAR address. The address is not changed by by
segmentation like other addresses, so you must
translate it yourself.
3. The 32-bit handler offset in each interupt gate
is broken into two 16-bit chunks. This doesn't
work:
idt_gate_0:
dw (handler & 0FFFFh) ; bits 15-0 of offset
dw CODE_SEL ; selector
db 0
db 8Fh ; access byte
dw (handler >> 16) ; bits 31-16 of offset
NASM chokes on the shift (>>) operation. So, you
must build the IDT at run-time. This is not
difficult.
4. The BIOS programs the interrupt controller
chips (the 8259s) so that IRQs 0-7 use some of
the "reserved" interrupts. (This was a mistake
by IBM when they designed the PC.)You should
re-program these chips; maybe like this:
http://www.execpc.com/~geezer/osd/intr/8295.c
>I am using gcc, and one last thing, how do you get headerfiles
>to get included? the only way I got them to work was to compile
>them into .o files and link them in. I know it sounds stupid, but
If it works, it's not stupid
The .h files should not contain any function
bodies or variable declarations. Everything that
occupies memory (function bodies and global
variables) should go into the .c files. The .h
files should be #include'd, but not compiled by
themselves.
>I've been doing all the compiling and linking by hand because
>I don't know how to make makefiles well enough toactually be useable.
If your code is small and you have a fast PC, this is OK for now.
A crash course in makefiles:
1. Use macros as you would with C: to make the
file self-documenting, and to confine possible
changes to a small part of the file:
LIBOBJS =stdio.o string.o x86.o
OBJS =startup.o main.o io.o
LIBS =libc.a
LDSCR =coffkrnl.ld
LFLAGS =-T$(LDSCR)
CFLAGS =-Wall -W -I. -O2 -fno-builtin -mcpu=i486
AFLAGS =-f coff -dUNDERBARS=1
2. Use "explicit rules" for linking, and for
building libraries:
krnl.cof: $(OBJS) $(LIBS) $(LDSCR)
(tab) ld $(LFLAGS) -o$@ $(OBJS) $(LIBS)
libc.a: $(LIBOBJS)
(tab) ar rcs $@ $(LIBOBJS)
*** NOTE *** For the commands in the makefile
rules, you must use tabs at the beginning of the
line, not spaces. (Yes, this is stupid.) DO NOT
USE DOS EDIT FOR MAKEFILES.
3. Use "dependencies" plus "implicit rules" for
creating .o files:
# implicit rules
.c.o:
(tab) gcc -c $(CFLAGS) -o$@ $<
.asm.o:
(tab) nasm $(AFLAGS) -o$@ $<
# dependencies
startup.o: startup.asm
main.o: main.c
io.o: io.c
stdio.o: stdio.c
string.o: string.c
x86.o: x86.asm
*** NOTE *** GNU make doesn't recognize some
implicit rules unless you use a .SUFFIXES line
.SUFFIXES: .asm
4. If you just type "make", the first dependency
or explicit rule or "target" in the makefile will
be built. Usually, the first target is named
"all":
all: krnl.cof
>>On 2001-03-08 21:54:35, Chris Giese wrote:
>>>On 2001-03-07 12:41:51, coindood wrote:
[setting up IRQs with GCC]
DJGPP has some functions for handling interrupts
under DOS/DPMI. GCC in general, however, has no
built-in support for interrupts, so you must use
some assembly language. Here is some skeleton
code:
http://www.execpc.com/~geezer/osd/intr/idt.asm
Watch out for these potential problems:
1. The argument to LIDT is unusual. It's the
address of a 6-byte "pseudo-descriptor". The
pseudo-descriptor contains the 2-byte IDT size
followed by 4-byte IDT linear address.
2. The IDT address in the pseudo-descriptor is a
LINEAR address. The address is not changed by by
segmentation like other addresses, so you must
translate it yourself.
3. The 32-bit handler offset in each interupt gate
is broken into two 16-bit chunks. This doesn't
work:
idt_gate_0:
dw (handler & 0FFFFh) ; bits 15-0 of offset
dw CODE_SEL ; selector
db 0
db 8Fh ; access byte
dw (handler >> 16) ; bits 31-16 of offset
NASM chokes on the shift (>>) operation. So, you
must build the IDT at run-time. This is not
difficult.
4. The BIOS programs the interrupt controller
chips (the 8259s) so that IRQs 0-7 use some of
the "reserved" interrupts. (This was a mistake
by IBM when they designed the PC.)You should
re-program these chips; maybe like this:
http://www.execpc.com/~geezer/osd/intr/8295.c
>I am using gcc, and one last thing, how do you get headerfiles
>to get included? the only way I got them to work was to compile
>them into .o files and link them in. I know it sounds stupid, but
If it works, it's not stupid
The .h files should not contain any function
bodies or variable declarations. Everything that
occupies memory (function bodies and global
variables) should go into the .c files. The .h
files should be #include'd, but not compiled by
themselves.
>I've been doing all the compiling and linking by hand because
>I don't know how to make makefiles well enough toactually be useable.
If your code is small and you have a fast PC, this is OK for now.
A crash course in makefiles:
1. Use macros as you would with C: to make the
file self-documenting, and to confine possible
changes to a small part of the file:
LIBOBJS =stdio.o string.o x86.o
OBJS =startup.o main.o io.o
LIBS =libc.a
LDSCR =coffkrnl.ld
LFLAGS =-T$(LDSCR)
CFLAGS =-Wall -W -I. -O2 -fno-builtin -mcpu=i486
AFLAGS =-f coff -dUNDERBARS=1
2. Use "explicit rules" for linking, and for
building libraries:
krnl.cof: $(OBJS) $(LIBS) $(LDSCR)
(tab) ld $(LFLAGS) -o$@ $(OBJS) $(LIBS)
libc.a: $(LIBOBJS)
(tab) ar rcs $@ $(LIBOBJS)
*** NOTE *** For the commands in the makefile
rules, you must use tabs at the beginning of the
line, not spaces. (Yes, this is stupid.) DO NOT
USE DOS EDIT FOR MAKEFILES.
3. Use "dependencies" plus "implicit rules" for
creating .o files:
# implicit rules
.c.o:
(tab) gcc -c $(CFLAGS) -o$@ $<
.asm.o:
(tab) nasm $(AFLAGS) -o$@ $<
# dependencies
startup.o: startup.asm
main.o: main.c
io.o: io.c
stdio.o: stdio.c
string.o: string.c
x86.o: x86.asm
*** NOTE *** GNU make doesn't recognize some
implicit rules unless you use a .SUFFIXES line
.SUFFIXES: .asm
4. If you just type "make", the first dependency
or explicit rule or "target" in the makefile will
be built. Usually, the first target is named
"all":
all: krnl.cof