ATARI TECHNICAL POSTINGS 1991 This volume is a collection of postings to Usenet by Atari's technical staff from January '91 through to December '91. Postings from November '88 through to October '89 are available in ATARI_89.TXT and postings from 1990 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. 1991. ------------------------------ From: Allan Pratt Subject: Re: Setting 2000 year date Date: 4 Jan 91 19:24:20 GMT alex@hpgnd.grenoble.hp.com (Alexis MERMET-GRANDFILLES) writes: >My STE definitively refuses to set its Date to any day >after the 31 december 1999. I just tried setting the date to 1/4/2001 on my TT and it works fine. The code hasn't changed between 1.62 and this version, so I don't know what to tell you. Try Tsetdate(0x2a24) -- the return code should be zero, meaning it succeeded. If you then try to print the date with a program which is not prepared to handle the turn of the century, that can cause trouble, but it's not TOS's fault. ------------------------------ From: Allan Pratt Subject: Re: DMA/FDC Programming Date: 9 Jan 91 21:11:40 GMT bcullign@vax1.tcd.ie writes: >Could someone tell me how to program the DMA and the Floppy Disk Controller >(FDC) on a 520STFM? Any info would be appreciated. You might get more help if you described what you're trying to do. From me, you'll get advice on how to do it without directly programming the DMA or FDC components of the system. Unless you're an operating system, there's no reason that you need to talk to the DMA controller or the FDC directly. If you're a developer, check your docs about the Flop* and Rwabs BIOS calls. If you aren't, then become one so you can find out about this stuff. ------------------------------ From: Allan Pratt Subject: Re: Max of 113 files in a subdirectory: fact or fiction? Date: 10 Jan 91 19:56:06 GMT GEMDOS imposes no limits to the number of files you can have in a subdirectory. The only limit is disk space: the directory file itself needs to grow as more files are added to it. Under some versions of TOS, the Desktop will not show more than N files in one folder, but that's a Desktop limit, not a GEMDOS limit. Gulam might also gag if it finds a large number of files in a directory, or if it's asked to copy a large number of files, but I have not had that problem, and I've used it to copy large numbers of files (>1000 total, >100 in some directories). Root directories do have a limited number of slots for files; this number is fixed at the time you format the disk. It's often 128 or so. ------------------------------ From: Allan Pratt Subject: Re: switching res Date: 10 Jan 91 19:59:10 GMT sslee@polyslo.CalPoly.EDU (Steven Lee) writes: > char *ainit=(char *)a_init; /* Line A call, $A000 */ > Setscreen(-1L,-1L,0); > *((int *)(aline-692))=319; /* Mouse X limit */ > *((int *)(aline-690))=199; /* Mouse Y limit */ > *((int *)(aline-666))=16; /* # of bitplanes */ Setscreen() fills in the line-A variable space with correct values for the new resolution, so you don't have to do it yourself. This is the right way to change rez, if you want to do that. Since you already know you're going "behind AES's back" in doing this, I won't lecture you on the implications. As long as you Setscreen() back to the old rez before you make any AES calls, this works. ------------------------------ From: Allan Pratt Subject: Re: case insensitivity in TOS Date: 14 Jan 91 21:34:18 GMT rosenkra@convex.com (William Rosencranz) writes: >is there any inherent reason why future TOS versions can't be case >sensitive [...?] The quick answer is this: GEMDOS was that way originally because MS-DOS is that way, and GEMDOS is still that way because it was that way originally. There is little hope of a case-sensitive GEMDOS in the near future. If you're desperate, you can look up UNIXMODE from Bammi@cadence.com. I don't know if he has a stand-alone TSR version yet, or if it's still just part of libraries you have to link with to get it. ------------------------------ From: Allan Pratt Subject: Re: Setting a 2000 year date *HELP* Date: 14 Jan 91 21:59:08 GMT I assure you it has nothing to do with being in France. The countries that we do ROMs for get their ROMs from headquarters, and there are no differences in low-level time handling. I have just done some research on the clock handling, and I think you're right: if you don't have a clock chip in your system (i.e. not a Mega ST or Mega STe or TT) then the keyboard clock is regarded as the most correct one, and it uses the "last two digits of the year" method of keeping time. This is too bad. If you have a clock chip, either the kind in the Mega ST and Mega STe (from Ricoh) or the kind in the TT (from Motorola), then your IKBD clock is never used, and this problem does not arise. Also, of course, if you have some third-party clock chip and a TSR that intercepts the Xbios Settime/Gettime calls, you won't have this problem. Sorry I blew you off earlier: I forgot that there was so much variation in timekeeping in the Atari computer line. It is certainly possible to fix this in the BIOS or with a TSR, but I don't think it'll be a priority for 9 years or so :-) ------------------------------ From: Allan Pratt Subject: Re: TOS Version (was Veriosn) Date: 18 Jan 91 21:49:50 GMT bdm@sirius.rice.edu (Brian D Moore) writes: > Quick question...how do I know which version I have? [...] > Perhaps the default date tells, which is 4/22/87. That date is the date of the Mega TOS release (TOS 1.2), so that's probably what you have. The definite way to tell is to read the OS header. A pointer to the OS header is at $4f2, and the TOS version number is found in the second word of the OS header. For example, $0102 there means TOS 1.2. ------------------------------ From: Allan Pratt Subject: Re: Hidden folders (was Hidden Files) Date: 23 Jan 91 18:58:39 GMT Somebody says "MAC copies to MSDOS (Atari) disks create a hidden folder." Then ss60wbi@sdcc4.ucsd.edu (G. "Maddog" Knauss) writes: >You can make ANY file think it's a folder by fiddling with >GEMDOS(67). [...] I shudder to think of what's going to happen to the disk >structure if the file isn't actually a folder, though. TOS versions 1.4 and greater do not allow this. They return "access denied" if you try to change the folder bit to make a file into a folder. You also can't set the volume-label bit or any of the undefined bits. You can't change ANY of the attribute bits of a folder. If the folder bit is set, it has to be the ONLY bit set. "Hidden folder" is an invalid combination under GEMDOS. Obviously, it's possible for something illegal to come in from outside. I really didn't think about this when I put those restrictions on Fattrib. I'll have to think about that one. ------------------------------ From: Allan Pratt Subject: Re: GEMDOS dir/drive changing Date: 29 Jan 91 21:55:07 GMT rosenkra@convex.com (William Rosencranz) writes: >if i Pexec a process, then within that process do a Dsetpath/Dsetdrv, >when i return from the Pexec, will the parent think it is back in the >same dir before the Pexec, or will the child's actions be >propagated back to the parent? in other words, is GEMDOS's concept >of current/default directory global in scope or is it per process? Why don't you try it? The answer is that it's per-process. The information is stored partly internally in GEMDOS and partly in the process' basepage (in the GEMDOS-private part). ------------------------------ From: Dave Hanna Subject: Re: Fast Raster Routines Needed. Date: 31 Jan 91 18:31:55 GMT In article <1991Jan23.005852.28904@sbcs.sunysb.edu> mrose@libserv1.ic.sunysb.edu (Michael Rose) writes: > Also, does anyone know how the bit planes are set up in the new >TT specific graphics modes? In the 320x480x8 mode, does one byte equal >one pixel? NO! The 320x480x8 mode is merely an extension of the X 2 and X 4 planar modes: 2 bytes hold plane 1 data for the first 16 pixels, followed by 2 bytes for plane 2 for the first 16 pixels... ------------------------------ From: Allan Pratt Subject: Answer to "what does CACHEnnn do?" Date: 1 Feb 91 02:29:23 GMT carter@cat34.cs.wisc.edu (Gregory Carter) writes: >I don't even know of [a disk accelerator] that does, except Atari's really >absurd cache program, which doesn't work worth a dam. You might not understand what CACHEnnn does. If you think it is supposed to do something that it doesn't do, you will think it does it badly. Try this: without running CACHEnnn say "show info" on a disk (floppy or hard). Now say it again. Took a while, right? Had to hit the disk both times, right? Now run CACHEnnn (with nnn at least 020) and and do it again. The second time you "show info," the disk isn't accessed, because the information is in memory already. That's an example of what CACHEnnn does. (This demonstration won't work with a write-protected floppy, because the second "show info" will actually read the disk to detect media change.) CACHEnnn doesn't do much good on a machine with TOS older than 1.4 because those versions used the cache badly: adding more buffers to a badly managed cache doesn't help. But STe's have TOS 1.6 or 1.62, so that's not an issue. ------------------------------ From: Allan Pratt Subject: Re: Hidden folders (was Hidden Files) Date: 6 Feb 91 20:59:38 GMT neil@cs.hw.ac.uk (Neil Forsyth) writes: >As it is I can hide a folder by flipping the bit manually >using a disk editor. (It's OK Allan I reboot afterwards!) It's not OK. GEMDOS's behavior in the presence of unexpected flag combinations is undefined. For example, some places in the code could check for (attr & SUBDIR) but some check for (attr == SUBDIR). So you might find that you can use the thing as a folder, but you can also Fdelete it, or if you Fcreate a file with the same name it'll get clobbered! This would be disaster for the files contained in the folder. You're playing with fire. ------------------------------ From: Allan Pratt Subject: Re: Hidden folders (was Hidden Files) Date: 11 Feb 91 20:10:31 GMT >apratt@atari.UUCP (Allan Pratt) writes: >>For example, some places in the code could >>check for [...] (attr == SUBDIR). wolfram@ikki.informatik.rwth-aachen.de (Wolfram Roesler) writes: >If it is allowed to criticize the Sensei: >This a a VERY bad programming style. Tell me about it. I didn't write GEMDOS, I inherited it. Besides, I didn't say this was the case, I said it might be. I think it is. I haven't looked. I choose not to look, so as to keep the possibility open. It's like Schroedinger's Cat: if you don't look, you don't know. In this case, I want to assume (and I want you all to assume) it's unsafe. ------------------------------ From: Allan Pratt Subject: Re: bombs on an STE Date: 13 Feb 91 21:20:25 GMT avgroeni@cs.ruu.nl (Annius Groenink) writes: > Has any STE owner ever had the problem of two bombs (bus error) appearing >on the screen after one of the alert boxes `no disk in drive A' or >`Disk in drive A has been write-protected'? Can anyone explain this strange >behaviour of my computer (which already caused me to loose MANY files)? Try not running any accessories, and see if the problem goes away. There is a bug in some TOSes: if an alert comes up, and then an accessory's event_timer call expires, and then the accessory makes a GEMDOS call, you will get bombs when you click either button of the alert. The original Control Panel from Atari (the one that lets you set the colors) did in fact use event_timer and then make GEMDOS calls, so it would cause this problem to happen. Most accessories don't have this problem, since (A) they don't use event_timer much, or (B) they don't do GEMDOS calls as a result of event_timer. ------------------------------ From: Allan Pratt Subject: Re: catch SLM DMA-calls --- How? Date: 13 Feb 91 21:23:53 GMT nico@cs.ruu.nl (Nico Verwer) writes: >about all [the SLM804] can do is print bitmaps, which are built in memory. That's right. But the WAY it prints bitmaps, and the way they are built, and the way they get sent via DMA to the printer, are all pretty strange. One thing you can do is have your program (whatever it is) write a page image to memory, then use the DIAB630 software to send that page to the printer. There are escape codes which say, "Hey, printer driver! There's a page image at location X in memory - print it!" So if you can get a bitmap to appear in memory someplace, you can point DIAB630 at it and it'll be printed. ------------------------------ From: Allan Pratt Subject: Re: Apple wins against Microsoft Windows/HP New Wave Date: 11 Mar 91 19:00:48 GMT >>In article <4159.27d64355@miavx1.acs.muohio.edu>, >>rlcollins@miavx1.acs.muohio.edu (Ryan 'Gozar' Collins) writes... >>...is Digital Research and Gem far behind?... >gilliam@lowlif.dec.com writes: >Apple did sue DRI in 1985 and won. The Atari license using GEM V1.1 was >exempted from the ruling. That's why subsequent versions of GEM are different. Actually, that's not the case. I don't know if Apple actually sued DRI, but I don't think so. The story as I know it is that they just made threatening noises, and DRI knuckled under. DRI agreed to modify GEM to be less Mac-like (e.g. no overlapping windows), and that got Apple off their back. Atari's license pre-dated that agreement, I think. I'm just blabbering; I don't really know anything. Have your lawyers talk to our lawyers if you want facts and legal opinions rather than scuttlebutt. ------------------------------ From: Allan Pratt Subject: Re: TOS 1.4 /auto/ folder stuff Date: 11 Mar 91 19:08:18 GMT steve@thelake.mn.org (Steve Yelvington) writes: >I now have TOS 1.4, and I'm not sure what /auto/ folder programs >I ought to be using with it. FATSPEED apparently isn't compatible >or necessary. I have FOLDR200.PRG (probably overkill). I'm running >DCACHE 1.0f. Is there anything else I really ought to have? Yes, you should have POOLFIX3.PRG. This is a program which fixes a serious bug in GEMDOS. The bug doesn't bite all the time, but often enough and seriously enough that "Thou Shalt Run POOLFIX Under TOS 1.4 And 1.6" is a good commandment to have lying around. I don't know what DCACHE does, but it is probably different from what CACHEnnn does. CACHEnnn installs multiple cache buffers in GEMDOS. The resulting speedup in original TOS and Mega TOS (1.2) is small, but in TOS 1.4 it's great. Try this: do a "show info" on a hard disk from the Desktop once, then do it again on the same disk. If the second time didn't cause any hard-disk accesses, then you're in business. If not, use CACHEnnn (where nnn is three decimal digits, 080 is a good place to start). ------------------------------ From: T R Hall Subject: Re: ST Pad specs Date: 25 Mar 91 18:38:20 GMT ekrimen@ecst.csuchico.edu (Ed Krimen) writes: >johns@maccs.dcss.mcmaster.ca (Conan the Barbarian) writes: >- TOS with additional stylus features including mouse emulation and >- handwriting recognition. > >I don't know, but for some reason 'TOS with...handwriting recognition' >doesn't seem to jive, if you know what I mean. :^) >Thanks for posting the information. May I ask where you found it? I >just like to know the sources of these things. :^) You may feel skeptical, but as the designer of the two machines announced, I can tell you that "TOS ... with handwritting recognition" is FACT, not conjecture. The HCR code will be in the ROMs (and was, in the Demo at CeBIT), and tied into the operating system and desktop such that a gesture in the Menu Bar area will bring up a window (as invisibly to existing applications as possible) into which Hand-written characters are drawn. As you write, the characters are converted to ASCII; when you are satisfied, the characters are sent (via the Keyboard input stream) to the application. This way, _*existing*_ applications will have HCR capabilitites. The "hooks" to call the HCR system will be available to software developers, so they may call it directly, to recognize ASCII characters, special character sets, or even gestures. This will be part of the standard documentation. In case you're curious, the software is a neural-net simulation. TRH [ Incidently, "OCR" is "Optical Character Recognition" and "HCR" is "Handwritten Character Recognition"; the former uses the Bit-Map image; the latter uses the "pen-stroke" information directly.] ------------------------------ From: Allan Pratt Subject: Re: The cause of the phantom typist Date: 4 Apr 91 21:13:42 GMT micro@imada.dk (Klaus Pedersen) writes: >> To exorcise one may >> 1) Replace expressions like ++i; if(i == ANYPOWEROFTWO) i= 0; >> by ++i &= (ANYPOWEROFTWO - 1) >jan@janhh.hanse.de (Jan Willamowius) writes: > in what language do you want to write that? >What you are writing is : > ++i = ++i & (APO2-1); > - no matter how you try to hide it... That's not true. Semantically, "i += 2;" is equivalent to "i = i + 2;" but "++i += 2;" is not equivalent to "++i = ++i + 2;" because the people who designed C are smarter than that. The side-effect is performed only once. But regardless of that, you are suggesting that what happens in a C statement is uninterruptable, so doing something in a single statement makes it safe when it might be unsafe in multiple statements. This is not true. On the 68000 family, an interrupt can come between any two instructions. Individual instructions can't be interrupted, but the bus can be arbitrated away (for DMA, for example) between the read and the write of a read-modify-write instruction, except for the TAS instruction which is explicitly atomic. ------------------------------ From: Allan Pratt Subject: Re: Hardware -vs- Software Scrolling Date: 4 Apr 91 21:24:01 GMT >In article <150708@pyramid.pyramid.com> wniren@pyrtech.pyramid.com >(Walter "Crash" Nirenberg) writes: >>My question is what's the difference between scrolling routines written >>for an older system and a new system with hardware scrolling? Would I have >>to completely rewrite them to take advantage of the hardware or would it be >>a minor modification? vsnyder@jato.jpl.nasa.gov (Van Snyder) writes: >I've been using the raster operations in VDI and LineA, in the hope that the >OS will automatically take advantage of the hardware when it's there. If >I'm wrong, will somebody please post? You're wrong. The only hardware that can help raster operations is a blitter, and VDI/LineA automatically takes advantage of that when you do those operations. But "hardware scrolling" means something else. It operates on the entire display, not just pieces of memory. Hardware scrolling means that you have a "virtual display" which is larger than your physical screen. Imagine a large piece of paper with a smaller piece of glass on it. Your screen is a "window" onto the larger display. You can move the window around very quickly, in very fine increments, and this is hardware scrolling. The point is that you just bang a few registers rather than moving all 32K of screen memory to accomplish the move. (On the TT it can be 150K of screen memory!) (Of course, the piece of paper doesn't have to be as big as the world you're scrolling around in; it can be just a little bigger, and you can write the world in strips as it becomes visible.) Both the TT and the STe can move the window vertically on single-line boundaries, and the STe can move the window horizontally on single-pixel boundaries, but the TT can only move horizontally on 8-byte boundaries. This is eight pixels in the 256-color mode, but sixteen pixels in the 16-color modes, and sixty-four pixels in the monochrome modes. Hardware scrolling is only good for limited applications like paint programs where you want a canvas larger than your screen, or games where you want to scroll the player's view around in a larger world. Hardware scrolling CAN be used to make whole-screen scrolling faster. This is something you do in TOS programs when you're on the bottom line of the screen and you hit return. But that's another specialized operation, and it doesn't help such useful programs as Emacs, where some parts of the screen move and some don't. ------------------------------ From: apratt@atari.UUCP (Allan Pratt) Subject: Re: TOS 2.05 bugfix Date: 12 Apr 91 00:21:17 GMT larserio@IFI.UIO.NO (LarsErikOsterud) writes: >While testing out my new MEGA STE i discovered a nasty bug in one >of the Xbios routines (I can't understand why no beta-tester has). Maybe because it's not a bug. >The XBIOS 5 call setscreen(logadr,physadr,resolution) >is used to set screen adresses and change screen resolution. >The routine does NOT wait for vertical blank as it i supposed to >but resets the video in the middle of the screen, causing the >picture to wrap around the left edge of the screen in 50% of >the cases. This does not look good (you get the edge of the >grapic screen in the middle of the monitor screen :-) Thank you for starting a panic. I think it is not a bug but a problem with your Mega STe. I can not reproduce the "bug" you report. It might have occurred to you that your Mega STe is to blame, not TOS. Your lack of understanding of the reasons for the protection code in the ROM has led you to a false conclusion. To nip this in the bud, I'll explain. The shifter mode must not be changed during a critical moment around vertical blanking. Previously that was avoided by waiting for the vblank interrupt, which ensures that the critical moment has passed. The new code uses another method: it checks to be sure that you are in the middle of the screen someplace, not in vblank. The upshot is the same: you avoid the window of vulnerability. If you had named the programs that caused trouble this would have been a more useful bug report. It is possible that there is an interaction between those programs and the new code. Please post or mail me the names of those programs. If this turns out to be a real live software bug, I will eat my words. (Lars-Erik has responded to me in mail about the programs (e.g. Degas Elite) and I have suggested that he return the machine to his dealer. This posting is for everybody else, so you don't think we're totally out to lunch when it comes to testing software.) ------------------------------ From: Allan Pratt Subject: Re: Ptermres() Date: 11 Apr 91 21:19:08 GMT >wolfram@tschil.informatik.rwth-aachen.de (Wolfram Roesler) writes: >... and then terminates via Ptermres(0,0) ... csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: >If I'm wrong here, Allan Pratt >will certainly correct me in an instant 8-) Did I hear my name being called? Ptermres(0,0) is unsafe. Your TPA is shrunk to zero size (or freed) before the terminate happens, and therefore you are relying on the contents of memory that nobody owns: the contents of your basepage to process the terminate. This is bad news. Don't do it. The minimum size argument to Ptermres should be $80 (the size of your basepage, up to the command line). This wierd case is not one the authors of GEMDOS (including me) anticipated, so it's not enforced or anything. I guess it could be. Of course, people frequently *do* rely on the contents of memory that nobody owns, but it's not SAFE. In particular, that address may have no meaning any more in a VM system. ------------------------------ From: Allan Pratt Subject: Re: How store extra data at the end of an executable? Date: 12 Apr 91 21:09:38 GMT >erik@mcrware.UUCP (Erik Johnson) writes: >Here is what I would like to do. I would like to append a picture file to the >end of my executable file. In this case, the extra data is a picture file that >is the menu for my program. Once a program is loaded into memory, is it closed >and all file offset information lost, or is there a way I can start reading >data from the file where the program data left off. wolfram@ikki.informatik.rwth-aachen.de (Wolfram Roesler) writes [some stuff based on wierd and wrong guesses about how things work]. You can't just tack the picture data onto the program file after the program's data segment, because that would mess up the BSS segment. I reiterate: you should not try to "append a picture file to the end of [your] executable file" but rather "arrange for a picture file to be included in your program file." This you can do, in the worst case, by turning the picture file into an assembly (or C!) source file, assembling (or compiling) it, and linking with the resulting .o file. Example using my DB (it doesn't matter what compiler you ultimately use): :read picture.neo :transcript mypic.c :dw(+ `rwstart 4)[@32] ; dw(+ `rwstart 80)[@32000] :transcript off Now, in mypic.c, there's a top line you should delete ("dw..."), two lines' worth of palette data, and 2000 lines' worth of picture data, followed by another line you should delete ("transcript off"). You have to edit the file to remove the address and ASCII fields from the dump, and prefix each number by "0x", and put commas between them, and now you can wrap them in to C as array initializers, so the result looks like this: short paldata[] = { 0x0777,0x0007,0x0070,0x0700, ..., ... }; short picdata[] = { 0x ... }; and now you can compile this file, link with it, and use the symbols paldata and picdata in your program. ------------------------------ From: Allan Pratt Subject: Re: Porting from MWC code Date: 12 Apr 91 21:15:13 GMT bill@mwca.UUCP (Bill Sheppard) writes: >I'm in the process of attempting to recompile MicroEmacs 3.11 to make some >changes (remove mouse support so I can use within a CLI, for one). I will be doing that for Dan (making it truly conditional on the compile-time symbol "MOUSE") before the true 3.11 release. I tell you so you know you're probably duplicating the effort. >source code appears to expect Mark Williams C, but I'm using Sozobon (also >have Alcyon). So far I've seen two compilation (haven't tried linking yet) >errors: the structure DMABUFFER is expected in stat.h, the Sozobon stat.h >doesn't reference it, and "aesbind.h" is expected, which also isn't in the >Sozobon or dlibs distribution. Any ideas how these can be compensated for >or where I might find AES bindings (are they in another .h file?) This Emacs for the ST is GREAT, but the portability stuff is TERRIBLE. If you're on an ST, the code only works for ST520 and ATARI and MWC. If you want to do something different, like a different compiler, you're in for trouble. Basically, you should leave MWC and ATARI and ST520 defined and then and remove code as necessary for your compiler. DMABUFFER is the MWC name for the DTA structure; it's only used in getffile and getnfile. Substitute the DTA struct from your compiler (check osbind.h or make your own) and fix the field names in the defines that have "info" in them. As for aesbind.h, it might be called gem.h or gembind.h. It has the AES structure and constant definitions, the companion to vdibind.h. ------------------------------ From: apratt@atari.UUCP (Allan Pratt) Subject: Re: Problem with my C program [a few general hints about malloc] Date: 25 Apr 91 20:50:24 GMT steve@thelake.mn.org (Steve Yelvington) writes: >[In article <1991Apr22.014758.3846@wam.umd.edu>, > dmb@wam.umd.edu (David M. Baggett) writes ... ] >> If you want to allocate more memory than can be specified in an unsigned int, >> use calloc. It takes two parameters which are multiplied together to get >> the size of the requested block. To allocate 128K: >> >> p = calloc(128, 1024); In general, this is not a fix. I have seen allocators which call malloc from calloc after multiplying the two args together AS INTS, not longs. So this does you no good at all. Some compilers work and some don't in this respect. You pays your money and you takes your chances. >You also can use lalloc, which works like the library malloc() >function except that it requires a long argument. (Be sure to include >malloc.h when calling any dynamic memory management functions.) Much better solution, if your library has lalloc. Some have lmalloc, so try both. (I forget if the original poster said what compiler/library he was using.) >> In general it is VERY WISE to avoid using the bios Malloc and Free and >> use the malloc, calloc, and free provided with your compiler of >> choice. Humph. TOS 1.4 and upwards have NO PROBLEMS with Malloc that have been reported to me. ------------------------------ From: Allan Pratt Subject: Re: Weird TT hard disk thingy Date: 29 Apr 91 17:15:23 GMT cummins@unx2.ucc.okstate.edu (John Cummins) writes: >On my Mega ST... I have no SCSI 0 drive. I use scsi 4 and 5 so I can >daisy chain a friends scsi 0 drive and still access my own disks. >But I can still boot... and use my hard disks w/o any SCSI 0 device >attached. >The fellow you've been chatting with says the TT won't recognize SCSI devices >1-7 on the ASCI bus, at least not without an SCSI 0 in place. Device 0 MUST >be used for the first device. Why???? [Am I "the fellow [he's] been chatting with"?] I can't speak for what SCSI unit numbers ICD or Supra adaptors will or won't recognize. From the data presented here, it sounds like ICD will handle any SCSI unit number on the drive, and Supra will only talk to SCSI unit zero. The latter is not unreasonable -- if you've got only one drive on a SCSI-to-ACSI converter, why include the logic to talk to an arbitrary SCSI device number? It would mean logic in the adaptor to see what SCSI drives are out there. I have even heard of some adaptors which look at the SCSI unit number of the drive that's connected, and configure themselves as that ACSI unit number, further confusing the issue. As for the ST/TT side of the bus, you have to start with zero on each bus and increment by one for each drive you connect to that bus. (Remember, that's unit numbers as the computer sees them, not as the adaptor sees the disk it's actually talking to.) The reasons for this are kind of involved, and I don't want to go into them; just take my word for it and carry on. I hope this clears up the questions about busses and unit numbers, and we can get on with our lives. ------------------------------ From: Allan Pratt Subject: Re: *** HELP! Annoying Verticle line screen garbage! *** Date: 29 Apr 91 17:20:44 GMT sean@ccwf.cc.utexas.edu (Sean Sterling Foiles) writes: >Occasionally my ST Color Monitor SC1224 fills up with vericle lines along >the left side of every other character column. In lo rez that means 20 >verticle lines, in med rez it's 40. That's "vertical," not "verticle." Take your machine to a dealer. There's something wrong inside. A dealer should be able to diagnose, attempt a fix, and ultimately repair or replace the motherboard. If the machine is out of warranty he will probably want to charge you something. Let him. ------------------------------ From: Allan Pratt Subject: Re: Can't get Setpallete() to work. Date: 29 Apr 91 17:27:48 GMT marco@sys6626.bison.mb.ca (Marco) writes: >Here's the code I've been trying to use to blank (black) my screen: >---------------------------------------------------------------------- >#include >#include >main() >{ >int i, pal; >for (i=0;i<16;i++) > pal = i; >Setpallete(pal); >} This won't work because Setpallete (sic) takes a LONG argument which is a POINTER to an ARRAY of 16 INT's. Check those types in the documentation! If you look at your code again I think you'll realize that it doesn't make any sense at all. main() { int i, pal[16]; for (i=0; i<16; i++) pal[i] = 0; Setpallete(pal); } Setpallete is a misspelling of Setpallete, and is that way because Atari's original docs and include files spelled it wrong in the first place. As has been pointed out, this is now retained by most compilers. A caveat for Setpallete users: the above program is unreliable because Setpallete copies its argument to a variable, and the palette registers are loaded from the 16 int's found there AT THE NEXT VBLANK. Since the above program has terminated by the time the next VBLANK rolls around, that means this memory is not owned by anybody, violating the commandment "Thou shalt not mess with memory thou ownest not." I know the "program" is just an example of this poor slob's problem, but it bears repeating that Setpallete is a delayed-action call. ------------------------------ From: Allan Pratt Subject: Re: TT ROM Date: 2 May 91 18:02:12 GMT kimmo@field.fi (Kimmo Lahtinen) writes: >Here in Finland we are getting TT's with Swedish ROM, >and there seems to be some problems in them. Also >my friend does not like so much for Swedish as language >for a computer. So I would like to know if it would >be possible to have an English TOS for TT. I mailed this guy details on Atari Sweden, but this part is meaningful for everybody: The only differences between Swedish TOS and English TOS are the keyboard mapping and the text in the Desktop. The underlying code is all the same. If the problems have to do with keyboard mapping or text, then a different country could make a difference, but if the problems are anywhere else, you should describe them so we can decide if they're TOS bugs. It may be that what you've encountered is already fixed. There have been updates to TT TOS; the current release is 3.05. ------------------------------ From: Allan Pratt Subject: Re: Weird TT hard disk thingy Date: 3 May 91 18:09:56 GMT boyd@nu.cs.fsu.edu (Mickey Boyd) writes: >The DMA port on the back of the TT >is handled differently than that on the various ST's, and this could cause >an hard drive set up (and working) on an ST to fail (with very little >explanation from the Atari HD software). A phrase like "The DMA port on the back of the TT" encourages misunderstanding: there are TWO DMA ports on the back of the TT; one is ACSI and one is SCSI, and you should make that distinction explicit when you talk about the TT. In any case, you are mistaken. A working setup on an ST will work fine on a TT. What part of this conversation makes you think it won't? The only oddity will be that SCSI drives (like the internal one), if present, will have their partitions appear first in the sequence of drive letters. But if you have a working chain of drives coming out of your ST, and you unplug the end of the chain from the ST and plug it into the TT, all those drives will be accessible and will work just fine. ------------------------------ From: Allan Pratt Subject: Re: TT questions Date: 3 May 91 18:12:48 GMT D.C.Halliday@newcastle.ac.uk (Dave Halliday) writes: >Is it realy true that the TT can only run Unix OR TOS but not both. I do not >meen that they should run Unix and TOS at the same time but be bootable >between the two different OS's. No, it is not true. Any production TT can be booted in either TOS or UNIX. UNIX, of course, is not yet a product from Atari, but there is no distinction between a TOS TT and a UNIX TT; it's all in the software. ------------------------------ From: Allan Pratt Subject: Re: Dfree() void? Date: 2 May 91 18:03:34 GMT ONM07@DMSWWU1A.BITNET (Julian F. Reschke) writes: >The GEMDOS funtion Dfree() is documented to be void ('GEMDOS Reference >Manual'). In practice, it SEEMS to return useful return codes (like BIOS >error codes). The manual is wrong, in more places than one. Yes, Dfree() is not void. Never has been. ------------------------------ From: Allan Pratt Subject: Re: Which monitors can use TT high res? Date: 8 May 91 20:07:07 GMT >In article <1991May6.010100.9329@noose.ecn.purdue.edu> yegerleh@vivaldi.ecn.purdue.edu (James D Yegerlehner) writes: >>I know that the TT has a really high-res mode (more than a 1200 by >>600? pixels), and I know that Atari is (or will be) selling a rcb@netcom.COM (Roy Bixler) writes: >I read it was 1200x960. >Along the same lines, does Atari sell a monitor that can take >advantage of the 1200x960 monochrome and the 640x400 color mode? If >there's no Atari monitor which does this, are there any multi-sync >alternatives? Enough of this misinformation. TT high rez is 1280x960, an industry standard. This resolution requires a monitor along the lines of the Moniterm Viking. (I don't know if that particular model actually works, but you need something like it.) Atari either sells or is planning to sell such a monitor. I don't have any real information on our marketing plans in that direction: I just don't know. This type of monitor can't show any of the other TT or ST resolutions, and no Atari monitor which can show the other resolutions of the TT can show TT High. In that respect this is like the ST: ST REZ X,Y,COLORS MONITOR REQUIRED ST LOW 320,200,16 ST color monitor ST MED 640,200,4 ST color monitor ST HIGH 640,400,bw ST mono monitor TT REZ X,Y,COLORS MONITOR REQUIRED (all ST modes above) TT color monitor TT LOW 320,480,256 TT color monitor TT MED 640,480,16 TT color monitor TT HIGH 1280,960,bw high-rez monitor I am speaking only for monitors that Atari sells and uses. I guess there are monitors which you can hook up to ST's and see all the ST modes. There may be monitors that can show all six resolutions of the TT. I suspect such a monitor would be hellishly expensive -- moreso than the 1280x960 monitor, which is not cheap. Another note: ST HIGH on the TT is actually a color mode: you can choose any two colors, not just black and white. ------------------------------ From: Allan Pratt Subject: Re: TOS filing system for MiNT Date: 15 May 91 16:51:12 GMT dpg@cs.nott.ac.uk (Dave Gymer) writes: >I'm about to start work on an MeSsy-DOS filing system for MiNT, and would >appreciate some advice about the way it should handle filenames. Before you "start work" please check to see if TOS's and MiNT's own filesystem isn't what you need. They *are* MSDOS compatible. You can take TOS disks and use them on PC's. Well, that's not quite true. They have to be formatted by a program which does an MS-DOS compatible format. The difference is a couple of bytes at the beginning of the boot sector. Original TOS didn't set that up the way MSDOS needed. New TOSes (1.4 and greater) do. Other people's formatters, like DoubleClick, let you select this as an option. There is no difference at all in the data part of the disk, only a couple of bytes in the first sector which we ignore and they use. Sometimes you can format a disk on a PC and use it on an ST. You can certainly READ the disk on the ST. You can't WRITE it unless the disk was formatted with two FATs. Some newer MSDOSes think they're doing you a favor by writing just one FAT. If you have one of those, use the option to FORMAT which says, "Put two FATs on the disk." Aside from these details of formatting (which are not minor), the TOS and MSDOS filesystems are identical, files, subdirectories, and all. ------------------------------ From: Allan Pratt Subject: Re: GCC compile error Date: 16 May 91 20:46:26 GMT wolfram@akela.informatik.rwth-aachen.de (Wolfram Roesler) writes: >I had that problem too. It seems that gcc had not fully been ported from >Unix, so some filespecs still use slashes. >However, the slashes arent really the problem since TOS can deal with >filenames containing slashes. This is not the case. TOS can't deal with filenames containing slashes. What CAN deal with them is programs compiled with Bammi's GCC libraries (or the MiNT libraries, which is almost the same thing). This guy's problem is that drive D: doesn't contain a directory called tmp in its root. ------------------------------ From: Ken Badertscher Subject: Re: Weird TT hard disk thingy Date: 16 May 91 19:51:16 GMT Roger.Sheppard@bbs.actrix.gen.nz writes: |I don't think you should be rail roaded in what Atari gives you, I |believe in freedom of choice, and not this dogmatic attitude that Atari |gives you. Precisely. You are free to use whatever hard disk driver software you desire. If you want to use the Supra software, buy a Supra drive and use it. If you want to use the ICD software, buy an ICD drive or host adapter, and enjoy yourself. Likewise, Atari should be free to choose whether or not to follow a "standard" created by a third party. Some such standards are hacks, some are good ideas, some have a core of good ideas with a lot of extra nonsense that Atari doesn't need in a standard. The bottom line for us is that it doesn't matter what standard we decide on, some people will be unhappy with our decisions. That's something we live with. You can't please all the people all the time. You can't please all Atari users hardly ever . ------------------------------ From: Ken Badertscher Subject: Re: Force Desktop Res Change? Date: 16 May 91 19:41:29 GMT csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: |There seems to be no easy way to do this with an AUTO folder program - |AES overwrites any changes, and so you have to write a TSR that waits |for AES to come up and then re-vectors trap #2. Nope. I don't know where this rumour came from, but it's been flying around for some time now, and I've run into it about 3 times in the past month, so it's time to start spreading facts. Nobody should be touching trap #2 on a res change. Think about it for a minute: if trap #2 got taken every res change how could GDOS possibly work? Assemble the following, put it in your auto folder, and change res a couple dozen times. You'll see that the trap #2 counter in the upper left corner of the screen keeps on ticking... ; TAKE2.S - count trap #2's, even after res change. trap2vec = $88 _v_bas_ad = $44e start: pea take2(pc) move #$26,-(sp) trap #14 ; Supexec(take2) addq #6,sp clr.w -(sp) move.l #($100+fin-start),-(sp) move.w #$31,-(sp) trap #1 ; Ptermres(0,size) take2: lea save2(pc),a0 move.l trap2vec,(a0)+ move.l a0,trap2vec rts save2: dc.l 0 do2: move.l _v_bas_ad,a0 addq.l #1,(a0) move.l save2(pc),a0 jmp (a0) fin: .end ------------------------------ From: Ken Badertscher Subject: Re: Traps on Resolution Change Date: 16 May 91 20:01:48 GMT Desk accessories should not steal trap vectors. This is not to say that lots of DA's (desk accessories should not steal trap vectors) that are already out there don't take vectors, but (desk accessories should not steal trap vectors) it really isn't a recommended thing. Desk accessories, as we all know, are (desk accessories should not steal trap vectors) accessories, side-liners, assistants, and as such (desk accessories should not steal trap vectors) they don't warrant the same considerations (desk accessories should not steal trap vectors) as main-line applications. As Julian R. (hi, Julian!) has recently pointed out (desk accessories should not steal trap vectors), things that take vectors really belong in the AUTO folder. TSRs should be the ones (desk accessories should not steal trap vectors) setting up resources like this, and they should use the Cookie Jar to communicate with other programs. ------------------------------ From: Ken Badertscher Subject: Re: TRAP #2, Form_doit Date: 16 May 91 20:06:38 GMT cmedley@wam.umd.edu (Charles Henry Medley) writes: |Incidentally, I understand that the new Atari Control Panel has hooks into |the AES for a modified form_do call that doesn't "lock up" the system. Does |anyone know if it is legally patching into TRAP #2 or if it is actually a |new form_do handler in the ROMs? No hooks, just a library routine that is also available to CPX's, since they run as little pieces of XControl. ------------------------------ From: Allan Pratt Subject: Re: TT VME Bus Date: 20 May 91 17:11:08 GMT baffoni@aludra.usc.edu (Juxtaposer) writes: > Is it possible [to make] an accelerator card that uses >the buslines available on the VME/Atari (TT/mega)bus slots? Like for instance >a 68040 board that takes over the machine and delegates the on >board cpu as an I/O handler ... ? No, it's not, because the things that can go on the VME bus in the TT can't be bus masters. The TT's VME bus is slave-only, meaning the motherboard can instigate an access to the VME board, but not the other way around. It is not unreasonable to suppose that future Atari machines may have full-blown VME where the VME boards can be bus masters, and then you could do this. >Dave Small has already shown that it's possible >for the ST...:) No, he shows that it's possible to wire a 68030 into the ST. I don't know how he tells the 68000 to go to sleep; maybe you have to cut the whole thing loose, maybe you just have to cut a few traces (like power and ground :-) to get it out of the circuit. ------------------------------ From: Ken Badertscher Subject: Re: How can I use the 6x6 ROM font? Date: 20 May 91 18:06:59 GMT Use vst_point(). Setting the point size to 8 will get you the 6x6 system font, 9 will give you the 8x8 font, 10 the 8x16 font, and 20 the 16x32 font (if you're running under TOS 2.0x/3.0x). ------------------------------ From: Allan Pratt Subject: Re: Disabling FAT/Directory cache Date: 28 May 91 19:04:36 GMT danny@fiction.ms.sub.org (DanielRoedding) writes: >7103_2622@uwovax.uwo.ca (Eric Smith) writes: >> Is there a nice way to tell TOS (version 1.4 and higher) *not* to >> cache a drive? I want to share a drive over a network; clients >> will see the drive as read-only, but I'd like the server to be able to >> write to the drive. >Since you have to write a little device driver, you also have to take care >of the media change state. If you return 2 all the time at Mediach() calls, >TOS should not keep old information it it's caches. If you return 2 on every call, then you could never do anything: 2 means HAS CHANGED, and all open handles on the drive are closed. Subsequent accesses with those handles would return EIHNDL (invalid handle). Even if you return 1 and find that GEMDOS always re-reads the sectors, this will be REALLY SLOW, because TOS uses Mediach() to validate its cache buffers, and it happens A LOT in some cases. Example: for each Fsfirst/Fsnext call in a directory search, you'll get at least one Mediach() call. If you actually had to read the sector over the net for each call, it would be unbelievably slow. I don't know a way to cache a drive from outside. You're better off using MetaDOS to catch the calls at the filesystem level rather than the BIOS level. If a call is destined for a remote filesystem you make it a remote procedure call at the top level, not the record level. Eric, aren't you running MiNT? You already have the capability: just mount it like you do a Minix filesystem and make remote procedure calls at that level. You could even do local caching and make remote calls like, "Are my cached buffers still valid?" to reduce your net traffic. ------------------------------ From: Allan Pratt Subject: Re: TT VME Bus, and extending it Date: 28 May 91 19:10:08 GMT pegram@kira.UUCP (Robert B. Pegram) writes: >[T]he TT's VME bus is only D(ata)16(bits), A(ddress)24 (one vme >connector), which is fine for a Mega STE, but you need D32, A32 to >really handle an 030. I'm also not completely clear whether VME >supports Bus mastering properly ... The VME in a TT and a Mega STe is indeed A24/D16. In addition, it is slave-only: the VME board can't be a bus master. It is not unreasonable to suppose that a future machine from Atari might have full-sized VME with A32/D32 and full bus mastership. I have seen at least one product where you put the TT in a card-cage and get larger-sized VME connections (6U; the TT only has 3U) but the bus is still the same. The only difference is the physical size and shape of the VME cards you can plug in. There is lots available in A24/D16, especially if you aren't limited to 3U (as the TT and Mega STe are), but as I said, the VME card(s) can't be bus master(s) in the current machines. ------------------------------ From: Allan Pratt Subject: Re: Atari TT Date: 3 Jun 91 20:20:26 GMT baffoni@aludra.usc.edu (Juxtaposer) writes: > From the discussion on c.s.a.st a while back with Alan Pratt, I believe he >said that you can only have 4MB _ST_ ram. You can have 16 MB TTram like you >said, but that the other 6MB of ram comes from using the VME bus for ram >expansion. In fact, the VME ram is supposed to be faster than STram (no >sharing it with video, etc.), even though it is slower than TT ram. No, no, no... Your picture of memory in a TT and its limits is a little off. On the motherboard there are two megabytes of ST RAM. Period. No options, no extra SIMM or DIP sockets, no nothing. You can buy a 2MB ST RAM add-on card, for a total of 4MB of ST RAM. There may one day be an 8MB ST RAM add-on card, resulting in a total of 10MB of ST RAM. You can buy a 4MB TT RAM add-on card. It may be that, with some work, you can make this address 16MB of TT RAM. In future (now?) you can buy 16MB of TT RAM from Atari -- I'm just not sure. All of these boards are more than just RAM -- they also have memory controllers which you can't just get off the shelf. In the TT030, there is one VME slot, but it is not appropriate to put system expansion RAM there. The slot is for peripherals, not RAM. If you DO put RAM there, you have to tell the OS about it yourself, and it will be slow: it's not cacheable, it's only 16 bits wide, it's on the VME bus, and it's not SCSI-accessible (meaning transfers have to be use SCSI-accessible RAM; this is taken care of in the drivers, but it slows you down). I've put memory there to test things, and it is not fun. Things run DRAMATICALLY slower from that kind of RAM. It is not unreasonable to suppose that Atari may, in future, come out with a machine in the TT family which has full-featured VME, including the ability to put 32-bit, cacheable, OS-detectable, SCSI-accessible RAM on the VME bus. The TT is designed with this in mind, but the actual VME bus in the TT030 isn't capable of it. Such RAM would be slower than TT RAM (mainly because you can't do burst fills on the VME bus) and about the same speed as ST RAM: faster because it's not shared with video, but slower because it's on the VME bus. ------------------------------ From: Allan Pratt Subject: Re: Does TT monitor have sound? Date: 12 Jun 91 18:36:05 GMT d90-ngp@sm.luth.se (Niklas Grip) writes: >Is it usual that multisync monitors don't have loudspeakers and >whatabout the TT? Yes, it's true that most monitors don't have speakers. The TT has a speaker built in. It also has stereo output jacks on the back so you can hook it up to an amplifier and speakers, and you can turn off the internal speaker if you want. The idea is that the internal speaker can be used for normal stuff like beeps and bells, but for high-quality digitized sound you're likely to want to use the stereo outputs. The digital sound always goes to the stereo output jacks; you can control whether the PSG sound (clicks and beeps) also goes there. ------------------------------ From: Allan Pratt Subject: Re: 1024-byte floppy sectors? Date: 17 Jun 91 20:12:42 GMT adamd@rhi.hi.is (Adam David) writes: >TOS uses a BPB to handle various media specifications. The floppy driver / >filing system must use 1024-byte cluster buffers for the standard format. >Why should it not be possible with standard TOS to use 1024-byte clusters >of one sector each? What modifications do I need to make to TOS in order to >use the larger sectors with it? >Any thoughts / suggestions welcome. You are mistaken in your belief that TOS keeps cluster buffers around. It doesn't. It keeps SECTOR buffers around. The floppy BIOS assumes sectors are 512 bytes long. GEMDOS does not, and hard-disk partitions larger than 16MB are implemented using large logical sectors (but not large physical sectors) with appropriate values in the BPB. To use 1K sectors on floppies you would have to replace the floppy BIOS completely, and include in your TSR a routine which replaces GEMDOS's sector buffers with new buffers large enough to handle the largest sector size in your system. This is what the hard disk driver has to do (except that instead of replacing the floppy BIOS it's installing the hard-disk BIOS). ------------------------------ From: Allan Pratt Subject: Re: TT beginner questions Date: 18 Jun 91 20:27:44 GMT friedric@r2d2.fmi.uni-passau.de (Carsten Friedrich) writes: >Does anyone have some TT documantation, e.g. new tos-routines and > hardware - registers ? If you only have them on paper, i would give > you some money for stamps, if you send them to me. (send e-mail for > adress) These kinds of documentation are available to developers through the Atari. Call Gail Johnson at (408) 745-2022 for information on becoming a developer. >My version of Mint (0.6) does not seem to work with the TT is there a version > that does ? The latest one, 0.8, does. However, there are some problems in exception handling. 0.7 worked better, but I don't know if the released version of 0.7 had the TT modifications. >Is there a switch for gcc (my version is 1.39) to use 68030 code, to use the > co-processor and the full TT memory ? Yes, use -m68020 and -m68881 on the GCC command line, and use PRGFLAGS.PRG (freely copyable, available on GEnie at least) to set the program-load and malloc bits so your program can see all TT memory. >I tried to connect my external 5 1/4'' floppy i used with the st to the tt > but failed. any ideas why ? (i just pulled the plug out of the st > and into the tt, but the tt couldn't handle it. :( ) Don't know why. Should have worked. Do you use a hack program to change the seek rate, or a program that makes the Floprate() XBIOS call? In the former case the program is probably TOS-version-specific, and in the latter case it should work. ------------------------------ From: Allan Pratt Subject: Re: Mega STe Questions Date: 21 Jun 91 16:47:58 GMT >In article <1991Jun19.114741.11944@informatik.uni-erlangen.de>, >csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: >> The 68881 is optional. The Mega STE's FPU is programmed just like >> the FPUs available for the standard Mega, so there should be some >> development packages supporting it. This is correct. stigvi@Lise.Unit.NO (Stig Vidar Hovland) writes: >How is it programmed on a standard Mega? Will programs written for the >TT and 68882 run correctly on a Mega STE and 68881? No. The 68030 communicates with the FPU as a coprocessor. You use instructions like "FSIN fp0,fp1" and the CPU communicates directly with the coprocessor, telling it to take the sine of FP0 and put the answer in FP1. (FP0 and FP1 are floating-point data registers in the FPU.) The 68000 does not have this ability. With a 68000 the FPU is a peripheral, like the sound chip or floppy-disk controller: it takes many regular 68000 instructions to read and write I/O ports on the chip to get it to do what you want. You have to do it "by hand" instead of having the CPU do it for you. Thus, it is slower and your program is larger than it would be using 68030 FPU instructions. What Claus is saying is that there is an FPU peripheral that plugs into the Mega ST (called the SFP004), and there is an FPU that comes with the Mega STe, and they interface the same way. They both interface in the "peripheral" way, because that's the only way the 68000 can handle. This means that a program (or library) that runs on a Mega using the SFP004 will run on a Mega STe and use its built-in FPU. In the TT the FPU interfaces in the "coprocessor" way, so these programs won't work. ------------------------------ From: Allan Pratt Subject: Re: 1024-byte floppy sectors? Date: 24 Jun 91 18:18:12 GMT Roger.Sheppard@actrix.gen.nz (Roger Sheppard) writes: >> ...and hard-disk partitions larger than >> 16MB are implemented using large logical sectors... > ^^^^ >Correct me if I am wrong, but should this not read 32MB ?, I thought >that this was a typo that caused this problem and was fixed in TOS 1.4 It may or may not have been fixed, but because even people with TOS 1.2 and (gasp!) TOS 1.0 want to be able to use large partitions, HDX goes to BGM at 16MB for maximum compatibility. Otherwise you could take a 31MB, non-BGM partitioned disk to a machine running TOS 1.2 and not be able to get at the files. ------------------------------ From: Allan Pratt Subject: Re: Writing to read-only files Date: 8 Jul 91 19:00:16 GMT danny@fiction.ms.sub.org (Daniel Roedding) writes: >ue@nathan.ruhr.de (Udo Erdelhoff) writes: >> In <91186.104812ZVD007@DMSWWU1C.BITNET>, U.Kuehn writes: >> >Yesterday, I discovered that maccel3, the mouse-accelerator of atari, >> >which saves the configuration in its program-file, uses Fopen with the >> >mode readonly to open that file and writes then the data via Fwrite into >> >it. Is that the correct way???? And why is there no error returned by GemDos? >> Nope, that's not the correct way. GemDos doesn't care about it and fixes this >> internally, KAOS won't accept it... >Some networks also can be crashed with this. They just check for read/write >permissions when *opening* the file. If you have read-only access, open the >file for reading (correct so far) and write something into it, some programs >(PAMs Net... :-) won't recognize it. >Even worse: You can manipulate files marked as read-only if you just open >'em for reading and then write... >BTW: Are you allowed to change the date/time stamp with Fdatime() when >you open a file just for reading? GEMDOS allows it, but is it logically >correct? >Daniel Sigh. As everybody knows by now, GEMDOS does not check the mode you opened the file in when you try to write to it. You can read from a file you've opened for write-only, too. This is a bug, but it's the kind of bug we can't really fix. Perfectly reasonable programs and programmers have made this mistake, and their programs work because GEMDOS has never checked this. Fixing this bug means these working programs will break. I don't think the win is bigger than the lose. Naturally, nobody should rely on this bug on purpose. In the case of networking, where you implement access rights more strictly than GEMDOS does inherently, I think checking the open mode before allowing a read or write is perfectly reasonable. I am surprised that KAOS to "fixes" this bug because it can make an otherwise-OK program "KAOS incompatible." I would be interested to know how many programs actually rely on this bug, and break under KAOS for that reason. (Of course, KAOS isn't sanctioned by Atari in any way, and my understanding is that it might be illegal; it certainly is if it's a hacked version of TOS, as opposed to a complete rewrite without any Atari code or influence.) ------------------------------ From: Allan Pratt Subject: Re: XCONTROL MODEM ACC BUG Date: 8 Jul 91 19:06:17 GMT steve@thelake.mn.org (Steve Yelvington) writes: >[neil@cs.hw.ac.uk (Neil Forsyth) writes ... ] > > I was quite surprised. I have since been told of TOS14FX2 (Atari US) and > > TOS14FX5 (Germany). Both of which I will try ASAP. >Since it's a very short file and *lots* of people will need it, here >is TOS14FX2 (the official Atari Corp. version). The doc file >specifically mentions the problem you had with XCONTROL.ACC. Thank you for posting this, Steve. I would have done it, but I have been on vacation. I approve of (re-)posting small, freely-copyable, important Atari fixes to the net when there is a demand like this. If you ever wonder if something is freely copyable, the best place to check is GEnie: if it was uploaded to the Atari Roundtable (*not* the Atari Developer's Roundtable) by somebody like Mike Fulton or ATARIDEV (J. Patton) or Bill Rehbock, you can reliably say that it's official and freely copyable. XCONTROL itself falls in this category now, and it's available on Atari Archive. (The A.A. people asked me about another XCONTROL version, ostensibly from Atari France, and I had to say that it should not be made available: even if XCONTROL is freely available, and even if it was the genuine article and not an older rev or something, this other archive was probably just a collection of stuff and not "the official release archive." It makes a difference.) ------------------------------ From: Allan Pratt Subject: Re: Writing to read-only files Date: 10 Jul 91 20:17:16 GMT >In article <2978@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >>Fixing this bug means these working programs will break. I don't >>think the win is bigger than the lose. Naturally, nobody should rely on >>this bug on purpose. >> boblu@tekgen.BV.TEK.COM (Robert Luneski) writes: >This is utter bulsh*t rationalism. Actually, I think you meant "a rationalization," not "rationalism." I would say that it is EXCELLENT rationalism: it is rational for you to to be conservative in what you demand of the machine and OS, and for me to be liberal in what the machine will allow. >IMHO any programmer who opens a file Read-Only >and then writes to it deserves to have the program break. If it were your program, or a program you use and rely on, you might not feel that way. I am reluctant to fix this because I don't know what programs will break. It could be just a few little hacks, and it could be some big title which would cause a huge uproar. Who can tell? ------------------------------ From: Allan Pratt Subject: Re: TT memory allocation Date: 9 Jul 91 17:04:46 GMT martin@minster.york.ac.uk writes: >OK so far. My problem is that I can't find anywhere a description of >*which bits* in the program header contain this information! [about >allowing program load and malloc to come from TT RAM] I think it's there somewhere, but it's easier to answer this than find it myself and tell you where to look. One of the previously-unused longwords in the program header has been assigned a meaning as of TOS 1.4. The least significant bit of this longword is a flag which, when set, says "don't bother to clear the whole TPA, just my declared BSS." The next-least significant bit declares that the program may be loaded into alternative RAM (that is, non-ST RAM) and the next bit declares that alternative RAM is eligible to satisfy Malloc calls. The high byte of the longword has another meaning (too arcane to go into here) and the other bits are reserved. This longword is at offset $16 from the start of the program file. Thus, the program header looks like this: struct prg_header { short magic; /* always $601a */ long tsize, dsize, bsize, ssize; /* segment sizes */ long unused; /* unused */ long prgflags; /* described above */ short absflag; /* if nonzero then no fixups */ } I think program appeared recently in c.[sb].a.st which lets you set the bits in prgflags. ------------------------------ From: Ken Badertscher Subject: Re: Writing to read-only files Date: 14 Jul 91 04:41:44 GMT Yep, sure enough, MACCEL3 updates its configuration by opening the file in read-only mode. Oops. 50 lashes with a wet noodle for me. I really do need to fix that (and other minor MACCEL glitches), one of these days when someone sends me a case of round tuits. ------------------------------ From: Ken Badertscher Subject: Re: Determining available font sizes Date: 14 Jul 91 04:18:30 GMT tolk@opal.cs.tu-berlin.de (Robert Tolksdorf) writes: |... the idea |is that vst_point yields the next available font-size smaller-equal i. |But this does not work, when scalable fonts will be available. Checking font sizes still works with FSMGDOS, and it is still important. The effects buffer used for algorithmic text effects (such as outline, bolding, etc.) is based on the largest font size in the FSMGDOS configuration file (EXTEND.SYS). A program should not use algorithmic special effects for point sizes larger than the largest returned by vst_point(). The important thing is that it's not necessary to check *all* point sizes available under FSMGDOS, for obvious reasons. But it still works, for compatibility with non-FSM-aware programs, and it's still important to find out the largest point size you can get from vst_point(). ------------------------------ From: Allan Pratt Subject: Re: Writing to read-only files Date: 15 Jul 91 17:51:01 GMT >In article <2986@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >> ... I am reluctant to fix this because I don't know what >>programs will break. It could be just a few little hacks, and it could be >>some big title which would cause a huge uproar. Who can tell? neil@cs.hw.ac.uk (Neil Forsyth) writes: >Oh come on Allan! Who in their right mind is gonna create a stink when you >break a program because you fixed a bug? If you change a documented practice >you'd deserve some blasting (eg. resvector). I guess you weren't around on GEnie when I suggested that I fix a bug in the BIOS trap dispatcher HUGE stink because it would break those programs that relied on getting a pointer to an internal table in a certain register. Apparently this is a favorite trick of the cute-little-hack crowd, and they were all up in arms that I would take this away. It's not documented, and it *is* documented that I am *not* required to return anything useful or consistent in garbage registers d1-d2/a0-a2. So people, right mind or no, DO raise hell when seemingly-innocuous changes are made or suggested. My logic is not as off-the-wall as you seem to think: it's based on experience. Another subject in this thread relates to keeping track of Malloc'ed blocks using a fixed-sized pool of memory descriptors. Again, changing this creates all kinds of hassle -- much more than disallowing writes to read-only handles. Having successive Malloc's no longer contiguous is only part of the problem. The other, bigger part is that many programs access memory outside what they own -- a few bytes before or after, or memory they've just released with Mshrink. Currently, those places are relatively safe: if you just used Mshrink to release memory, then it's not used by anyone. If you run off the top of a block you've Malloc'ed, it's likely that either the next few bytes are free, or they're owned by you (via a different Malloc). So at in the likely case things will work, or you will mess up your own data and bomb. But you won't corrupt the whole memory architecture of the system. If you write over the OS's memory descriptors, though, you get in BIG trouble. Without validation, the result is really wierd behavior. With validation, the result is a panic ("Memory data structure corrupted"). Memory protection is a subject of current study for the TT, but not all the world's a TT (yet). ------------------------------ From: Ken Badertscher Subject: Re: TT compatability... Date: 16 Jul 91 17:00:26 GMT ford@tardis.computer-science.edinburgh.ac.uk writes: (several programs tried out on the TT didn't work, most were games) As far as TT compatibility is concerned, games are risky at best. Disk-based copy protected games are almost certain to fail. The main reason for this is the use of timing instruction loops. As you mentioned, some games go too fast. The same applies to the tricky timing they try to (wow, alliteration) make copy protection work. Something else you could try for non-bootload software is running 24BIT.PRG in your auto folder. This won't help for software that relies on CPU instruction timing for timers, or for software that installs its own exception handlers, but it will let you run programs that aren't 32-bit clean. GFA Basic programs compiled using all but the more recent versions of their compiler have this problem. |PS. Should the TTs internal speaker sound as if it's blown? No, but it does sound quite tinny. It's quite a low-fidelity speaker. Try plugging your TT into your home stereo with some RCA jack cables. Whee! ------------------------------ From: Allan Pratt Subject: Re: TT compatability... Date: 16 Jul 91 20:31:46 GMT ford@tardis.computer-science.edinburgh.ac.uk writes: >Spectre GCR Well... I've got version 3.0, but I canne get it to work.. it > locks up (as does GCRTEST) at the first try at > accessing the floppies in GCR mode. Mine works. Don't know what the problem might be. >MiNT 0.8 Works fine (except for the exception handling). Known bug, I fixed it & sent Eric the fix. >GNU CC 1.37.1 Everything works except the preprocessor, which doesn't parse > #if blocks properly. Mine works -- are you SURE this is a TT/ST difference? GCC from Bammi has always been pretty robust, and certainly has always worked fine on the TT. It compiles itself, which is a pretty thorough test. ------------------------------ From: Ken Badertscher Subject: Re: XCONTROL & Mouse Accel Date: 16 Jul 91 17:10:22 GMT fischer-michael@cs.yale.edu (Michael Fischer) writes: |I changed my boot sequence so that "maccel3.prg" is the LAST thing |loaded from the auto folder and now everything seems to work fine. I |don't know which program in my boot sequence was causing the problem. |Does xcontrol locate maccel3 using the cookie jar...? Yes, the Mouse Accelerator CPX finds MACCEL3 by looking for the cookie installed by MACCEL3.PRG. If the CPX is unable to find the TSR, then something in your boot sequence is probably screwing up the cookie jar -- a *dangerous* thing in STE's & TT's. MACCEL3 should be able to run anywhere in the auto folder, in fact you can even run and install it from the desktop. Someone mentioned that MACCEL3 had problems with DC Showit? Hmm... MACCEL3 is very compatible with a lot of stuff, I'm curious what the conflict with Showit is... ------------------------------ From: Ken Badertscher Subject: MACCEL3 fea...er, bugs Date: 16 Jul 91 16:29:41 GMT Wot, you got something against $AA006E? Well, it is a REALLY silly cookie value (and in fact, intentionally non-printing). It works much better hex-dumped, you see, if you squint at your monitor like I do, the AA sort of looks like an M, and the 6E sort of looks like "SE", which gives you the word "MOOSE" in a hex dump. Truthfully, MACCEL3 is a MOOSE accelerator! 'macc'? Naah, I should use 'Maus' :) And I should have used 'Maus' for the CPX, too! ------------------------------ From: Allan Pratt Subject: Re: floppyBIOS FAT handling. Date: 22 Jul 91 18:51:33 GMT >In article , danny@fiction.ms.sub.org (Daniel Roedding) says: >>Oops ... IT DOESN'T CHECK THE BFLAGS FIELD IN THE BOOT SECTOR???? So what's >>this flag good for, if even GEMDOS doesn't care about it? >> >>Daniel ONM07@DMSWWU1A.BITNET writes: >Sorry, there is no such flag in the boot sector. It's only in a BPB. MSDOS draws the line between 12-bit and 16-bit FATS at the point where a 12-bit FAT cannot work: 4096 clusters. I think. GEMDOS' floppy BIOS is hard-coded to report 12-bit FATs, on the assumption that it won't be called upon to deal with any 2.88MB floppies with one-sector clusters. You should be asking, "IT DOESN'T CHECK THE NUMBER-OF-FATS FIELD IN THE BOOT SECTOR??" That's a far more serious problem. You had better not try writing to a PC-formatted disk that only has one FAT, as some do. The number of FATs is in the boot sector but it's not passed to GEMDOS in the BPB: GEMDOS is hard-coded for two FATs. ------------------------------ From: Allan Pratt Subject: Re: TT printing Date: 19 Aug 91 17:59:17 GMT glenn@ludwig.sharebase.com (Glenn Linderman) writes: >So, I finally got my TT030! My current programming project gets loaded on, >and runs slower than on my Mega...until I rework the memory allocation to >fast RAM, and then it generates a complete screen of graphics before the Mega >starts (given simultaneous commands) to even update the screen. Are all the same things running on both machines? You should run CACHE080 or so, FOLDR100 or so, and you should set the "fast load" bits of your programs -- there is a TSR that does this for ST's, but starting with TOS 1.4 it's not necessary. This will all speed things up independent of which kind of RAM the program loads into. If you have an ACSI hard disk then you should NOT set the "load in TT RAM" bit of CACHE080.PRG, because if you do accesses to the ACSI hard disk will be slightly slower. >All is wonderful...until I try to print. >Even from the Desktop, double-clicking on a text file, it says printing that >file, delays proportionally to the length of the file, and quits. >Printers are Epson GQ3500, Toshiba 341. >Desktop printer configuration is to the parallel port. Any clues? Are you sure it's configured for the parallel port? Are you running the Control Panel and the Printer CPX? Try NOT running the Printer CPX. If the delay is truly proportional to the length of the file then SOMETHING is happening -- if you have no printer connected it should delay for 60sec and then say "Your output device is not receiving data." Parallel printers work fine here. The parallel port on the ST and TT is the same, but there is a known problem with some printers: they have pull-up resistors on the parallel port lines which are either too strong or too wimpy (I forget which) and cause more current to flow than the Atari parallel port can manage. The fact that your printer works on an ST argues that there might be something else wrong; take your TT back to the dealer and see if he can make it work, repair it, or replace it (it should still be under warranty, right?). >and apparently jiggling the power cord caused either a short >or an open Well, yes, jiggling ANY power cord which plugs into a device can cause it to lose contact. >...and it wouldn't turn on for several minutes after... I can't explain this part of what you say -- there is no reason for it to refuse to turn on for a while, then go ahead and turn on. >Glenn Linderman glenn@sharebase.com 408-378-7575 x2366 I hope you'll get back to me on this stuff: I won't deny the possibilty of software or hardware quirks that result in the behavior you're seeing, but this is the first we've heard of them. ------------------------------ From: Ken Badertscher Subject: Tos 2.0x coming to an STf(m) near you... NOT! Date: 21 Aug 91 15:08:20 GMT mike@abekrd.co.uk (Mike Quinn) writes: |[ST User...] |said that Tos 2.0 would be made available for owners of old Sts on 512K roms. TOS 2.0 won't fit in 192K, so it can't go in ST's or Megas. It could be put in an STe, but I don't know about any plans to sell ROM upgrades for STe's. That doesn't mean it won't ever happen, just that _I_ haven't heard any marketing rumbles in that direction. I prefer to stay away from marketing rumbles. ;) Oh, and TOS 2.0x is the version that comes in the Mega STe. Never fear, though, if ROM upgrades are ever made available for the 1040 STe, they'll probably be made available to Mega STe owners, too. (Can you say "Atari fixed some bugs"? Sure you can.) ------------------------------ From: Allan Pratt Subject: versions that need POOLFIX3 [was Re: Gulam problems] Date: 27 Aug 91 18:14:11 GMT >In article <3030@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) says: >>(and also 2.01 and 3.01), and that bug will EASILY be triggered by the ONM07@DMSWWU1A.BITNET writes: >REALLY? I thought this one was fixed in GEMDOS 0.15 (Sversion(): 0x1500)??? My mistake. The bug is in TOS 1.4 and 1.06 and 1.62 but not in any TT TOS or Mega STe TOS. The Sversion() value for the first fixed version is 0x1700, which is to say Version 0.17. ------------------------------ From: Ken Badertscher Subject: Re: Tos 2.0x coming to an STf(m) near you... Date: 28 Aug 91 15:26:33 GMT neil@cs.hw.ac.uk (Neil Forsyth) writes: |Well the word is that there is some hardware hacking going on too. We'll know |more next week hopefully when they let the cat out of the bag. Yep, as soon as I heard about the upgrade board shown in Dusseldorf, I started choking on that last post... and lemme tell you, regurgitated Usenet posts are none too tasty. :) Looks like ST & Mega owners win after all... with this slick little upgrade, you *will* be able to plug TOS 2.0x ROMs into those machines. The upgrade is reportedly not for the faint of heart, though... it does involve running some wires and burning your fingers with a soldering iron. |What is your opinion of patched versions of TOS 2.0x? I think we already know. 'Nuff said. ------------------------------ From: Ken Badertscher Subject: Re: GEMDOS and AES questions Date: 29 Aug 91 18:09:37 GMT avgroeni@cs.ruu.nl (Annius Groenink) writes: |1. It seems to me that all OTHER text editors load files about | twice as fast as my program. I use one straight Fread(). One straight Fread() is the fastest way you can load a file. It is possible that the slowdown you see is due to buffer setup you might be doing after you have read the file. |2. Does the ATARI AES send ANY WM_NEWTOP messages? No. ------------------------------ From: Ken Badertscher Subject: Re: Official weird thing: wandering menu bar Date: 28 Aug 91 15:02:20 GMT bboychuk@sdcc13.ucsd.edu (The Majestic Llama) writes: |In a program I'm working on, after a re-compile, the menu bar [...] |is now showing up about three text lines down and half a dozen |spaces over from the left. This is probably due to a bug in the Atari RCS. The things that seem to trigger this bug are moving menu items around followed by quitting the RCS and then saving the resource from the exit alert box, rather than saving first, then quitting. Another thing that might cause this is trying to edit a "menu" type tree as a dialog or a panel. This used to happen to me occasionally when I would edit menus, until I got into the habit of always explicitly saving the resource before exiting the RCS. To make your resource usable again, read it into a binary file editor. Look at the second word in the resource file; that is the offset to the object data. Go to that offset in the file (you'll probably see that the strings in your resource come before the objects), and find the root of your menu tree. If your menu tree is the first tree in the resource, you'll be patching the first object. If you found the menu tree, the bytes at that location will look like: FF FF 00 01 00 0x 00 19 00 00 00 00 00 00 00 00 ^^^^^ ^^^^^ ^^^^^ ^^^^^ ^^^^^ ^^^^^ ^^^^^^^^^^^ next head tail type flags state spec ob_tail will equal the number of titles in your menu, and the ob_type of a menu ROOT object is always G_IBOX (25, or 0x19). Following those 16 bytes is the rectangle of the IBOX which is the root of your menu. The first four bytes of that rectangle (the ob_x and ob_y) should be 0. In your resource they aren't, because the RCS corrupted them, which is why your menu is showing up in the middle of the screen. Set those 4 bytes (the ob_x and ob_y) to 0 and save the file back out. If you have Allan Pratt's DB (Release 3), you can use the following commands to accomplish the above: :read foo.rsc Done, start=, size= :`t0 = `rwstart + wpeek(`rwstart + 2) :dw `t0[14] : FFFF 0001 000x 0019 0000 0000 0000 0000 : junk junk :sl`t0+10 0 :write foo.rsc Overwrite existing file foo.rsc? y Wrote foo.rsc, start=, size= The next time you run your program, the menu bar should show up in the usual place. Remember... you shouldn't have this problem if you always remember to save the resource file out before quitting the RCS, and never change the type of a MENU tree to dialog or panel. ------------------------------ From: Allan Pratt Subject: Re: Official weird thing: wandering menu bar Date: 28 Aug 91 18:43:28 GMT bboychuk@sdcc13.ucsd.edu (The Majestic Llama) writes: >In a program I'm working on, after a re-compile, the menu bar >decided that it wanted to stop appearing at the top of the screen >and is now showing up about three text lines down and half a dozen >spaces over from the left. I had this happen to me, and people here said it was a problem in the resource file, introduced by some versions of RCS (Atari's Resource Construction Set). Unfortunately, once this happens to your resource file you can't un-do it. I'm told it comes from saving the resource from the "Abandon / Save / Cancel" box that comes up when you select "Quit" or "Close" from the top level after you've changed the resource. It doesn't happen if you always save using the "Save" menu item, then use "Quit" or "Close" to get out. Like I said, once it's happened to your resource file it won't un-happen unless you actually edit the file on disk. Since I don't know exactly what happened or what resource files and menu bars look like, I can't help you there. Go back to a backup version of your resource file. (What? You don't keep old versions of important files under development in case stuff like this happens? Sorry!) DISCLAIMER: I have had this happen to me and I've told you what the people here told me. I do not know what version(s) of RCS this affects, I don't know whether or not it's been fixed, and I don't know whether or not it will be. Not my department. I'm trying to be helpful here. ------------------------------ From: Allan Pratt Subject: Re: ST memory allocation Date: 4 Sep 91 20:43:25 GMT A variable-size RAMdisk basically Can't Be Done under TOS from outside GEMDOS, for exactly the reasons you've discovered: you can't go around allocating and freeing memory from inside a BIOS call or interrupt. There's another problem: just allocating memory to your RAMdisk when somebody copies a file there and deleting memory when they remove it won't do the job, because this will fragment your RAM hopelessly and nothing will be able to run. You can ameliorate this by reshuffling memory to compact your RAMdisk when you can, but that is a lot of work. And you STILL can't do Malloc's from inside BIOS, so this complication is academic. Writing your own Malloc and Mfree is not the answer, because GEMDOS calls its versions directly, not via trap #1, when it allocates memory for Pexec. You'd have to replace Pexec, too. If it sounds like you're going to have to replace bloody great chunks of OS to do what you want to do, it's time to think that maybe you should scrap the project and start another one. ------------------------------ From: Allan Pratt Subject: Re: Conclusions: How do I stop Control-C? Date: 5 Sep 91 21:15:31 GMT mforget@ersys.edmonton.ab.ca (Michel Forget) writes: >2. Use getch() and putch() to do the input and output, and use cfg_ch() >to modify the functions to use the BIOS calls mentioned above. This >would be more portable than the above method, ... I disagree. It assumes that everybody else who uses your source code has the same library that you have. Even if it's popular & widespread (like MWC or something) it's still not portable. There's a third alternative: use Crawio(c) for output and Crawcin() for input. These are GEMDOS functions, not BIOS functions, and as such are redirectable and other stuff. The redirection doesn't actually work before TOS 1.4 for some of the single-character I/O calls, but that's Yet Another Good Reason To Upgrade. ------------------------------ From: Allan Pratt Subject: Re: ST memory allocation Date: 5 Sep 91 21:24:20 GMT ersmith@ria.ccs.uwo.ca (Eric Smith) writes: >So perhaps what you should do instead (and it's a *much* cleaner >solution than fiddling with GEMDOS' allocated memory buffers) is to >catch the ramdisk calls at a higher level, i.e. at the trap #1 level >instead of trap #13. You call that cleaner?! Eric, I'll assume you had some bad drugs this morning and forgive you; you don't usually make howlers like this. It is VERY hard to tell if a GEMDOS call is destined for a given filesystem. You have to keep track of all handles to decide which ones are open on files of yours, including stdin and stdout because of redirection. This is a COMPLETE non-solution as far as this guy's ramdisk is concerned. Furthermore and most obviously, DON'T MUCK WITH GEMDOS. It's almost ALWAYS a bad idea. If you have to steal Trap #1 then you've probably got some serious organizational problems with your program, or else you're just doing something Evil and Wrong. The only things that steal trap #1 that I can approve of are OSes in themselves: MiNT and MetaDOS and the like. And they HAVE to. ------------------------------ From: Allan Pratt Subject: Poolfix not needed for TOS 1.62 [was Re: Gulam problems] Date: 9 Sep 91 19:17:58 GMT Roger W. Sheppard, Roger.Sheppard@bbs.actrix.gen.nz writes: >> That was the reason that I posted my Arcticle in the First place, >> Atari will not state if TOS 1.62 needs Poolfix, I would like a clear >> statement from Atari on this.. ken@isgtec.uucp (Ken Newman) writes: >I asked Bob Brodie a similar question on Compuserve a while ago, coming >at it from a different angle, and got a fairly clear reply. I asked what >the differences were between TOS 1.60 and 1.62, and he stated that there >were exactly two differences: > > 1) fix for the DESKTOP.INF/low-res boot problem (formerly fixed > by STEFIX.PRG) > 2) fix for the memory pool problem (formerly fixed by POOLFIX3.PRG) This is correct. ------------------------------ From: Ken Badertscher Subject: Re: Mouse click delay hell! Date: 12 Sep 91 02:25:04 GMT rossin@hpfctgr.HP.COM (Ted Rossin) writes: |When I try to detect a mouse button down event in a GEM application, |event_multi does not return the event to my code until after the double-click |time out period. If you ever ask for double click events, you'll wait for single click events in ROM TOS and Mega TOS. Unless I misremember, this bug was fixed in TOS 1.4, certainly by TOS 1.6. If you have Easy Draw you'll notice that its response to clicks that bring up the menu are much quicker. YARTU! ------------------------------ From: Allan Pratt Subject: Re: I/O address space Date: 26 Sep 91 02:08:05 GMT herzling@rhrk.uni-kl.de (Alexander Herzlinger [Informatik]) writes: >That's not true, the standard registers are physicaly located at >0x00FF.... _NOT_ at 0xFFFF.... !!!!! That's not true. The standard addresses are physically located at BOTH 0x00FF AND 0xFFFF. I think you should probably think twice before correcting somebody who has "atari" in his return address. It leads to needless confusion and contradiction. Yes, the PMMU is used to map addresses, because of a bug in the 68030's cache-inhibit logic, and yes, the page tables route both $FFxxxxxx and $00xxxxxx to $00xxxxxx, but that doesn't make you right. It turns out that it saves page table space, that's all. ------------------------------ From: Allan Pratt Subject: Re: GEMDOS File Functions and the STe Date: 8 Oct 91 16:50:08 GMT mlake@irscscm.UUCP (Marshall Lake) writes: >Is anyone aware of any undocumented changes with GEMDOS file functions >on an STe from that on an ST? I'm thinking specifically of Fopen. Nothing changed. TOS 1.4 and TOS 1.62 (STe TOS) have the same GEMDOS, save for the fix to the bug that POOLFIX fixes -- that bug was in TOS 1.4 and TOS 1.06 but not TOS 1.62. Differences in behavior can come from running or not running FOLDRxxx.PRG; differences in speed from running or not running CACHExxx.PRG, but a given configuration of these two programs should run identically whether you're running TOS 1.4 plus POOLFIX or TOS 1.62. ------------------------------ From: Allan Pratt Subject: Re: Malloc'ing, what strategy to use? Date: 8 Oct 91 16:58:11 GMT r0mill01@ULKYVX.BITNET (Robert Delius Royar) writes: >It's also safer to Malloc in chunks divisible (no remainder) by 512 bytes. Where did this come from? There is NOTHING in ANY piece of code that cares how much you Malloc, as long as it's more than zero bytes. Your request gets rounded up to an even number of bytes (currently; this may become "multiple of four bytes" in the future), but that's it. On the subject of Malloc in general: I like what somebody (Steve Yelvington?) described about Dlibs. He says Dlibs does a Malloc(-1L) early on, and uses that number divided by 16 as the "chunk" size for requests from the OS. I *hope* that it doesn't prevent you from allocating more than 16 chunks of that size: with appropriate fragmentation (or TT RAM!) you can have many more than 16 times that much memory available in the system. But the flexible nature of this chunk size (small on a 1040, large on a 4MB machine) is A Good Thing. TOSes 1.4 and newer don't have "number of Mallocs" restrictions, but this algorithm is still worthwhile. ------------------------------ From: Allan Pratt Subject: Re: TT problem with keyboard interrupt Date: 8 Oct 91 17:05:37 GMT vspicer@ccu.umanitoba.ca writes: >Old_kbd_isr=(long)Setexc(70,kbd_isr); >asm{ >kbd_isr: > move.l A0,-(A7) > > (do other stuff) > > pea retrn(PC) > move.w SR,-(A7) > move.l Old_kbd_isr,A0 > jsr (A0) ; jmp has also been tried and failed > >retrn: > move.l (A7)+,A0 > rte >} >this code works fine on the ST but crashes with two bombs (bus error) >after the "jsr (A0)" command on our TT. any ideas? Use JMP not JSR, and you need to test the word at $59e, a system variable called "longframe." From the 68010 on there is a longer exception stack frame, and that's what you're constructing by putting the SR and a return PC onto the stack and jumping to an exception handler. If the word at $59e is nonzero, you need to push a zero before the "pea" instruction. (On ST's, $59e is an unused word in system variable space, so it's zero. On newer TOSes, it gets initialized to a nonzero value if you're on anything other than a 68000.) On the other hand, since you're not doing anything useful at retrn, you can restructure this in a stack-frame-insensitive way: move.l a0,-(a7) (do stuff) move.l (a7)+,a0 move.l Old_kbd_isr,-(a7) rts The "move an address from memory to the stack, then rts" trick is a way to do an indirect jump without changing any registers. Think of it as "jmp to the address found at Old_kbd_isr" and not really an "rts" and you'll have the idea. Since the routine you jmp to ends with RTE, and you haven't changed the exception stack frame, you don't have to care about longframe. ------------------------------ From: Allan Pratt Subject: Re: Why programs don't work (was Fligth Simulator on STe) Date: 18 Oct 91 21:03:10 GMT reeuwijk@dutentb.et.tudelft.nl (C. van Reeuwijk) writes: >After that, I bought a Mega STe. And I discovered that I could not run >FSII at all, so I took >out a disassembler and tried to find the cause. It appears that there is >a loader program, FS2.PRG, that loads and relocates the code from either >the color or monochrome version of FSII. However, *IT LOADS THE PROGRAM >TO A FIXED ADDRESS*, $28000. This may, or may not be an address that is >already used by other programs, but if you have a harddisk with some ACC's, >a disk cache, or The FOLDRxxx.PRG program it is very likely that the ram >at that address *is* in use. To prove this to myself, I have de-installed >the auto-boot disk-driver, and started FSII directly from floppy. >It worked! Thank you for the opportunity to discuss the question "why doesn't program X work on machine Y?" Program X might have been written by real dingbats, that's why. It might load at an explicit address. It might use really low memory in an attempt to foil debuggers, and using that memory might not be as harmless as it was in the TOS version the author designed it for. It might assume that ROM starts at $FC0000. It might demand (inexplicably) that a certain system buffer appear below address $1000, as Crack'ed does. It might clobber a system resource (like Timer C) and then expect BIOS calls to go on working. It might run off the end of memory looking for something above phystop, with a guard against doing that on a 4-meg machine: ST's won't give bombs when you access non-existent memory under 4MB, but STe and TT will. The Shadow (background-download) detection code does this. It might have a bug that wasn't fatal in old TOSes, like I recently found in Starglider: it has this instruction move.b $df,$fffa0f instead of this one: move.b #$df,$fffa0f The second one clears a single bit in the MFP in-service register the first moves whatever value happens to be in memory at $df into that register. Since $df is the low byte of an exception vector that isn't used, you're at the mercy of the address where the bomb handler landed in ROM. My point is that we just can't fix these things. I don't like the fact that Starglider doesn't work under new TOS, but I can't help it. ------------------------------