Author Topic: ES/1 open source kernel  (Read 44097 times)

ak120

  • Guest
Re: ES/1 open source kernel
« Reply #30 on: December 05, 2017, 06:00:36 pm »
I plan on creating a real-mode emulator that will run in 32-bit protected mode, allowing for all existing 16-bit code to run natively in ES/2 through emulation.
Sorry, but it sounds quite strange. Some wrong assumptions as usual. You claim that "all existing 16-bit code" should "run natively" by a fictive real-mode emulation. But on the other hand not "all existing 16-bit code" operates in real-mode and additionally you can write real-mode code that can deal with 32-bit registers. Every 386 compatible CPU has a virtual 8086 mode which also includes x86-64.

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #31 on: December 05, 2017, 06:05:37 pm »
I plan on creating a real-mode emulator that will run in 32-bit protected mode, allowing for all existing 16-bit code to run natively in ES/2 through emulation.
Sorry, but it sounds quite strange. Some wrong assumptions as usual.

Perhaps on your part as well, Andreas Kohl.

Quote
You claim that "all existing 16-bit code" should "run natively" by a fictive real-mode emulation. But on the other hand not "all existing 16-bit code" operates in real-mode and additionally you can write real-mode code that can deal with 32-bit registers. Every 386 compatible CPU has a virtual 8086 mode which also includes x86-64.

I am well aware of that.
« Last Edit: December 05, 2017, 06:08:20 pm by Rick C. Hodgin »

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #32 on: December 06, 2017, 04:56:10 am »
I have been able to get the graphics working in 24-bit and 32-bit graphics modes.  The 3dfx card is in a PCI bus and takes about one second to redraw the screen in 1280x1024x24 mode.  The ATI card uses an AGP bus and updates a 1600x1200x32 screen in about 1/10th second in full-redraw mode.

I'll be moving entirely to a graphics mode for all future development.  Am working on adding mouse and flashing caret support.

ES/1 will support all apps, both text-based and graphics, as windows on the desktop.

UPDATE:  I have been able to get 16-bit working too.  I've also added a delta render function, allowing console windows to work in graphics mode by only rendering changed characters or attributes.  With delta render, on console windows it's as fast as text now.  Working on mouse pointer and flashing caret now.
« Last Edit: December 06, 2017, 08:47:07 am by Rick C. Hodgin »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: ES/1 open source kernel
« Reply #33 on: December 06, 2017, 08:23:34 am »
What object format are you using? Also what executable format?

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #34 on: December 06, 2017, 08:40:14 am »
What object format are you using? Also what executable format?

Right now I'm doing all work in DOS with the Open Watcom for DOS compiler.  It uses OMF and ELF by default.

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #35 on: December 06, 2017, 02:46:46 pm »
I've contacted Sammy Mitchell who wrote The SemWare Editor, Jr. for DOS.  He's going to make me a special version that receives -rows and -cols command line parameters and uses those rather than BIOS and INT 10h services to determine the screen size.

He's going to modify TSE, Jr. for DOS to allow those parameters and write to text video memory at 0xb800000.  I will write a TSR which projects that memory into graphics mode, allowing a 200x75 console and editor.

Since I have my delta render working, it should be as fast as text in DOS.

Here is the source code.  It's missing some recent changes, but those will be pushed tonight.
« Last Edit: December 06, 2017, 02:50:58 pm by Rick C. Hodgin »

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #36 on: December 09, 2017, 11:41:39 pm »
I have the mouse pointer working correctly, on text and graphics modes.  Am developing the flashing caret algorithms now.

Once completed, I'll finish development on the Vio algorithms for the menu and input fields.

This will give us a solid framework for text-based UI in a text or GUI wrapper.  I will use that base for developing all ES/1 apps.  The first will be kernel code support for FAT12/16 disks, and memory allocation algorithms.  The second will be my Debi debugger.  The third will be cmd.exe and supporting algorithms (copy, move, md, rd, etc.).

Here's to great success (James 4:15 -- Lord willing) !

Note:  I will say that programming back in text-based consoles in DOS these many days really makes me appreciate GUI interfaces and TrueType fonts. :-). I may bump my DSF implementation up a few notches and give myself a GUI with proportional fonts.
« Last Edit: December 10, 2017, 12:09:35 am by Rick C. Hodgin »

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #37 on: December 10, 2017, 05:26:17 am »
Here's a screenshot.  I'm using VESA video modes.  This one is 1600 x 1200 with 32-bit color.  You can see the mouse pointer rendered, and I caught the caret/cursor mid-blink so you can see it there near the mouse pointer.

ES/1 allows three types of built-in carets:  (1) boxed outline, (2) line [shown in the image], and (3) solid.  There is also a 4th type, which is a custom caret up to 16 x 32 in size.

The mouse pointers supported by default are:  (1) arrow, (2) inverse arrow [white with black outline], (3) cross, (4) I-Beam, and a custom type of up to 16 x 32 in size.

Carets and mouse pointers are all up to 254 shades of gray, so they can be smoother than what I have shown there.  You can see their default appearances here.

UPDATE:  The information at the bottom is debugging info:  mouse position, timer tick, caret position.  The caret flashes on and off and is only displayed on ticks, not tocks.  Here it's on a tick cycle.
« Last Edit: December 10, 2017, 01:54:05 pm by Rick C. Hodgin »

ak120

  • Guest
Re: ES/1 open source kernel
« Reply #38 on: December 10, 2017, 08:39:15 pm »
Here's a screenshot.  I'm using VESA video modes.  This one is 1600 x 1200 with 32-bit color.

It's unbelievable. Unfortunately a colour in PNG files can only have 1, 2, 4 or 8 bits (or additionally 16 bits for grayscale). Simply run a test to count the number of colours in the attached image file.

Those who know nothing must believe everything.

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #39 on: December 10, 2017, 10:30:26 pm »
Here's a screenshot.  I'm using VESA video modes.  This one is 1600 x 1200 with 32-bit color.

It's unbelievable. Unfortunately a colour in PNG files can only have 1, 2, 4 or 8 bits (or additionally 16 bits for grayscale). Simply run a test to count the number of colours in the attached image file.

32-bits is the color depth.  It uses R,G,B,X each 8-bits.

32-bits uses 8:8:8:8 bits for R,G,B,X.
24-bits uses 8:8:8 bits for R,G,B.
16-bits uses 5:6:5 bits for R,G,B.

The image you see is a text-based console window projected into graphics modes.  It only uses 16-colors.

During development of my mouse pointer algorithms, I had some bugs at various times, and every color of the rainbow appeared. :-)

You can see the VESA algorithms I created here.  Search for "bpp" to find references to various drawing algorithms.

I can create an app that renders something in colors.  Tell me what to write and I'll post the source code and instructions for how to compile it so you can run it live and see it rendering colors.
« Last Edit: December 10, 2017, 11:24:39 pm by Rick C. Hodgin »

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #40 on: December 11, 2017, 02:11:18 am »
I can create an app that renders something in colors.  Tell me what to write and I'll post the source code and instructions for how to compile it so you can run it live and see it rendering colors.

I know what I'll write.  The ES/1 logo and splash screen for booting.  Here is a sample from OS/2.

UPDATE:  Here's the initial design.
« Last Edit: December 11, 2017, 04:00:55 am by Rick C. Hodgin »

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #41 on: December 11, 2017, 05:42:28 am »
...Unfortunately a colour in PNG files can only have 1, 2, 4 or 8 bits (or additionally 16 bits for grayscale).

The bit depth you indicate there are per color channel bit counts (such as 1, 2, 4 or 8 bits for the red channel, and another 1, 2, 4 or 8 bits for the green, and another set for the blue, resulting in 3-bit, 6-bit, 12-bit, or 24-bit colors by your own statement).

PNG also supports extended true color RGB images with a full 16 bits per color channel, resulting in a total encoding of 48-bit samples per pixel.  And there is one which includes an alpha channel RGBA with 32- or 64-bits per pixel.

www.libpng.org -- Chapter 8 -- PNG Basics -- 8.5.6 RGB
« Last Edit: December 11, 2017, 04:34:37 pm by Rick C. Hodgin »

ak120

  • Guest
Re: ES/1 open source kernel
« Reply #42 on: December 13, 2017, 01:11:01 am »
32-bits is the color depth.  It uses R,G,B,X each 8-bits.
But only R, G and B are colours - it's still 24bits of colour depth summarised.

By using 10 bits you would get 30bits totally. But 32bits is very uncommon - I cannot think of any practical example.

Quote
The image you see is a text-based console window projected into graphics modes.  It only uses 16-colors.
Hard-coded or per virtual screen?

I know of Greg's book but prefer the paper form. ;-)

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #43 on: December 13, 2017, 10:42:10 am »
32-bits is the color depth.  It uses R,G,B,X each 8-bits.
But only R, G and B are colours - it's still 24bits of colour depth summarised.

By using 10 bits you would get 30bits totally. But 32bits is very uncommon - I cannot think of any practical example.

32-bits is used everywhere.  It is far faster and simpler to code, and automatically maintains alignment in memory.  Some ATI VESA implementations only support 16-bit and 32-bit for data alignment.

Quote
The image you see is a text-based console window projected into graphics modes.  It only uses 16-colors.
Hard-coded or per virtual screen?

Hard-coded presently to emulate VGA BIOS color defaults, but easily extensible.

Since your comment about colors, I have had it in mind to provide calls which allow arbitrary rgba() colors as well.  They would work on graphics consoles by overriding the default mapped color attributes.  I am also adding support for disabled, and underlined text in graphics mode.  Disabled will dither.
« Last Edit: December 13, 2017, 10:43:41 am by Rick C. Hodgin »

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #44 on: December 15, 2017, 10:18:17 pm »
For ES/1, I have developed a fairly comprehensive graphics engine that runs entirely under VESA.  I'm currently working on a fonts engine to support more than 8x8, 8x14, and 8x16 fixed-point console fonts.  I plan to have a proportional "libsf" font, and a fixed point "libsf mono" font at release, in addition to the three console fonts.

As such, ES/1 will now launch with a start bar, a few built-in programs, and the ability to run multiple graphical command windows simultaneously.  I will begin working on a primitive Presentation Manager interface, which will allow non-console windows which contain graphics and special drawing abilities.

I plan for ES/1 to be a very simple 32-bit kernel which initially allows 16-bit apps to run using Dos*() and other function calls to simulate BIOS, but over time is expanded into a full 32-bit OS as indicated below.

Code: [Select]
The plans are:
Version 0.1 -- boot and run from a floppy disk
Version 0.2 -- boot from a floppy or FAT16 hard disk
Version 0.3 -- adds additional apps to support the kernel
Version 0.4 -- introduction of a general purpose text editor, compiler, and assembler for creating custom ES/1 apps
Version 0.5 -- increased development of the Presentation Manager
Version 0.6 -- introduction of system objects
Version 0.7 -- a fully integrated desktop and the introduction of 32-bit apps
Version 0.8 -- network stack, sockets, ES/1 network file system support
Version 0.9 -- boot from a network drive, some usable userland apps
Version 1.0 -- a functional general purpose OS release

I plan for each ES/1 release will be available as a downloadable virtual machine image with virtual media already configured, able to run under Oracle's VirtualBox.  Or, as stand-alone boot floppy images for real machine installation.  I plan for Version 1.0 to be able to run multiple apps well, possess a robust desktop user experience within its fully object-oriented design, giving it a general look and feel similar to that of OS/2's desktop.

ES/1 will serve as the base for the Al-x kernel extended development, and eventually as the base for what will become ES/2 as those innate abilities are refactored for the needs of a backward binary-compatible OS/2 kernel replacement, and later driver replacement and user apps replacement.

The goal for ES/1 is to be a launching platform for the rest of development, which will eventually yield a complete and fully-replaced OS/2 kernel and suite of drivers, utilities, apps, everything.  I look forward to having other developers come on board as development progresses.
« Last Edit: December 15, 2017, 10:22:58 pm by Rick C. Hodgin »