Daniel_Roedding@fiction.ms.sub.org (02/16/91)
Some strange things about the <Esc> function in the DeskTop... Just try an assembly from 0xFE75E0 (TOS 1.04), you'll see a *really* dirty hack!! When you press <Esc> on the DeskTop, the following happens: 1) hdv_bpb and hdv_rw are patched 2) hdv_mediach is changed to a routine that always returns "2" 3) The DeskTop opens a file "Drv:\\X" 4) This call *must* use the Getbpb()-function, otherwise the redraw routine is teminated! 5) The vectors are restored and the new directory is shown So when you write your own device drivers on GEMDOS level, you *must* use Getbpb at a file request on "Drv:\\X". It took us almost a week to find out about this... IS THIS REALLY NECESSARY???? Daniel
fischer-michael@cs.yale.edu (Michael Fischer) (02/18/91)
In article <208348@fiction> Daniel_Roedding@fiction.ms.sub.org writes: >Some strange things about the <Esc> function in the DeskTop... > >Just try an assembly from 0xFE75E0 (TOS 1.04), you'll see a *really* >dirty hack!! > >When you press <Esc> on the DeskTop, the following happens: > > >1) hdv_bpb and hdv_rw are patched >2) hdv_mediach is changed to a routine that always returns "2" >3) The DeskTop opens a file "Drv:\\X" >4) This call *must* use the Getbpb()-function, otherwise the redraw > routine is teminated! >5) The vectors are restored and the new directory is shown You have uncovered the approved way of forcing Gemdos to recognize a media change. Normally, Gemdos recognizes a media change when the media has really changed, e.g., when you pop out one floppy and put in another. When media changes, Gemdos flushes its (now out of date) cached FAT and directory information and reads afresh from the new floppy. However, sometimes Gemdos fails to recognize the change, for example, if the new disk has the SAME serial number as the old. With newer TOS's, pressing <Esc> forces Gemdos to recognize a media change and flush its buffers. This keeps you out of trouble in those cases where the media change isn't automatically recognized. Thus, pop out old disk, pop in new one, hit <Esc> is safe, regardless of disk serial numbers. The way in which it is done may seem like a dirty hack to you, but think of what the possibilities are: 1. Introduce yet another Gemdos call. Assign it a number. Document it. Add code. Call it when <Esc> is pressed. 2. Temporarily insert a fake device driver to behave the way any device driver is supposed to behave when the media really has changed, i.e., it returns a "media-change error" until Gemdos calls "Getbpb" (which it does when it begins reading a new disk). Does not require modification of Gemdos OR device drivers. The desktop does (2). While (1) is in some sense cleaner, the advantages of (1) over (2) seem minor, and the advantages of not having to modify and extend Gemdos are considerable. >So when you write your own device drivers on GEMDOS level, you *must* >use Getbpb at a file request on "Drv:\\X". It took us almost a week to >find out about this... > >IS THIS REALLY NECESSARY???? I don't know what you mean about writing device drivers "on GEMDOS level". Device drivers are the lower-level things that Gemdos calls in order to move data to and from a device. They are what you link into the hdv_rw vector. Yes, a device driver does have to understand the media change protocol and to provide Getbpb and Mediach routines for the device (as well as the read/write routine), but it doesn't ever have to deal with pathnames. That Gemdos's job! What you are talking about sounds like replacing Gemdos-level functions with your own. If you are doing that, then yes, you had better be prepared to make your routines behave like the real thing, since client programs have no way of knowing they are talking to your functions instead of the real Gemdos. I think your complaint is simply that Gemdos operates a little differently than you had thought. Yes, there is an assumption that if you attempt to open a file after media change has been signalled, then Gemdos will call Getbpb(), even if the file doesn't exist. (How is Gemdos supposed to know that the file doesn't exist until it has read the directory? How is is it supposed to read the directory until it has determined the media parameters with the Getbpb call?) That's all the above code is doing. Doesn't seem that unreasonable, when you think about it. I don't think this is a reason to flame. I do suggest that you become a registered developer and get the necessary documentation if you want to get into the ST internals that deeply. -- ================================================== | Michael Fischer <fischer-michael@cs.yale.edu> | ==================================================
vsnyder@jato.jpl.nasa.gov (Van Snyder) (02/19/91)
In article <28841@cs.yale.edu> fischer-michael@cs.yale.edu (Michael Fischer) writes: >In article <208348@fiction> Daniel_Roedding@fiction.ms.sub.org writes: >>Some strange things about the <Esc> function in the DeskTop... >>1) hdv_bpb and hdv_rw are patched... >You have uncovered the approved way of forcing Gemdos to recognize a >media change... I think there was a much simpler way distributed with TOS 1.4. I don't have it with me now so I can't say for sure. Allan, can you cover this? -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp