No Fragments Archive 12: Textmags & Docs/nf_archive_12.iso/MAGS/DOCS/MULTITOS.ZIP/MULTITOS.ASC

Text File | 1992-05-12 | 109.7 KB | 2,981 lines

 ====================================================================

 (C) 1992 by Atari Corporation, GEnie, and the Atari RoundTables.  May be
 reprinted only with this notice intact.  The Atari RoundTables on GEnie
 are the *official* information services of the Atari  Corporation.


 To sign up for GEnie service, call (with modem in HALF DUPLEX)
 800-638-8369.  Upon connection, type HHH
 Wait  for the U#= prompt.  Type XJM11877,GENIE and hit
 RETURN.  The system  will now prompt you for your information.

 ====================================================================

 ************
Topic 34        Sat Mar 14, 1992
E.KRIMEN [Ed Krimen]         at 21:11 EST
Sub: MultiTOS

A topic for the discussion of Atari's MultiTOS, a multitasking TOS based upon
Eric Smith's MiNT.

210 message(s) total.
 ************
 ------------
Category 14,  Topic 34
Message 1         Sat Mar 14, 1992
E.KRIMEN [Ed Krimen]         at 21:12 EST

  From Usenet:

 Article 23475 in comp.sys.atari.st:
 From: [e-mail] (Nils-Henner Krueger)
 Subject: Re: MultiTOS \was MiNT copyright s
 Message-ID: <[e-mail]>
 Date: 13 Mar 92 13:57:00 GMT
 References: <[e-mail]>
 Organization: MausNet
 Lines: 21
 X-Gateway: MausGate/News 1.03

 Hi folks!

 e>As for the many contradictory rumors floating around about multitasking
 e>TOS; suffice it to say that wild speculation about unreleased products
 e>is rarely productive (and even more rarely accurate :-).
 e>Let's wait and see what Atari actually produces, shall we?

 Well, just yesterday at the CeBit fair I could see what Atari actually
 produces:
 There was a demonstration show of the comming MultiTOS, and it really _is_
 based on MiNT! They said that it will come out as a ROM-Upgrade, available
for
 _all_ Atari Computers down to the 1040 ST, although it won't be very usefull
on
 a maschine with less then 16mhz. They were not able to give any exact
 information about the release date, but they said that it will not be before
 the Atari fair in Duesseldorf (Germany) in august.


 -------------------------------------------------------
 Nils-Henner Krueger, Waitzstr. 98, D-2300 Kiel, Germany
 Phone: xx49/431/86267, email: [e-mail] (Internet)
 -------------------------------------------------------

 ~~~~~~


 Article 23476 in comp.sys.atari.st:
 From: [e-mail] (Bernhard Stumpf)
 Subject: MultiTOS really exists - thanks to Eric S.
 Message-ID: <[e-mail]>
 Date: 14 Mar 92 15:41:13 GMT
 Sender: [e-mail]
 Lines: 25

 Yesterday I visited the Hannover Cebit fair - and they really could show it:

                 The MultiTOS !!!

 It exists - and it runs!!!

 They had a beta version, but what I could see:

 Atari now has a OS like the Mac, it does Multitasking in several windows,
 not a task switching like the Mickey Mouse commander on a MS-DOS machine
(brr,
 I'll have to wash my mouth afterwards...).

 The Multitos runs at the moment as a program, but it will be distributed in
 ROMs. The Atari guy I spoke had to avoid that it bases on Eric Smith's work,
 they only added the GEM surface. He said that the development now will be
 continued on Atari side and will surely make another way than Eric's MiNT.


 That's all for now...


 Bernhard


 [e-mail]

 ~~~~~~


 Article 23477 in comp.sys.atari.st:
 From: [e-mail] (Techno)
 Subject: Multitasking TOS on CeBit
 Summary: Multitasking TOS shown
 Keywords: TOS,Atari,multitasking,CeBit
 Message-ID: <[e-mail]>
 Date: 14 Mar 92 20:55:42 GMT
 Distribution: comp
 Organization: LIME Systems featuring a TOGA Party
 Lines: 12

 Atari demonstrated the new multitasking TOS on the german CeBit computer
 fair. Due to the huge crowds, I was only able to cast a glimpse at it,
 though it seemed to run OK.

                             Techno

 --
 | [e-mail] ||| Please do not e-mail from outside Germany !
|
 | [e-mail]   / | \ Hardcore ST user !  ======================
|
 | Nothing that's real is ever for free, you just have to pay for it sometime.
|
 |                                        (Al Stewart)
|
   Hi ! I'm a .signature virus. Join the fun and copy me into your .signature
!

 ~~~~~~
 ------------
Category 14,  Topic 34
Message 2         Sun Mar 15, 1992
TOWNS [John@Atari]           at 13:43 EST

Yes, Atari did demonstrate the Multitasking TOS at CeBIT. There are currently
no estimated delivery dates or pricing information available. As soon as real
information is available, we will let you know.

-- John Townsend, Atari Corp.

PS. And yes, It is based on MiNT (MiNT is _NOW_ TOS! <grin>) from
    Eric Smith.

 ------------
Category 14,  Topic 34
Message 3         Sun Mar 15, 1992
M.ABDULKAREE [ASX]           at 16:06 EST

Hey.. I could have told you guys that! When I went down there (at Atari) they
had it running on Mike Fulton's machine and I NEVER figured out what it was
until they told me that it was indeed Multitasking TOS.. <wide grin> (Okay, so
every one knows now.. I can spill the bits!)


You can switch application by going to the Desk menu and selecting the
application-- the last time I saw it simply put in the programs filenames, I
suggested that they allow the program to register a name it wants using an
extention to appl_init(name). Also you can switch by clicking on the other
application's menu.


It is VERY much like MultiFinder.. I just hope Apple does not become jealous;
Atari's implementation is faster :-) I can't wait until the release it..
especially a 68030 optimized version!


By the way.. I did not get a chance, but does it run non GEM applications in a
sizeable window? John?
 ------------
Category 14,  Topic 34
Message 4         Sun Mar 15, 1992
C.MACLEOD2 [Cam MacLeod]     at 16:31 EST

Well congratulations to Eric Smith. He hails from London, Ontario and actually
showed MiNT to the local users group last year (London Users of STs...LUST).

MiNt was impressive even last year.

 ------------
Category 14,  Topic 34
Message 5         Sun Mar 15, 1992
M.DORMAN2 [Mike Dorman]      at 16:33 EST

Oh, John.  Oh, John.  This is wonderful news.  I'm going to quiz you now...:-)

I assume that Allan (sp?) Pratt was knee-deep in the development, since he's
been sort of Eric Smith's co-conspirator.  Gee, is *that* why he gave Eric
patches to use with Lattice?

Any details about the structure?  (And just to make sure--this system does pre-
emptive multitasking of GEM apps, right?  Or is it strictly cooperative?  Does
it use something similar to Allan's MW2 for MiNT to allow multiple TOS
programs to run?)  At one time, people had talked about setting up sort of a
client-server sort of baby-XWindows sort of thing, and letting both processes
operate under MiNT.

Is that what's being done?

I really can't tell you how excited this news makes me.  I've lived with MiNT
off and on for the last 1.5 years, since v. 0.6, and I'm using 0.92 on a daily
basis, and it is *SOLID*.

Although, this does raise some questions as to how you're going to handle some
of the things MiNT has problems with, like the start-up code from older
compilers that doesn't support the "correct" argument passing standard, and
some of the other hacks that MiNT has had to implement to stay 99% compatible.
Personally, at this not-yet-released stage, I'll say this:

Make the stuff in the ROM's *pure*--no hacks, no garbage, just a damn solid
system.  And then, if possible, design RAM-patches that will make it more
compatible with old, non-standard stuff.  You're going to have to make some
changes that are going to break old stuff.  I, at least, accept and encourage
that, despite the fact that one of the compilers that I use on a daily basis,
Sozobon 1.33i, is going to break.  I think they way because I think it would
be a shame not to do it *right*, and make those changes count by making them a
totally solid basis for expansion.

But that's just my $.02.  Do good, and I'm looking forward to seeing it.

Mike.
 ------------
Category 14,  Topic 34
Message 6         Sun Mar 15, 1992
TOWNS [John@Atari]           at 20:22 EST

Thanks for the comments everyone. However.. I would like to hold off on
discussing specifics of the implimentation at this point. According to what I
know, the Multitasking TOS is still under development and is currently being
beta-tested with a group of extremely capable people. As you probably know,
when things are in the development stages, features and implimentation details
are subject to change.

-- John

 ------------
Category 14,  Topic 34
Message 16        Thu Mar 19, 1992
S.JOHNSON10 [Steve]          at 00:46 EST

TOWNS - Geesh!  Calm down.  I think everyone's aware that Atari's never
released a disk-based version of TOS (except the ORIGINAL TOS).  I believe Jim
was referring to (and joking about) when beta versions of TOS 2.xx and TOS
3.xx started showing up on some BBS's.  And I DO remember some of the Atari
folks online here saying not to use them because they were still buggy and
could mess up data on peoples' drives, not to mention the fact that it was
illegal!
 ------------
Category 14,  Topic 34
Message 22        Sat Mar 21, 1992
G.ANDERSON                   at 20:44 EST

Ah yes, but it does make for a nice change now and then <grin>.

Meanwhile, back on the subject...  How long before we can get some of the
specifics of MultiTOS?  IE: how many applications running at the same time,
selecting between applications (clicking on the window (if on the screen),
selecting from a dropdown menu on the desktop, switching between applications
that fill the available screen to others, performance losses per application
active, assigning priorities to CPU time per applications, handling of
application conflicts for system I/O, etc....

Since I'm running a T-16 right now (and hopefully a T-25 when it arrives) on
my Mega4 I'd be interested in MultiTOS when it becomes available (any 'wags'
on a date?).  I must admit that my goal, assuming I'm still employed when they
are released, is to upgrade to a new system in the rumored 'Falcon' series so
some practice with MultiTOS would be nice to have.

I'm curious though, how does MultiTOS/MiNt handle applications that grab ALL
system RAM/resources when they boot?  There are more of them like that out
there then there should be (Flash for example).

MultiTOS is a GREAT step forward for Atari, as much for 'bragging rights' in
advertising as for actual user capability.  It also indicates a change at
Atari itself.  For years it seemed Atari had a bad 'not invented here'
complex, ignoring or rejecting 3rd party developments in favor of 'in house'
programs and ideas.  By bringing MultiTOS online and basing it on a 3rd party
creation (with credits given to the original creator) Atari is showing us that
they've opened up a BUNCH and are looking at independent developers with new
respect and acceptance.  This is NOT to imply they've ever done otherwise mind
you, but now the message is much clearer and more public.

Good show guys, I'm tipping my hat to you again <grin>.

Gregg <Yokota AB, Japan>
 ------------
Category 14,  Topic 34
Message 24        Sun Mar 22, 1992
J.EIDSVOOG1 [CodeHead]       at 04:28 EST

Gregg,

Nice try <grin>, John T. says he can't talk about MultiTOS, the subject gets
diverted, and you slip back in an attempt to pull out some more info.  Pretty
sneaky.

Yes, there are a lot of programs that grab all of memory, and yes, MultiTOS
has a method to handle this.  Oops...already said too much.

John
 ------------
Category 14,  Topic 34
Message 25        Sun Mar 22, 1992
G.ANDERSON                   at 06:48 EST

John (E)....  I may be honest, but I never said I wasn't sneaky <grin>..

Still, the questions were reasonable ones I think.  I AM interested in
MultiTOS and hope to see it available before too much longer. I've a few
thoughts as to how it handles the 'bad' programs.. but admit that I lack the
programming talents to manage any details.

Still, it's a VERY positive step and one that says good things about what
Atari's doing these days.

Gregg <nasty but nice>
 ------------
Category 14,  Topic 34
Message 26        Sun Mar 22, 1992
WAYNED. [Wayne]              at 11:58 EST

Gregg,
  I too have a lot of questions about Multi-Tos. (doesn't everyone?) However
from what little has been said it sounds like they are still in the process of
defining the scope and limits so anything they (Atari) told you now might just
change in the final form for one of several reasons that I can think of right
away.  1) Memory constraints: It might take too much memory to implement a
'feature'. 2) Speed:  Said 'feature' might slow the OS down to an unacceptable
level.  3) Compatibility:  Adding a 'feature' might compromise compatibility
with the existing software/hardware base.

  While 3 isn't quite as important to me it does become important given the #
of developers no longer supporting old software either because they are out of
business, or no longer supporting Atari. Hopefully though with the new
machines rumoured, Multi-Tos, and some other glimmers of hope we'll see a
fresh infusion of new and returning developer support.  Of course that would
require significant #'s of machines being sold!

  So while like you I have a lot of questions I'm satisfied to wait and see
for a while.  I think it's time to go and get back into trying out MINT and
it's companion programs so I can get a taste of what's coming!
            Wayne

 ------------
Category 14,  Topic 34
Message 27        Sun Mar 22, 1992
M.ABDULKAREE [ASX]           at 13:55 EST

Using any kind of mutliple processing on the 68000 does manage to slow the
machine down.. you can fool around with this right now but simply opening up
all six DAs while doing your wordprocessing.. SNAIL!


And one note you should keep in mind is that not all applications will run,
notably the non GEM ones.. don't expect a miracle, there are none. I think
John Towns is good at expalining these things, he set me straight on them.


---


Hmm.. how about a feature that allows the user to use a picture for the
bacground instead of colors/patterns? This stuff is already there for X, OS/2,
and (bleakh) Windows.. just for those of use who have spare 150K lying
around.. <smile> Just a thought.
 ------------
Category 14,  Topic 34
Message 28        Sun Mar 22, 1992
M.DORMAN2 [Mike Dorman]      at 15:01 EST

Everyone--

I just uploaded MiNT 0.93 last night, and I'll try to get some other,
subsidiary programs up tonight--a port of tcsh (a PD c-shell clone), Eric R.
Smith's package of miscellaneous utilities, probably a MiNT-aware port of the
GNU BASH, some other stuff like that.  Heck, if people are interested enough,
I can upload the *source*.

MiNT is *definitely* worth working with if you like using a CLI--I've had *7*
different instances of Zoo running at once, unarchiving a bunch of files I got
off the Internet--and then I jumped into GNU Emacs.  The response was a
_little_ slow, but still usable.

I'm not affiliated with Eric Smith (though I'd like to be, so I could get
betas of the newest versions before anyone else...:-), I'm just someone who's
been using MiNT for the last year and a half, and almost constantly for the
last 6 months (I only boot up in GEM to use Aladdin and Uniterm--I need to
work on hacking a good vt100 emulator that'll handle 7-bit connections, and
then I'll only be in GEM to use Aladdin).

Oh, I'm just posting this here because of what Wayne said about wanting to
tinker--there's already a MiNT topic on the board (somewhere, unless it died),
so any requests and such should go there. I have Internet access, and though
I'm not always prompt, if there's stuff you want, I can usually get it.

Mike.
 ------------
Category 14,  Topic 34
Message 29        Sun Mar 22, 1992
REALM [Joey]                 at 15:33 EST

    ASX, Theres already a few Auto programs that display pictures in the
background.  I had one way back, I think I even got it off GEnie.:-)  It
loaded Degas and Neo if I remember right.
 ------------
Category 14,  Topic 34
Message 30        Mon Mar 23, 1992
TOWNS [John@Atari]           at 10:55 EST

I am sorry, folks. But I think we owe our developers the chance to prepare
their products for MultiTOS and to allow them to get their input heard before
we start to reveal details. As you are well aware, when a product is in the
testing stage, lots of things are still up in the air. To discuss details of
the implimentation would be premature at best.

- John

 ------------
Category 14,  Topic 34
Message 31        Mon Mar 23, 1992
J.NESS [Jim]                 at 20:14 EST

ACK!!

You mean, we have to make changes to our programs, in order for them to run
under MultiTOS?

ACK!!

                               -JN

 ------------
Category 14,  Topic 34
Message 32        Mon Mar 23, 1992
M.ABDULKAREE [ASX]           at 22:32 EST

Most of my GEM documentation kept reminding me that there would be a
multitasking version of GEM and not to use certain things.. well, seems like I
was prepared!


REALM: I wanted a picture on the TT medium (Degas only supports ST
resolutions.)
 ------------
Category 14,  Topic 34
Message 33        Tue Mar 24, 1992
S.NOAH [Stu]                 at 01:14 EST

Well, I wish everyone involved with the MultiTOS project the best of luck.  I
only hope that you do your idiot testing with some real live idiots... after
you have that accomplished maybe then the product will be ready for all the
rest of us.

                        ... enough self deprecating humour

Stu

 ------------
Category 14,  Topic 34
Message 34        Tue Mar 24, 1992
G.ANDERSON                   at 03:59 EST

Thanks guys... and good kudos to you John (T).  I agree that the developers
need a good, solid 'head start' on the MultiTOS....  I'm just tickled to death
(does anyone really talk like that anymore?) that MultiTOS is being
xDseveloped.  Since it's a software item a little 'advanced word' is both
welcomed and appriate <sp?>..  Thanks for letting us know it's being done..
and forgive us if we get a bit impatient now and then, but all of also have a
major investment in Atari & its products and want to see it become not only
great (already is) but everything it can be.

Gregg
 ------------
Category 14,  Topic 34
Message 35        Tue Mar 24, 1992
TOWNS [John@Atari]           at 13:38 EST

In most cases, GEM programs will run without any modifications at all. The
only kinds of programs that MultiTOS doesn't like are programs that take over
the screen (i.e. Dialogware!) and lock out other applications.

If you really want to make your programs (or future programs) work with
MultiTOS, just be sure to follow the rules, stay clear of dialogs that are
more than just call up, select something and go away, and try to use Windows
for your output. If you do this, you should be okay.

BTW.. If you are worried about Windows in MultiTOS, don't. Windows are
allocated dynamically, so you are only limited by your memory. If your machine
has the memory, you can open the window.

And to answer a couple of questions, MultiTOS can run as many GEM programs as
you have memory for. There is no limit. Of course, you have to realize that
for every application that you have running in the System, it is going to take
a piece of the available CPU time. So, realistically.. there is a limit to the
number of applications you can run (before your machine will slow down to a
crawl ;-)

Applications are switched by topping one of their windows or by selecting the
name of the application in the Desk Menu. Applications are listed below the
Desk Accessories.

Just a couple of answers for those of you out there. I don't mind answering
questions on this subject, just don't ask me stuff like "What happens to I/O
registers when you switch applications?, etc."

-- John


 ------------
Category 14,  Topic 34
Message 37        Tue Mar 24, 1992
D.MCNAMEE [Dan @ Atari]      at 14:43 EST

Jim,

        Only those that broke the rules so that their software won't work.

Dan

Stu,

        They already have.  They had me do some testing on it ;-)

Dan

 ------------
Category 14,  Topic 34
Message 38        Tue Mar 24, 1992
DENNYA [Denny Atkin]         at 16:22 EST

I'm curious about the comment that multitasking would "slow down" the ST if
you launched too many tasks. On the Amiga, at least, a task really on takes up
time if it's actually doing something. If it's just waiting for input, it
basically uses no processor time. Will GEM apps under MultiTOS work the same
way, or will they be "busy-waiting" when not actually calculating and thus
using up processor time?

(I find this whole thing rather amusing, since I remember the old Atari vs.
Amiga days when one of the Tramiels was claiming that multitasking slowed the
Amiga down, and was a bad thing. ;-)

 ------------
Category 14,  Topic 34
Message 39        Tue Mar 24, 1992
NEVIN-S                      at 18:32 EST

Towns, what happens to I/O registers when you switch applications? <grin>

Seriously, MultiTOS sounds great! I can't wait to put it on my TT.

--Nevin

 ------------
Category 14,  Topic 34
Message 40        Tue Mar 24, 1992
C.TOWNSLEY [CHARLIE]         at 19:42 EST

Heh heh.

Dan @ Atari and Stu, I have a feeling that this could turn into a version of
the "lightblub" jokes.

Q: How many idiots does it take to break Atari MultiTOS?

A: With or without the power turned on?

 Charlie Townsley
 ------------
Category 14,  Topic 34
Message 41        Tue Mar 24, 1992
REALM [Joey]                 at 19:49 EST

    ASX, Ohhhhhhhhhhh!:-)  It could still be done with a short Auto program,
maybe GIF, PNT or something?  Be nice to save the desktop as a GIF, remove all
icons and windows and save setup.  Then when someone else starts playing on it
none of the windows will work since it's just a picture of the desktop and not
the real thing.:-)
    When you have two programs running at once isn't the CPU speed cut in
half?  Seems like using several programs at once wouldn't be any more
productive then using one then the other.  If I have Prism Render running in
two windows doing two different frames wouldn't it take the same amount of
time as doing one frame then the other since the speed is cut in half?
    I've talked to several people who think Multitasking means the can run 4
or 5 programs at the same time and accomplish 4 times the work.  I think it's
a little misleading in that sense.  It's actually not much more then a
switcher that continues to run in the background should the CPU have time.
    I know theres a lot of positive aspects I just like to pick on the
negative.:-)  I look forward to it but I don't think it should be considered
the missing link or anything.:-)
 ------------
Category 14,  Topic 34
Message 42        Tue Mar 24, 1992
M.ABDULKAREE [ASX]           at 23:11 EST

Applications that are completly event driven work best in any multitasking
system. They get serviced when needed and perform their calculations when
needed. I think a combination of event servicing and time sharing is the best
way to go.


In short, if you write your applications to just sit there until the user
clicks somewhere, or your window needs a redraw, etc. and perform
calculations/operations at request then the speed degradation will be less.


For example, I (hypotehtically) write a graphing program. Initially I wait for
messages, open window, menu selections, etc. Most of the time I am not doing
anything so the OS does not need to worry about me. Now say the user wishes to
enter a new function to graph. Okay, put up a window and go into another even
management loop; wait until the user starts typing when the mouse in in my
window or I get messages.


I think this type of multitasking is called cooperative? Contrary to the
"blind" time sharing or prioritied schemes.. NOTE: I'm not saying which system
Atari has implemented but simply discussing how things are being done on other
platforms and currently under the limited multiprocessing under AES.

I could go on.. but this is basically how programs could be written: courteous
and yielding. No hogging of the timer or wind_update() stuff.

 ------------
Category 14,  Topic 34
Message 43        Tue Mar 24, 1992
T.MCCOMB [=Tom=]             at 23:20 EST

But Joey- you could have Prism Render busy rendering away in the background
while you type up a text file.  you wouldn't have to give up your computer for
hours(?) days(?) while it renders.  Of course this means the rendering would
take longer, but... theres always a trade off, ain't there!

                        -Tom

 ------------
Category 14,  Topic 34
Message 44        Wed Mar 25, 1992
S.NOAH [Stu]                 at 00:48 EST

Charlie,

The nice thing about the idiotic is we have all been there.  No one person has
a monopoly on it, and no one person is immune from it.

All@Dev@Atari,<..can ya tell I've been working with Vines a lot ?>

I am not much for playing computer games, but ...

A friend of mine has the Sublogic flight simulator, and I have noticed that it
does windowing, but these do not look like standard GEM windows.  It would be
really neat if this sort of stuff could be run from within a window...  Given
a fast enough machine, could this type of, graphics intensive, program be
written to operate from within a GEM window  ?

Stu
 ------------
Category 14,  Topic 34
Message 47        Wed Mar 25, 1992
REALM [Joey]                 at 20:05 EST

     Tom, Thats a given!:-)  I just think it's important users know when you
run several programs your not actually doing several times the amount of work.
I'm not complaining just being observant.:-) I'm all for multitasking, it
sounds like a great way to optimize your computer time and avoid dead lock
when rendering or other time consuming actions.  Actually, on a TT or Turbo 30
it would be like having 4 ST's in one spot.
     I was wondering about running applications in a window.  Would it be
possible to run ST High res programs on a 19" monitor?  How would the program
running view the resolution of a window?  Is that too specific a question?

 ------------
Category 14,  Topic 34
Message 48        Wed Mar 25, 1992
TOWNS [John@Atari]           at 20:51 EST

Denny.. I mean't applications that are doing something. MultiTOS is smart
enough that it will time slice to the applications that are doing things, and
applications that aren't doing things will get smaller slices.

I was speaking of applications that are doing things. What I should have said
was that "As you load applications that are constantly doing things (like
drawing to the screen), the system will get slower." For example, I have
several programs I run at the same time on my machine.. one is a clock (that
updates the screen once a second), one is a "lines" program in a window that
continuously draws line patterns in a window, etc. These programs will take up
CPU time.

BTW.. MultiTasking on a 68000 will slow down the machine. That hasn't changed.
You can't expect a computer that is handling several applications to run as
fast as a computer that is sitting there waiting to run one application. The
single tasking computer is usually going to be faster.

Joey.. not neccessarily. A program only takes up CPU time when it needs it.
It's doesn't get a 25% cut of the time or anything that definite. When it
needs to run, it gets some time to run. MiNT also has provisions for making a
process get less or more priority, similar to 'nice'ing a process under UNIX,
etc.

-- John



 ------------
Category 14,  Topic 34
Message 49        Thu Mar 26, 1992
J.ROY18 [Jonathan]           at 01:50 EST

Well, personally, I'm glad to hear about MultiTOS for the ST! I've used MiNT
alot (Did I upload one of the first versions? I don't remember..) up to about
.8 or so, but then my HD died, and I didn't get back into it... Maybe MiNT 1.0
is MultiTOS? (grin) I've always liked MiNT and felt it was very stable. Glad
to see it as Atari's choice! Also glad you can set priorities and such for
programs... (grin) Someone on Usenet said it wouldn't work on an ST, only a
TT, but then someone else said it was shown on an ST! (^= Anyways, enough
blathering for now. Is there any projected release date? (I'll just wait for
MultiTOS instead of TOS 2.06...)

Oh, by the way, will running ONE single program run the same speed as on an
older TOS? (Or does teh MultiTOS have some overhead?)
 ------------
Category 14,  Topic 34
Message 50        Thu Mar 26, 1992
J.ROY18 [Jonathan]           at 01:52 EST

Opps, forgot to ask. Will TOS programs run in a window?
 ------------
Category 14,  Topic 34
Message 51        Thu Mar 26, 1992
DENNYA [Denny Atkin]         at 11:44 EST

John,

Thanks for the clarification on how MultiTOS handles "waiting tasks." Sounds
pretty neat. I'll be anxious to try it out.

 ------------
Category 14,  Topic 34
Message 52        Thu Mar 26, 1992
TOWNS [John@Atari]           at 21:30 EST

Again.. there is no release date, no information on what platforms MultiTOS
will run on (i.e. TT only, or TT and STE/ST/Mega, etc.), or upgrade
information.

As for whether one program will run as fast under MultiTOS as it does under
normal TOS, I am just not sure. To me it appears to be close on my TT. But
then again, I am just going by look and feel.

As for TOS Programs, that has yet to be determined. There is talk of a
possible "console" window in TOS that would be were TOS programs are run. This
hasn't been nailed down yet. See what I mean about details?

-- John

 ------------
Category 14,  Topic 34
Message 53        Thu Mar 26, 1992
M.ABDULKAREE [ASX]           at 22:02 EST

..And that time slicing, etc. can be controlled via CPX right? :-) And while
your're at it, how about adding a function to change the NNN values for
CACHENNN and XXX values for FOLDRXXX? I know it is trivial to open up the
auto\ and rename them, but.. just a suggestion.
 ------------
Category 14,  Topic 34
Message 54        Thu Mar 26, 1992
R.GLOVER3 [Rob]              at 22:25 EST

Towns:

Be careful about using that term -- "look and feel" as I hear uttering those
words alone is enough to bring on the wrath of the Apple legal department! ;)


I know this is slightly off-topic, but can someone give me a brief hint on how
to get MiNT working?  When I downloaded it, it had no docs, other than to
state that you put MINT.PRG in the AUTO folder. By the way, is there a topic
for MiNT?  I don't recall seeing one...

Thanks!

Rob

 ------------
Category 14,  Topic 34
Message 55        Fri Mar 27, 1992
J.ROY18 [Jonathan]           at 00:25 EST

There used to be a MiNT topic. I think the older MiNT archives have all the
files and such, where .93 and so on are only the updated files.  (I'm not
sure.)
 ------------
Category 14,  Topic 34
Message 56        Fri Mar 27, 1992
R.GRANT11 [Ron @ GXRSYS]     at 01:40 EST

Towns, I'm amused yet horrified by your use of capitalization when speaking of
"Windows" in MultiTOS.

:-)

 ------------
Category 14,  Topic 34
Message 57        Fri Mar 27, 1992
TOWNS [John@Atari]           at 02:54 EST

Rob.. check out the MiNT topic in the Programming Category (I think!). I
believe it contains information on setting up MiNT and how to use it.

Ron.. <grin> Sorry. I will be sure to make it "windows" in the future. But,
remember, I didn't call them "win 3s" or anything. So, you're safe. <One
comment: I used Windows on a 386SX tonight. ugh. The think was soooo slow.
Amazing>

- John

 ------------
Category 14,  Topic 34
Message 58        Fri Mar 27, 1992
T.KAY3 [TKAY]                at 05:07 EST

John@...

Risking the wrath of the topic cops, I would like to ask a question on the use
of the term "Windows".   Granted, "window" is a generic term; however, when
used in conjunction with "computer", would we be infringing on MS/Windows
copyrights?  And excuse me if I'm wrong, but didn't we (in the Atari ST+
community) have windows before any other platform?

BTW..  glad to see so much activity between Atari and the users here on GEnie
and at Atari Corp.   Looks like we still have a very positive future if I read
between the line.

Tell me John, will my new Falcon be able to run Lotus, Excel, MS Word et. al.,
faster than a 386/40?  slap.. *^&$@ ! or faster than a 486? ..ouch..  bye.
 ------------
Category 14,  Topic 34
Message 59        Fri Mar 27, 1992
D.A.BRUMLEVE [kidprgs]       at 07:45 EST

 Actually, TK, the generic use of the term "windows" was commonplace
 before the development of MS Windows, so MS would be hard-pressed to
 protect that usage.

 I'm not a lawyer, but, as a member of the jury, I'd sure shoot down such
 a suit. ;-)
 ------------
Category 14,  Topic 34
Message 60        Fri Mar 27, 1992
SANDY.W [RT SysOp]           at 10:30 EST

The old MINT topic was archived. It is file #21122 in the Software Library.
There will be a MINT topic in Category 3 Topic 20 early tomorrow (Saturday)
morning. It is being moved from Category 2 due to space considerations.
 ------------
Category 14,  Topic 34
Message 61        Fri Mar 27, 1992
WAYNED. [Wayne]              at 19:49 EST

  Unfortunately many terms that are 'generic' have come to be synonymous with
the IBM arena.  Take the term PC for instance.  It means Personal Computer,
but whenever you say PC most people picture an IBM.(UGH!)  Now windows will
come to mean WINDOWS on the PC instead of being a generic term. (And NO we
didn't have windows first, for all intents and purposes Apple did)

  I'm about to download the new version of MINT (Mint is NOW Tos!) and some of
the companion programs and give it a whirl again.  I tried it a few versions
back and it showed promise but wasn't really practical at the time.  However
now that it is going to be a basis for the new Multi-Tos I want to get back up
to speed.

       Wayne (I think "P"iece of "C"rap when I picture an IBM)

 ------------
Category 14,  Topic 34
Message 62        Fri Mar 27, 1992
J.NESS [Jim]                 at 20:20 EST

John T. -

Well, there is always NBM v1.2, for testing the speed of MultiTOS.

You may not be free to tell us anything about the results, but at least YOU
would know.

Of course, since NBM itself is a screen-hogger dialog box, it probably is not
MultiTOS compliant...

                                -JN


 ------------
Category 14,  Topic 34
Message 63        Fri Mar 27, 1992
R.GLOVER3 [Rob]              at 20:36 EST

I finally got the new MiNT installed and running with Neodesk, but I don't
know what to do with it.  I'm a little peeved at it right now, as it's
partially responsible for toasting my Aladdin config file, so I had to
reconfigure from scratch.  Ugh.

Rob

 ------------
Category 14,  Topic 34
Message 64        Fri Mar 27, 1992
M.DORMAN2 [Mike Dorman]      at 21:08 EST

Rob--

The latest version of MiNT (0.93) us up, and it has docs and all. There is
also a new MiNT topic--I know, because I started it.  I guess I've sort of
crowned myself "MiNT Emperor of GEnie"--I use it regularly, and I have
Internet access, and I'm willing to keep thing up here updated, and offer
suggestions and tips to the best of my ability.

The topic is somewhere in CAT 2, I think.

Mike.
 ------------
Category 14,  Topic 34
Message 65        Sat Mar 28, 1992
S.JOHNSON10 [Steve]          at 01:18 EST

I don't know if anyone answered this when I asked it before, but will MultiTOS
be setup to handle multitasking of timing-critical MIDI applications?
 ------------
Category 14,  Topic 34
Message 66        Sat Mar 28, 1992
S.NOAH [Stu]                 at 02:07 EST

Why not just alow access to TOS programs through a gem/VT52 terminal program ?
Then you could set up a number of Terminal-Window/TOS sessions as you want.
 ------------
Category 14,  Topic 34
Message 67        Sat Mar 28, 1992
SANDY.W [RT SysOp]           at 16:39 EST

The MINT topic is in Category 3 Topic 20.
 ------------
Category 14,  Topic 34
Message 68        Sat Mar 28, 1992
TOWNS [John@Atari]           at 21:45 EST

Stu.. that is basically what the console window would be. Naturally, the
ability to have more than one console window at a time would be part of the
solution.

As for MIDI timing.. I don't know anything about that.

-- John

 ------------
Category 14,  Topic 34
Message 69        Sat Mar 28, 1992
R.GLOVER3 [Rob]              at 22:46 EST

Mike, Sandy:

Thanks... I did the topic update and I now get the new MiNT topic. Yes, I have
0.93.  I got it from atari.archive last week (much cheaper than getting it
from GEnie!).  I also got all the associated utilities (BASH, TCSH, etc).  Oh,
and I did find the docs afterall!

Now once I figure out what to do with it, I'll start using it again. The only
TOS-related programs I ever run are LHARC and occaisonally ARC or ZOO.

Now I'll shut up and move over that that topic. ;)

Rob

 ------------
Category 14,  Topic 34
Message 70        Sun Mar 29, 1992
S.JOHNSON10 [Steve]          at 00:01 EST

T.KAY3 - No, the Mac had windows first (as standard on a microcomputer).  One
interesting piece of info is that Microsoft tried to sell Windows (what they
had at the time) to Atari to use in the ST's OS instead of DRI's GEM, but
luckily Atari chose the latter.  Also, keep in mind that Apple's suing
Microsoft for some $4.5 billion for MS Windows infringing on THEIR
copyrights/patents. I'm also interested to see if we'll have some IBM
emulators for the Falcon machines (software AND hardware) that'll support
VGA/XGA/etc. color since that kind of video capability's already available in
the new machines' hardware.

--- End Topic Drift ---
 ------------
Category 14,  Topic 34
Message 71        Sun Mar 29, 1992
JLS [John STanley]           at 02:08 EST

TOWNS,

  This is sounding more and more fantastic the more I hear...

  How well does MultiTOS work with any of the dozens of exitsting system
enhancement programs (various vector stealers and resident goodies)?  Any tips
on what's (TSR programming-wise) legal or semi-legal under TOS that we won't
be able to do under MTOS?

 >... There is talk of a possible "console" window in TOS that would be
 >were TOS programs are run. ...

  Three things:

    Please don't limit this to _a_ (singular) window.  The programs I use most
of the time are TOS/TTP programs and limiting me to only running one at a time
would drasticaly limit the utility of the new system.

    Please allow for a method any shell program can use to "launch" new (tos
or prg) processes in seperate windows and allow icon'ing the window/tasks
(under program or manual control) when we don't need to see the process for a
while.

    For tos/ttp programs running in a window, please have some method we can
use to alias and update window-specific copies of the aline variable block
(positive and negative offsets) (or some other non-GEM method) so programs
that pay attention can sense the true window size (or some virtual-screen
scrollable window size) and adapt themselves where appropriate.  (This may be
something you'd want to control with one of the unused program flags...)  I
know that on windows where this is used, this would take some extra memory per-
task, but I've seen and written several programs that adapt to any screen size
based on the "still-supported" aline vars and it would be a real shame if
there was no way to allow them to easily sense and adapt to running in a
window.

    Is the system pointer "run" used-by/maintained-by MTOS?

  Keep up the great work,
                      ... JLS
 ------------
Category 14,  Topic 34
Message 72        Sun Mar 29, 1992
B.KANTOR [CadMan]            at 04:32 EST

John Towns,

Does/will Multi-TOS have resource locking capabilites.  By this I mean, can an
application open a file for exclusive access or lock hardware so that no other
application can use it?  Will it contain a built in print spooler so that
multiple applications can print at the same time?

I know nothing about MINT, so I apoligize if these are obviuos features of
Multi-TOS.

               Bruce M. Kantor

 ------------
Category 14,  Topic 34
Message 73        Sun Mar 29, 1992
S.NOAH [Stu]                 at 04:40 EST

Just a thought...   Support for the standard clipboard really takes on an
entire new meaning when viewed in the light of a Multitasking version of TOS.


Stu
 ------------
Category 14,  Topic 34
Message 74        Sun Mar 29, 1992
A.VALENT [Mike]              at 09:17 EST

John Stanley - One of you programmers really should come up with some sort of
a GEM window shell for TOS/TTP programs to run in. For that matter, a
resolution-independent shell in which hard-coded ST Medium/High res programs
would run on the Moniterm, TTM194, and in TT Medium would really be useful.
I've read that the Overscan programmers have done one that sets up a 640x400
window on a MOniterm or TTM, and Jim Allen has told me of a German program
that will display 640x400 on a 1280x960 monitor with each pixel x 4.

Nice if Multiple TOS/TTP support comes built into multitasking TOS, but if not
it would appear to be possible to get it with such a shell program.
 ------------
Category 14,  Topic 34
Message 75        Sun Mar 29, 1992
J.ROY18 [Jonathan]           at 11:48 EST

Well, MiNT already runs loads of TOS/TTP programs at once, so I don't see why
they would remove that ability...
 ------------
Category 14,  Topic 34
Message 76        Sun Mar 29, 1992
D.FLORY [ALERTsys*Cop]       at 14:58 EST

Steve, actually I saw windows on the Xerox Star years before the Mac. I think
Mac licensed it from Xerox, originally. In any case Mac is the one that
popularized it by offering the windows environment on a popular (read less
than $10,000[and $10k then was more like $20k nov]) computer.
 ------------
Category 14,  Topic 34
Message 77        Sun Mar 29, 1992
M.ABDULKAREE [ASX]           at 15:50 EST

Yep, the WIMPy interface was developed at Xerox PARC but when Apple and DRI
started coming up (wee early days) they did not do anything.. until Apple
started making lotsa money! And started suing others.


Incidentally, Apple licensed the Mac from some place called Mac Labs. Hmm..


Heh heh heh.. John is really being inundated with queries. If we're not
careful, he might stop answering in this topic.
 ------------
Category 14,  Topic 34
Message 78        Sun Mar 29, 1992
TOWNS [John@Atari]           at 16:48 EST

Steve.. if I remember right.. Microsoft Windows didn't even exist in late
1984. I have never heard this statement until you mentioned it. I would be
interested to know where you got that one.

John.. TSRs are loaded before MiNT. Currently, MiNT is the last thing in your
AUTO Folder. Whether or not it will be put into ROM, I have no idea. But,
currently you can have TSRs load before MiNT.

As for Legal vs. Illegal.. please see the previous messages in this topic. One
new thing in TOS that might cause some problems.. You can now move background
windows, and basically use any gadget on a background window. Remember, always
go thru your rectangle list for Redraws. Never assume that there is nothing on
top of you.

Another thing.. Dialogware is bad as well. Most Dialogs will lock the screen.
This will prevent you from switching to another Application until you make the
Dialog go away. Try to use Windows for your output whenever possible. Dialogs
are okay, as long as you use them to Select something and then they go away.
They shouldn't be the primary display for your application.

As for your comments on console windows, please see my previous comments in
this topic. We have not limited the number of TOS programs you can run. MiNT
has this capability and we haven't removed it.

As for processes ability to launch applications, We are trying to "distance"
the Desktop from the AES so that you can install a different shell. I think
this will solve the problem.

Your other comments should be addressed in the Developer's Area at the
appropriate time.

Bruce.. I am not sure. As I said, a number of things are still up in the air.



 ------------
Category 14,  Topic 34
Message 79        Sun Mar 29, 1992
R.DEAN3 [GUNNER]             at 18:12 EST

Will Multitos take advantages of the 68030 chip???  Looks like a great
addition to any of the 68030 accellerators!!!

Gunner
 ------------
Category 14,  Topic 34
Message 80        Sun Mar 29, 1992
M.DORMAN2 [Mike Dorman]      at 19:02 EST

Mike Valent (Just to distinguish you from the other Mikes)

Well, there is a program under MiNT that will let you run multiple
shells/programs in multiple console windows.  Allan Pratt wrote it...

I can get it up here, and help you set it up, if you'd like...

Mike.

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

John--

I, too, have heard the rumor about Windows, and also heard that they couldn't
deliver it in time, and that's why we ended up with GEM (which is a nicer OS,
*still*, IMHO).

Mike. <Who supports Windows on a NetWare LAN at his day job, and hates it,
even if Word for Windows is pretty darn spiffy>
 ------------
Category 14,  Topic 34
Message 81        Sun Mar 29, 1992
OUTRIDER [Terry @ T2]        at 19:47 EST

     What ever happened to MidiTasking or whatever it was called?

                                  - Terry -

 ------------
Category 14,  Topic 34
Message 82        Sun Mar 29, 1992
M.DORMAN2 [Mike Dorman]      at 22:54 EST

Outrider--

It died a kludge's death?

Mike.
 ------------
Category 14,  Topic 34
Message 83        Mon Mar 30, 1992
DENNYA [Denny Atkin]         at 16:18 EST

Towns,

A pre-alpha Windows was shown publically at the NCC (National Computer
Conference, used to be the big computer show before Comdex killed it) show in
Anaheim, CA in summer of 1983. Before the Mac was even announced.

 ------------
Category 14,  Topic 34
Message 84        Mon Mar 30, 1992
A.VALENT [Mike]              at 19:43 EST

Thanks, Mike (Dorman). I had an older version of MiNT on my hd for a while but
but didn't do anything beyond playing around with it. Was fun to load my
Moniterm screen with 5 or 6 windows drawing those string art demos... that's
about my level of sophistication. :-)

Whatever the Mint shell was that I also downloaded, it sure had a lovely
opening screen.

Back in the early Tramiel Atari days, one or more of the mags published
speculation that Microsoft wouldn't do any ST programming because they'd tried
to sell Jack on using Windows for the ST's OS shell, and "were upset" that the
ST went with GEM instead.

John, Windows was featured (Along with GEM and the ST and the Amiga) in an
announced but not yet released item section in The Whole Earth Software
Catalogue. That was published in 1985, suggesting that the story may have been
possible.
 ------------
Category 14,  Topic 34
Message 85        Tue Mar 31, 1992
REALM [Joey]                 at 00:29 EST

    I've got Microsoft Write and I'm glad Microsoft 'isn't' programing for the
ST.:-)
 ------------
Category 14,  Topic 34
Message 86        Tue Mar 31, 1992
S.JOHNSON10 [Steve]          at 00:39 EST

D.FLORY - I said (or at least THOUGHT I did) that the Mac was the first
personal computer to be window-based.  Apple didn't license it from Xerox, but
Xerox sorta told Apple that they had no use for the windowing system and that
they were welcome to 'borrow' it.  Mind you, that changed several years later
when Apple was making tons of money with the Mac and Xerox tried to sue.
<grin>


TOWNS - I'd heard from several places that when the ST's OS was in the
'planning stages' that both Microsoft and DRI were trying to 'sell' a
windowing system to Atari.


OUTRIDER - MIDI-Tasking died due to lack of interest from developers, although
Bob Brodie said that multitasking for MIDI applications is still being worked
on by Atari, which is why I asked if MultiTOS was 'set up' to handle MIDI
applications.
 ------------
Category 14,  Topic 34
Message 87        Tue Mar 31, 1992
J.EIDSVOOG1 [CodeHead]       at 11:33 EST

Steve,

MIDI tasking did not die from lack of developer interest, it died because it
was headed in the wrong direction and wasn't feasible.

John
 ------------
Category 14,  Topic 34
Message 88        Tue Mar 31, 1992
D.FLORY [ALERTsys*Cop]       at 19:05 EST

Sorry, Steve, I think you're right, the Star really wasn't a _personal_
computer. Not at those prices and it had a pretty big box that sat on the
floor. Not what we generally think of as a personal computer.
 ------------
Category 14,  Topic 34
Message 89        Wed Apr 01, 1992
S.SCHAPER [Meneldil]         at 02:23 EST

Huh? The personal computer Danny Dunn used, the Miniac, was pretty big.


And I've got a friend in Mound that has as his goal a VAX in his house. He
figures that he's got room for that _and_ the dogs. . .
 ------------
Category 14,  Topic 34
Message 90        Thu Apr 02, 1992
S.JOHNSON10 [Steve]          at 02:41 EST

J.EIDSVOOG1 - I THOUGHT Bob Brodie said that they couldn't get developers
together to 'discuss' it and that certain developers were more interested in
using their current systems (MROS and Dr.T's MPE, although the latter isn't
multitasking) rather than adopt MIDI-Tasking?
 ------------
Category 14,  Topic 34
Message 91        Thu Apr 02, 1992
TOWNS [John@Atari]           at 16:29 EST

The point is that it is no longer being pursued.

-- John

 ------------
Category 14,  Topic 34
Message 92        Thu Apr 02, 1992
J.ROY18 [Jonathan]           at 20:03 EST

Will MultiTOS be able to write to the drive, and such, without freezing the
rest of the system? (The amiga can write to the disk in the background, can't
it?)
 ------------
Category 14,  Topic 34
Message 93        Thu Apr 02, 1992
J.EIDSVOOG1 [CodeHead]       at 21:27 EST

Steve,

Perhaps we're both right.  I believe that developers lacked interest in
MIDItasking because the proposed plan was not feasible.  I just don't want to
see developers blamed for the demise of MIDI-Tasking by stating that it was
dropped for lack of interest by developers. Something must be useful in order
to entice people to use it.  I believe that MultiTOS will fill this bill and
am happy about it.

John
 ------------
Category 14,  Topic 34
Message 94        Sat Apr 04, 1992
A.FASOLDT [Al Fasoldt]       at 00:33 EST

Jonathan,

STalker already writes to the disk in the background when you run it as a DA
on the ST, so your answer is certainly "yes" regarding MultiTOS.

Al

 ------------
Category 14,  Topic 34
Message 95        Sat Apr 04, 1992
J.ROY18 [Jonathan]           at 14:19 EST

No, it doesn't. (At least not on my computer.) Whenever STalker accesses the
drive (most noticeable on a floppy) the entire computer freezes.  NOTHING
continue while the floppy is being written to. I know. (^=  I have a 4K file
buffer, and I get little 1-2 seconds delays every time it fills.

Could you (with MT) write two floppy drives, and a HD, and a RAM disk, all at
once? I've also heard that SCSI controller have some sort of built in
mechinism for handleing multiple read/write commands at once... I hope
MultiTOS exploits it. (^=
 ------------
Category 14,  Topic 34
Message 96        Sat Apr 04, 1992
R.GLOVER3 [Rob]              at 21:44 EST

  Will MultiTOS handle multitasking as well as the Amiga?  I have to ask this,
because I was at a friend's house today, and he has an Amiga.  It's a stock
(processor-wise) Amiga 2000 with 5 meg of RAM, a new SCSI card (two ports), a
flicker fixer and a Sony 1304HG monitor. He runs a BBS on this system, and two
users were logged on.  He was also showing me a graphic animation, and playing
a MOD file.  And all with the 7.16 MHz 68000.  Very impressive to say the
least.

My point is, can MultiTOS do that????

Rob


 ------------
Category 14,  Topic 34
Message 97        Sun Apr 05, 1992
J.ROY18 [Jonathan]           at 00:06 EST

Well, I can already run a MOD file in the background.. (grin)
 ------------
Category 14,  Topic 34
Message 98        Sun Apr 05, 1992
R.GLOVER3 [Rob]              at 14:21 EDT

J.ROY18:

How do you manage that?

Rob

 ------------
Category 14,  Topic 34
Message 99        Sun Apr 05, 1992
J.ROY18 [Jonathan]           at 21:31 EDT

Just use Jukebox. The next version 1.2 (which I'm testing) adds a shuffle
ability, and a resumption of suspended mods..
 ------------
Category 14,  Topic 34
Message 100       Mon Apr 06, 1992
C.MACLEOD2 [Cam MacLeod]     at 00:00 EDT

I played with MultiTOS at the ACE show this weekend and was IMPRESSED. It
works and works well. It was running on a TT and although there weren't tons
of apps on it it did work and looked nice.

Apparently it should be available in 1992 but the decision hasn't been made
whether to offer it as an upgrade to 68000 machines. I imagine that it will be
offered as an upgrade if not standard on these machines.

Atari seems to have gotten its act together and is now pulling in the same
direction. A welcome change to be sure.

 ------------
Category 14,  Topic 34
Message 102       Mon Apr 06, 1992
M.ABDULKAREE [ASX]           at 21:40 EDT

Hmm.. I think you can check a similiar situation by loading the BBS under MiNT
and running the desktop. Next, start the DMA stereo MOD file and after
returning to the desktop, start the graphic animation (sans DMA sound.)


I don't have MiNT or an STE with HD (just a TT waiting for multitasking AES)
so someone else will have to do it.
 ------------
Category 14,  Topic 34
Message 103       Mon Apr 06, 1992
C.TOWNSLEY [CHARLIE]         at 23:26 EDT

Well, I saw MultiTOS at the Atari booth at ACE and was very impressed. I
missed Bill's talk on it, unfortunatly, had to get back to work at the booth.

I am very much lookng forward to it's delivery.

 Charlie Townsley

 ------------
Category 14,  Topic 34
Message 104       Tue Apr 07, 1992
J.ROY18 [Jonathan]           at 02:21 EDT

It's better be availible for use 68000 people. (grin) I won't be able to
afford a TT for some time..
 ------------
Category 14,  Topic 34
Message 106       Tue Apr 07, 1992
G.ANDERSON                   at 07:27 EDT

I echo the '68000' release for MultiTOS....  Why?  Because there are a LOT of
us out here with 16, 20, and 25 Mhz 68000s and 68030 boards that could benifit
from having it.  Granted that it might suffer an Amiga-like slow down on an
8Mhz 68000 and 'might' suffer from compatibility problems with some
programs.... but a simple disclaimer and a LOT of public comments on it should
help there. I plan on upgrading my Mega4 too, but it will have to wait a
little while until I can get my pennies stacked high enough <grin>.  But until
then I'd like to try my luck with MultiTOS....

If it were released to current ST owners, would it be as a software-based
patch or would we have to swap ROMs?  I know, no decisions have been  reached
yet but could you tell us which way the wind is blowing without getting into
trouble?

Gregg
 ------------
Category 14,  Topic 34
Message 107       Tue Apr 07, 1992
TOWNS [John@Atari]           at 17:51 EDT

The method of distribution for MultiTOS has not been determined as of yet. We
will have to wait and see what happens!

-- John

 ------------
Category 14,  Topic 34
Message 112       Wed Apr 08, 1992
F.BELL1 [Frank @ Home]       at 15:29 EDT

If my voice means anything, the dogs around my house don't think so, then I
too am for a 68000/T16/T20/T25 MultiTos.  But I understand if it made
available on the Falcon or the TTs only - remember guys, good Memory
Management is a must for any multi processing system and those 68000s just
don't have it.

Frank...

P.S.  all the TOS 2.06 conversion board manufactures that I know of, said they
will support MultiTos ROMs if at all possible.


 ------------
Category 14,  Topic 34
Message 114       Thu Apr 09, 1992
OUTRIDER [Terry @ T2]        at 06:26 EDT

Frank @ Home,

     I can appreciate your statement about good memory management being
important for multi processing, but I still think it should be made available
for 68000 users and let the buyer beware.  I don't like being told I HAVE to
wear a seatbelt.  ;^)

                                  - Terry -

 ------------
Category 14,  Topic 34
Message 116       Sat Apr 11, 1992
J.ALLEN27 [FAST TECH]        at 15:25 EDT

Nothing like the "LINES.PRG" running on an ISAC under MultiTos to make an
impression on people. A couple Lines, and couple Boinks, and the desktop.
Nieat!
 ------------
Category 14,  Topic 34
Message 117       Thu Apr 16, 1992
M.ABDULKAREE [ASX]           at 21:33 EDT

I have been pondering over this scenario since I started writing my custom
Editable field handler; driven by evnt_multi().


I suspect that this problem has been attended to, but as a "things to make
others think about" I present it.


Okay, assume that you have two desk accessories in the background doing status
updates and you are in your application busily doing things, clicking, typing,
etc.


If the two DAs use AES object routines for their output (or their own routines
but do not check for mouse bounds) then everytime they draw something to the
screen, you get a mouse flicker. An example is Aladdin's text editor, and my
dummy DA which puts up a window and just draws numbers via objc_draw() every
two seconds; I purposely do not check for mouse bounds for any thing. If I had
two copies of my DA installed, there is a very good chance that I will
experience difficulty and irritation using the mouse due to the flicker
frequecy.


The problem is that the current AES drawing routines do not check for mouse
bounds. Think what would happen if on a multitasking system with the user
having started several tasks which are now busy doing their work and
displaying stuff (which is not a bad idea.) FLICKER HELL!


Would YOU like it? I seriously doubt it. So please consider your users and
think open.


Checking whether the mouse is in bounds or not maybe code consuming, but you
do realize space and user-interface pay offs in the long run. VDI calls do not
check for mouse bounds and neither do they hide/show it during operations: the
program must handle this. I do, and check for the bounds.


Now if the AES's functions are updated to check for this, then you probably
would add a general function to be called everytime you need to check.


WORD m_inregion(WORD rect[]);


Where rect contains the coordinates of the area to be re/drawn in standard AES
x, y, w, h form. And the function would return 0x01 if the mouse in within the
region or 0x0 otherwise.


The reason for adding this function is to perform check at the interrupt
level, right after the mouse has been moved. This will effectively eliminate
the LOW possibility of the mouse moving into the bounding region after passing
the outside test:


rect[]= { x, y, w, h }

evnt_multi(..&mx, &my..)

.

..  Perhaps a call to a function-- chance for delay.

.

if ( (mx>rect[0]) OR (mx<rect[0]+rect[2]) ..same for y coord )

 { hide mouse and draw.. }

else

 { don't bother hiding mouse, just draw! }

.

.


I have tested my simple checking routine before calling v_gtext and was unable
to cause the mouse to be overwritten, i.e., my check was successful!


What do you all think?



------


One more thing: Is it recommended that we use any of the low level "direct
i/o" in our programs or use evnt_keybd() to obtain input? Basically, how are
the low level input or keyboard input handled in the multitasking system? Will
programs have data overflow if the used raw "curses.h"-type i/o or do you have
some exceptions to this?


Thanks.. for reading this long message!
 ------------
Category 14,  Topic 34
Message 118       Fri Apr 17, 1992
DOUG.W [ICD RT]              at 07:46 EDT

ASX,
   Using your bounds checking technique can cause problems...  What happens if
the mouse is outside of the region when the redraw occurs, but the user moves
the mouse into the regions DURING the redraw?

--Doug

 ------------
Category 14,  Topic 34
Message 119       Sat Apr 18, 1992
M.ABDULKAREE [ASX]           at 00:38 EDT

You are correct and I am aware of the problem, however, that does not happen
often and when it does it can be cleaned up easily. But you can't fix the
flickering problem! You could write a VBL triggered draw routine which would
draw the mouse at the ending of VBL, or like the Mac does.


I consider the remote chances of the mouse invading the redraw region a remote
possibility. Given the alternative: mad flickering, I would take the chance.


Moreover, as I suggested, if Atari added an AES function which will return
TRUE if the mouse is within bounds, then putting that function in your redraw
function right after get_next_rect_list() will eliminate the possibility of
mouse droppings.


The current solution to the problem is to add some statistically sound
buffer/margin to the mx,my so that you decrease the chances.
 ------------
Category 14,  Topic 34
Message 120       Sat Apr 18, 1992
DITEK [David]                at 02:40 EDT

ASX -- Even adding a bounds intersecting routine would not work since the
mouse could still move before you are finished drawing. I had to write
functions to handle this not too long ago and the remote possibility you spoke
of isn't nearly as remote as you'd think. Mouse droppings were pretty
regular... :-)

The addition of a 'chicken factor' only decreases the chances. With people
using mouse accelerators, I still got droppings. The only way I could ever get
it to work reliably was...

1 - Grab the GEM mouse movement vector

Whenever graphics had to be drawn ( VDI or otherwise )..

2 - Lock the mouse
 3 - Test for bounds intersection and hide the mouse if re'qd
 4 - Draw the graphics
 5 - Unlock the mouse

While there are probably better ways, this method was GEM compliant and
resulted in no visible slow down in the redraw functions.



 ------------
Category 14,  Topic 34
Message 121       Sat Apr 18, 1992
CHERRY.FONTS [Todd]          at 09:31 EDT

David (Ditek),
  By "lock the mouse", do you mean in effect to nail it to its spot while
drawing the graphic? How compliant would that be to MultiTOS? (Or did I
misunderstand?)

..Todd


 ------------
Category 14,  Topic 34
Message 122       Sat Apr 18, 1992
DITEK [David]                at 21:44 EDT

Todd (Cherry.Fonts)
 Yes, it means you zero out any movement that occurs during your drawing. By
treating each individual graphic ( i.e point, line, etc.. ) for testing rather
than attempting to draw a large block of graphics, ( one of the first mistakes
I made ) the mouse continues to be move smoothly.

Since it uses only GEM calls and doesn't affect any other programs why would
this method be 'non-compliant' ?

The absolute best solution of course would be for Atari to implement a low
level algorithm that would be transparent to all applications... ( I can dream
)

 ------------
Category 14,  Topic 34
Message 123       Sun Apr 19, 1992
M.ABDULKAREE [ASX]           at 16:17 EDT

Thanks David.. now I have to look up what the mouse movement vector
means<smile>. Steps 2 through 5 I can do.

2. event_update(mcntrl)

3. intersect()

4. vro_cpyfm()

5. event_mouse(endctrl)


Now do you mean that I should call vex_curv() or vex_motv() and do something
then?


Well.. I guess you are right about mouse trails <sigh> I was drawing a small
area so the chances were slim, but if I had several rectangles to redraw then
I can see how the mouse could very well move inside!


And Todd brought up my next concern.. if I locked the mouse, then the user
will not be able to complete what s/he was doing, for example moving a window
elsewhere while our program's window (background) was asked to redraw.


Sheesh.. it is getting messy awfully fast! That is exactly why I wanted a VBL
driven draw routine under AES/VDI! Makes life sooo much easier for both the
programmers and the user.


Well David, if we all "suggested" to Atari, then there may well be such a
routine! <pinch>
 ------------
Category 14,  Topic 34
Message 124       Tue Apr 21, 1992
JWC-OEO [Jon]                at 21:14 EDT

  Since I've seen the comments here about so called "dialogware" being less
than fully compatible with MultiTOS I've been keeping an eye out for it.
Well, I've got lots and lots of it.  It's likely that the vast majority of the
utilities that I might want to multitask under MultiTOS are dialogware.  While
I certainly would not want Atari to cripple MultiTOS in the attempt, I'd like
to urge them to find a way to get MulitTOS to deal with this type of program.
Maybe programs that don't open a window but are not really TOS programs could
be banished to a screen that would only show up when the user switched to it.
That would let them run and tie up their own screen waiting for input but
would keep the properly written GEM window programs free to do their stuff on
the "main" screen.  I don't know how feasable this is but I do think that
without something like this, MultiTOS is not going to be satisfactory as a
general use everyday operating system on many peoples systems.

Jon

 ------------
Category 14,  Topic 34
Message 125       Wed Apr 22, 1992
TOWNS [John@Atari]           at 14:36 EDT

Dialogware will work as long as they lock the screen using a wind_update call
before they bring up their Dialog and after the get rid of the Dialog.

Please note.. While this happens, you can't switch applications.. but your
Dialogware program will work just fine.

-- John Townsend, Atari Corp.

 ------------
Category 14,  Topic 34
Message 126       Wed Apr 22, 1992
J.ROY18 [Jonathan]           at 18:18 EDT

I'd like to see Dialogs pop up as they do now (ie: the come up no matter what)
but if they aren't responded to in say, a user-defineablt number of seconds,
the dialog will disappear. Then, when that program's window is topped, the
dialog will reappear. This would keep your computer running along fine even if
you went out the room and a dialog poped up. (Perhaps the window's could have
a dialog-flag somewhere.)

Also, since MultiTOS is being shown at shows now, could you load in a number
of programs, and snap-shot the screen in Degas format, then upload it for us
little people to drool over? I'd like to see some GEM programs loaded under
the ACC slot (With it's drop-down menu open, so we can see how they are
listed) and of course, some programs on the desktop. Maybe Calamus, Avant
Vector, and Didot Pro all running at once? (grin) Throw in a TOS program for
good measure.


Will MT use the same method (and same calls) for pipelining informatiom from
one process to another? (ie: Can I write MultiTOS friendly software before it
comes out by writing it for MiNT?)

--

More importantly, can a program "spawn" tasks that will automaticly be
multitasked by the OS? (Even open their own window perhaps) That'd be a _very_
cool feature... I'm pretty sure the Amiga OS does it, so I know someone must
have considered adding it. This could let WP's spawn a printing-child when you
print, so you don't need DA's or printer buffers. You just pass it to your
child-task, and it goes about it's merry way. Calamus and such could be really
cool like this. You hit "print" and it makes a child-task to do all the
printing functions, whereas Calamus itself is still totally usable. Hmmm...


(The above is Aladdin delayed a day, the following is new:)

If you have a dialog pop up, won't that suspend any GEM updating? (So, if you
have multiple windows open, all those processes will be suspended? What about
closed windows?)
 ------------
Category 14,  Topic 34
Message 127       Wed Apr 22, 1992
M.ABDULKAREE [ASX]           at 21:30 EDT

"Dialogware" or basically forms are NOT incompatible with AES or multitasking
TOS. John (and Bill R.) said that because if you put one up, say like
Aladdin's file Xfer dialog, then the user won't be able to do anything with
other applications (they may continue running in the background but all
drawing and menus will be halted.)


So.. the best thing is to put them up in a window, add a little more code to
your program and make the users happy! Otherwise you are taking away the
entire concept of multitasking (speaking generally.)


One advice would be to think as if you are the user and would like to be able
to get at other things as well. That is the way I see it..


There are of course cases where mouse locking is good: file/HD utilites, they
are sensitive applications and should not be disturbed. But I guess with a
little bit of modifications to GEMDOS, that consition can be removed.. I
guess.


And I don't think it is Atari's fault if you find that it won't be "worth it".
You can create the same situation under MacOS and Windows 3.. that is
something that the OS cannot circumvent.. in fact, like I pointed out there
are cases when the applicaiton needs to lock everything up.
 ------------
Category 14,  Topic 34
Message 128       Wed Apr 22, 1992
J.NESS [Jim]                 at 22:56 EDT

John Townsend -

Thanks for the additional info on how to handle dialogs in MultiTOS. Those of
us who are amateurs and don't have NDA access to info need SOME clue about
what changes may be necessary in our programs.

Anything you feel comfortable telling us, technique-wise, will be appreciated.

                                    -JN
 ------------
Category 14,  Topic 34
Message 129       Thu Apr 23, 1992
JWC-OEO [Jon]                at 00:04 EDT

  TOWNS,
  Thanks for the replay.  Too bad though.  So called dialogware formes a large
rich subset of ST utilities and other applications and while I'll do my best
to bring my own contributions to this field into line, I'm not going to hold
my breath waiting for an onslaught of updates from other sources.  Feel free
to come up with a better solution at the last minute.

Jon
 ------------
Category 14,  Topic 34
Message 130       Thu Apr 23, 1992
DOUG.W [ICD RT]              at 07:55 EDT

Atari really needs to follow that path that Microsoft (Windows), Apple (System
7.0) and Commodore (Intuition) have created for handling modal dialogs.  Under
these GUIs, standard modal dialogs are only application-modal and not system-
modal.  While the modal dialog is on the screen, you can't do anything else
with that application, but you can still switch to other applications.

--Doug

 ------------
Category 14,  Topic 34
Message 132       Thu Apr 23, 1992
M.STUEVE [Marlo]             at 22:28 EDT

 Any way this works, lots of applications are going to be screwed up.
 Some applications save the dialog background as a raster. If anything
 happens in background applications in the meantime, the redraw will
 produce garbage. This may also be a problem with alert boxes, I don't
 know. (Not to mention menus.)

 I'd also like to know how conflicts over the desk window (handle 0)
 are going to be resolved. The best thing I can think of is for the
 desktop to put up and manage a fully-functional window for each
 application using window 0, and redirect all accesses to window 0
 into the new window. I don't like the Multi-GEM approach of having to
 select the program from the Desk menu in order to access the
 background. As a bonus, the desktop could put the program's menu bar
 in the info bar at the top of the window (ala Stalker and Steno). I
 know this is a lot to ask, but how hard could it possibly be?


 On a side note,
 Does anyone know what happened to the idea that we users were going
 to be able to ask Leonard Tramiel all sorts of questions, and his
 answers were going to be posted in Cat 14 Top 25? I sent him a whole
 bunch of Multi-TOS questions, and am hoping to get some answers. I'd
 also like to hear what everyone else asked.

 Marlo Stueve
 5th Crusade Software

 ------------
Category 14,  Topic 34
Message 133       Thu Apr 23, 1992
JEFF.W [ST Sysop]            at 23:14 EDT

Marlo,

I'm working with Atari to get the Leonard answers posted to Topic 25. I guess
with all the work and excitement going on at Atari, the answers had to take a
back seat for a while, but I understand they are almost ready, so we should
start seeing them soon.  I hope.  <smile>

Jeff

 ------------
Category 14,  Topic 34
Message 134       Fri Apr 24, 1992
JLS [John STanley]           at 03:10 EDT

  Towns,

  Has any thought been done about the possibility of modifying the wind_update
dialog-framing calls, form_draw, and form_do calls to force dialogs into a
window so dialogware would not lock out task swaping under multi-tos?  It
looks like this could easily be a major bottleneck to ease-of-use using older
(can't get upgrades anymore) software and it would seem to me that modifying
the system form_do to run dialogs in windows would be more practical than
trying to get everyone to re-invent the wheel for every program.

   ... JLS

 ------------
Category 14,  Topic 34
Message 137       Fri Apr 24, 1992
M.ABDULKAREE [ASX]           at 21:33 EDT

This is ticking me off.. I spent time reading my (meager) documentation trying
my very best to make software compatible with future versions. This includes
thinking about diablogs, windows, and line As. I started this even before
there was any leaks or etc. on MultiTOS!


I personally would not care if the older software expreienced problems! I
spent money on a machine so I can get increased speed and performance, not to
run some non-confromant or short-sighted programs. I spend money on those
programs whose developers show interest in the USER and compatibility.. not
just getting every cycle off the machine. The later is Atari OS teams job and
guys like Codeheads, not everybody.


So.. instead of complaining to the company (Apple, Atari or etc.) urge the
developers to write code that fits _your_ needs and also remains conformant.
Then, if Atari messes up, we can post suggestions.


The rest of the discussion about mapping dialogs into windows, changing low
level AES handlers.. that is okay and I support it. Constantly complaining
about EVERY damn thing gets us nowhere..
 ------------
Category 14,  Topic 34
Message 140       Sat Apr 25, 1992
TOWNS [John@Atari]           at 12:19 EDT

In response to a number of questions, comments from Developers.. I would like
to request that programming issues and questions from Developers be taken over
the to the Developer's Roundtable.

I am more than happy to answer what I can for users here.. but Developer's
should bring up their concerns to the Developer Support Staff in the Atari
Developer's RT.

-- John Townsend, Atari Corp.

 ------------
Category 14,  Topic 34
Message 142       Sat Apr 25, 1992
J.ROY18 [Jonathan]           at 16:22 EDT

Marlo,
   Maybe CodeHead will expand PopIt to work with MutliTos and "pop" open
installed GEM programs that aren't on the desktop. (grin)

TOWNS,
   So people who program, but aren't "developers", can't ask programming
questions? )^=
 ------------
Category 14,  Topic 34
Message 143       Mon Apr 27, 1992
M.ABDULKAREE [ASX]           at 00:50 EDT

It would be great if Atari allowed the use of an external program for the
"Show/Print.." feature. They could start us out by including the regular Show
Text/Binary File and print but in a window. And of course people like me (and
others) will _immediately_ buy the program to view the files, GIFs, TIF, IMG,
WP, etc.


And they can print via a system wide print manager!
 ------------
Category 14,  Topic 34
Message 144       Mon Apr 27, 1992
J.ROY18 [Jonathan]           at 04:11 EDT

You can already patch out the S/P/C code... I think there is a DC Viewer or DC
Shower that does that.

I guess there's no chance of someone uploading some MultiTOS screen shots?
There's no Atari shows down here in south Florida. )^=
 ------------
Category 14,  Topic 34
Message 145       Mon Apr 27, 1992
C.F.JOHNSON [CodeHead]       at 11:53 EDT

  There is no legal, documented way to replace the "Show/Print/Cancel" feature
of the desktop.  The program you mentioned, Jonathan, breaks just about every
ST programming rule.  I agree, it would be nice for Atari to provide a legal
hook for this function.

- Charles

 ------------
Category 14,  Topic 34
Message 146       Mon Apr 27, 1992
TOWNS [John@Atari]           at 12:27 EDT

ASX.. That's a good idea. And it is already under consideration. Who knows, it
might even make it's way into MultiTOS..

-- John

 ------------
Category 14,  Topic 34
Message 147       Mon Apr 27, 1992
J.EIDSVOOG1 [CodeHead]       at 19:05 EDT

It's even easier than that.  Even since TOS 1.0, the ability has existed to
replace the "Show/Print/Cancel" function with whatever program you like.  All
you need to do is modify your DESKTOP.INF (NEWDESK.INF) a little bit.  The
docs for our LookIt program tell you how to do this.  The advantages of this
method are that it is completely legal, does not take _any_ resident memory,
and has no compatibility problems whatsoever.

         John Eidsvoog  /|\  Member of the IAAD
 CodeHead Technologies  \|/  Serving the Atari Community
 ------------
Category 14,  Topic 34
Message 148       Mon Apr 27, 1992
J.ROY18 [Jonathan]           at 21:08 EDT

This is pretty funny. Charles says theres no legal way to do it, then John
says there IS a legal way to do it. (^= Personally, I'd like to see MultiTOS
support some type of background printing automaticly... (Which it probably
already has.)

 ------------
Category 14,  Topic 34
Message 149       Mon Apr 27, 1992
OUTRIDER [Terry @ T2]        at 22:06 EDT

Jonathan,

Charles and John are talking about two different things.  Charles was talking
about actually patching (intercepting) the S|P|C function, whereas John was
talking about bypassing it via the Install Application feature of TOS.  The
former is a no-no, while the latter is just dandy.  ;^)

Personally, I _legally_ replace the S|P|C function -- ah heck, the ENTIRE GEM
DESKTOP -- with the HotWire/MaxiFile combo.  :^)

                                  - Terry -

 ------------
Category 14,  Topic 34
Message 150       Mon Apr 27, 1992
C.F.JOHNSON [CodeHead]       at 22:39 EDT

Jonathan,

  John was referring to the "Install Application" method of viewing text
files; a very different thing than having an AUTO folder program that tries to
"intercept" the desktop's show function, as the program you mentioned does.
There is _no_ "hook" for a resident program to use in this way.

  However, you can install an application for _all_ unrecognized file types,
so that any time you double-click a data file that isn't already assigned to
some other application, a "default" application will start up and be passed
the name of the data file.  This will completely bypass the desktop's
"Show/Print..." function; the "Show/Print..." alert box will never even
appear.  The technique requires a manual modification to the DESKTOP.INF file;
there's no way to do it with the GEM desktop itself.

- Charles

 ------------
Category 14,  Topic 34
Message 151       Mon Apr 27, 1992
S.SCHAPER [Meneldil]         at 23:20 EDT

You mean that something like the two-column printer could be activated by
print, simply by doing something to the Desktop.INF file?
 ------------
Category 14,  Topic 34
Message 152       Mon Apr 27, 1992
J.ROY18 [Jonathan]           at 23:31 EDT

Would just putting a *.* in the Desktop.Inf file work?
 ------------
Category 14,  Topic 34
Message 153       Tue Apr 28, 1992
J.EIDSVOOG1 [CodeHead]       at 04:51 EDT

Meneldil,

Yes, you could install the two-column printer to be activated when you double-
click on an unknown file type, but it would be the only way you could "show" a
file.

Jonathan,

It's not _quite_ that simple, but almost.  I have the following entry in my
DESKTOP.INF (NEWDESK.INF) file:

 #G 03 04   C:\CODEHEAD\LOOKPOP\LOOKIT.PRG@ *.*@

This causes LookIt to be called every time I double-click on an unrecognized
extension.  But the trick is that this entry has to be located in the right
spot.  GEM searches the list from the bottom up so this entry has to be
_above_ all other installed applications, including the entries for *.PRG,
*.APP, *.TOS, and *.TTP.

John
 ------------
Category 14,  Topic 34
Message 154       Tue Apr 28, 1992
REALM [Joey]                 at 20:05 EDT

   Might be nice if when double-clicking on a file a dialogue would come up
with the programs that suppott it.  For instance when installing 5 different
programs to use TXT files the 5 would pop up in a button box and allow you to
chose the one you want.
 ------------
Category 14,  Topic 34
Message 155       Tue Apr 28, 1992
B.KING8 [Brien King]         at 20:28 EDT



I think what would be nicer would be the ability to assign ownership to a
file.  What I mean by this, is that if you have a program that creates TXT
files called STUFF.PRG and another program called THINGS.PRG then the OS could
determine which program created the file and then execute that program.  I
think the Mac has this feature.

Then you could change the directory to show this :

Name           Size    Date      Time     Owner

MYFILE.TXT     30,000  04/28/92  14:00    G:\UTILITIES\THINGS.PRG AFILE2.TXT
15,434  04/28/92  01:33    F:\DODADS\STUFF.PRG


Just an idea...  The Owner list would have to be kept seperate from the rest
of the Disk format inorder to keep compatibility with IBM format.

                                                Brien
 ------------
Category 14,  Topic 34
Message 156       Tue Apr 28, 1992
J.ROY18 [Jonathan]           at 21:28 EDT

Yeah, I knew about the bottom to top thing... Never thought of doing a *.*
line however...

Seems someone should write a S/P/C viewer that can display picture and all
those goodies like DC Showit (Was that the name? Ack!) but look exactly like
the normal S/P/C selector so it's completely "tranparent" to the user. Of
course, you'd want a RAM disk for it.... (^;


Realm,
  I've thought of that... One could make a program that is application
installable. Install it for *.*. Make a text file/data file for it listing the
extensions for each specific program. If you click on TXT for example, STeno,
EdHak, and WordPerfect might pop up in a little window, and you click on one.
You could have a default, and the other only open if you hold down ALT or
something when you double click... This is something I'd like to write, but
unfortuantly I'm nowhere near the level of skill needed for it yet. )^=
 ------------
Category 14,  Topic 34
Message 157       Tue Apr 28, 1992
M.ABDULKAREE [ASX]           at 21:46 EDT

Yess!!! <smile>


That is true John E.: but I don't want to have tons of extenders and several
programs when the fastest way could be the module feature built into TOS.


By the way, it would be great if TOS allowed more than one extension for each
application-- this would help a lot for integrated compilers, okay Pure C. But
art/image editing programs will benefit too!
 ------------
Category 14,  Topic 34
Message 158       Tue Apr 28, 1992
TOWNS [John@Atari]           at 23:07 EDT

You can do that now. Write a program that will take a number of inputs and
have it shell to the various programs after running it's shell.

-- John

 ------------
Category 14,  Topic 34
Message 159       Wed Apr 29, 1992
A.FASOLDT [Al Fasoldt]       at 01:05 EDT

John:

GEM searches from the bottom up??

Wow, what a helpful tip. Thanks.

Al

 ------------
Category 14,  Topic 34
Message 160       Wed Apr 29, 1992
CBARRON                      at 02:44 EDT

 Brien King - Re mac resource fork , FORGET IT I am glad I don't have that
problem with my ATARI's.  It is more of a problem than a solution.
 ------------
Category 14,  Topic 34
Message 161       Wed Apr 29, 1992
B.KING8 [Brien King]         at 20:22 EDT

  CBARRON -

        What is a "MAC resource fork"?
 ------------
Category 14,  Topic 34
Message 162       Wed Apr 29, 1992
C.TOWNSLEY [CHARLIE]         at 21:59 EDT

Brien a MAC resource fork is what you use to fix HD crashes. There is no need
to buy the high priced name brands, however. A common BBQ fork will easily
substitute.

For system crashes, there are two usefull tools. Those users who favor finesse
recomend a Katana while those with a more, shall we say, direct approach stand
by a twelve pound sledge. Users priviledge.

:-)

 Charlie Townsley
 ------------
Category 14,  Topic 34
Message 163       Wed Apr 29, 1992
M.DORMAN2 [Mike Dorman]      at 23:59 EDT

But seriously, folks...

It's an entry (or is it actually part of the file?) that allows the MAC to
"know" what program created what file.  It's a bit more sophisticated than
using the "Install Application" menu item (or hacking your desktop.inf), but
it has it's own set of problems.

That's part of why the MAC has all it's proprietary archiving software--
they've got to be able to preserve the resource fork (that's why I get the
impression it's an entry somewhere in the MAC equivalent of the FAT).

Mike.
 ------------
Category 14,  Topic 34
Message 164       Thu Apr 30, 1992
CBARRON                      at 02:33 EDT

 Re REsoure fork.. it is stored in stuffit as a separate entity. I would guess
it is sort of a 'super hidden' file in reality. Ask the gadgets folks, they
can probably tell you more than you want to know about resource forks!  It is
my understanding that every file created has a data fork(the actual file on
most systems) and a resource fork that takes care of the mac 'advanced'
install application methods among other things.
 ------------
Category 14,  Topic 34
Message 165       Thu Apr 30, 1992
DOUG.W [ICD RT]              at 07:50 EDT

All files on the Macintosh consist of two parts, the DATA fork and the
RESOURCE fork.  The data fork usually consists of raw text data and the
resource fork contains everything else including: program code, icons, dialog
boxes, sounds, fonts, menus, etc.
   Most applications have an empty data fork (since everything they use goes
in the resource fork) and most text files have an empty resource fork.
   The filetype and creator information (what kind of file it is and what
program "owns" it) is stored in the directory entry, not the file itself.

--Doug

 ------------
Category 14,  Topic 34
Message 166       Thu Apr 30, 1992
F.BELL1 [Frank @ Home]       at 15:38 EDT

ASX,

  >> [...] allowed more than one extension for each application [...]

You mean like my ARCSHELL example below (extract of Desktop.Inf /
                                         Newdesk.Inf file):

  [...]
  #W 00 00 06 01 34 09 00 @
  #P 03 04 000 C:\EDIT.PRG@ *.*@ @  <-- default program for all
                                        other files (replaces
                                        SHOW/PRINT/WHATEVER)
  #D FF 01 000 @ *.*@ @
  #G 03 FF 200 *.APP@ @ @
  #G 03 FF 000 *.PRG@ @ @
  #Y 03 FF 000 *.GTP@ @ @           <-- anybody know what this is?
  #P 03 FF 000 *.TTP@ @ @
  #F 03 04 000 *.TOS@ @ @
  #G 03 04 000 C:\U_ARCLZH\ARCSHELL.PRG@ *.ARC@ @ <-- call Arcshell
  #G 03 04 000 C:\U_ARCLZH\ARCSHELL.PRG@ *.LZH@ @ <-- call Arcshell
  #G 03 04 102 D:\FIDO\MODULE\BTS.PRG@ *.@ @
  #G 03 04 101 D:\ALADDIN\ALADDIN.PRG@ *.@ @
  [...]

Frank...



 ------------
Category 14,  Topic 34
Message 167       Thu Apr 30, 1992
J.EIDSVOOG1 [CodeHead]       at 20:52 EDT

Frank,

A GTP file is a "GEM Takes Parameters" file.  It is similar to a TTP program
in that a command line box will appear when you run it.  But the program will
run as a GEM program instead of a TOS program.  In other words, the screen
will appear with the standard desktop fill pattern instead of a white screen,
and the mouse will remain enabled.

John
 ------------
Category 14,  Topic 34
Message 168       Thu Apr 30, 1992
J.ROY18 [Jonathan]           at 21:24 EDT

I have my DESKTOP.INF also set to execute *.SFX file... (^=
 ------------
Category 14,  Topic 34
Message 169       Thu Apr 30, 1992
DOUG.W [ICD RT]              at 21:51 EDT

Frank,
   .GTP means "GEM Takes Parameters."  It's for GEM programs that can accept
command line arguments.  Note, though, that this only applies to TOS 2.0x and
above (i.e. NewDesk).

--Doug

 ------------
Category 14,  Topic 34
Message 170       Fri May 01, 1992
F.BELL1 [Frank @ Home]       at 01:10 EDT

John, Doug,

On my brand new Newdesk desktop I've noticed 'GEM Takes Para..." but have had
no idea, will sort'f, what is really meant and no idea on how to use it.
Thanks.  Ah, sorry about the topic drift.

Frank...

 ------------
Category 14,  Topic 34
Message 171       Fri May 01, 1992
TOWNS [John@Atari]           at 01:32 EDT

The .GTP extension is recognized by the new Desktop as a program that runs the
same as a .PRG gem program, but takes parameters on startup. Think of it as a
GEM "ttp" program. ;-)

-- John Townsend, Atari Corp.


 ------------
Category 14,  Topic 34
Message 172       Fri May 01, 1992
B.GOCKLEY [Brian G.]         at 08:30 EDT

Has anybody written one? I'd love to see a sample PD GTP, OK.

Brian D Gockley ST Informer
 ------------
Category 14,  Topic 34
Message 173       Fri May 01, 1992
J.EIDSVOOG1 [CodeHead]       at 12:18 EDT

There are plenty of GTPs.  I've been using them for years.  Any GEM program
that takes a command line is theoretically a GTP.  Some of the most common
ones are ArcShell and Calamus.  You can simulate a GTP in HotWire by simply
selecting "Command Line" for a GEM program entry.  This feature has been there
since the day HotWire was released over three years ago.  There's nothing
magical about a GTP. It was just a logical step for Atari to add this type to
TOS.

John
 ------------
Category 14,  Topic 34
Message 175       Fri May 01, 1992
E.KRIMEN [Ed Krimen]         at 21:08 EDT

 >I have my DESKTOP.INF also set to execute *.SFX file... (^=

One of things I used to do before I got MultiDesk was to have my DESKTOP.INF
set to execute *.AC? files.  Therefore, when I double clicked on something
like STeno or STalker, or any other desk accessory that could also be run as a
program, it would execute as an application.

Of course, if it wasn't one of those 'special' desk accessories,... :^)
 ------------
Category 14,  Topic 34
Message 176       Sat May 02, 1992
CBARRON                      at 04:15 EDT

 There is a gtp executer that works with install application so that double
clicking a gtp file executes it, by executing a small program that executes
the actual file... Just about any CLI that can execute GEM programs can
execute gtp's as well...
 ------------
Category 14,  Topic 34
Message 177       Sat May 02, 1992
J.ROY18 [Jonathan]           at 12:01 EDT

Well, read the AEO issue last night! Sounds great! I'm very happy to hear
MultiTOS supports all sorts of inter-process communication, and spawning off
child processes! I can see all sorts of uses for that in some of the ideas for
programs I have...

Can you set default priorities for individual programs? I guess could you have
a list of them someplace, or use a byte of the program's header... (There
isn't that much free space left, though, is there?)

I think it'd be neat to have things like ARC and LZH preset to lower
priorities than your "normal" settings for other programs. Say, you download a
few files, and while downloading more you start up LZH to extract them
quietly... (Grin)

Hey, now there's an idea for STalker! Auto-execution of LZH under MultiTOS to
extract files to folder, automagicly, after downloading them. Neat.
 ------------
Category 14,  Topic 34
Message 178       Sat May 02, 1992
A.FASOLDT [Al Fasoldt]       at 22:24 EDT

STWriter.prg is a GTP. Has been from the start.

Al

 ------------
Category 14,  Topic 34
Message 179       Sun May 03, 1992
S.JOHNSON10 [Steve]          at 00:31 EDT

So is anyone at Atari 'in the know' as to whether MultiTOS is also designed to
be able to multitask MIDI applications?  I asked before, but I think it was
John Townsend who said that he didn't know.  Is there anyone at Atari or a
developer who DOES know?
 ------------
Category 14,  Topic 34
Message 180       Sun May 03, 1992
M.ABDULKAREE [ASX]           at 16:27 EDT

What are the chances of implementing direct SCSI to FRAM loading of
programs/files an virtual memory in the next release of TT TOS? A lot of TT
owners will be primarily buying FRAM (I'm going to get one soon as
Multitasking TOS is out or I have the money) we don't want the overhead of
loading into regular RAM and then blitting to FRAM.


--


I'd think that one of Atari's concerns is making their system handle MIDI
applications without problems.. I hope.
 ------------
Category 14,  Topic 34
Message 181       Tue May 05, 1992
G.ANDERSON                   at 08:21 EDT

Will it be possible to run different resolutions in different windows under
the new Multitasking TOS or will it multitask only in a single resolution?

Gregg
 ------------
Category 14,  Topic 34
Message 182       Wed May 06, 1992
TOWNS [John@Atari]           at 02:14 EDT

It will only multitask in the resolution you are in. This is just _one_ of the
reasons I beg programmers to make their software work in all possible modes.

--- John

 ------------
Category 14,  Topic 34
Message 183       Wed May 06, 1992
J.ROY18 [Jonathan]           at 19:51 EDT

I'd like to see MultiTOS have a built in "virtual" screen... Something like
MonSTEr so you can scroll the screen around, to run programs that need a
higher res than you normally have. (^=
 ------------
Category 14,  Topic 34
Message 184       Wed May 06, 1992
B.KING8 [Brien King]         at 20:40 EDT



Towns -

        I'll make my programs REZ independent if Atari makes Colors ReZ
independent.  I.E. If I want 256 colors in 320x200, 640x400, 640x480, etc..
then I can have it.  Some of the software I want to do requires 16 or more
colors on the screen at a time.  BTW: Memory is NO OBJECT to me.

                                                    Brien
 ------------
Category 14,  Topic 34
Message 185       Wed May 06, 1992
M.ABDULKAREE [ASX]           at 21:31 EDT

Yeah, all resolutions except the damn crummy and prehistoric ST LOW, ST
MEDIUM, TT LOW (yeah, what a joke!). Everything else I support. Mono and hi.
res color and 1:1 ratio modes.


And yes, I'd automatically expect you implement virtual screen (at least on
the TT and set form_center() to map to physical screen size) with the hardware
scroll features!


And yes, why do we have to go through the painful process of interleaving bits
around? Why not use a byte-scheme for encoding pixels and enhance VDI to
support 24/32 bit color.


Otherwise, your statement only applies to resolutions (the ST mono and TT mono
are redundant, as are the ST Low and TT Medium). And from what we know, the
next resolution you come out with, we will have to scramble or painstakingly
rewrite/update to support it!


This has really gone too far; I agree with Brien, memory is no object.
 ------------
Category 14,  Topic 34
Message 186       Wed May 06, 1992
S.SANDERS2 [SDS]             at 22:19 EDT

I think making a computer REZ independant would be pretty difficult, plus
Atari wants to make sure their OS's are backwardly compatible. It _would_ be
nice if an indepenant bitmap call would be included in the VDI (one that
worked on the screen, had scaling, color dithering, and could work from an
image in memory) ala MS Windows.

-Scott @ SDS
 ------------
Category 14,  Topic 34
Message 187       Thu May 07, 1992
TOWNS [John@Atari]           at 13:11 EDT

If you need a certain number of colors, then you should check the number of
colors on startup and they decide if you can use this resolution. If you can,
then run it in. If not, inform the user that you need a resolution with X
number of colors.

Is that so hard?

-- John

 ------------
Category 14,  Topic 34
Message 188       Thu May 07, 1992
DENNYA [Denny Atkin]         at 14:23 EDT

Isn't there any provision under MultiTos to change resolutions under software
control? ("I need to run in 640x200. Change screen mode if no other programs
onscreen, else inform user.")

 ------------
Category 14,  Topic 34
Message 189       Thu May 07, 1992
R.GLOVER3 [Rob]              at 18:55 EDT

  Towns:

A few strange questions here... when MultiTOS is finally released, will the
disk part of the package be a single TOS.IMG-type file, or multiple utility
files?  Will it be fast enough to get reasonable use out of a normal ST (8 or
16 MHz)?  How far is there to go (in pre-production phase) before it becomes
really stable?  And finally, is there any chance Atari would release a Beta
version to the public for testing, or is that honor reserved for registered
developers?

Rob

 ------------
Category 14,  Topic 34
Message 190       Thu May 07, 1992
S.SCHAPER [Meneldil]         at 20:28 EDT

Ah, but can you run a resolution emulator in one window?

Brien, Have you thought about grey-scaling? AIM has 256 shades of grey on
monochrome, and JLS's StarSaver has 1200.
 ------------
Category 14,  Topic 34
Message 191       Fri May 08, 1992
M.ABDULKAREE [ASX]           at 01:08 EDT

Telling the resolution and colors available is abosolutely not difficult. Just
the fact that we have to mess around with various transformations just to put
a pixel on the screen (in color resolution) from a file (IMG, PCX, TIF, etc.)


MultiTOS on disk? OH MAN.. think about pirates. Unless Atari really wants to
give it away, which is a good gesture but not likely, then ROMS are the best
choice. I'd think they will have it on ROM at least for the TT (which have the
address space) and not sure about the rest of the machines.


Plus loading from disk opens up the pirate market and is also open to run-time
corruption from "rogue processes"!


By the way, in the latest Atari Explorer Online (the first issue) the article
on Multitasking AES/TOS has Bill Rehbock saying that TOS, TTP, applications
will run in a window. Does this mean that the VDI terminal emulation functions
are mapped on to the window? v_clreol(), v_cur_home(), etc. And does AES
automatically detect whether the applications need to be placed in this
window, even if their extension says PRG but they don't even use any AES/VDI
functions? How about line-A driven programs ( not that I care, but just for
completeness).


Also, how are system errors handled? Say, if I'm messingaround with pointers
in Pure C and making Aladdin get messages.. well, I get BUSsed.. now perhaps
the machine may not fold (the current TOS simply quits to the parent process
and Pure C is damn good at trapping everything so far.) Basically, will TOS
still write the bombs on the screen and just leave it at that (potentially
messing up backgrounds) or just draw the bombs, wait a sec, and issue a global
refresh. Or, the better alternative: put the error in a new alert with a bomb
icon and allow the user to acknowledge it.. and then issue a area redraw or
whatever.
 ------------
Category 14,  Topic 34
Message 192       Fri May 08, 1992
S.JOHNSON10 [Steve]          at 01:29 EDT

S.SANDERS2 - Right.  Making SOFTWARE resolution independent is much simpler
than HARDWARE.  The way Atari (TOWNS) suggests it is about the same as Apple
does for the Mac's (i.e. make resolution/bit-depth the choice of the user and
NOT 'hardwire' software to specifics).
 ------------
Category 14,  Topic 34
Message 193       Fri May 08, 1992
J.ROY18 [Jonathan]           at 02:34 EDT

I'd guess MT will have lots of utility programs since MiNT has a whole slew of
them...
 ------------
Category 14,  Topic 34
Message 194       Fri May 08, 1992
G.T.GRAY [Gary Gray]         at 17:55 EDT

An even better MulitTos question than can you run a resolution emulator in one
window would be, can you run a 386sx emulator in one window? I know just
having fun here guys. After all we are just speculating right:-).

 ------------
Category 14,  Topic 34
Message 195       Fri May 08, 1992
S.SCHAPER [Meneldil]         at 20:34 EDT

Well, the _best_ way, IMHO, is releasing OS's on pass-through carts. But if I
understood correctly, at one point, and this may have changed, Atari's idea
was to release it to the entire community for free or nearly so. You would
still need the TOS ROM's, but the enhanced MiNT TOS extensions would go on
disk. The only problem with that is viruses. But at that point they wanted to
make it the new standard for all machines. So making it easily available was
the idea.


At one point someone from Atari asked in an oblique fashion on a public net if
people would like DOS emulation built in, for example, some suggested, a slot
for a 486. The answer is YES.  Even better if it ran in a window. . . But
perhaps only UNIX can do that.
 ------------
Category 14,  Topic 34
Message 196       Fri May 08, 1992
S.SANDERS2 [SDS]             at 21:56 EDT

M.ABDULKAREE:

For displaying any monochrome bitmap on a color screen just use vrt_cpyfrm().

-Scott @ SDS

 ------------
Category 14,  Topic 34
Message 197       Fri May 08, 1992
M.ABDULKAREE [ASX]           at 23:57 EDT

Why in the world would Atari want people to use IBM emulators?! They are
investing a lot of time into Multitasking AES and related stuff.


Third party, perhaps but from Atari?! This would indicate that they are
abandoning TOS (which is not true, so far.)
 ------------
Category 14,  Topic 34
Message 198       Sat May 09, 1992
S.JOHNSON10 [Steve]          at 01:06 EDT

TOWNS - I get annoyed NOW with programs that just refuse to run in certain
resolutions (i.e. they don't even tell the user it can't run in the current
resolution). <grin>


R.GLOVER3 - From what I've heard, if Atari DOES decide to 'let' it run on
68000 machines, you should have an absolute minimum of a 16MHz machine.


M.ABDULKAREE - The way it's worded in AEO, it sounded like MultiTOS might only
be part ROM and part disk for current machines (i.e. it COULD be all in ROM in
their newer machines).
 ------------
Category 14,  Topic 34
Message 199       Sat May 09, 1992
G.T.GRAY [Gary Gray]         at 14:49 EDT

It has been reported several times in the European press and elsewhere that
Sack the German developers of AT-Speed were working with Atari to develop DOS
emulations as original equipment. PC emulation on the ST family machines is
quite well understood. Unfortunately there have been 3 main problems.

(1) No proper installation. A processor direct slot on new machines, would
allow a reliable end user installation.

(2) Limited video capability. Rumours of Falcon's 16 bit color with a pallette
of 262,000 colors is the same as many modern SVGA cards. This would allow
SuperVga DOS emulation. I also read reports of a blitter on these machines, a
good fast blitter aid screen speed could also help an emulator run VGA well.

(3) Price performance. DOS emulators on the ST have always suffered from being
to slow at to high a price. Atari's quantities make the board inexpensive to
manufacture. Recent drastic price drops on SX386 parts also help. Finally new
processors like the Cyrix 486SLC offer 486 performance in a 386SX package, at
prices close to a hundred dollars a chip. These parts will be fifty bucks each
in 6 months. Atari could therefore offer 486 level emulation cards for $299
retail.


There are other reported features of the new machines that also make emulation
easier and more attractive. The new machines have IDE hard disks internal.
Reports of a more standard printer port design, could help with compatability
issues. But the most interesting would be MultiTos. DOS emulation in a Window
under MultiTos would be big plus.

Why would Atari bother with PC emulation in the first place? Because properly
done it would sell a lot of machines. The Amiga offers factory PC emulation,
and it sells machines for them. I suppose also that Atari would like a box
that they can sell of the shelf at ComputerCity or CompUSA type of stores.
Excellent PC emulation would make the product much more saleable in those
stores.



 ------------
Category 14,  Topic 34
Message 200       Sat May 09, 1992
J.ROY18 [Jonathan]           at 19:17 EDT

Hey... Wouldn't it be possible to release MultiTOS on a cartridge? Possibly
with a battery-backed up RAM chip, to keep "patch" info on. (^= You could, of
course, load info into the patch-ram from disk..

A silly idea, I know, but someone has to say it!
 ------------
Category 14,  Topic 34
Message 201       Sun May 10, 1992
G.ANDERSON                   at 01:34 EDT

I, for one, would be interested in a $300 386/486 plug-in DOS emulator for my
system.  Why?  For only two reasons. First is that the AirForce FORCES
everyone to use DOS machines in everything but high-level graphics and so-on
applications and I'd like to be able to 'take work home with me' now and then
without having to convert everything to ASCII all the time. Second is to get
access to all those nifty DOS games that may never be converted to an Atari
format...  Funny, isn't it?  We're called a 'games machine' by all those smug
DOS owners yet there are more games available for DOS than ST/TT/Amiga/MAC
combined.... by a LARGE margin.

Needless to say, I'd buy the Atari-specific version of ANY program if  given
the choice between DOS and Atari versions.

By the way, how did this subject work it's way into the MultiTOS topic? Ah
well, I at least mentioned it so the infamious Topic Police should be happy
<grin>......

Gregg
 ------------
Category 14,  Topic 34
Message 202       Sun May 10, 1992
J.ZORZIN [Joe]               at 09:40 EDT

Well, when MT finally becomes available I hope the cost of Moniterm type
monitors comes down.  What good is all this power on our dinky little screens?

 ------------
Category 14,  Topic 34
Message 203       Sun May 10, 1992
TOWNS [John@Atari]           at 12:18 EDT

Denny.. There are provisions under MultiTOS to change resolutions. MultiTOS
will not allow you to change resolutions until all programs have been
terminated, however.


Rob.. The distribution of MultiTOS has yet to be decided. As for release of
Beta software to the public, Atari has never done this with TOS and it is
unlikely that we will begin now. As for scheduling, I am not sure when a
release of MultiTOS will take place.

Meneldil.. There is not resolution emulator in a window. Sorry.


 ------------
Category 14,  Topic 34
Message 204       Sun May 10, 1992
M.STUEVE [Marlo]             at 19:04 EDT

 Yeah, MultiTOS on cart. I can just see it now. Custom designed pass
 through for other cartridges, battery backed up RAM on board, memory
 paging of some kind to get past the 128K/cartridge address space,
 ROMs executing at cartridge-bus speeds, modified cart for the
 non-standard notebook port, possible replacement power supply for the
 additional power a cart would draw, technical hassles from dirty edge
 connectors, TOS patch for 2.0x telling it to actually load something
 from the cartridge port, etc, etc.

 This IS a silly idea. It wouldn't work. Lets forget about it.

 ------------
Category 14,  Topic 34
Message 206       Mon May 11, 1992
S.SANDERS2 [SDS]             at 03:46 EDT

Actually, as I understand it TOS now is around 192k and the external cartridge
slot only adresses 128k.

-Scott @ SDS
 ------------
Category 14,  Topic 34
Message 207       Mon May 11, 1992
F.BELL1 [Frank @ Home]       at 18:46 EDT

Steve,

Why in the world would you want to limit MultiTos to 16Mhz machines? The next
question - only Atari's 16Mhz machines?  or can Jim Allen, Dave Small, ICD
etc. get on too?

Your 1000% correct about programs that don't inform their users about what
resolution they run in.

Frank...
 ------------
Category 14,  Topic 34
Message 208       Tue May 12, 1992
M.ABDULKAREE [ASX]           at 04:17 EDT

TOS is much larger than 192K.. The TT TOS is around the 512K (definitely over
256K.)


So.. why not put the multitasking kernel into ROMs too?


I was thinking.. _if_ Multitaskting TOS/AES package comes with a buncha
utilities (not all of them CPX) would you like to have the user associate a
folder for placing all SYS, CFG etc. files into? This would REALLY help some
of use manage the C: partition. I keep my C: only for programs/files that NEED
to be there (AUTO, ACC) but others can be relocated elsewhere but noone offers
the choice.


Also, it would be great if the desktop automatically loaded the relevant INF
file to the resolution. NEWDESK1 for LOW, NEWDESK2 for MEDIUM, NEWDESK3 for ST
HIGH, etc..


Also, the Show Information dialog can be made more useful by adding HD spefic
information (when applicable). For example, I'd like to know which HD
partition belongs to which SCSI, where is it hooked up? ACSI, SCSI, it's
status, other info.


HDX displays some of this information at boot up, but do I really have to
bootup everytime I need to remember which disk is what? This becomes more
important for removebale and CD media.


How about including the VOLUME name in the window as well as the amount of
free space? You could use a custom status bar and smaller fonts (beginning to
sound like the way Mac does.)


Also, how about an AES function to obtain the current disk VOLUME name..
helpful for floppies, CD, and removeable HDisks. Or.. perhaps there is another
way of handling it?
 ------------
Category 14,  Topic 34
Message 209       Tue May 12, 1992
J.ZORZIN [Joe]               at 06:29 EDT

But John, wouldn't this be a good time to change Atari policy of not having
the public (by that I mean trusted ST developers) find the inevitable bugs in
MultiTos?  Or by public did you mean "mass distribution."

 ------------
Category 14,  Topic 34
Message 210       Tue May 12, 1992
DOUG.W [ICD RT]              at 07:39 EDT

ASX,
   I already use a 'SYSTEM' folder for my AUTO programs, ACCs, MDXs, CPXs,
GDOS fonts & drivers, MetaDOS drivers, etc.  It really cleans up drive C.

--Doug

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