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

[Octocontrabass]

It works without end user hassle/configuration, or it deserves to go in the trash.

What about the users who can't afford to replace their hardware? For example, I have a display that reports the wrong (too high) native resolution in its EDID. Is your OS compatible with this display?

[Brendan]

Hi,

Temporary code to generate a background image (in 48-bpp device independent XYZ format).
Code to generate a routine at run-time, where the resulting routine does "48-bpp device independent XYZ -> device dependent RGB", including gamma correct dithering; that takes into account:

Can you elaborate? I can't find any information about a 48 bit graphics format on the web. Did you create it yourself?

First, I got it wrong - it's actually 96-bit.

The XYZ colour space is a standard colour space which is able to represent all colours (unlike any variation of RGB). It's this "able to represent all colours" that makes it ideal for a device independence.

Note that part of my plan is to use this same colour space for everything - the device drivers for all input devices (scanner, web camera, etc) will convert data from whatever the device itself uses into XYZ, the device drivers for all output devices (video cards, printers, etc) will convert from XYZ into whatever the device uses; and all other software (and all file formats) will only ever use XYZ for everything. Note: Technically it's "XYZ linear with a D65 white-point".

I generate pixel data for this colour space; with a 32-bit X, a 32-bit Y and a 32-bit Z; and store it in a buffer in RAM.

Then I convert it into whatever the device actually wants. That's the tricky part; because it's a lot of "per pixel" work and there's lots of pixels; and I wanted to do it in a single "do everything in one pass" way to avoid the need for intermediate buffers (and more cache misses). The result is stored in a second buffer; which is blitted/copied to display memory like normal.


Cheers,

Brendan

[Brendan]

Hi,

It works without end user hassle/configuration, or it deserves to go in the trash.

What about the users who can't afford to replace their hardware? For example, I have a display that reports the wrong (too high) native resolution in its EDID. Is your OS compatible with this display?

During boot, the boot loader gets the first block of EDID, extracts the "vendor ID" and "product ID" fields, and tells my BAL (Boot Abstraction Layer). The BAL uses the vendor/product ID to find the file for that display. In theory; it finds a file (with correct information) and the information from EDID isn't used, and it'll work perfectly (even though the monitor's EDID is wrong).

However; in practice the BAL won't find a file yet; because there are no "display information data" files yet.

When the BAL can't find a suitable file it asks the boot loader for the full EDID; and then BAL auto-generates a file from the EDID and marks it as temporary, uses it to determine a video mode, and adds that temporary file into the file system.

The idea is that (eventually) people (using tools that don't exist yet) would add missing information to the temporary "display information data" files (and check/correct auto-generated information if necessary) to create the actual file for the display; and then upload these files to some sort of repository on the Internet for everyone to use (and where they can be included in the OS's official "installer CD"). Of course it's going to take a long time before the OS gets to that stage...


Cheers,

Brendan

[Octocontrabass]

During boot, the boot loader gets the first block of EDID, extracts the "vendor ID" and "product ID" fields, and tells my BAL (Boot Abstraction Layer). The BAL uses the vendor/product ID to find the file for that display.

And what do you do when several different displays share the same vendor and product ID?

[Brendan]

Hi,

During boot, the boot loader gets the first block of EDID, extracts the "vendor ID" and "product ID" fields, and tells my BAL (Boot Abstraction Layer). The BAL uses the vendor/product ID to find the file for that display.

And what do you do when several different displays share the same vendor and product ID?

I'd do the same as I would if different PCI devices have the same "vendor ID" and "device ID" - inform the manufacturer that they're incompetent, and tell everyone that'll listen to never buy that manufacturer's products ever again. Note that (eventually) I imagine the OS would have a hardware compatibility database with some sort of tool (and/or web front-end) that people can use to check if (and how well) the OS supports various pieces of hardware (and if there's any issues).

Beyond that; depending on how different the monitors are people might be able to find some common ground - e.g. if one supports a 1280*1024 timing, one supports a 1920*1600 timing and they both support the same 800*600 timing; then you'd be able to create a file that only mentions the 800*600 timing.


Cheers,

Brendan

[Antti]

• Boot image/inital RAM disk decompression; with max. size of 1.5 GiB (decompressed), even if the OS failed to enable A20 and physical memory is completely fragmented

This is interesting because I have been struggling with this problem. To be precise, I have not decided what would be the best way to make this scalable because all computers can not possibly load the whole boot image/initial RAM disk. I thought about making it like a database. The boot loader would read little units ("database sessions") from disk and each one of them modifies the database state. The order of sessions is from "important" to "extra", of course. For example, the first session could create a database element. The second session could add more data to that element, create new elements, delete elements, and so on. It would be possible to make this fully scalable and the final database state depended on how much sessions are read from disk or from other sources. This partly means discarding the traditional file concept.

If we had a database element called "$SOME_ELEMENT" with an attribute ".SomeAttribute", I would be able to read its value:

Code: Select all

var temp1 = READ FROM DATABASE $SOME_ELEMENT.SomeAttribute

The variable contains something that is read from a database that has been built from N database sessions. Now if we had N + 1 database sessions (more RAM so more sessions are read), and I would do:

Code: Select all

var temp2 = READ FROM DATABASE $SOME_ELEMENT.SomeAttribute

I think it goes without saying that "temp1 == temp2" is not necessary. Also, the database should not be just a "flat element array" but it had a hierarchy tree and elements may own other elements. Basic things like cross-references are possible.

Please note that this is just an idea.

[mallard]

Getting back to this thread's topic, here's a picture of my GUI, showing all four GUI applications currently in existence:



We have, (clockwise from the top-left):

• "WM Menu" - the extremely simple menu/launcher application acting as a temporary "GUI shell" until I get a proper desktop implemented.
• "WM Test Application" - the very first GUI application ever written (also shown in my last screenshot). It has some simple "mouse painting" code written to test GUI responsiveness and used here to draw a smiley face.
• "Breakout" - the first (and so far only) game/entertainment application for my OS. A version of the classic ball-bouncing block-smashing game, shown here with a game in progress.
• "BT/OS Terminal 3" - my GUI "terminal emulator" ("Terminal window" on the menu) displaying the CLI (CMD.ELX) and the results of a command to display a list/table of currently running processes.

The process list shows:

• "SPAWN.ELX" - a small utility used to automatically restart a program if it ends/crashes. Used to keep the session switcher running.
• "SWITCHER.ELX" - the terminal session switcher/creator. Runs in its own terminal session and provides a way to create new sessions and switch between them. Can be accessed by pressing CTRL+ESC.
• "CMD.ELX" - the CLI command interpreter in the session that the GUI is running in.
• "STARTWM.ELX" - a utility that starts the GUI and cleans up any orphaned processes when it ends.
• "GDS.ELX" - the "Graphics/Drawing Service" (name not fully decided upon). Provides a high-level graphics API used by the rest of the GUI, interfaces with the terminal's graphics support, which in turn interfaces with the video driver.
• "WM.ELX" - the Window Manager. Provides windowing services built upon the GDS and interfaces with the terminal to provide user input to applications.
• "WMMENU.ELX", "BREAKOUT.ELX", "WMTEST.ELX", "TERMWIN.ELX" - the four visible GUI applications.
• "CMD.ELX" - the CLI command interpreter in the GUI terminal window session.

Aside from minor bugfixes/tweaks, this is the state that I'm leaving the GUI in until after my 0.1 release. This release will be made once I've made the OS "installable"; i.e. able to be booted from removable media then partition/format a hard drive, install a bootloader and copy across all required files. Once that's done, the proper GUI desktop environment will be developed.

[Octocontrabass]

inform the manufacturer that they're incompetent, and tell everyone that'll listen to never buy that manufacturer's products ever again.

The manufacturer went bankrupt. The brand name is now used by an entirely different company.

e.g. if one supports a 1280*1024 timing, one supports a 1920*1600 timing and they both support the same 800*600 timing; then you'd be able to create a file that only mentions the 800*600 timing.

Unfortunately, these are LCDs, so any compromise will end up with a very blurry picture on at least one display model. You could use the resolution of the smaller display and set the larger one to center the picture - but that needs to be configured for each individual display, so you're still better off letting the user set the native resolution.

[Brendan]

Hi,

• Boot image/inital RAM disk decompression; with max. size of 1.5 GiB (decompressed), even if the OS failed to enable A20 and physical memory is completely fragmented

This is interesting because I have been struggling with this problem. To be precise, I have not decided what would be the best way to make this scalable because all computers can not possibly load the whole boot image/initial RAM disk. I thought about making it like a database. The boot loader would read little units ("database sessions") from disk and each one of them modifies the database state. The order of sessions is from "important" to "extra", of course. For example, the first session could create a database element. The second session could add more data to that element, create new elements, delete elements, and so on. It would be possible to make this fully scalable and the final database state depended on how much sessions are read from disk or from other sources. This partly means discarding the traditional file concept.

First; the boot image/initial RAM disk only really needs to contain enough drivers, etc. to be able to load more after kernel is started. This gives 2 scenarios:

• You know which drivers, etc the computer will need (OS has been installed)
• You don't know which drivers, etc the computer will need (OS is being installed)

For the first case there shouldn't be much problem - e.g. you'd only need some misc. files, one kernel, 2 drivers and one file system. You might want more (to improve boot times by pre-loading things earlier); but you also know how much RAM the machine has and know how much optional/additional stuff you can fit in the boot image. It's this "optional/additional stuff to improve boot times" where you want the boot code to support large boot images. You'd also want (and I also have) boot code that tracks which pieces are actually used, so that the (installed) OS can "self optimise" its own boot image (remove unused/unnecessary files, etc).

For the second case; you know 80x86 is backward compatible (e.g. the installer can use a 32-bit kernel regardless of whether the computer supports 64-bit or not, and regardless of which kernel it ends up installing), and you know the OS is being installed from CD or USB (and don't need motherboard drivers, hard disk drivers, network card drivers, sound card drivers, ...., etc in the boot image itself). If you only really need about 50 drivers (for different CD and USB controllers and devices) and estimate ~64 KiB per driver on average, it could easily fit in 8 MiB. You might also need to add a few "display info data" files for problem cases (where the monitor provides buggy/incorrect EDID), but they're only about 6 KiB each and you wouldn't need many (for most computers the "auto-generate temporary file from EDID" is perfectly fine for an OS installer to use for however long it takes to install the OS).

Of course for modern laptop/desktop/server (systems that will be old by the time the OS is usable) you can expect there will be 2 GiB of RAM or more; and you could have an OS installer that loads a full 1.5 GiB boot image (~750 MiB compressed) anyway. The problem is that you'd have no way of knowing which "not strictly needed but pre-loaded for performance anyway" files will actually be used (and will help boot times) and which ones won't be used (and are just unnecessary baggage that slows down boot times instead).

The other case is installing the OS from network; but I'm planning to do this very differently - essentially, client downloads almost nothing (kernel and network card drivers), then sends the hardware's details (a list of PCI devices, CPUs and their features, memory map, etc) back to the server; and the server builds the boot image for the client, then tells client to "reboot via. kexec".

e.g. if one supports a 1280*1024 timing, one supports a 1920*1600 timing and they both support the same 800*600 timing; then you'd be able to create a file that only mentions the 800*600 timing.

Unfortunately, these are LCDs, so any compromise will end up with a very blurry picture on at least one display model. You could use the resolution of the smaller display and set the larger one to center the picture - but that needs to be configured for each individual display, so you're still better off letting the user set the native resolution.

For "faulty by design" hardware that failed to comply with even the most basic requirements (that probably doesn't exist and will probably never exist); the default expectation is "hardware shouldn't work at all". If the OS provides "works but is blurry" instead, then that's several orders of magnitude better than anyone can reasonably expect.


Cheers,

Brendan

[Primis]

The other case is installing the OS from network; but I'm planning to do this very differently - essentially, client downloads almost nothing (kernel and network card drivers), then sends the hardware's details (a list of PCI devices, CPUs and their features, memory map, etc) back to the server; and the server builds the boot image for the client, then tells client to "reboot via. kexec".

I really like this idea, mind if I borrow it?

[Roman]

@mallard: Looks good! Any pre-built boot images available?

[jnc100]

So not my actual OS but something I've been working on over the past month or so. Its my own design CPU core implemented in an FPGA. The current design is a 32-bit RISC machine with 16 registers. The peripherals included in the design are: VGA output, UART serial, SPI (so can interface SD cards and EEPROM chips), external SRAM interface, interrupt controller and timer.

The supporting software includes an assembler, linker, backend for LLVM (so clang can be used to compile C code), emulator, EEPROM programmer (for loading firmware) and various support tools.

Pong in action and Repository.

Regards,
John.

[max]

I wrote a calculator and a login screen

[Kevin]

I agree, every login screen needs a calculator!

Nice to see that you're still making progress.

[osdever]

I wrote a calculator and a login screen

Looks like Win10.