Draft 002 of D kernel [2003 sep 08]

get the sources dkernel.002.tgz

This has a bit more in D, and the GC now WORKS :)

This version just scans the PCI bus (on real hardware/vmware[untested] but not bochs as ports 0xCF8/0xCFC just return 0xFF...FF on bochs, it does have a PCI bios so I may try interacting with that later.)
From this root, I intend to create two branches

• one real OS where the isr causes a device driver thread to be sheduled on iret (obviously required multi threading and locks and all manner of other stuff). this requires several stacks, locking primatives (I will try to do away with buzy spin locks, I think I can .....) the threading choises are
  • Software task switching
  • Hardware (TSS)
  • a mix of the two, TSS's used to allow hardware task switching and task gates for some isr's, with software task switching within a given hardware task.
  not sure which is the best, and not sure when to start paging too, and if I should start using segmenting to protect memory areas (move stacks out of data segment [will work if pointers to stack items are disallowed, not sure how it effects DMD with inout/out params {yet}])
• one "DOS" style kernel, single thread, isr's do a little more work, the core/user code is responcible for calling `Thread.yeild()` to allow the OS to call system registered call backs to run to process data recv'd etc. this kernel does not require any manipultion of cpu reg's at all and only one stack. as its uni processor only, no locks (the odd cli/sti but very few) required anywhere. basically just for playing with, but very fast. (USB may be a pain, I've yet to decipher the way packets are sent to see if polled USB messaging can be achived).

Draft 001 of a D kernel [2003 sep 06]

get the sources dkernel.001.tgz

This is build with the linux DMD 0.71, as that can output elf objects which can be linked with gcc and gas compiled files

this project will build a 1.44M boot floppy, works on Bochs and real hardware (Duron 800) the basic kernel is loaded by a very simple boot sector that puts the CPU into 368 protected mode NO paging 2 segments, one code one data both (0..4G) at ring 0 [I still managed the odd GPF during testing], the 32 bit image is loaded at 128K and run from there it has no mem managment to speak of, just allocats from 2M onwards as requested by the D GC

The GC for some reason is missing the statics (even though I do seem to be registering the correct data and bss area), the GC obviously walks the stack o.k.

DON'T expect all of D's features to work, for instance I've yet to dare to throw an exception.
there are more files that require moving into the build env, I have only included just enough to get this to run (as the bootloader is currently limited to 64K and the kernel is currently just under 32K).
although the boot loader should be able to load (limit is at 512K (as it loads at 128K)) and is only in real mode. (640K mem only) so a three stage boot might be an option if I can ever fathom out how to start a v86 task to make bios calls, or make the kernal relocate its self (he current c code is very small the boot loader could be 512 bytes of boot loader then 512/1K of relocator (32 bit no paging) with 510K max of kernal code designed to be run from 1M leaving the lower 1M free for dma/kernal buffers (rather than shared kernal code+buffers)

my other stuff .... D Win32 COM and other D stuff