No Fragments Archive 12: Textmags & Docs/nf_archive_12.iso/MAGS/TEXTMAGS/ATARI16/INFO89.ZIP/INFO89/409.TXT

Text File | 1997-04-16 | 18KB | 411 lines

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![e-mail]  (Greg Lindahl)
Subject: Re: Towards a real, somewhat compatible multiTASKING TOS
To: [e-mail]

In article <[e-mail]> [e-mail] (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
[e-mail]                                             I'm not the NRA.

------------------------------

Date: 22 Jul 89 21:32:37 GMT
From: vax5![e-mail]
Subject: Disk Repair Advice
To: [e-mail]

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![e-mail]  (Farrell Woods)
Subject: Re: Mono monitor problems
To: [e-mail]

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:  [phone]
Concurrent Computer Corporation            Domain: [e-mail]
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![e-mail]
Subject: Data transfer from Apple ][ to ST 4 ?
To: [e-mail]

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: [e-mail]

In article <[e-mail]> 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![e-mail]  (P E Smee)
Subject: Re: PC Board Designer/Atari ST Software Bargain
To: [e-mail]

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: [e-mail]
 Computer Centre         |   BITNET: [e-mail]
 University of Bristol   | Internet: [e-mail]
 (Phone: [phone]) |     UUCP: ...!mcvax!ukc!gdr.bath.ac.uk!exspes

------------------------------

Date: 17 Aug 89 05:51:22 GMT
From: pacbell!sactoh0![e-mail]  (Mark F. Newton John)
Subject: DOS 3 errata notes
To: [e-mail]

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![e-mail]  (Joe Gilray)
Subject: Designing HIs under GEM
To: [e-mail]

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![e-mail]  (George Seto)
Subject: RESET-PROOF RAMDISKS & Line A routines
To: [e-mail]

 RESET-PROOF RAMDISKS & Line A routines:

  John [e-mail]

 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
  -==-==----==-==-   [phone] 3/12/2400 8N1 24h/7d
 -==-------==------  [e-mail]
  -==-==----==-==-   uunet, utai, watmath!dalcs!iisat!brains!george_seto

------------------------------

Date: 17 Aug 89 10:01:55 GMT
From: mcvax!hp4nl!phigate!philmds![e-mail]  (Leo de Wit)
Subject: Re: Towards a real, somewhat compatible multiTASKING TOS
To: [e-mail]

In article <[e-mail]> [e-mail] (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![e-mail]  ( James )
Subject: IN SEARCH of SEAGATE 296N HD w/ ROM rev. 7
To: [e-mail]

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: [e-mail]
Bitnet: [e-mail]

------------------------------

End of Info-Atari16 Digest
**************************
-------

ə