Hi Andreas, > INT 28 doesn't solve the problem of heavy load for me. > As I read it's just an IRET by default.
Well INT 28 is an interface for an extra layer of abstraction: Int 28, int 2a, ah=84, or some other API only have effect when a suitable driver or TSR such as POWER or FDAPM are active. So you GET extra features, but also NEED extra software. While raw calls to HLT are less versatile, they are self-contained. > Is there a good way of doing a really short hardware-based delay? (BIOS?) You can either ask the BIOS or use a loop of HLT or idle calls combined with calls to any source of wall time. The most simple example would be a loop of HLT, then compare 40:6c to desired value, repeat. The BIOS might do exactly that for longer delay requests (int 15, ah=86, wait for X microseconds, if X is big) but if you want to wait for less than 1/18 second, you would use very different methods. For example the RTC IRQ mechanism, which offers 1/1024 second steps, or reprogramming the timer to produce more frequent IRQ. In the latter case, you need to take care to call the old int 8 handler at the original speed. > Or better another way to wait for any hardware interrupt? If you really want to wait for the next IRQ, then HLT does make sense, but only on hardware level. If you want your program to be cooperative, you should call some idle API. For example in Windows, int 2f, ax=1680 is "release current VM time slice" which means "give Windows the chance to let other things use the CPU until the next time slot". Because time slice slots are short, it is better to give them away when you are idle: You will get fresh CPU time soon. If you do not release time slices, Windows will eventually have to take the CPU away from you to give others the time, without knowing whether the moment is convenient for you. Note that FDAPM etc. also support int 2f next to int 28 and others. Windows will probably block your attempts to HLT, too, which is yet another reason to use idle API instead. In DOS, EMM386 will usually trap HLT attempts, but then invoke a HLT itself for you, because that seems safe in a single tasking DOS. Style of DOS friendly emulators is similar: Trap attempted HLT, but then do some other waiting for you - most likely give away the current host operating system time slice and pause emulation until the host OS returns with fresh time. Dosbox, Dosemu, Windows and even Emm386 all use virtual CPU state. However, Emm386 and certain Dosemu and Windows setups only trap and simulate low level access (e.g. graphics card) while the rest simulates the whole PC and the whole CPU :-) Regards, Eric ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
