bgarrels / coffee-os Goto Github PK

VBE3 requires use of 16-bit segments not possible to jump to at this time.

no extended pascal support on writeln() yet, so keep the strings simple. Do not 
mix types YET. You cannot mix anything with a string and expect the kernel to 
build. Convert it TO a string, first. Writeln still works due to a RTL glitch 
in FPC.

If you need a line by itself use:
writeLINE;

for writing strings use:
writestring or writestrln

[deleted issue]

No TimeZone support yet.
No widechar, UTF support yet.[though maybe only in system unit]

Jazz has not gotten this far. Feel free if you wish to donate time on this.

Support CANNOT be removed..it is too cumbersome to rewrite the RTL.
Writeln is effectively blacklisted due to this, though the function works.

initRD code is under evaluation for inclusion..

we dont really need one if GRUB can boot us. And RESCUE GRUB DISK can find a 
LOT to boot from.....

this is to pre-init hd access code and such as usb drivers...why not include 
them in the kernel to begin with and solve this problem?

This is a good start for implementing FAT/VFS access to other partition types, 
will re-evaluate this after i match the C code with what should be written in 
FPC. I have code to access the hard drive, I just havent gotten that far yet.

Paging and tasking need to settle first.

The Paging/Threading code is suspended upon further review.
Aparently some devs at osdever and Mike all seem to point to one thing:

1) The code works as-is(with the assumption that C ports ok to Pascal).
2) The kernel is mapped somehow by magic to 4MB or 3GB pageDir entry.[solved]

3) These HobbyOS devs must be building a project for class and not an actual OS 
or solution to someone's BAD code problems in C.(as I am)


Fixing #2 causes the following:

This causes a GPF in QEMU with:
      'Access beyond END of RAM'

Triple faulting on the paging unit is caused by not properly mapping[copy the 
kernel to another address and marking space as KernelMode, Writable, and 
InUse.] the kernel to another location before transfering control back to the 
processor and enabling paging. 

Anything else is a problem with allocation between Heap, PMM, and Paging(VMM) 
units. These problems have been fixed.

This is a headache to fix to say the least. Apparently this was an issue with 
windows at some point. I have to dive further into Linus' kernelbase in C to 
work out a viable solution. In the meanwhile, these units are disabled, but 
should be fully functional. The logic is properly implemented.(I will adjust 
the tasking code upon further review(it just builds for the moment) DO NOT 
ATTEMPT to ALLOC/FREE beyond end of physical ram or emulated ram in the 
meanwhile. QEMU will crash if you attempt to do so.

Use FLAT PMM memory model and HEAP as needed for now. These units work ok.

--Jazz

apparently no one has heard of 'Ill be with you in a jiffie.'
..what? no hedgehogs around??

The heap is in flux. We did not leave the code from FPOS in a stable state.

HEAP is normally USERMODE memory management of a linked list(stacked chunks of 
choclate instead of a stack of papers in order).Hence the C is a bit messy.

HEAP must be initialized when the papging unit(VMM) prepares to flip the paging 
bit.From then on, HEAP automagically allocated and frees ram by variable, 
paging unit/heap unit work as one to allocate/free by page(4K chunk) as the OS 
requires it.

A lot of units here on out require RAM(therfore HEAP) to function. Once this 
unit is fixed, we can move on.

I have reworked some of BrokenThorn examples from C at the moment, I am merging 
in FPOS code and parts from the FPC RTL.Code is currently UNSTABLE.

[deleted issue]

PCI CANNOT be implemented, nor USB......ETC. until HEAP is finished.

PCI unit needs some rework.

[deleted issue]

[deleted issue]

currently this is in ALPHA state and UN USEABLE. Its only use anyways is 
setting up hardware until I can get Protected mode access to work in some 
manner(no matter how degraded).

Testing a new theory.

**BROKEN**

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

Golly, what HELL this is trying to implement correctly.

Yet, still when we do so, init fails.
it either GPFs or reboots qemu. Code does NOT triple fault.QEMU catches this 
and the OS catches a double fault.

Code to init VMM has been commented out.
As a result interrupts now work and so does the rest of the OS.
Heap is enabled at kernel level to allow FLAT mode memory programming instead 
for the moment.

AKA: drivers and other programming can continue until problem is fixed.
THIS is a SERIOUS issue with any decent OS.