Conference 7.286::atarist

    ROCP.ACC (Read Only Control Panel) is a little under 4kb and can
    be copied from: MILRAT::DISK$USER3:[WALLACE.PUBLIC.ST]ROCP.ARC
    
    	Ray

    
    
    I thought that DESKTOP.INF is ALWAYS loaded (if it's located in
    the root directory). Just SAVE DESKTOP with the settings you require
    (via the normal DAs) remove the DAs, reboot and you don't need any
    DA's.

    DESKTOP.INF is loaded by a DA! Normaly (thats probably the wrong
    word to use :-) by one of the DAs that come with the ST. I think
    it's called CONTROL.ACC (ie:Control Panel) but I'm not sure since
    I haven't used it in a while.
    
    If you remove "CONTROL.ACC" then what you saved in DESKTOP.INF is
    never loaded (unless you have a replacement DA that does this) so
    what you get is some default (not to be confused with DEFAULT.INF)
    settings.
    
    	Ray

    Maybe we should define 'loaded'.
    
    The CONTROL.ACC is used to modify certain parts of the data which
    is stored in DESKTOP.INF. But, if I change the location and size
    of the directory window and SAVE PREFERNCES that also modifies the
    contents of the file. No accessory is needed to have my revised
    directory window take effect on the next bootup.
    
    I think you're out in left field on this one, Ray!
    

    Sorry... that should be SAVE DESKTOP.
    

    OK..OK! So I told a half truth. How about if we compromise and say
    I'm out in middle field instead of left field :-)?
    
    Not all of the information in DESKTOP.INF is read and acted upon
    by CONTROL.ACC et. al., but some of it is (I new this, realy I did,
    I just didn't think about it in my haste to write the reply).
    
    I don't have an Atari document that states what information in
    DESKTOP.INF does and does not need CONTROL.ACC. But with a little
    trial and error it would seem that anything you would use CONTROL.ACC
    to set, you also need CONTROL.ACC to read/use.
    
    A simple test (simpler to do than write about) to see one case each of 
    needing and not needing CONTROL.ACC follows -
    	Make sure CONTROL.ACC is in your top level directory.
    	If you just put CONTROL.ACC there then reset the ST.
        Use the control panel to set the screen color to some odd color,
    	for monochrome this means reverse video (black background in
    	the window).
    	Create a window over to one side of the screen (just make sure
    	it isn't the default size and/or loacation).
    	Change the name of CONTROL.ACC to CONTROL.AC1 (just make the
    	extension something other than .ACC).
    	SAVE DESKTOP
        Reset the ST.
    	What you should see is:
    		The window were you put it (the OS read DESKTOP.INF
    		and put the window up were you saved it).
    		The "default" screen color (white background for monochrome
    		and I don't know what for color) not the color you selected
    		with CONTROL.ACC (the OS did NOT read DESKTOP.INF for
    		these values, at least it didn't use them, and CONTROL.ACC
    		wasn't there to read them either).
    
    Things I've tried that need CONTROL.ACC (or an equivelant) -
    	keyboard rate
    	screen color
    	install printer (ie: is printer connected to RS232 port)
    
    Things I've tried that do NOT need CONTROL.ACC -
    	set preferences (ie: confirm copies)
    	windows (ie: position when opened and "pre-opened" windows)
    
    So I stand corrected CONTROL.ACC is not needed to load all of the
    data in DESKTOP.INF BUT it is needed to load some of DESKTOP.INF.
    
    In response to "Maybe we should define 'loaded' ", I define it thusly -
    	A load is when you set the switches on a PDP11-45 console to
    	000102 (octal) and then toggle the "load" switch! :-)
    (of course since it's been 10 years since I used an 11-45 I'll probably
    have someone tell me I've got that half wrong also :-).
    
    		Ray (..just a smilling away..)

    The desktop.inf will boot from disk even without any DA, as said
    before. You also may change things in the file by opening it with
    a texteditor like 1stWord (not in WP-mode) and modify the parameters.
    Even if you don't have a control.acc or other .acc's activated this
    will work. For example you may store a ramdisk in the auto-folder
    and modify desktop.inf with an editor in a way that automatically
    the Disk C/Memory-Icon appears after booting the disk.
    Printer modification, RS232 a.s.o may be changed as well as windowing.
    I have the detailed code of desktop.inf and how to change it by
    editor (without needing a DA), if interested.
    
    Bernd
    

    Re: Control.acc
    
    One other parameter loaded by control.acc which isn't loaded
    by the desktop is the printer setup.  If you do not have the
    control panel than the desktop print screen function will use
    the default and the picture will be cut off on the right hand
    side.
    
    Martin H.

    Your default palette is not loaded automatically either.  That is
    what I wanted.
    
    Steph

    Hi,
    
    	Re .9 :-
    
    		There is no O/S call to read your current palette, but
    there is an XBIOS call to set the palette to new settings. However,
    you can get your current palette settings by reading the 15 registers
    in the hardware area of memory. This information is in the ABACUS
    book ATARI ST INTERNALS, I have used this technique to restore the
    palette settings on termination of programs that set different
    palettes. 
    
    	PS. To read the registers you will have to be in supervisor
    mode.
    
    		John
    

    re .10

>                There is no O/S call to read your current palette, but
>    there is an XBIOS call to set the palette to new settings. However,
>    you can get your current palette settings by reading the 15 registers
>    in the hardware area of memory. This information is in the ABACUS
>    book ATARI ST INTERNALS, I have used this technique to restore the
>    palette settings on termination of programs that set different
>    palettes. 

 
         There is a call to I believe the xbios to determine the current
    palette setings, you don't have to go out and read the hardware
    registers.  There is a call to set them all at once, but I believe
    there is no call to read them all at once, just one at a time.
    
    Bill Powers
    

    re .10
    
         The xbios function setcolor (7) can be used to read the current
    color, if you pass it a -1 instead of the new color val 0-0777.
    
    ex:
           move.w    #0,-(sp)       * color register 0 - can be 0-15
           move.w    #-1,-(sp)      * enquire its color, don't set
           move.w    #7,-(sp)       * xbios function code number
           trap      #14            * xbios trap
           addq.l    #6,sp          * stack fixup                   
    
    or in  MWC
    
      oldcolor = Setcolor(0,-1);  /* return color value for reg 0 */
    
    

    Re: .6
    
    I believe you had to type something like 773020 load, unit #, start.
    My memory is also very fuzzy on this...  :-)
    
    						-Dave

    Hi,
    
    	Re .11 :- My way is a lot faster
    
    John