|
|
Post by fischle on Feb 19, 2019 9:17:17 GMT 1
Hi, it´s my first time working with vDos. I want to start an old program of our company. The program starts, but it is not shown. I can see the cursor blinking and the clock of the application is shown between the lines of the vDos start screen. In the attachments you can see how it should look like and how it looks like right now. What I figured out is, when I start the DataPerfect demo program DBTEST, close it and start then my application, then it works fine. So it might be an option I have to set. I tried several but nothing helped. Does anyone have an idea?   |
|
|
|
Post by Jos on Feb 19, 2019 9:48:44 GMT 1
I suppose you start the program by autoexec.txt. Test what happens when you add PAUSE between the lines cd euro and auf.
The clock (separate routine) is displayed, while your (main) program writes to an incorrect video page?
If so, no way to tell how/why your program establishes that video page w/o having access to the program.
Jos
|
|
|
|
Post by fischle on Feb 19, 2019 10:26:16 GMT 1
I only map the network path with the autoexec. The rest I type right now.
What I´m really wondering is that it works after I started and exit DBTEST.
|
|
|
|
Post by Jos on Feb 19, 2019 10:53:20 GMT 1
Typing the rest at least excludes the vDos video system not being initialized.
DataPerfect (DP26YI.EXE) will modify something in the vDos system that causes your program to display properly.
Major suspect is still an incorrect video page, or even video memory segment (MDA/Hercules). But again, no way to tell w/o something to duplicate this behavior.
Jos
|
|
|
|
Post by fischle on Feb 19, 2019 12:00:46 GMT 1
I am not in the office today. I see if I can upload it tomorrow.
|
|
|
|
Post by fischle on Feb 21, 2019 15:32:51 GMT 1
Here I attach a demo of the application for testing. Auf.exe starts the program. Attachment Deleted |
|
|
|
Post by Jos on Feb 21, 2019 16:10:03 GMT 1
I can replicate the behavior, so I’ll have a look and come back to you.
Jos
|
|
|
|
Post by fischle on Feb 21, 2019 16:50:59 GMT 1
Thanks alot!!!
|
|
|
|
Post by Jos on Feb 24, 2019 21:14:55 GMT 1
No real idea what’s causing this. AUF.EXE at some moment fetches a byte in a table, AND’s that with a value popped off its stack, causing AUF to establish the video memory segment is B000 (Hercules/MDA) instead of B800 (VGA). Writing to segment B000 won’t be displayed since vDos is at that moment in VGA mode. Complicating factor is AUF at that moment running in protected mode, with its main code and data in XMS. The table is built, modified and copied back and forth to other locations by several routines, the first 20 million instructions of AUF running. I lost track of what’s going on at all those stages in between. I gave up, and resorted to an ugly fix: The attached tiny RAUF.COM will set one specific byte in DOS conventional memory to FF (255). Far from a satisfying solution, but it will at least force AUF to ‘recognize’ VGA mode when you run RAUF before starting AUF. The DataPerfect Demo (DP26YI) doing the same is mere coincidence. Some DOS programs (mostly by just being loaded) will also cause that byte set to an effective value. Jos Attachments:RAUF.COM (17 B)
|
|
|
|
Post by fischle on Feb 25, 2019 15:09:16 GMT 1
That was an idea I had on the weekend too, just starting an app that does the required changes. So far your RAUF helps me to start further testing. Maybe we can also change the code of the program later to start in VGA mode.
I realy thank you for your help!!!
|
|
|
|
Post by Jos on Feb 25, 2019 22:59:16 GMT 1
Don’t think changing the code will bring you anything, this unique mishap is beyond what you can do with that.
Executing RAUF before AUF will be the only practical solution. It’s just a 17 byte program and so unnoticed by users.
Jos
|
|
