thethumbler / aquila Goto Github PK

I think you need to specify what's on your mind for that OS, and what are your next steps, so people can help, and also maybe choosing a way of communicating is a good thing also

The last commit was on October 26, 2019. Has the project stopped its development?

when calling kfree, it calls pmman.unmap to unmap the allocated region, the issue is that it unmaps much more than needed!

right now I'm following the .travis.yml to build it.

It all works well I may add some instructions to the README.md

it fails in the first run, and complete in the second always, I think it's a kind of dependencies problem

building binutils and gcc takes so much time man 😄 and life is short.
using -j $(nproc) should make it much faster.

I'm trying that on my machine right now and will pull request if it builds with no issues.

building the toolchain giving errors.

It builds okay without concurrent jobs.
I believe some of the rules depend on other rules but that's not explicitly stated in the Makefile

cp: cannot stat 'sys/crt0.o': No such file or directory
make[4]: *** [Makefile:1046: crt0.o] Error 1

Hello @mohamed-anwar , it's been a long time :)

I hope everything is fine on your side!

I was looking at the implementation of the 8259 Programmable Interrupt Controller (kernel/arch/i386/platform/misc/pic.c) and found what is probably small typo or copy/past error that alters the behaviour of the x86_irq_mask() function.

/* The mask value currently on slave:master */
static uint16_t pic_mask = 0xFFFF;

void x86_irq_mask(int irq)
{
    if (irq < 8) {  /* Master */
        pic_mask |= 1 << irq;
        io_out8(&master,  PIC_DATA, (pic_mask >> 8) & 0xFF);
    } else if (irq < 16) {  /* Slave */
        pic_mask |= 1 << irq;
        io_out8(&slave,  PIC_DATA, (pic_mask >> 8) & 0xFF);
    } else {
        panic("Invalid IRQ number\n");
    }
}

The mask given to the master PIC looks like it's the one of the slave.

Good luck in your study and on your work on Aquila,

Arignir

The header at the website that says

How Does It Look Like

should either be

What Does It Look Like

or

How Does It Look

See e.g. this.

Great project otherwise, keep it up :)

The driver has not been updated after the change to I/O system.

we need to ignore all the .o files. and I see some of the Makefiles are generated so they need to be ignored as well.

Steps to reproduce: boot Aquila floppy in VirtualBox (because of problem with QEMU at #23) and cd to "/" directory. Do ls -al the first time and it will work, but if you'd repeat it you'd see something like this:

Terminal already waits for a new command despite it hasn't printed the whole directory contains

Hi,

You never say if it is 32 bit operating system. That needs to be clarified.
I would like to see a 16 bit version. This way I can try it on my vintage 16 bit computer with 640 kb RAM.

You can try these 16 bit compilers:

• https://github.com/tkchia/gcc-ia16
• http://openwatcom.org/

16 bit os that allows for programs to be easily written or ported will be fun.

In the README you name IA64 as one of the goals, is it a misspelling for amd64/x86_64 or is it genuinely IA64, aka itanium ?
If its the latter, why?

Good day, @mohamed-anwar and @nagyation . Please tell, could Aquila fit on a 1.44MB or 2.88MB floppy? Even today the floppies are still being used, for example - as virtual floppies inside the coreboot open source BIOS. Just imagine: your wonderful OS could be a part of someone's BIOS build! (for coreboot supported motherboard, maybe you have or could get one - see https://www.coreboot.org/Supported_Motherboards )

If you already have a coreboot-supported motherboard, or a real chance to get one, - wouldn't it be cool to be able to launch your own OS straight from the BIOS chip? ;) With one simple command its possible to add any floppy to coreboot BIOS build - and then you see it as a boot entry! Multiple floppies could be added this way (as long as you have enough space left inside the BIOS flash chip, luckily LZMA compression could be used for the stored floppies to reduce their occupied size)

So far I see ~10MB images at your Aquila releases, but could their contains be compressed for a floppy, maybe not 1.44MB but an 2.88MB one?

That way it insures comparability with later versions of GPL

I can't find the build-tools in this project

Hi!

I ended up looking at your AquilaOS last week and found it well written. Then, I got redirected to your website and read a few of your articles... and found out about Nuklear. Wow what a super good-looking and capable immediate mode GUI!!! I immediately started thinking that I should port it to Microwindows, my small framebuffer-based graphical windowing system, and consider how it could be made the standard UI for that platform. Now, a week later, I have completed the initial port, and have had some great ideas about the next steps to make this work as a completely client/server environment where each process would have its own Nuklear context, but have the drawing all performed by Microwindows, which runs on top of raw frame buffer, X11, SDL, etc. This seemed to be what you were looking for in your blog articles, and this may be a way to do it without basically having to write a windowing system all over again, but still get the benefits of a standard UI for Aquila. We have a terminal emulator also for shell tasks.

I'm not sure if you're interested, but if so, I'd be happy to talk about how each Nuklear "app" could run as as separate process, while still looking exactly as though they all currently are implemented within one window.

I've attached a screenshot showing the standard MIcrowindows window frame, with Nuklear running inside it, as a single process for the moment. The window frame will be replaced with one differently drawn that will exactly resemble the internal Nuklear frame, but with the Nuklear application's window flags set to no titlebar, no border, no minimize or close box, an no movement. When the user drags the Microwindows frame around, it will look like Nuklear moving it but the windowing system will be doing the blit-based window move instead.

-- Greg