From: tholen@antispam.ham   
      
   "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?   
      
      
   --- Internet Rex 2.31   
    * Origin: Aioe.org NNTP Server (1:261/20.999)   
|