SST Release Disk 1.87 (First Revision) Disk 1.87 is a slight upgrade to the 1.86 disk. NONE of the fundamental programs for the SST (such as RAMnbmm) have been changed; however, some of the additional, helpful, or plain fun files have changed. To document this, we have added NOTEs where necessary in the 1.86 documentation; the changes are so few, and only to accessory programs, that we didn't want to do a complete rewrite and re-CRC/ARC of the disk. In this file, to make the changes stand out, they look like this: << This is a sample of a 1.87 note. >> 1.87 isn't a major change, just some things we felt would help. None of the main SST programs have changed. * Fast-MAGPLOT is now at version 3; some bugs fixed, and I'm partway towards making it a standard benchmarker with a fixed set of points and timer. * We updated Jim Ness' benchmark program from 1.1 to 1.2. * We added a desk accessory Charles Johnson wrote that helps with those pesky "accidental" double-clicks that have been around since 1.4 (and are still in 2.06). * We also added X_MON, a program to help users with high resolution moniters (called Moniterm in the USA) and other types use the SST; this was the result of many Moniterm & SST installations' experience. X_MON is good stuff. * We also added an offer of a new, higher-current power supply for ST users from the Merlin Group (who designed the SST!) in the file "power.txt", in the root directory. We wanted to stay within the space available on a standard double sided 9-sector disk, instead of going to a 10-sector format, because backing up a 10-sector disk isn't something for the beginner. Hence we deleted a few programs that were identical copies of others, which merely had their "SST RAM" bit set, such as the benchmarkers and MAGPLOT. -- thank you, Dave Small Engineer Gadgets by Small, Inc. p.s. Be sure to check out POWER.TXT for the power supply offer. It is good. ----------------------------------------------------------------------------- SST Release Disk 1.86 (Original) << with 1.87 updates >> File Listing and COMMENTS This is a listing and EXTENSIVE documentation, up-to-date, on ALL files shipped on the SST release disk version 1.86. Take note of the two known bug reports on Quick-ST and RAMnbmm.PRG, if nothing else. This information supplements and adds to the manual's information. Here are the files on the SST Software Disk, Version 1.86. * This is the original release disk. * * Later updates will be revision greater than 1.86. * << We are at 1.87 now. >> We used the popular ARC program, version 6.02, to generate this listing, because it gives you CRC's for each file; you can check for file damage by using ARC to generate this CRC list. (e.g., build an ARC file, then use "ARC v filename.arc" to generate this listing; the CRC's should match. You can even use an IBM/clone to check out the ARC file; ARC 6.02 is IBM compatible. Files are grouped by function by folder; for instance, the benchmarkers we include are all in the BNCHMARK folder, the programs that should go into your AUTO folder are in AUTOFOLD, and so forth. (We didn't name it AUTO in case you started up with this floppy.) Of course, the files on the release disk will change as we improve and add programs to it; if you have SST release disk 2.5, for instance, don't expect to find these identical files on it. Here's the complete list of what you should find on your floppy. Name Length Storage SF Size now Date Time CRC ================= ======== ======== ==== ======== ========= Name Length Storage SF Size now Date Time CRC ================= ======== ======== ==== ======== ========= ====== ==== AUTOFOLD 18200 Subdir 72% 5209 25 Jan 92 12:24p 0000 << no changes >> AUTOMMU2.PRG 17064 Crunched 75% 4391 25 Jan 92 12:23p 24c1 CLDBOOT2.PRG 1136 Crunched 31% 787 25 Jan 92 12:24p 260b BENCHMAR.K 106768 Subdir 38% 66922 1 Jan 98 19:63p 0000 << updated to version 1.2, which adds graphics testing, etc. >> << Hence these files are slightly different. Version included is >> << set for SST RAM. >> FNBM11.DOC 2020 Crunched 37% 1291 1 Jan 98 19:63p 2597 FNBM11.PRG 36329 Crunched 37% 23016 1 Jan 98 19:63p 0fbb NBM11.PRG 36329 Crunched 37% 23021 1 Jan 98 19:63p f7fe ---------------- << deleted for space; just un-set SST RAM bit on QINDX18S to get. >> QINDEX18.PRG 16045 Crunched 40% 9780 28 Nov 90 9:06a b3c0 ---------------- QINDX18S.PRG 16045 Crunched 40% 9783 28 Nov 90 9:06a dfbb BOINK 133367 Subdir 56% 59221 5 Feb 46 2:33a 0000 << no changes >> BALL.PI3 9494 Crunched 65% 3356 20 Aug 89 10:25a d987 BOINK.ACC 11926 Crunched 28% 8592 20 Aug 89 10:25a a9d2 BOINK.DOC 5633 Crunched 42% 3272 20 Aug 89 10:25a ac05 BOINK.IM2 8836 Crunched 67% 2959 20 Aug 89 10:25a 9b34 BOINK.IM3 9494 Crunched 65% 3356 20 Aug 89 10:25a d987 BOINK.PI2 32066 Crunched 64% 11769 23 Jan 92 8:36p 809f BOINK.PI3 32066 Crunched 73% 8703 5 Feb 46 2:33a 8511 BOINK.PRG 11926 Crunched 28% 8592 20 Aug 89 10:25a a9d2 FBOINK.PRG 11926 Crunched 28% 8591 20 Aug 89 10:25a 9bd5 CPX 70420 Subdir 38% 43962 1 Jan 98 19:63p 0000 << no changes >> ASCII.CPX 7037 Crunched 33% 4741 1 Jan 98 19:63p e454 CALENDAR.CPX 9958 Crunched 28% 7188 1 Jan 98 19:63p 4904 COOKIES.CPX 6434 Crunched 34% 4289 1 Jan 98 19:63p c697 FILEINFO.CPX 9744 Crunched 28% 7109 1 Jan 98 19:63p 7aeb LIESMICH 13611 Crunched 57% 5951 1 Jan 98 19:63p a2ee SYSTEM.CPX 16130 Crunched 29% 11565 1 Jan 98 19:63p 5dc9 SYSTEM.INF 7506 Crunched 59% 3088 1 Jan 98 19:63p 8107 DISK 70370 Subdir 68% 22878 3 Dec 31 2:25a 0000 << no changes >> DISK94.PRG 35185 Crunched 68% 11422 3 Dec 31 2:24a d9a4 DISK94HU.PRG 35185 Crunched 68% 11425 3 Dec 31 2:25a bbde FASTBOOT 10656 Subdir 62% 4067 13 Dec 31 11:49p 0000 << no changes >> MAKEDSK5.TOS 5293 Crunched 63% 1987 13 Dec 31 11:35p 272c MAKEFRB5.TOS 5363 Crunched 62% 2049 13 Dec 31 11:49p 9e58 MAGPLOT 108292 Subdir 38% 67761 0 --- 28 0:00a 0000 << Deleted >> FMAGCLIP.PRG 12724 Crunched 44% 7217 0 --- 28 0:00a 4f5f --------------------- MAG68881 57392 Subdir 33% 38871 25 Jan 92 1:12p 0000 << Deleted; Magplot is now at Version 3; these were about version 1.5. >> FMAG_CLP.PRG 14348 Crunched 33% 9709 24 Jan 92 2:29a bf26 MAGNOCLP.PRG 14348 Crunched 33% 9702 25 Jan 92 1:12p 7c4c --------------------- << This is FastRam, FPU, Magplot Version 3. >> MAG_CLIP.PRG 14348 Crunched 33% 9717 24 Jan 92 2:54a ceba -------------------- << Put the two non-FPU Magplots into their own subdirectory. >> << These are still Magplot about release 1.5. >> MAG_NO.FPU Subdir MAG_CLIP.PRG 12724 Crunched 44% 7218 0 --- 28 0:00a 9c47 MAG_NCLP.PRG 12726 Crunched 44% 7213 25 Jan 92 12:55p 4bf6 ------------------- << NEW: A desk accessory that may help with the "double clicking" problem often found since TOS 1.4, and also present in TOS 2.06. Read the .TXT file for information. >> BUTTON.FIX Subdir BUTTNFIX.ACC The Desk Accessory. BUTTNFIX.TXT Its documentation. << New: An AUTO folder program to properly manage higher resolution monitors from Doug Wheeler, known as X_MON. It helps the Moniterm to work right with the SST; you should also use Quick-ST 2.2 with it, also included on this disk. Note: The Moniterm was differently named outside the USA, we believe. >> X_MON Subdir XMON.PRG The AUTO folder program. XMON.DOC The Documentation. << No changes in the root directory >> MEMSTAT6.TOS 3872 Crunched 40% 2328 3 Dec 31 1:14a 2cc6 MMU24BIT.TOS 2730 Crunched 35% 1794 3 Dec 31 1:15a 4a1b PRGFLAG.PRG 28652 Crunched 25% 21736 27 Aug 90 3:14p 6a3c QUICKST 96462 Subdir 40% 58384 0 --- 28 0:00a 0000 QINDEX22.PRG 11648 Packed 0% 11653 22 Feb 89 0:05a f44c QST2CUST.ACC 20510 Crunched 41% 12121 13 Sep 90 10:21p 5556 QUICKSTC.PRG 32453 Crunched 48% 16937 0 --- 28 0:00a 8e8a QUICKSTM.PRG 31851 Crunched 45% 17642 0 --- 28 0:00a b01f RAM3333.PRG 38024 Crunched 55% 17273 3 Dec 31 2:28a f955 STACK1.TOS 2161 Crunched 78% 486 0 Dec 31 8:37p 213c ==== ======== ==== ======== ( Note: Dates not showing Jan 25 1992 are incorrect. All software was recompiled/reassembled by that date, but a faulty system clock did not get the right date into the files; don't worry. ) ============================================================================== Here is a breakdown of what each file is, for your reference, along with hints and the latest news: Name Length Storage SF Size now Date Time CRC ================= ======== ======== ==== ======== ========= ====== ==== AUTOFOLD == Programs for the AUTO Folder == AUTOMMU2.PRG CLDBOOT2.PRG Here are the two programs that ought to go into your AUTO folder, either on your startup floppy, if you don't have a hard disk, or on your C:/AUTO folder, if you have a hard drive. AUTOMMU is discussed in the manual; it is **essential** to stabilize a bug in the 68030 that happens at the time the GEM Desktop shows up. NEVER RUN THE SST WITHOUT RUNNING AUTOMMU or RAMnbMM.PRG (or both)! By running AUTOMMU or RAMnbmm.PRG in the AUTO folder, the bug cannot appear. Important Note: If you decide to automatically turn on SST RAM each startup by putting RAMnbmm.PRG into your AUTO folder, you do not need AUTOMMU2, because RAMnbmm.PRG sets up MMU tables that are a "superset" (e.g., includes, but do more) of AUTOMMU2's function. The old AUTOMMU2 tables are then discarded. Two notes on using RAMnbmm.PRG in the AUTO folder: * If you run RAMnbmm.PRG, THEN run AUTOMMU2 by accident, the newer tables will be wiped out and your system left in a an uncertain state, particularly relating to other SST software. This is a Bad Thing. * Also, you may want to shut off RAMnbmm.PRG from time to time in the AUTO folder, by holding down the SHIFT key as it runs (RAMnbmm.PRG tells you this each time it runs.) If you shut off RAMnbmm.PRG, you DEFINITELY NEED to have run AUTOMMU2, or your hardware is unsafe. Hence, the Best & Safest Of All Worlds if you want to initialize SST RAM in the AUTO folder is to do this: Put both AUTOMMU2 and RAMnbmm.PRG in the AUTO folder. Also copy RAMnbmm.PRG into the root directory where the AUTO folder is; due to a fluke in TOS, when AUTO folder programs run, the directory they "see" is the main root directory! The wait-state and MHz numbers from the ROOT DIRECTORY version will be used. You must make sure that AUTOMMU2 *IS RUN FIRST*, BEFORE RAMnbmm.PRG!! Because AUTO folder programs are not run in alphabetical order, but rather in the order they appear in the directory (which is something you cannot directly see, but relates to the order they were put into the AUTO folder originally), one way to ensure this is as follows: 1) Copy the entire AUTO folder (by dragging it) to a new folder, AUTOCOPY. 2) DELETE THE AUTO FOLDER. This is important; it wipes the directory clean. 3) Create a new AUTO folder. 4) Copy AUTOMMU2.PRG into the AUTO folder. It will then be the first AUTO folder program run. 5) Copy RAMnbMM.PRG into the AUTO folder. It will then be the second AUTO folder program run. (Thus, While starting up, if you then shut off RAMnbmm.PRG, you still have AUTOMMU2 working, protecting the MMU and your hardware.) Note: If you have other AUTO folder programs which MUST be first, you can place them before AUTOMMU2; the key thing is that AUTOMMU2 must be copied in BEFORE RAMnbmm.PRG.) 6) Go to AUTOCOPY and copy in your other AUTO folder programs back to AUTO; they will then run AFTER AUTOMMU2 and RAMnbmm.PRG. --------------------------------------------------------------------- COLDBOOT (here, CLDBOOT2) makes "warm" RESETs into true RESETs. This is important to ensure that twin copies of system tables don't appear, which happen with warm RESETs. This version of COLDBOOT also makes the CTRL-ALT-DEL keyboard RESET work, which it otherwise will not, because Atari chose not to safely turn off the MMU, TT0/TT1, and CACR upon RESET; when the MMU table's memory is wiped out, the ST crashes. COLDBOOT does a clean shutdown by handling warm-boots; it shuts off the MMU, TT0/TT1, and CACR, THEN performs a proper coldboot. The Shift-Ctrl-Alt-Del "Cold" RESET does not work right now. This is because when the system sees that keypress, it wipes out critical sections of memory for unknown reasons, and gives no clean way for us to catch and "fix" the hardware shutdowns needed. Newer software will have to watch the keyboard input vector and track the Shift, ALT, Ctrl keydown/keyups to prevent this crash. (The new RESET method was a surprise to us in TOS 2.05). If you should forget and use the old Shift-Ctrl-ALT-Delete and crash (you'll "hang"), simply press the hardware RESET and you should be fixed. (If that fails, power off, wait 10 seconds, and power on; that usually fixes the worst of problems.) ===================== 1.87 BLITTER NOTE: ========================= << Note: The most common problem we see here are Blitter incompatibilities. There are a number of brands of Blitter, each with differing timing. Adjusting SST to work with the worst of them would have slowed down SST quite a bit, so we didn't. TURN THE BLITTER OFF; with the 68030 at high MHz doing screen draws, you are not losing speed relative to the Blitter. Note that Atari did not even bother *putting* a Blitter into the 68030 TT! It is very important during setup to TURN OFF the Blitter in your control panel / menu / X-Control panel ("General"). You can then cautiously enable it and see if it causes you problems. This has been far and away the majority of our technical support for the SST! >> --------------------------------------------------------------------- BENCHMRK == Jim Ness' BenchMark Program v. 1.1 == << Note: This has been updated to ver 1.2, but the comments are generally relevant. To save disk space, only the SST-RAM version is included in 1.87. >> FNBM11.DOC 2020 Crunched 37% 1291 1 Jan 98 19:63p 2597 FNBM11.PRG 36329 Crunched 37% 23016 1 Jan 98 19:63p 0fbb This is Jim Ness' benchmark version 1.1, set to load into SST RAM via the program PRGFLAGS (also on this disk). It will run much faster in SST RAM. (Note: If it does not, check that SST RAM has been turned on -- run RAMnbmm.PRG). NBM11.PRG 36329 Crunched 37% 23021 1 Jan 98 19:63p f7fe This is Jim Ness' benchmark version 1.1, set to load into ST RAM. Try varying the CACHE on/off to note the results. It will not run as fast as the version set for SST RAM! --------------------------------------------------------------------- == Darek's Quick-Index Program v. 1.8 == << For space reasons, the non SST RAM version has been deleted. >> QINDEX18.PRG 16045 Crunched 40% 9780 28 Nov 90 9:06a b3c0 This is Darek's benchmark version 1.8, set to load into ST RAM only. Try varying the CACHE on/off to note the results. Quick Index 1.8 compares performance with stock ST's, but not with the TT. See below. QINDX18S.PRG 16045 Crunched 40% 9783 28 Nov 90 9:06a dfbb This is Darek's benchmark version 1.1, set to load into SST RAM via the program PRGFLAGS (also on this disk). It will run much faster in SST RAM. These programs are freely distributable. There are later releases of Quick Index that are not freely distributable; since we are licensing Quick-ST, refer to the "QUICKST" folder for QINDEX22, which compares machine speed to a TT. --------------------------------------------------------------------- BOINK == The "Boink" Bouncing-Ball Programs == BALL.PI3 9494 Crunched 65% 3356 20 Aug 89 10:25a d987 BOINK.ACC 11926 Crunched 28% 8592 20 Aug 89 10:25a a9d2 BOINK.DOC 5633 Crunched 42% 3272 20 Aug 89 10:25a ac05 BOINK.IM2 8836 Crunched 67% 2959 20 Aug 89 10:25a 9b34 BOINK.IM3 9494 Crunched 65% 3356 20 Aug 89 10:25a d987 BOINK.PI2 32066 Crunched 64% 11769 23 Jan 92 8:36p 809f BOINK.PI3 32066 Crunched 73% 8703 5 Feb 46 2:33a 8511 BOINK.PRG 11926 Crunched 28% 8592 20 Aug 89 10:25a a9d2 FBOINK.PRG 11926 Crunched 28% 8591 20 Aug 89 10:25a 9bd5 These are necessary files for BOINK to work. Make sure they are in whatever folder you try to run BOINK out of, particularly BOINK.ACC! BOINK.ACC 11926 Crunched 28% 8592 20 Aug 89 10:25a a9d2 This is the BOINK program, which bounces a ball across the screen, set up to load into ST RAM at startup time as a desk accessory. It is available in any program that has desk accessory access. If you want to use this desk accessory, you MUST have the other Boink files in the C:\ directory or on the boot floppy, particularly the IM2-PI2 (color) or IM3-PI3 (monochrome) image files. NOTE: You can have several BOINK's available as desk accessories if you just rename them; for instance, for three BOINK's, use BOINK.ACC, BOINK1.ACC, BOINK2.ACC (all copies of the same file) on the C:\ directory. You can then activate three independent bouncing ball windows, re-size them to be on the same screen, and so forth. You will see GEM's task-switching in action if you do this; it is neat! This BOINK.ACC is just a renamed copy of BOINK.PRG below! Be sure to read BOINK.DOC for further on information on Boink. FBOINK.PRG 11926 Crunched 28% 8591 20 Aug 89 10:25a 9bd5 This is the FBOINK ("Fast Boink") program, which bounces a ball across the screen, set up to load into SST RAM via the PRGFLAGS program (also on this disk). It will run much faster in SST RAM. It's also a good "quick test" if SST RAM is working okay, since it exercises so much of the ST machine. After a few seconds, the menu bar will show "free RAM" available; if you're running in SST RAM, you'll see nearly 4 or 8 megabytes free. Also, remember to use the "fast" menu option, which turns off time-consuming AES accesses and system stuff, to see BOINK running as quickly as possible. BOINK.PRG 11926 Crunched 28% 8592 20 Aug 89 10:25a a9d2 This is the BOINK program, which bounces a ball across the screen, set up to load into ST RAM. Try varying the cache on/off to see the speed difference. CPX 70420 Subdir 38% 43962 1 Jan 98 19:63p 0000 == The CPX Utility Folder == These are .CPX files (Extended Control Panel Files) for use with Atari's extensible control panel program. While they aren't absolutely essential, they are often quite useful. They are shareware with a donation requested; I felt they might be useful for you. If you end up using them, please send along the requested contribution to the author. ASCII.CPX 7037 Crunched 33% 4741 1 Jan 98 19:63p e454 This gives you quick access to an ASCII table. CALENDAR.CPX 9958 Crunched 28% 7188 1 Jan 98 19:63p 4904 This gives you quick access to a calendar. COOKIES.CPX 6434 Crunched 34% 4289 1 Jan 98 19:63p c697 This shows you a listing of the System Cookie Jar data structure. This is VERY useful. For instance, to see if RAMnbmm.PRG has run, look for the "_FRB", "F117", and "SR71" entries to find the disk data buffers (each 64K long) and the SST-SR71 Cockpit, itself a Cookie Jar. FILEINFO.CPX 9744 Crunched 28% 7109 1 Jan 98 19:63p 7aeb This VERY USEFUL cpx shows you information about a file, and in addition, lets you change the "fast-load", "SST-RAM load", and "SST-RAM memory request" bits of a file, very much like PRGFLAGS.PRG. All available through a desk accessory CPX! (Note: you cannot switch a running program from ST RAM to SST RAM while it is running; you must change the SST RAM "flag" and re-run it.) LIESMICH 13611 Crunched 57% 5951 1 Jan 98 19:63p a2ee Here is documentation for these CPX's; however, they are very intuitive and easy to use by themselves. It has the address for a shareware donation to the author, that he deserves. SYSTEM.CPX 16130 Crunched 29% 11565 1 Jan 98 19:63p 5dc9 SYSTEM.INF 7506 Crunched 59% 3088 1 Jan 98 19:63p 8107 This VERY USEFUL CPX lets you examine many system tables, and lets you add more system entries via the SYSTEM.INF file. Hint: When you start this CPX, click on the lower left hand corner's box, which is blank, to get started; it will then initialize. The SYSTEM.INF file defines what you can look at with this CPX, and may be extended for all kinds of purposes, but it already has a substantial number of tables in it. --------------------------------------------------------------------- DISK == Disk Access Life Support == Some Discussion of Hard Disk Life Support Software These two programs funnel (channel) all hard disk accesses through an ST-RAM buffer, pointed to by the "F117" Cookie Jar entry.Long. This enables hard disk software that is NOT fully SST-RAM compatible to operate, *because it is only using ST RAM!*. For example, let's say you double-click on a program that is set to run in SST RAM (by PRGFLAGS, see below); the program is 130,000 bytes long. With the disk program installed, the following happens: 1) The disk request is looked at and checked to make sure it isn't a special "media change" request or other little-documented thing. 2) It's determined that the disk request is for SST RAM. 3) Since our ST RAM area is only 64K long, we have to read in the 130K file in pieces. (The 64K long limit is also because the Atari disk hardware will only allow a maximum of 64K to transfer at once!) 4) We send a request to the Hard Disk Driver to read 64K from the start of the program, into our ST area (buffer). 5) The hard disk driver does that; after all, it is a normal ST read request! 6) We copy 64K of data up to SST RAM from the ST RAM buffer. 7) We ask the hard disk, once again, for another 64K; that makes 128K of the program read in. 8) We copy that next 64K up to SST RAM from the ST RAM buffer. 9) We have done 128K out of 120K. We ask for 2K more from the disk. 10) We copy that 2K up to SST RAM. 11) We "return" and tell whoever called us that we are done. Hence the disk accesses are intercepted and handled by us, with the programs below. ------------------------- TECHNICAL ----------------------------------- TECHNICAL NOTES: We intercept the TRAP #13 vector COMPLETELY. We "break out" the #4 RWABS and process it in 64K pieces, and then with whatever cleanup is required. We then RTE. NOTE: We DO NOT "jump through" the old TRAP #13 vector to the ROM dispatcher. We use code that is pretty much the same as the ROM dispatcher, but is 32-bit clean (which the ROM dispatcher is not; the top bit is used for indirection). This may have implications for "trap intercepter" programs. Since we are effectively the "last" program in the TRAP chain, we do not set up an "XBRA"-style vector; RWABS calls must be handled by our program, not the system RWABS handler, or they will often fail. (We also cannot intercept calls at the hdv_rw $4xx vector, because many programs over-write that vector.) << Let us know if this gives you trouble. >> We intercept the 200Hz Timer vector ONLY for the "heads-up" display, and update the display every 1/2 second. We DO continue by jumping to the old 200 HZ vector. The TOS 2.06 ROMs contain support for floppy disks and SST RAM. TOS 2.05 did not have such support; hence, I wrote much code to divert SST RAM requests for floppy disks (floprd, flopwr, etc) through an ST RAM buffer. Fortunately, TOS 2.06 came out right after I was done writing this code (*sigh*). Hence I do not intercept TRAP #14 to "catch" the floppy requests. TOS 2.06 MUST find a Cookie named "_FRB" pointing to an even aligned, 64K-long RAM buffer in order to use SST RAM with floppies. About the second JSR in the floppy routines is the _FRB check, if you're interested. (It was formerly TT-only code). Hence RAMnbmm.PRG installs an _FRB cookie if there isn't one already; TOS 2.06 does NOT install this cookie on startup like TT TOS 3.0x does... If you run the cookie jar out of room, RAMnbmm.PRG will warn you. RAMnbmm.PRG does not yet have a utility to "stretch" the cookie jar by moving it; with the way RAMnbmm.PRG overlays itself with disk buffers, that would be pretty tricky. Use another program that is more cookie-jar aware if this becomes a problem. Some ST Hard Disk software is already aware of SST RAM and can deal with it. In that case, you don't really need disk life support. USA Hard Disk software was tested; some required disk support, other software did not. We have not yet tested other hard disk software, but expect that to begin around the first SST shipment! USA Hard Disk software that does NOT need DISK94.PRG: - AHDI 4.02, 4.03 (you SHOULD RUN 4.03; 4.02 is said to be buggy) - AHDI 5.00 (also called HDX 5) USA Hard Disk Software that definitely DOES NEED DISK94.PRG: - AHDI 3.00-3.02 (HDX 3) from Atari - ICD anything; we tested ICD 5.20 and 5.4.2, which was the latest version as of this writing. Both REQUIRE DISK94. ICD 5.4.2 works only for programs less than 64K long, which won't work all the time! - Supra 3.xx; we tested 3.42 with the 3.00 booter. We will add to this list as we get more reports. In general, software that is "TT Compatible" should work; however, if it doesn't, use DISK94 to settle the problem. A quick way to find out is to run RAMnbmm.PRG, then to load one of the SST-RAM flagged programs from the hard disk, such as FBOINK, QINDX18S, or the FMAGPLOT series. If you crash pretty instantly, you also need DISK94. Also test files BIGGER than 64K (the abovenamed files are not). Try running a SST-RAM program larger than 64K and make sure it works. Also, try COPYING a program bigger than 64K, with the GEM Desktop, after running RAMnbmm.PRG. For some reason, GEM uses SST RAM as the intermediate buffer for disk copies; if programs bigger than 64K "break" on a copy, or if you can't copy at all, you need DISK94. Note: Some "TT Compatible" software may REQUIRE an _FRB Cookie to be installed very early in startup, when the "boot sector" of the hard disk is read. We have a program called MAKEFRB5.TOS which creates an executable floppy disk for drive A: which does just this. WE HAVE NOT YET SEEN A NEED FOR IT, but we are providing it "just in case"; one USA HD software developer told us this would make their software SST compatible. (It didn't; DISK94 did.) These two programs are basically the same. The ONLY difference is that DISK94HU.PRG adds a "Heads-Up" display in the upper-right corner of the screen. --------------------------------------------------------------------- DISK94.PRG This program should be run after RAMnbmm.PRG (the SST RAM initializer) in many cases, depending on whose hard disk software you are using. It uses the "F117" "Stealth Buffer" to perform disk accesses all through ST RAM, so that hard disk software which is not "SST RAM Able" can still work. However, if your hard disk software is already "SST RAM Aware", use of this program will result in slowed-down disk accesses, since excessive copying from buffer to buffer takes place. You cannot run this program until you have run RAMnbmm.PRG. <> If you put RAMnbmm.PRG in the AUTO folder, and your hard disk software needs DISK94 to work, then you must also put DISK94 into the AUTO folder, and make sure it runs right after RAMnbmm.PRG. You can do this with the procedure discussed under "AUTOMMU2" above; namely, copy & delete the AUTO folder, re-create the AUTO folder, and copy files into it in the order you want them to run upon startup. If you should shut off RAMnbmm.PRG with the SHIFT key press, DISK94 will shut itself down, too, with a message telling you it cannot find tables that RAMnbmm.PRG sets up. << You then exit with any keypress. >> --------------------------------------------------------------------- DISK94HU.PRG This is the same as DISK94; however, it adds a "Heads Up Display" to show you a few things about the status of SST RAM. It shows a "0", "4", or "8" in the upper right hand corner of the screen, showing how much SST RAM is known; it adds a "C" if the cache is turned on or a blacked-out "C" if the Cache is off; and it adds an "S" if the supervisor stack is currently in SST RAM (an intermittent condition indeed!) This is an extremely useful program, since you can tell at a glance that SST RAM has been turned on, how many megabytes of SST RAM are there, whether or not the 68030 Caches are on, and if the Supervisor Stack is in SST RAM for speed. I will probably move the "Heads Up Display" to a seperate program in the next software release, since I am finding it very useful but don't want to have it tied to DISK94. One bug: In lowest resolution, the "S"tack display can overprint the "C"ache display; this is not critical. Everything else about this program is the same as DISK94; please read DISK94's documentation immediately above! You cannot run this program until you have run RAMnbmm.PRG, of course, just as with DISK94. --------------------------------------------------------------------- FASTBOOT == The Fast Boot Floppy Disk Maker == Avoid the Delay On Startup! MAKEDSK5.TOS If you run this program, it will create a "Fast Boot" disk, using Drive A:. TOS 2.05/6 has a 90-second delay on startup; if you leave this "Fast Boot" disk in Drive A:, when you start up, the system will briefly read this disk, and bypass the 90-second delay! Hence, you won't have to press a key to start up, or wait 90 seconds either. Because there was extra room in the boot sector, we added some graphics. They DO work on the low, medium, and high res ST modes, but may fail on higher resolution monitors. (Oh, well). CAUTION: This disk MUST be formatted at least single sided. And after running this program, this disk WILL NOT be accessible to GEM/TOS; the boot sector will be mangled pretty well. --> READ THIS <-- << Since some people didn't read that last paragraph, judging by tech supoort: WHATEVER DISK YOU RUN MAKEDSK5.PRG ON WILL BE BLOWN AWAY, SCRAGGED, WHAMMIED, WIPED-OUT, UNUSABLE, FELDERSNOCKER, FRICKLESNATZ! >> If you want a "Fast Boot" disk, this is the program you want; it is rather similar to the "NOROACH" program written by Ken Badertscher from Atari, which enables the Mega STE and TT computers to bypass the startup delays. ------------------------- TECHNICAL ----------------------------------- MAKEFRB5.TOS This is a program much like MAKEDSK5 above. However, there is an important difference; at System Startup time, this boot disk forces in an "_FRB" entry to the System Cookie Jar. Some hard disk software may need this to work properly; the "_FRB" is handled VERY differently among hard disk makers. Using a floppy in this way makes the Cookie Jar look a lot like TT TOS does, with an _FRB entry already there. ** CAUTION!! ** ** DO NOT USE THIS YET ** ** DO NOT USE MAKEFRB5.TOS UNLESS YOU'VE CHECKED WITH US!!! ** As of the SST's 1.86 release, WE KNOW OF NO HARD DISKS THAT NEED THIS PROGRAM -- AND YOU *WILL POSITIVELY* HAVE PROBLEMS IF YOU USE THIS WITH Atari, ICD, OR Supra HARD DISK SOFTWARE! Again, YOU WILL HAVE PROBLEMS IF YOU USE THIS PROGRAM UNDER EVERY HARD DISK TYPE WE HAVE TESTED! We are ONLY including this program because we have not tested all hard disks available in the world, and it could prove necessary if the hard disk software is written a certain way. In that case, we wanted to have the program easily available to you. Before you try it, PLEASE try starting up SST RAM, then running from the hard disk with and without running DISK94. Give us a call or FAX, telling us your hard disk situation, before trying out this program. As with MAKEDSK, this program REQUIRES a pre-formatted floppy disk (single or double sided) and WILL wipe out any data on that floppy disk. Careful! --> READ THIS <-- << Since some people didn't read that last paragraph, judging by tech supoort: WHATEVER DISK YOU RUN MAKEDSK5.PRG ON WILL BE BLOWN AWAY, SCRAGGED, WHAMMIED, WIPED-OUT, UNUSABLE, FELDERSNOCKER, FRICKLESNATZ! >> Again, we are ONLY including this program in the event some hard disk software is TT-only, and requires an _FRB cookie early on in boot time. It positively WILL screw up using the hard disks we have tested it with that do not have that requirement. --------------------------------------------------------------------- QUICKST 96462 Subdir 40% 58384 0 --- 28 0:00a 0000 == Quick ST 2.2 SST Version == QINDEX22.PRG 11648 Packed 0% 11653 22 Feb 89 0:05a f44c This is Quick-Index, the benchmarker, version 2.2. It's a lot like 1.5 or 1.8, but includes comparisons with a 32 MHz TT (selectable at bottom right). QST2CUST.ACC 20510 Crunched 41% 12121 13 Sep 90 10:21p 5556 QUICKSTC.PRG 32453 Crunched 48% 16937 0 --- 28 0:00a 8e8a QUICKSTM.PRG 31851 Crunched 45% 17642 0 --- 28 0:00a b01f This is a special version of Quick ST, compiled especially for the SST and TOS 2. Quick ST is a "screen accelerator"; it replaces the system ROM routines that draw things to the video screen with more efficient, faster routines. The performance increase is often very startling. We include this because video RAM is limited to 8 MHz access (see the first 50 or so pages of the manual!) and you might as well get everything you can get out of those video accesses! To use this program, put either QUICKSTC (for color) or QUICKSTM (for monochrome) into your AUTO folder. If you put RAMnbmm.PRG into your AUTO folder as well, put Quick ST to run afterwards. It will load in at start up time, intercept and replace the system routines, and speed things up. You will find the SST's 68030 cache and Quick ST code work very, very well together. The desk accessory is for adjusting Quick-ST's parameters, turning it on or off, changing background patterns, and whatnot. It goes into the C:\ (root) directory and IS OPTIONAL if you're limited on D/A's. ** ** CAUTION: KNOWN BUG ** ** Note: I have seen an interaction where screen redraws become confused, possibly by self-modifying code in Quick ST. If you should see this (the most common symptoms are menus "blacking out" or "zoom boxes" staying on the screen) turn off Quick ST either in the AUTO folder (easy way: rename it to QUICKSTx.PRX instead of .PRG), or use the D/A. Interestingly, I have ONLY seen this with the D/A loaded ... perhaps the the interaction is in there, as the D/A seems to modify the Quick ST code. It is also possible I can get an update to Quick-ST that will cure this problem; it is reported to ALSO happen when Quick-ST is used with a Blitter, on a regular 68000 system (not a 68030). It is unlikely that Darek's Quick-ST for the TT will work on the ST, since the TT uses different video tables than the ST. However, it's possible a machine independent version might work. I asked Darek to build one especially for the 68030 and the SST, and this is the result; the Beta Testers and I have used it for months with no problem except the one mentioned above, and again, I *only* had a problem with it when I installed the desk accessory. See how it works for you; if it shows those problems you may want to remove the desk accessory. << Note: We are right now in the process of getting a newer version of Quick-ST, called WARP-9, from CodeHead Software, who recently acquired rights to it. It's a special version, assembled for use on a 68030, but with *ST*, not *TT*, style "video planes" (hi-techy stuff.) WARP-9 didn't pass our testing as of right before this disk release, so we'll stick with Quick-ST 2.2 for now. >> --------------------------------------------------------------------- MAGPLOT MAG_NO.FPU == Magplot without an FPU == MAG_CLIP.PRG 12724 Crunched 44% 7218 0 --- 28 0:00a 9c47 MAG_NCLP.PRG 12726 Crunched 44% 7213 25 Jan 92 12:55p 4bf6 This is a program I wrote for the original issue of START Magazine (USA, not the other one). It plots the electrical field lines surrounding charged points, which also look exactly like the magnetic force lines flowing between magnetic poles! If you have ever seen iron filings and a magnet, you have a good idea what MAGPLOT does. I've included it here because it effectively demonstrates some features of the SST, namely the ability to handle extreme, severe number-crunching. MAGPLOT does *MASSIVE* amounts of floating point calculations; in particular, for EVERY 2-pixel line element drawn, it runs this equation for every point on the screen to the present point: SQRT ( (x2-x1) ^ 2) + (y2-y1) ^ 2) ) (Hence, the more points on screen, the more slowly it will run, by quite a bit.) There are several versions of this program. They are just options within the program; back when I wrote it, I didn't have much idea about how to use GEM (as you will see; this was early 1986!) One version "clips off" field lines to the displayable area; this is MAG_CLIP (ST RAM loading). You can set its program flag to make it SST RAM loading. You will see a substantial difference in speed between these two programs, since one is running in ST RAM, and one is running in SST RAM. Clipping off field lines that fall off the display is all very fine, but many of them would re-enter the display given a chance (and some would not-- they would go out nearly forever.) The other version does not "clip off" field lines until they get far, far beyond the bounds of the screen (I believe 700 pixels is the arbitrary limit). Lines OFTEN re-enter the displayable area, and this makes for a better display; it also takes a lot longer. MAG_NCLP.PRG is the ST-RAM loading version of No-Clip MAGPLOT. FMAGNCLP.PRG is the SST-RAM loading version of No-Clip MAGPLOT. Again, the SST RAM version runs MUCH more quickly. For your information, these programs were compiled with Alcyon C, back in about 1985-early 1986. The source code is available on the START Disk #1, and I have found it in many places. --------------------------------------------------------------------- However, there is another, VERY MUCH FASTER, Magplot: MAG68881 == MAGPLOT Using The Floating Point Chip == SST RAM Versions: No Clipping: MAGPLOT3.PRG << This is a recently updated version of Magplot, Version 3. It fixes some annoying bugs (like exiting when the first line was drawn too fast, while your finger was still on SHIFT) and probably adds other bugs, too. It also has a "benchmark mode" I'm working on; press CTRL once inside MAGPLOT3 to see this. >> We supply the 68882 processor on Option C boards. The 68882 is essentially a faster 68881 processor, capable of "pipelining" several things at once, and Wow!, does this program ever show it. This is a typical real-world increase found using floating-point hardware. You will find that even the ST-RAM version of this program with FPU support will far beat the SST-RAM version without FPU support. The program is such a number-cruncher that helping the math to be fast is very, very helpful, even moreso than helping out the 68030. A very interesting comparison can be made by comparing the 68881/2 program with 9 or so points with a non-FPU version. Be prepared to spend several hours waiting on the non-FPU version. Note: The FPU version was altered in several ways by necessity. I also increased the maximum number of points to 50. There may be a bug in the older, non-FPU version that sets a maximum of 10 points, by accident. Believe me, if you experience the non-68881 version with even 10 points, you will never want than many again ... (*Sigh*, I had to TEST them; I know!) MAGPLOT3 for the FPU is set for SST RAM. How To Use MAGPLOT In One Easy Lesson MAGPLOT runs in low, medium, or high res. There were no bigscreen monitors back in 1986 when I wrote it, so I have NO IDEA if it can run on (say) a Moniterm or other big monitor. Sections of it WERE written to try to be resolution independent, but there was never a way to test it. It uses the VDI for plotting, and only the mouse button and SHIFT keys for entry (no menus, etc.) I did not understand GEM back when the ST was that new! I would include the C source code, but I'm embarrassed ... I mean, I am unsure I have the right to after START magazine bought it. It's not exactly clean, structured code. In color mode, after the plot is complete, you get some color register shifting which will show you the flow from the + points to the - points. If you're running an "F" ("F"ast; SST RAM) version, of course be sure SST RAM is on. Anyway, double-click on the program. The screen will black out, and you'll have an arrow. Click anywhere on the screen except possibly the very top menu area. Two labels, "POS" (Positive) and "NEG" (Negative) will show up on the top-right side. Click on either one to select the charge on the point. This version of the program doesn't allow you to set the amount of charge other than +1 or -1, but there are other versions that do; I did not know how to enter data via the keyboard and settled for positive and negative. The program will then draw your point with a circle around it, and a + or - showing its charge, and remove the POS/NEG selector. Continue entering points, up to a maximum of 50, until you are done. Note: The non-FPU version MAY crash above 10 points entered; anyway, you will find out that the non-FPU version is so slow at even 10 points that you won't be using 10. The points can pretty much be anywhere, but it's possible to confuse the program if you plot them right on top of the POS/NEG selectors or the Press Shift to START area. It's best to stay out of the "menu bar" even if you can't see it. Caution: The program might fail if two points of opposite charge are nearly on top of each other; the line start-end algorithm is not 100% solid (it's a fairly tricky thing to end the lines). All the time you are plotting points, you have the option of starting. It will say "Press SHIFT to Start". Press the SHIFT key to begin plotting all the field lines from the + points. (Thus, the more + points, the longer the display, more lines, and more interesting; you CAN'T plot from negative, -, points, as they "pull in"!) Caution: On the 68881 versions, press SHIFT and LET IT GO VERY FAST INDEED. Press SHIFT anytime during plotting to end; it is checked anytime a line begins or is offscreen. You may have to hold down SHIFT a few moments. NOTE: On the 68881 version, plotting is so fast you will have to be careful to LET GO of the SHIFT key before the first line is complete! Otherwise you'll have pressed SHIFT to start, it'll draw the first line, see the SHIFT is still down, and exit. Well ... look, when I wrote this program in 1986, there was NO hardware that could make it draw that fast! The program has definite limits and needs polishing, sure, but in the meantime, have fun with it. On color systems, when the plot is finished, color register shifting will happen to show you the flow along field lines. You will exit back to the GEM Desktop (or whatever) when you press SHIFT again. I have disabled the CTRL/ALT options for this program that are mentioned onscreen because they cause the program to act strangely. Note: A known bug of MAGPLOT is that it does not restore screen colors. The COLOR CPX will do that for you quickly; the MAGPLOT code is murky enough without me changing it six years later! I apologize in advance for that bug. << On MAGPLOT 3, new on the 1.87 disk, press CTRL to do a standard benchmark plot; we'll soon add timer functions to time exactly how long the plot is and so forth. >> Things to watch for: * + points will oppose; you can have quite an interesting time building a "wall" of + points that will reflect anything. * Groups of same-charge points will have the effect of building up a "black hole" or "supernova", depending on charge. * Watching the color display shift too long can cause hallucinations. Finally, I should point out that I originally wrote MAGPLOT in 1987 in Control Data Cyber-171 BASIC for a Tektronix 4013 "Storage Tube" terminal, and it has since seen duty on the PLATO system, the Macintosh, and the ST. The SST/68882 version is far and away the fastest, even though the Cyber was renowned for number-crunching. MAGPLOT helped me (considerably) to pass first-year Physics as extra-credit; without it, I might not have met Sandy Heidlebaugh the *second* year of college. No jokes about "electrical attraction", please! ===============> NEW FOLDERS IN 1.87 <================ BUTTON.FIX This is a tiny desk accessory that tends to help with a problem in TOS since TOS 1.4 was released, including your TOS 2.06. When you click the mouse button, particularly on a scroll bar, it is as if you clicked twice; for instance, in a word processor, two screenfuls of data will fly by instead of one. If you put this desk accessory in, you will find this tendency greatly reduced. Refer to its documentation!! For example, you may have to access the D/A (once) to really get it going well. It works more or less by voodoo ... but it does work. X_MON: X_MON is a program Doug Wheeler wrote for Extended Moniters (like Moniterm). We are including it because many Moniterm (and possibly other graphics moniter drivers) are not 68030 compatible, and X_MON is. If you're going to run a Moniterm with the SST, you need to do several things. judging by many installations we have done: 1) You MUST get a bigger power supply. The Moniterm board plus the SST overloads the Mega supply. George Richardson at the Merlin Group has an excellent Mega power supply we recommend. (The big problem is current on the +5 line; it exceeds 3 AMPS with the Moniterm and the SST, and the Mega power supply just gasps and folds.) 2) You MUST add some modifications to your Moniterm circuit board. The board is apparently not designed for computers that can run above 8 MHz and even exhibits "glitching" (small horizontal black lines) at 8 MHz! There are some timing problems we have tracked down on the Moniterm circuit board. If you don't do this, your Moniterm's glitch rate will go WAY up. 3) You MUST run Quick-ST 2.2; it works with X_MON to keep things compatible. Otherwise, we observe a "crash" as the "screen clear" routine runs clean off of Moniterm memory at $C0 0000 into $D0 0000. --------------------------------------------------------------------- PROGRAMS NOT IN FOLDERS --------------------------------------------------------------------- MEMSTAT6.TOS This program is discussed in the manual. It gives you a "Memory Status" display onscreen, of ST, SST, and total System (ST + SST) memory available, used, and free. If SST RAM is not switched on (if you have not run RAMnbmm.PRG) this program will tell you. Note: If location $5a4 has been set (this happens), MEMSTAT6 can show you a display of 4 or 8 megabytes of SST RAM, but, ALL OF IT will be "In Use"! That's a sure clue that RAMnbmm.PRG has not been run to clean things up, and TOS is a little unsure of itself. You can also use the Extended Control Panel to check System RAM. Click on the Status button to get a RAM display. Note: For reasons I don't understand, sometimes the Extended Control Panel display adds up ST and SST RAM and displays that as "Total ST RAM", rather than as "ST and TT RAM", seperately. ("TT RAM" is what the Extended Control Panel calls "SST RAM".) Note: MEMSTAT uses Malloc (-1) or MxAlloc (-1) to show the largest available block of memory. It does not "walk Malloc" to show all available blocks, as the 20-Malloc limit still lurks by habit in me. Anyway, as a GEM program, it's going to show you the effective free memory you're going to get. --------------------------------------------------------------------- MMU24BIT.TOS 2730 Crunched 35% 1794 3 Dec 31 1:15a 4a1b This program switches the SST to "24-bit" mode, where the 68030 is only aware of 16 Megabytes of memory, just as the ST had. There are programs, notably anything written in GFA-Basic, which are not compatible with the full 4-Billion-Bytes 32-bit memory 68030 capability; technically, they use the upper 8 bits of the "program counter". This will fail if the SST is in normal, 32-bit mode, which it usually is. If you want to run a known 24-bit program, first run MMU24BIT.TOS to switch to 24-bit mode. TEMPUS2 is another program that is 24-bit only; there are doubtlessly others. CAUTION: SST RAM is located after the first 16 megabytes. You will switch off ALL ACCESS to SST RAM if you run this program! Also, you can only regain 32-bit mode by a ColdStart RESET (see COLDBOOT documentation in manual). THERE IS NO (well, not yet) MMU32BIT.PRG, okay? This is *NOT* our permanent solution to 24-bit software, but it will "get you by" and working for now. Note: This is just about identical to Atari's 24BIT.PRG and is used the same way and for the same reasons. However, 24BIT.PRG doesn't work on the SST -- it checks to see if it's on a TT with the TT memory scheme and ROM numbering. PRGFLAG.PRG 28652 Crunched 25% 21736 27 Aug 90 3:14p 6a3c This program, written by Atari and released for distribution, allows you to set the "Fast Load", "SST RAM load", and "SST RAM Request" bits inside of a program. We talk about it quite a bit in the manual. Essentially, if you want a program to load into SST RAM and run quickly, you use PRGFLAG to set the "TT RAM" load flag of the program; after that, when you run the program, it will run in SST RAM. (You can change it back, too.) Note: The flag that says if a program loads into SST RAM or ST RAM is PART OF THE PROGRAM. If you set the flag, and copy the program, the COPY will also have the bits set. HOWEVER, with PRGFLAG, you are only CHANGING ONE PROGRAM, NOT ALL PROGRAMS ON ALL DISKS NAMED THE SAME. It is not a "global" change of all programs named something. For instance, you might change ONE "emacs.ttp" program; that doesn't mean ANOTHER "emacs.ttp", on a floppy or another hard disk partition, will load into SST RAM. They must all be changed by hand and tested (for some probably will not work in SST RAM because of bugs). I wish there was a different scheme, too (say, a different program name automatically loads into SST RAM). I don't have one. The CPX folder also has a desk accessory that can change and display these program flags. --------------------------------------------------------------------- RAM3333.PRG 36937 Crunched 56% 16554 3 Dec 31 1:28a 6db0 See the manual for a LONG discussion of this program. THIS IS THE SST RAM INITIALIZER (often called RAMnbmm.PRG). As you can see from the "3333", it is currently configured for 3 normal wait states, 3 burst mode wait states, and 33 Mhz. PLEASE configure it properly for your system before using. With Option "C"/"D" SST's, it's probably right as is, although you will want to try reducing wait-states; see the manual. As I'm writing this, I am using a 2&2 wait-state board from the "ready to ship" boards! If you put this program in your AUTO folder, SST RAM will be turned on automatically at startup. You may or may not want to do this; that's up to you. If SST RAM is switched on before the GEM Desktop starts, the GEM Desktop will load into SST RAM, along with Desk Accessories if they are "set for" SST RAM (see PRGFLAGS). The D/A's may not like running in SST RAM, although we haven't seen many problems. If the GEM Desktop is in SST RAM, you may see a definite increase in program performance; we believe this is because the supervisor stack is switched to SST RAM. Since the supervisor stack is used VERY frequently, it makes sense that moving it to a faster RAM would help performance. (Quick Index 1.8 says there's about a 100% speed gain!) IF YOU setup in AUTO, be CERTAIN to read about AUTOMMU and DISK94 above, and be VERY careful of the order. The run-time order (and the order you copy them into the new AUTO folder) should be: 1) AUTOMMU 2) (optional) COLDBOOT 3) RAMnbmm.PRG 4) (if needed) DISK94.PRG Again, PLEASE see the AUTOMMU notes above. You will need them set up to work with RAMnbmm.PRG or conflicts will cause you trouble; for instance, if DISK94 is run before RAMnbmm.PRG, then DISK94 will exit without doing anything, since it will not find the F117 Stealth Buffer, where all disk transfer (and bad puns) happen. If AUTOMMU2 is run after RAMnbmm.PRG, it will wipe out critical tables. The order is critical, and you have to configure it. IF you put this program in the C:\AUTO folder, BE CERTAIN to put a copy (or, really, ANYTHING) named the same into C:\ (the root directory). IT IS THE NAME THAT IT CRUCIAL! (Due to a TOS fluke, AUTO folder programs looking for the directory are shown the C:\ directory, not the C:\AUTO directory (sigh)). ** KNOWN BUG TO WATCH OUT FOR: ** IF you initialize SST RAM in the AUTO folder, and thus have GEM load up into SST RAM, and IF you turn your BLITTER chip on THEN: You will get a very odd looking desktop. The problem here is that the ICONS for the desktop (the floppy disk, hard disk, trash can icons) are being stored in SST RAM (where, honestly, they DON'T BELONG -- but alas, I did not write that code). As we've said many times, SST RAM is completely and soulfully dedicated to the 68030, and the BLITTER chip is like the Video or DMA chips -- it takes over memory COMPLETELY when the BLITTER turns on. Hence, you can guess that the SST memory refuses to be taken over, the BLITTER cannot access the icons in SST RAM, and you end up with a Real Interesting screen. There is no fix for AUTO folder SST RAM init and BLITTER we can find. We recommend simply turning the BLITTER off if you run into this. The Atari TT *has no Blitter*; that is very likely why this problem happens. Since the TT has no Blitter, the TOS is not expecting to have to worry about having the icon images in non-grabbable memory. Honestly, with the 68030's speed (particularly in icon draws, which tend to cache nicely), you're not missing anything with no Blitter; Atari didn't think so, either. --------------------------------------------------------------------- STACK1.TOS 2161 Crunched 78% 486 0 Dec 31 8:37p 213c This unusual program, already set to run in SST RAM (you must have SST RAM turned on), attempts to shift the system "Supervisor Stack" to SST RAM to improve performance; the SuperVisor Stack is used extensively, and putting it into faster RAM improves performance. Note: Putting RAMnbmm.PRG into the AUTO folder will do the same thing, apparently; we get identical benchmark figures on acceleration improvements after running STACK1.TOS that we get by putting RAMnbmm.PRG into the AUTO folder. They do not work together, though; running STACK1.TOS with an AUTO folder'd RAMnbmm.PRG will give you NO gain. Quick-Index (see above listing) will show a 100% + increase in performance in the CPU-Memory benchmark if you run this little program. We are still not certain exactly how this works. Debuggers disagree about it moving the stack, and the "Heads Up Display" does not always show the SSP in SST RAM (although, the H-U-D may have a bug, or the SSP may not be 32-bit clean). Still, it speeds things up ... ... in the spirit of "You Know Best", we have included it on the release disk. Besides ... what's life without a little mystery? This program is VERY short and easy to disassemble; all we are doing is using the Super() call to put the A7 Supervisor Stack "on top of" the program, then exiting. Since the program is set to load into SST RAM, that moves the SSP to SST RAM. --------------------------------------------------------------------- READ.ME That's this file -- which is now done! --------------------------------------------------------------------- We very much hope you enjoy your SST and have many fun hours with your ST of the 1990's. ===================== End of 1.86 Release Disk =================