INFO-ATARI16 Digest         Thu,  2 Nov 89       Volume 89 : Issue 596
 
Today's Topics:
                    question SPECTRE GCR (2 msgs)
                            Sound on an ST
                          TOS, Zoo, or Zen?
                       TOS 1.4 Incompatibility
                          TOS 1.6 && TOS 1.4
                                 UNIX
                      UNIX -- ATW Speed (2 msgs)
                            unix on the TT
                     WordPerfect for the Atari ST
                             XFormer 2.55
----------------------------------------------------------------------
 
Date: 2 Nov 89 00:16:16 GMT
From: portal!cup.portal.com!Dave_Ninjajr_Flory@uunet.uu.net
Subject: question SPECTRE GCR
 
 
>Does anyone know anything about floppy compatibility between ATARI-1040ST
>with SPECTRE GCR and Macintosh II. I mean: can I port data from ST to Mac
>(vice versa) by means of a floppy? Do I need special hardware?
 
Yes you can run the same floppy in both machines, assuming that the Mac II
uses the same disks as the plus, 800K DS disks and has a compatible format.
I exchange data with macs all over the dept, from my Mega 4.
 
------------------------------
 
Date: 1 Nov 89 23:46:27 GMT
From: portal!cup.portal.com!Xorg@uunet.uu.net  (Peter Ted Szymonik)
Subject: question SPECTRE GCR
 
Spectre GCR allows you to pop a MAC disk into the ST drive and emulate
a real MAC.  MAC and ST format disks are *very* different, when you use
GCR you are always in MAC mode - not ST mode.  If you put an ST disk in
a MAC you will get nothing.  If your asking whether you can DL  a file
(MAC file) to an ST disk and then run it under GCR, the answer is no.
Niether would you be able to DL an ST program to a MAC disk and run it
on an ST.  There IS a program included with Specter GCR called TRANSVERTER
which does allow you to move files between the two different disk formats
however.
Peter Szymonik
Xorg@cup.portal.com
 
------------------------------
 
Date: 2 Nov 89 02:45:46 GMT
From:
 cs.utexas.edu!samsung!uakari.primate.wisc.edu!uflorida!novavax!hrshcx!wink!bob@
tut.cis.ohio-state.edu  (Bob Gray)
Subject: Sound on an ST
 
The other day I decided to write a small program to read a text file and
send Morse Code to the speaker.  I hacked together the driver but was unable
to get the Giaccess routine to work.  I was able to read the chip registers
but unable to write to them.  My Giaccess documentation is poor and my
sound chip documentation is worse.  Should I be using Dosound?  I am using
Mark Williams C on a 520ST.  Anyone got a code fragment that does this?
As always...
Thanks in advance.
        bob
--
-----------------------------------------------------------------------------
Bob Gray
Email : ...!novavax!hrshcx!wink!bob
Voice : 407-994-6408                              Boca Raton FL
 
------------------------------
 
Date: 1 Nov 89 22:18:51 GMT
From: imagen!atari!kbad@ucbvax.Berkeley.EDU  (Ken Badertscher)
Subject: TOS, Zoo, or Zen?
 
achowe@tiger.waterloo.edu (anthony howe) writes:
 
| So the problem is that both versions of zoo will not generate sound
| archives under TOS 1.4 - 89.4.6 for some reason. Yet under the developer
| release of TOS 1.4 - 88.8.8 everything is hunky-dorey.
 
It is possible that it is due to Zoo mishandling DTA management.
GEMDOS DTA handling (in the internal* part of the DTA) was changed,
possibly in the time between the developer release and the final TOS
release.  Another problem is that GEMDOS _uses_ the DTA differently
in the final Rainbow TOS version than previous TOS versions... to wit:
if you don't save out DTA information between Fsfirst/next calls, when
the last call fails (with file not found), the DTA _will_ contain
garbage.
 
Or maybe it's just bad fairies in your computer.
--
   |||   Ken Badertscher  (ames!atari!kbad)
   |||   Atari R&D System Software Engine
  / | \  #include <disclaimer>
 
------------------------------
 
Date: 1 Nov 89 22:22:31 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU  (Allan Pratt)
Subject: TOS 1.4 Incompatibility
 
neil@cs.hw.ac.uk (Neil Forsyth) writes:
>The speed of the TT means that lots of software will really fly! I would just
>love to see all those games get all their work done in under a frame...
 
As you know, games are the worst offenders in terms of doing things
which aren't portable and defeat our efforts at compatible upgrades.
The fact is, it is NON-game software which you can expect to work, and
games which are more likely to fail.  (As it happens, a number of games
DON'T fail, notably Air Warrior on GEnie and SubLogic's FS2(!).
SideWinder also works, and it *does* get its work done in one frame.
 
(And now for the standard disclaimer before people rag on me about
things I didn't say...)  Don't take this as a comprehensive list of
what works and what doesn't.  It's just some games which I happen to
know work.
 
============================================
Opinions expressed above do not necessarily     -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.      ...ames!atari!apratt
 
------------------------------
 
Date: 2 Nov 89 02:07:45 GMT
From: imagen!atari!towns@ucbvax.Berkeley.EDU  (John Townsend)
Subject: TOS 1.6 && TOS 1.4
 
in article <4280003@hpgnd.HP.COM>, alex@hpgnd.HP.COM (Alexis MERMET-GRANDFILLES)
 says:
 
>
>       My question is quite simple ,...
>       Does TOS 1.6 gives the same new functions that TOS 1.4 ?
>       Are they compatible ?
>
>       In fact , Is TOS 1.6 an enhancement of TOS 1.4  ? or are they
>       two different branches of TOS 1.2 enhancement ? ...
 
 
TOS 1.6 is essentially TOS 1.4 with the support for the new features of
the STE. It does give the same new functions as TOS 1.4. They are NOT
two different versions of the TOS 1.2 "enhancement."
 
-- John Townsend                                ames!atari!towns
   Atari Corporation
 
------------------------------
 
Date: 1 Nov 89 11:19:18 GMT
From:
 eru!luth!sunic!tut!ra!chyde!mcsun!unido!tub!tmpmbx!netmbx!hase@bloom-beacon.mit
.edu  (Hartmut Semken)
Subject: UNIX
 
In article <4212@blake.acs.washington.edu> themod@blake.acs.washington.edu
 (Chris Hinton) writes:
>  This is in response to a request for information on the Atari Transputer
>Workstation (ATW).  There is an article in the November STart.
>
>  Here are some of the highlights :
>
>       RISC (reduced instruction set computer) running at 50 mHz
RISC: Not really true. Ther T800 Transputer is a "processor" that is
said to be a RISC processor, but the instruction set ist a lot larger
and nicer than 6502 :-)
Almost nobody will do serious programming on this machine in assembler.
The multiple opcode instructions always drive me crazy :-)
>       With all 4 boards, that is 13 transputers, the machine
>        runs at 10 MIP (= 1/5 Cray)
MIPS: Most Insane measurment for Processor Speed.
MIPS: Marketing Instrument for Pushing Sales.
MIPS won't tell You, how fast the machine will do Your job.
Transputers work fast when pushed to the limits. The network layout (the
Transputers have "links" - high speed (5, 10 or 20 MBit per second)
serial interfaces with DMA - to exchange data and code among each other)
is a critical factor as ist parallelism of the program.
There is an optimal network; one for each given task :-)
>       Helios OS (UNIX-like) with both CLI and Graphic interface
HELIOS is - or will be? - POSIX compatible; it's very much Unix but it's
different, of course: Transputers are different.
Multitasking was introduced to have all that expensive equipment
(processor, I/o, disk, card reader/puncher, hardcopy terminal) busy -
doing work - all the time; to have the processor doing another job,
while the editor is waiting for You to press the "ANY" key.
Multi-processor systems do not just make multitasking faster. A four
processor computer can be faster than for single processor machines.
 
The ATW HELIOS comes with csh-like command line interface and X-Windows
for graphics.
 
 
HELIOS is not ATW-specific.
One of the development team showed a version that booted on an AT-clone
equipped with an Inmos B004-clone (the B004 was one of the first Transputer
evaluation board from Inmos; the clone is the TEK4/8, the building
instructions were published in the german magazine c't)
 
 
A T414, T425 ot T800 will not run Unix faster than a - say - 68030 or
80386 at compareble clock frequencies.
It will to a better job on programs, that have independent tasks running
simultaniously. The Transputers do the basic multitasking in hardware
(!). Inter process communication (for multiprocessing) and multitasking
are very much supported by the hardware. Virtual memory is not.
 
hase
--
Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP
Dennis had stepped up into the top seat whet its founder had died of a
lethal overdose of brick wall, taken while under the influence of a
Ferrari and a bottle of tequila. (Douglas Adams; the long dark teatime...)
 
------------------------------
 
Date: 1 Nov 89 12:03:14 GMT
From:
 eru!luth!sunic!tut!ra!chyde!mcsun!unido!tub!tmpmbx!netmbx!hase@bloom-beacon.mit
.edu  (Hartmut Semken)
Subject: UNIX -- ATW Speed
 
In article <5188@cbnewsh.ATT.COM> wolf@cbnewsh.ATT.COM (thomas.wolf,ho,) writes:
>These claims are very misleading in that they imply that a system with 13
>transputers will actually run a program 1/5th as fast as a Cray (I'm assuming
>the above MIPS figures are correct.)  _Each_ T800 has a processing power
>of 10 MIPS (the upper limit at which instructions can be processed.)  So
 
Well, The T800 interger and floating point unit are running
independently and parallel...
MIPS do not say anything.
 
>if you have a calculation-intensive application, say one that does ray-tracing,
>you can expect that peek to be reached.  If you ran this same program on
>a 13-transputer based ATW, I doubt whether you will see significant increases
>in performance, since that application will be run on a single T800 (unless
>it was specifically written with parallelism in mind - using OCCAM(I guess that
>is the T800 assembly language?) - I don't think there are compilers smart
>enough to take conventional C programs and parallelize them.)
 
True.
Well, OCCAM is not the "transputer assembly language", but it's the
language everybody uses for a start...
 
OCCAM ist very much compareble to C: it's a high level language that is
pretty close to the processor.
 
OCCAM and the T's were made for each other; OCCAM has high level
language contructs, that can be directly mapped to hardware funtions.
For Example there is the construct
 
PAR
        SER
                procedure1(foo)
                procedure2(foo)
                procedure4(foo)
                output(foo)
        ENDSER
        SER
                f1(foobar)
                f3(huhu)
                f1(huhu)
        ENDSER
ENDPAR
 
This will run procedure[124] after each other *while* running f1(huhu)
after f3(huhu) after f1(foobar). The multitasking is done by the T's
hardware (microcode counts as hardware to me if it is burned to the
microcode ROM, not booted off disk).
 
Another contruct is the "channel". Channels are - kind of - pipes where
a taks puts in some stuff to be received by another task. The sending
task is held until the message is received by the receiver. This can be
used for task synchronizing and inter process communication.
If the receiver task runs on the same Transputer (chip) (well, it's
probably not running but "sleeping for input"), the channel is mapped to
a memory location, probably a location in the T's
on-chip-fast-nowait-RAM.
If the receiver ist running (sleeping) on another Transputer, the
channel will be mapped to the one of the four (eight in case of T222 or
so) "links"; thel ink connected to the other T.
 
The links are used to connect Transputers with each other.
In an advanced Transputer system there will probably be some link switch
chips (there are availeble from SGS Thomson/Inmos). These are kind of
crosspoint switches (like the ones used in telecommunication). With
these, the network of Transputers can be reconfigured by the system
software, while the system is up and running.
 
Well, face it: the softies just cannot handle systems like this at this
time. It's much to different from classic computer systems.
To me, parallel programming is a more new way of thinking (like object
oriented programming) than just programming a new machine.
 
hase
--
Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP
Dennis had stepped up into the top seat whet its founder had died of a
lethal overdose of brick wall, taken while under the influence of a
Ferrari and a bottle of tequila. (Douglas Adams; the long dark teatime...)
 
------------------------------
 
Date: 1 Nov 89 22:34:53 GMT
From: imagen!atari!kbad@ucbvax.Berkeley.EDU  (Ken Badertscher)
Subject: UNIX -- ATW Speed
 
wolf@cbnewsh.ATT.COM (thomas.wolf) writes:
 
| >>>      4 megabytes of RAM, upgradable to 120 meg
| >>>      With all 4 boards, that is 13 transputers, the machine
| >>>       runs at 10 MIP (= 1/5 Cray)
| >>I guess this should be at least 100 Mips, because ONE T800 can run at 10
| >>Mips.
| ...speed improvements  (if 100MIPS = 1/5 Cray, I guess the program would run
| at 500 MIPS?)
 
MIPS == Meaningless Indications of Processor Speed
--
   |||   Ken Badertscher  (ames!atari!kbad)
   |||   Atari R&D System Software Engine
  / | \  #include <disclaimer>
 
------------------------------
 
Date: 1 Nov 89 22:37:23 GMT
From: imagen!atari!kbad@ucbvax.Berkeley.EDU  (Ken Badertscher)
Subject: unix on the TT
 
depeche@quiche.cs.mcgill.ca (Sam Alan EZUST) writes:
 
[ read in a magazine... ]
| THE DESKTOP MODEL WILL NEVER WORK WITH UNIX
| only the TOWER will....
 
| if this is true, WHY?????
 
Because the magazines don't know what they're talking about.
 
 
--
   |||   Ken Badertscher  (ames!atari!kbad)
   |||   Atari R&D System Software Engine
  / | \  #include <disclaimer>
 
------------------------------
 
Date: 1 Nov 89 23:38:37 GMT
From: portal!cup.portal.com!Xorg@uunet.uu.net  (Peter Ted Szymonik)
Subject: WordPerfect for the Atari ST
 
I can verify the fact that WP still supports the ST 100%, I just
ordered my upgrade yesterday with no problems and the operator knew
exactly what I was talking about and listed all the new features
for me over the phone.  A company that truely sets the standard
for software support!
 
Peter Szymonik
Xorg@cup.portal.com
 
------------------------------
 
Date: 2 Nov 89 03:43:07 GMT
From: portal!cup.portal.com!Vaprak@uunet.uu.net  (John C Foy)
Subject: XFormer 2.55
 
Well, I am baffled...  I have spent two days working with Xformer 2.55
with no sucess.  I seem to be missing the boat as I can not get any of
my 8 bit files into the proper format for the XFormer.  I have the
parallel cable, the lastest ARC of STXF255 and can not get the two to
interact.  When I load DOS 2.5 as a Context, I have tried numerous variations
of the 'A' - Directory command to get the 1050 to kick in and with no luck.
All I get is an Error 138.  Has anyone had any experience with this
combination?
 
Vaprak@Cup.Portal.Com
Sun!Cup.Portal.Com!Vaprak
 
------------------------------
 
End of INFO-ATARI16 Digest V89 Issue #596
*****************************************
=========================================================================