Anybody knows the initial counter divider values and modes for channel 1 and channel 2 of 8253 PIT/CTC ?

AFAIK it is presumed:
- 65536 for channel 0
- 18 for channel 1?

What about channel 2?

Also is there any more ram refresh done by channel 1 ?
ie changing it will disrupt RAM refresh ?

According to Ralph Brown's int list, the values are as follows(just as you mentioned):

counter 0: 0
counter 1: 12h
counter 2: not spoken

I am not sure what counter 2 is set to. But I don't think it really matters since it is not really used for anything, and it would get reset if any sound is played on the speakers.

I would highly doubt that the ram refresh counter was still used. I set this rate to both 1 and 0 (the two extremes) on my 486x66 and computer did not hang.

0040 RW PIT counter 0, counter divisor (XT, AT, PS/2)
Used to keep the system time; the default divisor of (1)0000h
produces the 18.2Hz clock tick.
0041 RW PIT counter 1, RAM refresh counter (XT, AT)
don't set below 3 on PCs (default 12h), and don't mess with this
counter at all unless you really know what you're doing....
0042 RW PIT counter 2, cassette & speaker (XT, AT, PS/2)
During normal operation mode (8253) 40h-42h set the counter values on
write and get the current counter value on read. In 16bit modes two
consequtive writes/reads must be issued, first with the low byte,
followed by the high byte. In 8254 read back modes, all selected
counters and status are latched and must be read out completely
before normal operation is valid again. Each counter switches back
to normal operation after read out. In 'get status and counter'
mode the first byte read is the status, followed by one or two
counter values. (see #P0379) Note that 16-bit reads performed
without using the "latch" command will get the current high/low
portion of the counter at the instant of the port read, so it is
possible for the low part of the counter to wrap around before the
high part gets read, resulting in a significant measurement error

I guess my computer did hang after all, it just takes awhile after I set counter 1 to 0(the slowest refresh). I probably wouldn't mess around with this since you can easily use the speaker counter if you need a timer or even counter 0.

Found out that setting counter 1 to 1 also hangs system, but setting it to 4 does not.

Counter 2 by default in my bios is set to 0.

If you want to find the values, just go into debug and type the following commands:
s f000:0 ffff e6 41
for counter 1. Change the 41 to 42 for counter 2. You can then unassemble the code.

Thank you,

I knewed all the internals of controlling the 8253/8254 but i was trying to use channel 0 for detecting CPU speed and i got a big error margin...then i have checked the Linux 1.0 and Menuet sources and i have noticed that they use the port 61 to read the output line of 8253 channels 1 and 2 ...and somehow seem to assume they know tha frequency of those counters (pre-setup by BIOS?) -- aka they are NOT programming them before counting cycles?

I was wondering if channel 1 is still critical for RAM refresh and thanks to your tests it look that at least on older 486's it still IS.

AFAIK channel 2 is free for testing the cpu speed but i did noticed that Menuet uses channel 1 instead ?

Besides it will multiply delay by 66 to get 1 ms delay and that suggests a divider by 33 as 1,193,181 is first divisivble by 33 if we need a result lower than 65536 that is

I honestly thought that i could use the channel 0 for a "performance Counter" stuff.. but it looks that its error margin is a little to much for high speed CPU's... or my code is not good enough

Here is some sample dos sample code I just wrote for getting the cpu speed.

It looks like it is accurate to about 0.1 megahertz. Every once in awhile in dos on my 466 mhz computer, I would get a number that was a mhz off. Not sure why this is the case since I disabled all other interupts.
I take it you wanted to use the easy way(rdtsc), otherwise it is pretty tough counting clock cycles by instructions.

Don't think I would want to use anything less the 65536 for the timer count since even with this the margin of error for the clock cycles brings us down to .1 mhz. Might even want to try ten of these for greater accuracy.

Hope it helps anyway.

...Gomer

Unfortunately it is NOT working on my OS ...

It is not accurate enough -- same as my own methods

but Linux's and Menuet's methods do work ok...

I just wonder how does Windows execute QuerryPerformanceCounter API, since all my naive attempts have failed... aka reading the CTC timmers directly...

and what exactly is the right frequency?

1,193,180 or 1,193,181 ?

What are you getting when you call the API QueryPerformanceFrequency?

I would assume that the frequency is 1,193,181 because I have seen that in a couple of places and 1,193,180 would be that number rounded off to 6 significant digits.

I checked out the high performance counter and my system doesn't support it, so I am guessing it would be additional hardware that would be added to the pc.
Reading the counter directly is easy you just do this:
mov al,0
out 43h,al
in al,40h
mov bl,al
in al,40h
mov bh,al

bx would then hold the counter value.
Are you saying that my program for computing computer speed is not accurate enough? What kind of accuracy are you looking for? MenuetOS uses a time period of .25 seconds. My program used a time period of .05 seconds.

The steps to find CPU speed to extreme accuracy are below.
1.) Get time stamp counter with rdtsc
2.) Delay for one second
3.) Read time stamp counter
4.) Subtract value in step 1 from value in step 3. This is your hertz.

How to delay for 1 second? Can use this process:
1.) Set counter 0 to 11932
2.) Count 100 interupts

Or manually count 119381 counts.
Here is my sample program. It is accurate to around .01 mhz on my 466mhz computer.

The interrupt method will give you greater accuracy. I think the only reason why your code might not be accurate enough is you are using too short of a delay.

Thank you but i have already fixed it...

It looks like any attempt to read the counters directly and /or count the interupts/a counter incremented by IRQ0 is NOT accurate enough on high speed CPU...

I doubt it is a multitasking problem (since i use cooperative)

The ONLY way that is accurate enough is to wait >250ms and read the counters via PORT 61h in a loop (like Linux and Menuet actually do)...

All other "naive but correct" versions are close ... but strangely have an error greater than 1Mhz (sometimes 10-200Mhz or even more) at least on every CPU with a speed>400Mhz that i have tested

Of course i do know how to properly read the PIT channels without disturbing it... but i am amazed by this port 61h discovery...

Great Bogdan, do you want to elaborate a bit on the port61 access? regards, tom tobias

A quick reply from Solar OS source code:

;---------------------------------
; We use Port 61h INPUT
; to fast read PIT status
;---------------------------------
; xxx1.xxxx - Out PIT-1
; xx1x.xxxx - Out PIT-2
;---------------------------------
; also assume PIT-1 divisor is 18
;---------------------------------

Basically with a single IN al,61h folowed by: and al,00010000b you can read the hardware output of the PIT1 channel (not the counter value) and counting the transitions we can deduct time passed...

Looks like in a much faster and reliable way than reading the counter values out of PIT channels... i am still amazed ... but that "why?" question will surely fade away

While doing what Gommer73 suggests (even if conceptually corect) is not as accurate as needed ...esp. on high speed CPUs

Hi Bogdan, Thanks for this elaboration, can you comment on the improvement offered by this new approach to accessing the 8253, which is what I assume you mean by PIT? Have you some data to share, for example with various methods of timing....? Michael Abrash described another undocumented feature of the timer, in his book from mid 1990's, sorry I don't have it, but as I recall, he explained that it was possible to stop the timer, and then start it up again...? Maybe I am incorrect about that. As I recall, he sent (out instruction) a code to the timer, which changed the timer from its normal method of counting clocks, and an additional benefit of the altered counting proceedure was a halt to counting, until another control signal was received, (and I think he also sent a zero to the counter as well...?) This was a decade ago, and probably lots of other "undocumented" features of the 8253 have already been elucidated by now, and I am simply behind the times.....regards tom

Yes by PIT i mean 8253, although i think today chipsets are 8254.. i preffer to work on the safe side of 8253

Today motherboards designers are interesed in compatibility not in standards, so they will implement exactly what is needed for older OS'es and applications to work ok... ... ... sometimes nothing more so take care in your assumptions

Yes i think the 8253 can be stopped in middle of counting with normal commands and can be also restarted or even start/stop with either software or a mixture of software /hardware commands (aka an out to a port will actually comand the trigger input of 8253)...

But all this is documented in 8253's chip manuals so i do not keep them up into my mind... i have already too much cold utility facts stored up / pilled up into my mind... so i just read the manuals when i am intrested to do such testings

I also work on a need to know / need to do basics when it comes to details, and now i just needed a way to find the CPU speed for my OS so i started digging for details and i was anmazed of my findings and shared them with you...

Obviousely Linux and Menuet makers already did knowed this -- but i did not.

Basically this method is always giving the right speed without fluctuations (well if used for more than 250ms)
my CPU real speed is 1333Mhz and my counter shows exactly this when run on real hardware.

With the other methods used i have got an variation in between 1327-1356.. pretty close anyway but the variation itself was NOT nice.

Unfortumately since i have found this new method i have scratched my old code, but this new method will be in the next release of SOLAR OS source code

I guess i will have to touch/test with 8253 again when i will have to implement a method for a "Performance Timmer"

But in my OS everybody can use IN/OUT directly to hardware ports so each one can easyly make his own tests without restrictions or ring3/ring0 complications

Bogdan noted:
"But in my OS everybody can use IN/OUT directly to hardware ports so each one can easyly make his own tests without restrictions or ring3/ring0 complications"

And, in my opinion, this is a terrific feature. Regards, tom

Just a quick note: in my own oppinion this is exactly what i wanted and a beautiful feature.

Even if freedom has it caveats I DO choose freedom as opposed to a paternal supervised safety location.

However this discussion is very badly placed in this thread so i will stop here.

Why are you messing with divisors?
if you want a simple delay you might wanna try reading the $1234DD Hz frequency timer itself no?

MATRIX

lol dude
you re using "
0061 R- KB controller port B control register (ISA, EISA)
system control port for compatibility with 8255 (see #P0393) "
for reading PIT?

Bitfields for KB ctrller port B control register (system control port) [input]:
Bit(s) Description (Table P0393)
7 RAM parity error occurred
6 I/O channel parity error occurred
5 mirrors timer 2 output condition
4 toggles with each refresh request
3 NMI I/O channel check status
2 NMI parity check status
1 speaker data status
0 timer 2 clock gate to speaker status
Note: also supported by OPTi 82C392
SeeAlso: PORT 0061h-R,#P0392

MATRIX

it hurts to see some don't know what is he/she doing, so i help:


; MATRIX CPU FREQENCY MEASUREMENT PROGRAM #2
; Program measures CPU speed and writes in Hz via bios
; ( takes over your computer while measuring )
this program has moved from here because 1 is enough on this board

CPU SPEED i think is not OS dependent, so it might fit better in the main here is the thread about Machine Independent Timing Methods:
http://board.flatassembler.net/topic.php?p=16161#16161

MATRIX