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

RickCHodgin

  • Guest
ES/1 open source kernel
« on: November 16, 2017, 09:37:28 pm »
Quote from: Rick C. Hodgin
Nov.13.2017 -- A quick update:

I've begun coding a DOS-like ES/1 operating system as a precursor to my ES/2 kernel.  It will be a simple text-based kernel in real-mode allowing me to port compilers, assemblers, linkers, debuggers, to that system, allowing me to test code in a simple environment, one I can easily mimic in IBM PC DOS 7.

ES/1 will also be released as a simple public OS people will be able to download and use for FAT12 and FAT16 disks.  It will also natively allow serial port networks. :-)

Quote from: Rick C. Hodgin
Nov.16.2017 -- I have a text-based forms mechanism.  I'm currently developing my own master boot record, partition, FAT12 and FAT16 drivers, as well as an ES/1 compiler, assembler, linker, and debugger.  A large portion of that code is being ported from my existing kernel code.

I still have to complete:  COM port I/O, the basic ES/1 command prompt.

I will send screenshots at some point.  I'm using a 3dfx Voodoo3 2000 card as it does a 132x60 text mode (at 0xb8000 for those who know what that means, allowing me to reclaim 0xa0000 - 0xb7fff for real mode memory).

ES/1 will boot like a basic 16-bit DOS running on an 80386 or higher, and have a developer environment.  It will be a springboard for 16-bit ES/2 development.

It will boot up as:
Code: [Select]
ES/1 Operating System - Command Prompt
Nov.16.2017 06:30 am

[c:\es1\] _

I've created this thread to discuss ES/1 development and to answer any questions.  ES/1 is basically a stand-alone self-bootable version of what will become the 16-bit components present in ES/2:

My goals:
  • Get ES/1 developed sufficiently to boot stand-alone (on floppy or FAT16 hard disk)
  • Release for public inspection and testing
  • Develop compiler, assembler, linker, debugger, in ES/1
  • Release for public inspection and testing
  • Use ES/1 as a launching pad for all ES/2 development

Note also that ES/1 will have a nice set of basic abilities.  It will serve as a decent launching pad for any custom kernel efforts.  Since ES/1 will pretty much use only what BIOS has already established, you can load your kernel into 0x0000:0x7c00 and single-step debug your way through all real-mode code.  If you write it in my compiler and/or assembler, you'll have source-level debugging abilities to boot your own kernel.

--
Rick C. Hodgin

ak120

  • Guest
Re: ES/1 open source kernel
« Reply #1 on: November 16, 2017, 09:43:46 pm »
So how it runs inside a VDM?

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #2 on: November 16, 2017, 09:53:54 pm »
So how it runs inside a VDM?

I'm running it on native hardware, but it should run perfectly fine as it uses very basic BIOS services for keyboard, mouse, disk, video, timer, with pretty much everything else being completely custom developed.  It won't have any USB support, save any BIOS emulation of USB devices as standard devices (PS/2 keyboard + mouse, hard drives, etc).

I will use it to develop the ES/1 and ES/2 networking stack, and also the algorithms required for FAT32 and JFS file support.

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #3 on: November 17, 2017, 02:40:35 pm »
The user interface is becoming mature.  It will be integrated as a standard set of ES/1 DLLs available for linking against at runtime.  I'll try and post some screenshots this weekend.

My next goal is to get the disk services working.  These are internal support algorithms for these command line functions:

Code: [Select]
DIR {/w /a: /p}      // Normal directory
CD target            // Change directory
MD target            // Make directory
RD target            // Remove directory
COPY src dst         // Copy one file to another
COPY CON target      // Copy console content to file
TYPE {/hex} target   // Display file content
program              // Load an ES/1 program, .BAT, or .REX into memory
DEBI program         // Load an ES/1 program into memory and launch the Debi debugger
DATE                 // System date
TIME                 // System time
REBOOT {/cold}       // Restart ES/1 either warm or cold

At that point, the system will be usable (provided there are programs written in ES/1 to run).  After that, the compiler, assembler, linker, and debugger.

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #4 on: November 18, 2017, 08:20:16 pm »
So how it runs inside a VDM?

I was able to verify it runs in dosbox 0.74 for Windows.  I haven't been able to figure out how to get it to use larger than an 80x25 text screen in dosbox, however, so it's limited.  VESA reports no extended 132xYY text modes, so it may not be possible.  The things I've been designing have been for my personal use and use 132x60 video modes.  I'm working on posting some screen shots right now.

ak120

  • Guest
Re: ES/1 open source kernel
« Reply #5 on: November 18, 2017, 10:01:10 pm »
So how it runs inside a VDM?

I was able to verify it runs in dosbox 0.74 for Windows.  I haven't been able to figure out how to get it to use larger than an 80x25 text screen in dosbox, however, so it's limited.  VESA reports no extended 132xYY text modes, so it may not be possible.  The things I've been designing have been for my personal use and use 132x60 video modes.  I'm working on posting some screen shots right now.
DOSbox is a special case. It doesn't offer accurate emulation of an IBM PC compatible architecture. Fortunately even under Microsoft's OS/2 derived products there is a broader choice of emulation methods. Virtual PC or Virtual Server can do the trick for a limited set of modes. VirtualBox or QEMU use the Bochs Video BIOS. And PCem https://pcem-emulator.co.uk/status.html offers support for different graphic adapters.

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #6 on: November 18, 2017, 10:12:23 pm »
So how it runs inside a VDM?

I was able to verify it runs in dosbox 0.74 for Windows.  I haven't been able to figure out how to get it to use larger than an 80x25 text screen in dosbox, however, so it's limited.  VESA reports no extended 132xYY text modes, so it may not be possible.  The things I've been designing have been for my personal use and use 132x60 video modes.  I'm working on posting some screen shots right now.
DOSbox is a special case. It doesn't offer accurate emulation of an IBM PC compatible architecture. Fortunately even under Microsoft's OS/2 derived products there is a broader choice of emulation methods. Virtual PC or Virtual Server can do the trick for a limited set of modes. VirtualBox or QEMU use the Bochs Video BIOS. And PCem https://pcem-emulator.co.uk/status.html offers support for different graphic adapters.

I typically use VirtualBox and Bochs, but I haven't setup an IBM PC DOS 7 machine yet.  But I'm sure it will work because I only use the absolute smallest set of BIOS functions, the rest is all reliant only upon the hardware itself, and should work on any compliant CPU.

ES/1 in production will probably only be an 80x25 video system like normal consoles, and I'll probably allow 80x50, and other modes via VESA calls which can enumerate their capabilities (the 3dfx Voodoo3 2000, for example, enumerates 132x25, 132x43, 132x50, and 132x60 as text modes).

And, it will be open source so people can port it to whatever they like.  If the patch is good code, I'll accept it back upstream into the ES/1 mainline. :-)

I almost have the screen shot converter written.  I am capturing text with attributes to a disk file, and then running it through a post-processor to generate the .BMP file, which will be converted to a .PNG file.  Eventually I'll incorporate this ability in the text-based console using the iVio_screenCapture(filename); function.

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #7 on: November 18, 2017, 11:55:40 pm »
I doubt anyone cares about this project at this point, but to keep people posted here's where I am:  I had to use my ES/2 fonts for generating this image, and they use my specially mapped upper ASCII characters.  As such, they come through like the attached image, showing some characters incorrectly.  The characters around the double-lines look correct, but the single-line borders were usurped by my own font characters, so they don't show up properly in this image.

I'll have to download the original VGA font bitmaps from the graphics card and re-generate the image.

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #8 on: November 19, 2017, 01:31:10 am »
Updated image using the VGA 8x16 font.  The original image above was with an 8x14 font.


RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #9 on: November 19, 2017, 04:23:57 am »
The two screens now rendered in an 8x14 font.  The navigation from highlighted blue/cyan window to each of the other windows is with F6 and Shift-F6.  Tab and Shift-Tab navigates input fields within each window.  F12 saves a screenshot.  Escape exits.  All keys and mouse movements are routed through custom callback functions.

Other such windows can be created.  A main form is created, and then windows are created and arranged within it.  And then objects are added to each window allowing for inputs like labels, textboxes, editboxes, checkboxes, and other controls can be added as needed.

The source code for rendering the screenshots has been checked in.  You can also see the font data extracted from the VGA card for 8x8, 8x14, and 8x16 modes.
« Last Edit: November 19, 2017, 04:29:17 am by Rick C. Hodgin »

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #10 on: November 20, 2017, 03:24:16 am »
I have the Disk Inspector reading data.  It also has checkboxes now, and the input boxes for the text and numbers are complete.  Still have date and time to complete.

Here we see the first disk sector on drive C:, which is device 128 (0x80 hex).

ak120

  • Guest
Re: ES/1 open source kernel
« Reply #11 on: November 20, 2017, 12:18:26 pm »
If you're keen on some publicity or a wider audience why not simply setting up a demo image with Jeff's PCjs. Just my two cents...

Et ne nos inducas in tentationem.

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #12 on: November 20, 2017, 12:35:27 pm »
If you're keen on some publicity or a wider audience why not simply setting up a demo image with Jeff's PCjs. Just my two cents...

Et ne nos inducas in tentationem.

I don't understand.  But, I'm not keen on publicity.  I have a lot of work ahead of me.  Until I get a bootable, semi-usable product, I would only post my updates here.  And if people aren't interested, I'm content to work without posting updates.

Here's my source code for the screenshots above, the Disk Inspector, and Debi Debugger.  It's designed for 132x60 text-based video modes.  Here's the utility which does the text screenshot converter.  And here are all the video algorithms.

All released under a PBL license.
« Last Edit: November 20, 2017, 12:41:26 pm by Rick C. Hodgin »

ak120

  • Guest
Re: ES/1 open source kernel
« Reply #13 on: November 20, 2017, 01:01:16 pm »
I will not judge about the expedience of using C++ in your approach. But I can give the "wise" advise: better using C. Everything else can be called a lèse-majesté.

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #14 on: November 20, 2017, 01:08:21 pm »
I will not judge about the expedience of using C++ in your approach. But I can give the "wise" advise: better using C. Everything else can be called a lèse-majesté.

It is C code.  It uses a handful of C++ syntax relaxations, but with minor tweaks it will compile in a C compiler.

C++ doesn't require "struct" keyword, and allows anonymous unions and certain line comments.  And I also use parameter initialization, and if it came up I would use function overloading.  That's about all I use of C++ though.  I don't use the class, or exception handling, etc.  I just like to use the C++ compiler because it's like "an extended and somewhat simplified C," but it also adds additional type checking, which I also prefer.

UPDATE:  I thought of one more thing I use:  bool types. :-)
« Last Edit: November 22, 2017, 04:44:00 am by Rick C. Hodgin »