SeaMonkey/1.5a
14kiBwLWp/w8+v73VeoceY3BVmeF!0zrMqu4jGKFgKIWU2uGlS0oCYHlKHZE866N
rzaLu0iC6KmFWbONdbHzgfBYDuebwfjrzDexniPl!xYXLIcCxlFstkK1DTT/kB38=
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?
>
Regarding your question, on my system, the crtc00.dat file only gets
written to if one of the associated parameters stored in it (such as
refresh rate) gets changed. Otherwise, SNAP does not write to it,
although it presumably reads from it at startup.
--
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)
|
