SeaMonkey/1.5a
8Ftw5/FgtS9dwOfI5Jjhcrnq85Te!wkr6CSriDiF951+snm/tGYqQBN9Y2U1XNDE
Rc16ape3sOVzaABDQAIVQzXVpVhStdSHHDM8ghbD!wwJ//1ajM1KXX0sv8friXaI=
properly
From: "David T. Johnson"
tholen@antispam.ham wrote:
> "David T. Johnson" 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)
|
