DOS gfxlib improvements (proper locking semantics)
DOS gfxlib improvements (proper locking semantics)
As you might have noticed, a few days ago I modified the DOS gfxlib to respect the lock state of the screen (i.e. that set by SCREENLOCK/SCREENUNLOCK and by the graphics primitives internally), so now all graphics programs (and especially those using SCREENLOCK) should work more correctly under DOS (no flicker or halfway-drawn frames).
This works by running the PIT at 1000 Hz instead of at the refresh rate of the screen and only actually updating the screen when it is not locked.
This works well on my test machine (a Pentium II), but I'd like to know if it works well on older/slower hardware (the overhead of 1000 interrupts/sec shouldn't be too overwhelming, but if it is, I'd like to know about it). Any program with changing graphics involved should work fine for testing (but especially those with SCREENLOCK), and it should be obvious when comparing with a version using the older graphics library, so any reports would be helpful (positive or otherwise :). An example program is at http://drv.nu/temp/stars.zip - this is examples/math/stars.bas from the FB extended lib - but please try any programs you can come up with that work correctly on other platforms but haven't on DOS due to the former SCREENLOCK semantics (ignoring the lock).
This works by running the PIT at 1000 Hz instead of at the refresh rate of the screen and only actually updating the screen when it is not locked.
This works well on my test machine (a Pentium II), but I'd like to know if it works well on older/slower hardware (the overhead of 1000 interrupts/sec shouldn't be too overwhelming, but if it is, I'd like to know about it). Any program with changing graphics involved should work fine for testing (but especially those with SCREENLOCK), and it should be obvious when comparing with a version using the older graphics library, so any reports would be helpful (positive or otherwise :). An example program is at http://drv.nu/temp/stars.zip - this is examples/math/stars.bas from the FB extended lib - but please try any programs you can come up with that work correctly on other platforms but haven't on DOS due to the former SCREENLOCK semantics (ignoring the lock).
-
- Posts: 612
- Joined: Jun 15, 2005 13:22
- Location: Upstate NY
- Contact:
SO far it seems to work good on my P4 1.2 gHz laptop ...
I need to take the time here to really thank DrV (and anyone involved in the DOS port) for all the hard DOS work. I don't need to remind anyone how much I love DOS ;-).
I've been noticing big improvements on DOS's support of graphics, exhanced mode that work where other languages I use don't seem to or not quite adequately. the DOS port RULES. I can see here i'm not the only one that appreaciates all the hard work, and I'm glad to see that ;-).
Two thumbs up for the DOS team (to quote Adigun A. Polack) d=^^=b hehe
I need to take the time here to really thank DrV (and anyone involved in the DOS port) for all the hard DOS work. I don't need to remind anyone how much I love DOS ;-).
I've been noticing big improvements on DOS's support of graphics, exhanced mode that work where other languages I use don't seem to or not quite adequately. the DOS port RULES. I can see here i'm not the only one that appreaciates all the hard work, and I'm glad to see that ;-).
Two thumbs up for the DOS team (to quote Adigun A. Polack) d=^^=b hehe
The faster PIT could indeed be used as a high-res timer, but I'm not sure how that would work when, for example, SHELL is called, because at that point we should probably reset the PIT to its normal ~18.2 Hz speed (I actually need to check into what happens now...) because other programs will expect it to be that way, so the timer values will suddenly no longer increase at the same rate. It is an interesting idea, though, and worth considering if there are ways around this (perhaps switching over to a lower-resolution timer when the PIT needs to be reset and somehow synchronizing the two). Alternatively, I could use the CMOS timer mentioned here, but the article indicates that it's not necessarily usable on all machines, which is probably a cause for concern. In any case, if another external program is using this timer as well, it will cause the same problems as the PIT, since it has a programmable divider too.
-
- Posts: 836
- Joined: Jul 28, 2005 13:56
- Location: Brazil, Santa Catarina, Indaial (ouch!)
- Contact:
and i guess that changing the timer will not work under any windows, not sure if it will work under dosemu, or xp dos-emu, only in dosbox
anywayz, the timer calls certain functions every 18.2 second, so i guess that making it call that original function only 18.2 times second even with a 1000hz timer, will should work, for most shell programs, but changing it back to 18.2 times by second when you call the "shell" isnt a problem, since there are no multithread in dos
anywayz, the timer calls certain functions every 18.2 second, so i guess that making it call that original function only 18.2 times second even with a 1000hz timer, will should work, for most shell programs, but changing it back to 18.2 times by second when you call the "shell" isnt a problem, since there are no multithread in dos
In the old days you would install a hander for Interrupt 8 that would call the previous handler at something close to the normal rate, so the BIOS and DOS clocks, tick count, etc, as well as any application that depended on these values, would continue to function correctly. The timer could be reprogrammed and the handler installed when application was started, and the handler uninstalled and the timer restored to normal operation before the application terminated. IIRC this is what QB does when it speeds up the timer. This could be done as a TSR, or I think in this case as a Resident Service Provider, but it would not work correctly if an application later changed the rate, unless it went to the trouble to restore the rate to what it was when the application started, instead of to the default.
Please don't reprogram the PIT. It doesn't work under Windows XP, and it doesn't even work on plain MS-DOS with the MS Network Client loaded. The RTC (int 70h) already runs at 1024Hz and is much more compatible. Any 286 or newer computer should have no problem with the RTC interrupt.
More info here: http://www.phatcode.net/articles.php?id=211
More info here: http://www.phatcode.net/articles.php?id=211
That's the CMOS timer I was speaking of earlier - but in any case, the DOS gfxlib has been using (and reprogramming) the PIT since the beginning, though I agree it's not the best solution. I'll look into the RTC soon, but I remember having trouble with it in the past.
Oddly enough, this has worked for me on XP in the past, but I have recently been having troubles, so maybe this is related.
Thanks for the article link - that looks quite a bit more in depth than the PCGPE one.
Oddly enough, this has worked for me on XP in the past, but I have recently been having troubles, so maybe this is related.
Thanks for the article link - that looks quite a bit more in depth than the PCGPE one.
-
- Posts: 1759
- Joined: May 23, 2007 21:52
- Location: Cut Bank, MT
- Contact:
-
- Posts: 1759
- Joined: May 23, 2007 21:52
- Location: Cut Bank, MT
- Contact:
What exactly does not work? The application I posted here reprograms the PIT for ~1000.99 interrupts per second so it can be used for a ms-resolution timer, and installs a temporary interrupt 8 handler that calls the previous handler at very nearly the standard rate, and it appears to work just fine under Windows 2000/XP.Plasma wrote:Please don't reprogram the PIT. It doesn't work under Windows XP.
Edit:
And substituting this RTC-based timer the test works normally under Windows XP, but I cannot get it to work from a Windows 98 startup diskette.
Edit:
Problem fixed, for my test system, a Dell Dimension 4400 with an early P4, I needed to unmask IRQ 8.
Example code posted to link above.
Sorry DrV if this isn't fully on topic:
One possibility for higher-res timer:
1) Read 0x40:6c to get ticks since midnight
2) Latch PIT counter 0 to get fractions of a tick ( 0 - 65535 )
3) Read 0x40:6c again to check if tick changed
The max resolution of the timer will be ~1.193MHz, precision will be around 2X the amount of time to execute steps 1-3 above. So a faster computer should get better precision than a slower computer.
Doesn't require any ISR's or memory locking etc, but does assume that the PIT is programmed to count down from the max 65536 and INT 8 is getting called 18.2 times per second. (To correctly update the ticks since midnight)
As for the 1000Hz interrupts, not sure but I think *the* test would be running it on something old like a 386-25Mhz. I have one but it is burried under a stack of PC's at the moment. (quite possibly broken also :/)
This is a little off topic, but I think it has been suggested before that SCREEN[RES] could be called with a special flag such that no background updating occurs. The user would be responsible for explicitly doing the update. with FLIP or something like in OpenGL modes. Just an idea.
One possibility for higher-res timer:
1) Read 0x40:6c to get ticks since midnight
2) Latch PIT counter 0 to get fractions of a tick ( 0 - 65535 )
3) Read 0x40:6c again to check if tick changed
The max resolution of the timer will be ~1.193MHz, precision will be around 2X the amount of time to execute steps 1-3 above. So a faster computer should get better precision than a slower computer.
Doesn't require any ISR's or memory locking etc, but does assume that the PIT is programmed to count down from the max 65536 and INT 8 is getting called 18.2 times per second. (To correctly update the ticks since midnight)
As for the 1000Hz interrupts, not sure but I think *the* test would be running it on something old like a 386-25Mhz. I have one but it is burried under a stack of PC's at the moment. (quite possibly broken also :/)
This is a little off topic, but I think it has been suggested before that SCREEN[RES] could be called with a special flag such that no background updating occurs. The user would be responsible for explicitly doing the update. with FLIP or something like in OpenGL modes. Just an idea.
I have a working 486 Sx/25 and also a P166. However, I did test one version of STARS on the P166 that I got from DrV in IRC. I think it needed VESA 2.0 (so I had to use UNIVBE, which wouldn't install on the 486).coderJeff wrote: As for the 1000Hz interrupts, not sure but I think *the* test would be running it on something old like a 386-25Mhz. I have one but it is burried under a stack of PC's at the moment. (quite possibly broken also :/)
DrV, if you need me to test it again with a newer version, I will. But if you e-mail it to me, remember that Gmail is picky about binaries in attachments, so you'll have to 7-Zip (or Bzip2 or LHA) it first. :-/
PIT
> If you have code in place to run the PIT at 1000Hz, could this be
> used to improve the resolution of the TIMER function?
Definitely YES, one would have to reprogram the PIT in every FB program (or every program using TIMER at least), not only when FBGFX is used.
plasma wrote:
> Please don't reprogram the PIT.
Or reprogram both the PIT and the PENDULUM at least :-D
> It doesn't work under Windows XP
NOT a DOS problem ;-)
As next you could ask for complete FBGFXDOS removal (doesn't work at all in Vi$$$ta) or complete DOS target removal (doesn't work in XP/Vi$$$ta XXX-64) ...
PIT usage and reprogramming is perfectly valid in DOS, OTOH there are only 2 PIT's available thus they should be reprogrammed only if there is a real need to do so ... I would prefer a PC with 4 or 8 PIT's from one with 4 or 8 CPU's :-D
> More info here: www.ph****de.net/articles.php?id=211
Much better info here, nice PIT and timing manual : http://www.sat.dundee.ac.uk/~psc/pctim003.txt
> and it doesn't even work on plain MS-DOS with the MS Network Client loaded.
Hmm...
> The RTC (int 70h) already runs at 1024Hz and is much more compatible.
Maybe good idea, nevertheless
> > Nothing wrong with doing it on DOS - but don't try to run those DOS apps in an emulator!
> Why not? They should work fine.
1. Some emulators are crippled (good: BOCHS and QEMU)
2. Might not work in DOS then
Rugxulo wrote:
> I have a working 486 Sx/25
Please keep it working and available, badly needed for DOS development ;-)
> you e-mail it to me, remember that Gmail is picky about binaries in attachments
Ultraparanoid about virii ? Not only GMAIL's problem :-D
> so you'll have to 7-Zip (or Bzip2 or LHA
Please don't promote obsolete stuff ... ZIP or 7-ZIP encrypt it at best, or use http://www.yousendit.com/
DrV wrote:
> This works well on my test machine (a Pentium II),
> but I'd like to know if it works well on older/slower hardware
> but please try any programs you can come up with that work
> correctly on other platforms but haven't on DOS due to the
> former SCREENLOCK semantics (ignoring the lock).
Unfortunately I don't have anything below 500 MHz available by now ...
Tests:
Didn't notice any difference, seems to work as it used to ...
STARS.EXE works.
FBCAD works (but requires -lang deprecated)
HANOI still doesn't, problem is not screenlock but missmatching screenres:
http://www.freebasic.net/forum/viewtopic.php?t=8511
Anyone can point me to the "correct" lock-affected code to be tested ?
> used to improve the resolution of the TIMER function?
Definitely YES, one would have to reprogram the PIT in every FB program (or every program using TIMER at least), not only when FBGFX is used.
plasma wrote:
> Please don't reprogram the PIT.
Or reprogram both the PIT and the PENDULUM at least :-D
> It doesn't work under Windows XP
NOT a DOS problem ;-)
As next you could ask for complete FBGFXDOS removal (doesn't work at all in Vi$$$ta) or complete DOS target removal (doesn't work in XP/Vi$$$ta XXX-64) ...
PIT usage and reprogramming is perfectly valid in DOS, OTOH there are only 2 PIT's available thus they should be reprogrammed only if there is a real need to do so ... I would prefer a PC with 4 or 8 PIT's from one with 4 or 8 CPU's :-D
> More info here: www.ph****de.net/articles.php?id=211
Much better info here, nice PIT and timing manual : http://www.sat.dundee.ac.uk/~psc/pctim003.txt
> and it doesn't even work on plain MS-DOS with the MS Network Client loaded.
Hmm...
> The RTC (int 70h) already runs at 1024Hz and is much more compatible.
Maybe good idea, nevertheless
> > Nothing wrong with doing it on DOS - but don't try to run those DOS apps in an emulator!
> Why not? They should work fine.
1. Some emulators are crippled (good: BOCHS and QEMU)
2. Might not work in DOS then
Looks good :-) I did some such experiments some time in past and IIRC had problems since I failed to "latch" ... and didn't finalize the thingie then :-(One possibility for higher-res timer:
1) Read 0x40:6c to get ticks since midnight
2) Latch PIT counter 0 to get fractions of a tick ( 0 - 65535 )
3) Read 0x40:6c again to check if tick changed
The max resolution of the timer will be ~1.193MHz, precision will be around 2X the amount of time to execute steps 1-3 above. So a faster computer should get better precision than a slower computer.
Should be pretty safe to set up this way ... BTW, couldn't a PIT "jump" from a low value near zero to a high value near $FFFF replace the "midnight" test and INT 8 dependence ?Doesn't require any ISR's or memory locking etc, but does assume that the PIT is programmed to count down from the max 65536 and INT 8 is getting called 18.2 times per second. (To correctly update the ticks since midnight)
A good one ... or some commands like "update-on" "update off"This is a little off topic, but I think it has been suggested before that SCREEN[RES] could be called with a special flag such that no background updating occurs. The user would be responsible for explicitly doing the update. with FLIP or something like in OpenGL modes. Just an idea.
Rugxulo wrote:
> I have a working 486 Sx/25
Please keep it working and available, badly needed for DOS development ;-)
> you e-mail it to me, remember that Gmail is picky about binaries in attachments
Ultraparanoid about virii ? Not only GMAIL's problem :-D
> so you'll have to 7-Zip (or Bzip2 or LHA
Please don't promote obsolete stuff ... ZIP or 7-ZIP encrypt it at best, or use http://www.yousendit.com/
DrV wrote:
> This works well on my test machine (a Pentium II),
> but I'd like to know if it works well on older/slower hardware
> but please try any programs you can come up with that work
> correctly on other platforms but haven't on DOS due to the
> former SCREENLOCK semantics (ignoring the lock).
Unfortunately I don't have anything below 500 MHz available by now ...
Tests:
Didn't notice any difference, seems to work as it used to ...
STARS.EXE works.
FBCAD works (but requires -lang deprecated)
HANOI still doesn't, problem is not screenlock but missmatching screenres:
http://www.freebasic.net/forum/viewtopic.php?t=8511
Anyone can point me to the "correct" lock-affected code to be tested ?