Info-Atari16 Digest Wednesday, August 23, 1989 Volume 89 : Issue 409 This weeks Editor: Bill Westfield Today's Topics: Re: Towards a real, somewhat compatible multiTASKING TOS Disk Repair Advice Re: Mono monitor problems Data transfer from Apple ][ to ST 4 ? Re: mx2 query Re: PC Board Designer/Atari ST Software Bargain DOS 3 errata notes Designing HIs under GEM RESET-PROOF RAMDISKS & Line A routines Re: Towards a real, somewhat compatible multiTASKING TOS IN SEARCH of SEAGATE 296N HD w/ ROM rev. 7 ---------------------------------------------------------------------- Date: 17 Aug 89 03:17:02 GMT From: gem.mps.ohio-state.edu!ginosko!aplcen!haven!uvaarpa!hudson!astsun7.astro.Virgin ia.EDU!gl8f@tut.cis.ohio-state.edu (Greg Lindahl) Subject: Re: Towards a real, somewhat compatible multiTASKING TOS To: info-atari16@score.stanford.edu In article <877@per2.UUCP> dag@per2.UUCP (Daniel A. Glasser) writes: >There's been a lot of chatter about multitasking on the ST, but no real >concrete proposals. It seems that many of the people in the debate are >not aware of the difference between a multitasking system and a multi-user >system. No, there is one concrete program out there (Beckmeyer's stuff) and Leo is working on another real system. And there are lots of people talking past each other about multitasking and multiuser and all that. Keep in mind that there is NO EASY WAY to add multitasking to GEM (the graphics part) such that you can have several gem applications going, but with a multitasking GEMDOS (which provides functions like MS-DOS), you could write a desk accessory that would allow you multiple multitasking CLIs along with 1 GEM application. It doesn't matter whether this is the most optimal solution, because this is what can be done without totally re-writing GEM. :-) :-) ------ Greg Lindahl gl8f@virginia.edu I'm not the NRA. ------------------------------ Date: 22 Jul 89 21:32:37 GMT From: vax5!yz2y@cu-arpa.cs.cornell.edu Subject: Disk Repair Advice To: info-atari16@score.stanford.edu I messed up both the boot sector and the FAT table sectors on a disk, but the data sectors are intact. Is there anyway to recover the files from this disk? I have tried Disk Doctor and got nowhere. Help! -Steve ------------------------------ Date: 22 Jul 89 13:33:14 GMT From: mailrus!ulowell!masscomp!ftw@csd4.milw.wisc.edu (Farrell Woods) Subject: Re: Mono monitor problems To: info-atari16@score.stanford.edu Two folks have mono monitor problems, so I'll address both here. To the fellow who has a linearity problem (the characters at the top of of the screen get tall, etc.): Go to Radio Shack and get yourself a can of "freeze mist". Also, arm yourself with a handheld hair dryer. With the monitor running, and the back off, use the hair dryer to heat the innards some. This should cause the problem to appear more quickly than it would otherwise. Then, take the freeze mist and carefully zap components in the vertical circuitry. Observe the picture while you do this. When the picture snaps back to "normal", you have your faulty component. To the fellow with the jitter and bends: The jitter might be fixed by adjusting the "vertical hold" pot. I don't recall its location; it's been a while since I've had my monitor apart. For the bends, it's probably caused by a little too much enthusiasim when the previous owner stretched the picture. You might try backing off on some of those adjustments. The rings you see on the back of the yoke are for centering the picture on the face of the tube. -- Farrell T. Woods Voice: (508) 392-2471 Concurrent Computer Corporation Domain: ftw@masscomp.com 1 Technology Way uucp: backbones!masscomp!ftw Westford, MA 01886 OS/2: Half an operating system ------------------------------ Date: 15 Aug 89 10:23:08 GMT From: mcvax!cernvax!cui!ugun2b!ugcmu!stouder@uunet.uu.net Subject: Data transfer from Apple ][ to ST 4 ? To: info-atari16@score.stanford.edu I have an old Apple ][e and a ST 4. I'd like to read data stored with Apple ][ on 5.25 '' diskette with my ST 4. How to do that ? Thanks. Alan Stouder ------------------------------ Date: 17 Aug 89 02:13:54 GMT From: cs.utexas.edu!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!gryphon!crash!fgbrooks@ tut.cis.ohio-state.edu (Fred Brooks) Subject: Re: mx2 query To: info-atari16@score.stanford.edu In article you write: >Well, I've been seeing tons of references to MX2 in the latest flurry >of multitask mania. I'm curious...Does MX2 allow you to multitask ANY >program or just the small set that comes with it? I'd find it useful if >I could do some thing like: Run UniTerm as one task (downloading a file), >unARC the file as a separate task, and during this time format a disk as a >third task. I often start d/ling a file and then realize I don't have space >on any disks. This is when I kick myself for not having some way to have >that idle disk drive format a new disk while I'm using the cpu for other >things. I've seen this done on an Amiga relatively easily. > >Also, how does MX2 measure up to the multitasking environment written by >Dave Beckermeyer (sp??)? Enquiring minds want to know. :-) MX2 will run most "well behaved" TOS programs. TOS being programs that use the BIOS I/O calls. I use it to run a BBS "STADEL" program or uucall "a uucp type program for unix mail" in background. As MX2 is a PD program, MTC shell or RTX by Beckermeyer may be a better product but MX2 comes with the complete source. BTW I wrote MX2 and would be glad to give you a copy of the latest version to play with. Or if you use GENIE look for files 11360 and 11361 in the atari archives. I think a copy of a older version is in the atari archives here. Fred brooks ------------------------------ Date: 16 Aug 89 15:13:29 GMT From: mcvax!ukc!dcl-cs!gdt!gdr!exspes@uunet.uu.net (P E Smee) Subject: Re: PC Board Designer/Atari ST Software Bargain To: info-atari16@score.stanford.edu I've found myself wondering whether PC board designers couldn't be used to make maps for adventure games. Seems to me that the typical adventure 'room' could be regarded as a box with up to 10 connections (Up, Down, 8 compass points) so you could lie to the software and tell it it was working with 10-pin IC's. The 'paths' between the rooms then become the traces of the PC, of course. Has anyone actually tried this? -- Paul Smee | JANET: Smee@uk.ac.bristol Computer Centre | BITNET: Smee%uk.ac.bristol@ukacrl.bitnet University of Bristol | Internet: Smee%uk.ac.bristol@nsfnet-relay.ac.uk (Phone: +44 272 303132) | UUCP: ...!mcvax!ukc!gdr.bath.ac.uk!exspes ------------------------------ Date: 17 Aug 89 05:51:22 GMT From: pacbell!sactoh0!mfolivo@ames.arc.nasa.gov (Mark F. Newton John) Subject: DOS 3 errata notes To: info-atari16@score.stanford.edu Someone had posted that Atari included errata notes with manuals to DOS 3 dated 5-1-84. Now since it has been about five years, I doubt that any dealer would have DOS 3, let alone any notes. Perhaps someone who still has a DOS 3 manual put away somewhere could post the errata notes. Mark Newton-John -- ############################################################# # PRIVATE # SAC-UNIX, Sacramento, Ca. # # PARKING # UUCP=...pacbell!sactoh0 # ------------------------------ Date: 16 Aug 89 19:10:07 GMT From: hpfcdc!hpldola!jg@hplabs.hp.com (Joe Gilray) Subject: Designing HIs under GEM To: info-atari16@score.stanford.edu I would like to start a discussion about human interface design under GEM. Lately I've been building some dialog boxes for a GEM application, and I got to thinking about the following: 1) Is there any standard "look and feel" for dialog boxes? More than just Title at the top, buttons across the bottom? For example I would like a single dialog to handle several different cases, so I turn off inappropriate Object sub-trees with the ob_flag HIDETREE bit. Now each Object sub-tree has its own location in the box so when I turn some off there are "holes" in the box. I could place different Object sub-trees in the same location (as long as they will NEVER be both visible at the same time) but I don't want to do this as I feel that the user will find it easier to learn and use the box if it is possible to associate a location with a function. What do you think? 2) I also tend to use nested dialogs quite a bit. I like to keep the amount of information on a given dialog limited (this can also be helpful in making a dialog multipurpose, i.e. useable in many different parts of an application). Do you think that nested dialogs are too hard to use? I know that they can be harder to write as you often have to allow the user to move up and down through the levels of dialog hierarchy and may have to offer the same function in several different boxes (i.e. Abort, finished, etc). 3) One of the reasons I use nested dialogs is a limit I think I've found in GEM, it appears that there must be less than 256 editable (FTEXT, FBOXTEXT) characters per box in GEM. Has anyone else noticed this (I am using original ROM TOS)? Is this fixed in QuickSt or TurboSt? -Joe Gilray ------------------------------ Date: 16 Aug 89 06:35:15 GMT From: cs.dal.ca!iisat!brains!george_seto@uunet.uu.net (George Seto) Subject: RESET-PROOF RAMDISKS & Line A routines To: info-atari16@score.stanford.edu RESET-PROOF RAMDISKS & Line A routines: John Lindwall@tw-rnd.SanDiego.NCR.COM Yup, we have quite a few Ramdisks which are "bootable", ie created when we power up the machine. Most of these are reset-proof, which I assume is what you mean by warm boot. These keep their contents after a press of the Reset button. They tie into the vectors and make sure the section of memory isn't touched and that the driver handling it stays around. ETERNAL2 is the most popular and is PD. Are there no Atari ST BBS's out there? If not try Atari's BBS's in Northern California. Should be available there. I know of several systems in the north-east. Craig Shock @ cs-spool.calgary.UU Are you on any of the STadel/Citadel-86 systems in Calgary? Seems to me some of them tie into the STadel netted C room. Authors such as Steve Yelvington & Tony Andrews are on there tied in through Four Wheeling BBS in Colorado or BRASS in the New York states. Let's see..... Poopsie at 403-288-4481. Not sure if they do, but they are a STadel system and might be tied into the proper net. If not there are others up there. -- -===------===- From George Seto at Cerebral Cortex BBS System -==-==----==-==- (902)462-7245 3/12/2400 8N1 24h/7d -==-------==------ george_seto%brains@iisat.UUCP -==-==----==-==- uunet, utai, watmath!dalcs!iisat!brains!george_seto ------------------------------ Date: 17 Aug 89 10:01:55 GMT From: mcvax!hp4nl!phigate!philmds!leo@uunet.uu.net (Leo de Wit) Subject: Re: Towards a real, somewhat compatible multiTASKING TOS To: info-atari16@score.stanford.edu In article <877@per2.UUCP> dag@per2.UUCP (Daniel A. Glasser) writes: |There's been a lot of chatter about multitasking on the ST, but no real |concrete proposals. It seems that many of the people in the debate are |not aware of the difference between a multitasking system and a multi-user |system. I have a real and very concrete proposal. It's the multitasking system I'm building right now. Read on. |[] |Changes to TOS for application driven multitasking might include the following: |[] | 1) An extended basepage which contains entries for various hard and | soft exception vectors. Notably, there should be a termination | vector, divide by 0 vector, buss-error, address error, critical | error, illegal/invalid instruction, break-point, etc. A TOS call | to set the vectors (Set Exception Vector) already exists, and | could be modified to use the extended basepage. The entries in | the extended basepage vector table would have three reserved values: | -1L means use the parent process value for this vector, -3L means | use the system default routine for this vector, 0L means ignore | this exception, any other even value is taken as the address of | an exception routine to be jumped to in the case of the exception. | All other odd values are reserved. My solution uses per process an array of 32 exception vectors, which resemble the standard set of signals for a BSD type UNIX system, a signal mask to indicate which signals are currently being blocked, and a set of 'signals to be delivered'. Signals can be ignored, defaulted, and set to user-supplied routines. Instead of Setexc() I introduced calls like signal() and kill() to set and invoke signals (they are triggered via an extra GEMDOS function). The signal mask is inherited from the parent by child processes, which means that ignored signals stay ignored (unless the child explicitly calls signal()). Not-ignored signals are defaulted. This is all conforming standard Unix. Perhaps I could add some of the suggestions you made (when it doesn't violate my sense of a clean system; some ideas sound really nice). | | This vector table would allow programs that set exception vectors | to abort abnormally without fear of bringing the system down, and | allow multiple programs to set exception vectors for when they are | the active task. The vector table could have more or different | entries than are in the system table now, for example, a control-c | vector, an I/O Timeout vector, a message-received vector, etc. I intercept the keyboard interrupt and store occurences of ~C,~\ and ~Z. These are passed to the running program as SIGINT (default action: terminate), SIGQUIT (default action: terminate with coredump) and SIGTSTP (default action: stop the process - it can be restarted later). There is no notion yet of fore- and background; when it's there, only the foreground job(s) can receive these keyboard-generated signals. Also SIGALRM has been implemented, with corresponding functions/system calls sleep(), pause(), alarm(). | | 2) A new TOS call to send a signal to a process based on its ID. I use one new TOS call to implement several new functions; the unused 0x4d. The first argument is the request. 2) would be kill(). | | 3) A new TOS call to unschedule a process until it receives a signal. This is pause(). | | 4) An extensible stream device list, similar to the extensible | block device list, allowing serial devices to be added and used | in the same manner as the standard streams. Pipes and perhaps semaphores, messages queues are planned. | | 5) A new TOS call to schedule a signal to a process at some delta-time. Don't know what you mean here exactly, but it could be alarm(). | | 6) An extension of the Mshrink TOS call to conditionally grow an allocated | block of RAM. Don't know what you mean by conditionally here; I'd say if you don't want the grow, don't do the call. | | 7) An extension to the Malloc command to return the size of the largest | contiguous available block of RAM. This is already there: call Malloc with -1 as argument. | | 8) An extension to the TOS Pexec function to start a task and continue. Indeed; also implemented. A priority can be given to the started task; priorities may be modified by the getpriority() and setpriority() calls. | | 9) The ability for an interrupt handler to access the process context | of a task. What do you mean by this: its own process context, or some other process's context; what would you want to do with it? |[] |This is just to get the ball rolling. Let's see some constructive ideas |on what a TOS 3.0 might look like. If we can get a good enough unified |collection of ideas, maybe the folks in Sunnyvale might use some of it. |If the ST commercial software development community publicly buys into |the ideas which may break lots of existing software, we might see some |real progress. What you will need also in a multitasking environment is some means of restricting the amount of memory supplied to a program; I found out many programs just don't Mshrink, so you need to control this too. B.T.W. thanks for some nice ideas, maybe someone else wants to add to this discusson too? Leo. ------------------------------ Date: 17 Aug 89 19:08:57 GMT From: cs.utexas.edu!usc!orion.cf.uci.edu!jtang@tut.cis.ohio-state.edu ( James ) Subject: IN SEARCH of SEAGATE 296N HD w/ ROM rev. 7 To: info-atari16@score.stanford.edu Does anyone know of any dealer that sells the SEAGATE 296N ROM rev 7?? I am in search of one, please mail me the address and phone number of the dealer. James Usenet: jtang@orion.cf.uci.edu Bitnet: JWTang@UCIVMSA.BITNET ------------------------------ End of Info-Atari16 Digest ************************** -------