What's your OSDev AWWWW YEAH! moment?

[SpyderTL]

After months of trying to figure out why I couldn't read raw audio data in VirtualBox, I finally discovered, just now, that the code has been working the whole time. I just needed to read the TOC from the disc first, and then everything else started working...

Long story short, I now have an OS that can play CDs! *

AWWWWWW YEAH!!!

(* at least for a few seconds, then it locks up...)

[Unsigned]

The floppy drive LED turned off automatically... AWWWW YEAH!
I'm implementing virtual mode to read sectors using BIOS interrupts, and i need the v86 task to intercept the IRQs. After using a separate task for the v86 monitor and having trouble with it (it gave warnings in Bochs and just locked in real hardware), I finally got it working by implementing the monitor in kernel mode and having it called exactly when an IRQ or interrupt happened. Now the BIOS code gets all the hardware interrupts and turns the floppy drive LED off after a few timer ticks. It also turns the keyboard LEDs on and off when pressing the lock keys, and it's the first time Ctrl+Alt+Del is able to restart the computer while my protected mode code is running.

[Roman]

1840 LOC (both obiectumc and essentiac, blank lines and comments already excluded) for this...
PS. It's not OS dev, but something also complex - compiler dev.

[SpyderTL]

1840 LOC (both obiectumc and essentiac, blank lines and comments already excluded) for this...
PS. It's not OS dev, but something also complex - compiler dev.

It took me a few minutes to figure out WTH was going on here... but, Good Job!

What OS is this running on?

[Roman]

It took me a few minutes to figure out WTH was going on here...

I'm developing a compiler for my custom language - Obiectum. The compiler (obiectumc) generates code in an intermediate bytecode representation, then essentiac translates it into the target assembly code, only x86_64 and OS X are supported at the moment.

What OS is this running on?

OS X El Capitan.

[SpyderTL]

I'm impressed.

What language are obiectumc and essentiac written in?

How far along is the intermediate language? Does the intermediate language have a name?

I'm guessing that you aren't quite to the "Hello world" stage, yet. Correct?

[Roman]

What language are obiectumc and essentiac written in?

C. I expect Obiectum to be mainly influenced by Objective-C (OOP, ARC) and Go (no headers, less braces, built-in multithreading).

How far along is the intermediate language?

Implementation in parallel with design. I think the project is too complex for me to design perfectly before trying to implement (can't keep everything in mind, don't know some things).

Does the intermediate language have a name?

Yes, Essentia.

I'm guessing that you aren't quite to the "Hello world" stage, yet. Correct?

I think, I'm far enough from a "Hello, World!" program. The "package" directive is the first to be supported.

[onlyonemac]

The floppy drive LED turned off automatically... AWWWW YEAH!
I'm implementing virtual mode to read sectors using BIOS interrupts, and i need the v86 task to intercept the IRQs. After using a separate task for the v86 monitor and having trouble with it (it gave warnings in Bochs and just locked in real hardware), I finally got it working by implementing the monitor in kernel mode and having it called exactly when an IRQ or interrupt happened. Now the BIOS code gets all the hardware interrupts and turns the floppy drive LED off after a few timer ticks. It also turns the keyboard LEDs on and off when pressing the lock keys, and it's the first time Ctrl+Alt+Del is able to restart the computer while my protected mode code is running.

That sounds quite impressive, but nevertheless that isn't really the best way of doing things. With about the same amount of work, you should be able to replace the IRQs with similar handlers yourself and re-create (and improve upon) most of the core BIOS functions.

[Unsigned]

That sounds quite impressive, but nevertheless that isn't really the best way of doing things. With about the same amount of work, you should be able to replace the IRQs with similar handlers yourself and re-create (and improve upon) most of the core BIOS functions.

That's a good advice, and it's in fact what I'm going to do if I implement DOS compatibility. But I forgot to say that it's just the bootloader, there's not enough space for all the disk drivers (IDE/ATAPI/SATA/USB), and I'm just using the BIOS giving it about the same privileges as in real mode. The actual kernel, which I haven't started yet, will use native 32-bit drivers for disk access. By the way, once I got it working, I find virtual mode relatively easy (the only difficulties were fixing my mistakes), and I think that writing all the disk drivers and BIOS functionality will be more difficult.

[onlyonemac]

If it's a bootloader, then you probably don't need to be using protected mode/virtual mode. Normally one just loads the stuff in real mode and then switches to protected mode and enters the kernel. I needed a second stage bootloader as my kernel is being loaded higher up in RAM and I needed to set up paging before entering the kernel plus because of the kernel load location I needed to use protected mode thus the second stage bootloader needs to contain a floppy disk driver. Which is fine as I already had such a driver written and I'll easily be able to adapt it. So I guess that unless you're trying to load the kernel above the first megabyte of RAM, you don't need a protected mode bootloader, and if you do need a protected mode bootloader then using BIOS interrupts is really excessive; you could just write a small floppy disk driver. One good thing though as that it should be relatively easy to replace this virtual mode hack with the real thing when you're ready to.

[Unsigned]

But it is already about 33KB in size, and I still need to implement the different filesystem drivers. So no, I can't implement a FD driver, because that would mean I need to implement drivers for IDE, ATAPI, SATA, USB, USB floppy, USB mass storage, and new kinds of drives that may appear in the future (EDIT: and PnP/PCI/ACPI for detecting those), and that may make my code grow beyond the limit. The 32-bit module (written in C) is limited to 64KB minus the size of the 16-bit module (written in assembler) because the bootloader is loaded by the boot sector and I don't want it to be too big. If you don't know, my 16-bit module performs basic setup like enabling the A20 line, detecting the 386, etc., and then copies the 32-bit module (which is included in assembler using the %incbin directive) in the location it's linked to, and then it jumps to the entry point. My kernel will not be necessarily limited in size, so I can't assume it can be loaded all in the first MB. I want to be able to load it at any free region, possibly fragmented physically (therefore using paging). Aditionally, I want my bootloader to be universal, that's to say, able to load the kerner from any kind of drive the BIOS was already able to load the MBR and bootloader from. I don't want to update my bootloader as new drives are invented, so using the BIOS will work, since it will take care of the hardware internals. And yes, I need to use protected mode becuase GCC doesn't produce real mode code, and I personally don't fancy to write the filesystem drivers in assembler. I find C far more convenient.

[onlyonemac]

But it is already about 33KB in size, and I still need to implement the different filesystem drivers. So no, I can't implement a FD driver, because that would mean I need to implement drivers for IDE, ATAPI, SATA, USB, USB floppy, USB mass storage, and new kinds of drives that may appear in the future (EDIT: and PnP/PCI/ACPI for detecting those), and that may make my code grow beyond the limit. The 32-bit module (written in C) is limited to 64KB minus the size of the 16-bit module (written in assembler) because the bootloader is loaded by the boot sector and I don't want it to be too big. If you don't know, my 16-bit module performs basic setup like enabling the A20 line, detecting the 386, etc., and then copies the 32-bit module (which is included in assembler using the %incbin directive) in the location it's linked to, and then it jumps to the entry point. My kernel will not be necessarily limited in size, so I can't assume it can be loaded all in the first MB. I want to be able to load it at any free region, possibly fragmented physically (therefore using paging). Aditionally, I want my bootloader to be universal, that's to say, able to load the kerner from any kind of drive the BIOS was already able to load the MBR and bootloader from. I don't want to update my bootloader as new drives are invented, so using the BIOS will work, since it will take care of the hardware internals. And yes, I need to use protected mode becuase GCC doesn't produce real mode code, and I personally don't fancy to write the filesystem drivers in assembler. I find C far more convenient.

I guess that's justifiable...

[Nutterts]

After about three weeks hanging around here these are my moments:

1) Getting to see your assembly raw boot sector written from scratch putting a zero terminated string on the screen and accurately reading floppy sectors. The moment I got that far I got a major high of it.

2) Wondering what would happen if you followed the barebone but while compiling gcc adding go as one of the languages & seeing it actually kinda working although only visible by it not rebooting and repeated bochs magic breakpoints. (Hint: While there's even a post on this forum somewhere of me more or less claiming it was near impossible.)

3) Discovering I could use pascal functions compiled in to allow Go to access memory & portio like this:

Code: Select all

function addrToPtr(addr: DWord): PtrUInt; cdecl; [public, alias: 'fpc_addrToPtr'];
begin
  addrToPtr := PtrUInt(addr);
end;

4) After more then a week of putting sh*itloads of effort into trying to port a libc library and/or libgo finding out I could hack myself around the problem using simple a simple pascal function like this & seeing it actually working:

Code: Select all

function go_new(const td: PtrUInt; size: DWord): PtrUInt; cdecl; [public, alias: '__go_new'];
begin
  go_new := PtrUInt(krn_memstart + krn_mempos);
  krn_mempos += size;
end;

5) Seeing it (very) slowly but certainly coming together
https://bitbucket.org/nutterts/golos/sr ... ?at=master

Edit: Just realized my repository isn't up to date. I fixed the math (eg: x % 10) mistake in krnout and changed the pascal functions to the cdecl calling convention. Don't know why I used stdcall instead of cdecl but I had a weird stack corruption problem that I'm almost sure was caused by that mistake.

[onlyonemac]

@Nutterts: Please don't tell me you're planning on writing your OS in *pascal*... *shudder*

[Nutterts]

@Nutterts: Please don't tell me you're planning on writing your OS in *pascal*... *shudder*

[mode=sarcasme]
Of course not, that would be silly... I'm writing it in Go. :p