Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 89 Issue 402
Info-Atari16 Digest Tuesday, August 22, 1989 Volume 89 : Issue 402
This weeks Editor: Bill Westfield
Today's Topics:
Re: Multitasking on the ST
QINDEX15 measurents : QuickST 1.46 vs TurboST 1.2
Re: Apathy and Defeatism
Re: Loyal Atarians?!?
Re: Multitasking on the ST
Re: C.E.K.A.
X windows
modedit file(s)
Screen flicker, top
Re: Multitasking on the ST
User needed near New Britain, CT
RAM Upgrades
----------------------------------------------------------------------
Date: 14 Aug 89 04:29:46 GMT
From: cwjcc!dsrgsun.ces.cwru.edu@g.ms.uky.edu (Jwahar R. Bammi)
Subject: Re: Multitasking on the ST
To: info-atari16@score.stanford.edu
In article <89081310545051@masnet.uucp>, david.megginson@canremote (DAVID
MEGGINSON) writes:
>From what I've heard, Minix is very restrictive with memory. Each
>program is allowed a maximum of 64k, and there is not VM paging. A cute
>toy, but useless for anything but learning.
>---
The restriction on memory is only on the Ibm-Pc version of minix.
In ST-minix there is no such restriction. Its true that there is no
virtual memory.
IMHO it is a little bit more than a cute toy.
--
bang: any internet host !dsrgsun.ces.CWRU.edu!bammi jwahar r. bammi
domain: bammi@dsrgsun.ces.CWRU.edu
GEnie: J.Bammi
------------------------------
Date: Mon, 14 Aug 89 11:28 N
From: <KRUYSBER%HNYKUN53.BITNET@Forsythe.Stanford.EDU>
Subject: QINDEX15 measurents : QuickST 1.46 vs TurboST 1.2
To: info-atari16@score.stanford.edu
X-Original-To: info-atari16@score.stanford.edu, KRUYSBERGEN
To complete the QINDEX15 measurements I've compared QuickST 1.46 and
TurboST 1.2.
These two only affect the BIOS operations, so I'll give you these
results only.
All measures were done with a 1040ST with no accessories or AUTO folder
programs (except QSTAUTO.PRG...)
Normal QuickST TurboST
BIOS character output 99 150 312
BIOS string output 99 578 725
BIOS text scrolling 99 175 178
GEM resource drawing 99 167 125
Psychological data: a difference between 578-725 is not 3.5 times the
difference between 167-125! The ratio 725/578 = 1.25 and 167/125 = 1.31,
so these differences are about the same. 578 is however 5.78 as fast as
a normal 1040ST! The difference 167-125 is very noticeable. GEM resources
are drawn much quicker. This favours QuickST. The difference 578-725 is
pure mathematical, since the increase in speed of 578% in the QuickST
case is already striking enough! Another increase up to 725 is merely
'for the record': this is hardly noticable in reality.
Conclusion: the measures indicate a better BIOS text handling by TurboST
and a better GEM resource handling by QuickST. These measures however
have to be seen in the light of the human, indicating that QuickST is
(in the comparison of these two versions) preferable.
I'm not in the possession of QuickST 1.5 (witch should even be faster),
nor am I in the possession of TurboST 1.6 (yet?). The new TurboST should
handle GEM drawing much better one promissed to me...
Noud van Kruysbergen
N.I.C.I.
Mail Box 9104
6500 HE Nijmegen
The Netherlands
kruysbergen@hnykun53
P.S. I haven't done any QINDEX15 testing using cache programs, since these
programs keep the last information used in RAM. Reading the same infor-
mation 64 times increases the QINDEX measure considerable, but this is
not real! You'll never read the same information more than once normally,
so unless your cache memory is rather big you'll never reach this measure
in practice! Using a cache with these kind of measurements is one of
the pitfalls I mentioned the first time.
------------------------------
Date: 14 Aug 89 01:00:39 GMT
From: portal!cup.portal.com!Xorg@uunet.uu.net (Peter Ted Szymonik)
Subject: Re: Apathy and Defeatism
To: info-atari16@score.stanford.edu
Hi Scott, although I completely agree with most of what you wrote, one
falining among most people who bad-mouth the ST is not recognizing that
unlike the Apple or MS-DOS machines, the ST was sold internationally and
like it or not, the United States was never tapped as the major market
for the ST. Yes, Atari has been brain-dead when it comes to the U.S>
market, but that may well have been on purpose - going after and
against MS-DOS and MAC's with the multi-BILLION dollar war-chests
would hardly have been a wise business decision on the aprt of Atari.
Atari's strategy HAS also worked by the way - financially the company is
very strong and solid and 400 on the Fortune 500 list - far from an
easy achievement for a compnay that appeared a mere four years ago!
------------------------------
Date: 14 Aug 89 09:01:49 GMT
From: amdahl!pacbell!pbhya!dbsuther@ames.arc.nasa.gov (Daniel B. Suthers)
Subject: Re: Loyal Atarians?!?
To: info-atari16@score.stanford.edu
The Question; Why are Atari users so fanatical/loyal?
The ST was the best machine available at the time; Cheap, fast, capable.
It is still fast and capable.
Most of the software has been written from scratch, and takes the hardware
into account. This makes for some VERY good programs.
The IBM and MAC programs I have to work with generally are barely usable or
badly over-priced. I would hate to have to put up with them at home.
The built in interfaces mean that most programmers can devote time to the
programing, not on getting it to work with all 10,000 variations of
dos/memory/hardware/TSRs.
The development environments are close enough the UNIX environment that
I can port code to my ST, and back to the Mini I use at work. This saves
me development time.
I'd rather have a 3B4000, but can't aford the power bill. :-)
Dan
------------------------------
Date: 14 Aug 89 08:10:39 GMT
From: amdahl!pacbell!pbhya!dbsuther@ames.arc.nasa.gov (Daniel B. Suthers)
Subject: Re: Multitasking on the ST
To: info-atari16@score.stanford.edu
In article <63138@linus.UUCP> rachamp@mbunix (Champeaux) writes:
>From The Amiga ROM Kernel manual:
>
> Every task has an assigned priority and tasks are scheduled to use the
> processor on a priority basis. The highest priority ready task is selected
> and receives processing until:
>
[TEXT DELETED]
> Task scheduling is preemptive in nature. The running task may lose the
> processor at nearly any moment by being displaced by another more urgent
> task. Later, when the preempted task regains the processor, it continues
> where it left off.
>
>When a higher priority task becomes active, the running task is immediately
>interrupted.
After reading this a question popped into my head. If you are downloading in
the back ground (it seems the most popular multi-task task) and running a
action game in the foreground, do you set the download process to the
highest priority to avoid losing data or do you just put up with longer
download times and connect times so your joy-stick will be responsive?
While I'm at it...
What is a "ray trace" that most amiga users seem to want to generate them, and
are willing to wait 2 or 3 days for the output??? The ray traces I've done
have always completed over-night, and that's longer than I wish to wait for
a pretty drawing.
My idea of great uses for multi-tasking agrees with the UNIX system. Utilities
such as UUCP, LP and cron are great. I almost never compile in the back-ground
as it adds just that much more time before it's finished, and I find myself
constantly checking to see if it's finished yet.
Dan Suthers, Analyst, Pacific Bell
------------------------------
Date: 10 Aug 89 16:10:20 GMT
From: att!mtuxo!mtgzz!drutx!druwy!dlm@ucbvax.Berkeley.EDU (Dan Moore)
Subject: Re: C.E.K.A.
To: info-atari16@score.stanford.edu
in article <8908091425.AA09465@ucbvax.Berkeley.EDU>,
AKISUJAR@NUSVM.BITNET says:
> Micheal C Barnes ask about CEKA Enterprises Phone Number. Here it is:
> (415) 4742641 For benefit of the other netter who maay not aware what
> this is all about, CEKA Enterprises is now working on the internal
> hardware board for the MEGA and the forthcoming Stacey laptop to
> emulate Macintosh with out the need for the Macintosh boot ROMs. I
> only have the phone number of this company. I would appreciate the
> Mailing address if you manage to contact them. The foundeer of this
> firm is James McHugh.
Unfortunately this is a hoax. There is no C.E.K.A Enterprises.
James McHugh is someone who decided it was time for his 15 mintues of
fame.
James McHugh showed up on GEnie a few months ago and announced
that he was going to be releasing a clone of the Macintosh OS ROMs and
that his hardware/software would let Atari STs, Amigas, Apollo and Suns
(I'm probably forgeting some, he listed almost every machine that uses
a 68000 family CPU) all run Macintosh software. He promissed to send
lots of people prototypes, and agreed to show up and do several demos.
I've heard that several magazines even published his comments and lauded
him for his programming skill (they did this without even seeing a
prototype, which shows how real things in magazines are).
Then people who know how the Macintosh works started asking him
questions and he was unable to answer them correctly. He had no idea
how the Mac works and what is needed to make non-Apple hardware work
like a Mac. Soon after the questions started he disappeared, his
phone, the one given above, was disconnected. No one has heard from
him in a couple of months.
If you like conspiracies you can believe that big evil Apple
did away with him. Maybe they moved him in with Jimmy Hoffa. It's
much more likely that he was a kid who wanted to be famous and get lots
of attention, and now he's gone back to his normal, boring, life.
If people are interested in running Macintosh software on the
ST, or other computers, contact one of the real companies (eg. Gadgets
by Small or ReadySoft). Don't waste your time on James McHugh.
Dan Moore
AT&T Bell Labs
Denver
dlm@druwy.ATT.COM
------------------------------
Date: Mon, 14 Aug 89 14:30:58 BST
From: Mark Powell <SQ79%liverpool.ac.uk@NSFnet-Relay.AC.UK>
Subject: X windows
To: Atari mailing list <INFO-ATARI16@score.stanford.edu>
I've heard that there's an X-windows package that runs on the Megas. Is this
true? If anyone knows anything about this could they e-mail me with the info.
Thanks in advance.
Mark Powell
ARPAnet : sq79%liv.ac.uk@ ucl-cs.arpa,cs.ucl.ac.uk
USENET : ...!mcvax!ukc!liv.ac.uk!sq79
------------------------------
Date: 14 Aug 89 09:12:29 GMT
From: otter!gjh@hplabs.hp.com (Graham Higgins)
Subject: modedit file(s)
To: info-atari16@score.stanford.edu
I'm trying to use to German modula-2 environment, but keep getting told that it
can't find the editor.
I somehow missed getting a specific file - modedit - from what was volume5 in
the ssyx binaries archives. Could anyone email it to me?
BTW, are the files that used to be in ssyx available anywhere else? - I had a
look round but couldn't find modedit anywhere.
Cheers,
Graham
======
------------------------------------------------------------------
Graham Higgins @ HP Labs | Phone: (0272) 799910 x 24060
Information Systems Centre | gray@hpl.hp.co.uk
Bristol | gray%hplb.uucp@ukc.ac.uk
U.K. | gray@hplb.hpl.hp.com
------------------------------
Date: 14 Aug 89 13:01:09 GMT
From: romeo!currier@cs.duke.edu (Bob Currier - DCAC Network Comm. Specialist)
Subject: Screen flicker, top
To: info-atari16@score.stanford.edu
Greetings,
This weekend, while noodling around with animation, I came across a
most puzzling phenomena. My graphics displayed fine while on the
lower part of the screen (I am using a monochrome 1040), but when
my little critters got about 30 or 40 pixels from the top they
started to get a bad case of the flickers. I was using Vsync() to
control flicker, and it seemed to work well, except for this
twilight zone.
I pulled my hair out for a couple of hours on this one, dug thru all
my books, and finally, at about 1 a.m., in the premier issue of START,
found a comment in an article about al graphics that went like this:
"...vsync, but you will still see flicker near the top of the screen. This
is a problem that can only be dealt with by very complex multiple screen
flipping techniques..."
So, does anyone know of this problem? What causes it? And, Virginia, how
can I eliminate it?
Bob Currier
currier@romeo.cs.duke.edu
rdc@northlab.ac.duke.edu
------------------------------
Date: 14 Aug 89 06:17:03 GMT
From: mcvax!hp4nl!phigate!philmds!leo@uunet.uu.net (Leo de Wit)
Subject: Re: Multitasking on the ST
To: info-atari16@score.stanford.edu
In article <194@crash.cts.com> fgbrooks@.UUCP (Fred Brooks) writes:
|In article <1069@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
|>[about avoiding block in read/write on slow devices]
|
|I intercept the BIOS trap vector and add my own routine to do the BConin
|call. If nothing is waiting in the buffer then I swapout the current process
|, if a char is is the buffer it is passed on to the calling process and a
|countdown variable is set to say 100 so that when then next time the buffer
|is empty it won't swapout until it has checked the buffer a few times.
You'll have to be careful this BIOS call was not done from GEMDOS, I think.
I'm interested to know how you save a process's state.
|>P.S. The current version screamed for job control, signalling etc. so
|>that's being implemented right now (together with some system calls
|>like signal() and kill()).
|
|I would like a copy if you are giving it away with source.
The signalling stuff has been implemented. Now of course add job control,
so that a character typed from the keyboard (~Z or is that too overloaded
in GEMDOS?) can stop a process. I'll have to add a notion of background/
foreground, so that a background process is stopped when it wants to use
the console (read/write) and can be brought into the foreground.
You can have a premature copy if you want that (undoubtedly with bugs);
before I offer it to the sources/binaries groups I want to test it myself
when it is complete (I'm already thinking about pipes / interprocess
communication etc., so depending on whether this would come into the
first release, it could take a while).
Leo.
------------------------------
Date: 14 Aug 89 14:18:09 GMT
From: cs.dal.ca!silvert@uunet.uu.net (Bill Silvert)
Subject: User needed near New Britain, CT
To: info-atari16@score.stanford.edu
A German colleague of mine is spending a half-term working at Central
Connecticut State University in New Britain, CT. He needs to get his
hands on an ST, but cannot find one at the university. Since he is
developing a very interesting object-oriented modelling program (similar
to Stella on the Mac, but much more sophisticated), I hope that someone
in the area might be interested in contacting him.
His name is Wolfgang Ebenhoeh, and he is in the Math/CS department at
CCSU. His home telephone number is (203)224-2024, and he will be there
until Christmas.
I've worked with Wolfgang for a number of years, and he is an amazing
and interesting fellow. If you contact him, you may want to ask about
his computer version of Ecolopoly, a simulation of running a country in
an environmentally acceptable fashion, written in OSS Pascal.
--
Bill Silvert, Habitat Ecology Division.
Bedford Institute of Oceanography, Dartmouth, NS, Canada B2Y 4A2
UUCP: ...! uunet,watmath !dalcs!biomel!bill
Internet: biomel@cs.dal.CA BITNET: bs%dalcs@dalac.BITNET
------------------------------
Date: 14 Aug 89 14:20:21 GMT
From: att!cbnewsm!cbz@ucbvax.Berkeley.EDU (craig.b.ziemer)
Subject: RAM Upgrades
To: info-atari16@score.stanford.edu
I recently posted a request for info on the EZRAM II RAM upgrade board and
received no replies. So, let me rephrase the question. Can anyone send me
any information (opinions, etc.) on ANY RAM (1M) upgrade boards available?
I'd like to checkout this possibility before I try the DIY piggyback-type
upgrade. Suggestions appreciated!
* Craig B. Ziemer %% DISCLAIMER: AT&T does not *
* AT&T Bell Laboratories %%%%%% officially support what I *
* Reading, PA %% just said, in fact, they *
* UUCP ADDRESS: alux6!cbz %% rarely do :~) *
------------------------------
End of Info-Atari16 Digest
**************************
-------
