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

Alfredo Fernández Díaz

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 17
    • View Profile
Re: ES/1 open source kernel
« Reply #45 on: December 16, 2017, 01:23:58 pm »
Just a quick question: unicode?

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #46 on: December 16, 2017, 01:33:37 pm »
Just a quick question: unicode?

For ES/1, partially supported through limited code page support through libsf and libsf-mono fonts.  I am creating a new font editor tool.  The more help I get in authoring characters for other languages, the more support there will be.  I wil unveil the font tool next.  You will see limited ES/1 updates until then.

For ES/2:  Planned to be fully supported.  I like Microsoft's ability to have funcA() for ascii, and funcW() for unicode.  There will be full kernel support for unicode, including filenames and all tag names.  Everything that can be asciiz can also be unicode, except conversion functions. :-)
« Last Edit: December 16, 2017, 01:40:30 pm by Rick C. Hodgin »

Alfredo Fernández Díaz

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 17
    • View Profile
Re: ES/1 open source kernel
« Reply #47 on: December 16, 2017, 01:58:16 pm »
For ES/1, partially supported through limited code page support through libsf and libsf-mono fonts.  I am creating a new font editor tool.  The more help I get in authoring characters for other languages, the more support there will be.  I will unveil the font tool next.  You will see limited ES/1 updates until then.
You may want to check Alex Taylor's bitmap and vector fonts -- I think his license would let you relieve quite some work from that front. Custom tools or not, I don't think you have developed a third way to define glyphs* so you probably can re-use work.

*You haven't, have you? :)

Quote
For ES/2:  Planned to be fully supported.  I like Microsoft's ability to have funcA() for ascii, and funcW() for unicode.  There will be full kernel support for unicode, including filenames and all tag names.  Everything that can be asciiz can also be unicode, except conversion functions. :-)
Just like it is a subset of all codepages, ASCII is also a subset of unicode (ASCII chars are unicode chars 0-127), so why do you need funcA?

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #48 on: December 16, 2017, 02:22:42 pm »
For ES/1, partially supported through limited code page support through libsf and libsf-mono fonts.  I am creating a new font editor tool.  The more help I get in authoring characters for other languages, the more support there will be.  I will unveil the font tool next.  You will see limited ES/1 updates until then.
You may want to check Alex Taylor's bitmap and vector fonts -- I think his license would let you relieve quite some work from that front. Custom tools or not, I don't think you have developed a third way to define glyphs* so you probably can re-use work.

*You haven't, have you? :)

I began with fundamentals.  I designed everything up from there.  I did what made sense to me.  Others can judge for themselves the nature of its originality or usefulness.

Quote
For ES/2:  Planned to be fully supported.  I like Microsoft's ability to have funcA() for ascii, and funcW() for unicode.  There will be full kernel support for unicode, including filenames and all tag names.  Everything that can be asciiz can also be unicode, except conversion functions. :-)
Just like it is a subset of all codepages, ASCII is also a subset of unicode (ASCII chars are unicode chars 0-127), so why do you need funcA?

ASCII goes 0..255 in my opinion. :-)  It never made sense to hobble existing apps which use those characters so they'd have to be significantly rewritten in moving forward.  Less of an issue now, but still ... it's a sound goal.

I'm not trying to piece together what already exists because it's faster.  I'm trying to build up a product from the ground, founded on the Lord, given over to this project for the people, so that all of it is built from within those who will contribute, for that purpose, on purpose.  In that way its origins are solidly given over in that way, with a common thread of purpose throughout.
« Last Edit: December 16, 2017, 02:34:55 pm by Rick C. Hodgin »

Alfredo Fernández Díaz

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 17
    • View Profile
Re: ES/1 open source kernel
« Reply #49 on: December 16, 2017, 02:55:42 pm »
ASCII goes 0..255 in my opinion. :-)
But that's what the codepage mess was about from the start. All codepages I know of* (classic ones, I don't know if the term has caught on a new meaning lately) are 255-character sets, and every character on any of them is therefore represented by one byte. And that's the problem: simplifying quite a bit, you only 'know' character 0x65 is an 'A' because ALL codepages have 'character 0x65 = A' in their definition. But the answer to 'what is character #128' (or whatever > 2^7 -1 = 127)? depends on what codepage you are using. You can't just put say Spanish and Russian ASCII text together like that because the same numbers above 127 represent different characters, etc. Unicode was conceived to get rid of those problems, but had to be retro-fitted unto existing systems, which caused problems of its own.

If you asked me, my own Unicode implementation would be very different from what we have currently, but that's another story. If you are beginning something from scratch, and want it to be able to eventually 'talk' to the rest of existing software, proper Unicode support is a must because it is nearly universal now.

*I am leaving DBCS CPs aside for the sake of simplicity. These are of course 65535-char codepages, hence 'DBCS'.

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #50 on: December 16, 2017, 03:00:41 pm »
If you asked me, my own Unicode implementation would be very different from what we have currently, but that's another story. If you are beginning something from scratch, and want it to be able to eventually 'talk' to the rest of existing software, proper Unicode support is a must because it is nearly universal now.

What would you create?  OS/2 supported unicode, albeit clunkily.  It would be a reversal of direction to replace it.  It's also completely prevalent today.  If any apps would be ported, support would have to exist.

Alfredo Fernández Díaz

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 17
    • View Profile
Re: ES/1 open source kernel
« Reply #51 on: December 16, 2017, 03:13:34 pm »
Sorry, we can discuss my own ideas of how we could have a better Unicode some other day, it would require much thinking and long-term plans of interoperability -- assuming it would actually be better ;)

What I meant to say is that any new thing of yours that wants to talk to other software today must readily implement Unicode as we have it today (or interfaces to it), and not get stuck in the codepages stage. If it is not, fine :)

Andreas Kohl

  • Sr. Member
  • ****
  • Thank You
  • -Given: 6
  • -Receive: 12
  • Posts: 280
    • View Profile
    • warpserver.de
Re: ES/1 open source kernel
« Reply #52 on: December 16, 2017, 04:28:54 pm »
ASCII goes 0..255 in my opinion. :-)
7-bit ASCII was always from 0 to 128. But ISO-8859-1 (CP819) offers 8-bit.

Quote
But that's what the codepage mess was about from the start. All codepages I know of* (classic ones, I don't know if the term has caught on a new meaning lately) are 255-character sets, and every character on any of them is therefore represented by one byte.
That's the special case for 8-bit SBCS codepages - it's a good idea to distinguish between codepage and char set.

Quote
And that's the problem: simplifying quite a bit, you only 'know' character 0x65 is an 'A' because ALL codepages have 'character 0x65 = A' in their definition.
I can not follow at this point. Only a subset ASCII derived codepages behave this way. Decimal 65 for 'A' fine but in EBCDIC 'A' is 193.

Quote
But the answer to 'what is character #128' (or whatever > 2^7 -1 = 127)? depends on what codepage you are using. You can't just put say Spanish and Russian ASCII text together like that because the same numbers above 127 represent different characters, etc.
ASCII is a stupid American thing. For Russian there is GOST or better use Unicode. If you want to manage it with 7-bit ASCII you can do it with TeX.

Quote
*I am leaving DBCS CPs aside for the sake of simplicity. These are of course 65535-char codepages, hence 'DBCS'.
But nowadays MBCS are quite common or call it variable character size encodings.

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #53 on: September 18, 2018, 11:09:32 pm »
Just a quick update.

This project has not gone away and will continue.  I am currently working on developing a general purpose compiler called CAlive that supports (C/C++)-like code.  It will serve as the base compiler used for x86, as well as my own VM I'm working on (called Inspire VM), and will serve as the compiler I use to compile the user OS/2 source code people have for creating binaries that run in ES/2.

ES/1 will serve as a simple test platform for developing and testing new designs that will filter into ES/2.

If any of you would like to help, my plans are to continue development of ES/1 and ES/2 after I get my compiler completed, which is targeted for sometime on or around Christmas 2019.

Thank you. :-)
« Last Edit: September 19, 2018, 01:22:07 am by Rick C. Hodgin »

David Graser

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 27
  • Posts: 323
    • View Profile
Re: ES/1 open source kernel
« Reply #54 on: October 06, 2018, 07:25:15 pm »
Rick

Hopefully your new kernel will eventually do away with the SIQ. 
« Last Edit: October 06, 2018, 09:49:40 pm by David Graser »

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #55 on: November 26, 2018, 09:18:32 pm »
Quote from: Rick C. Hodgin
Nov.13.2017I'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. :-)

I've revisited this plan and have been working on the ES/1 kernel again.  I'm working in IBM PC DOS 7 with Open Watcom 1.9 on the graphics engine.  ES/1 will support basic graphics (windows, controls, be event-driven), as well as console windows displayed in a graphics window.

I'm currently working on my FAT12/16 driver to allow hard disk access without BIOS support.  Once that is completed, I'll begin working on supporting many functions present in the DOS INT 21h API, and will present a system people can download and try.

My goal is to use ES/1 as a platform for developing base ES/2 algorithms, but real development on ES/2 won't begin until late 2019 or so.  I'd like to have ES/1 booting, accessing hard disks, using VESA to support video modes, and handling all forms management in software, and get it working on as many types of machines as possible (those with traditional BIOS).

Once it's up and running, I'll begin creating tools which work in the ES/1 environment, and if there are others who would like to port other tools then I can extend the API to support whatever they need.

ES/1 intends to be a fully pre-emptive 32-bit multi-tasking OS running on a single core initially, with SMP added in mid-/late-2019.  It will support 16-bit and 32-bit code, including real mode code in v86.  I may never make a 64-bit ES/1 version, but ES/2 will be a 32-bit / 64-bit hybrid out of the box.  The user will actually be able to choose to boot into either the 32-bit or 64-bit kernel with a startup option.
« Last Edit: November 26, 2018, 09:21:51 pm by Rick C. Hodgin »

RickCHodgin

  • Guest
Re: ES/1 open source kernel
« Reply #56 on: November 27, 2018, 12:03:40 pm »
In development of the ES/1 operating environment, I've run into a limit in Open Watcom being able to compile the program in DOS as monolithic.  Am going to have to break it out into separate modules.