[comp.sys.atari.st] Rwabs question

iarocci@eneevax.UUCP (01/30/87)

I wrote a program which intercepts the Rwabs call through the Rwabs vector at
0x476 and noticed something really strange.  It seems that the operating system
sometimes calls Rwabs with the buffer argument set to zero.  Does this mean
that the operating system will load sectors starting at address zero, writing
over all the interrupt vectors stored at these locations?  If, as I suspect,
it does not, then what specifically does it do?  In all the documentation I
have examined, I have found no mention of Rwabs doing anything special under
these circumstances.

Upon further investigation of this phenomenon, I noticed that it occured only
when a folder was first entered from the desktop.  When I tried changing to
a folder from the Mark Williams shell, this phenomenon did not exhibit itself.
Also, this seems to only happen on the floppy drive; when I set up my routine
to intercept the hard drive, the buffer always seems to contain a valid value,
no matter whether I'm using the desktop or the shell.

I'd appreciate any comments from anyone with any thoughts on this matter.
Allan, you seem to be the authority on the ST's operating system, do you have
any idea what's going on?

dyer@atari.UUCP (02/03/87)

in article <613@eneevax.UUCP>, iarocci@eneevax.UUCP (Bill Dorsey) says:
>  I wrote a program which intercepts the Rwabs call through the Rwabs
>  vector at 0x476 and noticed something really strange.  It seems that
>  the operating system sometimes calls Rwabs with the buffer argument
>  set to zero.  Does this mean that the operating system will load
>  sectors starting at address zero, writing over all the interrupt
>  vectors stored at these locations?  If, as I suspect, it does not,
>  then what specifically does it do?  In all the documentation I have
>  examined, I have found no mention of Rwabs doing anything special
>  under these circumstances.


From the documentation:

	     LONG Rwabs(rwflag, buf, count, recno, dev)
	     WORD rwflag;
	     LONG buf;
	     WORD count;
	     WORD recno;
	     WORD dev;


          For floppies, if `buf' is NULL, then no  I/O  operation
     is  performed,  and the volume's media-change mode is set to
     `count'.  (This kludge brought to you courtesy  of  the  GEM
     desktop.)

This can be used by applications (such as the desktop), typically
to force a "Might have changed" media change mode on the floppy.
Rwabs() will check for a media change on the next I/O operation.
[DMA cannot occur to location $000000 on the ST since the first
eight bytes are ROM.]

-- 
-Landon Dyer, Atari Corp.	    {sun,lll-lcc,imagen}!atari!dyer

The views expressed here do not not
necessarily reflect those of Atari Corp.	Segments are for worms.

roof@unido.UUCP (Systemverwalter und super user) (02/04/87)

In article <613@eneevax.UUCP>, iarocci@eneevax.UUCP (Bill Dorsey) writes:
> I wrote a program which intercepts the Rwabs call through the Rwabs vector at
> 0x476 and noticed something really strange.  It seems that the operating system
> sometimes calls Rwabs with the buffer argument set to zero.  Does this mean
> .........

This is a "funny feature" of the GEM(TM) desktop. Whenever you change a
folder, the desktop reads the boot sektor (block 0) at adress 0 in
USERMODE!! I discovered this when i wrote a track buffering mechanism
(soon to be released). Under MWC shell this works fine but the desktop
bombed me out of business. My solution was simply use the old routine
when a bufferadress 0 is requested.

	Andreas Toenne
	University of Dortmund
	Dept. of CS, IRB
	at@unido.uucp
	at@unido.bitnet
	....!seismo!unido!at
	Some mailer choke on my name. Change it to toenne then

braner@batcomputer.UUCP (02/07/87)

[]

Since there is media-change sensing via the write-protect widget, is it
OK to defeat that kludge in Rwabs()?  I mean, the desktop sets mediach
to 2 ("definitely changed") each time you close the window, which is
silly, and reduces the utility of my 'scache'.  If I make scache filter
out those calls, am I inviting disaster?

I did something more elaborate to tell GEMDOS that media has changed
in 'flexcopy'  (so the RAMdisk won't kick that 40-folder bug).  Is this
Rwabs() kludge a better way to do it?  I.e., if you do Rwabs(0,0L,2,0,0)
will GEMDOS dismantle its directory tree next time it tries to access
the A: disk?

- Moshe Braner