Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: Read Back on 8253 PIT Chip

  1. #11
    Join Date
    Dec 2014
    Location
    The Netherlands
    Posts
    1,522

    Default

    Quote Originally Posted by neilobremski View Post
    Has the ol' 8253/8254 been removed in recent times? I had the notion that it was still present beneath or beside all the newer hardware.
    The physical 8253/8254 has been gone from PCs for a very long time. Even some 8088-based clones in the late 80s already used integrated chipsets replacing the 82xx chips. A popular single-chip solution in early clones was the Faraday FE2010: http://datasheet.datasheetarchive.co...DSA-151234.pdf

    These chips of course still offered equivalent functionality in order to remain compatible. In later times, some of the integrated functionality was changed somewhat. Eg, AT and later PCs didn't use DMA channel 0 and timer channel 1 for memory refresh. On the original AT, there are still discrete 82xx chips, they just aren't connected. In integrated chipsets, these channels might actually physically not exist anymore.

    I interpret this text from MSDN to indicate that channel 2 may also have been physically removed from some chipsets, because it was mainly used for the beeper. I never bothered to test PC speaker code on my modern systems. I know at least some of them still have a piezo on the board and boot up with a BIOS beep. I can only assume this is still the legacy PC speaker circuitry and PIT at work.

    I don't think they would remove the 8253/8254 altogether, because channel 0 is used for timer interrupts, and a lot of software uses that (multitasking OSes used to use it for the scheduler for example).
    I suppose there would be a modern replacement for that in ACPI, but I'm not really sure. Perhaps even current OSes still use it. I suppose checking the linux sources could answer that at least partially.
    According to this page on APIC: https://en.wikipedia.org/wiki/Advanc...upt_Controller
    The aperiodic interrupts offered by the APIC timer are used by the Linux kernel from 2.6.18 onwards to implement its tickless kernel feature; the legacy 8253 Programmable Interval Timer is no longer used by tickless kernels.

  2. #12

    Default

    Quote Originally Posted by Scali View Post
    Eg, AT and later PCs didn't use DMA channel 0 and timer channel 1 for memory refresh.
    Reminded me of another question: can timer channel 1 be reliably read from regardless of whether the system uses it for DRAM refresh?

    I'm thinking it could be useful simply for its raw counter values, if they're safe to latch and read. That leads me next to wonder what the counter reset value is. On AT systems I assume you can set the counter reset to anything and not crash since that channel is no longer connected to anything? You could then, if I have this right, determine if the read-back command works in order to know whether you're dealing with a 8253 or 8254. Then on an 8253 you would have to make some sort of assumption about the reset value (else forget about using that channel) and on the 8254 you'd know you were on an AT or higher and could safely reprogram that channel without blowing things up.

    Thoughts?

  3. #13
    Join Date
    Dec 2014
    Location
    The Netherlands
    Posts
    1,522

    Default

    Quote Originally Posted by neilobremski View Post
    Reminded me of another question: can timer channel 1 be reliably read from regardless of whether the system uses it for DRAM refresh?
    Only on a fast PC I'd gather.
    On a PC, refresh is programmed to 18 ticks. That is just 72 CPU cycles. A polling loop will be relatively inaccurate, giving you probably ~10 cycles jitter or so. Which would mean you could be 50% off.

    Quote Originally Posted by neilobremski View Post
    I'm thinking it could be useful simply for its raw counter values, if they're safe to latch and read.
    You wouldn't need to latch, since channel one runs in single-byte mode. Just a single read is enough to get the whole value.
    Latching and reading is safe though, it doesn't affect the timer.

    Quote Originally Posted by neilobremski View Post
    That leads me next to wonder what the counter reset value is. On AT systems I assume you can set the counter reset to anything and not crash since that channel is no longer connected to anything? You could then, if I have this right, determine if the read-back command works in order to know whether you're dealing with a 8253 or 8254. Then on an 8253 you would have to make some sort of assumption about the reset value (else forget about using that channel) and on the 8254 you'd know you were on an AT or higher and could safely reprogram that channel without blowing things up.
    I think there are easier and more reliable ways to determine whether you're running on an AT or better machine.
    On PC/XT, you shouldn't touch channel 1, unless you deliberately want to adjust the refresh rate (eg to get it in sync with audio or video).
    On an AT or better, in theory you should be able to use it as a regular counter. You should be able to reset it to any kind of mode and count, and then read back the counter whenever you like.
    Of course that won't work if the chipset designers decided not to implement the channel at all, because it was hardwired to the DMA refresh on legacy systems.

  4. #14

    Default

    Quote Originally Posted by Scali View Post
    I interpret this text from MSDN to indicate that channel 2 may also have been physically removed from some chipsets,
    I'd be very surprised if it was removed. I think whoever wrote that MSDN article confused the removal of the 8253/8254 timer functionality (which as far as I know is still in every PC) with the elimination of the actual chip (because its functionality had been subsumed into the chipset) or with the removal of the separate speaker. Removing the timer (or one of the channels) makes no sense because it costs much less to just continue shipping those several-hundred transistors forevermore than it costs to pay someone to make the change to the chip, retest everything, and refund that one customer who's running some obscure/ancient piece of software that gets broken. Removing legacy stuff is really hard.

Page 2 of 2 FirstFirst 12

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •