The Place to Start for Operating System Developers
https://f.osdev.org/
Does it actually do anything other than print out 100 MB in GB, KB, and bytes? 
This morning I have around an hour of spare time in which I plan to implement a proper keyboard driver (instead of implementing it within the TTY driver) that'll initialise the keyboard correctly - including emptying the buffer, doing a reset, etc...One thing you might want to try in bochs is to smack the keyboard a few times during boot to fill the buffer and see if the driver can empty that.
Seems to be quite simple, heheI broke it!
. I'll look into that bug as well, it looks like it's faulting within the shell - probably time for a rewrite.Thanks - backspace definitely works here. As I said before, I'm planning on moving the keyboard driver out of the TTY driver and at around the same time I hope to implement VT100 compatibility into the TTY driver. Then when I get around to rewriting the shell I can use the VT100 protocol instead of hacking my way through.Backspace still broken, attached .gif.
Depending on the amount of RAM you gave the system, there will always be a certain amount at startup (that's just a given). One of the main things I use meminfo for is to find leaks after loading, running, and unloading an executable. Because there's no support in the shell for background execution (which is of course possible) you shouldn't see it changing more than one or two pages.Thanks for the meminfo
) as well that would be great too!Sure. Just one tiny problem: I don't have access to my test cluster during the weeks, so if you can wait for that...pcmattman wrote:Combuster, would I be able to get you to test a floppy image if needed so I can figure out this keyboard/not init bug on your systems? I think I may have fixed the keyboard problem (I now do a full reset and initialise the keyboard in my KB driver) but the slow load time is worrying me.
) - for instance the "adjk!" thing still crashes.Code: Select all
Welcome blabla
== PAGE FAULT ==
EIP=0x108812, CS=0x8, PID=-1
CR3=0x451000, CR2=0x17
.
A typical Linux infrastructure: one bugged kernel with infinite number of bugged drivers with X numbers of patches and add-on programs, which make the system stable. A great loophole [joking]). That's definitely one of the things on my TODO list, just so you don't think I overlooked it Always helpfulTested on the same hardware...
It should not be taking that long. The problem is that all my testing is done on emulators which run at > 2 GHz, so while for me my code is blazing fast for you on a real computer which might be slower it can be painfully slow. If there's no text on the screen at all then it's taking a long time in the basic kernel initialization (which it shouldn't be).Booting from GRUB to the OS shell took suprising 30 seconds - it's somewhat slow.
See above about the SHIFT key. As for the non-alpha characters - I believe that's a bug in either my FAT driver or in my ramfs driver (either way, it's in a filesystem driverAfter booting, I realized that your OS didn't support uppercase characters - bug in SHIFT key. After writing "|_" what the shift key does and pressing ENTER, there was a page fault.
). I'm pointing at the FAT driver because that's the buggiest thing I've ever written.Maybe I should make it a headless server OSThe whole kernel as you can see crashed within 5 seconds of booting with mine "assistance".
Yes, that's known behavior. I haven't yet implemented proper support into my virtual terminals for things like backspace and other VT100 protocol elements. This is also a TODO.After rebooting, typing something and "backspacing it" moves the cursor back, but doesnt erase what has been written. I can "backspace" even the user prompt.
Again, most likely page fault thanks to a faulty FAT driver.When I backspace everything and hit ENTER, it will write "command not found" but when I type e.g. "helpp" or make these weird characters with the shift key, page fault immediately after pressing ENTER. The thing is, if i write "asôkdkjf" it wont page fault, but if I would write "helpp, meminfoa" it does.
You should've seen Mattise 2.0 - never released! I took on a microkernel interface which was somewhat stable but was awfully slow and it liked crashing a lot.Ah, the stability of microkernels... monolithic ftw: next_ver_of_a_microkernel_OS = new_bugs + 580! A typical Linux infrastructure: one bugged kernel with infinite number of bugged drivers with X numbers of patches and add-on programs, which make the system stable. A great loophole [joking]
ECHO only prints the first argument for now.Back to the topic, ECHO works, but writing "echo loophole maniac" will write just "loophole".
I just noticed that myself. Slightly odd, but there's only one or two locations that it's referenced.MEMINFO command doesnt work (everything is zero)
I've tried it myself and it faulted, so now I have a call stack and can trace the bug.Executing NASM will write "no input file" and PAGE FAULT again.
I imagined I would have a lot of bugs, but thanks once again for taking the time to try things out. The only way this OS will get better is by having people try it out. I'd rather be fixing bugs that people keep finding than going off and implementing new features that cause even more bugs!That's my two cent. Unfortunately you have a good truckload of bugs to fix....
