DOS ain't dead

I've been using PharLap tools for a long time - 1988 or so.

I still use a lot of real-mode DOS for embedded processors, PC-104 stacks and the Vortex 86DX. With some older tools, the Phoenix Linker as it has an easy-to-use overlay manager. Recently, converted a lot of my code to 32-bit protected using PharLap 7.0 and 8.0; seems to be the most direct port of real-mode DOS. I have a lot of assembly language routines for the Phar Lap extenders, giving access to the interrupt vector table and memory mapping. I got used to their memory model.

Do any of the newer DOS extender tools emulate the Phar Lap memory model, ie similar use of the Segment Registers and virtual memory drivers? I've also used VMMDRV since it came out. 3-D stop-frame animation using a Compaq 386/25, Cyrix EMP-87 math coprocessor, and an analog video-laser disk, 25 years ago.

I've downloaded the HX extender- works great for my Windows Console programs. I have some learning to do about it.

> easy-to-use overlay manager. Recently, converted a lot of my code to 32-bit
> protected using PharLap 7.0 and 8.0;

Are these the versions that support the PE format ( TNT? ) or is this still REX?

> Do any of the newer DOS extender tools emulate the Phar Lap memory model,
> ie similar use of the Segment Registers and virtual memory drivers?

Open Watcom still supports the Pharlap dos extender, AFAIK - it's called "Easy OMF".

> Anyone else still using Phar Lap tools?

I don't - but at least I have learned now that the correct name is Phar Lap, not Phar Lab ( as I had written in a few readmes some years ago ).

---
MS-DOS forever!

> I don't - but at least I have learned now that the correct name is Phar
> Lap, not Phar Lab ( as I had written in a few readmes some years ago ).

Hehe, yes the Phar Lap was a name of extraordinary race horse (he had bigger heart and power than other horses) that they used to name the software comapany...

>Brian_extended
With what compiler do you use this tools? I never used this. I think it worked with watcom and HighC.

---
DOS gives me freedom to unlimited HW access.

>
> Are these the versions that support the PE format ( TNT? ) or is this still
> REX?
>
> > Do any of the newer DOS extender tools emulate the Phar Lap memory
> model,
> > ie similar use of the Segment Registers and virtual memory drivers?
>
> Open Watcom still supports the Pharlap dos extender, AFAIK - it's called
> "Easy OMF".

These versions support PE; I've used the older format "for a very long time", and have cracked the manuals open to read up on PE. Phar Lap "EXP" is what I've been using. "ELF", "COFF", been 15+ years since I needed to look these up!

(Added) I found the relevant sections in the Linker manual, and will look at the configuration files for PE format. One is NOT included for the Microway compilers, maybe I can hack one in. I tend to use -priv to run at level 0, install interrupt handlers, disable interrupts for critical timing, and take over the CTC of the CPU for timing. These limit the builds to "DOS Style" as per the linker docs. All the reasons to stick with DOS right? "or did they improve windows in the 21st century to do these things"... (HUMOR)

I will be experimenting with what can/cannot be done to run my code in the various formats. Still experimenting. Yesterday, got the "exec" function working- converted a 16-bit assembly routine written in 1986 to protected mode. The compiler has a library call, but "did not quite work". Register dump and locked keyboard. Mine worked on the first try.

>
> Hehe, yes the Phar Lap
> was a name of extraordinary race horse (he had bigger heart and power than
> other horses) that they used to name the software comapany...
>
> >Brian_extended
> With what compiler do you use this tools? I never used this. I think it
> worked with watcom and HighC.

I am using the Microway NDP compilers, Version 4.4 for Fortran and 4.6 for C/C++ (although I stick with C). I also do a lot in assembly. I was able to get 50,000 lines of Fortran and assembly converted from RM Fortran 2.43 and MASM to Microway and Phar Lap in a week. I wrote the interrupt installer for both a long time ago. I suspect the Microway compiler incorporated most of the RM and VAX extensions to aid in porting. That covered me.

The Watcom compiler- need to revisit. I bought it "in the day", but it did not include the Fortran extensions and porting would have been a major issue. The Microway compilers, use something for 25 years and you get used to the internals. I used the GNU C/C++ "a long time ago" for the i960 and MIPS R3000/R4000 CPU's.

> With what compiler do you use this tools? I never used this. I think it
> worked with watcom and HighC.

The compiler comes with two libraries, one for ".ltl" (Obscure?) and ".exp". Ihave some more experimenting. For my work, I can stick to the Phar Lap tools- basically dedicated code for my own hardware. "It just works"... I wrote my own font generator in protected mode assembly -a long time ago- as the ROM based fonts of the VGA were slowing down the animation on the screen. That was fun.

> "or did they improve windows in the 21st century to do these
> things"... (HUMOR)

Actually, "these things" can be done in windows. In Windows 9x/ME in any case, in Windows NT/XP/Vista/7 ( /8? ) only if you have administrator rights. But I guess it's fairly questionable whether it is a good idea to use such hacks / options in a multi-tasking OS.

---
MS-DOS forever!

> > "or did they improve windows in the 21st century to do these
> > things"... (HUMOR)
>
> Actually, "these things" can be done in windows. In Windows 9x/ME in any
> case, in Windows NT/XP/Vista/7 ( /8? ) only if you have administrator
> rights. But I guess it's fairly questionable whether it is a good idea to
> use such hacks / options in a multi-tasking OS.

My experience with doing a test under Windows several years ago, the timing was not as accurate. As it is now, running under DOS- the output of the hardware being driven under extended DOS is "O-Scope" solid. I've implemented a number of feed-back loops where the timing is critical.

ADDED- In 486/100 days, I used a hardware counter-timer-circuit, I think was 48 bits or so, for timing. After moving to the Pentium, the 64-bit timer was available and I made use of it in place of the CTC peripheral. "Resetting" the CTC was part of my timing software. I think resetting the 64-bit timer/counter makes windows kill the process "executed illegal instruction" type messages. The instructions works under DOS and Phar Lap. Like I stated before, I am still experimenting. What I have works well, I can time sub-microsecond- basically limited by the bus speed. I've disabled interrupts for hours at a time while the control loops are running. This is a Lab environment.

WIN98se halted the code on the write to TSC register- did not like that one. My software clears it out when timing certain events. I could probably alter the code to compute a base value; I am doing 64-bit arithmetic on it now. I am just used to starting with a base of '0'.

> WIN98se halted the code on the write to TSC register- did not like that
> one.

Yes, RDMSR/WRMSR won't run in ring 3 - you have to switch to ring 0.

Strangely, on my Pentium 200 board, even RDTSC causes a fault in Win98SE, although SoftICE tells that bit TSD ( time stamp disable ) in CR4 is clear!?

---
MS-DOS forever!

> > WIN98se halted the code on the write to TSC register- did not like that
> > one.
>
> Yes, RDMSR/WRMSR won't run in ring 3 - you have to switch to ring 0.
>
> Strangely, on my Pentium 200 board, even RDTSC causes a fault in Win98SE,
> although SoftICE tells that bit TSD ( time stamp disable ) in CR4 is
> clear!?

My program CPUID (with kernel driver for NT-based) can do WRMSR and I usually tested the functionality by writting 0 to TSC and windows never complained. Also under Win98 no problem.

---
DOS gives me freedom to unlimited HW access.

> I have works well, I
> can time sub-microsecond- basically limited by the bus speed. I've disabled
> interrupts for hours at a time while the control loops are running. This is
> a Lab environment.

Just a note - you cannot disable SMI handler that's executed on specific system events like controlling PM or emulating a peripheral - like USB legacy keyboard or USB flash drive. If you don't turn off this in BIOS you may expect lags of many tens us or more. But even if you disabled this, there will still rise some shorter SMI routines. Probably older computers are better for this because of minimum SMM code and well optimized assembly. Now most of UEFI BIOS is written i C, I'm not sure if SMI handler is optimized in ASM but I doubt.

---
DOS gives me freedom to unlimited HW access.

> > WIN98se halted the code on the write to TSC register- did not like that
> > one.
>
> Yes, RDMSR/WRMSR won't run in ring 3 - you have to switch to ring 0.
>
> Strangely, on my Pentium 200 board, even RDTSC causes a fault in Win98SE,
> although SoftICE tells that bit TSD ( time stamp disable ) in CR4 is
> clear!?

Phar Lap lets me use the "-priv" for ring 0.

On the PE format, the Microway Startup code is an issue. So at least for my current code, running EXP format, -priv, and preventing Phar Lap from allocating all of real-mode memory is working for me.

I will be experimenting with PE mode for Visual C/C++, and DOS32HX. Since it is DOS, each code can use it's own extender. Phar Lap 386link includes a build file for VC.

I've had to go into the BIOS of the machines that I run on to disable quite a few things, including the IR port and such. The transition from real-mode to Phar Lap DOS was much easier than I thought. The critical timing portions of the code all work; and the timing is even more precise.

I'm reminded of the movie 2010 where HAL is rebooted after being shutdown for 10 years. I have a lot of code in there that has not been used since well before 2001. Found one note that I left myself in 1988 warning me to change a line of assembly after the year 2000. I did, it worked...