home *** CD-ROM | disk | FTP | other *** search
/ No Fragments Archive 12: Textmags & Docs / nf_archive_12.iso / MAGS / TEXTMAGS / ATARI16 / INFO89.ZIP / INFO89 / 402.TXT < prev    next >
Text File  |  1997-04-16  |  17KB  |  414 lines
  1. Info-Atari16 Digest   Tuesday, August 22, 1989   Volume 89 : Issue 402
  2.  
  3. This weeks Editor: Bill Westfield
  4.  
  5. Today's Topics:
  6.  
  7.                       Re: Multitasking on the ST
  8.           QINDEX15 measurents : QuickST 1.46 vs TurboST 1.2
  9.                        Re: Apathy and Defeatism
  10.                         Re: Loyal Atarians?!?
  11.                       Re: Multitasking on the ST
  12.                              Re: C.E.K.A.
  13.                               X windows
  14.                            modedit file(s)
  15.                          Screen flicker, top
  16.                       Re: Multitasking on the ST
  17.                    User needed near New Britain, CT
  18.                              RAM Upgrades
  19.  
  20. ----------------------------------------------------------------------
  21.  
  22. Date: 14 Aug 89 04:29:46 GMT
  23. From: cwjcc!dsrgsun.ces.cwru.edu@g.ms.uky.edu  (Jwahar R. Bammi)
  24. Subject: Re: Multitasking on the ST
  25. To: info-atari16@score.stanford.edu
  26.  
  27. In article <89081310545051@masnet.uucp>, david.megginson@canremote (DAVID
  28.  MEGGINSON) writes:
  29. >From what I've heard, Minix is very restrictive with memory.  Each
  30. >program is allowed a maximum of 64k, and there is not VM paging.  A cute
  31. >toy, but useless for anything but learning.
  32. >---
  33.     The restriction on memory is only on the Ibm-Pc version of minix.
  34. In ST-minix there is no such restriction. Its true that there is no
  35. virtual memory.
  36.     IMHO it is a little bit more than a cute toy.
  37. --
  38. bang:   any internet host!dsrgsun.ces.CWRU.edu!bammi    jwahar r. bammi
  39. domain: bammi@dsrgsun.ces.CWRU.edu
  40. GEnie:    J.Bammi
  41.  
  42. ------------------------------
  43.  
  44. Date:     Mon, 14 Aug 89 11:28 N
  45. From:     <KRUYSBER%HNYKUN53.BITNET@Forsythe.Stanford.EDU>
  46. Subject:  QINDEX15 measurents : QuickST 1.46 vs TurboST 1.2
  47. To:       info-atari16@score.stanford.edu
  48. X-Original-To:  info-atari16@score.stanford.edu, KRUYSBERGEN
  49.  
  50. To complete the QINDEX15 measurements I've compared QuickST 1.46 and
  51. TurboST 1.2.
  52.  
  53. These two only affect the BIOS operations, so I'll give you these
  54. results only.
  55.  
  56. All measures were done with a 1040ST with no accessories or AUTO folder
  57. programs (except QSTAUTO.PRG...)
  58.  
  59.                                 Normal          QuickST         TurboST
  60. BIOS character output             99              150             312
  61. BIOS string output                99              578             725
  62. BIOS text scrolling               99              175             178
  63. GEM resource drawing              99              167             125
  64.  
  65. Psychological data: a difference between 578-725 is not 3.5 times the
  66. difference between 167-125! The ratio 725/578 = 1.25 and 167/125 = 1.31,
  67. so these differences are about the same. 578 is however 5.78 as fast as
  68. a normal 1040ST! The difference 167-125 is very noticeable. GEM resources
  69. are drawn much quicker. This favours QuickST. The difference 578-725 is
  70. pure mathematical, since the increase in speed of 578% in the QuickST
  71. case is already striking enough! Another increase up to 725 is merely
  72. 'for the record': this is hardly noticable in reality.
  73.  
  74. Conclusion: the measures indicate a better BIOS text handling by TurboST
  75. and a better GEM resource handling by QuickST. These measures however
  76. have to be seen in the light of the human, indicating that QuickST is
  77. (in the comparison of these two versions) preferable.
  78.  
  79. I'm not in the possession of QuickST 1.5 (witch should even be faster),
  80. nor am I in the possession of TurboST 1.6 (yet?). The new TurboST should
  81. handle GEM drawing much better one promissed to me...
  82.  
  83. Noud van Kruysbergen
  84. N.I.C.I.
  85. Mail Box 9104
  86. 6500 HE Nijmegen
  87. The Netherlands
  88. kruysbergen@hnykun53
  89.  
  90. P.S. I haven't done any QINDEX15 testing using cache programs, since these
  91. programs keep the last information used in RAM. Reading the same infor-
  92. mation 64 times increases the QINDEX measure considerable, but this is
  93. not real! You'll never read the same information more than once normally,
  94. so unless your cache memory is rather big you'll never reach this measure
  95. in practice! Using a cache with these kind of measurements is one of
  96. the pitfalls I mentioned the first time.
  97.  
  98. ------------------------------
  99.  
  100. Date: 14 Aug 89 01:00:39 GMT
  101. From: portal!cup.portal.com!Xorg@uunet.uu.net  (Peter Ted Szymonik)
  102. Subject: Re: Apathy and Defeatism
  103. To: info-atari16@score.stanford.edu
  104.  
  105. Hi Scott, although I completely agree with most of what you wrote, one
  106. falining among most people who bad-mouth the ST is not recognizing that
  107. unlike the Apple or MS-DOS machines, the ST was sold internationally and
  108. like it or not, the United States was never tapped as the major market
  109. for the ST.  Yes, Atari has been brain-dead when it comes to the U.S>
  110. market, but that may well have been on purpose - going after and
  111. against MS-DOS and MAC's with the multi-BILLION dollar war-chests
  112. would hardly have been a wise business decision on the aprt of Atari.
  113. Atari's strategy HAS also worked by the way - financially the company is
  114. very strong and solid and 400 on the Fortune 500 list - far from an
  115. easy achievement for a compnay that appeared a mere four years ago!
  116.  
  117. ------------------------------
  118.  
  119. Date: 14 Aug 89 09:01:49 GMT
  120. From: amdahl!pacbell!pbhya!dbsuther@ames.arc.nasa.gov  (Daniel B. Suthers)
  121. Subject: Re: Loyal Atarians?!?
  122. To: info-atari16@score.stanford.edu
  123.  
  124. The Question;  Why are Atari users so fanatical/loyal?
  125.  
  126. The ST was the best machine available at the time;  Cheap, fast, capable.
  127.  
  128. It is still fast and capable.
  129.  
  130. Most of the software has been written from scratch, and takes the hardware
  131. into account.  This makes for some VERY good programs.
  132.  
  133. The IBM and MAC programs I have to work with generally are barely usable or
  134. badly over-priced.  I would hate to have to put up with them at home.
  135.  
  136. The built in interfaces mean that most programmers can devote time to the
  137. programing, not on getting it to work with all 10,000 variations of
  138. dos/memory/hardware/TSRs.
  139.  
  140. The development environments are close enough the UNIX environment that
  141. I can port code to my ST, and back to the Mini I use at work.  This saves
  142. me development time.
  143.  
  144. I'd rather have a 3B4000, but can't aford the power bill. :-)
  145.  
  146. Dan
  147.  
  148. ------------------------------
  149.  
  150. Date: 14 Aug 89 08:10:39 GMT
  151. From: amdahl!pacbell!pbhya!dbsuther@ames.arc.nasa.gov  (Daniel B. Suthers)
  152. Subject: Re: Multitasking on the ST
  153. To: info-atari16@score.stanford.edu
  154.  
  155. In article <63138@linus.UUCP> rachamp@mbunix (Champeaux) writes:
  156. >From The Amiga ROM Kernel manual:
  157. >
  158. >   Every task has an assigned priority and tasks are scheduled to use the
  159. >   processor on a priority basis.  The highest priority ready task is selected
  160. >   and receives processing until:
  161. >
  162. [TEXT DELETED]
  163. >   Task scheduling is preemptive in nature.  The running task may lose the
  164. >   processor at nearly any moment by being displaced by another more urgent
  165. >   task.  Later, when the preempted task regains the processor, it continues
  166. >   where it left off.
  167. >
  168. >When a higher priority task becomes active, the running task is immediately
  169. >interrupted.
  170.  
  171. After reading this a question popped into my head.  If you are downloading in
  172. the back ground (it seems the most popular multi-task task) and running a
  173. action game in the foreground,  do you set the download process to the
  174. highest priority to avoid losing data or do you just put up with longer
  175. download times and connect times so your joy-stick will be responsive?
  176.  
  177. While I'm at it...
  178. What is a "ray trace" that most amiga users seem to want to generate them, and
  179. are willing to wait 2 or 3 days for the output???  The ray traces I've done
  180. have always completed over-night, and that's longer than I wish to wait for
  181. a pretty drawing.
  182.  
  183. My idea of great uses for multi-tasking agrees with the UNIX system.  Utilities
  184. such as UUCP, LP and cron are great.  I almost never compile in the back-ground
  185. as it adds just that much more time before it's finished, and I find myself
  186. constantly checking to see if it's finished yet.
  187.  
  188. Dan Suthers, Analyst, Pacific Bell
  189.  
  190. ------------------------------
  191.  
  192. Date: 10 Aug 89 16:10:20 GMT
  193. From: att!mtuxo!mtgzz!drutx!druwy!dlm@ucbvax.Berkeley.EDU  (Dan Moore)
  194. Subject: Re: C.E.K.A.
  195. To: info-atari16@score.stanford.edu
  196.  
  197. in article <8908091425.AA09465@ucbvax.Berkeley.EDU>,
  198. AKISUJAR@NUSVM.BITNET says:
  199. > Micheal C Barnes ask about CEKA Enterprises Phone Number.  Here it is:
  200. > (415) 4742641  For benefit of the other netter who maay not aware what
  201. > this is all about, CEKA Enterprises is now working on the internal
  202. > hardware board for the MEGA and the forthcoming Stacey laptop to
  203. > emulate Macintosh with out the need for the Macintosh boot ROMs.  I
  204. > only have the phone number of this company. I would appreciate the
  205. > Mailing address if you manage to contact them. The foundeer of this
  206. > firm is James McHugh.
  207.  
  208.     Unfortunately this is a hoax.  There is no C.E.K.A Enterprises.
  209. James McHugh is someone who decided it was time for his 15 mintues of
  210. fame.
  211.  
  212.     James McHugh showed up on GEnie a few months ago and announced
  213. that he was going to be releasing a clone of the Macintosh OS ROMs and
  214. that his hardware/software would let Atari STs, Amigas, Apollo and Suns
  215. (I'm probably forgeting some, he listed almost every machine that uses
  216. a 68000 family CPU) all run Macintosh software. He promissed to send
  217. lots of people prototypes, and agreed to show up and do several demos.
  218. I've heard that several magazines even published his comments and lauded
  219. him for his programming skill (they did this without even seeing a
  220. prototype, which shows how real things in magazines are).
  221.  
  222.     Then people who know how the Macintosh works started asking him
  223. questions and he was unable to answer them correctly.  He had no idea
  224. how the Mac works and what is needed to make non-Apple hardware work
  225. like a Mac.  Soon after the questions started he disappeared, his
  226. phone, the one given above, was disconnected.  No one has heard from
  227. him in a couple of months.
  228.  
  229.     If you like conspiracies you can believe that big evil Apple
  230. did away with him.  Maybe they moved him in with Jimmy Hoffa.  It's
  231. much more likely that he was a kid who wanted to be famous and get lots
  232. of attention, and now he's gone back to his normal, boring, life.
  233.  
  234.  
  235.     If people are interested in running Macintosh software on the
  236. ST, or other computers, contact one of the real companies (eg. Gadgets
  237. by Small or ReadySoft).  Don't waste your time on James McHugh.
  238.  
  239.  
  240.  
  241.             Dan Moore
  242.             AT&T Bell Labs
  243.             Denver
  244.             dlm@druwy.ATT.COM
  245.  
  246. ------------------------------
  247.  
  248. Date:         Mon, 14 Aug 89 14:30:58 BST
  249. From:         Mark Powell <SQ79%liverpool.ac.uk@NSFnet-Relay.AC.UK>
  250. Subject:      X windows
  251. To:           Atari mailing list <INFO-ATARI16@score.stanford.edu>
  252.  
  253.    I've heard that there's an X-windows package that runs on the Megas. Is this
  254. true? If anyone knows anything about this could they e-mail me with the info.
  255. Thanks in advance.
  256.  
  257. Mark Powell
  258.  
  259. ARPAnet : sq79%liv.ac.uk@ucl-cs.arpa,cs.ucl.ac.uk
  260. USENET  : ...!mcvax!ukc!liv.ac.uk!sq79
  261.  
  262. ------------------------------
  263.  
  264. Date: 14 Aug 89 09:12:29 GMT
  265. From: otter!gjh@hplabs.hp.com  (Graham Higgins)
  266. Subject: modedit file(s)
  267. To: info-atari16@score.stanford.edu
  268.  
  269. I'm trying to use to German modula-2 environment, but keep getting told that it
  270. can't find the editor.
  271.  
  272. I somehow missed getting a specific file - modedit - from what was volume5 in
  273. the ssyx binaries archives. Could anyone email it to me?
  274.  
  275. BTW, are the files that used to be in ssyx available anywhere else? - I had a
  276. look round but couldn't find modedit anywhere.
  277.  
  278. Cheers,
  279.  
  280. Graham
  281. ======
  282.  
  283. ------------------------------------------------------------------
  284. Graham Higgins @ HP Labs          |  Phone: (0272) 799910 x 24060
  285. Information Systems Centre        |  gray@hpl.hp.co.uk
  286. Bristol                           |  gray%hplb.uucp@ukc.ac.uk
  287. U.K.                              |  gray@hplb.hpl.hp.com
  288.  
  289. ------------------------------
  290.  
  291. Date: 14 Aug 89 13:01:09 GMT
  292. From: romeo!currier@cs.duke.edu  (Bob Currier - DCAC Network Comm. Specialist)
  293. Subject: Screen flicker, top
  294. To: info-atari16@score.stanford.edu
  295.  
  296. Greetings,
  297.  
  298. This weekend, while noodling around with animation, I came across a
  299. most puzzling phenomena.  My graphics displayed fine while on the
  300. lower part of the screen (I am using a monochrome 1040), but when
  301. my little critters got about 30 or 40 pixels from the top they
  302. started to get a bad case of the flickers.  I was using Vsync() to
  303. control flicker, and it seemed to work well, except for this
  304. twilight zone.
  305.  
  306. I pulled my hair out for a couple of hours on this one, dug thru all
  307. my books, and finally, at about 1 a.m., in the premier issue of START,
  308. found a comment in an article about al graphics that went like this:
  309.  
  310. "...vsync, but you will still see flicker near the top of the screen.  This
  311. is a problem that can only be dealt with by very complex multiple screen
  312. flipping techniques..."
  313.  
  314. So, does anyone know of this problem?  What causes it? And, Virginia, how
  315. can I eliminate it?
  316.  
  317.  
  318. Bob Currier
  319. currier@romeo.cs.duke.edu
  320. rdc@northlab.ac.duke.edu
  321.  
  322. ------------------------------
  323.  
  324. Date: 14 Aug 89 06:17:03 GMT
  325. From: mcvax!hp4nl!phigate!philmds!leo@uunet.uu.net  (Leo de Wit)
  326. Subject: Re: Multitasking on the ST
  327. To: info-atari16@score.stanford.edu
  328.  
  329. In article <194@crash.cts.com> fgbrooks@.UUCP (Fred Brooks) writes:
  330. |In article <1069@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
  331. |>[about avoiding block in read/write on slow devices]
  332. |
  333. |I intercept the BIOS trap vector and add my own routine to do the BConin
  334. |call. If nothing is waiting in the buffer then I swapout the current process
  335. |, if a char is is the buffer it is passed on to the calling process and a
  336. |countdown variable is set to say 100 so that when then next time the buffer
  337. |is empty it won't swapout until it has checked the buffer a few times.
  338.  
  339. You'll have to be careful this BIOS call was not done from GEMDOS, I think.
  340. I'm interested to know how you save a process's state.
  341.  
  342. |>P.S. The current version screamed for job control, signalling etc. so
  343. |>that's being implemented right now (together with some system calls
  344. |>like signal() and kill()).
  345. |
  346. |I would like a copy if you are giving it away with source.
  347.  
  348. The signalling stuff has been implemented. Now of course add job control,
  349. so that a character typed from the keyboard (~Z or is that too overloaded
  350. in GEMDOS?) can stop a process. I'll have to add a notion of background/
  351. foreground, so that a background process is stopped when it wants to use
  352. the console (read/write) and can be brought into the foreground.
  353.  
  354. You can have a premature copy if you want that (undoubtedly with bugs);
  355. before I offer it to the sources/binaries groups I want to test it myself
  356. when it is complete (I'm already thinking about pipes / interprocess
  357. communication etc., so depending on whether this would come into the
  358. first release, it could take a while).
  359.  
  360.    Leo.
  361.  
  362. ------------------------------
  363.  
  364. Date: 14 Aug 89 14:18:09 GMT
  365. From: cs.dal.ca!silvert@uunet.uu.net  (Bill Silvert)
  366. Subject: User needed near New Britain, CT
  367. To: info-atari16@score.stanford.edu
  368.  
  369. A German colleague of mine is spending a half-term working at Central
  370. Connecticut State University in New Britain, CT.  He needs to get his
  371. hands on an ST, but cannot find one at the university.  Since he is
  372. developing a very interesting object-oriented modelling program (similar
  373. to Stella on the Mac, but much more sophisticated), I hope that someone
  374. in the area might be interested in contacting him.
  375.  
  376. His name is Wolfgang Ebenhoeh, and he is in the Math/CS department at
  377. CCSU.  His home telephone number is (203)224-2024, and he will be there
  378. until Christmas.
  379.  
  380. I've worked with Wolfgang for a number of years, and he is an amazing
  381. and interesting fellow.  If you contact him, you may want to ask about
  382. his computer version of Ecolopoly, a simulation of running a country in
  383. an environmentally acceptable fashion, written in OSS Pascal.
  384. --
  385. Bill Silvert, Habitat Ecology Division.
  386. Bedford Institute of Oceanography, Dartmouth, NS, Canada B2Y 4A2
  387.     UUCP: ...!uunet,watmath!dalcs!biomel!bill
  388.     Internet: biomel@cs.dal.CA    BITNET: bs%dalcs@dalac.BITNET
  389.  
  390. ------------------------------
  391.  
  392. Date: 14 Aug 89 14:20:21 GMT
  393. From: att!cbnewsm!cbz@ucbvax.Berkeley.EDU  (craig.b.ziemer)
  394. Subject: RAM Upgrades
  395. To: info-atari16@score.stanford.edu
  396.  
  397. I recently posted a request for info on the EZRAM II RAM upgrade board and
  398. received no replies.  So, let me rephrase the question.  Can anyone send me
  399. any information (opinions, etc.) on ANY RAM (1M) upgrade boards available?
  400. I'd like to checkout this possibility before I try the DIY piggyback-type
  401. upgrade. Suggestions appreciated!
  402.  
  403. *  Craig B. Ziemer                %%        DISCLAIMER: AT&T does not  *
  404. *  AT&T Bell Laboratories       %%%%%%      officially support what I  *
  405. *  Reading, PA                    %%        just said, in fact, they   *
  406. *  UUCP ADDRESS: alux6!cbz        %%             rarely do :~)         *
  407.  
  408. ------------------------------
  409.  
  410. End of Info-Atari16 Digest
  411. **************************
  412. -------
  413.  
  414. ə