Hi, On at 2025-05-15 22:32:55 +0200, "Bernd Böckmann via Freedos-devel" <freedos-devel@lists.sourceforge.net> wrote: >Thanks to everyone who responded to my question. > >I will adapt the INT2F.1680 (+ HLT) method, as some of you suggested. > >However, as this was already built into EDIT, one comment in the source caught >my attention: > >> #if 0 /* int 2f is often quite crowded */ >> r.x.ax = 0x1680; /* release multitasker timeslice */ >> int86(0x2f, &r, &r); /* multiplexer call */ >> #else > >Why was that section disabled? The comment mentions that "INT2F is often quite >crowded". Was EDIT becoming unresponsive in the past because of it?
That shouldn't be the case, as I mentioned the time spent running int 2Fh is dwarfed by how much CPU time can be saved by idling. However, the code you quoted is missing a check whether the returned AL register is zero. If it is (indicating the call is supported) and you do run a HLT afterwards regardless, then every call to the idle routine could idle for twice the time it should. This could worsen response times. FDAPM APMDOS can also idle too much, affecting responsiveness. If you find this is so, try other settings. In my experiments I believe I found that a single call to lDebug's function idle could take as long as three timer ticks. In the SLEEP command I added code to handle multiple tick changes during the time it takes one "call idle" to run [1]. The old handler just counted how often the tick changed at all, swallowing multi-tick changes as if only one tick increment had been observed. With FDAPM APMDOS running (on MS-DOS v7.10 kernel, physical 686 box) this would increase the actual sleep duration to an unacceptable degree. (Side note, at midnight after tick 18_00B0h or 18_00AFh [2] the tick dword resets to zero, so if you do read the tick beyond just "detect any change" then your code should handle this special case gracefully.) Regards, ecm [1]: https://hg.pushbx.org/ecm/ldebug/file/97b4a91322eb/source/ss.asm#l94 [2]: https://retrocomputing.stackexchange.com/questions/25877/why-did-some-bioses-have-the-timer-tick-wrap-around-at-1800b1h-instead-of-at-180 _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
