jmarsh wrote on 2020-01-18, 01:45:
It's a standard AT bios function.
Keep in mind the bios isn't magic, it just contains a bunch of x86 subroutines. The function doesn't do anything that your program couldn't implement directly, and will trigger the same exceptions if the CPU is already running protected.
I'm trying to create a program, which uses 32bit instructions for processing information 32bits at a time. I could use 32bit instructions in 16bit real mode, but that is slow because of the 0x66 prefix before every 32bit instruction. My processing will be done in loops to process all the data, and any delay caused by the 0x66 prefix will be multiplied by the number of times the loop runs (which will be a lot). Also, switching to 32bit mode will give me full access to system memory (I think I have 4 gigs of ram in my PC) instead of just 1MB as in 16bit real mode, and with the amount of data I'm going to process I will need far more than 1MB. Why not just write a Windows program? Inaccuracy (jitter) of the Windows timer. A "15ms delay" one time around may be 14ms during one iteration, but 16ms the next. A workaround is using low level access in ring0 mode to directly communicate with PC's hardware timer, but Windows blocks applications from using ring0 mode. Even if I could, because instructions execute when Windows wants to allow it (task scheduler kernel feature in Windows), one run through a loop may take 0.10us in the first iteration but 0.12us the next iteration. So I need to run my program separate from Windows. Yes, DOSBox is running in Windows, with all its restrictions, but I'm only using DOSBox to test the program, to see if it will run at all.
My plan is for my program to run in 32bit protected mode, ring0. The idea for the final use of my program will be I will have a USB disk with DOS installed, and a copy of my program. I will boot the USB drive, run my program, which will then switch to 32bit protected mode ring0, and load the data file from disk (or an external sensor connected to serial port or even USB port). It will then process the data and save it to another file. When I want the processing stopped, I have no intent to go through the complexities of writing a program that backs out of 32bit protected mode, so shutting off the program is quite simple. Just power off the computer. Then to go back to Windows, just unplug the USB drive and power the computer back on, and Windows will boot from the normal internal harddrive.
Since timing precision and accuracy (no jitter) for live high-speed signal processing is needed for my application, running a dedicated program which runs from DOS and switches itself into 32bit protected mode is absolutely necessary (unlike most 32bit programs, which run from an OS that has already switched into 32bit protected mode). Having the overhead of a multitasking OS (such as Windows, or even any version of Linux with a GUI) which does stuff like task scheduling, that messes up the timing of the program you are running, is absolutely not an option in my case.