What does your OS look like? (Screen Shots..)

[Antti]

Here is my operating system project. This is a very early announcement but there are two bootable floppy images available if someone wants to try them.

• fdd1440.img
• fdd720.img

[BenLunt]

Here is my operating system project. This is a very early announcement but there are two bootable floppy images available if someone wants to try them.

Hi, I tried the 1.44meg on a USB thumb drive and it didn't boot. Don't know if you intended it to or not. I then tried it on a physical 1.44meg floppy and it booted as intended.

To get it to boot on a USB thumb drive, you have to do a few things to be sure it will. I think we have discussed it on this forum before. (I may be the only one around here with a physical floppy drive anymore.. )

Anyway, if you want to repay the favor, http://www.fysnet.net/blog/2018/03/.

Ben

[Antti]

Hi, I tried the 1.44meg on a USB thumb drive and it didn't boot. Don't know if you intended it to or not. I then tried it on a physical 1.44meg floppy and it booted as intended.

First of all, thank you very much for testing. (Un)fortunately, it worked just like it should if your USB thumb drive was not emulated like a floppy. There are three different VBRs ("floppy", "chs", and "lba"), the first one being for real floppies and that was used for those floppy images. The disk geometry ("sectors per track" and "heads") are read from the Bios Parameter Block for this media. If using the "chs" version, that practically works on floppies too, there should be no problem.

However, I did a lot of work for ensuring the USB thumb drive booting would work if using the right VBR version or an MBR/VBR combination. But, I failed this release because I did not provide the bootable images for that media. I should have known that of course USB thumb drives would be tested (if any).

I uploaded another image, would you mind testing this image on your USB thumb drive?

• usbtiny.img

[BenLunt]

• usbtiny.img

Yes, that one boots via USB thumb drive.

[BenLunt]

Just out of curiosity, did you have a chance to try mine? Out of the ten or more test machines I have here, I thought mine was doing quite well. However, thanks to a fellow reader, whom had tested it on a few of his/hers, come to find out I have an issue with my EHCI port reset of high-speed hubs, namely Rate Matching Hubs. I would have never found this out, though thanks to others, I did.

I know that there is a thread within this forum, I would have to go look, but I would much appreciate reviving that thread for a testing platform and have others test mine as well as myself testing others.

(What do you know, I was that last to post in that thread.. viewtopic.php?f=2&t=2970&start=105 )

Anyway, just curious to see if you had tried it,
Ben

[Antti]

Hello Ben, let's continue the discussion in another topic but I wanted to answer here so that the "discussion history" did not look like I ignored the requst. I tested your floppy image (a.img, physical floppy disk) on one computer and it worked. Then I tested your HDD image (hd.img, USB thumb drive) on three computers and they all worked.

By the way, I just did my El Torito "no-emulation" tests with the FAT12/16 boot chain and it looks like there were no "512-byte sectors" hard-coded anywhere. Perhaps this does not sound very impressive but it was a feeling of success for me. If you add all the components together, I was really expecting that there were bugs that prevented the boot. Of course, there might be hidden bugs but this proves that it could work.

It is possible to have many boot floppy disks (perhaps a feature that is not very common in hobby systems) and I am planning to try (just for fun) this kind of boot sequence:

• Floppy #1, the "standard" format with 512-byte sectors that BIOSs should boot. First databases are read from this.
• Floppy #2, the "almost standard" format with 1024-byte sectors. More databases are read from this.
• Floppy #3, the "almost standard" format with 1024-byte sectors. More databases are read from this.
• etc.

This is not very practical because it is not trivial to format those floppies. The common scenario is to use standard formats. The final test is to try the boot sequence on an ancient "160KB" floppy to test whether my 8086 compatible code really works or not... perhaps this is enough for now.

[BenLunt]

Thanks for your tests. I am going to move this to another thread. Please watch for it soon.
-Ben

[pcmattman]

Debian userspace + Pedigree kernel is progressing nicely. I've been trying to figure out how to post a screenshot that makes it a little more evident but decided to settle on this for now.

Most recent kernel log in this image:

Code: Select all

(NN) [1520789587.0] invoke: /etc/gdm/Init/Default [pid=326]
(NN) [1520789588.0] PosixSubsystem::exit(327, code=0)
(NN) [1520789588.0] PosixSubsystem::sendSignal #17 -> pid:tid 326:1
(NN) [1520789588.0] PosixSubsystem::exit(328, code=0)
(NN) [1520789588.0] PosixSubsystem::sendSignal #17 -> pid:tid 326:1
(NN) [1520789588.0] invoke: /bin/uname [pid=329]
(NN) [1520789588.0] PosixSubsystem::exit(329, code=0)
(NN) [1520789588.0] PosixSubsystem::sendSignal #17 -> pid:tid 326:1
(NN) [1520789588.0] PosixSubsystem::exit(330, code=0)
(NN) [1520789588.0] PosixSubsystem::sendSignal #17 -> pid:tid 326:1
(NN) [1520789588.0] PosixSubsystem::exit(326, code=0)
(NN) [1520789588.0] PosixSubsystem::sendSignal #17 -> pid:tid 286:1
(NN) [1520789588.0] sending #285 signal #0 from #286
(NN) [1520789588.0] sending #286 signal #12 from #285
(NN) [1520789588.0] invoke: /usr/lib/gdm/gdmgreeter [pid=331]
(EE) [1520789589.0] PosixSyscallManager: invalid syscall received: 0
(NN) [1520789590.0] PosixSubsystem::sendSignal #14 -> pid:tid 313:1
(NN) [1520789593.0] PosixSubsystem::sendSignal #14 -> pid:tid 313:1
(NN) [1520789594.0] createFile: e13b20fdb08344e0e664864cc2ede53d-x86-64.cache-2.TMP-DsMPdK
(NN) [1520789594.0] CREATE: e13b20fdb08344e0e664864cc2ede53d-x86-64.cache-2.TMP-DsMPdK
(NN) [1520789594.0] CREATE: e13b20fdb08344e0e664864cc2ede53d-x86-64.cache-2.LCK
(NN) [1520789594.0] REMOVE: e13b20fdb08344e0e664864cc2ede53d-x86-64.cache-2.TMP-DsMPdK
(NN) [1520789594.0] createFile: e13b20fdb08344e0e664864cc2ede53d-x86-64.cache-2.NEW
(NN) [1520789594.0] CREATE: e13b20fdb08344e0e664864cc2ede53d-x86-64.cache-2.NEW
(NN) [1520789594.0] REMOVE: e13b20fdb08344e0e664864cc2ede53d-x86-64.cache-2.NEW
(NN) [1520789594.0] REMOVE: e13b20fdb08344e0e664864cc2ede53d-x86-64.cache-2.LCK
(EE) [1520789595.0] POSIX: unknown Linux syscall 25 by pid=331, translation failed!
(EE) [1520789600.0] POSIX: unknown Linux syscall 29 by pid=331, translation failed!
(NN) [1520789600.0] PosixSubsystem::sendSignal #14 -> pid:tid 313:1
(NN) [1520789602.0] PosixSubsystem::sendSignal #14 -> pid:tid 313:1
(NN) [1520789602.0] PosixSubsystem::exit(332, code=0)
(NN) [1520789602.0] PosixSubsystem::sendSignal #17 -> pid:tid 331:1
(NN) [1520789602.0] EMPTY handler.
(NN) [1520789603.0] invoke: /usr/lib/gdmprefetch [pid=333]
(NN) [1520789603.0] PosixSubsystem::exit(333, code=1)
(NN) [1520789603.0] PosixSubsystem::sendSignal #17 -> pid:tid 1:2

Need to fix up some mismatches in the keymap so I can successfully log in

[MajickTek]

Debian userspace + Pedigree kernel is progressing nicely. I've been trying to figure out how to post a screenshot that makes it a little more evident but decided to settle on this for now.

Most recent kernel log in this image:

Code: Select all

-snip-

Need to fix up some mismatches in the keymap so I can successfully log in

That is quite awesome. It must have been a chore to port, considering that the kernel needs to be very unix/linux compatible.

[BrightLight]

Here's something unusual when compared to what the rest of you guys do. I've written a lightweight, portable ACPI AML interpreter entirely from scratch in C, and I've used it to create an ACPI control method battery driver. VirtualBox's AML provides a battery device, and so here's a screenshot of my OS detecting batteries on VirtualBox.



Of course, the AML interpreter is not complete yet, but it's a very good start in the proper direction. It's basically a project within a project.

EDIT: Fast forward a few hours later, and I've fixed a few OpRegion bugs and I can now detect my real laptop's battery too. (Click to enlarge.)

[nakst]

20 calculators. Because why not?

[qookie]

Multitasking in my OS. Took me quite a long time to get it working.
Still, some bugs to figure out(sometimes one process dying causes other ones to crash as well).
The screenshot shows 2 tasks running, one is the notepad and the other one prints ASCII from A to } characters and then crashes.

[GautamS]

20 calculators. Because why not?

Hah, I thought you were trying to emulate the good ol' WinXP window manager lag.

[qookie]

Sorry for posting another post in such a short time, just had to show you this.
I fixed all my issues with multitasking and an issue with a function related to paging causing my OS to randomly crash when allocating a new page table and got it to work on real hardware(and also got it to not crash randomly in VBox and when using KVM).
The photo looks like it was taken with a potato because my phone camera is a scratched.

[MollenOS]

So, over the course of the last two months I've managed to do a lot of improvements and porting for my OS.
- Ported a native build of LLVM to my OS (+ libcxxabi, libcxx, libunwind)
- Ported mesa with llvmpipe as the rendering backend
- Added 64 bit support for my OS so both 32 and 64 bit is done

Also started building my window compositor which is using opengl (mesa) as the rendering backend, currently following opengl tutorials to learn how to use it as I'm very novice in graphics programming. But in the following screenshot I'm using GLSL shaders to do the coloring!