OSDev.org

When somebody asks you what are you doing, you be like:

Woo-hoo! U365 1.2, FS works. Yay!

Got the keyboard working (・ｏ・)



(the + after the version is to indicate it's a post-release version rather than the one actually marked as 0.10)

Sik wrote:(the + after the version is to indicate it's a post-release version rather than the one actually marked as 0.10)

You could add the current Git commit hash as a define while building

ELF binaries work almost fine. Awesome, isn't it?

My v8086 monitor is almost done.

I'm debugging it with 3 second delays when it called.

First (useless) ELF program for U365.

Finally finished the V8086 Monitor.
Runned int 0x10 with ax = 0x4F02, bx = 0x117:



And I have a question:

I have a book called "8086 Assembly", and I made the V8086 Monitor with help of this book.

The book says push and pop operations are different than 80286+ CPUs. Because SP shows the empty word in the stack in 80286+ CPUs, but SP shows the last word in the stack in 8086 CPUs.

So order of operations in push and pop in 8086 CPUs:

PUSH src:

SP <--- SP - 2
SS:[SP] <--- src

POP src:

src <--- SS:[SP]
SP <--- SP + 2

So order of operations in push and pop in 80286+ CPUs:

PUSH src:

SS:[SP] <--- src
SP <--- SP - 2

POP src:

SP <--- SP + 2
src <--- SS:[SP]

As the V8086 Mode's name has 8086 in it, I thought 8086 rules are valid, not 80286+ rules. And I coded pushf and popd by applying 8086 rules. It works, but is that really correct? Which one should I use, the 8086 push and pop or 80286+ push and pop?

Agola wrote:Finally finished the V8086 Monitor.

And I have a question:

I have a book called "8086 Assembly", and I made the V8086 Monitor with help of this book.

The book says push and pop operations are different than 80286+ CPUs. Because SP shows the empty word in the stack in 80286+ CPUs, but SP shows the last word in the stack in 8086 CPUs.

So order of operations in push and pop in 8086 CPUs:

PUSH src:

SP <--- SP - 2
SS:[SP] <--- src

POP src:

src <--- SS:[SP]
SP <--- SP + 2

So order of operations in push and pop in 80286+ CPUs:

PUSH src:

SS:[SP] <--- src
SP <--- SP - 2

POP src:

SP <--- SP + 2
src <--- SS:[SP]

As the V8086 Mode's name has 8086 in it, I thought 8086 rules are valid, not 80286+ rules. And I coded pushf and popd by applying 8086 rules. It works, but is that really correct? Which one should I use, the 8086 push and pop or 80286+ push and pop?

You're a bit mixed up. For all processors when you're done with a push sp points to the pushed value. The difference is when sp is decremented:
8086:
sp = sp-2
[sp] = src
186+
[sp -2] = src
sp = sp -2

The big difference arises when pushing sp.

Anyway, i think v86 merely emulates real mode, not an actual 8086

Don't emulate 8086 bugs.

azblue wrote:

Agola wrote:Finally finished the V8086 Monitor.

And I have a question:

I have a book called "8086 Assembly", and I made the V8086 Monitor with help of this book.

The book says push and pop operations are different than 80286+ CPUs. Because SP shows the empty word in the stack in 80286+ CPUs, but SP shows the last word in the stack in 8086 CPUs.

So order of operations in push and pop in 8086 CPUs:

PUSH src:

SP <--- SP - 2
SS:[SP] <--- src

POP src:

src <--- SS:[SP]
SP <--- SP + 2

So order of operations in push and pop in 80286+ CPUs:

PUSH src:

SS:[SP] <--- src
SP <--- SP - 2

POP src:

SP <--- SP + 2
src <--- SS:[SP]

As the V8086 Mode's name has 8086 in it, I thought 8086 rules are valid, not 80286+ rules. And I coded pushf and popd by applying 8086 rules. It works, but is that really correct? Which one should I use, the 8086 push and pop or 80286+ push and pop?

You're a bit mixed up. For all processors when you're done with a push sp points to the pushed value. The difference is when sp is decremented:
8086:
sp = sp-2
[sp] = src
186+
[sp -2] = src
sp = sp -2

The big difference arises when pushing sp.

Anyway, i think v86 merely emulates real mode, not an actual 8086

Actually I'm not a native speaker and sometimes I can't explain what do I mean correctly. While I reading my post I noticed the explanation problem, thanks.

When I do the 80286+ way it doesnt work, I got confused again. As BIOS in QEMU designed to run in a 80386+ processor, so the 80286+ way should work instead of the 8086 way. But 8086 way is working, 80286 way not. Strange.

Edit: My bad, I forgot my memory read / write functions' directions are to up. As stack growns down, I always did the same what a 386 does actually.
As I can't fully explain what do I mean, I prepared that image:



Thanks, everything is good now.

Now I have first program for U365 that does something good. It's cat. I implemented read/open/write syscalls and now it works. Gonna make Surface syscalls now.

osdeverr wrote:Now I have first program for U365 that does something good. It's cat. I implemented read/open/write syscalls and now it works. Gonna make Surface syscalls now.

That looks really promising those MOTDs gave me a hearty chuckle! Are you loading the cat command dynamically during execution? if so, you've opened a whole world of possibilities for your OS - cant wait to reach that point in development too

--

Got ATA and FAT16 disk loading working (around 90%), need to get file allocation table navigation functional in order to link paths together for the "ls" command. but its going very well at the moment!

I've moved to exclusively C++ code for the kernel, the class system is a dream for my implementation of Surfaces! Each surface is inserted into a vector which I can iterate over, re-order, etc. so handy. My libc++ has a few essential STL classes: strings, vectors and bitsets currently. Aiming to get further classes implemented soon

prasoc wrote:

osdeverr wrote:Now I have first program for U365 that does something good. It's cat. I implemented read/open/write syscalls and now it works. Gonna make Surface syscalls now.

That looks really promising those MOTDs gave me a hearty chuckle! Are you loading the cat command dynamically during execution? if so, you've opened a whole world of possibilities for your OS - cant wait to reach that point in development too

Wow, thanks a lot, prasoc! Yes, I load cat dynamically from my initrd. Actually it wasn't a trivial task to achieve: we worked a lot with it. That work finally paid off. I'm gonna create my own libc now

osdeverr wrote:

prasoc wrote:

osdeverr wrote:Now I have first program for U365 that does something good. It's cat. I implemented read/open/write syscalls and now it works. Gonna make Surface syscalls now.

That looks really promising those MOTDs gave me a hearty chuckle! Are you loading the cat command dynamically during execution? if so, you've opened a whole world of possibilities for your OS - cant wait to reach that point in development too

Wow, thanks a lot, prasoc! Yes, I load cat dynamically from my initrd. Actually it wasn't a trivial task to achieve: we worked a lot with it. That work finally paid off. I'm gonna create my own libc now

Wait, you did all of that with your link/no standard library? I am simply amazed.