Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 89 Issue 415
Info-Atari16 Digest Friday, August 25, 1989 Volume 89 : Issue 415
This weeks Editor: Bill Westfield
Today's Topics:
Re: PC-DITTO questions
News from PC MAGAZINE Editor's Day
Re: Atari GEMVDI programming
Re SYSTEM2
Re: Multitasking
Re: Hard drive questions
Re: Multitasking on the ST
Mention of Portfolio on TV
Re: Multitasking on the ST
Re: Monitor/Drive info requested [PS3000]
Re: Alt. ST box
Re: Towards a real, somewhat compatible multiTASKING TOS
----------------------------------------------------------------------
Date: 21 Aug 89 03:07:42 GMT
From: portal!cup.portal.com!Matthew_Eric_Seitz@uunet.uu.net
Subject: Re: PC-DITTO questions
To: info-atari16@score.stanford.edu
Concerning PC Ditto II and EGA:
In an exclusive COMPUTER SHOPPER interview with the project's chief
engineer, Avante-Garde Systens Co-partner William Teal, it was
disclosed that hardware designed to support the 64K EGA (IBM Enhanced
Graphics Adapter) standard format was being tested successfully on
standard Atari SC1224 color monitors in Avant-Garde's labs.
- D. F. Scott, "ST Product News"
COMPUTER SHOPPER, August 1989
p. 444
------------------------------
Date: 21 Aug 89 03:25:44 GMT
From: portal!cup.portal.com!Matthew_Eric_Seitz@uunet.uu.net
Subject: News from PC MAGAZINE Editor's Day
To: info-atari16@score.stanford.edu
Last Thursday, I was at the PC MAGAZINE Editor's Day. Much to my suprise,
Atari was there, too. It wasn't a big showing, they just had a table, no
signs, a couple Portfolios, and some Atari people. However, one of those
people was Sig Hartman, so I pumped him for a little information.
He told me the ST-E was available as of last week. He didn't give me specs,
but said it had more colors and stereo sound, and was compatible with the
SC1224 monitor. Since my roommate is a registered developer, I called on
Atari on his behalf. Unfortunately, Gale Johnson, the new Developer's
Coordinator, knew nothing about the ST-E. I'll be checking in next week to
see if there's any more info.
Mr. Hartman also said that the TT would be shipping 4th quarter '89, probably
late 4th quarter. He mentioned that it will have the ability to support
multiple users running GEM programs, using STs as terminals.
By the way, you may have seen an article on Moses Computers and the PromiseLAN
network in ST-LOG a while back. As an employee of Moses, I can tell you it
was more wrong than right. As soon as I can find out how much info I can
tell, and if there's any interest, I will pass it along.
-Matthew Seitz
------------------------------
Date: 20 Aug 89 17:32:09 GMT
From: nis!pwcs!stag!daemon@UMN-CS.CS.UMN.EDU (Steve Yelvington)
Subject: Re: Atari GEMVDI programming
To: info-atari16@score.stanford.edu
chrisl@fulcrum.bt.co.uk writes...
> I am about to embark on the writing of a fairly major piece of programming on
> a 1040 ST with Mark Williams C (I think). I am writing a windowing application
> which will also have to gather data from the ST serial port.
> Can anyone recommend
> a) a good introductory text on programming, particularly the serial
> interface and the windowing features,
> b) a good reference work for the same features
As an introductory text on GEM programming, I would recommend:
Atari ST Application Programming
Lawrence J. Pollack
Eric J.T. Weber
Datatech Publications
Bantam Books
ISBN 0-553-34397-1
If the book isn't available in the U.K., try contacting Bantam at 666
Fifth Avenue, New York NY 10103 USA.
The serial interface is another matter entirely. You don't really NEED to
know much about it to make it work -- the logical AUX device actually is a
FIFO buffer maintained by an interrupt-driven communications routine built
into TOS. All you have to do is poll the AUX device using the Cauxis/
Cauxin GEMdos calls or the equivalent Bconstat/Bconin at the BIOS level.
You don't have to install your own interrupt service routines or other
MS-DOS-like brain-damage-control measures.
A couple of tricks:
Rsconf(baud,flow,uc,rs,ts,sc) WORD baud, flow, uc, rs, ts, sc
configures the RS232C port. Some legal "baud" values are:
0 == 19.2 kb
1 == 9600
2 == 4800
4 == 2400
7 == 1200
9 == 300
Values for flow are:
0 == no flow control (default)
1 == xon/xoff
2 == RTS/CTS (whether it works is another matter entirely)
3 == both xon/xoff and RTS/CTS
The rest of the parameters are best left untouched unless you really want
to get bizarre. To avoid changing the value of a setting, use -1. For
example. Rsconf(7, -1, -1, -1, -1, -1) will set the speed to 1200 and
leave the other settings unchanged.
Another useful call:
Iorec(iodev) WORD iodev
returns a pointer to an input buffer descriptor structure, which is
immediately followed by the output buffer descriptor in the same format.
By poking around in these structures, you can repoint the queue to your
own buffer of a larger or smaller size.
Why would you want to do this? Suppose you're receiving Ymodem. As soon as
you get a packet, you ACK it, THEN you start writing to disk. Since you
wisely have made the input buffer > 1K, the interrupt-driven i/o routine
has a place to stuff ALL of the next incoming block, even if you have very
slow disk drives and a very fast modem.
(I once made the mistake of trying Tom Zerucha's WXmodem (windowing xmodem)
program without using his companion TSR utility to expand the input buffer
... and I was writing to a floppy disk. It was a disaster!)
Here's what the structure looks like:
struct iorec
char *buffer; /* pointer to FIFO queue */
WORD buf_size, /* size of the FIFO queue */
buf_head, /* queue head index */
buf_tail, /* queue tail index */
buf_low, /* when to turn flow ON */
buf_hi; /* when to turn flow OFF */
If you fool around with this stuff, don't forget to restore the pointers
and values before your program terminates, or the next program may get a
very rude shock from the AUX port!
Hope this helps.
This message is in the public domain.
-- Steve Yelvington, up at the lake in Minnesota
... bungia.mn.org!stag!thelake!steve
------------------------------
Date: 20 Aug 89 10:30:10 GMT
From: cs.dal.ca!iisat!brains!george_seto@uunet.uu.net (George Seto)
Subject: Re SYSTEM2
To: info-atari16@score.stanford.edu
Re SYSTEM2:
I have used your System 2 shell a little bit and would like to suggest two
things.
1 - A method to determine what is the amount of space left available on the
disk.
2 - The system DOESN'T change the colours on entry into it or exit from it.
I am using a colour system, and the computer changes colour when it entered
the System2 program, which I don't mind. However when it returns to the
calling program it has changed the colours.
Haven't used it much except to find out those two things. Otherwise it
seems limited compared to gulam, but is almost half the size. Probably since
it doesn't include the Terminal program or MicroEmacs editor which gulam has
built-in.
--
-===------===- From George Seto at Cerebral Cortex BBS System
-==-==----==-==- (902)462-7245 3/12/2400 8N1 24h/7d
-==-------==------ george_seto%brains@iisat.UUCP
-==-==----==-==-
------------------------------
Date: 19 Aug 89 07:46:05 GMT
From: obryan@gumby.wisc.edu (Mark O'Bryan)
Subject: Re: Multitasking
To: info-atari16@score.stanford.edu
In article <1610@psueea.UUCP>, kirkenda@jove.cs.pdx.edu (Steve Kirkendall)
writes:
>
> 1) Why do I want multitasking? Well, mostly because it would make desk
> accessories obsolete; each DA could be replaced by an application program.
> DAs use memory from the time the system is booted to the time it is rebooted.
> This is bad. You have to reboot the system to install a new DA. This is bad.
Actually, neither of these statements is true if you have MultiDesk from
CodeHead Software. It allows you to load and flush accessories pretty much
at will, without rebooting. It's a slick product.
Your other points about DA limitations (omitted) were well made, and easy
to agree with.
--
Mark T. O'Bryan Internet: obryan@gumby.cc.wmich.edu
Western Michigan University
Kalamazoo, MI 49008
------------------------------
Date: 21 Aug 89 08:38:02 GMT
From: mcvax!hp4nl!ruuinf!verwer@uunet.uu.net (Nico Verwer)
Subject: Re: Hard drive questions
To: info-atari16@score.stanford.edu
In article <8908181535.AA13948@ucbvax.Berkeley.EDU>, SQ79@liverpool.ac.UK (Mark
Powell) writes:
>
> 2. I've heard that hard drives spin at about 3600 rpm. Therefore if your
> recommended interleave factor is one, will the controller read the track
> in a single revolution? If so doesn't that mean it is reading the track
> in 1/3600th of a second? (This can't be right!) I know the seek and
Rpm means `revolutions per _minute_', and since there are 60 seconds to one
minute, and the controller reads the track in a single revolution, it reads
the track in 1/60th of a second. That is 16.6ms, not 0.3ms.
--
Nico Verwer @ Dept. of Computer Science, University of Utrecht, The Netherlands
(verwer@cs.ruu.nl)
------------------------------
Date: 21 Aug 89 05:57:31 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 <679@opal.tubopal.UUCP> alderaan@tubopal.UUCP (Thomas Cervera)
writes:
|In article <1070@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
|=[]
|= Whereas the 68010, 68020 etc. store much
|=information on the stack at a BUSERR (29 words if I'm correct), the
|=68000 only stores 7 words, which is not sufficient to resume each type
|=of instruction. For instance:
|=
|= movem.l (a3),a2-a5
|=
|=Since this instruction modifies the contents of a3, it cannot be resumed
|=when a bus error occurs after a3 has been modified (and the instruction
|=has not yet completed).
|
| I'm not that familiar with the 68000's hardware and pin configuration.
|But isn't there a pin telling the non-existent MMU 'shut up, I'm working on
|an instruction right now !' ?
| Sure, the MMU must be able to hold it's BUSERR signal back until the CPU
|drops this line and tries to fetch the next instruction.
| If this is possible, error recovery on BUSERR should not be a problem.
I think you missed my point. The data pointed to by a3 could lay near a
page boundary. For instance a2-a3 can still be fetched, but a4 must be
read in from a not (yet) existing address (which causes a BUSERR). a3
has been modified, so you cannot repeat the instruction (you have to
know the original contents of a3 to do that).
You could hold back the BUSERR signal, but I don't know what good that
will do to you. You still have to execute the instruction. Execution of
the instruction causes the BUSERR, which kicks the BUSERR exception
handler to page in the new memory, after which the instruction can be
restarted at the point it was interrupted (reading a value for a4 in
the sample case). 68010's and 68020's etc. store enough intermediate
data to resume an instruction this way, 68000's do not. The whole point
is that the BUSERR exception is just the means to trigger the paging
event.
Leo.
------------------------------
Date: 19 Aug 89 03:06:59 GMT
From: att!chinet!saj@ucbvax.Berkeley.EDU (Stephen Jacobs)
Subject: Mention of Portfolio on TV
To: info-atari16@score.stanford.edu
Tonight's guest on Wall Street Week (PBS financial news show, hosted by
Louis Rukeyser) was Lee Isgur. He mentioned that Atari had announced a pocket
computer, that it would be available in time for Christmas, and that he had
one in his pocket as he was talking. This man is an influential enough
financial analyst that one can understand Atari buttering him up with early
samples. It's encouraging to hear that there are enough machines for ANY of
them to leave home. Isgur also referred to the hand-held game machine. And
no, he didn't say what he thought of Atari or show any goodies. It was just
something he said in passing.
Steve J.
------------------------------
Date: 21 Aug 89 16:46:47 GMT
From: cbmvax!daveh@uunet.uu.net (Dave Haynie)
Subject: Re: Multitasking on the ST
To: info-atari16@score.stanford.edu
in article <679@opal.tubopal.UUCP>, alderaan@tubopal.UUCP (Thomas Cervera) says:
> =The problem is that for instance a page fault can emerge whilst in the
> =middle of an instruction.
> I'm not that familiar with the 68000's hardware and pin configuration.
> But isn't there a pin telling the non-existent MMU 'shut up, I'm working on
> an instruction right now !' ?
Impossible. It's the fact that the 68000's working on that instruction that
caused the page fault in the first place. Page faults are caused most often
on a VM system when an instruction tries to access a virtual address that
isn't currently in physical memory. This always happens in an instruction;
where else do you think addresses are generated? The exception takes place,
the OS brings up its VM manager which proceeds to fetch the missing page, then
either continue the instruction (68010-68030) or retry the instruction (68040).
The 68000 doesn't save enough context for either. Though back in the old
days, a pair of 68000s could be hooked up to achieve this same end (Apollo is
one company that used such a scheme).
> Thomas Cervera | UUCP: alderaan@tubopal.UUCP
--
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
We have no choice. We are, after all, professionals.
------------------------------
Date: 21 Aug 89 18:30:57 GMT
From: titan!bro@rice.edu (Douglas Monk)
Subject: Re: Monitor/Drive info requested [PS3000]
To: info-atari16@score.stanford.edu
I don't know if it was "legal" or not, but I saw one of these combined
monitor and floppy drives for sale at Federated here in Houston years
ago. This was long before Atari bought them, if memory serves.
Doug Monk (bro@rice.edu)
Disclaimer: These views are mine, not necessarily my organization's.
------------------------------
Date: 21 Aug 89 18:35:23 GMT
From: titan!bro@rice.edu (Douglas Monk)
Subject: Re: Alt. ST box
To: info-atari16@score.stanford.edu
Tech Specialties in Houston offers a CPU case that moves the motherboard,
floppies, and hard drive(s) into an AT or tower type case, and puts the
original keyboard into a modified (smaller) case connected by cable to the
CPU. I don't have info on price or Tech Specialties' address, but they
have adds in Computer Shopper last I checked, and I saw a CPU case at
the World of Atari show in Dallas.
Doug Monk (bro@rice.edu)
Disclaimer: These views are mine, not necessarily my organization's.
------------------------------
Date: 20 Aug 89 05:27:53 GMT
From: att!chinet!saj@ucbvax.Berkeley.EDU (Stephen Jacobs)
Subject: Re: Towards a real, somewhat compatible multiTASKING TOS
To: info-atari16@score.stanford.edu
In the referenced article, David Beckemeyer repeated his offer to donate the
RTX multitasking kernel to the public domain <under the right circumstances>.
He takes us all to task because all he requires is for someone to write a
worthwhile application to go with it, and in 2 years, nobody wrote one. As
I remember the earlier discussion, though, the conditions were never so
clearcut before. I remember a lot of offers to make RTX available free if
anyone could give him a good reason, and then a general fading out of
discussion. So: somebody does a printer daemon or a shell with job control
and then we can all have RTX? That's a more concrete target.
Steve J.
------------------------------
End of Info-Atari16 Digest
**************************
-------
