Author Topic: ES/2 development  (Read 1428 times)

Rick C. Hodgin

  • Full Member
  • ***
  • Thank You
  • -Given: 13
  • -Receive: 2
  • Posts: 181
    • View Profile
    • Liberty Software Foundation
ES/2 development
« on: November 04, 2017, 01:10:06 pm »
Would anyone be interested in me posting about ES/2 development?

Here's the type of thing I have in mind.  If it's boring or of no interest please let me know.  I'll keep the same thing as a libsf.org/es2/blog, so people could just go there and see it as well.

Nov.04.2017:
I've been reviewing some of my hardware books.  Since I'll now be using an OS/2 machine for development, and a separate ES/2 machine for testing, I've decide to abandon the floppy disk method of writing changes and then booting.  Instead, I'm going to write a tiny loader program for the ES/2 machine which resides on the hard drive and is loaded automatically by BIOS.  It will then continue loading a slightly larger program which is designed to do one thing:  send and receive signals through the serial or parallel port to the OS/2 machine.

The OS/2 machine will maintain a virtual hard drive of what files are on the ES/2 machine, and these will be updated during development.  It will run a background process which monitors the serial or parallel port and fills requests as they come in during boot, along with becoming a go-between for debugging abilities on the OS/2 machine, and debugger modules on the ES/2 machines which can convey information about the ES/2 machine state.

During boot, the ES/2 machine will basically just be in "data receive" mode and the OS/2 machine will send the whole kernel image to the ES/2 machine, which will receive that data and route it to various portions of memory just as if it had been loaded from the floppy or hard disk.  Once everything's been received, the OS/2 machine will send a "go xyz" command, which will have the ES/2 machine jump to the xyz location and begin the real ES/2 kernel boot process.

By employing this system, I'll have a simple protocol to allow for very fast reboots, and the ability to change things running in memory, to be able to monitor the ES/2 machine state, to be able to remotely control the ES/2 machine from the OS/2 machine through custom built debuggers and machine reset programs, etc.

Everything will reside only in memory on the ES/2 machine for now, but will be permanent on disk on the OS/2 machine.  I'll be able to recompile software on the OS/2 machine and send live updates to the ES/2 machine to correct bugs while the ES/2 OS instance is live and running.  I'll be able to do all necessary remote debugging and monitoring, and create and extend a host of other kernel-level monitoring and control features that will be exposed and available during development.

Once I get my kernel booting and developed properly using this methodology, I'll use it to develop the network stack, and then ultimately switch over to a full network TCP/IP-based system to allow remote debugging at much faster speeds, and even over the Internet at that point.


UPDATE 7:03 pm:
I've been able to get the assembler and C compiler successfully compiling ES/2 source code.  I'm having some difficulty with the linker in an OS/2 environment.  It doesn't like some of the starting addresses.  And, I'm fairly new to REXX so converting .BAT files to .CMD files has proven interesting.  I need some help on how to single-step / debug REXX code.
« Last Edit: November 05, 2017, 05:44:58 am by Rick C. Hodgin »



Mike La Martina

  • Jr. Member
  • **
  • Thank You
  • -Given: 1
  • -Receive: 3
  • Posts: 50
    • View Profile
Re: ES/2 development
« Reply #1 on: November 05, 2017, 04:45:37 am »
I am interested in learning more about your efforts.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 7
  • -Receive: 88
  • Posts: 1146
    • View Profile
Re: ES/2 development
« Reply #2 on: November 05, 2017, 05:48:26 am »
I've been able to get the assembler and C compiler successfully compiling ES/2 source code.  I'm having some difficulty with the linker in an OS/2 environment.  It doesn't like some of the starting addresses.  And, I'm fairly new to REXX so converting .BAT files to .CMD files has proven interesting.  I need some help on how to single-step / debug REXX code.

Generally DOS BAT scripts should run fine under cmd.exe just by renaming to have a .cmd suffix, foo.bat --> foo.cmd.
Always nice to use REXX. You have PMREXX, pmrexx.exe foo.cmd. Tracing with PMREXX, pmrexx.exe /T foo.cmd and REXXTRY for testing functions.

For help with the linker, the source of the OpenWatcom linker is freely available and may be worth using until you get your linker working. There are other resources available for our object format such as Agner Fog's object converter or the source for lxlite for LX executables.
I'm sure many of us are interested enough to watch your progress.

Rick C. Hodgin

  • Full Member
  • ***
  • Thank You
  • -Given: 13
  • -Receive: 2
  • Posts: 181
    • View Profile
    • Liberty Software Foundation
Re: ES/2 development
« Reply #3 on: November 05, 2017, 06:03:51 am »
Nov.05.2017 12:55am
I've been going back through my various hardware books.  I've found code samples / templates for writing EPP+ECP parallel drivers (2+ MB/s) as well as serial drivers (12 KB/s).  I'm going to try to get them both working in DOS first.  Once working, I'll attempt them in OS/2, and code them successfully in ES/2. :-)

I have a terminal app I wrote back in the 90s called "2.It" (because it connected to it -- BBS sites back in the day).  It has solid serial protocols already debugged.  For EPP+ECP it will be new development.

I won't spend too much time on it right now.  My kernel is only about 180 KB including 128 KB for the kernel debugger.  So a full cold boot over serial would be under 20 seconds.  And updates while running would only be a few seconds.  With EPP+ECP it would be a couple seconds for cold boot and instantaneous updates while running.

I'll be using second IDE hard drives for my OS/2 and ES/2 machines, both with a target of IBM PC DOS 7.1, and probably Digital Mars for a compiler.  Should be a good test environment.
« Last Edit: November 05, 2017, 06:06:21 am by Rick C. Hodgin »

Rick C. Hodgin

  • Full Member
  • ***
  • Thank You
  • -Given: 13
  • -Receive: 2
  • Posts: 181
    • View Profile
    • Liberty Software Foundation
Re: ES/2 development
« Reply #4 on: November 05, 2017, 07:05:29 pm »
Nov.05.2017 -- 1:05pm
Am installing IBM PC DOS 7 on two machines, and two old IDE hard drives.  Will be installing Watcom for DOS to help with development.  I may also try Digital Mars.

Rick C. Hodgin

  • Full Member
  • ***
  • Thank You
  • -Given: 13
  • -Receive: 2
  • Posts: 181
    • View Profile
    • Liberty Software Foundation
Re: ES/2 development
« Reply #5 on: November 05, 2017, 07:07:51 pm »
Generally DOS BAT scripts should run fine under cmd.exe just by renaming to have a .cmd suffix, foo.bat --> foo.cmd ... Tracing with PMREXX, pmrexx.exe /T foo.cmd and REXXTRY for testing functions.

Did not know that.  Thank you, Dave.  Will look into REXXTRY as well.

Quote
For help with the linker, the source of the OpenWatcom linker is freely available and may be worth using until you get your linker working. There are other resources available for our object format such as Agner Fog's object converter or the source for lxlite for LX executables.
I'm sure many of us are interested enough to watch your progress.

The linker works, but I have to declare my code compiles to begin at offset 0 instead of the standard offset 0x100, which is common for DOS-based .COM files.  By setting it to 0, I am able to have the code loaded into its own segment selector during boot.

I'm sure there's a way around it, but I just have to figure it out.

Rick C. Hodgin

  • Full Member
  • ***
  • Thank You
  • -Given: 13
  • -Receive: 2
  • Posts: 181
    • View Profile
    • Liberty Software Foundation
Re: ES/2 development
« Reply #6 on: November 05, 2017, 10:21:43 pm »
Nov.05.2017 -- 4:20pm
I was able to get IBM PC DOS 7 installed, and Watcom for DOS installed.  Everything worked and compiled.  I discovered the code I had from the code examples were expecting Turbo C++ 2.0 for DOS, so I was able to locate that online and install it.  It also worked and compiled.  It also has nice integrated DOS-based tools including a nice debugger, so I'll probably use that in moving forward.

At least one of the machines I'm using does not support EPP+ECP hardware, so I'll fall back on regular parallel protocols.  It will be slower, but still at least 20x faster than serial.  For right now, I'm going to try to get serial communications working at 115.2 Kbps in OS/2, and then in ES/2.

Rick C. Hodgin

  • Full Member
  • ***
  • Thank You
  • -Given: 13
  • -Receive: 2
  • Posts: 181
    • View Profile
    • Liberty Software Foundation
Re: ES/2 development
« Reply #7 on: November 06, 2017, 05:56:58 am »
Nov.05.2017 -- 11:51pm
I have been able to get the serial port code algorithms half working on OS/2.  The com.sys API only supports 9600 baud, so I will have to try or write another driver.  My DOS-based 2.It program works properly, so I can scavenge that code for ES/2.

Things are looking promising in my Windows-to-OS/2 development platform migration.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 7
  • -Receive: 88
  • Posts: 1146
    • View Profile
Re: ES/2 development
« Reply #8 on: November 06, 2017, 07:03:25 am »
Nov.05.2017 -- 11:51pm
I have been able to get the serial port code algorithms half working on OS/2.  The com.sys API only supports 9600 baud, so I will have to try or write another driver.

Huh? I wonder how my modem goes so fast over the serial port then? It's set at 230400 but with a 28.8 connection I only see it go higher then 57600 occasionally on very compressible data.

Andi B.

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 12
  • Posts: 318
    • View Profile
Re: ES/2 development
« Reply #9 on: November 06, 2017, 09:41:53 am »
Quote
...working on OS/2.  The com.sys API only supports 9600 baud, so I will have to try or write another driver...
I use serial communication with OS/2 at 115200 baud since ages. No clue why you think a new driver is needed. Look at f.i. bloatcom samples at hobbes. I'm pretty sure current toolkit programming references describes this too. Something like
Code: [Select]
  cp->rc = DosDevIOCtl(cp->hCom, IOCTL_ASYNC, ASYNC_SETBAUDRATE, &usRate, sizeof(usRate), &cbPinout, NULL, 0L, &cbDinout);
or
  cp->rc = DosDevIOCtl(cp->hCom, IOCTL_ASYNC, ASYNC_EXTSETBAUDRATE, &esr, sizeof(esr), &cbPinout, NULL, 0, &cbDinout);

will do the job.

Rick C. Hodgin

  • Full Member
  • ***
  • Thank You
  • -Given: 13
  • -Receive: 2
  • Posts: 181
    • View Profile
    • Liberty Software Foundation
Re: ES/2 development
« Reply #10 on: November 06, 2017, 11:01:51 am »
Nov.05.2017 -- 11:51pm
I have been able to get the serial port code algorithms half working on OS/2.  The com.sys API only supports 9600 baud, so I will have to try or write another driver.

Huh? I wonder how my modem goes so fast over the serial port then? It's set at 230400 but with a 28.8 connection I only see it go higher then 57600 occasionally on very compressible data.

When I try as Andi B suggests with DosOpen "COM1" setting with 115200 and ASYNC_SETBAUDRATE, I get invalid parameter error returned.  Switch back to 9600 and it succeeds.  And two paper OS/2 programming books I have show valid inputs from 300 to 9600, nothing beyond.  I haven't tried ASYNC_EXTSETBAUDRATE.

I'll try again. :-). It seemed weird to me too.  I just figured I needed a different driver than the default COM.SYS.  What driver is in your CONFIG.SYS?

I found this XFree86 code.  I'll adapt it and try it as well.
« Last Edit: November 06, 2017, 02:45:40 pm by Rick C. Hodgin »

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 7
  • -Receive: 88
  • Posts: 1146
    • View Profile
Re: ES/2 development
« Reply #11 on: November 06, 2017, 04:22:17 pm »
Quote
What driver is in your CONFIG.SYS?

pscom.sys, which as far as I know, is there to fix some SMP issues. My Warp v4 partition still has com.sys and dial up works the same there.
What version of OS/2 are you running? Here, on Warp v4, I'm using

[E:\OS2\BOOT]bldlevel com.sys
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#IBM:10.036#@ COM Port Driver-SMP
Vendor:          IBM
Revision:        10.36
File Version:    10.36
Description:     COM Port Driver-SMP

Rick C. Hodgin

  • Full Member
  • ***
  • Thank You
  • -Given: 13
  • -Receive: 2
  • Posts: 181
    • View Profile
    • Liberty Software Foundation
Re: ES/2 development
« Reply #12 on: November 06, 2017, 04:32:16 pm »
Quote
What driver is in your CONFIG.SYS?

pscom.sys, which as far as I know, is there to fix some SMP issues. My Warp v4 partition still has com.sys and dial up works the same there.
What version of OS/2 are you running? Here, on Warp v4, I'm using

[E:\OS2\BOOT]bldlevel com.sys
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#IBM:10.036#@ COM Port Driver-SMP
Vendor:          IBM
Revision:        10.36
File Version:    10.36
Description:     COM Port Driver-SMP


My ArcaOS release.  I've gone in to the package manager and run updates, but I haven't installed anything manually except adding the COM.SYS line to my CONFIG.SYS last night when I realized it didn't automatically recognize my machine's two COM ports during install.

I'll look tonight when I'm back at that machine.
« Last Edit: November 06, 2017, 04:48:39 pm by Rick C. Hodgin »

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 7
  • -Receive: 88
  • Posts: 1146
    • View Profile
Re: ES/2 development
« Reply #13 on: November 06, 2017, 05:25:05 pm »
Use pscom.sys on ArcaOS

Rick C. Hodgin

  • Full Member
  • ***
  • Thank You
  • -Given: 13
  • -Receive: 2
  • Posts: 181
    • View Profile
    • Liberty Software Foundation
Re: ES/2 development
« Reply #14 on: November 06, 2017, 05:49:29 pm »
Use pscom.sys on ArcaOS

Will do.  Thank you.