Text 2103, 83 rader
Skriven 2011-07-13 15:05:00 av David T. Johnson
Ärende: Re: SNAP refresh rate
=============================
SeaMonkey/1.5a
sv3-FQmhG2KzeQZidD7i5MnSqwKMNaPjSKyFnNem1QcPNBfZvOs6bLN8Ftw5/FgtS9dwOfI5Jjhcrnq85Te!wkr6CSriDiF951+snm/tGYqQBN9Y2U1XNDE6Rc16ape3sOVzaABDQAIVQzXVpVhStdSHHDM8ghbD!wwJ//1ajM1KXX0sv8friXaI=

properly
From: "David T. Johnson" <djohnson@isomedia.com>

tholen@antispam.ham wrote:
> "David T. Johnson" <djohnson@isomedia.com> writes:
> 
>>>> SNAP stores the refresh rate in 
>>>> x:\os2\drivers\snap\config\graphics\crtc00.dat
>>>>
>>>> for the base monitor.  It's a binary file so you can only edit it with 
>>>> binary editor.
> 
>>> Editing it with a binary editor isn't a problem.  Finding the correct
>>> byte is.  There are at least a half dozen occurrences of the byte "41"
>>> in the file, which is the hex value for 65 Hz, which assumes, of
>>> course, that the refresh rate is stored in units of Hz.
>>>
>>> As soon as I get to my office, I'm going to need to check whether
>>> the "last written" dates on the crtc* files correspond to about
>>> the same time as the date on the swapper.dat file, which corresponds
>>> to the last reboot.  That would at least provide a hint as to
>>> whether they get written at graceful shutdown or not.  I' trying to
>>> think of a reason why they would NOT get written immediately upon
>>> the user making the change in the System object.
> 
>> I'm using SNAP 3.1.8 which identifies itself as build 505 and is the 
>> last one release by Scitech.  The .dat file gets written immediately 
>> after a change to the refresh rate and does not get written again until 
>> another change is made to the configuration data stored in the file.  If 
>> the next change is not made for 30 days, the file does not get written 
>> to for 30 days.  You could find the correct bit by just making an 
>> arbitrary change, saving a copy of the file, and then doing at a file 
>> compare with the unchanged file to see where the change was written.
> 
> Sounds good in theory, but if making an arbitrary change to the refresh
> rate actually changed the relevant byte, then I wouldn't be having the
> problem in the first place!
> 
> Here are my directory listings:
> 
> 11-07-07 15.51      2.097.152      0 ----  SWAPPER.DAT
> 
> The above represents when the system was last rebooted.
> 
> 11-07-10 17.45          8.424      0 a---  crtc-10.dat
> 11-06-03 17.49          8.424      0 a---  crtc00.dat
> 11-07-07 15.52          8.378      0 a---  crtc10.dat   
> 11-07-07 15.52         17.836      0 a---  graphics.log 
> 11-07-07 16.00            232      0 a---  mon00.dat    
> 11-07-07 15.52            232      0 a---  mon10.dat    
> 11-07-07 15.52        623.983      0 a---  monitor.dbx  
> 03-12-05 13.31            692      0 ----  options.dat  
> 11-02-20 23.59             51      0 a---  snapos2.ini  
> 11-05-03 18.25            258      0 a---  snapzoom.ini 
> 
> As you can see, mon10.dat, monitor.dbx, crtc10.dat, and graphics.log were
> all written about a minute after the reboot, while mon00.dat was written
> about 8 minutes later, which probably represents the delay in hooking up
> an old monitor to the system so that I could see my desktop (becaused the
> new monitors don't like the refresh rate).  Meanwhile, SNAP didn't touch
> the crtc00.dat file for some peculiar reason.  And even though crtc-10.dat
> was written days later (following some other refresh rate test), it was
> apparently based on the crtc00.dat file, given that the file sizes are
> the same (but the contents are not the same).
> 
> So, something seems to be inhibiting the writing of the crtc00.dat file.
> Or is there some reason to leave it untouched while the others are being
> written following a reboot?
> 
Hmmmm.  You definitely have an older SNAP build.  My build does not use 
the crtc-10.dat file nor does it use or have the snapos2.ini file. 
Perhaps Scitech changed the structure of their data storage method for a 
later build.

-- 
Posted with OS/2 Warp 4.52
and Sea Monkey 1.5a

--- Internet Rex 2.31
 * Origin: The gateway at Omicron Theta (1:261/20.999)