braner@batcomputer.tn.cornell.edu (braner) (01/09/87)
[] Two questions about TOS/GEM/??? A program I am writing reads and writes disk sectors using the BIOS call Rwabs(). It is a .TOS program: no GEM graphics. I am using a 1040ST with its one disk drive. I am accessing both "logical" drives A and B. I ran the same program from micro-C-Shell and from the desktop. In the first case, GEM dialog boxes appeared, asking me to "insert disk B in drive A" and such. In the second case they did not, and I got NO WARNING from the system about when to insert which disk. The question: Since GEM is supposed to call GEMDOS, and not the other way around (says my brand new Balma and Fitler book), where do those dialog boxes come from? Are they due to some initiative of mCS? It seems paradoxical that from the desktop (a GEM environment) they are absent (in this case) while in mCS (a TOS text-only environment) they appear. How can I make them appear, or in any other way get automatic disk-swap user-directives? The other question: A program uses Rwabs() to copy a bunch of sectors off a floppy to the 'eternal' RAMdisk. These sectors include the FATs, root directory, some files, and some subdirectories. Results: Everything seems fine at root level, files usable. BUT: trying to open a subdirectory (from the desktop) causes the usual animation but leaves me in the root. No error messages. Trying the same in micro-C-Shell yields a "not found" error, even though the names of the subdir's appear in "ls". Snooping around with a debugger failed to show anything wrong with the RAMdisk data: The subdirectory files are where the root says they are, and the files in the subdir's are both listed there and physically present in the RAMdisk area where it says they are. What's going on? Any help would be appreciated. (Two bonus points to whoever guesses what in the world could such a program be good for... :-) - Moshe Braner
dyer@atari.UUcp (Landon Dyer) (01/11/87)
> The question: Since GEM is supposed to call GEMDOS, and not the other > way around (says my brand new Balma and Fitler book), where do those > dialog boxes come from? Are they due to some initiative of mCS? It > seems paradoxical that from the desktop (a GEM environment) they are > absent (in this case) while in mCS (a TOS text-only environment) they > appear. How can I make them appear, or in any other way get automatic > disk-swap user-directives? The disk-swap request comes through the critical error vector, as an EOTHER (-17) error. An extra word argument on the stack is the number of the disk (0 or 1) the user should insert. Thus: ------- #define EOTHER -17 my_critical_error_handler(errno, arg) WORD errno; WORD arg; { if (errno == EOTHER) { printf("Hey! Stuff in disk %c and hit a key!", 'A' + arg); getchar(); } else if (errno == another_error_we_want_to_handle) { .. etc... } else follow_the_old_critical_error_handler_vector; } ------- (If you try to compile that pseudo-code, you are in trouble.) So GEM intercepts the critical error handler (as indeed, you can do) and starts an appropriate dialouge. EOTHER isn't really an error condition, and it's return value doesn't matter. > The other question: A program uses Rwabs() to copy a bunch of sectors > off a floppy to the 'eternal' RAMdisk. These sectors include the FATs, > root directory, some files, and some subdirectories. Results: Everything > seems fine at root level, files usable. BUT: trying to open a subdirectory > (from the desktop) causes the usual animation but leaves me in the > root. No error messages. Trying the same in micro-C-Shell yields > a "not found" error, even though the names of the subdir's appear in "ls". > Snooping around with a debugger failed to show anything wrong with the > RAMdisk data: The subdirectory files are where the root says they are, > and the files in the subdir's are both listed there and physically > present in the RAMdisk area where it says they are. What's going on? I'll bet you modified the RAMdisk without letting the DOS know about a media change. If the media changes, the driver's Rwabs() handler must return E_CHNG (-14) until a Getbpb() call is performed. -- -Landon Dyer, Atari Corp. {sun,lll-lcc,imagen}!atari!dyer /-----------------------------------------------\ | The views represented here do not necessarily | "If Business is War, then | reflect those of Atari Corp., or even my own. | I'm a Prisoner of Business!" \-----------------------------------------------/
bammi@cwruecmp.UUCP (Jwahar R. Bammi) (01/13/87)
In article <1973@batcomputer.tn.cornell.edu> braner@batcomputer.UUCP (braner) writes: >[] > >Two questions about TOS/GEM/??? > >A program I am writing reads and writes disk sectors using the BIOS call >Rwabs(). It is a .TOS program: no GEM graphics. I am using a 1040ST with >its one disk drive. I am accessing both "logical" drives A and B. >I ran the same program from micro-C-Shell and from the desktop. In the >first case, GEM dialog boxes appeared, asking me to "insert disk B in >drive A" and such. In the second case they did not, and I got NO WARNING >from the system about when to insert which disk. > >The question: Since GEM is supposed to call GEMDOS, and not the other >way around (says my brand new Balma and Fitler book), where do those >dialog boxes come from? Are they due to some initiative of mCS? It >seems paradoxical that from the desktop (a GEM environment) they are >absent (in this case) while in mCS (a TOS text-only environment) they >appear. How can I make them appear, or in any other way get automatic >disk-swap user-directives? Those dialog boxes are certainly coming from mCsh. Internally, Gemdos generates a "insert-disk" critical error whenever you address the 'other' logical drive on a 1 drive system. The Gemdos error number for "insert disk" is -17. Critical errors invoke the critical error handler (at vector 0x101). The first word on the stack (at 4(sp)) is the error number (in this case -17)) and additional info about the error are stacked on words on top of that (6(sp) and up). In the case of the "insert-disk" critical error, the word at 6(sp) contains the virtual device number (0 or 1). The critical error handler must return with one of the following in D0.L 0x00010000 to retry operation that caused crit error 0x00000000 to ignore the error 0xffffffXX to abort with an error As usual, the handle must preserve the C non-volatile registers (D3/D7,A3-A6). The default handler is obviously just aborting the condition, and that why you don't get the dialog or some kind of warning. -- usenet: .....!decvax!cwruecmp!bammi jwahar r. bammi csnet: bammi@case arpa: bammi%case@csnet-relay compuServe: 71515,155