exec/chain/run performance loss

[j'ordos]

Hi, I'm having some problems with the exec command in DOS: the program that is launched from within my own program runs too slow. Since it's DOS I assume no CPU cycles are wasted on my own program while the new program is running so probably it's a lack of RAM or VRAM? I tried freeing all loaded images using imagedestroy before the exec command but it didn't help. That machine has 64MB of RAM and I doubt my program and the other combined need that much but I'll try adding some RAM to see if it helps. Any other ideas on what may be causing this or how to remedy it? I also tried changing the exec command to 'run' but it didn't help. Doesn't the run command exit the original program before running the new one? I created a small test program that inits a screen and then execs the other program and that works fine.

[MichaelW]

What DPMI host are you using, and does it have any options that can reduce its memory footprint? For example CWSDPMI has an option that disables virtual memory, that may reduce its memory footprint significantly (not tested).

[j'ordos]

Actually I don't know, I had HDPMI32.EXE in the program folder but after removing it and rebooting the PC the program still runs the same? I thought I should get a no DPMI error. I'm running Freedos 1.1.

edit: I upped RAM to 256MB but it made no difference.

[Laaca]

It could be problem related to disk cache in protected mode.

Most disk caching programs can have problems when are in protected mode (which is used by FBC).
Before running FBC program you could load alternate DPMI server HDPMI32. Just enter on command line: "HDPMI32 -r". Then run your program. It could help but not always.

Also try to use different cache. I don't know what are you using but try to use last UIDE by Jack R. Ellis (johnson.tmfc.net/dos/driver.html)
Try to experiment a little bit with switches setting.

[codeFoil]

Is the program you are executing from your program a real mode or protected mode program? Does it rely on real mode BIOS or DOS services?

[j'ordos]

I ran hdpmi32.exe -r before running my own program and it's still too slow, it did *seem* as though it was a bit more responsive though. The disk caching utility that came with freedos 1.1 is UIDE though I don't know which version, I'll try replacing it.

The program I'm running is Vantage, a protected mode program. I don't know if it relies on real mode services (I guess not since it's a protected mode program? http://pc2jamma.mameworld.info/downemu.html. Btw the program on exiting always shows the average FPS it achieved and they've always shown 60+ FPS even though the game ran extremely choppy. I'll try exec'ing a few different programs to see if there's any difference, and I have another DOS PC I can test it on, see if it happens there as well.

[j'ordos]

As an update, I found it even happens in DOSbox. Does that rule out DPMI/disk cache problems as the cause of my problem?

[MichaelW]

I seen to recall that fbgfx reprograms system timer 0, and this could be the source of the problem. As a test you could try launching the program from a FB console app.

[counting_pine]

I seen to recall that fbgfx reprograms system timer 0, and this could be the source of the problem.

Hmm, could something like that be the cause of http://www.freebasic.net/forum/viewtopi ... 18&t=20371?

[MichaelW]

Looking at the 0.23.0 source at libfb_gfx_dos.c, system timer 0 is reprogrammed for 1000 ticks per second, instead of the normal 18.2. AFAICT, in the short time I had to investigate, the new handler calls the original handler at the normal rate, so the DOS time and such will run normally. If the launched program is also reprogramming the timer, to a rate lower than 1000 ticks per second, then from fbgfx’s POV the timer is running slow.

And I think a rate lower than 1000 is very possible, given that (IIRC) QB increased the rate to something like four times normal to improve sound quality.

Hmm, could something like that be the cause of http://www.freebasic.net/forum/viewtopi ... 18&t=20371?

In the 0.23.0 source, libfb_io_serial.c in rtlib\dos, the comm_isr code does not access the timer, so if there were a link I think it would have to be indirect.

[j'ordos]

Sorry about the delay. You're right MichaelW, running the external program without calling screen or screenres works fine. But if I init a screen first the external program runs choppy.