DOS ain't dead - Using Dos for Real Time applications

Damien

23.12.2012, 18:41

Using Dos for Real Time applications (Developers)

Hello everybody,

One of the reasons why I am using Dos is that I can make real-time programs. Indeed as it is a single task operating system, my program is not disturbed by some other processus that would take cpu time at any moment.
I just need to be aware of how much time do my elementary tasks take, and from this I can garantee the real-time aspect.

I wanted to check this or more precisely, to understand to what extent this is true.

So I made a small program that does very small loop, and which measures the time of each loop. Here is what I discovered.

Let's say my elemetary loop is about 20microseconds. And I loop for 1 minute.
Most of the loop are 19-20-21us long, which is fine.
Some others are between 20 and 30, which means that the computer does not exactly compute only my program, but makes some very tiny task. I consider this is not a problem, because it's about 10microsecs.
And finally I get a few loops that takes between 400 and 450 microsecs. In this test, it is precisely 60 loops because I noticed that it is one time per second.

So to sum up, when I run my program, every second there is "something" that takes about 400 usec to my CPU.

Do you have any idea of what is the reason of this? Maybe it is due to some interrupt depending of the computer clock, or anything else ...
Is this avoidable ? Is there a way I can see what is the origin of this "specific task" ?

Thanks for your advices.

Damien.

DOS386

24.12.2012, 09:39

@ Damien

Using Dos for Real Time applications -> CLI

Post reply

> So to sum up, when I run my program, every second there is "something" that
> takes about 400 usec to my CPU.
> Do you have any idea of what is the reason of this? Maybe it is due to some
> interrupt depending of the computer clock, or anything else ...

Most likely it's the timer interrupt called every cca 18.2 ms (!!!) and eating more time than usual cca every 1 second.

> Is this avoidable ?

CLI

Flaws:

* clock will probably not run during the CLI'fied times

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

RayeR

CZ,
24.12.2012, 15:13

@ DOS386

Using Dos for Real Time applications -> CLI

Post reply

> Most likely it's the timer interrupt called every cca 18.2 ms (!!!) and
> eating more time than usual cca every 1 second.
>
> > Is this avoidable ?
>
> > CLI >

Yes the most of time can take BIOS/DOS interrupts. But even if you CLI, there will occur some SMM interrupts that are handled by SMI handler and cannot be disabled (this is transparrent and running behind all OS). BIOS writers should make this routines as fast as possible but it still may take some us or maybe tens of us? It also depends on hardware config and BIOS. If you need some microsecond precision timing I rather suggest to connect some external microcontroller to do this job.

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

Damien

26.12.2012, 12:50

@ RayeR

Using Dos for Real Time applications -> CLI

Post reply

> > Most likely it's the timer interrupt called every cca 18.2 ms (!!!) and
> > eating more time than usual cca every 1 second.
> >
> > > Is this avoidable ?
> >
> > > > CLI > >
>
> Yes the most of time can take BIOS/DOS interrupts. But even if you CLI,
> there will occur some SMM interrupts that are handled by SMI handler and
> cannot be disabled (this is transparrent and running behind all OS). BIOS
> writers should make this routines as fast as possible but it still may take
> some us or maybe tens of us? It also depends on hardware config and BIOS.
> If you need some microsecond precision timing I rather suggest to connect
> some external microcontroller to do this job.

Thank you for your answers, DOS386 and RayeR.
I don't know much about CLI but I will look for "how to use it". Thus if you have an interesting link, please tell me.

I also use some microcontrollers, and I do some communications between this DOS PC and Arduino-like cards. For some basic tasks these microcontroller are nice, but when I do more complex programming I prefer to use the real computer, which has much more calculation power and on which it is easier to debug.
So on the PC I don't really care about 10us but then when more than 100us break happen it can be a little bit disturbing. I use "quite powerfull" computer, I mean for DOS, for example Pentium 4 or Athlon.

By the way RayeR, thank you again, as I used your tool "MTRRLFBE" which works well on my Nvidia cards :)

Damien

27.12.2012, 23:23

@ RayeR

Using Dos for Real Time applications -> CLI

Post reply

> > Most likely it's the timer interrupt called every cca 18.2 ms (!!!) and
> > eating more time than usual cca every 1 second.
> >
> > > Is this avoidable ?
> >
> > > > CLI > >
>
> Yes the most of time can take BIOS/DOS interrupts. But even if you CLI,
> there will occur some SMM interrupts that are handled by SMI handler and
> cannot be disabled (this is transparrent and running behind all OS). BIOS
> writers should make this routines as fast as possible but it still may take
> some us or maybe tens of us? It also depends on hardware config and BIOS.
> If you need some microsecond precision timing I rather suggest to connect
> some external microcontroller to do this job.

Hello,

Concerning CLI I don't really know how to do it, I guess it's inline assembler in my C-code ? Also my problem is that I don't want to inhibit all interrupts at the same time but one by one, to see which one is the origin of this "long" 400us task...

Moreover, I have tested my little "loop program" on another computer, older. And the surprise is that this 400usec task does not happen. There is indeed some fluctuation, but all the loops take less that 50usec.
To sum up, this phenomenon depends on hardware used, or maybe bios options...

RayeR

CZ,
28.12.2012, 01:32

@ Damien

Using Dos for Real Time applications -> CLI

Post reply

> Moreover, I have tested my little "loop program" on another computer,
> older. And the surprise is that this 400usec task does not happen. There is
> indeed some fluctuation, but all the loops take less that 50usec.
> To sum up, this phenomenon depends on hardware used, or maybe bios
> options...

Hehe, this is because old bios writers was the masters of assembler and did theirs work well. Now nobody cares and the most important think is profit and short time to market so why to bother with some optimizations, customer fuck you...
You can modify interrupt vector table such way you hook an interrupt vector to your dummy routine containing only IRET - this is fast as possible. You can walk vector by vector and check when the 400us delay disapper. First try timer interrupt.

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

Damien

02.01.2013, 13:20

@ RayeR

Using Dos for Real Time applications -> CLI

Post reply

>
> Hehe, this is because old bios writers was the masters of assembler and did
> theirs work well. Now nobody cares and the most important think is profit
> and short time to market so why to bother with some optimizations, customer
> fuck you...
> You can modify interrupt vector table such way you hook an interrupt vector
> to your dummy routine containing only IRET - this is fast as possible. You
> can walk vector by vector and check when the 400us delay disapper. First
> try timer interrupt.

Hello,

I have made some tests on several computers and it seems that I get as many behaviours as the number of PC I test.

In my test program I just added asm("CLI") at the beginning and asm("STI") at the end (programming in C with djgpp), to see the influence of masquable interrupts.
(It may be brutal, I don't know much about this).

Here is what I get:

On config A (AMD 2800+):
without CLI, I observe some 400us task, once a second.
with CLI : program ends early(strange), some smaller tasks disapper, but still 400us task
=> so this strange 400us task is not a masquable interrupt?

On config B (Intel Celeron800)
without CLI, I observe some 40us task
with CLI : all the loops last the same time, 8usec
=> on this config there is no strange task, all the 30-40us tasks were due to some masquable interrupts

On config C (Inter P4 3.2Ghz)
without CLI, I observe some 270us task.
with CLI :some smaller tasks disapper, but still 270us task
=> so this strange 270us task is not due to masquable interrupt...

So, in your opinion, if I can't avoid these tasks (270 or 400us) with CLI, what can it be ? Do you have any other ideas of how to change it?

THanks

Laaca

Czech republic,
02.01.2013, 21:02

@ Damien

Using Dos for Real Time applications -> CLI

Post reply

I am not sure if it can help however you could try to disable all USB related things in the BIOS.
Even if you don't have any USB drivers loaded, it still can do something in the background...

---
DOS-u-akbar!

RayeR

CZ,
02.01.2013, 23:22

@ Laaca

Using Dos for Real Time applications -> CLI

Post reply

> I am not sure if it can help however you could try to disable all USB
> related things in the BIOS.
> Even if you don't have any USB drivers loaded, it still can do something in
> the background...

Yes, USB Legacy emulation is done in SMI mode and cannot be masked only disabled in SETUP. But I think it's not this case. USB needs much more fast handling than 1 per second or so. Newer computers are also more affected due to CPU and PM complexity - more SMI and ACPI stuff than in ancient age of PII/PIII.
Maybe disable ACPI could help too, just try...

BTW I remember I had same observation when playing MP3s with my covox LPT player. This is configured to play via timer interrupt that occurs at sample rate. On some PC you can hear little cliks during playback, maybe at rate 1 per sec I don't remember. It's probably the same issue that you have. I wanted to play with different timer ISR chaining but didn't find time yet...

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

Damien

05.01.2013, 14:10

@ Laaca

Using Dos for Real Time applications -> CLI

Post reply

> I am not sure if it can help however you could try to disable all USB
> related things in the BIOS.
> Even if you don't have any USB drivers loaded, it still can do something in
> the background...

Yes you were right... I disabled all USB stuff in setup bios, and the "long tasks" disappeared in my test program! No more 270 or 400 usec task.
I thought USB was also handled by interruptions, but as RayeR says it's different way.

So now I just have "small" tasks left, which happen about 18 times per seconds, so it must be linked to the clock. It goes from 15 to 40 usec, depending on computer, which is quite a difference.

In your opinion, is it a matter if I inhibit this time interrupt ? I mean permanently, as long as my program is running...

RayeR

CZ,
06.01.2013, 21:43

@ Damien

Using Dos for Real Time applications -> CLI

Post reply

> Yes you were right... I disabled all USB stuff in setup bios, and the "long
> tasks" disappeared in my test program! No more 270 or 400 usec task.
> I thought USB was also handled by interruptions, but as RayeR says it's
> different way.

Holy crap... BTW I have some other compat. issues with USB legacy emu so I still use and prefer PS/2 KB and mouse (using PS/2 - USB adapter) so I have disabled it for most of time...

> In your opinion, is it a matter if I inhibit this time interrupt ? I mean
> permanently, as long as my program is running...

I think you can (some programms reprogram it speed for own purposes so disabling should be ok), if I remember there may be some issues with flopy drive and of course after you finis you should restore system time from CMOS RTC to keep it in sync.

BTW on what project are you doing? What HW do you RT control?

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

Damien

09.01.2013, 13:12

@ RayeR

Using Dos for Real Time applications -> CLI

Post reply

> I think you can (some programms reprogram it speed for own purposes so
> disabling should be ok), if I remember there may be some issues with flopy
> drive and of course after you finis you should restore system time from
> CMOS RTC to keep it in sync.
>
> BTW on what project are you doing? What HW do you RT control?

I tried to do some changes in the interrupt table (in real mode C programming), it seems to work. At the end of the program I restore the original vector.

But then I have one more question : is it possible not to restore the original vector of an interrupt, without crashing the computer ?

What I understand is that while I am in my program, the new handler I created exists at some memory location. but when the program ends, the adress in the interrupt table still points to the same memory location, but this one is freed and then completed randomly by another program.
So, when the interrupt happens, the computer tries to execute this random code, and crash. That's exactly what I observed.

Am I right?

As you guess I am really a newbie is this interruption gymnastic, but how can I "lock" the memory location of my interrupt handler, so that no one will write on it after my program ends??

About the project I am working on... to sum up I interface with electrical units such as, for example, engine control unit. But also, I am interested in undestanding how does a computer works. That's why I investigate this kind of stuff:)

RayeR

CZ,
09.01.2013, 13:52
(edited by RayeR, 09.01.2013, 14:04)

@ Damien

Using Dos for Real Time applications -> CLI

Post reply

> But then I have one more question : is it possible not to restore the
> original vector of an interrupt, without crashing the computer ?

I'm also not an interrupt expert to advice you, here are much experienced users about that. But I think that termination process of your program should be done following:
If there was interrupt enabled before your program with existing ISR, then simply do CLI, restore original vector, STI. I don't see problem why it should crash.
And if interrupt was not enabled and no existed ISR before, then simply reconfigure hardware to disable interrupt and you may leave your vector as is because interrupt will be disabled so nobody want to call this vector.
> So, when the interrupt happens, the computer tries to execute this
> random code, and crash. That's exactly what I observed.
This is probably your case.

This depends on what interrupt are you hooking. AFAIK e.g. serial ports or LPT/ECP has disabled INT generation and there's not installed any ISR by DOS. So it's up to you. But also there may be loaded some TSR which enabled interrupt, so you need to check and save state at the beginning of your program. In case of timer the interrupt is enabled after boot and BIOS and DOS ISRs are chained so you may chain yours ISR or disable/break chain and then restore it. Depends on what do you want.

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

Arjay

09.01.2013, 23:40

@ RayeR

Using Dos for Real Time applications -> CLI

Post reply

> > But then I have one more question : is it possible not to restore the
> > original vector of an interrupt, without crashing the computer ?
Yes.

For an initial starting point you might want to look at the documentation for
IVTUTIL which covers the basics of using Flopper to capture the initial interrupt vector table with this kind of low level tinkering in mind.

If you are just using DOS as an initial loading mechanism then you can save DOS's current interrupt vector table, go as far even as "stopping" DOS, fully or part restore a previously saved initial interrupt table, do various things then restore DOS's interrupt vector table. See flopper as a public example.

About 1-2 years ago I wrote a DOS swap loader (a kind of basic SYSLINUX if you like) which allows me to replace the current DOS with something else... I added a DOS memory viewer (like ramspy) and then created a test version for fun to see just how far I could go zeroing the interrupt vector table and also other things like the BDA (BIOS Data Area). Unsurprisingly after nuking DOS and pretty much everything else including the highlevel code of the main program with the exception of the ramviewer, the environment that I ended up with was similar to the very basic vm86 using Fabrice Bellard's runcom.

I did various tests and obviously my ramviewer allowed me to the results of these tests, e.g. I tinkered with having different interrupts on or off, e.g. I was able to watch the keyboard buffer overflow and overflow after I took out a little bit too much of the BDA area but not interrupt 16h. I'm not saying that I think you should go down this route which was more extreme than most people need to go but just be aware that there is a lot that isn't needed and once an application is up and running there is a lot that you can knock out quite happily. There was a serious side to my testing as I'm interested in old DOS embedded systems so I was curious to gain an insight into what was involved in replacing DOS in situ and how to maximise limited memory. i.e. I was also looking at could I pack extra code into areas normally used for other things in the legacy DOS, BIOS world.

I'm now back near the machine with this test code on but it's currently unplugged and my life is currently very busy but from memory from my testing I believe that at the most extreme I found that on the standard generic fairly modern clone I was testing with that I was able to zero out most of the interrupt table and run only running a basic handler (iret) on Int 00h, 01h, 03h and still keep my program running in various states happily after DOS, most BIOS services were no more. By various states I mean as above I was also experminenting with killing parts of that code as well but also in terms of safe methods for doing that, since it was highlevel code with some low level routines as well. e.g. move out of main highlevel code to low level routine, move stack, kill original stack and highlevel code etc.

If you want to play with IVTUTIL then I'd suggest having a read of the BIOMenance thread which has some examples.

I would strongly advise NOT using the undocumented patching feature which will be removed as/when I get a chance to update IVTUTIL (if/when/ever).