ATARI TECHNICAL POSTINGS 1988/89 This volume is a collection of postings to Usenet by Atari's technical staff from November '88 through to October '89. Earlier postings, and those from November and December '89 are unavailable. Postings from 1990 are available in ATARI_90.TXT. The majority of these postings come from Allan Pratt and Ken Badertscher, Atari systems software engineers. They are primarily concerned with TOS, with various definitive answers to common problems developers run in to, and advice on How You Should Do It. These are often a useful supplement to the official developers documentation. Those postings more to do with Atari policy and operations have been ommitted. Note that "opinions expressed do not necessarily reflect those of Atari Corp". I hope this is of use to you. Share and enjoy! Stephen Hebditch. ------------------------------ Date: 14 Nov 88 19:25:34 GMT From: Allan Pratt Subject: Re: Fdatime under Laser C In article <992@ncar.ucar.edu> bovet@hao.ucar.edu (Ray Bovet) writes: > I'm having a terrible time trying to get Fdatime to modify > a file modification time and date stamp using Laser C. Fdatime had some problems in TOS 1.0 and 1.2 -- it's been changed for TOS 1.4 to be more sane. I don't remember exactly what the problem was, besides the documentation having the arguments wrong... The new Fdatime doesn't write to the disk at all: it writes to the open-file data structure, which gets written to disk when you close the file. This means that checking your write with Fsfirst won't work, because what's on the disk won't get updated until the file is closed. The correct usage is: Fwrite(timebuf,handle,flag); int *timebuf; /* ptr to two ints: time & date */ int handle; /* handle of file */ int flag; /* nonzero to write from timebuf */ If 'flag' is zero, the file's date & time are copied into the two ints at timebuf. If 'flag' is nonzero, the ints at timebuf are copied into the file's date & time fields. Since the date & time are updated each time the file is written to, you should make this call immediately before closing the file. ------------------------------ Date: 17 Nov 88 18:24:07 GMT From: Allan Pratt Subject: Re: illegal instructions In article <881116021045.085584@DOCKMASTER.ARPA> Cothrell@DOCKMASTER.ARPA writes > Well, I just tried to get cute and replace the 68000 in my 1040 with a > 68010. Didn't work. No kidding. The 68010's stack frame format for all exceptions is different from the 68000's. This means there is an extra word between the stack pointer and the arguments to a GEMDOS, BIOS, or XBIOS call made from Super mode. It is possible to write code which deals with this situation, and in fact it's been done here by way of prototyping, but at this point it isn't planned for TOS 1.4. ------------------------------ Date: 15 Dec 88 21:43:48 GMT From: Allan Pratt Subject: Re: NULLFILL In article <8812150429.AA21699@ucbvax.Berkeley.EDU> U46050@UICVM.BITNET (JOHN ZAFIRIS) writes: > For those of you following the NULLFILL vs. FATSPEED saga: The > incompatibility can be avoided by using DISKFREE (by Tim Purves of > Michtron) instead of FATSPEED. DISKFREE seems to do things more > 'legally'... whatever that means. > ...John In the first place, NULLFILL and (FATSPEED & DISKFREE) do different things. In the second place, there is no "legal" way to do what DISKFREE does. (Note that Zoomracks, at least, doesn't work with it.) I don't know if FATSPEED and DISKFREE do the same thing or not. In any case, none of this is necessary with TOS 1.4. I can't recommend them even as stopgap measures, but if you want to take risks with your data, that's your lookout. ------------------------------ Date: 15 Dec 88 21:48:36 GMT From: Allan Pratt Subject: Re: bios function 0x7f In article <3767@druhi.ATT.COM> dlm@druhi.ATT.COM (Dan Moore) writes: > in article <12076@hall.cray.com>, rosenkra@hall.cray.com (Bill Rosenkranz) say > > after disassembling a code i found on some bbs which doubles the effective > > on-screen travel of the mouse form, i found it ixecutes bios function 0x7F > > There isn't a bios function 0x7f. But it is a useful bios call > if you intended to patch the bios handler on the ST. When the ST bios > or xbios handler receives an illegal function number it returns an error > code and a pointer to the bios/xbios function pointer table. Great! This is exactly the kind of "It works, so use it" philosophy which makes it so hard to improve TOS in a backward-compatible way. Please do not rely on crap like this in your programs. If you do, don't expect them to work in the future. Maybe I should make sure the hack described above stops working, but I'm not vindictive or petty, so I won't. ------------------------------ Date: 30 Jan 89 23:05:29 GMT From: Allan Pratt Subject: Re: Attaching a CHINON drive to the ST In article <973@laura.UUCP> scm1817%marvin.irb@unido.uucp (Chris Schmidt) writes : > I bought a chinon drive model FB 354 and attached it to my ST. > Now my ST does not recognize a diskchange with this new drive (it only does > with write-protected disks) This is a known problem with some (all?) Chinon drives Atari bought (and, alas, shipped). Go back to where you bought it and/or an Atari dealer to get it fixed or replaced. You can tell you have the problem by doing this: Get into a shell or program (not the desktop). Put a blank, write-enabled disk in the drive. Get a directory of that drive (a file selector will do). Remove the disk, then put it back in (still write-enabled). Get another directory of the drive. If the select light doesn't come on before the second (empty) directory listing appears, you have the bad drive. ------------------------------ From: Allan Pratt Subject: Re: Mfpint() and interrupts In article <8901302240.AA10005@ucbvax.Berkeley.EDU> ACPS5589@RYERSON.BITNET (George Borges) writes: > How can I install my own interrupt routine (in C) for the Ring Indicator > line and the Carrier Detect line? Currently, my routines DO execute but > the program bombs (usually two or three of them) immediately afterwards. You can't do it in C unless your compiler or library have some tricks. Specifically, C routines end with RTS (return from subroutine) while interrupt handlers need to end with RTE (return from exception). MWC has a library call, I think, which arranges for the calling procedure to end with RTE rather than RTS -- I think it plays games with the stack to achieve this. Check their documentation. However, the problem goes even deeper. Interrupt handlers must not change any registers (except SR; that's on the exception frame). Most C compilers can't be told to save & restore *all* the registers they use. Usually, if I *really* want to have the exception handler in C, I have a little assembly language to save registers, call the C procedure, then restore the registers and RTE: _ring: movem.l d0-d2/a0-a2,-(sp) ; alcyon clobbers these jsr _myring movem.l (sp)+,d0-d2/a0-a2 rte Then use "extern int ring()" and "Mfpint(xx,ring)" to install it. Better still, do the installation in assembly, so you can read & store the old handler's address, and restore it when you leave. Mfpint (foolishly) doesn't return the old value of the vector, so you can't use it to save & restore things. ------------------------------ Date: 7 Feb 89 01:50:58 GMT From: Dan Scott Subject: Re: TOS 1.4 in article <5321@homxc.ATT.COM>, dmk2@homxc.ATT.COM (D.KUSTER) says: > > > > A friend of mine just got the floppy version of TOS 1.4 and is having > some problems making it work. The disk has 2 files on it; TOS.IMG, > and COLDBOOT.PRG. In typical ATARI fashion the documentation describes > what the changes are but not how to use the new version. Running the > COLDBOOT.PRG causes a reboot and the old TOS installs. If he puts the > program in an auto folder it causes "infinite reboots". He has tried > all possible combinations of .IMG file and COLDBOOT program in either > root directory or auto folder with no luck. You're right, COLDBOOT.PRG only re-boots the system. > > Question 1 - is it possible that you have to remove the old TOS ROMS > from your machine before the software version will load? > Does anyone know how to use this software version of TOS1.4? No, that is not necessary when booting a RAM loaded copy of TOS 1.4 In order to use the TOS 1.4 disk, you mearly need to have it in drive A: at power-on time for the computer. >From the sound of it, your friend has an incomplete disk. The disks that are packed out of Developer Support have an AUTO folder w/ some HD files needed, a disk caching program, the SPR folder w/ the SPRgen program and of course TOS.IMG and COLDBOOT.PRG. There is also an active boot sector on the disk. If your friend is a registered developer (which he should be in order to have a copy of the OS at this point) then he should call Developer Support for an immeadiate replacement disk. Dev/Sup is the only place that *REAL* updates to TOS 1.4 should be comming from. > > Assuming he can get the floppy version of TOS1.4 to work, my friend would > like to attempt to make ROMS of TOS1.4. Making ROMs out of the RAM loaded TOS 1.4 will not be supported by Atari corp. in any fashion. TOS 1.4 is still in beta test and updates are common at this point. > > Question 2 - Can this be done using the TOS.IMG file? How? > You do not use the TOS.IMG file, there is a boot sector on each TOS 1.4 disk shipped from Atari that calls in and runs the .IMG OS file. ------------------------------ Date: 15 Feb 89 22:38:36 GMT From: Allan Pratt Subject: Re: TOS Error 35 with mx2? This is the second attempt at this posting... One way to get TOS ERROR #35 is to double-click something with a type of .TOS .TTP or .PRG which is not in fact a program, or which is garbled, or truncated. GEMDOS gives the error EPLFMT: invalid program load format. The Desktop says "TOS ERROR #35." I don't know why, and I don't know if this is the only way to get that error message: there may be other ways. ------------------------------ Date: 16 Feb 89 19:35:58 GMT From: Derek Mui Subject: Re: TOS Error 35 with mx2? in article <5440014@hplsla.HP.COM>, andyc@hplsla.HP.COM (Andy Cassino) says: > > ......... > (I have encountered TOS error 35 with other PD programs on my Mega. A copy of > twister that runs on a 1040 won't run on my Mega). > > Has anyone got mx2 running on their Mega (or 1040)? Can anyone explain the > meaning, if any, of TOS error 35? > When the AES's shell launches a program ( by doing the Pexec() ), it will check for certain error conditions. Currently it checks for -33, -34, -35, -36, -39, -41, -42, -46, -47 and if it matches, it will bring up appropriate alert boxes to inform the users. The rest of the errors will be shown as "TOS error XX." The error number XX is equivalent to the MSDOS error number as -32 is equal to 1, -33 is equal to 2 and so on. In this case, "TOS error 35" indicates there is a GEMDOS error -66. ------------------------------ Date: 22 Feb 89 18:05:58 GMT From: Allan Pratt Subject: Re: Mfpint() In article <336@wn2.sci.kun.nl> sommel@wn2.sci.kun.nl (Ron Sommeling) writes: > In article <825@per2.UUCP>, dag@per2.UUCP (Daniel A. Glasser) writes: > > > > Although, technically, you can call BIOS and XBIOS functions from interrupt > > level routines, it is not a good idea in general. It is better to set flags > > for the application "user-mode" routines to deal with. > > No, you can't safely call any BIOS or XBIOS function from within an > interrupt. That is not the case. You CAN call BIOS or XBIOS routines from interrupts. The way to do it is documented (in the documentation, of all places, not the disassembly!). You subtract 46 ($2e) from the system variable 'savptr' which is at $4a2. THEN you use the TRAP instruction. When the trap returns, you add $2e to savptr again. With this approach, one can write a BIOS call in C, because when the dispatcher calls the [X]BIOS function, the arguments are right on the stack, just as virtually all C compilers expect them to be. A couple of BIOS calls *are* written in C, notably Rwabs(). I don't know that I'd have made this decision if I'd designed the BIOS, but it does work, and it *is* reentrant, if you do what the documentation says to do. THIS IS NOT AN ENDORSEMENT OF USING BIOS FROM INTERRUPT LEVEL. If you find your program is doing that, re-think your program. There are not very many reasons to call BIOS like that, and a number of reasons not to: speed is the most important. Furthermore, NEVER ATTEMPT PRINTER OR DISK I/O FROM INTERRUPT LEVEL, because aside from the time it will take, timers and things aren't running. ------------------------------ Date: 7 Mar 89 00:53:18 GMT From: Ken Badertscher Subject: bconinning This is a reply to a mail query I recieved regarding hooking into the system console input routines. Basically the question boiled down to: "How do I do something at the BIOS level before GEMDOS gets ahold of an input character?" ================ As you may have guessed, GEMDOS gets all its character input by trapping into the BIOS. Not only that, but (thank goodness) the BIOS has a RAM based jump table for its* character IO, and it actually uses that jump table. Starting at $51e, there are four sets of 8 vectors for character device functions, as follows: *--- "soft" console vectors xconstat: ds.l 8 ; (51e) console status vectors xconin: ds.l 8 ; (53e) console input vectors xcostat: ds.l 8 ; (55e) console output-status vectors xconout: ds.l 8 ; (57e) console output vectors Each set of vectors consists of the addresses of the routines that handle the BIOS character devices (in the following order): 0 - lst: (printer) 1 - aux: (rs232) 2 - con: (screen) 3 - midi 4 - keyboard (output only) 5 - raw console output (bypass vt52 pressure cooker) 6 - reserved 7 - reserved and, as comments in the BIOS source indicate: * No range checking is performed. If a bogus device number * is passed to the BIOS' character I/O handler, the system * will crash or become funky duex. * * BIG BUG: ikbd and midi output status are reversed. Sorry, kids. * For compatibility, we won't fix it. (But we should!) Armed with all that information, you should probably be able to do what you need at BIOS level by replacing the built-in input and input status routines with your own. ------------------------------ From: Ken Badertscher Subject: FATAL TOS 1.4 ERROR! (heh, I figured that title would get your attention... ;-) When somebody showed me what ST Report had to say about TOS 1.4 in the latest issue, I just about fell out of my chair. Something about a "fatal hard disk error" that was corrected by Leonard Tramiel and myself. For those of you who don't know who I am, my name is Ken Badertscher, and I'm a TOS software engineer at Atari. In fact, for the past six or eight months, I've been the guy who puts all the various parts of TOS together and burns the result into EPROMS for us to test here at Atari. I've also worked on many of the later enhancements that went into TOS 1.4, in the BIOS, Desktop and AES, primarily. The last thing that was holding up approval for TOS 1.4's release to manufacturing a couple of weeks ago was a bug that bit Leonard Tramiel (VP of Software at Atari). Leonard had been running his system for quite some time with a hard disk that was literally on its last legs -- it had several* hardware problems, as well as media problems, but he had a lot of old stuff on it and never bothered to move it off to a different disk. It's too bad that he didn't, because a VERY OBSCURE bug in TOS reared its ugly head, and sent his hard disk data into oblivion. Now before everyone starts to panic and think that TOS is going to thrash their hard disk, I want to make something very clear: THE BUG IN QUESTION IS *VERY* RARE AND ONLY SHOWS UP IN EXTREMELY RARE CIRCUMSTANCES! Now that I've made that perfectly clear, on with the story. Allan Pratt looked into the guts of GEMDOS, the part of TOS that handles files, and after a lot of looking, reconstructed the weird circumstances that caused Leonard to lose his hard disk data. Allan fixed the bug. In fact, this whole episode started back in December, and Allan fixed the bug in December. Leonard wasn't convinced that it had been tested thoroughly, however, so he was reluctant to proceed with releasing TOS until it had been tested thoroughly. So, after weeks of writing test code, and trying to reconstruct the problem that happened to Leonard, and performing extensive autopsies on his hard disk, and running test programs for days at a time, I finally concluded that the bug was fixed. Not only that, but I cleared up another minor inconsistency in the way GEMDOS deals with deleting files. (Actually, I just discovered it; Allan finally upgraded the code). In conclusion, I'd like you to all remember two very important points. NUMBER 1: The bug that bit Leonard has been around in GEMDOS since DAY ONE. If this were really a "FATAL ERROR" that could regularly cause problems, IT WOULD HAVE BEEN FOUND AND CORRECTED A LONG TIME AGO, AND A LOT MORE PEOPLE WOULD HAVE REPORTED THE PROBLEM. In point of fact, it was a very unusual bug, and to his immense credit, Leonard is such a perfectionist that he would not allow TOS 1.4 to be released even with such a obscure, rare bug in it! NUMBER 2: ST Report reported that this bug was fixed in the FEBRUARY 24 version of TOS 1.4. In point of fact, the FEBRUARY 24 version of TOS does not exist. As you recall, I am currently the person at Atari who builds these things, and I never built a FEBRUARY 24 version. You can rest assured, however, that the FINAL RELEASE of TOS 1.4 will be as bug-free as we could possibly make it. The moral of the story is: Don't believe everything you read in the press! ------------------------------ Date: 12 Mar 89 03:47:21 GMT From: Mark O. Jansen Subject: Re: TOS 1.4 vs NEODESK and UIS-II in article <418@ultb.UUCP>, clf3678@ultb.UUCP (C.L. Freemesser) says: > > I'd KILL to have TOS 1.4 in my machine to fix all the nasties I've got > now. But I will never see it in my machine (assuming Atari's track > record for upgrading older machines doesn't change). Everything I have heard has said that Atari _is_ planning to make TOS 1.4 available to owners of existing machines. TOS 1.4 is a very different animal than the 4/22/87 ROMs. The main point of 4/22 ROMs was the support for the BLiTTER. TOS 1.4, on the other hand, is a significant upgrade even _without_ a blitter; it makes sense to make it available to everyone. ------------------------------ Date: 13 Mar 89 20:42:22 GMT From: Allan Pratt Subject: Re: TOS 1.4 vs NEODESK and UIS-II In article <418@ultb.UUCP> clf3678@ultb.UUCP (C.L. Freemesser (709ITP)) writes: > If the size of the program is too big for the 256k chips we use now, > Atari could: > > 1) Put out a smaller version (if this is possible) to fit into our > machines. TOS 1.4 certainly DOES fit in 192K (the ROM space for all STs), and you CAN upgrade a 520 or 1040 or Mega-2 or Mega-4... I don't know why you think you can't. Some newer Megas have only two ROM chips, but that's because those two parts are cheaper than six parts. The addressable ROM space is the same for all current ST machines: 192K. The six-chip sets have 256K *bits* per chip, or 32Kbytes, and 192K is 32K times six. The two-chip sets have 1024K *bits* or 128Kbytes per chip, 256K total ROM space, but the ST can only address 192K of that. TOS 1.4 will be available in both two-chip and six-chip sets, and can be put in all machines. ------------------------------ Date: 27 Mar 89 00:52:36 GMT From: Ken Badertscher Subject: Re: 2K of disk space lost? In article <2228@brahma.cs.hw.ac.uk> neil@cs.hw.ac.uk (Neil Forsyth) writes: | [...] I would also like to see the desktop diskcopy function copy disks |with 10 sectors per track. The TOS 1.4 Desktop will copy arbitrary format disks. As long as you feed it a destination disk with the same format as the source, no problem. ------------------------------ Date: 27 Mar 89 00:34:54 GMT From: Ken Badertscher Subject: Re: GDOS font format The unsigned int font_seg variable which was (unfortunately) included in some GDOS documentation does not belong there. It is an internal variable which is only used by GDOS. Actual font headers on disk should end after the "next_font" longword. One other thing you should know about GDOS fonts... the font data is NOT guaranteed to be contiguous with the end of the header. Whether on disk or in memory, pointers/offsets are provided in the font header. Use them! (Except the memory ones... you really should leave the manipulation of font data loaded in memory up to the VDI...) ------------------------------ Date: 26 Mar 89 23:42:18 GMT From: Ken Badertscher Subject: Re: News from CeBIT '89 In article <8903201139.AA00599@ucbvax.Berkeley.EDU> VBRANDT@DBNUAMA1.BITNET writes: |... |BTW: Maybe someone at Atari could tell us (many people in Germany already use |this ROM version, so I use plural) if the abovementioned version does/does not |include the 'rare fatal TOS 1.4 harddisk bug' Ken Badertscher told the net |about a few digests back. Most Definitely Not. The German TOS release is exactly the same as what is being made for France, Switzerland, USA, Canada, UK, etc. etc. This is very much the most bug-free TOS version yet. If we knew of any serious (or even small!) bugs, it would not have been released! That was the point of the "Fatal TOS 1.4 bug" message. That, and correcting the incorrect TOS version date from ST Report. ------------------------------ Date: 27 Mar 89 00:49:05 GMT From: Ken Badertscher Subject: Re: desktop.inf In article <435@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes: | |is there a ** legal ** way of obtaining the current desktop.inf information |in memory. As someone mentioned, there is the shel_get call. However, it only returns the address of the AES internal buffer which is sometimes used to store DESKTOP.INF data, ***AND*** the format of that buffer is SUBJECT TO CHANGE WITHOUT NOTICE. In other words, don't try to use what you find there, or your software will surely break in the future. |what i am wondering if it is possible to get the current window |search mask information in memory, and being able to alter it at will. This |would allow the window to search not only *.*, but also *.c, *.o, or anything |that your heart desires. [...] While that is an admirable goal, it is NOT a good idea to go peeking around in the AES' private variable space. The AES and Desktop are a very tangled intertwining convoluted piece of work, and you stand a very good chance of breaking something before you would add a useful enhancement if you tried to modify the way the Desktop handles window templates. This feature is, in fact, on the slate for the next revision of the Desktop! In the mean time, might I recommend that you try NeoDesk from Gribnif Software. It has the "window template" feature, and a host of other enhancements that Atari just didn't have room for in 192K worth of ROM space. ------------------------------ Date: 27 Mar 89 00:27:57 GMT From: Ken Badertscher Subject: Re: setenv on boot-up (how?) Dale posts some very useful code for dealing with environment variables. However, the part of the code that deals with the TOS environment will hopefully be obsolete very soon. The fact that there is a null after the PATH= in the default TOS environment string is an anachronism left over from a bug in earlier TOS versions, to wit; the BIOS variable which holds the value of the boot device was used as a WORD instead of as a BYTE when filling the startup environment string, hence you get a null before the drive letter. This is not standard, nor should it be construed as a "TOS" format environment. The easiest way to check for the default environment is with a couple of longword compares (look for "PATH" then "=;\0" <- really four characters there, =, ;, , A or C ). GEMDOS environment strings are: ...a series of null-terminated strings of the format "VAR=value"; the last string is followed by two zero bytes, indicating the end of the environment. - Pexec Cookbook Which is to say, they follow the somewhat universal environment string standard, a'la UNIX(tm) or MS-DOS(tm). The fact that semicolons were required to separate path names was an oversight as well; TOS 1.4 allows commas or semicolons to separate pathnames in the PATH environment variable. In fact, the AES now uses the environment much more intelligently, and will look down whatever paths you have specified for shel_find and rsrc_load calls. Hopefully someday I'll get to release the auto/accessory environment setting utility that I've written; I think people will like being able to stick their resources all in one folder... ------------------------------ Date: 26 Mar 89 23:14:07 GMT From: Ken Badertscher Subject: GEMDOS Extended Argument Standard Please excuse the length of this message (nearly a hundred lines - sheesh!) but I consider Atari's role in setting software standards fairly important... Since I'm taking over the mantle (or is it a yoke? ) of maintaining GEMDOS, I will be intimately involved in the pending (admittedly belated) adoption of a standard for extended argument passing in TOS. It is a major concern of mine, for a couple of reasons: - Two (or more) de facto standards exist - The proponents of these standards seem to have some emotional involvement in whose standard is best: "Since they (MWC) are bigger than I am..." Mr. Beckemeyer ;-) "Oh, I wish I had known about this conclave!" Mr. Schumacher ;-) "!" David Parsons ;-) ;-) - GEMDOS enhancements are coming that will require a robust means of passing lots of information between parent and child processes In fact, we have discussed this recently at Atari. It came up because of a bug in Gulam, which does something strange with the command line length byte. The MWC extended argument scheme not only puts extended arguments in the ARGV environment variable; it also puts a length byte of 127 into the command line. Normally, this is no big deal, because a command line string is null terminated anyways. Even if a Pexec caller passes a command tail that is not null terminated, GEMDOS makes sure that the trailing null is there in the command line part of the basepage of any process that it creates. If, however, a program uses a command line length byte that is unreasonable (like 127), that program is going to have problems. GEMDOS does nothing at all with the length byte passed in a Pexec command tail except copy it along with the rest of the command tail into the child's basepage. To quote the Pexec Cookbook (yes Virginia, there is a Pexec Cookbook), the command tail string is a "null-terminated Pascal-style string." This means that the maximum theoretical length of a GEMDOS command line is 126 bytes (128 bytes in the basepage minus length byte minus null terminator). In fact, the *actual* maximum length of a GEMDOS command line is 125 bytes, because that's the maximum number of bytes that GEMDOS will copy into a command line when it creates a process during Pexec. Unfortunately, I didn't get that little tidbit into the Pexec Cookbook before it went out. The upshot of all this is that it is* possible for a process to know if the ARGV in its environment is meant for it and not left over from one of its MWC/Manx/MT-C Shell spawned ancestors. If its command line length is something unreasonable, a program can take that as a clue that it should go sniffing around in its environment for more information. One can only imagine the multitude of meanings that could be assigned to bytewise-negative command line lengths... HOWEVER... I still have problems with both ARGV and xArg command line extenders. This whole iovector thing bothers me. David Parsons came up with a nice, clean isatty() that works just fine without cluttering up ones environment with ???????'s. As far as I can see, the iovector is not necessary, nor does it belong in a scheme for passing arguments. And as Dale et. al. said in the xArg proposal, it "makes a mess of the already confused environment string." XARG also bothers me, because it means that a child has to muck with its parent's address space. Can you say "virtual nightmare"? Not only that, but XARG.xparent (pointer to parent's basepage) is a needless duplication of information that a process can get from its own basepage (although I guess it could be useful for an extra level of verification). And again, needless support for the iovector string. And both methods *require* the startup code to search the environment for extra commands that may not even be there. Currently, I'm leaning towards the ARGV method with the iovector yanked, a negative byte value for the command line length to flag it, and a different name for the environment variable. This saves applications from needlessly hunting through their environments (if the length byte isn't negative), and applications that don't understand the significance of the negative length byte will get what they can from the 125 bytes that GEMDOS gives them. Since the dLibs don't use the iovector anyways, it only entails a small startup code change for them. If the name of the environment variable is different, library code which uses the iovector from ARGV can still do it, but I STRONGLY recommend that people who are using iovector strings fix their libraries to use a safer isatty(). I am not formulating a standard on a Sunday afternoon, though. I'll let this percolate through the net for a week or three, and see what bounces back. From here and other sources, we'll come up with something that everyone can at least live with. And to those of you who have been bemoaning the lack of "strong Atari involvement" in matters like this, I have but one thing to say: Be careful what you wish for, you just might get it! ------------------------------ Date: 28 Mar 89 23:59:08 GMT From: Allan Pratt Subject: Re: Problem with TOS recognizing media changes In article <3938@druwy.ATT.COM> dlm@druwy.ATT.COM (Dan Moore) writes: > Unfortunately many drives do not return valid write protect > status for several milliseconds after they are selected, which is many > times longer than the vblank code takes. So these drives have problems > on the ST since media changes aren't always detected. Another failure mode is that some drives don't give a valid write-protect signal when there is no disk present. This means you can take out one write-enabled disk and put in another, and the ST won't see a transition on the write-protect line. If you MUST use such a drive, have a write-protected disk handy. Whenever you remove a disk, place the write-protected disk in the drive for 1 second or so, then take it out again. In this time, the ST will detect the transition on write-protect and mark the media as "maybe changed." When you put in the next (write-enabled) disk, the serial number will be read, it won't be the same, and media change processing will commence. Note that going from one write-protected disk to another, the write-protect line often doesn't change. That's taken care of by the floppy code, too: if the line has not changed from the write-protect state and the last access was more than 1.5 seconds ago, the media's state is "maybe changed." These drives, and those mentioned by Mr. Moore, are out of spec for the ST: don't use them. ------------------------------ Date: 31 Mar 89 09:49:43 GMT From: Ken Badertscher Subject: Re: Obliterating your boot sector, Part I In article <2938@brunix.UUCP> rjd@cs.brown.edu (Rob Demillo) writes: |OK, here I am...peacefully working on a contract program. Suddenly, |I decide that, for various reasons, it would be a useful thing to |be able to detect whether GDOS is installed on the user's machine. | [stuff about HD boot sector mysteriously disappearing after TRAP #2] | |My question is: was this a co-ink-ee-dink, or did the TRAP #2 put |my Atari into the twilight zone? Coincidence? Maybe. But there is no way that a GDOS Trap #2 inquiry could waste your hard disk's boot sector. Got any other evil, insidious memory resident tools lurking in your system? ------------------------------ Date: 2 Apr 89 02:52:48 GMT From: Ken Badertscher Subject: Re: Handling mouse button pushes In article <8086@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen Jacobs) writes: |[stuff about evnt_multi problems monitoring mouse buttons deleted] |1) Use the documented extended Line A variable to sense the mouse button | state whenever it might be interesting. A better solution than using line A variables is to use the VDI vex_butv() call, inserting an interrupt handler of your own which saves the button states in your local variables and passes off to the original vector. After you have installed your handler via vex_butv(), the system will jsr to your code any time the mouse buttons' state changes. When you are done updating your local variables, you should jump through the vector that was returned by vex_butv() so that the system gets the button state change information as well. This is just a pet peeve of mine; people tend to indiscriminantly use the line-A variables rather than the VDI calls that are there. In most cases, it is not necessary (and sometimes dangerous) to use Line A variables. In this particular case, even if you're being very conservative with what you do with button changes, you may run into problems. The AES maintains its own button state information which is independant of the VDI/Line-A variables, and it is possible (if you aren't careful) to get "out of sync" with the AES. Good luck with your button handling code, Stephen! ------------------------------ Date: 2 Apr 89 14:31:48 GMT From: Ken Badertscher Subject: Pexec Cookbook, and pseudolegal system calls... Several people have asked how to get the Pexec Cookbook. It is available to registered developers, who can find it in the usual online places. It will also be included with the TOS 1.4 release notes, which will be sent to all* registered developers. It is also being folded into the developer documentation, so if you buy that documentation, you can get it that way too. Complete Atari ST developer documentation (not schematics, they are available seperately) is available from Atari Corp. for $100. If you're looking for "real" ST documentation, this is the first and best place to get the inside facts. Believe me, you get quite a stack of documentation for your hard-earned C-note! ================ In article <1409@atari.UUCP> I wrote: >As someone mentioned, there is the shel_get call. However, it only >returns the address of the AES internal buffer which is sometimes used >to store DESKTOP.INF data, ***AND*** the format of that buffer is >SUBJECT TO CHANGE WITHOUT NOTICE. > In other words, don't try to use what you find there, or your software >will surely break in the future. ... >it is NOT a good idea to go peeking >around in the AES' private variable space. The AES and Desktop are a >very tangled intertwining convoluted piece of work, and you stand a very >good chance of breaking something before you would add a useful >enhancement if you tried to modify the way the Desktop handles window >templates. Ignac Kolenko writes: if the shel_get() call returns values which are *internal* to the desktop only, then why, oh why, is this call sitting around for us programmers to use???????????????? The tos 1.4 developer docs do not say that there is anything inherently wrong with using shel_get()!!! (i had to phone a friend who has the docs to find out this info) Quite a few things in TOS are documented and have no useful function. That does not mean that programmers can or should have carte blanche to use these features. Nor should anyone assume that the useless features will retain the same behavior in future TOS revisions. It is unfortunate that the BETA TOS developer documentation was unclear on the lack of usefulness of the shel_put() and shel_get() AES calls, but that oversight will be corrected in the final release notes. Don't do illegal stuff with your software, please. We are no longer constrained to strict software compatibility in future TOS revisions, and I, for one, intend to take advantage of that fact. This means that I will be implementing enhancements which will almost certainly break software that either a) didn't follow the rules in the first place, or b) was built on bad assumptions about the internal workings of TOS. P.S. Have a nice day. ;-) ------------------------------ Date: 2 Apr 89 14:46:44 GMT From: Ken Badertscher Subject: Re: GEMDOS Extended Argument Standard Here is a summary of some of the mail & messages I've seen in the past week regarding the proposed GEMDOS Extended Argument Standard: David Beckemeyer writes: ------------------------ What about the transition period? There are a whole bunch of programs that use the current MWC style ARGV. MWC programs, and anything compiled with their libraries use iovector and they don't always work right when it's not there. Also I bet even if MWC does implement the new standard, it will take a while and many users won't change over for a long time. This leaves an ever increasing number of programs that won't understand the new format (and probably won't work right). The next issue is the idea of the "negative" command tail count. I wonder if some startup code might just take the value as 8-bit unsigned and attempt to grab, say 254 bytes from the tail without checking and maybe bomb out in attempting it (I've seen programs that do worse). I don't see how [leaving just the iovector after ARGV] can work, since the old MWC ARGV is *always* followed by the list of arguments. If the the new name has the arguments, you can't put them after ARGV too. John Dunning writes: -------------------- I think the scheme you outlined (use the magic env var "ARGV=..." as a sentinel, and use a negative byte length in the command string) is sort of ok, but but I'd advocate taking it one step further. The thing I'd worry about is old programs (or new programs using startup code that's not quite 'right' etc) getting their caller's args, if they were spawned with Pexec(0, foo, bar, 0). I propose the following extension to your scheme: When Pexec'ing, and there's no environment passed to Pexec, instead of simply cloning the current env, clone selectively, ie copy only up til the magic sentinel. Do everything else the same, and I think you get all the same benefits, with less risk of confusing programs that, for whatever reason, aren't adhering to your new protocol. You also don't even NEED to assign meanings for oddball values of the command line length byte if you do that. Part of why I suggest this scheme is that I just re-wrote the system() function for the GNU C lib to do just what I described. David Parsons writes: --------------------- What if the program uses the length byte to figure out length of command line tail like so: for (length = *(tail)++; length-- > && .... ???? It would be nice to be able to have the extended arguments code also be able to handle talking to processes that don't grok extended arguments and which don't clear sign-extension on the length byte (which is not an unreasonable thing to ignore, because the tail can't be >127 chars.) [...] at least xArgs doesn't carry the argument list to all the descendants of the process, which is what the Mark Williams `standard' does. [...] The big problem with this is that you will get those strings propagated all over the universe, anyway, and if a process modifies the environment with putenv(), the ARGV= stuff will be scrambled around. [and he proceeds to describe just how ugly the argument propagation gets] If you're planning to do enhancements to TOS for extended argument passing, perhaps it's time to consider the basepage & additional gemdos traps for extended argument pexecing? Pekka Sarnila writes: --------------------- if length is say FF the last long (after null) would contain the pointer to unix like parameter structure. In that case Pexec would count the length of that structure and allocate that much more space and copy (and reloc pointers) it to the new processes memory area. ================================================================ The transition period is going to be ugly. No two ways about it. No matter what new standard we adopt, we're going to break some software. If the new scheme is sufficiently different from the old ones, however, software which uses an older method will continue to work with other software which agrees with that old method. The negative command tail count has been received negatively. That's OK, because there's still an "unreasonable" positive command tail length that isn't in use: 126 bytes. Remember that GEMDOS only ever copies 125 bytes from the command tail passed to it in Pexec. The various suggestions that deal with changing the behavior of Pexec are unacceptable for two reasons: 1) Folks with an older version of TOS would lose big. 2) We have just finished a TOS revision, and the next one won't be complete for quite some time. I would prefer for this standard to be in place before that, so that the Desktop, et. al. can take advantage of it. It's just going to have to be the responsibility of library startup code to comply with the new standard. Period. Using the basepage, or additional GEMDOS traps, won't fly either, for the reasons stated above. Finally, let's consider the sticky problem of environment-based argument strings being propagated all over creation. There are two things that GEMDOS copies from a parent when it creates a process. The basepage (process descriptor) information, and the environment. GEMDOS allocates memory for these, then fills them in. It would be nice if it allocated an argv[] area as well, but it doesn't. The only clean way that I see to get around that problem is to put the extra args in the environment. This causes problems if the args take the form of a standard argv[] array. BUT... If the extended argument string is not itself a series of null terminated strings, the problem solves itself neatly. getenv() and putenv() will not confuse the environment, and can in fact be easily used to pass a lot of args to a child. The environment arguments should consist of a regular command-tail style string, with arguments separated by white space. That way, arguments can even contain `='! So... here's GEMDOS Extended Argument Standard proposal #2: ---------------------------------------------------------------- If a program wants to pass more than 125 bytes of arguments to a child, it should create a command tail of (at most) the first 125 bytes of the "real" arguments, and give it a length byte of 126. This will satisfy children which don't understand the extended argument standard. The program should also place an environment variable called ARGS in the environment it intends to pass to the child (its own, or a specially created environment, per the Pexec spec). The ARGS variable should consist of the name of the child (argv[0]) followed by a space, followed by the rest of the arguments (argv[1..n]), separated by spaces. The startup code of ARGS-aware programs is responsible for checking the command line for the magic length byte, then searching the environment for the ARGS environment variable command line. It must copy the ARGS command line somewhere so that it can be parsed into an argv[] string. IT MUST NOT BE PARSED IN PLACE, OR THE ENVIRONMENT WILL BE CORRUPTED. The startup code can then set the argument count and argv[] array pointers, and do whatever else it needs to do before starting up the mainline code. ---------------------------------------------------------------- Hopefully, some time this week, I will be able to get in touch with most of the compiler vendors to discuss this plan with them. In the mean time, please keep the e-mail coming! ------------------------------ Date: 3 Apr 89 23:26:12 GMT From: Allan Pratt Subject: Re: TOS bugs. Disk related. In article <763@stag.UUCP> to_stdnet@stag.UUCP writes: > From: omni!emh@stag.UUCP (Eric Hopper) > Organization: Omnifarious software. > > When using a shell program on the ST, I can't seem to delete a > directory without going into it first. Before I go into the directory, it > gives me a "directory not empty" message. I know the directory is empty > though, because when I do go into it, and then back out, I can delete it > just fine. Yes, this is a GEMDOS bug. In fact, if you try to delete the subdirectory twice, the second time will work, even if you don't "go into" the subdir. It's fixed completely in TOS 1.4. In fact, lots of trouble can happen if you get a disk error or even disk full during a mkdir operation; now those things are not harmful (or at least much less harmful). ------------------------------ Date: 5 Apr 89 00:40:42 GMT From: Ken Badertscher Subject: ST docs In article <1221@ncrcce.StPaul.NCR.COM> rogers@ncrcce.StPaul.NCR.COM (Bob Rogers) writes: |Do you folks _ever_ intend to publish this information in a readily available |and affordable format? Yes. |From what I saw of the developer's docs (I saw a |copy a couple of years ago) they're not professional quality documentation. The ST documentation is much better now than it was several years ago. |Given the tiny percentage of the market that the ST has, and the tiny number |of (mostly tiny) companies that write software for it, can you really afford |to "certainly break software"? Context! We definitely can afford to, and most certainly will, break... |>software that either a) didn't follow the rules in the first place, or |>b) was built on bad assumptions about the internal workings of TOS. |Bob Rogers rogers@stpaul.ncr.com or rogers@pnet51.cts.com |NCR Comten, St. Paul, MN GEnie: R.C.ROGERS ------------------------------ Date: 4 Apr 89 19:45:19 GMT From: Allan Pratt Subject: Re: May I overwrite basepage In article <766@stag.UUCP> to_stdnet@stag.UUCP writes: > From: BROOKS%csss-a.prime.com@RELAY.CS.NET > > Sometimes I write very small stay-resident programs and, instead of > allocating 2K of bss for an stack (and then only using 250 bytes) I set > up the stack to overrun my startup code and wander down into the > basepage. > > Does anyone know: Will this cause any problems? Does TOS need anything > in the basepage one I've started executing -- providing I don't Pexec > anything? Of course, I'd better not go *below* the basepage... You'd better not go INTO your basepage, at least not past your command line (which starts at offset $80 in your basepage). GEMDOS needs to use the basepage (not surprisingly), so you can't make any GEMDOS calls after you clobber your basepage. The GEMDOS call Ptermres, which you obviously are using, definitely needs stuff in your basepage, like your parent's basepage address so it can restart your parent. You can clobber your own command line area and the part of the TPA beyond that, but leave the rest of your basepage alone. Do NOT take the example I gave above and think, "Oh, if I preserve the parent's basepage value in my basepage, I can use the rest of it." It is intended as an example, not an exhaustive list, of what GEMDOS needs from your basepage. ------------------------------ Date: 5 Apr 89 08:13:55 GMT From: Ken Badertscher Subject: Re: Screen Dump Stuff In article <8904012328.AA04233@ucbvax.Berkeley.EDU> UNCSPL@UNC.BITNET ("Scott P Leslie") writes: |Atari, | Could someone there comment on whether the TOS 1.4 hangs for |30 seconds when ATL-HELP is inadvertantly pressed and the printer |is not ready? The 30 second "hang" is a required timeout for dot matrix printers. Yes, TOS 1.4 still does it, because it is necessary. Even if you press ALT-HELP a second time to cancel the screendump, the print screen routine will do the timeout. ------------------------------ Date: 5 Apr 89 20:53:36 GMT From: Allan Pratt Subject: Re: GEMDOS Extended Argument Standard In article <156@np1.hep.nl> t19@np1.hep.nl (Geert J v Oldenborgh) writes: > I wonder why we could not use the present 'standard' with one small diff: > let the sartup code of a program kill the extra part of the environment by > putting a 0L on "_P(B=...)". This unclutters the environment and avoids > misunderstandings of its children, the main arguments against this scheme. The only thing that fixes is a "smart" program finding surprising things in its environment. (That is, an argument FOO=3 will also look like an environment variable FOO with value 3). This doesn't help dumb programs at all. A dumb program will still get this funny thing in its environment, and will still pass that along to its children. Worse, if the dumb program actually tries to change its environment, it might put a new (and important) variable at the end, after the ARGV and the rest, and a "smart" program will lose this when it nulls out ARGV. So ARGV is bad for dumb programs. We need something which does not violate the format of an environment variable (i.e. no embedded nulls allowed) and therefore doesn't confuse either dumb programs which change their environments or smart ones which use getenv(). We also need to address validation: finding ARGV in your environment does not mean that the args were meant for you. MWC kindly puts a strange number in the command-line length byte ($7f), but, alas, doesn't check it. If it did check this would solve the problem, because a dumb program might blindly pass along the ARGV in the environment, but it's not likely to put the same number in the command-line length byte. Another validation technique is to use the process' PID (basepage address) to identify who put the args in the environment: eight bytes can encode the PID of the culprit, and this number could be checked against the "parent's basepage" field in the child's basepage; a match means these args really came from your parent. This removes the problem of putting a funny number in the command-line length byte, which might just happen accidentally. ------------------------------ Date: 5 Apr 89 21:23:58 GMT From: Allan Pratt Subject: Re: TOS bugs. Disk related. In article <460@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes: > when you install an application on the desktop (you know, click on a program, > go to the menu entry for install application, type in the extender for the > program and click install), and then click on a file with the correct > extender for that application, the desktop seems to stick in a carraige > return into the commandline for that application. > > ie: the commandline buffer in the base page will contain the length byte, > the the filename clicked on, and then a carraige return before the null > termination byte. the carraige return does not appear when you run the > program from the numerous commandline shells in existence. The command line is not null terminated. The nulls just happen to be there. The only correct assumption to make is that the command line length byte tells how many valid characters there are in the command line. You will notice that an argument like "foo" will give a command line length byte of three, and the CR is the fourth byte in the command line space. Note that this convention is violated by MWC: they put $7f in the command line length byte (and null-terminate the real command line) to indicate that ARGV is in the environment. See the discussion going on in this newsgroup for more on that. > also, say you were in a couple of subdirectories deep on a drive, and click > on a file with the correct extender for that application. what seems to > happen now is that the desktop will do a pexec load call to load the program > into memory, change directory back to the directory containing the file you > clicked on, and do a pexec go call. is this a correct assumption?? > (this is based upon the fact that only the filename appears in the commandline > in the basepage, NOT the complete path to the filename!!) if it is true, > will this mannerism change in the future?? it is a nice feature if it is true! Your reverse-engineering of what goes on is admirable for its complexity. The truth is that you can call Pexec (or any other GEMDOS function) with a full-blown pathname to the file in question, so no changing of directories is required. What you see on the screen or in your command line and what got passed to GEMDOS can easily be two different things. Your current directory when the program starts is the directory where the file was double-clicked. The argument you find on your command line is the name of the file which was double-clicked, with no path or drive information. This has always been true, and it is still true. If you use the right button to double-click a document from a window which is not the top window (did you know you could do this?), I don't know what happens in original TOS or Mega TOS, but TOS 1.4 "tops" that window before starting the installed application, making that the current directory. This is for clicking documents for installed applications only: if you use the right button to double-click an application outright, the current directory is still the top window. TOS 1.4 has a new feature in this area: shell_find (which rsrc_load uses to find resource files) now looks in more places, including the place where the application was loaded from, even if that's not the current directory. Therefore an "installed" application will find its resource file no matter where it lives, as long as the resource file and the application are in the same place. There are more details in this area; see the TOS 1.4 release notes for full details. ------------------------------ Date: 7 Apr 89 19:33:59 GMT From: Allan Pratt Subject: Re: Problem with TOS recognizing media changes In article <330@laas.laas.fr> ralph@nastassia.laas.fr writes: > I often pop in and out floppy disks while running gulam. This media > change problem does hit me from time to time when I want to access a > sub directory on A:. Is there any way for to reread the disk? An > 'ls -l' does correctly show the root directory. Is there any other > solution to quitting gulam, clicking in GEM, and restarting gulam? Gulam has a feature whereby it caches directories. There should be validation of the directory cache via a Mediach() call on the pertinent device, but there isn't. This is strictly Gulam's fault. Gulam's directory handling is really bad: ever try "ls -lt" on a directory with, say, 100 files? It takes a LONG time. That time is not sorting; it's making two or three Fsfirst calls for each file. Fortunately, if you use TOS 1.4 and add directory buffers, it doesn't hit the disk 300+ times... The trouble is, the code is so convoluted I can't hope to improve it. I am really sorry Gulam is so good: it prevents me from writing a proper shell. Gulam's bugs are irritating, but the bulk of it is too good to junk. (Well, specifically, the code is badly unstructured and virtually impossible to analyze, troubleshoot, and improve.) ------------------------------ Date: 11 Apr 89 00:30:35 GMT From: Allan Pratt Subject: Re: HELP!!!!!!!!!!!!!!!! In article <6840@saturn.ucsc.edu> humtech@ucschu.ucsc.edu (Mark Frost) writes: > Other than manually copying all of the files > off of the floppies I can find no way to do this using Turtle (or any of > the support programs). You have hit on the only solution there is: copy the files from floppy to your hard disk. Too bad for you that TOS 1.4 isn't out yet: it'd be a lot faster. Did you know that you can use the desktop to copy a whole floppy to a hard disk, including (recursively) copying directories, by dropping the floppy disk's icon onto the open window of the hard disk's root directory? That'll be fastest. ------------------------------ Date: 11 Apr 89 00:21:14 GMT From: Allan Pratt Subject: Re: (none) In article <8904071506.AA22861@ucbvax.Berkeley.EDU> USQB015@LIVERPOOL.AC.UK writes: > I've heard talk about TOS 1.4. One of the "little" things about TOS that > is very annoying is when a program returns to desktop the OS "always" reads > the disk, even if the disk hasn't changed! Has this been rectified on the > new TOS or will this little problem be explained away as "necessary" from > somebody up on these things? When you launch an application, you do it from an open window. When you return, the Desktop has to redraw that window. To do this it has to re-read the directory for the files in that window. To do that, it has to read the disk. Well, not quite: if you have so many GEMDOS disk buffers in your system that the directory is still cached, the Desktop's reads won't actually hit the disk. I don't know if this is ever true for current TOS, because the cache is managed so badly. Also, you only have four buffers by default (two each in two different lists), so you rarely have anything useful still cached. If you add more buffers, GEMDOS performance improves considerably, especially with TOS 1.4. As an example, let's take copying a disk full of files onto your hard disk. With only a couple of buffers, you'll hear the floppy head seek to the directory, to the FAT, out to the data area to read the file, then back to the directory for the next file. With more buffers in TOS 1.4, the FAT and directory are read once, and from then on the disk simply steps through the data area, reading sector after sector of file after file, without having to re-read the FAT or directory. Naturally, copying *to* a floppy will involve more, because writes are never delayed -- closing a file causes the FAT and directory to be updated. But reading a disk full of files is much faster & more pleasant. ------------------------------ Date: 13 Apr 89 19:44:13 GMT From: Ken Badertscher Subject: Re: how to kill a mouse cursor In article <8904051001.AA18434@ucbvax.Berkeley.EDU> USQB015@LIVERPOOL.AC.UK writes: |Easy, | Use A-line instruction 10 $a i.e. opcode $a00a That's also a good way to get the AES confused about how many times the mouse has been hidden/shown. The AES keeps its own internal count of how many times the mouse has been hidden or shown so that it can clean up after applications that go astray with the mouse. This AES count will get out of sync with the actual mouse state if you interleave VDI/line-A show/hide mouse calls with AES graf_mouse calls. So the answer to the question how to kill a mouse cursor isn't all that easy. If your program uses the AES a lot, you should probably use the AES graf_mouse() calls to hide and show the mouse. If not, use VDI or even line-A. You could even disable mouse event reporting at the IKBD level if you wanted to go so far. | Mark Powell ------------------------------ Date: 13 Apr 89 20:02:56 GMT From: Ken Badertscher Subject: Re: (none) In article <8904120448.AA24499@ucbvax.Berkeley.EDU> U46050@UICVM.BITNET ("JOHN ZAFIRIS ") writes: |I am familiar with the line-A calls and the VDI ((or is it AES)... the GEM |type) calls for mouse cursor handling. None clear up the problem. |I assumed that calling the hide mouse line-A opcode several zillion times |and then using either the line-A show mouse code with a cleared "mouse hidden" |counter or the VDI (?) code to show the mouse cursor no matter how many times |it was hidden (which works otherwise) would fix the problem but it did not. [...] |The desktop does not have the problems my shell has. What does it do? I have |tried all the leagal ways of fixing the problem that I can think of. Does the |desktop do something illegal? But then that would actually be legal |just undocumented. (Atari-speak) The desktop, because it is an integral part of the OS, can get away with some things that applications just can't do. In this case, when launching a program, the desktop terminates, the AES shell runs the program, and when the program terminates, the AES shell starts up the desktop again. One of the first things that the desktop does, in order to clean up after "unclean" applications, is to re-initialize the AES window and mouse handlers. This is something that an application just can't do (legally...) Until TOS 1.4. When TOS 1.4 becomes available, a new AES call will become available with it. The wind_new() call effectively does what the desktop needs done after an application has exited; it cleans up after the application, resetting the AES window and mouse handlers. I'm sorry that I can't provide an easy solution to your problem, but that's why the wind_new() function was put into TOS 1.4! ------------------------------ Date: 13 Apr 89 22:26:53 GMT From: Ken Badertscher Subject: Re: Extended argument passing conventions in Pexec() [MWC] In article <841@per2.UUCP> mwc.uucp!rec writes: | My name is Roger Critchlow. I work for Mark Williams. I invented | the MWC ARGV argument passing convention in October 1985. I don't | think either of the proposed replacements is an improvement. | ----------------------------------------------------------------------- | Our convention is incomplete because you can't tell if the ARGV was | actually passed by your parent or simply passed on by some intervening | shell? | [ environment comparison code omitted ] | | This example is only the simplest of many procedural validations | of the ARGV convention. You can chase the parent pointers all the | way to the desktop and determine who exactly is responsible for | each part of the environment in each of the processes active. It is simple, yes, and it simply won't work. Using ARGV, a parent is required to copy its environment before it execs a child. What if someone decides they'd like to sort the environment variables for the child as they create the child's environment? What if they want to filter it? The environment comparison fails, and validation goes out the window. The MWC tools already* provide a flag ("unreasonable" command line length byte) which can be used to validate the ARGV, and it is unused by the MWC startup code! | I don't think that every program which uses ARGV needs be burdened | with this sort of validation, but it's clearly possible. One of the *main* reasons that xArgs came into existence in the first place was that ARGV lacks validation that the arguments in the ARGV pseudo-environment-variable really do come from one's parent. You may not find the validation necessary, Roger, but there are many people who use tools which were not compiled using MWC libraries. A typical ST developer's toolkit contains sundry tools with a varied ancestry. The plain fact is that ARGV does not peacefully coexist with tools that don't use ARGV. | ----------------------------------------------------------------------- | Our convention is messy because it involves copying arguments around | in the environment? | | But all three proposed argument conventions require copying, and all | three pass linkage information in the environment, and the ARGV convention | is the most efficient of the three. | [ enumeration of implementation requirements omitted ] | | The ARGS and xArgs proponents are proposing to load more code into the | runtime startup to support their proposals. [...] | How many independent count-allocate-copies does it | take to start a Gemdos process? Who cares??? How long does it take an 8Mhz 68000 to copy 1k, or even (gasp) 2k of memory, even with extra processing to parse it? Somewhere on the order of tens of milliseconds per program invocation, if that much. God forbid that we should fritter away people's valuable milliseconds in our wanton disregard of startup module code efficiency. | ----------------------------------------------------------------------- | Programs which ignore the ARGV convention for arguments end up | mis-interpreting ARGV specified arguments as environmental variables | and passing screwed up environments on to their children. | | This problem is addressed differently by the ARGS and xArgs proposals. | [ means of addressing the problem omitted ] | | In article <156@np1.hep.nl> Geert J v Oldenborgh suggested truncating | the environment after extracting the ARGV from it. I think this is | an excellent suggestion: it adds one instruction, 2 words, to the | runtime startup module and immediately cures one whole class of bugs, | the class created by MWC compiled programs doing naive Pexec()'s. Hah, I caught you! You admit that ARGV is imperfect! ;-) You are even willing to change the startup code to make it more perfect! | I have two solutions for binary programs which screw up the | environment by ignoring the ARGV standard but cannot be rebuilt | with the improved runtime startup. Both involve the same | transformation suggested above. | | Solution 1 - call the program indirectly through a second program [...] | Solution 2 - rewrite the binary of the offending program to | incorporate the environment truncation into the offending | program's runtime startup. [...] That's very nice, but the other two methods of extended argument passing don't require ANYBODY to be insulated from them. In fact, all THREE methods can peacefully coexist in one system, except that ARGV will cause problems for programs which haven't been "innoculated" against it. | ----------------------------------------------------------------------- | In summary, the ARGV convention can be validated by comparing the | ARGV received in the environment to the ARGV received by the parent; unless the parent has done anything to the environment... | the ARGV convention rides for free on Pexec() while the new proposals | both involve additional overhead; negligible additional overhead... | and it is trivial to fix programs | which pollute the environment by ignoring the ARGV convention. perhaps we disagree on the meaning of the word trivial; in any case, the other two schemes don't cause any pollution, and thus don't require any programs to be fixed... | If Atari wants MWC to discard the ARGV argument convention, I hope | they'll wait until they can find something better to replace it with. :-) | | -- rec -- If MWC wants Atari to adopt the ARGV argument convention, I hope they'll come up with some better defenses for it. >;-) ------------------------------ Date: 24 Apr 89 04:32:13 GMT From: Ken Badertscher Subject: Flow control In article <17401@cup.portal.com> BUGGS@cup.portal.com (William Edward JuneJr) writes: | Anyone know if the new TOS will support flow control? RTS/CTS flow control was fixed in Mega TOS. As far as I know, it wasn't un-fixed in TOS 1.4. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include ------------------------------ Date: 24 Apr 89 05:32:58 GMT From: Ken Badertscher Subject: Re: GEM AES/Resource Questions In article <13423@watdragon.waterloo.edu> achowe@tiger.waterloo.edu (CrackerJack) writes: | 1) How do I get the address of a string contained in a dialog in order | to change its contents? #include /* R_TREE define */ #include /* OBJECT, GRECT typedefs */ OBJECT *dial int i; GRECT rect; typedef struct _prect { int *x, *y, *w, *h; } PRECT; PRECT rectptr = { &rect.g_x, &rect.g_y, &rect.g_w, &rect.g_h }; : /* start up application, load resource, etc... */ : /* get the address of the tree containing the dialog `DIALOG' */ rsrc_gaddr( R_TREE, DIALOG, &dial ); /* put the string in the dialog object `DIALSTR' */ sprintf( (char *)dial[DIALSTR].ob_spec, "%4d", i ); /* redraw the dialog */ form_center( dial, rectptr ); objc_draw( dial, 0, MAX_DEPTH, rect ); : Make sure that the string object in your resource has MORE than enough space to handle any strings that you're going to stick into it. | 2) How do I send myself a WM_REDRAW message? >From the code you included describing how you were sending yourself the message, it appeared that you wanted to redraw the dialog when you changed the string values. It's much better to redraw the dial (as above) when you change the value of any string-type object. However, if you still want to send yourself a redraw message, try the following... (untested code off the top of my head): #include /* WM_REDRAW define */ #include /* GRECT typedef */ extern int gl_apid; /* this application's ID */ SendRedraw( whandle, rect ); int whandle; GRECT rect; { int msg[8]; msg[0] = WM_REDRAW; /* message type */ msg[1] = gl_apid; /* sender ID */ msg[2] = 0; /* buffer length (0 := 16 bytes) */ msg[3] = whandle; /* window to redraw */ msg[4] = rect.g_x; /* rectangle to redraw */ msg[5] = rect.g_y; msg[6] = rect.g_w; msg[7] = rect.g_h; appl_write( gl_apid, 16, msg ); /* tell self to redraw */ } Then, when your application recieves the WM_REDRAW message, it can do whatever redrawing needs to be done, based on the rectangle. ------------------------------ Date: 24 Apr 89 18:53:17 GMT From: Allan Pratt Subject: Re: Pexec question In article <477@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes: > In article <1927@hall.cray.com> rosenkra@hall.UUCP (Bill Rosenkranz) writes: > >i have a question on Pexec, specifically on load/nogo then go more than once. > [I have the same problem...] > ... the ability to do this would allow > people to write really HUGE accessories, but instead of eating up 200K for > the huge accessory all at once, the modules it need to run can be pexeced > when needed into an internal buffer. I will tell the net the same thing I told Bill Rosenkranz: don't try to use Pexec to load overlays. If you want to load overlays, do it some other way. For example, demand that the overlays be position-independent and load them anyplace you want. Alternatively, load them and fix them up yourself -- there is enough information in the documentation to do this. The normal startup will not work, of course, because an overlay is a fragment, not a program. Certainly, an overlay should never call Pterm(), and should not expect to have a basepage. Some programs which have multiple printer drivers, like Degas and (I believe) MicroSoft Write, use this trick. The driver is a module, not a program: the beginning of the module contains relative pointers to the externally-visible entry points. Your best bet is to load the driver code into memory and relocate it yourself (unless it's position independent), JSR to it, and have it RTS to you, and stop trying to think of it as a process. ------------------------------ Date: 28 Apr 89 18:47:42 GMT From: Allan Pratt Subject: Re: Hard drive synchronization with the ST In article <890427.09095442.063770@SFA.CP6> Z4648252@SFAUSTIN.BITNET (Z4648252) writes: > wondering if TOS 1.4 ... detects a hard drive during power up Nope. Might be a good idea, but how long do you wait? If the computer and the drive both power up at the same time, the hard drive may not reset properly. Some drives need to be allowed to do the whole power-up sequence before they can take any commands or data, even just request-sense (status) commands. On the other hand, some don't. If you put AHDI.PRG in the \AUTO\ folder of a floppy, and put another program BEFORE that in the AUTO folder which delays by 30 seconds (or whatever it takes), you could be in business without any sequencer. The ROMs will look for a hard disk, not find one, and boot off the floppy. By the time the delay has elapsed and AHDI loads, the drive is ready. Give that a try. It might not work. Warranty void if terms are violated. Your mileage may vary. You may have some other rights which vary from state to state. ------------------------------ Date: 1 May 89 20:45:36 GMT From: Allan Pratt Subject: Re: Screen Saver In article <1040@gmdzi.UUCP> kloppen@gmdzi.UUCP (Jelske Kloppenburg) writes: > I just wrote a Screen Saver Program for a friend. I used the trick to > set the Vsync to external Signal. While testing I realized, that with > Screen off (= no sync signal) the VBL Queue routines are not executed. > Is that right? > > Kloppenburg@kmx.gmd.dbp.de > UUCP: kloppen@gmdzi I'm not sure I understand your description, but if you're programming the shifter to take Vsync from an external source, and there is no external source, you can actually case MORE damage to your monitor than leaving it on. Monochrome monitors in particular don't like being turned on without any synch information: they make a noise like they're in pain, if your ears can pick it up. Here's a good chance to say NEVER LEAVE YOUR ATARI MONOCHROME MONITOR ON (for long) AFTER TURNING OFF YOUR COMPUTER. A minute or two is fine, but over the course of hours something gets hot inside and eventually your monitor dies. ------------------------------ Date: 1 May 89 20:55:15 GMT From: Allan Pratt Subject: Re: Hard drive synchronization with the ST Some people have mentioned that their non-Atari hard disks don't always auto-boot. Something came to my attention recently, and this might be part of the explanation: The boot sequence on the ST starts with a "move.w #$2700,sr" instruction (to ensure IPL 7) and then "reset" to reset external devices. Unfortunately, the "reset" instruction does not pull down reset as long as the SCSI spec requires. Furthermore, the time between letting go of the reset button and the time the "reset" instruction gets executed is too short -- that is, you get "reset" (the button is down), then "not reset" (the instructions are executing), then "reset" (the reset instruction), and the "not reset" time is shorter than the SCSI minimum-time-between-resets specification. A host adapter to a true, picky SCSI device would have to lengthen any reset it gets to the minimum SCSI length, and possibly remove the brief "glitch" it sees while the two instructions are executing. Atari hard disks can take it (or the host adapter is doing the fiddling) because, of course, they work. I regret (retroactively) that this timing problem exists. The fact that the reset instruction is too short isn't really our fault: it grounds "reset" for 124 clocks in the 68000, 512 clocks on the 68020 and 68030 (but remember, clocks are likely to be shorter). However, the too-short time between resets *is* under software control. ------------------------------ Date: 3 May 89 00:24:52 GMT From: Allan Pratt Subject: using memory (was re: A REAL RamDisk) In article <3694@nunki.usc.edu> rjung@sal61.usc.edu (Robert allen Jung) writes: > You're > uncompressing a package, and send all of the bits into the RAMdisk. Solutions like this are necessary because of problems like ARC. ARC is poorly implemented in that it reads & writes 512 or 1024 bytes at a time (as far as I know). You get HUGELY improved throughput if you read a large buffer-full of your source, decode into another buffer, and write large chunks at a time. The chunks don't have to be very big: you get dramatic improvements at 16K, and usually not much increased benefit by going up to 1M or more. Look how much faster UNARC.TTP is than the equivalent extraction using ARC. The entire difference is that UNARC reads the file in from the archive, uncompresses it, then writes the plaintext. It might not even read & write the whole thing, and I don't care; it's a hell of a lot more than 1024 bytes! The extreme example of this problem is GFA BASIC, which reads and writes text files ONE BYTE AT A TIME. That is, they use Fread(fd,1L,&c); to read a character from a file. This is ABSURDLY slow, and you end up with whole subcultures coming up with workarounds to make text file I/O reasonably fast. I know this doesn't directly address the RAMDISK problem; that's been put to bed, I think (can't resize meaningfully under TOS). My point is this: you have lots of memory; use it! ------------------------------ Date: 4 May 89 19:39:41 GMT From: Allan Pratt Subject: Re: assemblers In article <99@sdcc10.ucsd.EDU> cs163afu@sdcc10.ucsd.edu.UUCP (Some call me...Tim) writes: > MadMac in the Atari Developer's kit, for one reason: Speed. You betcha. > And if you really want it optimized--after you have it running, use > the Alcyon assembler at that point. They are completely code > compatible. They are NOT completely compatible. It is possible to write code which assembles the same (modulo optimizations) under both assemblers. However, MadMac is more strict on some points (colon after label, semicolon before comment) and AS68 doesn't have macros. Furthermore, the syntax for conditional assembly is totally different, and the behavior of "=" and "set" and "equ" might be different. MadMac has an option (-6) which lets you assemble Alcyon compiler output. It is NOT an AS68 compatibility mode; it is a C68 back-end mode. It simply ignores lines beginning with "%" and does some other things (I forget what). You can ask MadMac to inform you of unoptimized short branches, so you can go back and put ".s" on them. AS68 doesn't know about the XXXX.w addressing mode: INPUT MadMac output AS68 output ------------ ------------------------ -------------------------- lea $1234,a0 lea $1234.w,a0 (2 words) lea $00001234,a0 (3 words) Lastly, AS68 makes at least one illegal optimization. Assuming that a missing size modifier means the same as .w, the optimization move #1,d0 --> moveq.l #1,d0 which AS68 does is illegal. MadMac does moveq, addq, and subq optimization correctly. ------------------------------ Date: 9 May 89 18:32:10 GMT From: Allan Pratt Subject: Re: POWERUP HARD DRIVE/CPU SEQUENCING I give in. Please report us to the Better Business Bureau for Abuses and Criminal Neglect of Hard-Disk Start-up Sequences. Yes, we could issue the "Test Unit Ready" command to the controller, and if there's no response, then there's no controller. If there is a response, and it's negative, we can keep asking until it's positive. However, there's still a timeout -- it may be that the controller is getting power but the drive unit is not, so it'll NEVER be ready. How long do you propose we wait? At any rate, it's too late for TOS 1.4. Sorry. Use your "text file causing reboot" trick. Or, you can do it properly: ; This program causes a warm boot. ; Un-comment the clr.l for a cold(er) boot. move.l #0,-(sp) ; get into supervisor mode move.w #$20,-(sp) trap #1 ; clr.l $420 move.l $4f2,a0 ; a0 -> OS header move.l 4(a0),a1 ; a1 -> reset handler jmp (a1) ; jump there. That's a reset. That's all there is to it. No guessing, just a warm boot. If you want a cold boot, un-comment the clr.l instruction. This will run in the AUTO folder, as an accessory, or as something you can double-click from the Desktop or start from a shell. ------------------------------ Date: 11 May 89 19:46:23 GMT From: Allan Pratt Subject: Re: Preloading revised In article <1028@philmds.UUCP>, leo@philmds.UUCP (Leo de Wit) writes: > For those who might be interested, here's a demo program that preloads > some programs (whose pathnames are supplied on the command line), then > executes them. It uses the Pexec variants 3, 4 and 5 to do so. Compiled > with Lattice C. > Enjoy! > Leo. The program Leo posted should work fine. It uses Pexec 3 (load/nogo) once per program you're loading, but then uses Pexec 5 (create basepage) followed by Pexec 4 (just go) on *that* basepage (after filling it in) once per execution of a preloaded program. This is fine; nothing wrong with it at all. Excellent solution. Except for one thing: some programs expect their basepage to be $100 bytes below their text base. In fact, virtually all programs make that assumption to one extent to another, but most of them use it to determine how to Mshrink, and being off by $100 bytes won't matter. And another thing: a program which assumes any initial state for a variable in the data or BSS segment will lose, because the second time you start it the variable will have a leftover value from the previous execution. You can fix this problem by saving a copy of the initial data segment and copying it into the process before starting it again, and clearing the BSS (just the declared part; you don't usually have to clear the whole heap). If a program modifies its text segment, this'll lose, but hell, at that point it'll be quicker just to load it off a RAMdisk. Very cool idea. I might try to add some builtins to Gulam this way. ------------------------------ Date: 18 May 89 05:43:40 GMT From: J. E. Patton Subject: Becoming a developer By popular demand the following information is posted for those interested in becoming registered Atari developers. It pertains only to those located in the U.S. Atari has subsidiaries all over the world and you should contact the appropriate one for more information about becoming a developer. ------------------------------------------------------------------------ To become a registered developer you must purchase one of the following forms of the kit. $ 112.50 Documents Only $ 237.00 Above w/telephone support, online registration, hardware discounts $ 300.00 All the above plus Mark Williams C compiler. If you live in California please add 7% sales tax. Checks will be returned if tax is not included. To purchase the Developer's Kit please send a cashiers check or money order to the following address: Atari Corporation 1196 Borregas Avenue Sunnyvale, CA 94086 Attn: Developer Coordinator The Developer's Kit will be sent back to you prepaid UPS Blue. Allow two weeks from the time we receive your check. Please note: UPS cannot deliver to a P.O. Box. The actual process of getting registered relies on the developer returning a confidential disclosure form which is contained in the developer's kit. The following is a list of some of the documents in the developers kit: o Question and Answer Newsletters o Introduction to GEM programming o A Hitchhiker's Guide to the BIOS o Atari GEMDOS Reference Manual o GEM Programmer's Guide, Vol. 1--VDI o GEM Programmer's Guide, Vol. 2--AES o Still Another Line-A Document (SALAD) o Engineering Hardware Specification o Chip specifications o SFP004 ------------------------------ Date: 18 May 89 17:46:36 GMT From: Allan Pratt Subject: Re: HELP! (Damaged data) In article <3475@ihlpm.ATT.COM> jshwang@ihlpm.ATT.COM (Hwang) writes: > I have an atari 1040st. Sometimes when I try to run a program, > the disk drive (built in the st) makes a sick sound (I don't > know how else to describe it..it is not the normal rrrrrrr, > but r..r..r..r), then a banner comes up saying the data on > the disk may be damaged. The program will not run. What's happening when it goes r..r..r..r is that it's trying to read a certain sector, failing (after five revolutions), and the software "reloads the head" -- that is, it seeks track zero, then seeks back to the track where the data is supposed to be. It does this three or four times. This can happen if the disk is damaged, if the floppy's heads are dirty or damaged, and, most especially, if the floppy's heads have come out of alignment with the "ideal" for 3.5" drives. Take the machine to your dealer; s/he can open the drive, clean the heads (don't use a "head cleaner" disk; use the kind of kit that comes with Q-tip-style applicators), and realign the drive if necessary. There's a gotcha to realigning your heads: if you've been writing data to disks with misaligned heads, then you fix the heads so they're in the "standard" alignment, you might not be able to read your own disks any more! This is usually not a problem, but something to watch out for. ------------------------------ Date: 24 May 89 15:55:32 GMT From: J. E. Patton Subject: Re: Becoming a developer in article <43609a62.14a1f@gtephx.UUCP>, covertr@gtephx.UUCP (Richard E. Covert) says: > > > Thanks to Atari for sending out the info about becoming > an Atari developer, BUT (ain't there always a but :-) ), > how current are they?? Do they reflect the Mega ST, TOS 1.2 > and TOS 1.4?? How often are they updated?? How accurate are they?? > Do you still get those old Digital Research Xeroxed manuals?? > > And how much are the hardware discounts?? Can a new developer get a > break on the new 68030 TT machine?? > > Richard (UNIX hacker and eagerly awaiting the TT) Covert The currently shipping docs. contain all the updates we've made available to developers. Unfortunately the DRI manuals are still present, but ( There is always a but :) specific information about TOS 1.2 and 1.4 has been merged with more to come. Developer pricing for the TT has not been discussed ... yet, but you can understand that limited quantities of custom parts will be a factor ( I have nothing to do with setting prices, so these are MY thoughts ). ------------------------------ Date: 1 Jun 89 22:19:51 GMT From: Allan Pratt Subject: Re: ST @ 38400 baud??? In article <665@stag.math.lsa.umich.edu>, hyc@math.lsa.umich.edu (Howard Chu) writes: > [38KBaud on an ST] > It's easy. You need to call Rsconf to reset a bit in the UCR, then you need > to reset the baud rate timer... Basically, when you use Rsconf to set the > baud rate of the serial port, it always puts the UART in divide-by-4 mode. > Reset that to divide-by-1, then you need to set the correct counter values > in the timer [yes, it's Timer D] to get the > baud rate you want. You can calculate them pretty easily... Actually, the UART is in divide-by-16 mode, not divide-by-4. Timer D is running as fast as it can; *that* is where the divide-by-4 comes in. If you change the bit in the UART to divide-by-1, you disable certain synchronization logic in the UART and reliability goes down the toilet. Talking to my VAX at 9600 with this trick, there is lots of noise. 19.2 is the pits, and I've hooked up two STs at 38 and it's unusable (too many glitches). If you can do it and are satisfied with the results, more power to you. Personally, I would consider leaving the UART at divide-by-16 so the synchronization logic works, and placing a different clock on the 68901's baud-rate inputs instead, but that involves finding a clock and running a jumper, and makes the baud rate nonprogrammable. (Just don't put a different clock on the 68901's CLOCK input, since that controls all the timers; there isn't a separate Timer D input.) ------------------------------ Date: 2 Jun 89 18:50:26 GMT From: Allan Pratt Subject: Re: Critical error handler In article <757@sbsvax.UUCP> roeder@sbsvax.UUCP (Edgar Roeder) writes: > You can install a normal C-routine as the error handler. But you can only > call Bios-functions for terminal output, since the handler may be called > from a GEMDOS-function and since GEMDOS is not reentrant (*), you can't use > GEMDOS-functions like Cconout() (and most printf()'s in C-Compilers). > > (*) GEMDOS is not reentrant when called by the Bios because it uses a static > (and undocumented (!)) storage location for the return address when it calls > a Bios-function like for example Rwabs() from inside Fwrite() which > eventually calls the critical error handler. Give me a break! GEMDOS is not reentrant for more reasons than that! And you don't expect us to document EVERY VARIABLE that GEMDOS uses, do you? GEMDOS is not reentrant because (A) it sets SSP to the same address every time it's called, and (B) it uses the basepage of the current process to store the context (the registers, incl. PC). If you make a GEMDOS call from within a GEMDOS call, the second one overwrites the stack of the first one and overwrites the first caller's context. NOw that's what *I* call non-reentrant! Given those two reasons, finding other reasons for non-reentrancy in GEMDOS is little more than vanity or folly. ------------------------------ Date: 5 Jun 89 18:46:31 GMT From: Allan Pratt Subject: Re: Rsconf in TOS 1.4 In article <374*hofer@urz.unibas.ch> hofer@urz.unibas.ch ("Remo Hofer") writes: > Some documentation about TOS 1.4 says: > Rsconf(-1,-1,-1,-1,-1,-1) does return the old values of USART registers. > (That was true for all TOS versions, but wasn't documented) > Rsconf(-2,-1,-1,-1,-1,-1) does return the old value for the baud rate. > (That is only true for TOS 1.4) > Does this mean that you can inquire all settings of the RS232 except > the setting of the handshake? I think, it would be nice, if we could inquire > the handshake settings. Any comments? Maybe somebody at Atari? > > Remo Hofer > hofer@urz.unibas.ch > > ---------------------------------------------------------------------------- That would have been a good idea, but it's too late for TOS 1.4. Sorry. I regret that so much of TOS is done piecemeal, and I regret further having contributed to that, but that's the way it is sometimes. ------------------------------ Date: 6 Jun 89 22:47:41 GMT From: Ken Badertscher Subject: Re: TOS environment In article <1232@infbs.UUCP> hafer@infbs.UUCP (Udo Hafermann) writes: | What is the TOS variable 'the_env' (at 0x4be) used for? The documentation | says it is an evironment pointer and is 0L. Does any software use it? The system variable the_env is currently not used by the OS, but is reserved for use by Atari. It is documented as a "null environment; four bytes of 0." Back in the dark ages of TOS, before the environment started getting set up later on in system startup, these four bytes were a convenient place for GEMDOS to pick up a null environment string. It's done differently these days, but the cruft of the_env is still lying about. If you're looking for low memory space to put something, there are much better places than at the_env. Please don't use it. I don't know of any software that uses it currently. I am still planning (someday) on releasing the DA/program environment-setter that I have put together, and as system software, I may have it use the_en for something meaningful. If I do, I'll be sure to document its purpose far and wide. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include ------------------------------ Date: 6 Jun 89 23:48:51 GMT From: Allan Pratt Subject: Re: Revolver/19.2K baud/awards In article <8906050250.AA22171@ucbvax.Berkeley.EDU> 01659@AECLCR.BITNET (Greg Csullog) writes: > 2. Alan Pratt says that 19.2K is the pits on the ST. Nonsense. > > 3. Since Atari folks read and respond to various items on the net, why > haven't I heard anyone from Atari respond to my idea about awards for > best PD and commercial software to reward ST code developers? Is Atari > selectively deaf? 2. I said 19.2K is the pits when you put the MFP in divide-by-1 mode. This is true, and it's true because the clocks on two machines won't be exactly in synch. See the discussion of 38KBaud on ST for more about this. When you use the normal 19.2K set up by Rsconf, you're fine. 3. With the signal/noise ratio on the net, you should be more surprised that something DOES get a response than that something DOESN'T. We can't take the time to respond to everything; as far as management is concerned, netnews is somewhere between a perk and a necessary evil. It's a huge time-sink with only minor payback. ------------------------------ Date: 6 Jun 89 23:06:03 GMT From: Ken Badertscher Subject: Re: WHICH TOS? The best way to visually determine what TOS version you're running is to look at the copyright date in the "Desktop Info..." dialog. Here at Atari, we like to call the versions by name; the first TOS release is "ROM TOS" and it has a copyright year of 1985. The TOS that was put into the Mega computers is "Mega TOS" (we would call it "BLiT TOS", because the only major difference from ROM TOS is BLiTTER support, but that name is used by some German developers to refer to the hacked-up TOS ROM that works with a 68020). Mega TOS has copyright 1986,1987 in the Desktop Info dialog. When TOS 1.4 becomes available to the general public, it'll be pretty obvious from the Desktop Info box what its name should be. As far as dates go however, it's copyright 1985,86,87,88,89. Unfortunately, there are so many versions of TOS 1.4 floating around on BBS's, being sold by Atari Dealers (yes, it's true *sigh* -- illegal and bug-ridden copies of Beta Test ROMs are being foisted off on unknowing Atari customers by a few money grubbing dealers), and available from other channels that it might be worthwhile to have a "version-checking program" so that people can know what TOS version they're actually using. This program could be useful to the majority of honest dealers out there so they can prove that they've got the "real stuff" ;-) and it could be a benefit to the wary customer. ------------------------------ Date: 7 Jun 89 22:59:51 GMT From: Ken Badertscher Subject: Re: WHICH TOS? In article <801@orbit.UUCP> steve@pnet51.cts.com (Steve Yelvington) writes: | The Sversion() Gemdos function allegedly provides this information, but on my | STFM it returns a value of 0.19. Does anybody know whether Sversion() really | works? Hmm, Sversion is returning a float value? Hmmm... ;-) Sversion() returns the GEMDOS version number, not the TOS version. The GEMDOS version number for your machine should be 0x1300 (our version numbers are all WORD values); I'm not sure how you get 0.19 from that, but... In any case, the TOS version number is in the OS header. To get the TOS version number, use the pointer to the OS header (sysbase) at 0x4f2. The TOS version number is the second word of the OS header. Offsets for the rest of the stuff in the OS header is documented in the Hitchhiker's Guide to the BIOS. The Pexec Cookbook also has a small section on GEMDOS/TOS version numbers. To add to the version number confusion, the AES has its own version number too (returned in global[0] on appl_init)! For those with a furniture fetish, here is a table: Versions ============== ROM TOS Mega TOS ------- -------- ------- $0100 $0102 $0104 TOS version (from the OS header) $1300 $1300 $1500 GEMDOS version (from the Sversion call) $0100 $0120 $0140 AES version (from global[0] after appl_init) Can you now see why we don't like to give OS releases specific version numbers? ;-) ------------------------------ Date: 8 Jun 89 19:00:58 GMT From: Allan Pratt Subject: Re: Revolver/19.2K baud/awards In article <37800008@hpbbrd.HP.COM> marcog@hpbbrd.HP.COM (Marco Gommersbach) writes: > / hpbbrd:comp.sys.atari.st / 01659@AECLCR.BITNET (Greg Csullog) > > I cannot disable REVOLVER's loader on boot up by holding > > down the LEFT SHFT-ALT combo like the manual says. Has this feature been > > disabled? (HISOFT BASIC's info program says I have ROM version 1.2) This smells a lot like another case of being B.A.D. (Broken As Designed). There is a perfectly legal and compatible way to find out what shift keys are down: use Bioskeys(-1). However, some developers use the address in RAM where the BIOS keeps this information, without regard for the fact that the address is not published and changes from ROM to ROM (as you have discovered). ------------------------------ Date: 12 Jun 89 18:39:05 GMT From: Allan Pratt Subject: Re: TOS In article <8906090105.AA10969@ucbvax.Berkeley.EDU> WOODALLP@VAX1.BHAM.AC.UK writes: > I have seen mention of TOS 1.0 and TOS 1.2, in Britain I have not seen > any mention of these numbers [...] Sversion() only gives the version number for GEMDOS, and that didn't change between original ROMs and Mega ROMs. The TOS version number is available as the second word of the OS header, whose address can be found at _sysbase, $4f2. Original RAM TOS and also original ROM TOS were both 1.0 (regrettably), but since RAM TOS is no longer supported this isn't a big deal. Mega TOS was 1.2 (with more changes than you think), and the new TOS (available now to USA developers -- write J. Patton at Atari for info) is 1.4. By "x.y" I mean the first byte of that word is x and the second one is y. NEVER NEVER NEVER use an absolute address like $FC0000 because if we ever move the ROM start address (HINT HINT) your program won't work! The only absolute addresses in any TOS program should refer to published system variables or hardware things like interrupt vectors. ------------------------------ Date: 13 Jun 89 00:09:53 GMT From: Ken Badertscher Subject: Re: Flow control in TOS 1.4 In article <43ad1ca2.14a1f@gtephx.UUCP> covertr@gtephx.UUCP (Richard E. Covert) writes: | Does anyone know if Atari ever fixed the flow control problem in | the last Developer's RAM version of TOS 1.4?? I recently purchased | a new US Robotics 9600 baud modem which will go as fast as 14,400 buad | BUT it requires flow control. | | I am told that the USR 9600 HST modem runs at the higher speed just fine | on a Mega ST using TOS 1.2. But, it doesn't work with the Dec 1988 | disk-based TOS 1.4. Whoever told you the above was confused. Nothing in the flow control has changed since Mega TOS. There was a problem with flow control in the original ROM TOS. It didn't work at all. That was fixed in Mega TOS. ------------------------------ Date: 13 Jun 89 02:29:45 GMT From: Ken Badertscher Subject: Re: Pexec() and shel_write() The current incarnation of shel_write is only useful to chain to another program when you are run from the desktop. If you need to run programs which chain via shel_write from a shell program, the shell program must intercept trap #2 and look for shel_write calls, and handle them itself. This is precisely the same problem NeoDesk was having. In my opinion, the solution of having a "shel_write patch" program in your computer all the time is suboptimal. All that is necessary is for the "shell" type program to perform the shel_write calls itself via Pexec. That's all the AES does when a program uses shel_write to chain to another program. Rather than restarting the desktop, the AES shell Pexecs the program whose name was shel_written. This and other sticky shel_stuff will be covered by the forthcoming (yeah, it's been forthcoming for about 6 months now, so sue me...) shel_games document. ------------------------------ Date: 13 Jun 89 04:16:37 GMT From: Ken Badertscher Subject: Re: versions In article <865@stag.UUCP> to_stdnet@stag.UUCP writes: | kbad@atari.UUCP (Ken Badertscher) writes ... | | > Hmm, Sversion is returning a float value? Hmmm... ;-) | | No, I'm not *that* silly. [source code omitted...] Of *course* you aren't. *I* was being silly (note the smiley above... ;-). | ... basing the above on the Sversion() documentation in Pollack & Weber's | "Atari ST Application Programming," which says in part: | "The high byte contains the minor version number and the low byte | the major version number." Oh my, I stand corrected. That documentation is corroborated by the GEMDOS documentation, which says that Sversion returns the GEMDOS version number "in byte-reversed format." Don't ask me why it's like that... In fact, the Pexec Cookbook is incorrect in this regard, it states that the high byte is the major version number. According to the GEMDOS bible, the high byte is the MINOR version number. So byteswap it before doing any version dependancy tests. | Heh... what IS the new version of TOS going to be called, Ken? | Besides late, I mean. :-) My lips are sealed until the general ROM release. WhoKnowsWhen. ------------------------------ Date: 13 Jun 89 01:32:48 GMT From: Ken Badertscher Subject: Re: Communicating with Desk Accessories In article <507@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes: | what happens to this accessory when you switch resolution. what i've been | able to trace myself is that the accessory will get an AC_CLOSE message, | but what is it supposed to do with that?? | | the reason why i'm asking is that only the accessories that i've written | end up eating memory everytime you switch resolutions. the memory that is | eaten is equivalent to the size of the accessory! (not a good situation to | say the least). An AC_CLOSE message means that any resources that your accessory has open are about to go away. Namely, any open files will be closed, Malloc'ed memory will be released, etc. Anything that your accessory sets up while a program is running has a potential for vanishing when the program terminates. AC_CLOSE is the system's way of warning accessories about programs terminating. As far as memory-gobbling is concerned, this is unfortunately how the system works. Whenever you switch resolutions, accessories get re-loaded, and the old ones just hang around using memory. This is a side effect of the way the AES treats res changes: not-quite- a-warmboot. Offhand, I can't think of any quick and easy ways around it. I usually use warmboots to switch resolution ;-). ------------------------------ Date: 13 Jun 89 16:25:06 GMT From: Kenneth Soohoo Subject: Re: Mark Williams C In article <381@laas.laas.fr> ralph@laas.laas.fr (Ralph P. Sobek) writes: > >Since the previous postings were discussing what one complier supports >or does not support, I have a simple question. > >Is it true that MWC does not support the IEEE floating point standard? >Is it in the queue? According to our local ST mag (precisely: ST >Magazine), they stated that MWC uses the DEC standard. > Yes, Ralph, MWC _does_ support the DEC format, which isn't a heck of a lot of help with the MC6881 floating point co-processor board, which uses IEEE standard floating point. As far as _I_ know, MWC has plans to support IEEE in the near future (i.e. "we're working on it, OK???"). You should check out, oh, any number of other compilers if you _really_ need IEEE... Aztec, Alycon... ;-) Oh, and regarding the expansion bus which the '881 sits on in a Mega, it'd be _really_ hard to make the equivalent slot for a 520/1040 style machine, sorry. ------------------------------ Date: 13 Jun 89 21:23:11 GMT From: Ken Badertscher Subject: Re: Version Number Confusion In article <5440035@hplsla.HP.COM> andyc@hplsla.HP.COM (Andy Cassino) writes: | | | | Unfortunately, most software checks the version | | date. For example, the ICD hard disk driver knows about the Beta ROM date, | | but fails to recognize my 1.4 version, which is dated Feb 22, 1989. | | | | Yikes! Does this mean that my ICD host adaptor won't work with TOS 1.4 until | I get a new rev of ICDBOOT??? ICD did A Bad Thing. Actually 2 bad things. First, they shouldn't have released ANY software that relied on ANY Beta TOS releases. All developers who got early releases of the latest TOS were warned and foresworn not to base any software on any features of the intermediate release; we sent it out to allow them to test their existing software. DON'T BASE ANYTHING IN YOUR SOFTWARE ON INTERMEDIATE OS RELEASES. Second, they shouldn't have based anything on the date of the TOS ROMs. As I have said before, there are three supported OS releases; ROM TOS, Mega TOS, and the one that is forthcoming. Each has a different OS version number in the OS header. ROM TOS and Mega TOS have the same GEMDOS version number, because GEMDOS didn't change between those OS revisions. What's worse, dates in the OS header will vary from country to country, so by checking OS header dates, you not only make your software version dependant, you make it country dependant as well. USE THE OS VERSION NUMBER, NOT THE OS DATE, IF YOU MUST CHECK OS VERSIONS. 'nuff said. ------------------------------ Date: 16 Jun 89 03:19:33 GMT From: Ken Badertscher Subject: Re: Mark Williams C In article <211@nikhefh.hep.nl> n62@nikhefh.hep.nl (Klamer Schutte) writes: | In article <1557@atari.UUCP> kens@atari.UUCP (Kenneth Soohoo) writes: | >You should check out, oh, any number of other compilers if you _really_ need | >IEEE... Aztec, Alycon... | | Or you can try TURBOC... Or you can use Laser C. Laser supports IEEE format reals, and the software FP libraries are very very fast. Megamax has recently added 68881 support in their FP libraries, too! ------------------------------ Date: 16 Jun 89 03:25:46 GMT From: Ken Badertscher Subject: Re: v_dspcur In article <6038@ka3ovk.UUCP> lake@ka3ovk.UUCP (Marshall Lake) writes: | I'm having trouble getting v_dspcur() to work at all. [...] | The fix was supposed to | be in an auto program provided with the European ST Tour ... but this | fix doesn't seem to be the trick. The patch program you're referring to was a fix to appl_tplay, which didn't work correctly in the ROM TOS release. Appl_tplay was fixed in Mega TOS. I'm not sure about v_dspcur(), but I seem to remember something odd about it... I believe you have to call the function twice in order to get it to work (don't ask me why!). Luck... ------------------------------ Date: 15 Jun 89 18:14:22 GMT From: Allan Pratt Subject: Re: TOS In article <2637@brahma.cs.hw.ac.uk> neil@cs.hw.ac.uk (Neil Forsyth) writes: > In article <1550@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: > >NEVER NEVER NEVER use an absolute address like $FC0000 because if we > >ever move the ROM start address (HINT HINT) your program won't work! The > >only absolute addresses in any TOS program should refer to published > >system variables or hardware things like interrupt vectors. > > Your not thinking of moving the I/O addresses are you? Sorry, you're right, the I/O space is definitely nailed down. That is, any machine with, say, a Mega-style real time clock will have that clock chip address at the same place as on a Mega. That goes for all I/O devices: if the hardware acts like an ST, it'll address like an ST. Things which aren't in future machines will, of course, not be there, and nothing funny will address at the same place. Things which are different will address at a different place. Things which are both the same and different (i.e. new features, but have a compatibility mode) will address both ways. ------------------------------ Date: 16 Jun 89 20:42:11 GMT From: Ken Badertscher Subject: Re: Minix, ST, and forking... In article <632@lzaz.ATT.COM> hcj@lzaz.ATT.COM (HC Johnson) writes: | Finally, If a blitter was used to copy in the active parent/child, this | would become even faster on the ST. Not necessarily. Depending on how much context needs to be switched, the overhead of setting up the hardware blit could actually slow the process of context switching. Be wary of the tendency to treat the BLiTTER as a panacea for speed problems. The 68000, when treated right, can be quite speedy. The Atari BLiTTER was designed primarily to aid with graphics processing. ------------------------------ Date: 16 Jun 89 20:17:46 GMT From: Ken Badertscher Subject: Re: Setting the seek rate In article <8906151157.AA03321@ucbvax.Berkeley.EDU> ONM07@DMSWWU1A.BITNET ("Julian F. Reschke") writes: | I wonder if there is a LEGAL way to set the current seek rate (for using | 5 1/4''-drives...). What happened to the function Getdsb() in the | original DR-Gemdos? The newest TOS adds the Floprate() xbios call which does just that. For earlier TOS versions, it is necessary to use the undocumented BIOS dsb locations. These will be described in the documentation that comes with the new TOS. Atari has also released a program (I believe it is called PCF554.PRG, because it was released to support the Atari PC external drives), available on several online services and probably from Atari Customer Relations, which sets the correct seek rate for using the PCF554 as drive B. The Getdsb() call (if it existed) would have given you a different dsb than the BIOS dsb. GEMDOS also has a dsb, which is actually only an extension to the bpb that you get from Getbpb(). The function went away apparently because whoever was working on GEMDOS at the time felt it was redundant. ------------------------------ Date: 16 Jun 89 18:02:30 GMT From: Allan Pratt Subject: Re: TOS In article <4601@ttidca.TTI.COM> woodside@ttidcb.tti.com (George Woodside) writes: > In article <1550@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: > ...[edited] > >Sversion() only gives the version number for GEMDOS, and that didn't > >change between original ROMs and Mega ROMs. The TOS version number is > >available as the second word of the OS header, whose address can be > >found at _sysbase, $4f2. > > The GEMDOS version is changed with the release of TOS 1.4, I see from > and earlier posting. > > So, when software wishes to take advantage of TOS 1.4 features (such as > the improved file selector), should the feature be enabled via the > Sversion call, or a check of the OS header? > -- > *George R. Woodside - Citicorp/TTI - Santa Monica, CA > *Path: ..!{philabs|csun|psivax}!ttidca!woodside You should use the version number appropriate to what you're up to. If you want to know if you have the new file selector, you definitely should NOT check the GEMDOS version number. AES and GEMDOS are not inseparable. Check the AES version number (it has one) or the OS version number (described above). You could check the GEMDOS version number to see, for example, if a Dfree() call will take all day or not (old ones do, new ones don't). It is possible to have new GEMDOS but not new anything else (e.g. with a RAM-loaded GEMDOS, currently only used for internal development). It's best not to tie unrelated things, like the GEMDOS version number and the file selector, together. ------------------------------ Date: 16 Jun 89 20:00:29 GMT From: Ken Badertscher Subject: Re: Communicating with Desk Accessories Desk accessories eating memory on resolution changes is a mystery to me. I haven't witnessed the phenomenon myself, because I've never looked (I don't switch res very often). I have no idea why some DA's exhibit this behavior and others don't. To cover other questions brought up recently, though - Because a desk accessory is *not* a process, it does not own memory it allocates or files it opens. GEMDOS doesn't know about DA's, so when a DA allocates memory or opens files, GEMDOS assigns ownership to the DA's parent process. What this means is that if a DA allocates memory while an application is running, that memory will be freed out from under the DA when the application finishes. If a desk accessory needs memory that won't be treated like this, it must allocate that memory before it goes into its main event_multi loop. That way, the allocated memory belongs to the AES shell, which is actually the pseudo-process to which all DA's belong. Memory allocated in this way won't be freed until a resolution change or reboot. The only thing a DA needs to free on an AC_CLOSE message is memory it has allocated or files it has opened during the main event_multi loop, because it is possible that such memory/files actually belong (as far as GEMDOS is concerned) to the application that is about to terminate. ------------------------------ Date: 19 Jun 89 17:14:07 GMT From: Allan Pratt Subject: Re: Open Files at AC_CLOSE In article <1158@gmdzi.UUCP> kloppen@gmdzi.UUCP (Jelske Kloppenburg) writes: > What about an open file? Is the file already closed when the AC_CLOSE > comes or have I to close it? And when may I reopen it? Unfortunately, there is a lot of confusion about how the various parts of the OS interact, especially with respect to desk accessories. One crucial thing to remember is that desk accessories are meant to be like the Control Panel or a calculator or something -- you open them, use them, and close them. Desk accessories which do things in "background" are an extension to this concept, and much trickier. For one thing, a desk accessory is not a separate GEMDOS process, though it is a separate AES application (it has a separate AP_ID (doesn't it?)). The things which AES handles, therefore, are pretty well dealt with when it comes to desk accessories. But GEMDOS simply doesn't know the difference between the mainline application and the accessory. There is [conceptually, at least] a sentence in the GEMDOS documentation which says, "All of a process' open files are closed when the process terminates, and all the memory it owns is freed." What it doesn't say is that files opened by a desk accessory (and memory allocated by it) are considered owned by the mainline process, so when the mainline process terminates, they are closed (freed). Therefore: DESK ACCESSORIES SHOULD NOT OPEN FILES OR ALLOCATE MEMORY WHEN THERE IS ANY CHANCE OF THE MAINLINE PROCESS TERMINATING. The Desktop never terminates, and it's the mainline process when your desk accessory starts up, so it is safe to open files and allocate memory when you start up, BEFORE YOU MAKE ANY AES CALLS (including registering yourself in the Desk menu). However, not all processes which run are AES processes, so you can't count on getting AC_CLOSE before process termination. What *is* safe for the event-driven part of your accessory, however, is to open a file and/or allocate memory, do some work, then close/free what you opened/allocated, without making any intervening AES calls. If you don't make any AES calls, you'll never stop running, and the mainline never gets a chance to terminate. This is not safe for any interrupt-driven part of an accessory; that's a totally different kettle of fish. In the specific case of the serial-to-disk accessory, I recommend allocating a buffer when you start up, filling that buffer at interrupt level or with AES events (esp. if you will never run any non-AES programs). Then, when the buffer is full, you can open a file, write the buffer to it (even append the buffer to it) and close the file, all at once, without ever giving the mainline a chance to terminate. I hope this clears up some of the remaining confusion about desk accessories. ------------------------------ Date: 20 Jun 89 04:22:33 GMT From: Ken Badertscher Subject: Re: Setting the seek rate In article <8906191106.AA27714@ucbvax.Berkeley.EDU> ONM07@DMSWWU1A.BITNET ("Julian F. Reschke") writes: | Is there a officially approved method to determine wether the TOS 1.4- | enhancements to the AES are present Yes, use the AES version number returned by appl_init in the first word of your application's `global' AES array. | (knowing that there IS an | implementation of GEM 2.1 from a dutch company, that doesn't know | about wind_new and fsel_exinput)... We are not, nor can we be reasonably expected to be, responsible for third party replacements for parts of TOS. It is their responsiblity to "follow the rules," not vice versa. | Equally, IF one day there is an Atari-GEM <= 2.1, will it have the | enhancements from PC-GEM (menu_unregister, Accessories with menus etc.)? TOS and PC-GEM are divergent as of the first release of TOS. Of course we shall endeavor to be as compatible as we can with the newer GEM versions, but TOS is not PC-GEM. It is mostly compatible in terms of the programming interface - but TOS has some enhancments over PC-GEM and vice versa. We shall continue to do our best to add whatever enhancements ST users request, within reason. ------------------------------ Date: 23 Jun 89 20:27:27 GMT From: Allan Pratt Subject: Re: Open Files at AC_CLOSE In article <599@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes: > There are a lot of other potential "GEMDOS state" related things > to consider, like changing directories or wiping out the Fsfirst() > (DTA) buffer. This could really screw up the "real" GEMDOS process > if the ACC doesn't restore things. > > Do I hear you saying "Nah, that probably won't ever happen?" No, you heard someone say, "If you change something, change it back before you let the mainline program run!" The current directory and DTA address can both be saved, changed, and restored before making any AES call (AES can only change tasks during AES calls). And in the serial-to-disk application I was talking about, you should allocate the memory at accessory-start time, and do the open-write-close when you need to, without giving the mainline a chance to terminate during this procedure. By allocating your buffer at the start of the world (mainly, when the Desktop is the current process, because the Desktop never terminates) you know there'll be enough. Yes, there might not be any handles available when you want one, but that *is* unlikely. ------------------------------ Date: 4 Jul 89 04:03:31 GMT From: Ken Badertscher Subject: Re: Is GDOS home? wesw@ozvax.WV.TEK.COM (Wes Whitnah) writes: | Would someone please tell me of a way that an application can | _reliably_ tell if GDOS is resident (without killing the program!)? Do a trap #2 with d0 set to -2. If the trap call returns to you with d0 still equal to -2, GDOS is not there. ------------------------------ Date: 4 Jul 89 04:29:01 GMT From: Ken Badertscher Subject: AES things to_stdnet@stag.UUCP writes: | From: stag!thelake!steve@bungia.mn.org (Steve Yelvington) | 89Jun24 9:37 pm from Ian@The Vale (We have returned!) | [...] | About that Usenet message from Ken B. concerning AC_CLOSED messages and | freeing up memory/file handles from within an accessory... I did a little | playing with the concept recently, and it seems like you get the AC_CLOSED | message **after** then main application has been Pterm'd by DOS. Desk accessories get AC_CLOSED messages when an application calls appl_exit. That's the only time the AES sends AC_CLOSED messages. Of course, if an application has already terminated, it can hardly be calling appl_exit ;-). The desktop itself also calls appl_exit on a resolution change and just before* an application is launched (to tell the AES that it is exiting). The AC_CLOSED messages that the desktop sends to accessories don't mean that they're going to lose anything, because the desktop never really terminates as such (except on a resolution change). | Speaking of GEM and DRI docs... Here's one for you: During form_do() | (dialog) processing, if the user double-clicks on an object defined as | TOUCHEXIT, the object index of the exit object as returned from form_do() has | the high bit set. Yup. If you don't care about double click reporting, always lop off the high bit of the return from form_do before using it as an object index! ------------------------------ Date: 10 Jul 89 17:41:16 GMT From: Allan Pratt Subject: Re: legal way to find SPECIAL addresses pvf@bridge2.ESD.3Com.COM (Paul V. Fries) writes: > I need to know a "legal" way to determine the locations of > the GEMDOS mouse variables. I have a mouse trapping > program that was written for the particular ROMS that are > in my 1040ST. As we all know, TOS 1.4 will soon be here. > I want to fix up the program to be more general so I don't > get bitten when the new TOS arrives. You can do this legally, but you might not be able to do it from the AUTO folder, and you can't do it legally the way you describe (linking into the trap and clobbering the Y movement value). What you should do is use the VDI exchange-mouse-movement-vector call. It will have the same effect as you describe, but will be legal. Another way is to use the negative Line-A variables... If you're a developer, get SALAD (Still Another Line A Document). If you aren't, then you should become one because you get cool stuff like Landon Dyer's assembler, my linker, my debugger, and SALAD. ------------------------------ Date: 14 Jul 89 17:55:37 GMT From: Ken Badertscher Subject: Re: timer C ignac@electro.UUCP (Ignac Kolenko) writes: | does GEM not like it if you screw around with the 200Hz system timer?? It does not indeed. If you turn off the 200Hz timer for any length of time, the AES gets very confused. The AES uses it to time mouse double- clicks, and even to do dispatching between accessories and the main application. If you're going to turn off the 200Hz timer for very long, you need to "feed" ticks to the system to be sure that the AES doesn't lose its mind. This is documented in the Hitchhiker's Guide to the BIOS. ------------------------------ Date: 16 Jul 89 18:29:29 GMT From: Ken Badertscher Subject: Re~2: legal way to find SPECIAL addresses uace0@uhnix2.uh.edu (Michael B. Vederman) writes: | Speaking of mouse movement and the such... Is there a way to *prevent* the | AES from getting mouse clicks at the desktop? In other words, can one turn | off mouse packet handling to AES? Like taking over the AES mouse handler? | Unfortunately, the AES mouse handler is not at all documented (VDI, yes). If you take the VDI mouse handler, *after the auto folder*, then you've got it. The AES gets clicks from the VDI mouse handling chain, you may feed clicks to the AES or not, as you choose. You have to be careful _when_ you take and give mouse clicks (or mouse movemement) because the AES has several state variables that you can't get at, and it may be in the middle of giving someone a double click, or it may restore an internally saved mouse position when you don't expect it. ------------------------------ Date: 21 Jul 89 10:05:41 GMT From: Ken Badertscher Subject: Re: Quick-ST ignac@electro.UUCP (Ignac Kolenko) writes: | hmmm, i never heard of the ST's roms at addresses other than the regular | addresses. nothing we can do about that. yell at atari :-) :-) And Atari will yell right back at you! >:-> There is a perfectly legal and documented way to get the base address of the ROM if you really need it. Which you shouldn't, for almost all applications. A pointer to the OS header is located at $4f2; the structure of the OS header is documented in the Hitchhiker's Guide to the BIOS (contact Gail Johnson at Atari 408/745-2568 for information on how to get ST developer documentation). ------------------------------ Date: 21 Jul 89 22:16:47 GMT From: Ken Badertscher Subject: Re: Tiny screen; large border calengr@cory.Berkeley.EDU (California Engineer Magazine) writes: | My Atari 520ST is over three years old now, but I just | realized that my screen size is much smaller than the | monitor's screen size. That's right, and there's a reason for it. The monitor is adjusted at the factory that way so that it has a 1:1 aspect ratio. That way, when you draw a circle on your monochrome screen, what you see really looks like a circle. And when the VDI drivers draw graphical text, the characters can be scaled so that what you see is the actual size of what you get, and not distorted. ------------------------------ Date: 26 Jul 89 16:31:45 GMT From: Allan Pratt Subject: Re: DOES TOS 1.4 DO THIS? UUCJEFF@ECNCDC.BITNET writes: >One thing there seemed to be no mention of, while TOS 1.4 formats disks >100% compatible with MS DOS, does it also flag bad sectors so you can use >a disk with bad sectors (as in MS-DOS)? >i.e. in format, file copy, and disk writes. TOS has always marked bad sectors when formatting, in exactly the same way that MS-DOS does. No other operation marks bad sectors, under either TOS or MS-DOS, except perhaps a utliity which does that explicitly. This is a good time for the reminder that TOS 1.4's desktop format operation is MS-DOS compatible, but other programs which format disks are not necessarily compatible. ------------------------------ Date: 26 Jul 89 16:35:44 GMT From: Allan Pratt Subject: Re: Hard Disk Auto Boot Bypass hcj@lzaz.ATT.COM (HC Johnson) writes: >For 2 years I have auto booted off a hard disk. >I have used the Bypass program by Small in Start magazine to save me >when the /auto or .acc program went bad and the system wouldnt boot. Why did you need that? I'm not quite sure of all the oldest versions, but most Atari hard disk drivers let you avoid booting from the hard disk by holding down the "Alternate" key. You can't do this too soon -- you have to do it after the keyboard's initialized. The procedure is to turn on your machine and wait for the floppy disk's access light to come on (the first time). Then hit the Alternate key and don't let go until you see the Desktop. The hard disk shouldn't have booted. This is a feature of the hard disk driver, not the ROMs, so a hard disk made bootable by something other than HINSTALL may not have this feature. Also, like I said, the very oldest bootable hard disk driver might not have it. ------------------------------ Date: 31 Jul 89 17:38:02 GMT From: Allan Pratt Subject: Re: Mega ST EPROMS schuster@dasys1.UUCP (Michael Schuster) writes: >What are the EPROM equivalents for the 1 megabit ROMS used in the >Mega ST (the ones with two of the six sockets filled)? Evidently, there aren't any. It's a pain the the rear for us, too. ------------------------------ Date: 31 Jul 89 17:35:44 GMT From: Allan Pratt Subject: Re: DOES TOS 1.4 DO THIS? ignac@electro.UUCP (Ignac Kolenko) writes: >if it has always marked bad sectors, why does the desktop stop and say that >the disk is unusable sometimes, and other times it finished a format ... If there are too many bad sectors, or if Track 0 of the disk is bad, you get the "unusable" message. I forget how many is "too many." As for writing to these bad sectors, it shouldn't happen. If it does, perhaps the sectors in question are marginal: they formatted ok but subsequent accesses were bad. It's also possible that I'm totally wrong and old TOS didn't mark bad sectors correctly. What version are you using? (Original) TOS 1.0 or (Mega) TOS 1.2? After a format of a disk with "known bad sectors" try looking at the FAT. Are there any entries (after the first two) which are not $000? $FF7 is the bad-sector mark, I think. The alert after the format should show the size of the disk after accounting for bad sectors and the two unused clusters at the end of the disk. (Don't open that can of worms, please!) ------------------------------ Date: 1 Aug 89 18:25:46 GMT From: Kenneth Soohoo Subject: <> TO ANYONE DEVELOPING DESK ACCESSORIES: Don't use Fsfirst()/Fsnext() without first setting the DTA to your own local buffer area using Fgetdta() and Fsetdta()!!!!!!!! If you're a Desk Acc, you'll be overwriting the desktop's DTA, and you never know what that can do to your desktop... Now, once you're done with your Fsfirst() and Fsnext()ing, be sure to restore the DTA to it's old value!!! That _too_ can cause problems... SAMPLE CODE: (Using MWC 3.0.6 Bindings. In some compilers "DMABUFFER" is "DTA". In any case, it's a 44 byte buffer that contains usefull info about file searches.) int err; DMABUFFER *oldbuff, newbuff; oldbuff = Fgetdta(); /* Save old DTA for later */ Fsetdta(&newbuff); /* Tell GEMDOS about OUR buff */ /* Insert Fsfirst() and Fsnext() calls here... err = Fsfirst("*.*", 0); /* First DTA fill */ while (err == E_OK) { /* Process DTA */ err = Fsnext(); /* Fill DTA again */ } */ Fsetdta(oldbuff); /* Restore for desktop's use */ Hope this helps... ------------------------------ Date: 11 Aug 89 17:36:54 GMT From: Dan Scott Subject: Re: HDX301 in article <890807.19362146.008300@SFA.CP6>, Z4648252@SFAUSTIN.BITNET (Z4648252) says: > > > Could some kind soul please send to me the HDX utilities version 3.01? > There is no GEnie or CompuServe node here and I noticed that HDX301.ARC > was available in the GEnie listings. > Send to my listed E-MAIL address. > Many thanks! > > Larry Rymal in East Texas The ARCed set of the new utilities is also available on the Atari Base BBS system run by Atari. The number is 408-745-5308. Expect a 12-24 hour lock-out period (meaning, call back and you should be verified) because of little hackers running amok the system. Dan ------------------------------ Date: 14 Aug 89 23:21:11 GMT From: John Townsend Subject: Re: Archive bit in article <8908091359.AA08065@ucbvax.Berkeley.EDU>, SQ79@liverpool.ac.UK (Mark Powell) says: > > > Bit 5 of a file mode is the archive bit. This is to do with backing up files. > When a file is backed up it's archive bit is set. When it is next written to > the bit is cleared. From this senario the disk back up program can tell whether > a file has been modified since the last back up and if so back up the file > otherwise leave it. This enables an incremental backup to be performed i.e. > back up your hard disk totally every month, and backup just the files that have > changed every week. Unfortunatley this procedure doesn't work on the old TOSes > (or so I'm informed) TOS 1.4 is said to fix this. > I have seen plenty of files on my disks with this bit set. You may be running > a different TOS from me though. I've got a UK TOS 1.0 dated 20/11/85 > i.e. 20th November for you in the US who don't put the date in ascending or > descending order of significance (make your minds up!) > You have it backwards. In TOS 1.4, the bit is set when a file is created or modified. The backup program should clear it after backing up the file. ------------------------------ Date: 23 Aug 89 17:42:37 GMT From: Allan Pratt Subject: Re: gulam bug dennis@marge.math.binghamton.edu (dennis pixton) writes: >I've noticed several problems with redirection in gulam (1.03.04.05) [...] >I wrote a trivial program, args.prg (compiled with mwc) to dump out its >args, the environment, and whether the file handles are ttys. When I run > args a b > junk > I then simply *rename* args.prg to shar.prg and run > shar a b > junk >This time the output is to the screen [...] Gulam has a serious bug in the code for launching programs. There is a table of the internal commands, and flags telling how to handle the argument list for each. Gulam looks your input up in this table, and, in the case of an external command, won't find a match. However, the flags of the last internal command it looked at will be used to parse your arguments! Some flags mean "Don't expand wildcards" and others mean "don't do anything." I happen to have the source, so I fixed this problem back in March, but I don't know if the official types have noticed the bug yet. There are other bugs in redirection, notably when you use shell_p to exec a program and redirect its output. Gulam is the shell I hate to love: it's too good to throw out, and yet so bad in some ways. ------------------------------ Date: 28 Aug 89 16:55:09 GMT From: Ken Badertscher Subject: Re: A little detective work... andyc@hplsla.HP.COM (Andy Cassino) writes: [ List of TSR's used by Mr. Cassino deleted ] | My point is, this is all great sport for us techies, but it's no fun for | your average home/business user trying to DO SOMETHING besides play junior | hacker. Which is precisely why we fixed the majority of the problems you mention in Rainbow TOS (a.k.a. TOS 1.4). When you get it, you'll be able to toss almost all of those TSR's you're using. Available now at a dealer near you. And if it isn't, please WRITE A LETTER to Atari Corp. asking why Rainbow TOS isn't available at your dealer. ------------------------------ Date: 30 Aug 89 21:34:22 GMT From: John Townsend Subject: Re: ROM disassembly for TOS 1.4 in article <9401@chinet.chi.il.us>, saj@chinet.chi.il.us (Stephen Jacobs) says: > > One of the more useful tools in programming the ST is the commented ROM > disassembly in the Abacus ST Internals book (English translation of the > corresponding Data Becker book, I think, but I'm usually wrong). I disagree completely. People should use the documented OS calls. They shouldn't fumble around inside the Operating System looking for calls and data structures that weren't intended for their use. > And a small love-note to the Atari contingent: IBM did it, even though > some of them must nearly have died doing it: they published a complete, > official ROM disassembly. Many developers did exactly what you don't want > us to do: they exploited internal code and data structures. Their code > broke when new DOS versions used the ROM code differently. Some of them > learned their lesson. Near-clone ROMs took more victims. But on balance, > I think you'll find pretty nearly complete agreement that the published > ROM code has helped the PC. An Atari-authorized, commented disassembly of > TOS 1.4 as of a given date (say the delivery date of the first production > lot?) would help programmers enormously. > Steve J. I can't believe what I am hearing! You state my case for me. Programmers depended on the things they read in the IBM disassembly and when things changed their code broke! Isn't that a good enough reason for not releasing disassembled or source versions of sections of the Operating System? My job at Atari is support. I am one of the people that has to take calls from irate customers that are mad because their favorite program breaks on their new computer (with MEGA TOS ROMs) and I am the one that has to tell them that it's because the manufacturer of the software didn't follow the rules when writing his/her program. Most of the time, Atari gets the blame (in the customer's eyes) for these problems with software, when in reality it's the software that is at fault. Anyway, there's my position on disassembled versions of TOS. ------------------------------ Date: 31 Aug 89 01:19:58 GMT From: Allan Pratt Subject: Re: Duesseldorf: personal impression of the TT(T) cmcmanis%pepper@Sun.COM (Chuck McManis) writes: >Hmmm, the whole graphics capability question is really foggy so far. Here's some really straight scoop about the TT from inside Atari: The video palette has *4* bits per gun for color values. That is, you have a total of 4096 colors: 16 levels each of red, green, and blue. (The ST has a palette of 512 colors: 8 levels for each gun.) Another "color" mode provides 256 levels of grey (actually green), for really fine reproduction of a black-and-white image. This is independent of the resolution: if you're in a 16-color mode, you can pick any 16 levels from the spectrum of 256. (We call this hyper-monochrome: one color, but a lot of it!) There are *6* video modes: the three ST modes (totally compatible), plus 640x480 16-color, plus 320x480 *256* color, plus 1280x960 monochrome. ALL of these modes except the last can be shown on a single monitor. That monitor need not be multisync. It can be a slightly modified VGA monitor, or (of course) the monitor which Atari will sell for the TT. The last mode needs a Viking monitor or something similar. ST high rez (640 x 400 x 2 colors) is not limited to black and white: you can choose any two colors. >Does this mean it has a "DMA" port like the 520/1040/MegaX ? Does it have >a "real" SCSI port as well? What kind of through put can be expected from >the hard disk interfaces? Can it do DMA and access > 4Meg ? Yes, there is a DMA port like on the ST and Mega. Your hard disk will plug right in. You can connect a bootable SH204 and it will boot! There is also an external SCSI port. The SCSI port can access the full 32-bit address space; the ACSI port is limited to 24-bit addresses. The internal hard drive is connected to the SCSI bus. >Is the >VME slot the _only_ way to expand it, or does it have a Mega compatible >expansion connector as well? There are a number of ways to expand the TT: you can add 2MB of dual-purpose (video and CPU) RAM, or 10MB when 4Mbit chips are available. You can add 4MB of REALLY FAST 32-bit nybble-mode RAM (not video-capable), and there's the VME bus. The number 2MHz that's been bandied about needs some explanation: The CPU and memory clock speed is 16MHz. There are four clocks in a bus cycle. For dual-purpose RAM, around half the bus cycles go to the video or refresh. Therefore, the CPU gets around two million MEMORY ACCESSES per second, or 2MHz. There are other architectural details which make it a little faster than that. And remember, each access gets you 32 bits, not 16 as on the ST. Also, since the CPU is allocated half the bus cycles, it isn't ALWAYS postponed by video or refresh: it might try to access the bus just as its turn comes up, and not wait at all. Therefore dual-purpose memory accesses run at MORE THAN 2MHz. "Fast" RAM does not have video taking up any of the cycles, so you don't have to wait for that. It takes 4 or 5 clocks (I think) to set up a fast-RAM access, but "nybble mode" means that the CPU fills its cache in "burst mode" at one cycle per subsequent access. The VME logic introduces one wait state, so a VMEbus access takes 5 clocks. (Your mileage may vary: VME cards vary widely in response time.) But, again, you won't be held off the bus by video. VME in the TT shown in Germany is A24/D16 (24 bits of addess, 16 bits of data). >[programs can load in fast RAM or dual-purpose RAM] By a "loader option" the original poster means "load program off disk" not "load .o files into a .prg file." This is correct: there are flags in the PRG header which control the behavior of Pexec and Malloc. Most program can run in fast RAM -- programs which change the screen base pointer and some other things can't, though. >[RAM on the VME bus] You *can* put memory on the VME bus. The performance penalty is not bad. TOS will recognize that memory and use it for programs if you set it up right. >Does it have a Blitter ? No need for one. The reason for the Blitter is to remove instruction- fetch overhead from memory operations, and with the 68030 on-chip cache, the TT does just fine without it. >>It is the cheapest workstation of that power around (about 1/2 the price >>of comparable competitors here in Germany). You can say that again. Please, people, remember that when you compare the TT with a Next machine, for instance, you're talking about roughly 4x the price! JT's motto is Power Without the Price, and we think we're giving you just that. ------------------------------ Date: 4 Sep 89 03:12:41 GMT From: Ken Badertscher Subject: Re: Amiga and ST Reliability mitchell@cbmvax.UUCP (Fred Mitchell - QA) writes: | ... can you make the co-processor | transparent, so that properly-written software can use it if there, and | not die if not? Yes. The SFP-004 coprocessor interface card can be used transparently by software which uses the libraries which Atari made available to developers. Third party compilers are also supporting the coprocessor, including Laser and Turbo C. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include ------------------------------ Date: 12 Sep 89 21:46:36 GMT From: Allan Pratt Subject: Re: TOS 1.4 bug? VBRANDT@DBNUAMA1.BITNET writes: >SYTANG%CSUGREEN.BITNET@Forsythe.Stanford.EDU asks: > - You don't have to use FOLDR100 with the new TOS 1.4, unless you want to > access hundreds of folders in the same 'session'. I have to jump on this one: you don't need FOLDR100 unless you access hundreds of folders AT THE SAME TIME. When you open a file, the directories from the root of that drive down to that file are "in use." When you close the file, they're not "in use" any more, and the space is reclaimed. Better internal memory management like this, and some other things (like way faster FAT code and program launching), is why you should get TOS 1.4 in the first place. ------------------------------ Date: 13 Sep 89 18:02:16 GMT From: Allan Pratt Subject: Re: TOS 1.4 on disk wardlaw@ucrmath.UCR.EDU (Johnie Wardlaw) writes: >Now that TOS 1.4 (aka Rainbow TOS) is available, does this mean that the >disk based beta version supplied to registered developers is "up for grabs"? If by "up for grabs" you mean "freely distributable" the answer is no. Besides being illegal (it was supplied to developers under their nondisclosure agreements, and is copyright by Atari in any case) it's dangerous. The version on disk is not the version in ROM. Also, it's not good business to let people use lots of different, unofficial versions: we don't want to be in the position of saying, "Sorry, we can't help you; we don't support the OS you're using." Please don't use or distribute disk-based versions of TOS 1.4. ------------------------------ Date: 15 Sep 89 02:20:24 GMT From: Ken Badertscher Subject: Re: TOS 1.4 bug? hcj@lzaz.ATT.COM (HC Johnson) writes: | 2. I found that it is absolutely necessary to REMOVE desktop.inf and reboot | before doing a save desktop. There are incompatibilities between how 1.1 | organized it and 1.4. There should be no incompatibility between the Rainbow TOS DESKTOP.INF file and those created with previous versions of TOS. If you're having a problem, please let us know the details. The DESKTOP.INF files should be completely interchangable, with the obvious exception that DESKTOP.INF files created with Rainbow TOS which have auto-launch files won't cause an auto-launch with an older TOS version. ------------------------------ Date: 15 Sep 89 21:39:31 GMT From: Allan Pratt Subject: Re: adding a 68881 The product you want is the Atari SFP004 Floating-Point Math Peripheral or some such name. SFP004 should be sufficient for your dealer to order one if he doesn't already have one. It only goes into Megas; it fits on the internal expansion bus. Of course, on a 68000 you can't talk to it as well as a 68020 can; you have to use it in "peripheral mode" where the handshaking protocol is handled in software, not directly by the CPU. Only programs compiled specifically with the SFP004 in mind will run faster; others won't notice it. (In that respect it is unlike the Blitter.) The SFP004 comes with a disk, I think, containing the guts of a library you can merge with Alcyon's libm to make lib81; link your Alcyon C programs with that library and they will use the SFP004 if it's installed, and Alcyon's software routins if it's not. There is also source for those routines, as examples you can use in assembly language or for other compilers. I *think* that disk is part of the SFP004 package; if it's not, it should be available from Atari. ------------------------------ Date: 13 Oct 89 17:44:24 GMT From: Allan Pratt Subject: Disk Speedup hcj@lzaz.ATT.COM (HC Johnson) writes: >In article <1725@atari.UUCP>, jansen@atari.UUCP (Mark O. Jansen) writes: >> > Is there a program that will speed up disk access on my hard disk? I >> > ...Does TOS 1.4 help with this ? What can I do in the meantime? >> Yes, Rainbow TOS (a.k.a. TOS 1.4) helps with this. A LOT. ... >... After 16-20 meg of copying, it gets noticeably SLOW! It may be slow, but good lord, not as slow as TOS 1.2! The "slow" part is the first write to a new file. GEMDOS looks for the first free cluster in the FAT, always starting from the beginning. When there are 16 solid MB of allocated clusters, that's a lot of FAT sectors to check before finding a free cluster. On TOS 1.2, this is REALLY APPALLINGLY SLOW! On TOS 1.4, this is kind of slow. On TOS 1.4 with enough GEMDOS disk buffers to keep the whole FAT in RAM, it is REALLY FAST! Try Dfree on a 32MB partition in under 1 sec! (Allocating the second, third, ... n'th cluster is not slow, because there the search begins with the previous cluster, not the start of the FAT.) Ken Bad should have posted "CACHEXXX.PRG" here - if he hasn't, I'm sure he will. If you use it and be sure XXX is equal to the sum of the FAT sizes (in sectors) of your disks, GEMDOS will load them up once and never have to hit the disk for reading a FAT again! It is not the case that the FAT is written after each allocation. It's written when a buffer is re-used or the file is closed. ------------------------------ Date: 13 Oct 89 20:36:06 GMT From: J. E. Patton Subject: TOS 1.4 features??? (Was Re: Disk Speedup) in article <1728@atari.UUCP>, jpatton@atari.UUCP (J. E. Patton) says: > > in article <1113@electro.UUCP>, carlo@electro.UUCP (Carlo Sgro) says: >> >> In article <1725@atari.UUCP> jansen@atari.UUCP (Mark O. Jansen) writes: >>>I'd recommend you get Rainbow TOS, for this and lots of other reasons. >> >> Well, what are those reasons?? I've seen a LOT of discussion about 1.4 but >> I still haven't seen a summary of its new features and how to use them. Is >> this asking too much (honest question!)? >> >> >> -- >> >> Carlo Sgro ... but does Bo know nuclear physics? >> watmath!watcgl!electro!carlo Dealers are now receiving information sheets along with their Rainbow TOS orders. If your dealer hasn't ordered the new TOS recently he may not have it, but his contact in dealer services at Atari Corp. will be happy to send it to him. In short the addendum addresses: 1. The file selector (expanded drive selector,improved wildcards). 2. Moving files by holding down [Control] as you click on and drag selected files. 3. Skip option available for group copying. 4. Aborting group move, copy, or delete operation by holding down [Undo]. 5. Disks formatted are fully MS-DOS compatible. 6. The Install Applications option allows you select an application to auto-boot. 7. Copy and Format dialogs have been combined. 8. Folders can be renamed. 9. The [Control][Alt][Delete] sequence will reset your computer. The [Control][Alt][Right Shift][Delete] causes a cold boot. The addendum does not address improvements such as improved FAT searches or a more responsive mouse. -=-=-=-=-=-=-=-=-=-=-=-=-=-= ...ames!atari!jpatton ------------------------------ Date: 16 Oct 89 20:30:08 GMT From: Allan Pratt Subject: TOS problem ? piet@cs.ruu.nl (Piet van Oostrum) writes: >I encountered a strange TOS behaviour (TOS 1.2): >I Fcreate a file, then Fopen the same file (not very usual, I agree). >... Finally I close the second handle, and forget to close the >first one, (or close that last). Result: an empty file. Well, that's interesting, but only just. Opening the same file twice is something which GEMDOS doesn't handle well (pun intended). I can apologize for only so long for how bad GEMDOS is before the blame shifts from the guy who wrote it (for introducing the bugs) to me (for not fixing them). I hope I haven't gotten to that point yet. ------------------------------ Date: 19 Oct 89 23:51:10 GMT From: John Townsend Subject: official tos 1.4 release in article <4634aec9.14a1f@force.UUCP>, covertr@force.UUCP (Richard E. Covert) says: > > The problem Greg is that you just plain and simply can't count on > Atari for support!! If Atari was going to support the ST, why didn't Atari > license GPLUS from Charles Johnson and include it in TOS 1.4?? > > Why didn't Atari make any improvments in GDOS for TOS 1.4?? I have over > 3 megs of GDOS fonts for my SLM804 and if it wasn't for Charles Johnson's > GPLUS I wouldn't use any of them!! The GDOS support in TOS, even TOS 1.4, > is almost zero compared to what GPLUS offers. And GPLUS has been out for > a year now, so Atari could have licensed it from Charles Johnson. > > And Atari didn't even want to admit that there was a bug in the serial > port code in TOS 1.4 until the Canadian hacker showed Atari the actual > bug in the code. Pretty responsive of Atari, huh?? And this is for an OS > that has been under development for 2 years!! After 2 years, you would think that > Atari would have it right!!! > > Boy, a good outline font system, aka the macintosh system, would really be > great for the ST!! But asking Atari for anything like that is like jumping > to the moon, you'll never get there!! > > I like the third party support starting to appear for the ST. My favorite > product is the Turbo16 product from FAST TECHNOLOGY. T16 really speeds up > my Mega ST!! It is great!!! > So, lets support the good 3rd party enhancments to the ST and hope that > things will get better IN SPITE OF ATARI!! > > Rich (Proud owner of a souped up T16ed Mega ST4!!) Covert First, TOS 1.4 is a product. GDOS is a product. They are COMPLETELY independent of each other. As for the serial port, We found the problem and we fixed it via the TOS 1.4 patch. Unfortunately, it was not found until after the release of the ROMs. To verify this, we did not receive a single SPR on this problem from the developers that had the Beta version of TOS 1.4 or any reports from anyone until AFTER the ROMs had been finalized. But, the end result is that the problem was reported, we looked into it, found there was a problem, fixed it, and released a patch program via the Networks and Dealer Network. What more do you want from us?? -- John Townsend ames!atari!towns Atari Corporation ------------------------------ Date: 20 Oct 89 18:07:07 GMT From: Allan Pratt Subject: CACHEXXX, (FATs, etc.) Ritzert@DMZRZU71.BITNET writes: >According to Allan, XXX must be exactly equal to the size of the FAT. Please, this is a gross misunderstanding. If it *had* to be exactly equal to anything, we would have written it to compute that thing when it ran. What I said is that there's little point in making XXX GREATER than the sum of the FAT sizes. >Related question: is it possible with tos14 to increase the cluster >size, i.e. shorten the FATs dramatically and thus speed up the hd even >further? Will CACHEXXX support such a configuration? TOS 1.4 FAT handling is so fast, you wouldn't notice. My God, it's DOZENS of times faster than TOS 1.2 FAT handling, and certainly acceptably fast in its own right! When the FAT is entirely cached, a Dfree() call on a 16MB partition takes under a second! That's fast enough for me. HDX on release 3.01 of the Atari Hard Disk Utilities disk allows you to create partitions greater than 16MB in size. It accomplishes this by making "sectors" on the disk appear to be larger than 512 bytes. A cluster is always two sectors, but larger sectors means more data per cluster, and therefore fewer FAT entries. Not all disk utilities use Getbpb() to find out how big a sector is, so they won't all work with this kind of partition. For maximum compatibility, therefore, this feature only kicks in on large (>16MB) partitions. CACHEXXX *does* support the larger sector size. No other cache program can, because it doesn't know where to look to find the sector size it should use. Don't use any other cache program if you have any partition >16MB created by this HDX. FYI: on the disk labelled 3.01 you will find HDX's version number is 3.00 and AHDI's version number is 3.01. If you use HINSTALL to make your hard disk bootable, the version number you will see when it boots is 3.01. This is all well and good. If your hard disk driver, whether installed by HINSTALL or loaded from your AUTO folder as AHDI.PRG, says it's version 3.00, GET THE UPDATE. AHDI and bootable disks version 3.00 are DEADLY to data. ------------------------------ Date: 25 Oct 89 17:07:10 GMT From: Allan Pratt Subject: 82 tracks, twister, etc. krieg@jupiter.uucp (Andrew Krieg) writes: >I have a few questions about disks and disk formatting for the ST. > 1) [What is Twister format?] > 2) [Why 82 tracks?] > 3) [Are there any 1.4M drives out there?] "Twisted" disks have sectors on successive tracks offset from one another. Instead of always starting sector 1 at the index mark, they start sector 1 there on track 0, sector 3 on track 1, sector 5 on track 2, and so on. This makes disk I/O faster, because there are only two sectors of latency between reading sector 9 from track 0 and sector 1 of track 1, instead of 9 sectors of latency waiting for the whole disk to spin around. You get "Twisted" disks any time you format a disk from the Desktop using Mega TOS or any newer TOS. Once the disk is formatted it will be fast no matter where you use it. Atari disk drives are only guaranteed to handle 80 tracks. Some people have discovered that some drives can actually access 82 tracks, so they have written formatters which will format 82 tracks. This is not recommended, and you can actually damage your disk drive by telling it to seek so far that it bangs into something. The Desktop format operation will only format 80 tracks. I am not aware of any 1.4M drives available for the ST. I know you couldn't just plug one in: they get 1.4M by doubling the data rate, and the controller inside the ST couldn't handle it. ------------------------------ Date: 25 Oct 89 21:15:21 GMT From: Allan Pratt Subject: Which filehandle for stderr? piet@cs.ruu.nl (Piet van Oostrum) writes: >Which filehandle should be used for stderr? I have seen compilers that use >2 and others that use -1. >If you use 2: you can redirect stderr, but it is not official TOS usage (2 >is supposed to be stdaux). So you need a sheel that sets up 2 to default to >the console. On the other hand it is Unix compatible. >If you use -1: it is TOS standard, compatible with the desktop, but you >can't redirect it to a file. Boy, if only all the questions on the net were this well thought out and concise. Way to go, Piet! My personal opinion, not to be construed as an Atari policy statement, is that handle 2 is a fine choice. I realize it requires a shell which supports it, but I think it's worth the effort. You can even tell if you've been run from the Desktop, and if you are, you Fforce handle 2 to -1 or something. (You can tell if you're launched from the Desktop by checking for a CR character just PAST the end of your command line. It's not very nice, but it works. Here's the code you'd have to use in your startup, before anybody munges the command line.) ----- move.l ,a0 lea.l $80(a0),a0 move.b (a0)+,d0 ext.w d0 cmp.b #$d,(d0,a0) bne notdesktop ... launched from desktop ... bra done notdesktop: ... not launched from desktop ... done: ----- Of course, if your shell puts a CR there in a misguided attempt at being compatible with the desktop, you'll be in trouble. Another way to tell is to see if there's anything but PATH in your environment: most shells put SOMETHING there... ------------------------------ From: Ken Badertscher Subject: GEMDOS Extended Argument Spec GEMDOS EXTENDED ARGUMENT (ARGV) SPECIFICATION --------------------------------------------- Introduction The Pexec() function of GEMDOS allows a program to pass to a child process a command line up to 125 characters long, with arguments separated by spaces. No provision is made in GEMDOS for the child to know its own name. This makes it difficult for C programs to correctly fill in argv[0], the standard place where a C program finds the command which invoked it. Because the command line arguments are separated by spaces, it is difficult to pass an argument with an embedded space. This document will specify a method of passing arguments which allows arbitrary argument length, embedded spaces, and support for argv[0]. Standard Argument Passing The Pexec Cookbook specifies how to use Pexec() to launch a child process, passing a command tail (argument string) and an environment. Before getting into the extended argument scheme, let's review how arguments are normally passed to a child. A parent process builds a command line into an argument string - a null terminated string whose first byte contains the length of the rest of the string - and its address is passed as one of the arguments to Pexec(). GEMDOS copies this argument string to the basepage which it creates for the child. Thus the parent is responsible for gathering all the child's arguments into one string. This is normally handled by a library exec() function. The child is responsible for parsing the string of space-separated arguments back into an array of strings. This parsing is normally handled by the child's startup code. Evolution Several methods of bypassing the limits imposed by Pexec() have been used by GEMDOS programs. Some allow a user to specify a file on the command line which contains the rest of the arguments. Others get a pointer to the arguments, or the arguments themselves, from the environment string. Most MS-DOS programs use a command file for the extra arguments. This can be inconvenient for a user, cluttering the file system with command files, and making the operation of batch files and makefiles more confusing. Several "standards" have arisen on the ST which use the environment to pass arguments. While more convenient than command files, these standards have other problems. Some rely on sharing memory between parent and child processes. Some take advantage of undocumented features of the operating system to get argv[0]. Others give the child process no way to validate that the arguments it finds are intended for it. Rationale In order to pass more than the standard 125 characters worth of arguments to a child, or to let the child find its name, the parent must place the extra information in a place where the child can access it safely and legally. The most convenient place is in the child's environment string. An environment string is a series of null-terminated strings of the format "VARIABLE=value" (e.g. PATH=c:\bin,c:\etc, or ShellP=YES). The last null-terminated string in the environment is followed by a zero byte, thus two consecutive nulls indicates the end of the environment. The environment is allocated for the child by GEMDOS, it is owned by the child, and its contents can be specified by the parent. The child must have some way of knowing that the arguments which it finds in its environment are intended for it. The child may have been invoked by a parent which does not conform to this specification. Such a parent would leave _its_ arguments in the environment, and could pass that environment on to the child. The child would mistakenly interpret its parent's arguments as its own. Placing arguments in the environment passed to the child gets around all of the command line limits of the standard Pexec() command tail. Because there is no limit on the length of the environment, arbitrary length arguments are supported. Arguments placed in the environment are null terminated, so they may contain spaces. A parent can also place the name of the command with which it invokes the child in the child's environment, providing support for argv[0]. Validation of the extended arguments can be placed in the standard Pexec() command line, by assigning a special meaning to an invalid length byte. The GEMDOS Extended Argument Specification This specification uses the convention that the presence of an environment variable named ARGV (all upper case) indicates that extended arguments are being passed to the child in its environment. This means that ARGV is a "boolean" environment variable. For the purpose of this specification, its value is not significant, but its presence indicates that the strings following it are the arguments for the child. Implementations of this specification are free to give the ARGV environment variable any value. The ARGV environment variable must be the last one in the environment passed to the child, so that the child can truncate its environment at that point, and treat everything before the ARGV as environment, and everything after it as arguments. The first argument to the child (argv[0]) is the first string in the environment after the ARGV variable. This argument is the "pathname" parameter passed by the parent to Pexec(). The remaining arguments are those that the child would normally find in the command tail in its basepage. Even if all of the arguments would normally fit in a child's command tail, the parent should set up the arguments in the environment to take advantage of the benefits of this extended argument scheme. As many arguments as will fit in the command tail will be passed there as well as in the environment, to support non-conforming programs. As a flag that arguments are also in the environment, the length byte of the command tail will be 127 (hex 7f). Non-conforming programs should not have a problem with this length byte, because it is longer than the maximum 125 bytes allowed by Pexec(). As an aside, the Pexec Cookbook erroneously implies that a command line can be 126 or 127 characters long. In fact, GEMDOS only copies to the child's basepage up to 125 bytes, or until it encounters a null, from the argument string passed to Pexec(). It ignores the length byte, placing a null at the same place it found one or at the 126th byte if no null is found. This has several implications: the length byte is not validated by GEMDOS (necessitating validation in the child's startup code, but also making this extended argument spec possible), and the null terminator _can_ be located after the end of the real command tail (the Desktop places a CR character after the command tail and before the null). The ARGSTART.S startup code listing below demonstrates how to correctly validate and parse a GEMDOS command tail. A child which finds an ARGV environment variable can use the command tail length byte value of 127 to validate that the arguments following the variable are valid, and not just left over from a non-conforming parent which left its own ARGV arguments in the environment. Because the strings in the environment following an ARGV variable are not environment variables, a child should truncate its own environment at the ARGV variable by changing the 'A' to a null. Implementation: Parental Responsibilities To pass arguments in the environment, a parent must create an environment string for the child. This can be achieved by first allocating as much space as is used in the parent's own environment, plus enough room for the ARGV variable and the arguments to the child, and then copying the parent's environment to the newly allocated area. Next, the ARGV variable must be appended, since it must be the last variable in the child's environment string. Following the ARGV variable is the null-terminated pathname of the child as passed to Pexec(), then the null-terminated arguments to the child, followed by a final null byte indicating the end of the environment. After setting up the arguments in the environment, the parent must place as many arguments as it can fit in the command tail it passes to Pexec(). This way, a child which does not conform to this specification can still get arguments from the command tail in its basepage. When placing arguments in the environment, the parent must set the first (length) byte of the command tail to 127 (hex 7f), validating the arguments in the environment. Here is an example execv() library routine in C. It uses three local utility routines, e_strlen(), e_strcpy(), and str0cpy() for getting environment size and copying strings into the environment created for the child. /* EXECV.C - example execv() library routine * ================================================================ * 890910 kbad */ long Malloc( long nbytes ); long Pexec( short mode, char *filename, char *tail, char *env ); long Mfree( void *address ); /* Return the total length of the characters and null terminators in * an array of strings. * `strings' is an array of pointers to strings, with a null pointer * as the last element. */ static long e_strlen( char *strings[] ) { char *pstring; long length = 0; while( *strings != 0 ) { /* Until reaching null pointer, */ pstring = *strings++; /* get a string pointer, */ do { /* find the length of this string, */ ++length; /* using do-while to count the */ } while( *pstring++ != 0 ); /* null terminator. */ } return length; /* Return total length of all strings */ } /* Copy a string, including the null terminator, and return a pointer * to the end of the destination string. */ static char * str0cpy( char *dest, char *source ) { do { /* use do-while to include null terminator */ *dest++ = *source; } while( *source++ != 0 ); return dest; } /* Copy an array of strings into an environment string, and return a pointer * to the end of the environment string. * `strings' is an array of pointers to strings with a null pointer * as the last element. * `envstring' points to the environment string. */ static char * e_strcpy( char *envstring, char *strings[] ) { while( *strings != 0 ) { envstring = str0cpy( envstring, *strings ); ++strings; } return envstring; /* Return end of environment string */ } /* Run a program, passing it arguments according to the * GEMDOS Extended Argument Spec. * * `childname' is the relative path\filename of the child to execute. * `args' is an array of pointers to strings to be used as arguments * to the child. The last array element must be a null pointer. * `environ' is a global array of pointers to strings * which make up the caller's environment. */ long execv( char *childname, char *args[] ) { long envsize, ret; char *parg, *penvargs, *childenv, *pchildenv; short lentail; char argch, tail[128], *ptail; static char argvar[] = "ARGV="; extern char *environ[]; /* * Find out how much memory we'll need for the child's environment */ envsize = e_strlen( environ ); /* length of environment */ envsize += e_strlen( args ); /* plus command tail args */ /* plus length of argv[0] */ parg = childname; do { /* use do-while to include null terminator */ ++envsize; } while( *parg++ != 0 ); /* plus length of ARGV environment variable and final null */ envsize += 7; envsize += envsize & 1; /* even # of bytes */ /* * Allocate and fill in the child's environment */ ret = Malloc( envsize ); if( ret < 0 ) return ret; /* Malloc error */ childenv = (char *)ret; pchildenv = e_strcpy( childenv, environ ); /* copy caller environment */ pchildenv = str0cpy( pchildenv, argvar ); /* append ARGV variable */ pchildenv = str0cpy( pchildenv, childname ); /* append argv[0] */ penvargs = pchildenv; /* save start of args */ pchildenv = e_strcpy( pchildenv, args ); /* append args */ *pchildenv = 0; /* terminate environment */ /* put as much in the command tail as will fit */ lentail = 0; ptail = &tail[1]; while( (lentail < 126) && (penvargs < pchildenv) ) { argch = *penvargs++; if( argch == 0 ) { *ptail++ = ' '; } else { *ptail++ = argch; } } /* terminate command tail and validate ARGV */ *ptail = 0; tail[0] = 127; /* * Execute child, returning the return code from Pexec() */ ret = Pexec( 0, childname, tail, childenv ); Mfree( childenv ); return ret; } /* End of execv() example code */ Implementation: Prenatal Responsibilities A program's startup code must handle getting extended arguments out of the environment. The startup code should get the basepage pointer off the stack, then get the environment pointer from the basepage, and search the environment for "ARGV=". If "ARGV=" is found, the command line length byte in the basepage is checked. If the command line length byte is 127, then the arguments in the environment are valid. The first argument begins after the first null following the "ARGV=". It is important not to assume that the null follows immediately after the "ARGV=", because some implementations may assign a value to the ARGV environment variable. After setting up an array of pointers to the arguments, the startup code should set the 'A' of the "ARGV" variable to null, thus separating the environment from the argument strings (remember: a double null terminates the environment). Here is some example C startup code which shows how a child could look for arguments in its environment: * ARGSTART.S - example C startup code * using GEMDOS Extended Argument Specification * ================================================================ * 890910 kbad .globl _main ; external, C entry point .globl _argv0 ; external, name used for argv[0] if no ARGV .globl _stksize ; external, size of application stack .globl _basepage ; allocated here, -> program's basepage .globl _environ ; allocated here, -> envp[] .globl _argvecs ; allocated here, -> argv[] .globl _stklimit ; allocated here, -> lower limit of stack .BSS _basepage: ds.l 1 _environ: ds.l 1 _argvecs: ds.l 1 _stklimit: ds.l 1 .TEXT _start: move.l 4(sp),a5 ; get basepage move.l a5,_basepage ; save it move.l 24(a5),a0 ; bss base add.l 28(a5),a0 ; plus bss size = envp[] base move.l a0,_environ ; save start of envp[] move.l a0,a1 ; start of env/arg vectors move.l 44(a5),a2 ; basepage environment pointer tst.b (a2) ; empty environment? beq.s nargv ; yes, no envp[] lea.l (sp),a4 ; use dummy return pc on stack for ARGV test * --- fill in the envp[] array nxenv: move.l a2,(a1)+ ; envp[n] move.l a2,a3 nxen1: tst.b (a2)+ bne.s nxen1 ; get the end of this variable tst.b (a2) ; end of env? beq.s xenv * --- check for ARGV move.b (a3)+,-(a4) ; get 1st 4 bytes of this var move.b (a3)+,-(a4) move.b (a3)+,-(a4) move.b (a3)+,-(a4) cmp.l #'VGRA',(a4)+ ; is it ARGV? bne.s nxenv cmp.b #'=',(a3) ; is it ARGV=? bne.s nxenv clr.b -4(a3) ; ARGV marks the end of our environment cmp.b #127,$80(a5) ; command line validation? bne.s nargv ; nope... and we're done with the env. * --- got an ARGV=, create argv[] array clr.l (a1)+ ; terminate envp[] move.l a1,_argvecs ; save base of argv[] nxarg: move.l a2,(a1)+ ; argv[n] nxar1: tst.b (a2)+ bne.s nxar1 tst.b (a2) bne.s nxarg * --- end of environment xenv: move.l _argvecs,d0 ; if we got an argv[] bne.s argok ; don't parse command tail * --- No ARGV, parse the command tail * NOTE: This code parses the command tail IN PLACE. This can cause problems * because the default DTA set up by GEMDOS for a program is located * in the command tail part of the basepage. You should use Fsetdta() * to set up your own DTA before performing any operations which could * use the DTA if you want to preserve the arguments in the command tail. nargv: clr.l (a1)+ ; terminate envp[] move.l a1,_argvecs ; base of argv[] move.l #_argv0,(a1)+ ; default name for argv[0] lea 128(a5),a2 ; command tail move.b (a2)+,d2 ; length byte ext d2 moveq #125,d1 ; validate length cmp d1,d2 bcs.s valen move d1,d2 ; if invalid length, copy all of tail valen: clr.b 0(a2,d2) ; null tail because desktop inserts moveq #' ',d1 ; space terminator get1: move.b (a2)+,d2 ; null byte? beq.s argok ; if so, we're done cmp.b d1,d2 ; strip leading spaces beq.s get1 subq #1,a2 ; unstrip start char move.l a2,(a1)+ ; and store that arg get2: move.b (a2)+,d2 ; next char beq.s argok ; if null, we're done cmp.b d1,d2 ; if not space... bne.s get2 ; keep looking clr.b -1(a2) ; terminate argv[argc] in the command tail bra.s get1 ; get next arg argok: clr.l (a1)+ ; terminate argv[] * --- allocate stack move.l a1,_stklimit ; end of env/arg vectors is stack limit add.l _stksize,a1 ; allocate _stksize bytes of stack move.l a1,sp ; set initial stack pointer * --- release unused memory sub.l a5,a1 ; size to keep move.l a1,-(sp) move.l a5,-(sp) ; base of block to shrink pea $4a0000 ; Mshrink fn code + junk word of 0 trap #1 lea 12(sp),sp ; pop args * * Everything beyond here depends on implementation. * At this point, _environ points to envp[], _argvecs points to argv[], * and _stklimit points to the end of the argv array. Thus argc can * be calculated as ((_stklimit-_argvecs)/4)-1. * _main could be invoked as follows: * move.l a5,-(sp) ; basepage move.l _environ,-(sp) ; envp[] move.l _argvecs,-(sp) ; argv[] move.l _stklimit,d0 ; 4 bytes past end of argv[] sub.l (sp),d0 ; (argc+1) * sizeof( char * ) asr.l #2,d0 ; argc+1 subq #1,d0 ; argc move d0,-(sp) jsr _main ; call mainline lea 14(sp),sp ; pop args A Final Note This specification was formulated with careful deliberation, and with input from several companies and developers who have created development tools for GEMDOS. The Mark Williams extended argument passing scheme was the main influence for this specification, because it has been in use, and supported by Mark Williams and other companies for several years. This specification is very similar to the Mark Williams scheme, with the following important exceptions: 1) Under the specification, the arguments after the ARGV environment variable may be validated by checking the command tail length byte. The Mark Williams execve() library function uses the command tail length byte as a telltale, but it is not checked by the crts0 startup code. This validation is important for the reasons mentioned in the Rationale section above. 2) The specification allows the ARGV environment variable to take on any value. Mark Williams uses the value of ARGV as an iovector, which is described in the Mark Williams documentation. The iovector should no longer be needed, as its primary purpose was to simplify the MWC implementation of the C library function isatty(). 3) Some versions of the MWC startup code do not require the ARGV= to have an `='. Because ARGV is an actual environment variable in the specification, the equals character is required. ---- END OF FILE ----