home *** CD-ROM | disk | FTP | other *** search
/ Fujiology Archive / fujiology_archive_v1_0.iso / !MAGS / !BONUS / DOCS / MULTITOS.ZIP / MULTITOS.ASC
Text File  |  1992-05-12  |  112KB  |  2,981 lines
  1.  ====================================================================
  2.  
  3.  (C) 1992 by Atari Corporation, GEnie, and the Atari RoundTables.  May be
  4.  reprinted only with this notice intact.  The Atari RoundTables on GEnie
  5.  are the *official* information services of the Atari  Corporation.
  6.  
  7.  
  8.  To sign up for GEnie service, call (with modem in HALF DUPLEX)
  9.  800-638-8369.  Upon connection, type HHH
  10.  Wait  for the U#= prompt.  Type XJM11877,GENIE and hit
  11.  RETURN.  The system  will now prompt you for your information.
  12.  
  13.  ====================================================================
  14.  
  15.  ************
  16. Topic 34        Sat Mar 14, 1992
  17. E.KRIMEN [Ed Krimen]         at 21:11 EST
  18. Sub: MultiTOS
  19.  
  20. A topic for the discussion of Atari's MultiTOS, a multitasking TOS based upon
  21. Eric Smith's MiNT.
  22.  
  23. 210 message(s) total.
  24.  ************
  25.  ------------
  26. Category 14,  Topic 34
  27. Message 1         Sat Mar 14, 1992
  28. E.KRIMEN [Ed Krimen]         at 21:12 EST
  29.  
  30.   From Usenet:
  31.  
  32.  Article 23475 in comp.sys.atari.st:
  33.  From: Nils-Henner_Krueger@ki.maus.de (Nils-Henner Krueger)
  34.  Subject: Re: MultiTOS \was MiNT copyright s
  35.  Message-ID: <A663@KI.maus.de>
  36.  Date: 13 Mar 92 13:57:00 GMT
  37.  References: <A42047@HB.maus.de>
  38.  Organization: MausNet
  39.  Lines: 21
  40.  X-Gateway: MausGate/News 1.03
  41.  
  42.  Hi folks!
  43.  
  44.  e>As for the many contradictory rumors floating around about multitasking
  45.  e>TOS; suffice it to say that wild speculation about unreleased products
  46.  e>is rarely productive (and even more rarely accurate :-).
  47.  e>Let's wait and see what Atari actually produces, shall we?
  48.  
  49.  Well, just yesterday at the CeBit fair I could see what Atari actually
  50.  produces:
  51.  There was a demonstration show of the comming MultiTOS, and it really _is_
  52.  based on MiNT! They said that it will come out as a ROM-Upgrade, available
  53. for
  54.  _all_ Atari Computers down to the 1040 ST, although it won't be very usefull
  55. on
  56.  a maschine with less then 16mhz. They were not able to give any exact
  57.  information about the release date, but they said that it will not be before
  58.  the Atari fair in Duesseldorf (Germany) in august.
  59.  
  60.  
  61.  -------------------------------------------------------
  62.  Nils-Henner Krueger, Waitzstr. 98, D-2300 Kiel, Germany
  63.  Phone: xx49/431/86267, email: nk@ki.maus.de (Internet)
  64.  -------------------------------------------------------
  65.  
  66.  ~~~~~~
  67.  
  68.  
  69.  Article 23476 in comp.sys.atari.st:
  70.  From: univwa@sbusol.rz.uni-sb.de (Bernhard Stumpf)
  71.  Subject: MultiTOS really exists - thanks to Eric S.
  72.  Message-ID: <17037@sbsvax.cs.uni-sb.de>
  73.  Date: 14 Mar 92 15:41:13 GMT
  74.  Sender: news@sbsvax.cs.uni-sb.de
  75.  Lines: 25
  76.  
  77.  Yesterday I visited the Hannover Cebit fair - and they really could show it:
  78.  
  79.                  The MultiTOS !!!
  80.  
  81.  It exists - and it runs!!!
  82.  
  83.  They had a beta version, but what I could see:
  84.  
  85.  Atari now has a OS like the Mac, it does Multitasking in several windows,
  86.  not a task switching like the Mickey Mouse commander on a MS-DOS machine
  87. (brr,
  88.  I'll have to wash my mouth afterwards...).
  89.  
  90.  The Multitos runs at the moment as a program, but it will be distributed in
  91.  ROMs. The Atari guy I spoke had to avoid that it bases on Eric Smith's work,
  92.  they only added the GEM surface. He said that the development now will be
  93.  continued on Atari side and will surely make another way than Eric's MiNT.
  94.  
  95.  
  96.  That's all for now...
  97.  
  98.  
  99.  Bernhard
  100.  
  101.  
  102.  bestu@rz.uni-sb.de
  103.  
  104.  ~~~~~~
  105.  
  106.  
  107.  Article 23477 in comp.sys.atari.st:
  108.  From: techno@lime.in-berlin.de (Techno)
  109.  Subject: Multitasking TOS on CeBit
  110.  Summary: Multitasking TOS shown
  111.  Keywords: TOS,Atari,multitasking,CeBit
  112.  Message-ID: <W8B174@lime.in-berlin.de>
  113.  Date: 14 Mar 92 20:55:42 GMT
  114.  Distribution: comp
  115.  Organization: LIME Systems featuring a TOGA Party
  116.  Lines: 12
  117.  
  118.  Atari demonstrated the new multitasking TOS on the german CeBit computer
  119.  fair. Due to the huge crowds, I was only able to cast a glimpse at it,
  120.  though it seemed to run OK.
  121.  
  122.                              Techno
  123.  
  124.  --
  125.  | techno@zelator.in-berlin.de ||| Please do not e-mail from outside Germany !
  126. |
  127.  | techno@lime.in-berlin.de   / | \ Hardcore ST user !  ======================
  128. |
  129.  | Nothing that's real is ever for free, you just have to pay for it sometime.
  130. |
  131.  |                                        (Al Stewart)
  132. |
  133.    Hi ! I'm a .signature virus. Join the fun and copy me into your .signature
  134. !
  135.  
  136.  ~~~~~~
  137.  ------------
  138. Category 14,  Topic 34
  139. Message 2         Sun Mar 15, 1992
  140. TOWNS [John@Atari]           at 13:43 EST
  141.  
  142. Yes, Atari did demonstrate the Multitasking TOS at CeBIT. There are currently
  143. no estimated delivery dates or pricing information available. As soon as real
  144. information is available, we will let you know.
  145.  
  146. -- John Townsend, Atari Corp.
  147.  
  148. PS. And yes, It is based on MiNT (MiNT is _NOW_ TOS! <grin>) from
  149.     Eric Smith.
  150.  
  151.  ------------
  152. Category 14,  Topic 34
  153. Message 3         Sun Mar 15, 1992
  154. M.ABDULKAREE [ASX]           at 16:06 EST
  155.  
  156. Hey.. I could have told you guys that! When I went down there (at Atari) they
  157. had it running on Mike Fulton's machine and I NEVER figured out what it was
  158. until they told me that it was indeed Multitasking TOS.. <wide grin> (Okay, so
  159. every one knows now.. I can spill the bits!)
  160.  
  161.  
  162. You can switch application by going to the Desk menu and selecting the
  163. application-- the last time I saw it simply put in the programs filenames, I
  164. suggested that they allow the program to register a name it wants using an
  165. extention to appl_init(name). Also you can switch by clicking on the other
  166. application's menu.
  167.  
  168.  
  169. It is VERY much like MultiFinder.. I just hope Apple does not become jealous;
  170. Atari's implementation is faster :-) I can't wait until the release it..
  171. especially a 68030 optimized version!
  172.  
  173.  
  174. By the way.. I did not get a chance, but does it run non GEM applications in a
  175. sizeable window? John?
  176.  ------------
  177. Category 14,  Topic 34
  178. Message 4         Sun Mar 15, 1992
  179. C.MACLEOD2 [Cam MacLeod]     at 16:31 EST
  180.  
  181. Well congratulations to Eric Smith. He hails from London, Ontario and actually
  182. showed MiNT to the local users group last year (London Users of STs...LUST).
  183.  
  184. MiNt was impressive even last year.
  185.  
  186.  ------------
  187. Category 14,  Topic 34
  188. Message 5         Sun Mar 15, 1992
  189. M.DORMAN2 [Mike Dorman]      at 16:33 EST
  190.  
  191. Oh, John.  Oh, John.  This is wonderful news.  I'm going to quiz you now...:-)
  192.  
  193. I assume that Allan (sp?) Pratt was knee-deep in the development, since he's
  194. been sort of Eric Smith's co-conspirator.  Gee, is *that* why he gave Eric
  195. patches to use with Lattice?
  196.  
  197. Any details about the structure?  (And just to make sure--this system does pre-
  198. emptive multitasking of GEM apps, right?  Or is it strictly cooperative?  Does
  199. it use something similar to Allan's MW2 for MiNT to allow multiple TOS
  200. programs to run?)  At one time, people had talked about setting up sort of a
  201. client-server sort of baby-XWindows sort of thing, and letting both processes
  202. operate under MiNT.
  203.  
  204. Is that what's being done?
  205.  
  206. I really can't tell you how excited this news makes me.  I've lived with MiNT
  207. off and on for the last 1.5 years, since v. 0.6, and I'm using 0.92 on a daily
  208. basis, and it is *SOLID*.
  209.  
  210. Although, this does raise some questions as to how you're going to handle some
  211. of the things MiNT has problems with, like the start-up code from older
  212. compilers that doesn't support the "correct" argument passing standard, and
  213. some of the other hacks that MiNT has had to implement to stay 99% compatible.
  214. Personally, at this not-yet-released stage, I'll say this:
  215.  
  216. Make the stuff in the ROM's *pure*--no hacks, no garbage, just a damn solid
  217. system.  And then, if possible, design RAM-patches that will make it more
  218. compatible with old, non-standard stuff.  You're going to have to make some
  219. changes that are going to break old stuff.  I, at least, accept and encourage
  220. that, despite the fact that one of the compilers that I use on a daily basis,
  221. Sozobon 1.33i, is going to break.  I think they way because I think it would
  222. be a shame not to do it *right*, and make those changes count by making them a
  223. totally solid basis for expansion.
  224.  
  225. But that's just my $.02.  Do good, and I'm looking forward to seeing it.
  226.  
  227. Mike.
  228.  ------------
  229. Category 14,  Topic 34
  230. Message 6         Sun Mar 15, 1992
  231. TOWNS [John@Atari]           at 20:22 EST
  232.  
  233. Thanks for the comments everyone. However.. I would like to hold off on
  234. discussing specifics of the implimentation at this point. According to what I
  235. know, the Multitasking TOS is still under development and is currently being
  236. beta-tested with a group of extremely capable people. As you probably know,
  237. when things are in the development stages, features and implimentation details
  238. are subject to change.
  239.  
  240. -- John
  241.  
  242.  ------------
  243. Category 14,  Topic 34
  244. Message 16        Thu Mar 19, 1992
  245. S.JOHNSON10 [Steve]          at 00:46 EST
  246.  
  247. TOWNS - Geesh!  Calm down.  I think everyone's aware that Atari's never
  248. released a disk-based version of TOS (except the ORIGINAL TOS).  I believe Jim
  249. was referring to (and joking about) when beta versions of TOS 2.xx and TOS
  250. 3.xx started showing up on some BBS's.  And I DO remember some of the Atari
  251. folks online here saying not to use them because they were still buggy and
  252. could mess up data on peoples' drives, not to mention the fact that it was
  253. illegal!
  254.  ------------
  255. Category 14,  Topic 34
  256. Message 22        Sat Mar 21, 1992
  257. G.ANDERSON                   at 20:44 EST
  258.  
  259. Ah yes, but it does make for a nice change now and then <grin>.
  260.  
  261. Meanwhile, back on the subject...  How long before we can get some of the
  262. specifics of MultiTOS?  IE: how many applications running at the same time,
  263. selecting between applications (clicking on the window (if on the screen),
  264. selecting from a dropdown menu on the desktop, switching between applications
  265. that fill the available screen to others, performance losses per application
  266. active, assigning priorities to CPU time per applications, handling of
  267. application conflicts for system I/O, etc....
  268.  
  269. Since I'm running a T-16 right now (and hopefully a T-25 when it arrives) on
  270. my Mega4 I'd be interested in MultiTOS when it becomes available (any 'wags'
  271. on a date?).  I must admit that my goal, assuming I'm still employed when they
  272. are released, is to upgrade to a new system in the rumored 'Falcon' series so
  273. some practice with MultiTOS would be nice to have.
  274.  
  275. I'm curious though, how does MultiTOS/MiNt handle applications that grab ALL
  276. system RAM/resources when they boot?  There are more of them like that out
  277. there then there should be (Flash for example).
  278.  
  279. MultiTOS is a GREAT step forward for Atari, as much for 'bragging rights' in
  280. advertising as for actual user capability.  It also indicates a change at
  281. Atari itself.  For years it seemed Atari had a bad 'not invented here'
  282. complex, ignoring or rejecting 3rd party developments in favor of 'in house'
  283. programs and ideas.  By bringing MultiTOS online and basing it on a 3rd party
  284. creation (with credits given to the original creator) Atari is showing us that
  285. they've opened up a BUNCH and are looking at independent developers with new
  286. respect and acceptance.  This is NOT to imply they've ever done otherwise mind
  287. you, but now the message is much clearer and more public.
  288.  
  289. Good show guys, I'm tipping my hat to you again <grin>.
  290.  
  291. Gregg <Yokota AB, Japan>
  292.  ------------
  293. Category 14,  Topic 34
  294. Message 24        Sun Mar 22, 1992
  295. J.EIDSVOOG1 [CodeHead]       at 04:28 EST
  296.  
  297. Gregg,
  298.  
  299. Nice try <grin>, John T. says he can't talk about MultiTOS, the subject gets
  300. diverted, and you slip back in an attempt to pull out some more info.  Pretty
  301. sneaky.
  302.  
  303. Yes, there are a lot of programs that grab all of memory, and yes, MultiTOS
  304. has a method to handle this.  Oops...already said too much.
  305.  
  306. John
  307.  ------------
  308. Category 14,  Topic 34
  309. Message 25        Sun Mar 22, 1992
  310. G.ANDERSON                   at 06:48 EST
  311.  
  312. John (E)....  I may be honest, but I never said I wasn't sneaky <grin>..
  313.  
  314. Still, the questions were reasonable ones I think.  I AM interested in
  315. MultiTOS and hope to see it available before too much longer. I've a few
  316. thoughts as to how it handles the 'bad' programs.. but admit that I lack the
  317. programming talents to manage any details.
  318.  
  319. Still, it's a VERY positive step and one that says good things about what
  320. Atari's doing these days.
  321.  
  322. Gregg <nasty but nice>
  323.  ------------
  324. Category 14,  Topic 34
  325. Message 26        Sun Mar 22, 1992
  326. WAYNED. [Wayne]              at 11:58 EST
  327.  
  328. Gregg,
  329.   I too have a lot of questions about Multi-Tos. (doesn't everyone?) However
  330. from what little has been said it sounds like they are still in the process of
  331. defining the scope and limits so anything they (Atari) told you now might just
  332. change in the final form for one of several reasons that I can think of right
  333. away.  1) Memory constraints: It might take too much memory to implement a
  334. 'feature'. 2) Speed:  Said 'feature' might slow the OS down to an unacceptable
  335. level.  3) Compatibility:  Adding a 'feature' might compromise compatibility
  336. with the existing software/hardware base.
  337.  
  338.   While 3 isn't quite as important to me it does become important given the #
  339. of developers no longer supporting old software either because they are out of
  340. business, or no longer supporting Atari. Hopefully though with the new
  341. machines rumoured, Multi-Tos, and some other glimmers of hope we'll see a
  342. fresh infusion of new and returning developer support.  Of course that would
  343. require significant #'s of machines being sold!
  344.  
  345.   So while like you I have a lot of questions I'm satisfied to wait and see
  346. for a while.  I think it's time to go and get back into trying out MINT and
  347. it's companion programs so I can get a taste of what's coming!
  348.             Wayne
  349.  
  350.  ------------
  351. Category 14,  Topic 34
  352. Message 27        Sun Mar 22, 1992
  353. M.ABDULKAREE [ASX]           at 13:55 EST
  354.  
  355. Using any kind of mutliple processing on the 68000 does manage to slow the
  356. machine down.. you can fool around with this right now but simply opening up
  357. all six DAs while doing your wordprocessing.. SNAIL!
  358.  
  359.  
  360. And one note you should keep in mind is that not all applications will run,
  361. notably the non GEM ones.. don't expect a miracle, there are none. I think
  362. John Towns is good at expalining these things, he set me straight on them.
  363.  
  364.  
  365. ---
  366.  
  367.  
  368. Hmm.. how about a feature that allows the user to use a picture for the
  369. bacground instead of colors/patterns? This stuff is already there for X, OS/2,
  370. and (bleakh) Windows.. just for those of use who have spare 150K lying
  371. around.. <smile> Just a thought.
  372.  ------------
  373. Category 14,  Topic 34
  374. Message 28        Sun Mar 22, 1992
  375. M.DORMAN2 [Mike Dorman]      at 15:01 EST
  376.  
  377. Everyone--
  378.  
  379. I just uploaded MiNT 0.93 last night, and I'll try to get some other,
  380. subsidiary programs up tonight--a port of tcsh (a PD c-shell clone), Eric R.
  381. Smith's package of miscellaneous utilities, probably a MiNT-aware port of the
  382. GNU BASH, some other stuff like that.  Heck, if people are interested enough,
  383. I can upload the *source*.
  384.  
  385. MiNT is *definitely* worth working with if you like using a CLI--I've had *7*
  386. different instances of Zoo running at once, unarchiving a bunch of files I got
  387. off the Internet--and then I jumped into GNU Emacs.  The response was a
  388. _little_ slow, but still usable.
  389.  
  390. I'm not affiliated with Eric Smith (though I'd like to be, so I could get
  391. betas of the newest versions before anyone else...:-), I'm just someone who's
  392. been using MiNT for the last year and a half, and almost constantly for the
  393. last 6 months (I only boot up in GEM to use Aladdin and Uniterm--I need to
  394. work on hacking a good vt100 emulator that'll handle 7-bit connections, and
  395. then I'll only be in GEM to use Aladdin).
  396.  
  397. Oh, I'm just posting this here because of what Wayne said about wanting to
  398. tinker--there's already a MiNT topic on the board (somewhere, unless it died),
  399. so any requests and such should go there. I have Internet access, and though
  400. I'm not always prompt, if there's stuff you want, I can usually get it.
  401.  
  402. Mike.
  403.  ------------
  404. Category 14,  Topic 34
  405. Message 29        Sun Mar 22, 1992
  406. REALM [Joey]                 at 15:33 EST
  407.  
  408.     ASX, Theres already a few Auto programs that display pictures in the
  409. background.  I had one way back, I think I even got it off GEnie.:-)  It
  410. loaded Degas and Neo if I remember right.
  411.  ------------
  412. Category 14,  Topic 34
  413. Message 30        Mon Mar 23, 1992
  414. TOWNS [John@Atari]           at 10:55 EST
  415.  
  416. I am sorry, folks. But I think we owe our developers the chance to prepare
  417. their products for MultiTOS and to allow them to get their input heard before
  418. we start to reveal details. As you are well aware, when a product is in the
  419. testing stage, lots of things are still up in the air. To discuss details of
  420. the implimentation would be premature at best.
  421.  
  422. - John
  423.  
  424.  ------------
  425. Category 14,  Topic 34
  426. Message 31        Mon Mar 23, 1992
  427. J.NESS [Jim]                 at 20:14 EST
  428.  
  429. ACK!!
  430.  
  431. You mean, we have to make changes to our programs, in order for them to run
  432. under MultiTOS?
  433.  
  434. ACK!!
  435.  
  436.                                -JN
  437.  
  438.  ------------
  439. Category 14,  Topic 34
  440. Message 32        Mon Mar 23, 1992
  441. M.ABDULKAREE [ASX]           at 22:32 EST
  442.  
  443. Most of my GEM documentation kept reminding me that there would be a
  444. multitasking version of GEM and not to use certain things.. well, seems like I
  445. was prepared!
  446.  
  447.  
  448. REALM: I wanted a picture on the TT medium (Degas only supports ST
  449. resolutions.)
  450.  ------------
  451. Category 14,  Topic 34
  452. Message 33        Tue Mar 24, 1992
  453. S.NOAH [Stu]                 at 01:14 EST
  454.  
  455. Well, I wish everyone involved with the MultiTOS project the best of luck.  I
  456. only hope that you do your idiot testing with some real live idiots... after
  457. you have that accomplished maybe then the product will be ready for all the
  458. rest of us.
  459.  
  460.                         ... enough self deprecating humour
  461.  
  462. Stu
  463.  
  464.  ------------
  465. Category 14,  Topic 34
  466. Message 34        Tue Mar 24, 1992
  467. G.ANDERSON                   at 03:59 EST
  468.  
  469. Thanks guys... and good kudos to you John (T).  I agree that the developers
  470. need a good, solid 'head start' on the MultiTOS....  I'm just tickled to death
  471. (does anyone really talk like that anymore?) that MultiTOS is being
  472. xDseveloped.  Since it's a software item a little 'advanced word' is both
  473. welcomed and appriate <sp?>..  Thanks for letting us know it's being done..
  474. and forgive us if we get a bit impatient now and then, but all of also have a
  475. major investment in Atari & its products and want to see it become not only
  476. great (already is) but everything it can be.
  477.  
  478. Gregg
  479.  ------------
  480. Category 14,  Topic 34
  481. Message 35        Tue Mar 24, 1992
  482. TOWNS [John@Atari]           at 13:38 EST
  483.  
  484. In most cases, GEM programs will run without any modifications at all. The
  485. only kinds of programs that MultiTOS doesn't like are programs that take over
  486. the screen (i.e. Dialogware!) and lock out other applications.
  487.  
  488. If you really want to make your programs (or future programs) work with
  489. MultiTOS, just be sure to follow the rules, stay clear of dialogs that are
  490. more than just call up, select something and go away, and try to use Windows
  491. for your output. If you do this, you should be okay.
  492.  
  493. BTW.. If you are worried about Windows in MultiTOS, don't. Windows are
  494. allocated dynamically, so you are only limited by your memory. If your machine
  495. has the memory, you can open the window.
  496.  
  497. And to answer a couple of questions, MultiTOS can run as many GEM programs as
  498. you have memory for. There is no limit. Of course, you have to realize that
  499. for every application that you have running in the System, it is going to take
  500. a piece of the available CPU time. So, realistically.. there is a limit to the
  501. number of applications you can run (before your machine will slow down to a
  502. crawl ;-)
  503.  
  504. Applications are switched by topping one of their windows or by selecting the
  505. name of the application in the Desk Menu. Applications are listed below the
  506. Desk Accessories.
  507.  
  508. Just a couple of answers for those of you out there. I don't mind answering
  509. questions on this subject, just don't ask me stuff like "What happens to I/O
  510. registers when you switch applications?, etc."
  511.  
  512. -- John
  513.  
  514.  
  515.  ------------
  516. Category 14,  Topic 34
  517. Message 37        Tue Mar 24, 1992
  518. D.MCNAMEE [Dan @ Atari]      at 14:43 EST
  519.  
  520. Jim,
  521.  
  522.         Only those that broke the rules so that their software won't work.
  523.  
  524. Dan
  525.  
  526. Stu,
  527.  
  528.         They already have.  They had me do some testing on it ;-)
  529.  
  530. Dan
  531.  
  532.  ------------
  533. Category 14,  Topic 34
  534. Message 38        Tue Mar 24, 1992
  535. DENNYA [Denny Atkin]         at 16:22 EST
  536.  
  537. I'm curious about the comment that multitasking would "slow down" the ST if
  538. you launched too many tasks. On the Amiga, at least, a task really on takes up
  539. time if it's actually doing something. If it's just waiting for input, it
  540. basically uses no processor time. Will GEM apps under MultiTOS work the same
  541. way, or will they be "busy-waiting" when not actually calculating and thus
  542. using up processor time?
  543.  
  544. (I find this whole thing rather amusing, since I remember the old Atari vs.
  545. Amiga days when one of the Tramiels was claiming that multitasking slowed the
  546. Amiga down, and was a bad thing. ;-)
  547.  
  548.  ------------
  549. Category 14,  Topic 34
  550. Message 39        Tue Mar 24, 1992
  551. NEVIN-S                      at 18:32 EST
  552.  
  553. Towns, what happens to I/O registers when you switch applications? <grin>
  554.  
  555. Seriously, MultiTOS sounds great! I can't wait to put it on my TT.
  556.  
  557. --Nevin
  558.  
  559.  ------------
  560. Category 14,  Topic 34
  561. Message 40        Tue Mar 24, 1992
  562. C.TOWNSLEY [CHARLIE]         at 19:42 EST
  563.  
  564. Heh heh.
  565.  
  566. Dan @ Atari and Stu, I have a feeling that this could turn into a version of
  567. the "lightblub" jokes.
  568.  
  569. Q: How many idiots does it take to break Atari MultiTOS?
  570.  
  571. A: With or without the power turned on?
  572.  
  573.  Charlie Townsley
  574.  ------------
  575. Category 14,  Topic 34
  576. Message 41        Tue Mar 24, 1992
  577. REALM [Joey]                 at 19:49 EST
  578.  
  579.     ASX, Ohhhhhhhhhhh!:-)  It could still be done with a short Auto program,
  580. maybe GIF, PNT or something?  Be nice to save the desktop as a GIF, remove all
  581. icons and windows and save setup.  Then when someone else starts playing on it
  582. none of the windows will work since it's just a picture of the desktop and not
  583. the real thing.:-)
  584.     When you have two programs running at once isn't the CPU speed cut in
  585. half?  Seems like using several programs at once wouldn't be any more
  586. productive then using one then the other.  If I have Prism Render running in
  587. two windows doing two different frames wouldn't it take the same amount of
  588. time as doing one frame then the other since the speed is cut in half?
  589.     I've talked to several people who think Multitasking means the can run 4
  590. or 5 programs at the same time and accomplish 4 times the work.  I think it's
  591. a little misleading in that sense.  It's actually not much more then a
  592. switcher that continues to run in the background should the CPU have time.
  593.     I know theres a lot of positive aspects I just like to pick on the
  594. negative.:-)  I look forward to it but I don't think it should be considered
  595. the missing link or anything.:-)
  596.  ------------
  597. Category 14,  Topic 34
  598. Message 42        Tue Mar 24, 1992
  599. M.ABDULKAREE [ASX]           at 23:11 EST
  600.  
  601. Applications that are completly event driven work best in any multitasking
  602. system. They get serviced when needed and perform their calculations when
  603. needed. I think a combination of event servicing and time sharing is the best
  604. way to go.
  605.  
  606.  
  607. In short, if you write your applications to just sit there until the user
  608. clicks somewhere, or your window needs a redraw, etc. and perform
  609. calculations/operations at request then the speed degradation will be less.
  610.  
  611.  
  612. For example, I (hypotehtically) write a graphing program. Initially I wait for
  613. messages, open window, menu selections, etc. Most of the time I am not doing
  614. anything so the OS does not need to worry about me. Now say the user wishes to
  615. enter a new function to graph. Okay, put up a window and go into another even
  616. management loop; wait until the user starts typing when the mouse in in my
  617. window or I get messages.
  618.  
  619.  
  620. I think this type of multitasking is called cooperative? Contrary to the
  621. "blind" time sharing or prioritied schemes.. NOTE: I'm not saying which system
  622. Atari has implemented but simply discussing how things are being done on other
  623. platforms and currently under the limited multiprocessing under AES.
  624.  
  625. I could go on.. but this is basically how programs could be written: courteous
  626. and yielding. No hogging of the timer or wind_update() stuff.
  627.  
  628.  ------------
  629. Category 14,  Topic 34
  630. Message 43        Tue Mar 24, 1992
  631. T.MCCOMB [=Tom=]             at 23:20 EST
  632.  
  633. But Joey- you could have Prism Render busy rendering away in the background
  634. while you type up a text file.  you wouldn't have to give up your computer for
  635. hours(?) days(?) while it renders.  Of course this means the rendering would
  636. take longer, but... theres always a trade off, ain't there!
  637.  
  638.                         -Tom
  639.  
  640.  ------------
  641. Category 14,  Topic 34
  642. Message 44        Wed Mar 25, 1992
  643. S.NOAH [Stu]                 at 00:48 EST
  644.  
  645. Charlie,
  646.  
  647. The nice thing about the idiotic is we have all been there.  No one person has
  648. a monopoly on it, and no one person is immune from it.
  649.  
  650. All@Dev@Atari,<..can ya tell I've been working with Vines a lot ?>
  651.  
  652. I am not much for playing computer games, but ...
  653.  
  654. A friend of mine has the Sublogic flight simulator, and I have noticed that it
  655. does windowing, but these do not look like standard GEM windows.  It would be
  656. really neat if this sort of stuff could be run from within a window...  Given
  657. a fast enough machine, could this type of, graphics intensive, program be
  658. written to operate from within a GEM window  ?
  659.  
  660. Stu
  661.  ------------
  662. Category 14,  Topic 34
  663. Message 47        Wed Mar 25, 1992
  664. REALM [Joey]                 at 20:05 EST
  665.  
  666.      Tom, Thats a given!:-)  I just think it's important users know when you
  667. run several programs your not actually doing several times the amount of work.
  668. I'm not complaining just being observant.:-) I'm all for multitasking, it
  669. sounds like a great way to optimize your computer time and avoid dead lock
  670. when rendering or other time consuming actions.  Actually, on a TT or Turbo 30
  671. it would be like having 4 ST's in one spot.
  672.      I was wondering about running applications in a window.  Would it be
  673. possible to run ST High res programs on a 19" monitor?  How would the program
  674. running view the resolution of a window?  Is that too specific a question?
  675.  
  676.  ------------
  677. Category 14,  Topic 34
  678. Message 48        Wed Mar 25, 1992
  679. TOWNS [John@Atari]           at 20:51 EST
  680.  
  681. Denny.. I mean't applications that are doing something. MultiTOS is smart
  682. enough that it will time slice to the applications that are doing things, and
  683. applications that aren't doing things will get smaller slices.
  684.  
  685. I was speaking of applications that are doing things. What I should have said
  686. was that "As you load applications that are constantly doing things (like
  687. drawing to the screen), the system will get slower." For example, I have
  688. several programs I run at the same time on my machine.. one is a clock (that
  689. updates the screen once a second), one is a "lines" program in a window that
  690. continuously draws line patterns in a window, etc. These programs will take up
  691. CPU time.
  692.  
  693. BTW.. MultiTasking on a 68000 will slow down the machine. That hasn't changed.
  694. You can't expect a computer that is handling several applications to run as
  695. fast as a computer that is sitting there waiting to run one application. The
  696. single tasking computer is usually going to be faster.
  697.  
  698. Joey.. not neccessarily. A program only takes up CPU time when it needs it.
  699. It's doesn't get a 25% cut of the time or anything that definite. When it
  700. needs to run, it gets some time to run. MiNT also has provisions for making a
  701. process get less or more priority, similar to 'nice'ing a process under UNIX,
  702. etc.
  703.  
  704. -- John
  705.  
  706.  
  707.  
  708.  ------------
  709. Category 14,  Topic 34
  710. Message 49        Thu Mar 26, 1992
  711. J.ROY18 [Jonathan]           at 01:50 EST
  712.  
  713. Well, personally, I'm glad to hear about MultiTOS for the ST! I've used MiNT
  714. alot (Did I upload one of the first versions? I don't remember..) up to about
  715. .8 or so, but then my HD died, and I didn't get back into it... Maybe MiNT 1.0
  716. is MultiTOS? (grin) I've always liked MiNT and felt it was very stable. Glad
  717. to see it as Atari's choice! Also glad you can set priorities and such for
  718. programs... (grin) Someone on Usenet said it wouldn't work on an ST, only a
  719. TT, but then someone else said it was shown on an ST! (^= Anyways, enough
  720. blathering for now. Is there any projected release date? (I'll just wait for
  721. MultiTOS instead of TOS 2.06...)
  722.  
  723. Oh, by the way, will running ONE single program run the same speed as on an
  724. older TOS? (Or does teh MultiTOS have some overhead?)
  725.  ------------
  726. Category 14,  Topic 34
  727. Message 50        Thu Mar 26, 1992
  728. J.ROY18 [Jonathan]           at 01:52 EST
  729.  
  730. Opps, forgot to ask. Will TOS programs run in a window?
  731.  ------------
  732. Category 14,  Topic 34
  733. Message 51        Thu Mar 26, 1992
  734. DENNYA [Denny Atkin]         at 11:44 EST
  735.  
  736. John,
  737.  
  738. Thanks for the clarification on how MultiTOS handles "waiting tasks." Sounds
  739. pretty neat. I'll be anxious to try it out.
  740.  
  741.  ------------
  742. Category 14,  Topic 34
  743. Message 52        Thu Mar 26, 1992
  744. TOWNS [John@Atari]           at 21:30 EST
  745.  
  746. Again.. there is no release date, no information on what platforms MultiTOS
  747. will run on (i.e. TT only, or TT and STE/ST/Mega, etc.), or upgrade
  748. information.
  749.  
  750. As for whether one program will run as fast under MultiTOS as it does under
  751. normal TOS, I am just not sure. To me it appears to be close on my TT. But
  752. then again, I am just going by look and feel.
  753.  
  754. As for TOS Programs, that has yet to be determined. There is talk of a
  755. possible "console" window in TOS that would be were TOS programs are run. This
  756. hasn't been nailed down yet. See what I mean about details?
  757.  
  758. -- John
  759.  
  760.  ------------
  761. Category 14,  Topic 34
  762. Message 53        Thu Mar 26, 1992
  763. M.ABDULKAREE [ASX]           at 22:02 EST
  764.  
  765. ..And that time slicing, etc. can be controlled via CPX right? :-) And while
  766. your're at it, how about adding a function to change the NNN values for
  767. CACHENNN and XXX values for FOLDRXXX? I know it is trivial to open up the
  768. auto\ and rename them, but.. just a suggestion.
  769.  ------------
  770. Category 14,  Topic 34
  771. Message 54        Thu Mar 26, 1992
  772. R.GLOVER3 [Rob]              at 22:25 EST
  773.  
  774. Towns:
  775.  
  776. Be careful about using that term -- "look and feel" as I hear uttering those
  777. words alone is enough to bring on the wrath of the Apple legal department! ;)
  778.  
  779.  
  780. I know this is slightly off-topic, but can someone give me a brief hint on how
  781. to get MiNT working?  When I downloaded it, it had no docs, other than to
  782. state that you put MINT.PRG in the AUTO folder. By the way, is there a topic
  783. for MiNT?  I don't recall seeing one...
  784.  
  785. Thanks!
  786.  
  787. Rob
  788.  
  789.  ------------
  790. Category 14,  Topic 34
  791. Message 55        Fri Mar 27, 1992
  792. J.ROY18 [Jonathan]           at 00:25 EST
  793.  
  794. There used to be a MiNT topic. I think the older MiNT archives have all the
  795. files and such, where .93 and so on are only the updated files.  (I'm not
  796. sure.)
  797.  ------------
  798. Category 14,  Topic 34
  799. Message 56        Fri Mar 27, 1992
  800. R.GRANT11 [Ron @ GXRSYS]     at 01:40 EST
  801.  
  802. Towns, I'm amused yet horrified by your use of capitalization when speaking of
  803. "Windows" in MultiTOS.
  804.  
  805. :-)
  806.  
  807.  ------------
  808. Category 14,  Topic 34
  809. Message 57        Fri Mar 27, 1992
  810. TOWNS [John@Atari]           at 02:54 EST
  811.  
  812. Rob.. check out the MiNT topic in the Programming Category (I think!). I
  813. believe it contains information on setting up MiNT and how to use it.
  814.  
  815. Ron.. <grin> Sorry. I will be sure to make it "windows" in the future. But,
  816. remember, I didn't call them "win 3s" or anything. So, you're safe. <One
  817. comment: I used Windows on a 386SX tonight. ugh. The think was soooo slow.
  818. Amazing>
  819.  
  820. - John
  821.  
  822.  ------------
  823. Category 14,  Topic 34
  824. Message 58        Fri Mar 27, 1992
  825. T.KAY3 [TKAY]                at 05:07 EST
  826.  
  827. John@...
  828.  
  829. Risking the wrath of the topic cops, I would like to ask a question on the use
  830. of the term "Windows".   Granted, "window" is a generic term; however, when
  831. used in conjunction with "computer", would we be infringing on MS/Windows
  832. copyrights?  And excuse me if I'm wrong, but didn't we (in the Atari ST+
  833. community) have windows before any other platform?
  834.  
  835. BTW..  glad to see so much activity between Atari and the users here on GEnie
  836. and at Atari Corp.   Looks like we still have a very positive future if I read
  837. between the line.
  838.  
  839. Tell me John, will my new Falcon be able to run Lotus, Excel, MS Word et. al.,
  840. faster than a 386/40?  slap.. *^&$@ ! or faster than a 486? ..ouch..  bye.
  841.  ------------
  842. Category 14,  Topic 34
  843. Message 59        Fri Mar 27, 1992
  844. D.A.BRUMLEVE [kidprgs]       at 07:45 EST
  845.  
  846.  Actually, TK, the generic use of the term "windows" was commonplace
  847.  before the development of MS Windows, so MS would be hard-pressed to
  848.  protect that usage.
  849.  
  850.  I'm not a lawyer, but, as a member of the jury, I'd sure shoot down such
  851.  a suit. ;-)
  852.  ------------
  853. Category 14,  Topic 34
  854. Message 60        Fri Mar 27, 1992
  855. SANDY.W [RT SysOp]           at 10:30 EST
  856.  
  857. The old MINT topic was archived. It is file #21122 in the Software Library.
  858. There will be a MINT topic in Category 3 Topic 20 early tomorrow (Saturday)
  859. morning. It is being moved from Category 2 due to space considerations.
  860.  ------------
  861. Category 14,  Topic 34
  862. Message 61        Fri Mar 27, 1992
  863. WAYNED. [Wayne]              at 19:49 EST
  864.  
  865.   Unfortunately many terms that are 'generic' have come to be synonymous with
  866. the IBM arena.  Take the term PC for instance.  It means Personal Computer,
  867. but whenever you say PC most people picture an IBM.(UGH!)  Now windows will
  868. come to mean WINDOWS on the PC instead of being a generic term. (And NO we
  869. didn't have windows first, for all intents and purposes Apple did)
  870.  
  871.   I'm about to download the new version of MINT (Mint is NOW Tos!) and some of
  872. the companion programs and give it a whirl again.  I tried it a few versions
  873. back and it showed promise but wasn't really practical at the time.  However
  874. now that it is going to be a basis for the new Multi-Tos I want to get back up
  875. to speed.
  876.  
  877.        Wayne (I think "P"iece of "C"rap when I picture an IBM)
  878.  
  879.  ------------
  880. Category 14,  Topic 34
  881. Message 62        Fri Mar 27, 1992
  882. J.NESS [Jim]                 at 20:20 EST
  883.  
  884. John T. -
  885.  
  886. Well, there is always NBM v1.2, for testing the speed of MultiTOS.
  887.  
  888. You may not be free to tell us anything about the results, but at least YOU
  889. would know.
  890.  
  891. Of course, since NBM itself is a screen-hogger dialog box, it probably is not
  892. MultiTOS compliant...
  893.  
  894.                                 -JN
  895.  
  896.  
  897.  ------------
  898. Category 14,  Topic 34
  899. Message 63        Fri Mar 27, 1992
  900. R.GLOVER3 [Rob]              at 20:36 EST
  901.  
  902. I finally got the new MiNT installed and running with Neodesk, but I don't
  903. know what to do with it.  I'm a little peeved at it right now, as it's
  904. partially responsible for toasting my Aladdin config file, so I had to
  905. reconfigure from scratch.  Ugh.
  906.  
  907. Rob
  908.  
  909.  ------------
  910. Category 14,  Topic 34
  911. Message 64        Fri Mar 27, 1992
  912. M.DORMAN2 [Mike Dorman]      at 21:08 EST
  913.  
  914. Rob--
  915.  
  916. The latest version of MiNT (0.93) us up, and it has docs and all. There is
  917. also a new MiNT topic--I know, because I started it.  I guess I've sort of
  918. crowned myself "MiNT Emperor of GEnie"--I use it regularly, and I have
  919. Internet access, and I'm willing to keep thing up here updated, and offer
  920. suggestions and tips to the best of my ability.
  921.  
  922. The topic is somewhere in CAT 2, I think.
  923.  
  924. Mike.
  925.  ------------
  926. Category 14,  Topic 34
  927. Message 65        Sat Mar 28, 1992
  928. S.JOHNSON10 [Steve]          at 01:18 EST
  929.  
  930. I don't know if anyone answered this when I asked it before, but will MultiTOS
  931. be setup to handle multitasking of timing-critical MIDI applications?
  932.  ------------
  933. Category 14,  Topic 34
  934. Message 66        Sat Mar 28, 1992
  935. S.NOAH [Stu]                 at 02:07 EST
  936.  
  937. Why not just alow access to TOS programs through a gem/VT52 terminal program ?
  938. Then you could set up a number of Terminal-Window/TOS sessions as you want.
  939.  ------------
  940. Category 14,  Topic 34
  941. Message 67        Sat Mar 28, 1992
  942. SANDY.W [RT SysOp]           at 16:39 EST
  943.  
  944. The MINT topic is in Category 3 Topic 20.
  945.  ------------
  946. Category 14,  Topic 34
  947. Message 68        Sat Mar 28, 1992
  948. TOWNS [John@Atari]           at 21:45 EST
  949.  
  950. Stu.. that is basically what the console window would be. Naturally, the
  951. ability to have more than one console window at a time would be part of the
  952. solution.
  953.  
  954. As for MIDI timing.. I don't know anything about that.
  955.  
  956. -- John
  957.  
  958.  ------------
  959. Category 14,  Topic 34
  960. Message 69        Sat Mar 28, 1992
  961. R.GLOVER3 [Rob]              at 22:46 EST
  962.  
  963. Mike, Sandy:
  964.  
  965. Thanks... I did the topic update and I now get the new MiNT topic. Yes, I have
  966. 0.93.  I got it from atari.archive last week (much cheaper than getting it
  967. from GEnie!).  I also got all the associated utilities (BASH, TCSH, etc).  Oh,
  968. and I did find the docs afterall!
  969.  
  970. Now once I figure out what to do with it, I'll start using it again. The only
  971. TOS-related programs I ever run are LHARC and occaisonally ARC or ZOO.
  972.  
  973. Now I'll shut up and move over that that topic. ;)
  974.  
  975. Rob
  976.  
  977.  ------------
  978. Category 14,  Topic 34
  979. Message 70        Sun Mar 29, 1992
  980. S.JOHNSON10 [Steve]          at 00:01 EST
  981.  
  982. T.KAY3 - No, the Mac had windows first (as standard on a microcomputer).  One
  983. interesting piece of info is that Microsoft tried to sell Windows (what they
  984. had at the time) to Atari to use in the ST's OS instead of DRI's GEM, but
  985. luckily Atari chose the latter.  Also, keep in mind that Apple's suing
  986. Microsoft for some $4.5 billion for MS Windows infringing on THEIR
  987. copyrights/patents. I'm also interested to see if we'll have some IBM
  988. emulators for the Falcon machines (software AND hardware) that'll support
  989. VGA/XGA/etc. color since that kind of video capability's already available in
  990. the new machines' hardware.
  991.  
  992. --- End Topic Drift ---
  993.  ------------
  994. Category 14,  Topic 34
  995. Message 71        Sun Mar 29, 1992
  996. JLS [John STanley]           at 02:08 EST
  997.  
  998. TOWNS,
  999.  
  1000.   This is sounding more and more fantastic the more I hear...
  1001.  
  1002.   How well does MultiTOS work with any of the dozens of exitsting system
  1003. enhancement programs (various vector stealers and resident goodies)?  Any tips
  1004. on what's (TSR programming-wise) legal or semi-legal under TOS that we won't
  1005. be able to do under MTOS?
  1006.  
  1007.  >... There is talk of a possible "console" window in TOS that would be
  1008.  >were TOS programs are run. ...
  1009.  
  1010.   Three things:
  1011.  
  1012.     Please don't limit this to _a_ (singular) window.  The programs I use most
  1013. of the time are TOS/TTP programs and limiting me to only running one at a time
  1014. would drasticaly limit the utility of the new system.
  1015.  
  1016.     Please allow for a method any shell program can use to "launch" new (tos
  1017. or prg) processes in seperate windows and allow icon'ing the window/tasks
  1018. (under program or manual control) when we don't need to see the process for a
  1019. while.
  1020.  
  1021.     For tos/ttp programs running in a window, please have some method we can
  1022. use to alias and update window-specific copies of the aline variable block
  1023. (positive and negative offsets) (or some other non-GEM method) so programs
  1024. that pay attention can sense the true window size (or some virtual-screen
  1025. scrollable window size) and adapt themselves where appropriate.  (This may be
  1026. something you'd want to control with one of the unused program flags...)  I
  1027. know that on windows where this is used, this would take some extra memory per-
  1028. task, but I've seen and written several programs that adapt to any screen size
  1029. based on the "still-supported" aline vars and it would be a real shame if
  1030. there was no way to allow them to easily sense and adapt to running in a
  1031. window.
  1032.  
  1033.     Is the system pointer "run" used-by/maintained-by MTOS?
  1034.  
  1035.   Keep up the great work,
  1036.                       ... JLS
  1037.  ------------
  1038. Category 14,  Topic 34
  1039. Message 72        Sun Mar 29, 1992
  1040. B.KANTOR [CadMan]            at 04:32 EST
  1041.  
  1042. John Towns,
  1043.  
  1044. Does/will Multi-TOS have resource locking capabilites.  By this I mean, can an
  1045. application open a file for exclusive access or lock hardware so that no other
  1046. application can use it?  Will it contain a built in print spooler so that
  1047. multiple applications can print at the same time?
  1048.  
  1049. I know nothing about MINT, so I apoligize if these are obviuos features of
  1050. Multi-TOS.
  1051.  
  1052.                Bruce M. Kantor
  1053.  
  1054.  ------------
  1055. Category 14,  Topic 34
  1056. Message 73        Sun Mar 29, 1992
  1057. S.NOAH [Stu]                 at 04:40 EST
  1058.  
  1059. Just a thought...   Support for the standard clipboard really takes on an
  1060. entire new meaning when viewed in the light of a Multitasking version of TOS.
  1061.  
  1062.  
  1063. Stu
  1064.  ------------
  1065. Category 14,  Topic 34
  1066. Message 74        Sun Mar 29, 1992
  1067. A.VALENT [Mike]              at 09:17 EST
  1068.  
  1069. John Stanley - One of you programmers really should come up with some sort of
  1070. a GEM window shell for TOS/TTP programs to run in. For that matter, a
  1071. resolution-independent shell in which hard-coded ST Medium/High res programs
  1072. would run on the Moniterm, TTM194, and in TT Medium would really be useful.
  1073. I've read that the Overscan programmers have done one that sets up a 640x400
  1074. window on a MOniterm or TTM, and Jim Allen has told me of a German program
  1075. that will display 640x400 on a 1280x960 monitor with each pixel x 4.
  1076.  
  1077. Nice if Multiple TOS/TTP support comes built into multitasking TOS, but if not
  1078. it would appear to be possible to get it with such a shell program.
  1079.  ------------
  1080. Category 14,  Topic 34
  1081. Message 75        Sun Mar 29, 1992
  1082. J.ROY18 [Jonathan]           at 11:48 EST
  1083.  
  1084. Well, MiNT already runs loads of TOS/TTP programs at once, so I don't see why
  1085. they would remove that ability...
  1086.  ------------
  1087. Category 14,  Topic 34
  1088. Message 76        Sun Mar 29, 1992
  1089. D.FLORY [ALERTsys*Cop]       at 14:58 EST
  1090.  
  1091. Steve, actually I saw windows on the Xerox Star years before the Mac. I think
  1092. Mac licensed it from Xerox, originally. In any case Mac is the one that
  1093. popularized it by offering the windows environment on a popular (read less
  1094. than $10,000[and $10k then was more like $20k nov]) computer.
  1095.  ------------
  1096. Category 14,  Topic 34
  1097. Message 77        Sun Mar 29, 1992
  1098. M.ABDULKAREE [ASX]           at 15:50 EST
  1099.  
  1100. Yep, the WIMPy interface was developed at Xerox PARC but when Apple and DRI
  1101. started coming up (wee early days) they did not do anything.. until Apple
  1102. started making lotsa money! And started suing others.
  1103.  
  1104.  
  1105. Incidentally, Apple licensed the Mac from some place called Mac Labs. Hmm..
  1106.  
  1107.  
  1108. Heh heh heh.. John is really being inundated with queries. If we're not
  1109. careful, he might stop answering in this topic.
  1110.  ------------
  1111. Category 14,  Topic 34
  1112. Message 78        Sun Mar 29, 1992
  1113. TOWNS [John@Atari]           at 16:48 EST
  1114.  
  1115. Steve.. if I remember right.. Microsoft Windows didn't even exist in late
  1116. 1984. I have never heard this statement until you mentioned it. I would be
  1117. interested to know where you got that one.
  1118.  
  1119. John.. TSRs are loaded before MiNT. Currently, MiNT is the last thing in your
  1120. AUTO Folder. Whether or not it will be put into ROM, I have no idea. But,
  1121. currently you can have TSRs load before MiNT.
  1122.  
  1123. As for Legal vs. Illegal.. please see the previous messages in this topic. One
  1124. new thing in TOS that might cause some problems.. You can now move background
  1125. windows, and basically use any gadget on a background window. Remember, always
  1126. go thru your rectangle list for Redraws. Never assume that there is nothing on
  1127. top of you.
  1128.  
  1129. Another thing.. Dialogware is bad as well. Most Dialogs will lock the screen.
  1130. This will prevent you from switching to another Application until you make the
  1131. Dialog go away. Try to use Windows for your output whenever possible. Dialogs
  1132. are okay, as long as you use them to Select something and then they go away.
  1133. They shouldn't be the primary display for your application.
  1134.  
  1135. As for your comments on console windows, please see my previous comments in
  1136. this topic. We have not limited the number of TOS programs you can run. MiNT
  1137. has this capability and we haven't removed it.
  1138.  
  1139. As for processes ability to launch applications, We are trying to "distance"
  1140. the Desktop from the AES so that you can install a different shell. I think
  1141. this will solve the problem.
  1142.  
  1143. Your other comments should be addressed in the Developer's Area at the
  1144. appropriate time.
  1145.  
  1146. Bruce.. I am not sure. As I said, a number of things are still up in the air.
  1147.  
  1148.  
  1149.  
  1150.  ------------
  1151. Category 14,  Topic 34
  1152. Message 79        Sun Mar 29, 1992
  1153. R.DEAN3 [GUNNER]             at 18:12 EST
  1154.  
  1155. Will Multitos take advantages of the 68030 chip???  Looks like a great
  1156. addition to any of the 68030 accellerators!!!
  1157.  
  1158. Gunner
  1159.  ------------
  1160. Category 14,  Topic 34
  1161. Message 80        Sun Mar 29, 1992
  1162. M.DORMAN2 [Mike Dorman]      at 19:02 EST
  1163.  
  1164. Mike Valent (Just to distinguish you from the other Mikes)
  1165.  
  1166. Well, there is a program under MiNT that will let you run multiple
  1167. shells/programs in multiple console windows.  Allan Pratt wrote it...
  1168.  
  1169. I can get it up here, and help you set it up, if you'd like...
  1170.  
  1171. Mike.
  1172.  
  1173. -------------------
  1174.  
  1175. John--
  1176.  
  1177. I, too, have heard the rumor about Windows, and also heard that they couldn't
  1178. deliver it in time, and that's why we ended up with GEM (which is a nicer OS,
  1179. *still*, IMHO).
  1180.  
  1181. Mike. <Who supports Windows on a NetWare LAN at his day job, and hates it,
  1182. even if Word for Windows is pretty darn spiffy>
  1183.  ------------
  1184. Category 14,  Topic 34
  1185. Message 81        Sun Mar 29, 1992
  1186. OUTRIDER [Terry @ T2]        at 19:47 EST
  1187.  
  1188.      What ever happened to MidiTasking or whatever it was called?
  1189.  
  1190.                                   - Terry -
  1191.  
  1192.  ------------
  1193. Category 14,  Topic 34
  1194. Message 82        Sun Mar 29, 1992
  1195. M.DORMAN2 [Mike Dorman]      at 22:54 EST
  1196.  
  1197. Outrider--
  1198.  
  1199. It died a kludge's death?
  1200.  
  1201. Mike.
  1202.  ------------
  1203. Category 14,  Topic 34
  1204. Message 83        Mon Mar 30, 1992
  1205. DENNYA [Denny Atkin]         at 16:18 EST
  1206.  
  1207. Towns,
  1208.  
  1209. A pre-alpha Windows was shown publically at the NCC (National Computer
  1210. Conference, used to be the big computer show before Comdex killed it) show in
  1211. Anaheim, CA in summer of 1983. Before the Mac was even announced.
  1212.  
  1213.  ------------
  1214. Category 14,  Topic 34
  1215. Message 84        Mon Mar 30, 1992
  1216. A.VALENT [Mike]              at 19:43 EST
  1217.  
  1218. Thanks, Mike (Dorman). I had an older version of MiNT on my hd for a while but
  1219. but didn't do anything beyond playing around with it. Was fun to load my
  1220. Moniterm screen with 5 or 6 windows drawing those string art demos... that's
  1221. about my level of sophistication. :-)
  1222.  
  1223. Whatever the Mint shell was that I also downloaded, it sure had a lovely
  1224. opening screen.
  1225.  
  1226. Back in the early Tramiel Atari days, one or more of the mags published
  1227. speculation that Microsoft wouldn't do any ST programming because they'd tried
  1228. to sell Jack on using Windows for the ST's OS shell, and "were upset" that the
  1229. ST went with GEM instead.
  1230.  
  1231. John, Windows was featured (Along with GEM and the ST and the Amiga) in an
  1232. announced but not yet released item section in The Whole Earth Software
  1233. Catalogue. That was published in 1985, suggesting that the story may have been
  1234. possible.
  1235.  ------------
  1236. Category 14,  Topic 34
  1237. Message 85        Tue Mar 31, 1992
  1238. REALM [Joey]                 at 00:29 EST
  1239.  
  1240.     I've got Microsoft Write and I'm glad Microsoft 'isn't' programing for the
  1241. ST.:-)
  1242.  ------------
  1243. Category 14,  Topic 34
  1244. Message 86        Tue Mar 31, 1992
  1245. S.JOHNSON10 [Steve]          at 00:39 EST
  1246.  
  1247. D.FLORY - I said (or at least THOUGHT I did) that the Mac was the first
  1248. personal computer to be window-based.  Apple didn't license it from Xerox, but
  1249. Xerox sorta told Apple that they had no use for the windowing system and that
  1250. they were welcome to 'borrow' it.  Mind you, that changed several years later
  1251. when Apple was making tons of money with the Mac and Xerox tried to sue.
  1252. <grin>
  1253.  
  1254.  
  1255. TOWNS - I'd heard from several places that when the ST's OS was in the
  1256. 'planning stages' that both Microsoft and DRI were trying to 'sell' a
  1257. windowing system to Atari.
  1258.  
  1259.  
  1260. OUTRIDER - MIDI-Tasking died due to lack of interest from developers, although
  1261. Bob Brodie said that multitasking for MIDI applications is still being worked
  1262. on by Atari, which is why I asked if MultiTOS was 'set up' to handle MIDI
  1263. applications.
  1264.  ------------
  1265. Category 14,  Topic 34
  1266. Message 87        Tue Mar 31, 1992
  1267. J.EIDSVOOG1 [CodeHead]       at 11:33 EST
  1268.  
  1269. Steve,
  1270.  
  1271. MIDI tasking did not die from lack of developer interest, it died because it
  1272. was headed in the wrong direction and wasn't feasible.
  1273.  
  1274. John
  1275.  ------------
  1276. Category 14,  Topic 34
  1277. Message 88        Tue Mar 31, 1992
  1278. D.FLORY [ALERTsys*Cop]       at 19:05 EST
  1279.  
  1280. Sorry, Steve, I think you're right, the Star really wasn't a _personal_
  1281. computer. Not at those prices and it had a pretty big box that sat on the
  1282. floor. Not what we generally think of as a personal computer.
  1283.  ------------
  1284. Category 14,  Topic 34
  1285. Message 89        Wed Apr 01, 1992
  1286. S.SCHAPER [Meneldil]         at 02:23 EST
  1287.  
  1288. Huh? The personal computer Danny Dunn used, the Miniac, was pretty big.
  1289.  
  1290.  
  1291. And I've got a friend in Mound that has as his goal a VAX in his house. He
  1292. figures that he's got room for that _and_ the dogs. . .
  1293.  ------------
  1294. Category 14,  Topic 34
  1295. Message 90        Thu Apr 02, 1992
  1296. S.JOHNSON10 [Steve]          at 02:41 EST
  1297.  
  1298. J.EIDSVOOG1 - I THOUGHT Bob Brodie said that they couldn't get developers
  1299. together to 'discuss' it and that certain developers were more interested in
  1300. using their current systems (MROS and Dr.T's MPE, although the latter isn't
  1301. multitasking) rather than adopt MIDI-Tasking?
  1302.  ------------
  1303. Category 14,  Topic 34
  1304. Message 91        Thu Apr 02, 1992
  1305. TOWNS [John@Atari]           at 16:29 EST
  1306.  
  1307. The point is that it is no longer being pursued.
  1308.  
  1309. -- John
  1310.  
  1311.  ------------
  1312. Category 14,  Topic 34
  1313. Message 92        Thu Apr 02, 1992
  1314. J.ROY18 [Jonathan]           at 20:03 EST
  1315.  
  1316. Will MultiTOS be able to write to the drive, and such, without freezing the
  1317. rest of the system? (The amiga can write to the disk in the background, can't
  1318. it?)
  1319.  ------------
  1320. Category 14,  Topic 34
  1321. Message 93        Thu Apr 02, 1992
  1322. J.EIDSVOOG1 [CodeHead]       at 21:27 EST
  1323.  
  1324. Steve,
  1325.  
  1326. Perhaps we're both right.  I believe that developers lacked interest in
  1327. MIDItasking because the proposed plan was not feasible.  I just don't want to
  1328. see developers blamed for the demise of MIDI-Tasking by stating that it was
  1329. dropped for lack of interest by developers. Something must be useful in order
  1330. to entice people to use it.  I believe that MultiTOS will fill this bill and
  1331. am happy about it.
  1332.  
  1333. John
  1334.  ------------
  1335. Category 14,  Topic 34
  1336. Message 94        Sat Apr 04, 1992
  1337. A.FASOLDT [Al Fasoldt]       at 00:33 EST
  1338.  
  1339. Jonathan,
  1340.  
  1341. STalker already writes to the disk in the background when you run it as a DA
  1342. on the ST, so your answer is certainly "yes" regarding MultiTOS.
  1343.  
  1344. Al
  1345.  
  1346.  ------------
  1347. Category 14,  Topic 34
  1348. Message 95        Sat Apr 04, 1992
  1349. J.ROY18 [Jonathan]           at 14:19 EST
  1350.  
  1351. No, it doesn't. (At least not on my computer.) Whenever STalker accesses the
  1352. drive (most noticeable on a floppy) the entire computer freezes.  NOTHING
  1353. continue while the floppy is being written to. I know. (^=  I have a 4K file
  1354. buffer, and I get little 1-2 seconds delays every time it fills.
  1355.  
  1356. Could you (with MT) write two floppy drives, and a HD, and a RAM disk, all at
  1357. once? I've also heard that SCSI controller have some sort of built in
  1358. mechinism for handleing multiple read/write commands at once... I hope
  1359. MultiTOS exploits it. (^=
  1360.  ------------
  1361. Category 14,  Topic 34
  1362. Message 96        Sat Apr 04, 1992
  1363. R.GLOVER3 [Rob]              at 21:44 EST
  1364.  
  1365.   Will MultiTOS handle multitasking as well as the Amiga?  I have to ask this,
  1366. because I was at a friend's house today, and he has an Amiga.  It's a stock
  1367. (processor-wise) Amiga 2000 with 5 meg of RAM, a new SCSI card (two ports), a
  1368. flicker fixer and a Sony 1304HG monitor. He runs a BBS on this system, and two
  1369. users were logged on.  He was also showing me a graphic animation, and playing
  1370. a MOD file.  And all with the 7.16 MHz 68000.  Very impressive to say the
  1371. least.
  1372.  
  1373. My point is, can MultiTOS do that????
  1374.  
  1375. Rob
  1376.  
  1377.  
  1378.  ------------
  1379. Category 14,  Topic 34
  1380. Message 97        Sun Apr 05, 1992
  1381. J.ROY18 [Jonathan]           at 00:06 EST
  1382.  
  1383. Well, I can already run a MOD file in the background.. (grin)
  1384.  ------------
  1385. Category 14,  Topic 34
  1386. Message 98        Sun Apr 05, 1992
  1387. R.GLOVER3 [Rob]              at 14:21 EDT
  1388.  
  1389. J.ROY18:
  1390.  
  1391. How do you manage that?
  1392.  
  1393. Rob
  1394.  
  1395.  ------------
  1396. Category 14,  Topic 34
  1397. Message 99        Sun Apr 05, 1992
  1398. J.ROY18 [Jonathan]           at 21:31 EDT
  1399.  
  1400. Just use Jukebox. The next version 1.2 (which I'm testing) adds a shuffle
  1401. ability, and a resumption of suspended mods..
  1402.  ------------
  1403. Category 14,  Topic 34
  1404. Message 100       Mon Apr 06, 1992
  1405. C.MACLEOD2 [Cam MacLeod]     at 00:00 EDT
  1406.  
  1407. I played with MultiTOS at the ACE show this weekend and was IMPRESSED. It
  1408. works and works well. It was running on a TT and although there weren't tons
  1409. of apps on it it did work and looked nice.
  1410.  
  1411. Apparently it should be available in 1992 but the decision hasn't been made
  1412. whether to offer it as an upgrade to 68000 machines. I imagine that it will be
  1413. offered as an upgrade if not standard on these machines.
  1414.  
  1415. Atari seems to have gotten its act together and is now pulling in the same
  1416. direction. A welcome change to be sure.
  1417.  
  1418.  ------------
  1419. Category 14,  Topic 34
  1420. Message 102       Mon Apr 06, 1992
  1421. M.ABDULKAREE [ASX]           at 21:40 EDT
  1422.  
  1423. Hmm.. I think you can check a similiar situation by loading the BBS under MiNT
  1424. and running the desktop. Next, start the DMA stereo MOD file and after
  1425. returning to the desktop, start the graphic animation (sans DMA sound.)
  1426.  
  1427.  
  1428. I don't have MiNT or an STE with HD (just a TT waiting for multitasking AES)
  1429. so someone else will have to do it.
  1430.  ------------
  1431. Category 14,  Topic 34
  1432. Message 103       Mon Apr 06, 1992
  1433. C.TOWNSLEY [CHARLIE]         at 23:26 EDT
  1434.  
  1435. Well, I saw MultiTOS at the Atari booth at ACE and was very impressed. I
  1436. missed Bill's talk on it, unfortunatly, had to get back to work at the booth.
  1437.  
  1438. I am very much lookng forward to it's delivery.
  1439.  
  1440.  Charlie Townsley
  1441.  
  1442.  ------------
  1443. Category 14,  Topic 34
  1444. Message 104       Tue Apr 07, 1992
  1445. J.ROY18 [Jonathan]           at 02:21 EDT
  1446.  
  1447. It's better be availible for use 68000 people. (grin) I won't be able to
  1448. afford a TT for some time..
  1449.  ------------
  1450. Category 14,  Topic 34
  1451. Message 106       Tue Apr 07, 1992
  1452. G.ANDERSON                   at 07:27 EDT
  1453.  
  1454. I echo the '68000' release for MultiTOS....  Why?  Because there are a LOT of
  1455. us out here with 16, 20, and 25 Mhz 68000s and 68030 boards that could benifit
  1456. from having it.  Granted that it might suffer an Amiga-like slow down on an
  1457. 8Mhz 68000 and 'might' suffer from compatibility problems with some
  1458. programs.... but a simple disclaimer and a LOT of public comments on it should
  1459. help there. I plan on upgrading my Mega4 too, but it will have to wait a
  1460. little while until I can get my pennies stacked high enough <grin>.  But until
  1461. then I'd like to try my luck with MultiTOS....
  1462.  
  1463. If it were released to current ST owners, would it be as a software-based
  1464. patch or would we have to swap ROMs?  I know, no decisions have been  reached
  1465. yet but could you tell us which way the wind is blowing without getting into
  1466. trouble?
  1467.  
  1468. Gregg
  1469.  ------------
  1470. Category 14,  Topic 34
  1471. Message 107       Tue Apr 07, 1992
  1472. TOWNS [John@Atari]           at 17:51 EDT
  1473.  
  1474. The method of distribution for MultiTOS has not been determined as of yet. We
  1475. will have to wait and see what happens!
  1476.  
  1477. -- John
  1478.  
  1479.  ------------
  1480. Category 14,  Topic 34
  1481. Message 112       Wed Apr 08, 1992
  1482. F.BELL1 [Frank @ Home]       at 15:29 EDT
  1483.  
  1484. If my voice means anything, the dogs around my house don't think so, then I
  1485. too am for a 68000/T16/T20/T25 MultiTos.  But I understand if it made
  1486. available on the Falcon or the TTs only - remember guys, good Memory
  1487. Management is a must for any multi processing system and those 68000s just
  1488. don't have it.
  1489.  
  1490. Frank...
  1491.  
  1492. P.S.  all the TOS 2.06 conversion board manufactures that I know of, said they
  1493. will support MultiTos ROMs if at all possible.
  1494.  
  1495.  
  1496.  ------------
  1497. Category 14,  Topic 34
  1498. Message 114       Thu Apr 09, 1992
  1499. OUTRIDER [Terry @ T2]        at 06:26 EDT
  1500.  
  1501. Frank @ Home,
  1502.  
  1503.      I can appreciate your statement about good memory management being
  1504. important for multi processing, but I still think it should be made available
  1505. for 68000 users and let the buyer beware.  I don't like being told I HAVE to
  1506. wear a seatbelt.  ;^)
  1507.  
  1508.                                   - Terry -
  1509.  
  1510.  ------------
  1511. Category 14,  Topic 34
  1512. Message 116       Sat Apr 11, 1992
  1513. J.ALLEN27 [FAST TECH]        at 15:25 EDT
  1514.  
  1515. Nothing like the "LINES.PRG" running on an ISAC under MultiTos to make an
  1516. impression on people. A couple Lines, and couple Boinks, and the desktop.
  1517. Nieat!
  1518.  ------------
  1519. Category 14,  Topic 34
  1520. Message 117       Thu Apr 16, 1992
  1521. M.ABDULKAREE [ASX]           at 21:33 EDT
  1522.  
  1523. I have been pondering over this scenario since I started writing my custom
  1524. Editable field handler; driven by evnt_multi().
  1525.  
  1526.  
  1527. I suspect that this problem has been attended to, but as a "things to make
  1528. others think about" I present it.
  1529.  
  1530.  
  1531. Okay, assume that you have two desk accessories in the background doing status
  1532. updates and you are in your application busily doing things, clicking, typing,
  1533. etc.
  1534.  
  1535.  
  1536. If the two DAs use AES object routines for their output (or their own routines
  1537. but do not check for mouse bounds) then everytime they draw something to the
  1538. screen, you get a mouse flicker. An example is Aladdin's text editor, and my
  1539. dummy DA which puts up a window and just draws numbers via objc_draw() every
  1540. two seconds; I purposely do not check for mouse bounds for any thing. If I had
  1541. two copies of my DA installed, there is a very good chance that I will
  1542. experience difficulty and irritation using the mouse due to the flicker
  1543. frequecy.
  1544.  
  1545.  
  1546. The problem is that the current AES drawing routines do not check for mouse
  1547. bounds. Think what would happen if on a multitasking system with the user
  1548. having started several tasks which are now busy doing their work and
  1549. displaying stuff (which is not a bad idea.) FLICKER HELL!
  1550.  
  1551.  
  1552. Would YOU like it? I seriously doubt it. So please consider your users and
  1553. think open.
  1554.  
  1555.  
  1556. Checking whether the mouse is in bounds or not maybe code consuming, but you
  1557. do realize space and user-interface pay offs in the long run. VDI calls do not
  1558. check for mouse bounds and neither do they hide/show it during operations: the
  1559. program must handle this. I do, and check for the bounds.
  1560.  
  1561.  
  1562. Now if the AES's functions are updated to check for this, then you probably
  1563. would add a general function to be called everytime you need to check.
  1564.  
  1565.  
  1566. WORD m_inregion(WORD rect[]);
  1567.  
  1568.  
  1569. Where rect contains the coordinates of the area to be re/drawn in standard AES
  1570. x, y, w, h form. And the function would return 0x01 if the mouse in within the
  1571. region or 0x0 otherwise.
  1572.  
  1573.  
  1574. The reason for adding this function is to perform check at the interrupt
  1575. level, right after the mouse has been moved. This will effectively eliminate
  1576. the LOW possibility of the mouse moving into the bounding region after passing
  1577. the outside test:
  1578.  
  1579.  
  1580. rect[]= { x, y, w, h }
  1581.  
  1582. evnt_multi(..&mx, &my..)
  1583.  
  1584. .
  1585.  
  1586. ..  Perhaps a call to a function-- chance for delay.
  1587.  
  1588. .
  1589.  
  1590. if ( (mx>rect[0]) OR (mx<rect[0]+rect[2]) ..same for y coord )
  1591.  
  1592.  { hide mouse and draw.. }
  1593.  
  1594. else
  1595.  
  1596.  { don't bother hiding mouse, just draw! }
  1597.  
  1598. .
  1599.  
  1600. .
  1601.  
  1602.  
  1603. I have tested my simple checking routine before calling v_gtext and was unable
  1604. to cause the mouse to be overwritten, i.e., my check was successful!
  1605.  
  1606.  
  1607. What do you all think?
  1608.  
  1609.  
  1610.  
  1611. ------
  1612.  
  1613.  
  1614. One more thing: Is it recommended that we use any of the low level "direct
  1615. i/o" in our programs or use evnt_keybd() to obtain input? Basically, how are
  1616. the low level input or keyboard input handled in the multitasking system? Will
  1617. programs have data overflow if the used raw "curses.h"-type i/o or do you have
  1618. some exceptions to this?
  1619.  
  1620.  
  1621. Thanks.. for reading this long message!
  1622.  ------------
  1623. Category 14,  Topic 34
  1624. Message 118       Fri Apr 17, 1992
  1625. DOUG.W [ICD RT]              at 07:46 EDT
  1626.  
  1627. ASX,
  1628.    Using your bounds checking technique can cause problems...  What happens if
  1629. the mouse is outside of the region when the redraw occurs, but the user moves
  1630. the mouse into the regions DURING the redraw?
  1631.  
  1632. --Doug
  1633.  
  1634.  ------------
  1635. Category 14,  Topic 34
  1636. Message 119       Sat Apr 18, 1992
  1637. M.ABDULKAREE [ASX]           at 00:38 EDT
  1638.  
  1639. You are correct and I am aware of the problem, however, that does not happen
  1640. often and when it does it can be cleaned up easily. But you can't fix the
  1641. flickering problem! You could write a VBL triggered draw routine which would
  1642. draw the mouse at the ending of VBL, or like the Mac does.
  1643.  
  1644.  
  1645. I consider the remote chances of the mouse invading the redraw region a remote
  1646. possibility. Given the alternative: mad flickering, I would take the chance.
  1647.  
  1648.  
  1649. Moreover, as I suggested, if Atari added an AES function which will return
  1650. TRUE if the mouse is within bounds, then putting that function in your redraw
  1651. function right after get_next_rect_list() will eliminate the possibility of
  1652. mouse droppings.
  1653.  
  1654.  
  1655. The current solution to the problem is to add some statistically sound
  1656. buffer/margin to the mx,my so that you decrease the chances.
  1657.  ------------
  1658. Category 14,  Topic 34
  1659. Message 120       Sat Apr 18, 1992
  1660. DITEK [David]                at 02:40 EDT
  1661.  
  1662. ASX -- Even adding a bounds intersecting routine would not work since the
  1663. mouse could still move before you are finished drawing. I had to write
  1664. functions to handle this not too long ago and the remote possibility you spoke
  1665. of isn't nearly as remote as you'd think. Mouse droppings were pretty
  1666. regular... :-)
  1667.  
  1668. The addition of a 'chicken factor' only decreases the chances. With people
  1669. using mouse accelerators, I still got droppings. The only way I could ever get
  1670. it to work reliably was...
  1671.  
  1672. 1 - Grab the GEM mouse movement vector
  1673.  
  1674. Whenever graphics had to be drawn ( VDI or otherwise )..
  1675.  
  1676. 2 - Lock the mouse
  1677.  3 - Test for bounds intersection and hide the mouse if re'qd
  1678.  4 - Draw the graphics
  1679.  5 - Unlock the mouse
  1680.  
  1681. While there are probably better ways, this method was GEM compliant and
  1682. resulted in no visible slow down in the redraw functions.
  1683.  
  1684.  
  1685.  
  1686.  ------------
  1687. Category 14,  Topic 34
  1688. Message 121       Sat Apr 18, 1992
  1689. CHERRY.FONTS [Todd]          at 09:31 EDT
  1690.  
  1691. David (Ditek),
  1692.   By "lock the mouse", do you mean in effect to nail it to its spot while
  1693. drawing the graphic? How compliant would that be to MultiTOS? (Or did I
  1694. misunderstand?)
  1695.  
  1696. ..Todd
  1697.  
  1698.  
  1699.  ------------
  1700. Category 14,  Topic 34
  1701. Message 122       Sat Apr 18, 1992
  1702. DITEK [David]                at 21:44 EDT
  1703.  
  1704. Todd (Cherry.Fonts)
  1705.  Yes, it means you zero out any movement that occurs during your drawing. By
  1706. treating each individual graphic ( i.e point, line, etc.. ) for testing rather
  1707. than attempting to draw a large block of graphics, ( one of the first mistakes
  1708. I made ) the mouse continues to be move smoothly.
  1709.  
  1710. Since it uses only GEM calls and doesn't affect any other programs why would
  1711. this method be 'non-compliant' ?
  1712.  
  1713. The absolute best solution of course would be for Atari to implement a low
  1714. level algorithm that would be transparent to all applications... ( I can dream
  1715. )
  1716.  
  1717.  ------------
  1718. Category 14,  Topic 34
  1719. Message 123       Sun Apr 19, 1992
  1720. M.ABDULKAREE [ASX]           at 16:17 EDT
  1721.  
  1722. Thanks David.. now I have to look up what the mouse movement vector
  1723. means<smile>. Steps 2 through 5 I can do.
  1724.  
  1725. 2. event_update(mcntrl)
  1726.  
  1727. 3. intersect()
  1728.  
  1729. 4. vro_cpyfm()
  1730.  
  1731. 5. event_mouse(endctrl)
  1732.  
  1733.  
  1734. Now do you mean that I should call vex_curv() or vex_motv() and do something
  1735. then?
  1736.  
  1737.  
  1738. Well.. I guess you are right about mouse trails <sigh> I was drawing a small
  1739. area so the chances were slim, but if I had several rectangles to redraw then
  1740. I can see how the mouse could very well move inside!
  1741.  
  1742.  
  1743. And Todd brought up my next concern.. if I locked the mouse, then the user
  1744. will not be able to complete what s/he was doing, for example moving a window
  1745. elsewhere while our program's window (background) was asked to redraw.
  1746.  
  1747.  
  1748. Sheesh.. it is getting messy awfully fast! That is exactly why I wanted a VBL
  1749. driven draw routine under AES/VDI! Makes life sooo much easier for both the
  1750. programmers and the user.
  1751.  
  1752.  
  1753. Well David, if we all "suggested" to Atari, then there may well be such a
  1754. routine! <pinch>
  1755.  ------------
  1756. Category 14,  Topic 34
  1757. Message 124       Tue Apr 21, 1992
  1758. JWC-OEO [Jon]                at 21:14 EDT
  1759.  
  1760.   Since I've seen the comments here about so called "dialogware" being less
  1761. than fully compatible with MultiTOS I've been keeping an eye out for it.
  1762. Well, I've got lots and lots of it.  It's likely that the vast majority of the
  1763. utilities that I might want to multitask under MultiTOS are dialogware.  While
  1764. I certainly would not want Atari to cripple MultiTOS in the attempt, I'd like
  1765. to urge them to find a way to get MulitTOS to deal with this type of program.
  1766. Maybe programs that don't open a window but are not really TOS programs could
  1767. be banished to a screen that would only show up when the user switched to it.
  1768. That would let them run and tie up their own screen waiting for input but
  1769. would keep the properly written GEM window programs free to do their stuff on
  1770. the "main" screen.  I don't know how feasable this is but I do think that
  1771. without something like this, MultiTOS is not going to be satisfactory as a
  1772. general use everyday operating system on many peoples systems.
  1773.  
  1774. Jon
  1775.  
  1776.  ------------
  1777. Category 14,  Topic 34
  1778. Message 125       Wed Apr 22, 1992
  1779. TOWNS [John@Atari]           at 14:36 EDT
  1780.  
  1781. Dialogware will work as long as they lock the screen using a wind_update call
  1782. before they bring up their Dialog and after the get rid of the Dialog.
  1783.  
  1784. Please note.. While this happens, you can't switch applications.. but your
  1785. Dialogware program will work just fine.
  1786.  
  1787. -- John Townsend, Atari Corp.
  1788.  
  1789.  ------------
  1790. Category 14,  Topic 34
  1791. Message 126       Wed Apr 22, 1992
  1792. J.ROY18 [Jonathan]           at 18:18 EDT
  1793.  
  1794. I'd like to see Dialogs pop up as they do now (ie: the come up no matter what)
  1795. but if they aren't responded to in say, a user-defineablt number of seconds,
  1796. the dialog will disappear. Then, when that program's window is topped, the
  1797. dialog will reappear. This would keep your computer running along fine even if
  1798. you went out the room and a dialog poped up. (Perhaps the window's could have
  1799. a dialog-flag somewhere.)
  1800.  
  1801. Also, since MultiTOS is being shown at shows now, could you load in a number
  1802. of programs, and snap-shot the screen in Degas format, then upload it for us
  1803. little people to drool over? I'd like to see some GEM programs loaded under
  1804. the ACC slot (With it's drop-down menu open, so we can see how they are
  1805. listed) and of course, some programs on the desktop. Maybe Calamus, Avant
  1806. Vector, and Didot Pro all running at once? (grin) Throw in a TOS program for
  1807. good measure.
  1808.  
  1809.  
  1810. Will MT use the same method (and same calls) for pipelining informatiom from
  1811. one process to another? (ie: Can I write MultiTOS friendly software before it
  1812. comes out by writing it for MiNT?)
  1813.  
  1814. --
  1815.  
  1816. More importantly, can a program "spawn" tasks that will automaticly be
  1817. multitasked by the OS? (Even open their own window perhaps) That'd be a _very_
  1818. cool feature... I'm pretty sure the Amiga OS does it, so I know someone must
  1819. have considered adding it. This could let WP's spawn a printing-child when you
  1820. print, so you don't need DA's or printer buffers. You just pass it to your
  1821. child-task, and it goes about it's merry way. Calamus and such could be really
  1822. cool like this. You hit "print" and it makes a child-task to do all the
  1823. printing functions, whereas Calamus itself is still totally usable. Hmmm...
  1824.  
  1825.  
  1826. (The above is Aladdin delayed a day, the following is new:)
  1827.  
  1828. If you have a dialog pop up, won't that suspend any GEM updating? (So, if you
  1829. have multiple windows open, all those processes will be suspended? What about
  1830. closed windows?)
  1831.  ------------
  1832. Category 14,  Topic 34
  1833. Message 127       Wed Apr 22, 1992
  1834. M.ABDULKAREE [ASX]           at 21:30 EDT
  1835.  
  1836. "Dialogware" or basically forms are NOT incompatible with AES or multitasking
  1837. TOS. John (and Bill R.) said that because if you put one up, say like
  1838. Aladdin's file Xfer dialog, then the user won't be able to do anything with
  1839. other applications (they may continue running in the background but all
  1840. drawing and menus will be halted.)
  1841.  
  1842.  
  1843. So.. the best thing is to put them up in a window, add a little more code to
  1844. your program and make the users happy! Otherwise you are taking away the
  1845. entire concept of multitasking (speaking generally.)
  1846.  
  1847.  
  1848. One advice would be to think as if you are the user and would like to be able
  1849. to get at other things as well. That is the way I see it..
  1850.  
  1851.  
  1852. There are of course cases where mouse locking is good: file/HD utilites, they
  1853. are sensitive applications and should not be disturbed. But I guess with a
  1854. little bit of modifications to GEMDOS, that consition can be removed.. I
  1855. guess.
  1856.  
  1857.  
  1858. And I don't think it is Atari's fault if you find that it won't be "worth it".
  1859. You can create the same situation under MacOS and Windows 3.. that is
  1860. something that the OS cannot circumvent.. in fact, like I pointed out there
  1861. are cases when the applicaiton needs to lock everything up.
  1862.  ------------
  1863. Category 14,  Topic 34
  1864. Message 128       Wed Apr 22, 1992
  1865. J.NESS [Jim]                 at 22:56 EDT
  1866.  
  1867. John Townsend -
  1868.  
  1869. Thanks for the additional info on how to handle dialogs in MultiTOS. Those of
  1870. us who are amateurs and don't have NDA access to info need SOME clue about
  1871. what changes may be necessary in our programs.
  1872.  
  1873. Anything you feel comfortable telling us, technique-wise, will be appreciated.
  1874.  
  1875.                                     -JN
  1876.  ------------
  1877. Category 14,  Topic 34
  1878. Message 129       Thu Apr 23, 1992
  1879. JWC-OEO [Jon]                at 00:04 EDT
  1880.  
  1881.   TOWNS,
  1882.   Thanks for the replay.  Too bad though.  So called dialogware formes a large
  1883. rich subset of ST utilities and other applications and while I'll do my best
  1884. to bring my own contributions to this field into line, I'm not going to hold
  1885. my breath waiting for an onslaught of updates from other sources.  Feel free
  1886. to come up with a better solution at the last minute.
  1887.  
  1888. Jon
  1889.  ------------
  1890. Category 14,  Topic 34
  1891. Message 130       Thu Apr 23, 1992
  1892. DOUG.W [ICD RT]              at 07:55 EDT
  1893.  
  1894. Atari really needs to follow that path that Microsoft (Windows), Apple (System
  1895. 7.0) and Commodore (Intuition) have created for handling modal dialogs.  Under
  1896. these GUIs, standard modal dialogs are only application-modal and not system-
  1897. modal.  While the modal dialog is on the screen, you can't do anything else
  1898. with that application, but you can still switch to other applications.
  1899.  
  1900. --Doug
  1901.  
  1902.  ------------
  1903. Category 14,  Topic 34
  1904. Message 132       Thu Apr 23, 1992
  1905. M.STUEVE [Marlo]             at 22:28 EDT
  1906.  
  1907.  Any way this works, lots of applications are going to be screwed up.
  1908.  Some applications save the dialog background as a raster. If anything
  1909.  happens in background applications in the meantime, the redraw will
  1910.  produce garbage. This may also be a problem with alert boxes, I don't
  1911.  know. (Not to mention menus.)
  1912.  
  1913.  I'd also like to know how conflicts over the desk window (handle 0)
  1914.  are going to be resolved. The best thing I can think of is for the
  1915.  desktop to put up and manage a fully-functional window for each
  1916.  application using window 0, and redirect all accesses to window 0
  1917.  into the new window. I don't like the Multi-GEM approach of having to
  1918.  select the program from the Desk menu in order to access the
  1919.  background. As a bonus, the desktop could put the program's menu bar
  1920.  in the info bar at the top of the window (ala Stalker and Steno). I
  1921.  know this is a lot to ask, but how hard could it possibly be?
  1922.  
  1923.  
  1924.  On a side note,
  1925.  Does anyone know what happened to the idea that we users were going
  1926.  to be able to ask Leonard Tramiel all sorts of questions, and his
  1927.  answers were going to be posted in Cat 14 Top 25? I sent him a whole
  1928.  bunch of Multi-TOS questions, and am hoping to get some answers. I'd
  1929.  also like to hear what everyone else asked.
  1930.  
  1931.  Marlo Stueve
  1932.  5th Crusade Software
  1933.  
  1934.  ------------
  1935. Category 14,  Topic 34
  1936. Message 133       Thu Apr 23, 1992
  1937. JEFF.W [ST Sysop]            at 23:14 EDT
  1938.  
  1939. Marlo,
  1940.  
  1941. I'm working with Atari to get the Leonard answers posted to Topic 25. I guess
  1942. with all the work and excitement going on at Atari, the answers had to take a
  1943. back seat for a while, but I understand they are almost ready, so we should
  1944. start seeing them soon.  I hope.  <smile>
  1945.  
  1946. Jeff
  1947.  
  1948.  ------------
  1949. Category 14,  Topic 34
  1950. Message 134       Fri Apr 24, 1992
  1951. JLS [John STanley]           at 03:10 EDT
  1952.  
  1953.   Towns,
  1954.  
  1955.   Has any thought been done about the possibility of modifying the wind_update
  1956. dialog-framing calls, form_draw, and form_do calls to force dialogs into a
  1957. window so dialogware would not lock out task swaping under multi-tos?  It
  1958. looks like this could easily be a major bottleneck to ease-of-use using older
  1959. (can't get upgrades anymore) software and it would seem to me that modifying
  1960. the system form_do to run dialogs in windows would be more practical than
  1961. trying to get everyone to re-invent the wheel for every program.
  1962.  
  1963.    ... JLS
  1964.  
  1965.  ------------
  1966. Category 14,  Topic 34
  1967. Message 137       Fri Apr 24, 1992
  1968. M.ABDULKAREE [ASX]           at 21:33 EDT
  1969.  
  1970. This is ticking me off.. I spent time reading my (meager) documentation trying
  1971. my very best to make software compatible with future versions. This includes
  1972. thinking about diablogs, windows, and line As. I started this even before
  1973. there was any leaks or etc. on MultiTOS!
  1974.  
  1975.  
  1976. I personally would not care if the older software expreienced problems! I
  1977. spent money on a machine so I can get increased speed and performance, not to
  1978. run some non-confromant or short-sighted programs. I spend money on those
  1979. programs whose developers show interest in the USER and compatibility.. not
  1980. just getting every cycle off the machine. The later is Atari OS teams job and
  1981. guys like Codeheads, not everybody.
  1982.  
  1983.  
  1984. So.. instead of complaining to the company (Apple, Atari or etc.) urge the
  1985. developers to write code that fits _your_ needs and also remains conformant.
  1986. Then, if Atari messes up, we can post suggestions.
  1987.  
  1988.  
  1989. The rest of the discussion about mapping dialogs into windows, changing low
  1990. level AES handlers.. that is okay and I support it. Constantly complaining
  1991. about EVERY damn thing gets us nowhere..
  1992.  ------------
  1993. Category 14,  Topic 34
  1994. Message 140       Sat Apr 25, 1992
  1995. TOWNS [John@Atari]           at 12:19 EDT
  1996.  
  1997. In response to a number of questions, comments from Developers.. I would like
  1998. to request that programming issues and questions from Developers be taken over
  1999. the to the Developer's Roundtable.
  2000.  
  2001. I am more than happy to answer what I can for users here.. but Developer's
  2002. should bring up their concerns to the Developer Support Staff in the Atari
  2003. Developer's RT.
  2004.  
  2005. -- John Townsend, Atari Corp.
  2006.  
  2007.  ------------
  2008. Category 14,  Topic 34
  2009. Message 142       Sat Apr 25, 1992
  2010. J.ROY18 [Jonathan]           at 16:22 EDT
  2011.  
  2012. Marlo,
  2013.    Maybe CodeHead will expand PopIt to work with MutliTos and "pop" open
  2014. installed GEM programs that aren't on the desktop. (grin)
  2015.  
  2016. TOWNS,
  2017.    So people who program, but aren't "developers", can't ask programming
  2018. questions? )^=
  2019.  ------------
  2020. Category 14,  Topic 34
  2021. Message 143       Mon Apr 27, 1992
  2022. M.ABDULKAREE [ASX]           at 00:50 EDT
  2023.  
  2024. It would be great if Atari allowed the use of an external program for the
  2025. "Show/Print.." feature. They could start us out by including the regular Show
  2026. Text/Binary File and print but in a window. And of course people like me (and
  2027. others) will _immediately_ buy the program to view the files, GIFs, TIF, IMG,
  2028. WP, etc.
  2029.  
  2030.  
  2031. And they can print via a system wide print manager!
  2032.  ------------
  2033. Category 14,  Topic 34
  2034. Message 144       Mon Apr 27, 1992
  2035. J.ROY18 [Jonathan]           at 04:11 EDT
  2036.  
  2037. You can already patch out the S/P/C code... I think there is a DC Viewer or DC
  2038. Shower that does that.
  2039.  
  2040. I guess there's no chance of someone uploading some MultiTOS screen shots?
  2041. There's no Atari shows down here in south Florida. )^=
  2042.  ------------
  2043. Category 14,  Topic 34
  2044. Message 145       Mon Apr 27, 1992
  2045. C.F.JOHNSON [CodeHead]       at 11:53 EDT
  2046.  
  2047.   There is no legal, documented way to replace the "Show/Print/Cancel" feature
  2048. of the desktop.  The program you mentioned, Jonathan, breaks just about every
  2049. ST programming rule.  I agree, it would be nice for Atari to provide a legal
  2050. hook for this function.
  2051.  
  2052. - Charles
  2053.  
  2054.  ------------
  2055. Category 14,  Topic 34
  2056. Message 146       Mon Apr 27, 1992
  2057. TOWNS [John@Atari]           at 12:27 EDT
  2058.  
  2059. ASX.. That's a good idea. And it is already under consideration. Who knows, it
  2060. might even make it's way into MultiTOS..
  2061.  
  2062. -- John
  2063.  
  2064.  ------------
  2065. Category 14,  Topic 34
  2066. Message 147       Mon Apr 27, 1992
  2067. J.EIDSVOOG1 [CodeHead]       at 19:05 EDT
  2068.  
  2069. It's even easier than that.  Even since TOS 1.0, the ability has existed to
  2070. replace the "Show/Print/Cancel" function with whatever program you like.  All
  2071. you need to do is modify your DESKTOP.INF (NEWDESK.INF) a little bit.  The
  2072. docs for our LookIt program tell you how to do this.  The advantages of this
  2073. method are that it is completely legal, does not take _any_ resident memory,
  2074. and has no compatibility problems whatsoever.
  2075.  
  2076.          John Eidsvoog  /|\  Member of the IAAD
  2077.  CodeHead Technologies  \|/  Serving the Atari Community
  2078.  ------------
  2079. Category 14,  Topic 34
  2080. Message 148       Mon Apr 27, 1992
  2081. J.ROY18 [Jonathan]           at 21:08 EDT
  2082.  
  2083. This is pretty funny. Charles says theres no legal way to do it, then John
  2084. says there IS a legal way to do it. (^= Personally, I'd like to see MultiTOS
  2085. support some type of background printing automaticly... (Which it probably
  2086. already has.)
  2087.  
  2088.  ------------
  2089. Category 14,  Topic 34
  2090. Message 149       Mon Apr 27, 1992
  2091. OUTRIDER [Terry @ T2]        at 22:06 EDT
  2092.  
  2093. Jonathan,
  2094.  
  2095. Charles and John are talking about two different things.  Charles was talking
  2096. about actually patching (intercepting) the S|P|C function, whereas John was
  2097. talking about bypassing it via the Install Application feature of TOS.  The
  2098. former is a no-no, while the latter is just dandy.  ;^)
  2099.  
  2100. Personally, I _legally_ replace the S|P|C function -- ah heck, the ENTIRE GEM
  2101. DESKTOP -- with the HotWire/MaxiFile combo.  :^)
  2102.  
  2103.                                   - Terry -
  2104.  
  2105.  ------------
  2106. Category 14,  Topic 34
  2107. Message 150       Mon Apr 27, 1992
  2108. C.F.JOHNSON [CodeHead]       at 22:39 EDT
  2109.  
  2110. Jonathan,
  2111.  
  2112.   John was referring to the "Install Application" method of viewing text
  2113. files; a very different thing than having an AUTO folder program that tries to
  2114. "intercept" the desktop's show function, as the program you mentioned does.
  2115. There is _no_ "hook" for a resident program to use in this way.
  2116.  
  2117.   However, you can install an application for _all_ unrecognized file types,
  2118. so that any time you double-click a data file that isn't already assigned to
  2119. some other application, a "default" application will start up and be passed
  2120. the name of the data file.  This will completely bypass the desktop's
  2121. "Show/Print..." function; the "Show/Print..." alert box will never even
  2122. appear.  The technique requires a manual modification to the DESKTOP.INF file;
  2123. there's no way to do it with the GEM desktop itself.
  2124.  
  2125. - Charles
  2126.  
  2127.  ------------
  2128. Category 14,  Topic 34
  2129. Message 151       Mon Apr 27, 1992
  2130. S.SCHAPER [Meneldil]         at 23:20 EDT
  2131.  
  2132. You mean that something like the two-column printer could be activated by
  2133. print, simply by doing something to the Desktop.INF file?
  2134.  ------------
  2135. Category 14,  Topic 34
  2136. Message 152       Mon Apr 27, 1992
  2137. J.ROY18 [Jonathan]           at 23:31 EDT
  2138.  
  2139. Would just putting a *.* in the Desktop.Inf file work?
  2140.  ------------
  2141. Category 14,  Topic 34
  2142. Message 153       Tue Apr 28, 1992
  2143. J.EIDSVOOG1 [CodeHead]       at 04:51 EDT
  2144.  
  2145. Meneldil,
  2146.  
  2147. Yes, you could install the two-column printer to be activated when you double-
  2148. click on an unknown file type, but it would be the only way you could "show" a
  2149. file.
  2150.  
  2151. Jonathan,
  2152.  
  2153. It's not _quite_ that simple, but almost.  I have the following entry in my
  2154. DESKTOP.INF (NEWDESK.INF) file:
  2155.  
  2156.  #G 03 04   C:\CODEHEAD\LOOKPOP\LOOKIT.PRG@ *.*@
  2157.  
  2158. This causes LookIt to be called every time I double-click on an unrecognized
  2159. extension.  But the trick is that this entry has to be located in the right
  2160. spot.  GEM searches the list from the bottom up so this entry has to be
  2161. _above_ all other installed applications, including the entries for *.PRG,
  2162. *.APP, *.TOS, and *.TTP.
  2163.  
  2164. John
  2165.  ------------
  2166. Category 14,  Topic 34
  2167. Message 154       Tue Apr 28, 1992
  2168. REALM [Joey]                 at 20:05 EDT
  2169.  
  2170.    Might be nice if when double-clicking on a file a dialogue would come up
  2171. with the programs that suppott it.  For instance when installing 5 different
  2172. programs to use TXT files the 5 would pop up in a button box and allow you to
  2173. chose the one you want.
  2174.  ------------
  2175. Category 14,  Topic 34
  2176. Message 155       Tue Apr 28, 1992
  2177. B.KING8 [Brien King]         at 20:28 EDT
  2178.  
  2179.  
  2180.  
  2181. I think what would be nicer would be the ability to assign ownership to a
  2182. file.  What I mean by this, is that if you have a program that creates TXT
  2183. files called STUFF.PRG and another program called THINGS.PRG then the OS could
  2184. determine which program created the file and then execute that program.  I
  2185. think the Mac has this feature.
  2186.  
  2187. Then you could change the directory to show this :
  2188.  
  2189. Name           Size    Date      Time     Owner
  2190.  
  2191. MYFILE.TXT     30,000  04/28/92  14:00    G:\UTILITIES\THINGS.PRG AFILE2.TXT
  2192. 15,434  04/28/92  01:33    F:\DODADS\STUFF.PRG
  2193.  
  2194.  
  2195. Just an idea...  The Owner list would have to be kept seperate from the rest
  2196. of the Disk format inorder to keep compatibility with IBM format.
  2197.  
  2198.                                                 Brien
  2199.  ------------
  2200. Category 14,  Topic 34
  2201. Message 156       Tue Apr 28, 1992
  2202. J.ROY18 [Jonathan]           at 21:28 EDT
  2203.  
  2204. Yeah, I knew about the bottom to top thing... Never thought of doing a *.*
  2205. line however...
  2206.  
  2207. Seems someone should write a S/P/C viewer that can display picture and all
  2208. those goodies like DC Showit (Was that the name? Ack!) but look exactly like
  2209. the normal S/P/C selector so it's completely "tranparent" to the user. Of
  2210. course, you'd want a RAM disk for it.... (^;
  2211.  
  2212.  
  2213. Realm,
  2214.   I've thought of that... One could make a program that is application
  2215. installable. Install it for *.*. Make a text file/data file for it listing the
  2216. extensions for each specific program. If you click on TXT for example, STeno,
  2217. EdHak, and WordPerfect might pop up in a little window, and you click on one.
  2218. You could have a default, and the other only open if you hold down ALT or
  2219. something when you double click... This is something I'd like to write, but
  2220. unfortuantly I'm nowhere near the level of skill needed for it yet. )^=
  2221.  ------------
  2222. Category 14,  Topic 34
  2223. Message 157       Tue Apr 28, 1992
  2224. M.ABDULKAREE [ASX]           at 21:46 EDT
  2225.  
  2226. Yess!!! <smile>
  2227.  
  2228.  
  2229. That is true John E.: but I don't want to have tons of extenders and several
  2230. programs when the fastest way could be the module feature built into TOS.
  2231.  
  2232.  
  2233. By the way, it would be great if TOS allowed more than one extension for each
  2234. application-- this would help a lot for integrated compilers, okay Pure C. But
  2235. art/image editing programs will benefit too!
  2236.  ------------
  2237. Category 14,  Topic 34
  2238. Message 158       Tue Apr 28, 1992
  2239. TOWNS [John@Atari]           at 23:07 EDT
  2240.  
  2241. You can do that now. Write a program that will take a number of inputs and
  2242. have it shell to the various programs after running it's shell.
  2243.  
  2244. -- John
  2245.  
  2246.  ------------
  2247. Category 14,  Topic 34
  2248. Message 159       Wed Apr 29, 1992
  2249. A.FASOLDT [Al Fasoldt]       at 01:05 EDT
  2250.  
  2251. John:
  2252.  
  2253. GEM searches from the bottom up??
  2254.  
  2255. Wow, what a helpful tip. Thanks.
  2256.  
  2257. Al
  2258.  
  2259.  ------------
  2260. Category 14,  Topic 34
  2261. Message 160       Wed Apr 29, 1992
  2262. CBARRON                      at 02:44 EDT
  2263.  
  2264.  Brien King - Re mac resource fork , FORGET IT I am glad I don't have that
  2265. problem with my ATARI's.  It is more of a problem than a solution.
  2266.  ------------
  2267. Category 14,  Topic 34
  2268. Message 161       Wed Apr 29, 1992
  2269. B.KING8 [Brien King]         at 20:22 EDT
  2270.  
  2271.   CBARRON -
  2272.  
  2273.         What is a "MAC resource fork"?
  2274.  ------------
  2275. Category 14,  Topic 34
  2276. Message 162       Wed Apr 29, 1992
  2277. C.TOWNSLEY [CHARLIE]         at 21:59 EDT
  2278.  
  2279. Brien a MAC resource fork is what you use to fix HD crashes. There is no need
  2280. to buy the high priced name brands, however. A common BBQ fork will easily
  2281. substitute.
  2282.  
  2283. For system crashes, there are two usefull tools. Those users who favor finesse
  2284. recomend a Katana while those with a more, shall we say, direct approach stand
  2285. by a twelve pound sledge. Users priviledge.
  2286.  
  2287. :-)
  2288.  
  2289.  Charlie Townsley
  2290.  ------------
  2291. Category 14,  Topic 34
  2292. Message 163       Wed Apr 29, 1992
  2293. M.DORMAN2 [Mike Dorman]      at 23:59 EDT
  2294.  
  2295. But seriously, folks...
  2296.  
  2297. It's an entry (or is it actually part of the file?) that allows the MAC to
  2298. "know" what program created what file.  It's a bit more sophisticated than
  2299. using the "Install Application" menu item (or hacking your desktop.inf), but
  2300. it has it's own set of problems.
  2301.  
  2302. That's part of why the MAC has all it's proprietary archiving software--
  2303. they've got to be able to preserve the resource fork (that's why I get the
  2304. impression it's an entry somewhere in the MAC equivalent of the FAT).
  2305.  
  2306. Mike.
  2307.  ------------
  2308. Category 14,  Topic 34
  2309. Message 164       Thu Apr 30, 1992
  2310. CBARRON                      at 02:33 EDT
  2311.  
  2312.  Re REsoure fork.. it is stored in stuffit as a separate entity. I would guess
  2313. it is sort of a 'super hidden' file in reality. Ask the gadgets folks, they
  2314. can probably tell you more than you want to know about resource forks!  It is
  2315. my understanding that every file created has a data fork(the actual file on
  2316. most systems) and a resource fork that takes care of the mac 'advanced'
  2317. install application methods among other things.
  2318.  ------------
  2319. Category 14,  Topic 34
  2320. Message 165       Thu Apr 30, 1992
  2321. DOUG.W [ICD RT]              at 07:50 EDT
  2322.  
  2323. All files on the Macintosh consist of two parts, the DATA fork and the
  2324. RESOURCE fork.  The data fork usually consists of raw text data and the
  2325. resource fork contains everything else including: program code, icons, dialog
  2326. boxes, sounds, fonts, menus, etc.
  2327.    Most applications have an empty data fork (since everything they use goes
  2328. in the resource fork) and most text files have an empty resource fork.
  2329.    The filetype and creator information (what kind of file it is and what
  2330. program "owns" it) is stored in the directory entry, not the file itself.
  2331.  
  2332. --Doug
  2333.  
  2334.  ------------
  2335. Category 14,  Topic 34
  2336. Message 166       Thu Apr 30, 1992
  2337. F.BELL1 [Frank @ Home]       at 15:38 EDT
  2338.  
  2339. ASX,
  2340.  
  2341.   >> [...] allowed more than one extension for each application [...]
  2342.  
  2343. You mean like my ARCSHELL example below (extract of Desktop.Inf /
  2344.                                          Newdesk.Inf file):
  2345.  
  2346.   [...]
  2347.   #W 00 00 06 01 34 09 00 @
  2348.   #P 03 04 000 C:\EDIT.PRG@ *.*@ @  <-- default program for all
  2349.                                         other files (replaces
  2350.                                         SHOW/PRINT/WHATEVER)
  2351.   #D FF 01 000 @ *.*@ @
  2352.   #G 03 FF 200 *.APP@ @ @
  2353.   #G 03 FF 000 *.PRG@ @ @
  2354.   #Y 03 FF 000 *.GTP@ @ @           <-- anybody know what this is?
  2355.   #P 03 FF 000 *.TTP@ @ @
  2356.   #F 03 04 000 *.TOS@ @ @
  2357.   #G 03 04 000 C:\U_ARCLZH\ARCSHELL.PRG@ *.ARC@ @ <-- call Arcshell
  2358.   #G 03 04 000 C:\U_ARCLZH\ARCSHELL.PRG@ *.LZH@ @ <-- call Arcshell
  2359.   #G 03 04 102 D:\FIDO\MODULE\BTS.PRG@ *.@ @
  2360.   #G 03 04 101 D:\ALADDIN\ALADDIN.PRG@ *.@ @
  2361.   [...]
  2362.  
  2363. Frank...
  2364.  
  2365.  
  2366.  
  2367.  ------------
  2368. Category 14,  Topic 34
  2369. Message 167       Thu Apr 30, 1992
  2370. J.EIDSVOOG1 [CodeHead]       at 20:52 EDT
  2371.  
  2372. Frank,
  2373.  
  2374. A GTP file is a "GEM Takes Parameters" file.  It is similar to a TTP program
  2375. in that a command line box will appear when you run it.  But the program will
  2376. run as a GEM program instead of a TOS program.  In other words, the screen
  2377. will appear with the standard desktop fill pattern instead of a white screen,
  2378. and the mouse will remain enabled.
  2379.  
  2380. John
  2381.  ------------
  2382. Category 14,  Topic 34
  2383. Message 168       Thu Apr 30, 1992
  2384. J.ROY18 [Jonathan]           at 21:24 EDT
  2385.  
  2386. I have my DESKTOP.INF also set to execute *.SFX file... (^=
  2387.  ------------
  2388. Category 14,  Topic 34
  2389. Message 169       Thu Apr 30, 1992
  2390. DOUG.W [ICD RT]              at 21:51 EDT
  2391.  
  2392. Frank,
  2393.    .GTP means "GEM Takes Parameters."  It's for GEM programs that can accept
  2394. command line arguments.  Note, though, that this only applies to TOS 2.0x and
  2395. above (i.e. NewDesk).
  2396.  
  2397. --Doug
  2398.  
  2399.  ------------
  2400. Category 14,  Topic 34
  2401. Message 170       Fri May 01, 1992
  2402. F.BELL1 [Frank @ Home]       at 01:10 EDT
  2403.  
  2404. John, Doug,
  2405.  
  2406. On my brand new Newdesk desktop I've noticed 'GEM Takes Para..." but have had
  2407. no idea, will sort'f, what is really meant and no idea on how to use it.
  2408. Thanks.  Ah, sorry about the topic drift.
  2409.  
  2410. Frank...
  2411.  
  2412.  ------------
  2413. Category 14,  Topic 34
  2414. Message 171       Fri May 01, 1992
  2415. TOWNS [John@Atari]           at 01:32 EDT
  2416.  
  2417. The .GTP extension is recognized by the new Desktop as a program that runs the
  2418. same as a .PRG gem program, but takes parameters on startup. Think of it as a
  2419. GEM "ttp" program. ;-)
  2420.  
  2421. -- John Townsend, Atari Corp.
  2422.  
  2423.  
  2424.  ------------
  2425. Category 14,  Topic 34
  2426. Message 172       Fri May 01, 1992
  2427. B.GOCKLEY [Brian G.]         at 08:30 EDT
  2428.  
  2429. Has anybody written one? I'd love to see a sample PD GTP, OK.
  2430.  
  2431. Brian D Gockley ST Informer
  2432.  ------------
  2433. Category 14,  Topic 34
  2434. Message 173       Fri May 01, 1992
  2435. J.EIDSVOOG1 [CodeHead]       at 12:18 EDT
  2436.  
  2437. There are plenty of GTPs.  I've been using them for years.  Any GEM program
  2438. that takes a command line is theoretically a GTP.  Some of the most common
  2439. ones are ArcShell and Calamus.  You can simulate a GTP in HotWire by simply
  2440. selecting "Command Line" for a GEM program entry.  This feature has been there
  2441. since the day HotWire was released over three years ago.  There's nothing
  2442. magical about a GTP. It was just a logical step for Atari to add this type to
  2443. TOS.
  2444.  
  2445. John
  2446.  ------------
  2447. Category 14,  Topic 34
  2448. Message 175       Fri May 01, 1992
  2449. E.KRIMEN [Ed Krimen]         at 21:08 EDT
  2450.  
  2451.  >I have my DESKTOP.INF also set to execute *.SFX file... (^=
  2452.  
  2453. One of things I used to do before I got MultiDesk was to have my DESKTOP.INF
  2454. set to execute *.AC? files.  Therefore, when I double clicked on something
  2455. like STeno or STalker, or any other desk accessory that could also be run as a
  2456. program, it would execute as an application.
  2457.  
  2458. Of course, if it wasn't one of those 'special' desk accessories,... :^)
  2459.  ------------
  2460. Category 14,  Topic 34
  2461. Message 176       Sat May 02, 1992
  2462. CBARRON                      at 04:15 EDT
  2463.  
  2464.  There is a gtp executer that works with install application so that double
  2465. clicking a gtp file executes it, by executing a small program that executes
  2466. the actual file... Just about any CLI that can execute GEM programs can
  2467. execute gtp's as well...
  2468.  ------------
  2469. Category 14,  Topic 34
  2470. Message 177       Sat May 02, 1992
  2471. J.ROY18 [Jonathan]           at 12:01 EDT
  2472.  
  2473. Well, read the AEO issue last night! Sounds great! I'm very happy to hear
  2474. MultiTOS supports all sorts of inter-process communication, and spawning off
  2475. child processes! I can see all sorts of uses for that in some of the ideas for
  2476. programs I have...
  2477.  
  2478. Can you set default priorities for individual programs? I guess could you have
  2479. a list of them someplace, or use a byte of the program's header... (There
  2480. isn't that much free space left, though, is there?)
  2481.  
  2482. I think it'd be neat to have things like ARC and LZH preset to lower
  2483. priorities than your "normal" settings for other programs. Say, you download a
  2484. few files, and while downloading more you start up LZH to extract them
  2485. quietly... (Grin)
  2486.  
  2487. Hey, now there's an idea for STalker! Auto-execution of LZH under MultiTOS to
  2488. extract files to folder, automagicly, after downloading them. Neat.
  2489.  ------------
  2490. Category 14,  Topic 34
  2491. Message 178       Sat May 02, 1992
  2492. A.FASOLDT [Al Fasoldt]       at 22:24 EDT
  2493.  
  2494. STWriter.prg is a GTP. Has been from the start.
  2495.  
  2496. Al
  2497.  
  2498.  ------------
  2499. Category 14,  Topic 34
  2500. Message 179       Sun May 03, 1992
  2501. S.JOHNSON10 [Steve]          at 00:31 EDT
  2502.  
  2503. So is anyone at Atari 'in the know' as to whether MultiTOS is also designed to
  2504. be able to multitask MIDI applications?  I asked before, but I think it was
  2505. John Townsend who said that he didn't know.  Is there anyone at Atari or a
  2506. developer who DOES know?
  2507.  ------------
  2508. Category 14,  Topic 34
  2509. Message 180       Sun May 03, 1992
  2510. M.ABDULKAREE [ASX]           at 16:27 EDT
  2511.  
  2512. What are the chances of implementing direct SCSI to FRAM loading of
  2513. programs/files an virtual memory in the next release of TT TOS? A lot of TT
  2514. owners will be primarily buying FRAM (I'm going to get one soon as
  2515. Multitasking TOS is out or I have the money) we don't want the overhead of
  2516. loading into regular RAM and then blitting to FRAM.
  2517.  
  2518.  
  2519. --
  2520.  
  2521.  
  2522. I'd think that one of Atari's concerns is making their system handle MIDI
  2523. applications without problems.. I hope.
  2524.  ------------
  2525. Category 14,  Topic 34
  2526. Message 181       Tue May 05, 1992
  2527. G.ANDERSON                   at 08:21 EDT
  2528.  
  2529. Will it be possible to run different resolutions in different windows under
  2530. the new Multitasking TOS or will it multitask only in a single resolution?
  2531.  
  2532. Gregg
  2533.  ------------
  2534. Category 14,  Topic 34
  2535. Message 182       Wed May 06, 1992
  2536. TOWNS [John@Atari]           at 02:14 EDT
  2537.  
  2538. It will only multitask in the resolution you are in. This is just _one_ of the
  2539. reasons I beg programmers to make their software work in all possible modes.
  2540.  
  2541. --- John
  2542.  
  2543.  ------------
  2544. Category 14,  Topic 34
  2545. Message 183       Wed May 06, 1992
  2546. J.ROY18 [Jonathan]           at 19:51 EDT
  2547.  
  2548. I'd like to see MultiTOS have a built in "virtual" screen... Something like
  2549. MonSTEr so you can scroll the screen around, to run programs that need a
  2550. higher res than you normally have. (^=
  2551.  ------------
  2552. Category 14,  Topic 34
  2553. Message 184       Wed May 06, 1992
  2554. B.KING8 [Brien King]         at 20:40 EDT
  2555.  
  2556.  
  2557.  
  2558. Towns -
  2559.  
  2560.         I'll make my programs REZ independent if Atari makes Colors ReZ
  2561. independent.  I.E. If I want 256 colors in 320x200, 640x400, 640x480, etc..
  2562. then I can have it.  Some of the software I want to do requires 16 or more
  2563. colors on the screen at a time.  BTW: Memory is NO OBJECT to me.
  2564.  
  2565.                                                     Brien
  2566.  ------------
  2567. Category 14,  Topic 34
  2568. Message 185       Wed May 06, 1992
  2569. M.ABDULKAREE [ASX]           at 21:31 EDT
  2570.  
  2571. Yeah, all resolutions except the damn crummy and prehistoric ST LOW, ST
  2572. MEDIUM, TT LOW (yeah, what a joke!). Everything else I support. Mono and hi.
  2573. res color and 1:1 ratio modes.
  2574.  
  2575.  
  2576. And yes, I'd automatically expect you implement virtual screen (at least on
  2577. the TT and set form_center() to map to physical screen size) with the hardware
  2578. scroll features!
  2579.  
  2580.  
  2581. And yes, why do we have to go through the painful process of interleaving bits
  2582. around? Why not use a byte-scheme for encoding pixels and enhance VDI to
  2583. support 24/32 bit color.
  2584.  
  2585.  
  2586. Otherwise, your statement only applies to resolutions (the ST mono and TT mono
  2587. are redundant, as are the ST Low and TT Medium). And from what we know, the
  2588. next resolution you come out with, we will have to scramble or painstakingly
  2589. rewrite/update to support it!
  2590.  
  2591.  
  2592. This has really gone too far; I agree with Brien, memory is no object.
  2593.  ------------
  2594. Category 14,  Topic 34
  2595. Message 186       Wed May 06, 1992
  2596. S.SANDERS2 [SDS]             at 22:19 EDT
  2597.  
  2598. I think making a computer REZ independant would be pretty difficult, plus
  2599. Atari wants to make sure their OS's are backwardly compatible. It _would_ be
  2600. nice if an indepenant bitmap call would be included in the VDI (one that
  2601. worked on the screen, had scaling, color dithering, and could work from an
  2602. image in memory) ala MS Windows.
  2603.  
  2604. -Scott @ SDS
  2605.  ------------
  2606. Category 14,  Topic 34
  2607. Message 187       Thu May 07, 1992
  2608. TOWNS [John@Atari]           at 13:11 EDT
  2609.  
  2610. If you need a certain number of colors, then you should check the number of
  2611. colors on startup and they decide if you can use this resolution. If you can,
  2612. then run it in. If not, inform the user that you need a resolution with X
  2613. number of colors.
  2614.  
  2615. Is that so hard?
  2616.  
  2617. -- John
  2618.  
  2619.  ------------
  2620. Category 14,  Topic 34
  2621. Message 188       Thu May 07, 1992
  2622. DENNYA [Denny Atkin]         at 14:23 EDT
  2623.  
  2624. Isn't there any provision under MultiTos to change resolutions under software
  2625. control? ("I need to run in 640x200. Change screen mode if no other programs
  2626. onscreen, else inform user.")
  2627.  
  2628.  ------------
  2629. Category 14,  Topic 34
  2630. Message 189       Thu May 07, 1992
  2631. R.GLOVER3 [Rob]              at 18:55 EDT
  2632.  
  2633.   Towns:
  2634.  
  2635. A few strange questions here... when MultiTOS is finally released, will the
  2636. disk part of the package be a single TOS.IMG-type file, or multiple utility
  2637. files?  Will it be fast enough to get reasonable use out of a normal ST (8 or
  2638. 16 MHz)?  How far is there to go (in pre-production phase) before it becomes
  2639. really stable?  And finally, is there any chance Atari would release a Beta
  2640. version to the public for testing, or is that honor reserved for registered
  2641. developers?
  2642.  
  2643. Rob
  2644.  
  2645.  ------------
  2646. Category 14,  Topic 34
  2647. Message 190       Thu May 07, 1992
  2648. S.SCHAPER [Meneldil]         at 20:28 EDT
  2649.  
  2650. Ah, but can you run a resolution emulator in one window?
  2651.  
  2652. Brien, Have you thought about grey-scaling? AIM has 256 shades of grey on
  2653. monochrome, and JLS's StarSaver has 1200.
  2654.  ------------
  2655. Category 14,  Topic 34
  2656. Message 191       Fri May 08, 1992
  2657. M.ABDULKAREE [ASX]           at 01:08 EDT
  2658.  
  2659. Telling the resolution and colors available is abosolutely not difficult. Just
  2660. the fact that we have to mess around with various transformations just to put
  2661. a pixel on the screen (in color resolution) from a file (IMG, PCX, TIF, etc.)
  2662.  
  2663.  
  2664. MultiTOS on disk? OH MAN.. think about pirates. Unless Atari really wants to
  2665. give it away, which is a good gesture but not likely, then ROMS are the best
  2666. choice. I'd think they will have it on ROM at least for the TT (which have the
  2667. address space) and not sure about the rest of the machines.
  2668.  
  2669.  
  2670. Plus loading from disk opens up the pirate market and is also open to run-time
  2671. corruption from "rogue processes"!
  2672.  
  2673.  
  2674. By the way, in the latest Atari Explorer Online (the first issue) the article
  2675. on Multitasking AES/TOS has Bill Rehbock saying that TOS, TTP, applications
  2676. will run in a window. Does this mean that the VDI terminal emulation functions
  2677. are mapped on to the window? v_clreol(), v_cur_home(), etc. And does AES
  2678. automatically detect whether the applications need to be placed in this
  2679. window, even if their extension says PRG but they don't even use any AES/VDI
  2680. functions? How about line-A driven programs ( not that I care, but just for
  2681. completeness).
  2682.  
  2683.  
  2684. Also, how are system errors handled? Say, if I'm messingaround with pointers
  2685. in Pure C and making Aladdin get messages.. well, I get BUSsed.. now perhaps
  2686. the machine may not fold (the current TOS simply quits to the parent process
  2687. and Pure C is damn good at trapping everything so far.) Basically, will TOS
  2688. still write the bombs on the screen and just leave it at that (potentially
  2689. messing up backgrounds) or just draw the bombs, wait a sec, and issue a global
  2690. refresh. Or, the better alternative: put the error in a new alert with a bomb
  2691. icon and allow the user to acknowledge it.. and then issue a area redraw or
  2692. whatever.
  2693.  ------------
  2694. Category 14,  Topic 34
  2695. Message 192       Fri May 08, 1992
  2696. S.JOHNSON10 [Steve]          at 01:29 EDT
  2697.  
  2698. S.SANDERS2 - Right.  Making SOFTWARE resolution independent is much simpler
  2699. than HARDWARE.  The way Atari (TOWNS) suggests it is about the same as Apple
  2700. does for the Mac's (i.e. make resolution/bit-depth the choice of the user and
  2701. NOT 'hardwire' software to specifics).
  2702.  ------------
  2703. Category 14,  Topic 34
  2704. Message 193       Fri May 08, 1992
  2705. J.ROY18 [Jonathan]           at 02:34 EDT
  2706.  
  2707. I'd guess MT will have lots of utility programs since MiNT has a whole slew of
  2708. them...
  2709.  ------------
  2710. Category 14,  Topic 34
  2711. Message 194       Fri May 08, 1992
  2712. G.T.GRAY [Gary Gray]         at 17:55 EDT
  2713.  
  2714. An even better MulitTos question than can you run a resolution emulator in one
  2715. window would be, can you run a 386sx emulator in one window? I know just
  2716. having fun here guys. After all we are just speculating right:-).
  2717.  
  2718.  ------------
  2719. Category 14,  Topic 34
  2720. Message 195       Fri May 08, 1992
  2721. S.SCHAPER [Meneldil]         at 20:34 EDT
  2722.  
  2723. Well, the _best_ way, IMHO, is releasing OS's on pass-through carts. But if I
  2724. understood correctly, at one point, and this may have changed, Atari's idea
  2725. was to release it to the entire community for free or nearly so. You would
  2726. still need the TOS ROM's, but the enhanced MiNT TOS extensions would go on
  2727. disk. The only problem with that is viruses. But at that point they wanted to
  2728. make it the new standard for all machines. So making it easily available was
  2729. the idea.
  2730.  
  2731.  
  2732. At one point someone from Atari asked in an oblique fashion on a public net if
  2733. people would like DOS emulation built in, for example, some suggested, a slot
  2734. for a 486. The answer is YES.  Even better if it ran in a window. . . But
  2735. perhaps only UNIX can do that.
  2736.  ------------
  2737. Category 14,  Topic 34
  2738. Message 196       Fri May 08, 1992
  2739. S.SANDERS2 [SDS]             at 21:56 EDT
  2740.  
  2741. M.ABDULKAREE:
  2742.  
  2743. For displaying any monochrome bitmap on a color screen just use vrt_cpyfrm().
  2744.  
  2745. -Scott @ SDS
  2746.  
  2747.  ------------
  2748. Category 14,  Topic 34
  2749. Message 197       Fri May 08, 1992
  2750. M.ABDULKAREE [ASX]           at 23:57 EDT
  2751.  
  2752. Why in the world would Atari want people to use IBM emulators?! They are
  2753. investing a lot of time into Multitasking AES and related stuff.
  2754.  
  2755.  
  2756. Third party, perhaps but from Atari?! This would indicate that they are
  2757. abandoning TOS (which is not true, so far.)
  2758.  ------------
  2759. Category 14,  Topic 34
  2760. Message 198       Sat May 09, 1992
  2761. S.JOHNSON10 [Steve]          at 01:06 EDT
  2762.  
  2763. TOWNS - I get annoyed NOW with programs that just refuse to run in certain
  2764. resolutions (i.e. they don't even tell the user it can't run in the current
  2765. resolution). <grin>
  2766.  
  2767.  
  2768. R.GLOVER3 - From what I've heard, if Atari DOES decide to 'let' it run on
  2769. 68000 machines, you should have an absolute minimum of a 16MHz machine.
  2770.  
  2771.  
  2772. M.ABDULKAREE - The way it's worded in AEO, it sounded like MultiTOS might only
  2773. be part ROM and part disk for current machines (i.e. it COULD be all in ROM in
  2774. their newer machines).
  2775.  ------------
  2776. Category 14,  Topic 34
  2777. Message 199       Sat May 09, 1992
  2778. G.T.GRAY [Gary Gray]         at 14:49 EDT
  2779.  
  2780. It has been reported several times in the European press and elsewhere that
  2781. Sack the German developers of AT-Speed were working with Atari to develop DOS
  2782. emulations as original equipment. PC emulation on the ST family machines is
  2783. quite well understood. Unfortunately there have been 3 main problems.
  2784.  
  2785. (1) No proper installation. A processor direct slot on new machines, would
  2786. allow a reliable end user installation.
  2787.  
  2788. (2) Limited video capability. Rumours of Falcon's 16 bit color with a pallette
  2789. of 262,000 colors is the same as many modern SVGA cards. This would allow
  2790. SuperVga DOS emulation. I also read reports of a blitter on these machines, a
  2791. good fast blitter aid screen speed could also help an emulator run VGA well.
  2792.  
  2793. (3) Price performance. DOS emulators on the ST have always suffered from being
  2794. to slow at to high a price. Atari's quantities make the board inexpensive to
  2795. manufacture. Recent drastic price drops on SX386 parts also help. Finally new
  2796. processors like the Cyrix 486SLC offer 486 performance in a 386SX package, at
  2797. prices close to a hundred dollars a chip. These parts will be fifty bucks each
  2798. in 6 months. Atari could therefore offer 486 level emulation cards for $299
  2799. retail.
  2800.  
  2801.  
  2802. There are other reported features of the new machines that also make emulation
  2803. easier and more attractive. The new machines have IDE hard disks internal.
  2804. Reports of a more standard printer port design, could help with compatability
  2805. issues. But the most interesting would be MultiTos. DOS emulation in a Window
  2806. under MultiTos would be big plus.
  2807.  
  2808. Why would Atari bother with PC emulation in the first place? Because properly
  2809. done it would sell a lot of machines. The Amiga offers factory PC emulation,
  2810. and it sells machines for them. I suppose also that Atari would like a box
  2811. that they can sell of the shelf at ComputerCity or CompUSA type of stores.
  2812. Excellent PC emulation would make the product much more saleable in those
  2813. stores.
  2814.  
  2815.  
  2816.  
  2817.  ------------
  2818. Category 14,  Topic 34
  2819. Message 200       Sat May 09, 1992
  2820. J.ROY18 [Jonathan]           at 19:17 EDT
  2821.  
  2822. Hey... Wouldn't it be possible to release MultiTOS on a cartridge? Possibly
  2823. with a battery-backed up RAM chip, to keep "patch" info on. (^= You could, of
  2824. course, load info into the patch-ram from disk..
  2825.  
  2826. A silly idea, I know, but someone has to say it!
  2827.  ------------
  2828. Category 14,  Topic 34
  2829. Message 201       Sun May 10, 1992
  2830. G.ANDERSON                   at 01:34 EDT
  2831.  
  2832. I, for one, would be interested in a $300 386/486 plug-in DOS emulator for my
  2833. system.  Why?  For only two reasons. First is that the AirForce FORCES
  2834. everyone to use DOS machines in everything but high-level graphics and so-on
  2835. applications and I'd like to be able to 'take work home with me' now and then
  2836. without having to convert everything to ASCII all the time. Second is to get
  2837. access to all those nifty DOS games that may never be converted to an Atari
  2838. format...  Funny, isn't it?  We're called a 'games machine' by all those smug
  2839. DOS owners yet there are more games available for DOS than ST/TT/Amiga/MAC
  2840. combined.... by a LARGE margin.
  2841.  
  2842. Needless to say, I'd buy the Atari-specific version of ANY program if  given
  2843. the choice between DOS and Atari versions.
  2844.  
  2845. By the way, how did this subject work it's way into the MultiTOS topic? Ah
  2846. well, I at least mentioned it so the infamious Topic Police should be happy
  2847. <grin>......
  2848.  
  2849. Gregg
  2850.  ------------
  2851. Category 14,  Topic 34
  2852. Message 202       Sun May 10, 1992
  2853. J.ZORZIN [Joe]               at 09:40 EDT
  2854.  
  2855. Well, when MT finally becomes available I hope the cost of Moniterm type
  2856. monitors comes down.  What good is all this power on our dinky little screens?
  2857.  
  2858.  ------------
  2859. Category 14,  Topic 34
  2860. Message 203       Sun May 10, 1992
  2861. TOWNS [John@Atari]           at 12:18 EDT
  2862.  
  2863. Denny.. There are provisions under MultiTOS to change resolutions. MultiTOS
  2864. will not allow you to change resolutions until all programs have been
  2865. terminated, however.
  2866.  
  2867.  
  2868. Rob.. The distribution of MultiTOS has yet to be decided. As for release of
  2869. Beta software to the public, Atari has never done this with TOS and it is
  2870. unlikely that we will begin now. As for scheduling, I am not sure when a
  2871. release of MultiTOS will take place.
  2872.  
  2873. Meneldil.. There is not resolution emulator in a window. Sorry.
  2874.  
  2875.  
  2876.  ------------
  2877. Category 14,  Topic 34
  2878. Message 204       Sun May 10, 1992
  2879. M.STUEVE [Marlo]             at 19:04 EDT
  2880.  
  2881.  Yeah, MultiTOS on cart. I can just see it now. Custom designed pass
  2882.  through for other cartridges, battery backed up RAM on board, memory
  2883.  paging of some kind to get past the 128K/cartridge address space,
  2884.  ROMs executing at cartridge-bus speeds, modified cart for the
  2885.  non-standard notebook port, possible replacement power supply for the
  2886.  additional power a cart would draw, technical hassles from dirty edge
  2887.  connectors, TOS patch for 2.0x telling it to actually load something
  2888.  from the cartridge port, etc, etc.
  2889.  
  2890.  This IS a silly idea. It wouldn't work. Lets forget about it.
  2891.  
  2892.  ------------
  2893. Category 14,  Topic 34
  2894. Message 206       Mon May 11, 1992
  2895. S.SANDERS2 [SDS]             at 03:46 EDT
  2896.  
  2897. Actually, as I understand it TOS now is around 192k and the external cartridge
  2898. slot only adresses 128k.
  2899.  
  2900. -Scott @ SDS
  2901.  ------------
  2902. Category 14,  Topic 34
  2903. Message 207       Mon May 11, 1992
  2904. F.BELL1 [Frank @ Home]       at 18:46 EDT
  2905.  
  2906. Steve,
  2907.  
  2908. Why in the world would you want to limit MultiTos to 16Mhz machines? The next
  2909. question - only Atari's 16Mhz machines?  or can Jim Allen, Dave Small, ICD
  2910. etc. get on too?
  2911.  
  2912. Your 1000% correct about programs that don't inform their users about what
  2913. resolution they run in.
  2914.  
  2915. Frank...
  2916.  ------------
  2917. Category 14,  Topic 34
  2918. Message 208       Tue May 12, 1992
  2919. M.ABDULKAREE [ASX]           at 04:17 EDT
  2920.  
  2921. TOS is much larger than 192K.. The TT TOS is around the 512K (definitely over
  2922. 256K.)
  2923.  
  2924.  
  2925. So.. why not put the multitasking kernel into ROMs too?
  2926.  
  2927.  
  2928. I was thinking.. _if_ Multitaskting TOS/AES package comes with a buncha
  2929. utilities (not all of them CPX) would you like to have the user associate a
  2930. folder for placing all SYS, CFG etc. files into? This would REALLY help some
  2931. of use manage the C: partition. I keep my C: only for programs/files that NEED
  2932. to be there (AUTO, ACC) but others can be relocated elsewhere but noone offers
  2933. the choice.
  2934.  
  2935.  
  2936. Also, it would be great if the desktop automatically loaded the relevant INF
  2937. file to the resolution. NEWDESK1 for LOW, NEWDESK2 for MEDIUM, NEWDESK3 for ST
  2938. HIGH, etc..
  2939.  
  2940.  
  2941. Also, the Show Information dialog can be made more useful by adding HD spefic
  2942. information (when applicable). For example, I'd like to know which HD
  2943. partition belongs to which SCSI, where is it hooked up? ACSI, SCSI, it's
  2944. status, other info.
  2945.  
  2946.  
  2947. HDX displays some of this information at boot up, but do I really have to
  2948. bootup everytime I need to remember which disk is what? This becomes more
  2949. important for removebale and CD media.
  2950.  
  2951.  
  2952. How about including the VOLUME name in the window as well as the amount of
  2953. free space? You could use a custom status bar and smaller fonts (beginning to
  2954. sound like the way Mac does.)
  2955.  
  2956.  
  2957. Also, how about an AES function to obtain the current disk VOLUME name..
  2958. helpful for floppies, CD, and removeable HDisks. Or.. perhaps there is another
  2959. way of handling it?
  2960.  ------------
  2961. Category 14,  Topic 34
  2962. Message 209       Tue May 12, 1992
  2963. J.ZORZIN [Joe]               at 06:29 EDT
  2964.  
  2965. But John, wouldn't this be a good time to change Atari policy of not having
  2966. the public (by that I mean trusted ST developers) find the inevitable bugs in
  2967. MultiTos?  Or by public did you mean "mass distribution."
  2968.  
  2969.  ------------
  2970. Category 14,  Topic 34
  2971. Message 210       Tue May 12, 1992
  2972. DOUG.W [ICD RT]              at 07:39 EDT
  2973.  
  2974. ASX,
  2975.    I already use a 'SYSTEM' folder for my AUTO programs, ACCs, MDXs, CPXs,
  2976. GDOS fonts & drivers, MetaDOS drivers, etc.  It really cleans up drive C.
  2977.  
  2978. --Doug
  2979.  
  2980.  ------------
  2981.