Postman@UOFMCC.BITNET (11/14/87)
Your mail was not delivered to some or all of its
intended recipients for the following reason(s):
5001 mailbox invalid -> CHARLTO@UOFMCC.BITNET
----------------------------------------------------------------------
Date: Fri, 13 Nov 87 23:30 CST
To: CHARLTO@UOFMCC.BITNET
From: Info-Atari16 Digest <INFO-ATARI16@SCORE.STANFORD.EDU>
Subject: Info-Atari16 Digest V87 #413
Received: by CANADA01 (Mailer X1.24) id 5626; Fri, 13 Nov 87 22:05:30 EDT
Date: Thu 12 Nov 87 12:31:39 PST
Reply-To: Info-Atari16@Score.Stanford.edu
Sender: INFO-ATARI16 Discussion <INFO-A16@CANADA01>
From: Info-Atari16 Digest <INFO-ATARI16@SCORE.STANFORD.EDU>
Subject: Info-Atari16 Digest V87 #413
To: Name Unknown <BUSU@UOFMCC>,
Jim Charlton <CHARLTN@UOFMCC>,
MIKE CHARLTON <CHARLTO@UOFMCC>,
Werner Ens <ENS@UOFMCC>,
Name Unknown <HABKE@UOFMCC>
Info-Atari16 Digest Thursday, November 12, 1987 Volume 87 : Issue 413
This weeks Editor: Bill Westfield
Today's Topics:
binary and source
uudecode Gulam
Re: External Keyboard (Dec LK201)
ST Minix status?
Gulam notes (alpha test v0.01.00) -old
Re: Worst product name award
re: Uniterm 2.0 / BIGformat.acc
Re: high density 3.5" disks
GULAM PROBLEMS
Re: FreeTerm 2.0 -- Doesn't work under MagicSac?
OSS Pascal Wanted
Re: Worst product name award
RE: Info-Atari16 Digest V87 #411
What group?
Re: External Keyboard
----------------------------------------------------------------------
Date: Wed 11 Nov 1987 16:24 CDT
From: <UUCJEFF%ECNCDC.BITNET@forsythe.stanford.edu>
Subject: binary and source
To: <Info-Atari16@score.stanford.edu>
How does one subscribe to the binary and source group for the Atari ST?
Jeff Beer, UUCJEFF@ECNCDC
------------------------------
Date: 11 Nov 87 22:17:35 GMT
From: zen!mercutio.berkeley.edu!c164-2ao@cad.Berkeley.EDU (Duy Le)
Subject: uudecode Gulam
To: info-atari16@score.stanford.edu
I received gulam in three pieces today. Do I need to concatenate these
three uuencoded files and then uudecode the concatenated file?
Thanks
Duy
------------------------------
Date: 11 Nov 87 23:30:50 GMT
From: decvax!minow@ucbvax.Berkeley.EDU (Martin Minow)
Subject: Re: External Keyboard (Dec LK201)
To: info-atari16@score.stanford.edu
My apologies for posting this without summarizing the original article.
However, as it refers to a safety issue, I feel the completeness is
appropriate. In the attached article, Farrell Woods points out that the
(Dec) LK201 keyboard warns the user against using an unapproved cable.
Because he refers to "really cheap cables", the reader may incorrectly
decide that expensive cables would work. While the LK201 cable looks
like a standard modular phone cable, it is build using significantly
heavier gauge wire -- as it carries the power needed by the keyboard.
Ordinary LK201 usage exceeds the rated capacity of standard modular phone
cables. You can order replacement cables from Dec Direct.
Martin Minow
decvax!minow
The above does not represent the position of Digital Equipment Corporation.
In article <105100029@datacube> ftw@datacube.UUCP writes:
>
>Your comments prompted me to look at the bottom of the LK-201 keyboard
>I'm typing on right now. Indeed, it does have a warning about using only
>"approved" cables for keyboard attachment, otherwise, "excessive overheating
>may result in abnormal conditions.". Thanks for pointing that out.
>I can picture a really cheap cable catching fire if the +5 to the keybaord
>gets shorted for some weird reason.
>
>As for number of wires, I'm glad I said _maybe_, since I don't have a 520
>to take apart, old or new. ;-)
>
>
> Farrell T. Woods
>
>Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960
>VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125
>INTERNET: ftw@datacube.COM
>UUCP: {rutgers, ihnp4, mirror}!datacube!ftw
------------------------------
Date: 11 Nov 87 23:48:11 GMT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Subject: ST Minix status?
To: info-atari16@score.stanford.edu
A couple of us here at Utah have been wondering what ever happened to
the port of Minix to the Atari ST. Anybody out there know the current
status of this project?
-Sandra Loosemore
sandra@cs.utah.edu (sandra@utah-cs.uucp)
------------------------------
Date: Wed, 11 Nov 87 12:29:31 EST
From: pyrdc!gmu90x!wmcs!nh!csrobe@uunet.UU.NET (Chip Roberson)
To: info-atari16@score.stanford.edu
Subject: Gulam notes (alpha test v0.01.00) -old
A couple of comments and questions about Gulam.
1) There is a command called 'sx' that is documented by referring you to
a command called 'rx', but rx doesn't exist. Can someone tell me what these
commands do?
2) From ue (emacs) when you type a ~K is 'temporarily' pops you into Gulam
and your editing buffers are not FREED. The manual says to try this but
doesn't say how to return to emacs. So far I only tried running emacs
then ~x~b to the buffer i was editing. Is there a more direct way to return
to your editing after doing a ~z (oops that was supposed to be a ~z not a
~k up there, sorry).
3) Finally, in ue, if you do several delete-backward-words (M-BS) then do
a yank (~Y) your deletes will be restored in reverse order. SO the line,
Delete this line backwards.
becomes
backwards. line this Delete
when you restore.
*~*~*~*~*~*
How does one get to atari-sources to find out what is there and to ultimately
upload or download (correct terminology?) something to/from them or is it
only a part of netnews.
thanks,
-chip
-------------------------------------------------------------------------
Chip Roberson ARPANET: csrobe@icase.arpa
1105 London Company Way BITNET: $csrobe@wmmvs.bitnet
Williamsburg, VA 23185 UUCP: ...!uunet!pyrdc!gmu90x!wmcs!csrobe
-------------------------------------------------------------------------
*(*please note change in UUCP address ~~~~~~~~~~~ seismo is gone*)*
------------------------------
Date: 12 Nov 87 02:53:07 GMT
From: nosc!humu!uhccux!cm450s02@sdcsvax.ucsd.edu (jeff t. segawa)
Subject: Re: Worst product name award
To: info-atari16@score.stanford.edu
In article <618@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes:
>Moses PromiseLAN ? ???
Hmmm. That IS pretty bad. I thought Lotus had the worst name with
"Modern Jazz". After Symphony and Jazz, I can't help but wonder what
the next product will be called. Lotus Heavy Metal, perhaps? Why no one
at Lotus ever thought of calling the new product "4-5-6" is beyond me.
------------------------------
Date: 10 Nov 87 18:00:10 GMT
From: decvax!linus!philabs!sbcs!lean@ucbvax.Berkeley.EDU (Lean L. Loh)
Subject: re: Uniterm 2.0 / BIGformat.acc
To: info-atari16@score.stanford.edu
As was mentioned in a previous posting, Uniterm 2.0 is NOT out yet,
but will be very very soon. So you panicky guys did not missed any
postings.
Uniterm 2.0BETA version can be obtained from the server at Houston,
although I'm not sure if it's supposed to be there. Since the official
version 2.0 will be out very soon now, I think we should just wait.
As i mentioned in my posting of BIGformat.acc, it worked fine for me
on my monochrome although the read/writes are slower. I've used it
for about 2 months now, mostly for storing documents and misc stuff.
If it caused trouble for anyone, I hereby apologize. I posted it
because I got quite a number of request from fellow-netters.
Anyone out there using publishing partner together with Beckemeyers'
C-SHell or GULAM? Please email me. Thanks
--
CSNET: lean@sbcs.csnet
ARPA: lean%suny-sb.csnet@csnet-relay.arpa
UUCP: {allegra, hocsd, philabs, ogcvax}!sbcs!lean
------------------------------
Date: 11 Nov 87 21:04:48 GMT
From: pepper!cmcmanis@sun.com (Chuck McManis)
Subject: Re: high density 3.5" disks
To: info-atari16@score.stanford.edu
The scoop on the high density drives is that they use a data clock that
is twice as fast as the low density drives. On Amiga/Atari/PC-XT type
5.25 and 3.5 inch disks this clock runs at 250Khz, on the AT and PS/2
this clock runs at 500Khz. Exactly double the speed, means you can fit
twice as many sectors on a track and double your storage (720K -> 1440K).
The standard Western Digital minifloppy only controllers will not read
or write this format. The WD1793 and family of dual 8"/5.25" controllers
will given they are supplied with the proper clock. Also, when you double
the bit rate you cram more bits in the same space so your drive mechanism
has to be able to resolve a higher number of flux changes/inch (fci) and
the diskette has to be capable of retaining those flux changes faithfully.
So all you need are a new controller, drive, and diskettes and you're all
set. No I don't if anyone is planning on offering them for the above
mentioned computers (except the AT and PS/2 of course).
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
------------------------------
Date: 11 Nov 87 21:17:25 GMT
From: ihnp4!homxb!homxc!jdn@ucbvax.Berkeley.EDU (J.NAGY)
Subject: GULAM PROBLEMS
To: info-atari16@score.stanford.edu
Has anyone succesfully uudecoded the recent GULAM postings?
I found that all my byte counts were initially 2 bytes larger
than those posted, pesumably due to two extra blank lines at the
end of each file. I deleted these extraneous blank lines, and all
the byte counts matched. But when I try to to uudecode them, I
get the message "Short file", and indeed, my gulam.arc is only
22284 bytes. [My files are correctly named gulam.uaa, etc.]
Any suggestions?
Jonathan Nagy
{ihnp4|allegra|harvard}!homxc!jdn
(201) 615-4349
------------------------------
Date: 12 Nov 87 05:12:30 GMT
From: jcc@ngp.utexas.edu (J. Chris Cooley)
Subject: Re: FreeTerm 2.0 -- Doesn't work under MagicSac?
To: info-atari16@score.stanford.edu
In article <2137@brspyr1.BRS.Com>, tim@brspyr1.BRS.Com (Tim Northrup) writes:
>
> FreeTerm 2.0 which was recently posted to the MacIntosh binaries group
> doesn't appear to work using the MagicSac on the Atari ST. This seems
> strange seeing as the Data Pacific folks tout FreeTerm 1.8 as *the*
> terminal package to use with the Sac.
>
> Does FreeTerm 2.0 work with version 4.5x of the MagicSac driver?
> (I am using 4.36 -- latest from CompuServe)
Isn't MagicSac that thing that needs Apple ROMs to operate?
Where'd you get your ROMs?
------------------------------
Date: 11 Nov 87 22:43:24 GMT
From: dalcs!aucs!870646c@uunet.uu.net (comer)
Subject: OSS Pascal Wanted
To: info-atari16@score.stanford.edu
Hi all, I am in the need of a copy of OSS's Personal Pascal. If there is
anyone out there that has this product and is not using it, could you
please drop a message my way with you phone number, or address that I
could get it from you.
later
Barry
------------------------------
Date: 12 Nov 87 06:14:20 GMT
From: zen!sim.Berkeley.EDU!pchris@cad.Berkeley.EDU (Chris Perleberg)
Subject: Re: Worst product name award
To: info-atari16@score.stanford.edu
In article <1107@uhccux.UUCP> cm450s02@uhccux.UUCP (jeff t. segawa) writes:
>In article <618@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes:
>>Moses PromiseLAN ? ???
>
>Hmmm. That IS pretty bad. I thought Lotus had the worst name with
>"Modern Jazz". After Symphony and Jazz, I can't help but wonder what
>the next product will be called. Lotus Heavy Metal, perhaps? Why no one
>at Lotus ever thought of calling the new product "4-5-6" is beyond me.
Maybe not such a bad name after all. It'll be 40 years before we see
that "Promised LAN" ;-)
------------------------------
Date: Thu, 12 Nov 87 09:35 EDT
From: NARESH SODHA <CS117151%YUSol.BITNET@forsythe.stanford.edu>
Subject: RE: Info-Atari16 Digest V87 #411
To: Info-Atari16@score.stanford.edu
X-Vms-To: IN%"Info-Atari16@Score.Stanford.edu"
q
s
------------------------------
Date: Wed, 11 Nov 87 14:30:15 EST
From: Flash%UMass.BITNET@forsythe.stanford.edu
Subject: What group?
To: INFO-ATARI16@score.stanford.edu
In-Reply-To: atari st <871111125620.0001BFBB.AAAI.MA@Mars.UCC.UMass.EDU>
What group are you talking about? Info-Atari16?
Rick
------------------------------
Date: 12 Nov 87 01:33:14 GMT
From: imagen!atari!portal!cup.portal.com!ANKH@ucbvax.Berkeley.EDU
Subject: Re: External Keyboard
To: info-atari16@score.stanford.edu
Sorry, Mr Glasser...but the new 520's *do* have the mouse joystick ports
in the front. They also have a drive built in. I know, because I bought
one of these for my daughter in July. Also, there is no clumsy transformer
on your desktop. It is a lot different than my 520, which is like yours...
ports on the side. etc,etc.
------------------------------
End of Info-Atari16 Digest
**************************
-------Postman@UOFMCC.BITNET (11/14/87)
Your mail was not delivered to some or all of its
intended recipients for the following reason(s):
5001 mailbox invalid -> CHARLTO@UOFMCC.BITNET
----------------------------------------------------------------------
Date: Sat, 14 Nov 87 01:02 CST
To: CHARLTO@UOFMCC.BITNET
From: Info-Atari16 Digest <INFO-ATARI16@SCORE.STANFORD.EDU>
Subject: Info-Atari16 Digest V87 #412
Received: by CANADA01 (Mailer X1.24) id 5738; Fri, 13 Nov 87 22:09:35 EDT
Date: Thu 12 Nov 87 12:30:49 PST
Reply-To: Info-Atari16@Score.Stanford.edu
Sender: INFO-ATARI16 Discussion <INFO-A16@CANADA01>
From: Info-Atari16 Digest <INFO-ATARI16@SCORE.STANFORD.EDU>
Subject: Info-Atari16 Digest V87 #412
To: Name Unknown <BUSU@UOFMCC>,
Jim Charlton <CHARLTN@UOFMCC>,
MIKE CHARLTON <CHARLTO@UOFMCC>,
Werner Ens <ENS@UOFMCC>,
Name Unknown <HABKE@UOFMCC>
Info-Atari16 Digest Thursday, November 12, 1987 Volume 87 : Issue 412
This weeks Editor: Bill Westfield
Today's Topics:
Double-Click Software
re: why doesn't Freeterm 2.0 work with Magic Sac
Re: new user asking for help.......?
Lies (was: Re: Atari/Perihelion Transputer Machine Spec)
Re: midi to rs232?
PD Smalltalk on AMIGA/ATARI-ST
Problems with new Midi ACIA Transmit Interrupts....
Re: Zmodem. (no <> in P.Partner fonts, GULAM)
Re: high density 3.5" disks
Re: high density 3.5" disks
Re: Mega STs
C++ on th ST
Re: External Keyboard
Worst product name award
----------------------------------------------------------------------
Date: Tue, 10 Nov 87 21:41:01 EST
From: Flash%UMass.BITNET@forsythe.stanford.edu
Subject: Double-Click Software
To: Info-Atari16@score.stanford.edu
Hello,
I recently received the COLOR version of the Double-Click Software
Formatter, version 2.21. Is it possible for someone to send me the MONO
versions of this? What other software is available from these guys?
I used to have the Double-Click Corner Clock, but alas, it doesn't work
with the new roms, so I got rid of it. Any other stuff I should be aware
of?
Rick Flashman
1040 N. Pleasant Street, #381, Amherst, MA 01002. (413) 549-0173
Flash@UMASS.BITNET -or- Flash%UMASS.BITNET@WISCVM.WISC.EDU
R-FLASHMAN on GEnie
------------------------------
Date: Wed, 11 Nov 87 07:56 PDT
From: <CS47011%IDCSVAX.BITNET@forsythe.stanford.edu>
Subject: re: why doesn't Freeterm 2.0 work with Magic Sac
To: Info-Atari16@score.stanford.edu
X-Original-To: Info-Atari16@Score.Stanford.EDU, CS47011
I don't claim to be an expert on the Sac, though I am pretty familiar
with Macs in general. I imagine that Freeterm 2.0 isn't working because
it has been upgraded to work better with the Mac Plus's 128K ROMs. If
routines from the new ROMs are being called, it just ain't going to work
with the Sacs older 64K ROMs. Best advice would be to continue to use
Freeterm 1.8. Failing that, buy a Mac!
Kelly M Hall
CS47011 @ IDCSVAX . BITNET
1> Never go first.
2> Never go last.
3> Never volunteer for anything.
------------------------------
Date: 10 Nov 87 16:45:44 GMT
From: dalcs!water!ljdickey@uunet.uu.net (Lee Dickey)
Subject: Re: new user asking for help.......?
To: info-atari16@score.stanford.edu
In article <5417@jhunix.UUCP> ins_ajcn@jhunix.UUCP (Julio Cesar Navas) writes:
>
> Hey folks! I'm very much new to all of this ...
> 1. UUDECODE - I take it from my perusals of the network that UUDECODE is way
> different from ARC - but how different?
ARC is several things at once... It can combine several files into
one file, gives you a check sum, and, unless you force otherwise, will
compress them according one or another data compression method.
UUENCODE, is a program that takes as input any file (such as a ".TOS"
file or an ARC file, for instance) and produces another that contains
only printable characters. UUDECODE is the inverse of UUENCODE.
If I understand correctly, the use of XMODEM requires use of all 256 8-bit
characters to do a transfer. This may be OK if you are calling from your
computer to another via one direct phone link, as well as
in some other circumstances.
However, some networks, for their own purposes,
respond to control characters, and for that reason, folks have
settled on schemes that move only printable characters. (Hence UUen-
and UUde-code.) Even this has caused some problems because *some*
machines that come in BLUE boxes and use EBCDIC codes are a bit out of
sync with these that use ASCII codes.
> 2. UNITERM - I've seen this mentioned a few times.
> From what I see it seems to be pretty good. Does it have KERMIT?
Yes it is great, and yes, it has KERMIT.
All our mainframes here run KERMIT, even those that come in BLUE boxes.
--
L. J. Dickey, Faculty of Mathematics, University of Waterloo.
ljdickey@watmath.UUCP UUCP: ...!uunet!watmath!ljdickey
ljdickey%water@waterloo.edu ljdickey@watdcs.BITNET
ljdickey%water%waterloo.csnet@csnet-relay.ARPA
------------------------------
Date: 11 Nov 87 01:27:03 GMT
From: pollux.usc.edu!papa@OBERON.USC.EDU (Marco Papa)
Subject: Lies (was: Re: Atari/Perihelion Transputer Machine Spec)
To: info-atari16@score.stanford.edu
> Permission to reprint or excerpt is granted only if the following line
>appears at the top of the article:
Sorry, but this is plain advertising. NO WAY I'll quote the real thing. It
should have been:
Jack TRAMIEL, COPYRIGHT 1987. REPRINTED BY PERMISSION
>workstations. A single transputer can deliver over ten times the power of
>an IBM PC AT. However, there's even greater strength in numbers. You can
>connect two, 10, 100 or even MORE transputers to create a relatively
>low-cost computer workstation with the power of a supercomputer.
False. The "standard" number of Transputers on the ABAQ system is 1 (ONE).
The maximum is 13.
>No firm delivery
>date is set, but late 1988 seems to be the most talked-about time frame.
>From a first-hand view, the crisp, vibrant graphics (such as four separate
>pictures running simultaneously) were drawing crushing crowds.
Not Really. I dropped in twice at the ATARI booth and the smallest crowds
were at the ABAQ setup. Both times I was able to talk with Tim King,
since NOBODY else was around.
-- Marco
------------------------------
Date: 11 Nov 87 00:24:01 GMT
From: imagen!atari!jwt@ucbvax.Berkeley.EDU (Jim Tittsler)
Subject: Re: midi to rs232?
To: info-atari16@score.stanford.edu
In article <8711100411.AA12628@ucbvax.Berkeley.EDU>, AIPS@BRANDEIS.BITNET (Greg
Lindahl [chimps@brandeis.bitnet]) writes:
>
> if the MIDI port is run by some sort of ACIA and is actually some fancy
> sort of rs232 port, could it possibly be reprogrammed a bit to be a
> "normal" rs232?
>
The MIDI port and the ikbd line are each provided by (Motorola) 6850 ACIAs.
They are being clocked with a 500 kHz signal. The MIDI port uses the
divide-by-16 mode of the 6850 to produce 31.25 kbaud, and the ikbd port uses
divide-by-64 to produce 7812.5 baud.
The things that make your suggestion a tad messy:
1. The baud rate divisors provided by the 6850 have no finer granularity
than /16 and /64. This precludes getting "standard" baud rates.
(Unofficial hint: If you were willing to hack up your hardware, you could
separate the MIDI 6850's TxClock and RxClock lines from the 500 kHz signal
and provide them with your own baud rate clock. If you were willing to
live with the restriction that the "MIDI" port would always have the same
baud rate as the MFP serial port, you could probably get away with stealing
the clock from the MFP's timer D output which is used as the MFP baud rate
generator.)
2. There are no modem control lines available on the MIDI output connectors.
3. You will have to convert the MIDI current loop to RS-232C (or whatever
your terminal expects).
Jim Tittsler {ames, imagen, pyramid}!atari!jwt
------------------------------
Date: 9 Nov 87 13:53:54 GMT
From: clyde!watmath!utgpu!bnr-vpa!mike@rutgers.edu (Mike Norman)
Subject: PD Smalltalk on AMIGA/ATARI-ST
To: info-atari16@score.stanford.edu
I'm interesting in finding out if a public domain Smalltalk (source
preferred, of course!) exists for either the Amiga or the ST?
Thanks in advance,
------------------------------
Date: 11 Nov 87 00:54:54 GMT
From: clyde!watmath!utgpu!utcsri!lansd@rutgers.edu (Robert Lansdale)
Subject: Problems with new Midi ACIA Transmit Interrupts....
To: info-atari16@score.stanford.edu
I have just recently finished writing new Midi Transmit and Receive
interrupt drivers for the ST. Testing revealed a problem with the Transmit
side. The test routine would fill up the transmit Midi buffer with 128 Midi
notes (3 x 128 bytes), and would program the Midi ACIA to start interrupting
if there were no data in the buffer previously to the new data being added.
While the buffer was being filled, the ACIA would start interrupting
and buffering the Transmit buffer out to the Midi port. This is what should
happen. What actually happens is that the Midi ACIA Tx interrupts just stop
coming in, even though there is data in the TX buffer. After spending about a
week looking into this problem I realized that this random behaviour was due
(I think) to other interrupts coming in - in particular the 200 hz system
timer and mouse/keyboard interrupts.
It seems to me that these other interrupts, which are also handled by
the MFP chip, are causing the MFP to drop the Midi ACIA's Tx interrupt request,
so my software never sees it. How do I get around this problem? I solved it, in
a crude way, by enabling the Tx interrupts EVERY time I write a byte into the
TX buffer, but this slows the program down from 26ms (only enable them when 1st
byte is written) to 156ms. The cause of the slow down is my program going into
supervisor mode on each call to enable the ACIA Tx interrupts.
So either I fix this problem or resort to non-buffered Midi output. I
am open to the wildest suggestions!
------------------------------
Date: 9 Nov 87 13:45:06 GMT
From: clyde!watmath!utgpu!utcsri!juancho@rutgers.edu (John Buchanan)
Subject: Re: Zmodem. (no <> in P.Partner fonts, GULAM)
To: info-atari16@score.stanford.edu
In article <801@sbcs.sunysb.edu> lean@sbcs (Lean L. Loh) writes:
> Latest (and greatest) version of GULAM is out. I believe Jim Turner
Post it. !Post it. !Post it. !Post it. !Post it. !Post it. !Post it. !
John W. Buchanan Dynamic Graphics Project
Computer Systems Research Institute
(416) 978-6619 University of Toronto
juancho@toronto.CSNET
{allegra,cornell,decvax,ihnp4,linus,utzoo}!utdgp!juancho
--
John W. Buchanan Dynamic Graphics Project
Computer Systems Research Institute
(416) 978-6619 University of Toronto
juancho@toronto.CSNET
{allegra,cornell,decvax,ihnp4,linus,utzoo}!utdgp!juancho
------------------------------
Date: 10 Nov 87 22:28:17 GMT
From: unisoft!hoptoad!dasys1!schuster@ucbvax.Berkeley.EDU (Michael Schuster)
Subject: Re: high density 3.5" disks
To: info-atari16@score.stanford.edu
In article <2923@hcr.UUCP> miken@hcr.UUCP writes:
>
>Does anybody out there in netland know anything about these little wonders,
>aforementioned hardware, and most importantly, how I can make my ST
>use these disks?
These diskettes write 80 tracks x 18 sectors/track. They require a special
drive mechanism whose write bias is adjusted by a special pin on the
cardedge. Similar to the way AT clones enable the 1.2MB 5.25" drives.
A friend and I recently tried an external high density drive (made by NEC)
designed for AT clones. It could read 720K diskettes but little else. It
could not read 1.4 MB PS/2 diskettes at all. Probably the controller is
incapable of recognizing this format - DiskMech said the tracks were
blank.
Perhaps these beasties could be run through a hard disk controller, like
Supra's 10MB floppies. If not - I fear it may be hopeless.
--
l\ /l' _ Mike Schuster {sun!hoptoad,cmcl2!phri}!dasys1!schuster
l \/ lll/(_ Big Electric Cat schuster@dasys1.UUCP
l lll\(_ New York, NY USA DELPHI,GEnie:MSCHUSTER CIS:70346,1745
------------------------------
Date: 10 Nov 87 22:15:27 GMT
From: tektronix!sequent!mntgfx!dclemans@ucbvax.Berkeley.EDU (Dave Clemans)
Subject: Re: high density 3.5" disks
To: info-atari16@score.stanford.edu
The difference between the current ST floppies and the 2 megabyte
ones is similar to the difference between the floppies on an
IBM PC-XT and a IBM PC-AT. Basically the clock rate is doubled,
letting you pack in twice as much information.
The consensus among the hardware people I've talked to is that
the WD 1772 that's currently in the ST can't handle a higher
clock rate. However if you removed the 1772 from the motherboard
and replaced it with a daughter board with appropriate clocks,
controllers, etc. you could get the hardware set up correctly.
The software incompatibilities you'd see would include:
the desktop disk formatter and copier probably wouldn't work
(but there are public domain versions of both of these available)
nothing knows about "switching" densities; i.e. you'd have to
invent some way to dynamically change clock rates
dgc
------------------------------
Date: 10 Nov 87 21:54:50 GMT
From: tektronix!sequent!mntgfx!dclemans@ucbvax.Berkeley.EDU (Dave Clemans)
Subject: Re: Mega STs
To: info-atari16@score.stanford.edu
There are two major causes of incompatibility with the blitter rom's
(as used in the Mega ST's)
Essentially all of the "undocumented" low memory locations have moved.
A MAJOR bug in the read portion of the floppy driver was fixed.
This bug had two symptoms that people might have encountered:
error status might not be correctly reported after a read that
got an I/O error
If running a program that used BIOS calls to directly access the
floppy (for performance), multi-sector reads were not reliable
(assuming that the BIOS listing ATARI sent me as part of the developers
kit accurately represented the old ROM's, the bug was caused by mis-using
a WD-1772 sector read command).
From what I've heard, the floppy read bug fix is what has caused most
compatibility problems; it seems some manufacturers of copy protected
software (mainly games) based their copy protection on a side-effect
of the bug. Based on my experience the other areas aren't as major;
the only packages I know of that were affected were the "twister"
formatter that came from STart and possibly GFA basic.
=============
How much memory you want depends on what you do now, and what you
might want in the future. My system (4 megabytes) normally runs
with slightly under 2 megabytes free. The rest is taken by a 800K
ram disk, a LARGE disk sector cache, a large printer buffer, auto-loaded
programs, desk accessories, etc. The whole conglomeration boots in
under 30 seconds, including the time to load about 400K of files into
the ramdisk.
There are also software packages that want memory; the laser printer driver,
Smalltalk-80, OS-9, IDRIS, etc.
dgc
------------------------------
Date: 10 Nov 87 16:04:28 GMT
From: ihnp4!homxb!homxc!jdn@ucbvax.Berkeley.EDU (J.NAGY)
Subject: C++ on th ST
To: info-atari16@score.stanford.edu
Does anyone know of a C++ compiler for the Atari ST
computers?
Jonathan Nagy
{ihnp4|allegra|harvard}!homxc!jdn
(201) 615-4349
------------------------------
Date: 10 Nov 87 22:22:00 GMT
From: cca!mirror!datacube!ftw@husc6.harvard.edu
Subject: Re: External Keyboard
To: info-atari16@score.stanford.edu
Your comments prompted me to look at the bottom of the LK-201 keyboard
I'm typing on right now. Indeed, it does have a warning about using only
"approved" cables for keyboard attachment, otherwise, "excessive overheating
may result in abnormal conditions.". Thanks for pointing that out.
I can picture a really cheap cable catching fire if the +5 to the keybaord
gets shorted for some weird reason.
As for number of wires, I'm glad I said _maybe_, since I don't have a 520
to take apart, old or new. ;-)
Farrell T. Woods
Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960
VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125
INTERNET: ftw@datacube.COM
UUCP: {rutgers, ihnp4, mirror}!datacube!ftw
------------------------------
Date: 11 Nov 87 01:09:41 GMT
From: spdcc!m2c!applix!scott@husc6.harvard.edu (Scott Evernden)
Subject: Worst product name award
To: info-atari16@score.stanford.edu
Moses PromiseLAN ? ???
------------------------------
End of Info-Atari16 Digest
**************************
-------Postman@UOFMCC.BITNET (11/14/87)
Your mail was not delivered to some or all of its
intended recipients for the following reason(s):
5001 mailbox invalid -> CHARLTO@UOFMCC.BITNET
----------------------------------------------------------------------
Date: Sat, 14 Nov 87 01:44 CST
To: CHARLTO@UOFMCC.BITNET
From: Info-Atari16 Digest <INFO-ATARI16@SCORE.STANFORD.EDU>
Subject: Info-Atari16 Digest V87 #414
Received: by CANADA01 (Mailer X1.24) id 6392; Fri, 13 Nov 87 22:38:28 EDT
Date: Fri 13 Nov 87 12:16:33 PST
Reply-To: Info-Atari16@Score.Stanford.edu
Sender: INFO-ATARI16 Discussion <INFO-A16@CANADA01>
From: Info-Atari16 Digest <INFO-ATARI16@SCORE.STANFORD.EDU>
Subject: Info-Atari16 Digest V87 #414
To: Name Unknown <BUSU@UOFMCC>,
Jim Charlton <CHARLTN@UOFMCC>,
MIKE CHARLTON <CHARLTO@UOFMCC>,
Werner Ens <ENS@UOFMCC>,
Name Unknown <HABKE@UOFMCC>
Info-Atari16 Digest Friday, November 13, 1987 Volume 87 : Issue 414
This weeks Editor: Bill Westfield
Today's Topics:
Re: FreeTerm 2.0 -- Doesn't work under MagicSac?
HP Laserjet Routines
Bugs in MWC? Also, Re: Disk I/O
Re: Zmodem. (no <> in P.Partner fonts, GULAM)
ABSOFT F77 suppliers ?
Re: Re: Binarys+source
Re: FILE I/O
Re: GULAM PROBLEMS
SPICE?????
Wanted: GKS, PD Languages INFO
Re: FILE I/O
sending files to listserv@canada01 -- how?
Hard Disk woes
OS-9 , gulam
RF Modulator for the 1040?
Re: PD Smalltalk on AMIGA/ATARI-ST
----------------------------------------------------------------------
Date: 12 Nov 87 16:00:11 GMT
From: ravi@mcnc.org (Ravi Subrahmanyan)
Subject: Re: FreeTerm 2.0 -- Doesn't work under MagicSac?
To: info-atari16@score.stanford.edu
>>
>> Does FreeTerm 2.0 work with version 4.5x of the MagicSac driver?
>> (I am using 4.36 -- latest from CompuServe)
>
>Isn't MagicSac that thing that needs Apple ROMs to operate?
>
>Where'd you get your ROMs?
You typically just buy them from an apple, or electronics
parts dealer. The Magic Sac is actually quite fussy about wanting to
use (Apple) ROMS (ie. EPROMS don't work).
-ravi
------------------------------
Date: Thu, 12 Nov 87 22:14:41 cst
From: biringer@anl-mcs.ARPA (Dennis Biringer)
To: Info-Atari16@Score.Stanford.EDU
Subject: HP Laserjet Routines
I would appreciate any pointers to programs, public domain or
otherwise, which would allow ST printer output to a HP Laserjet+ printer.
Thanks in advance!
Dennis
------------------------------
Date: Thu, 12 Nov 87 19:15:04 EST
From: Gribnif%UMass.BITNET@forsythe.stanford.edu
Subject: Bugs in MWC? Also, Re: Disk I/O
To: info-atari16@score.stanford.edu
I have recently discovered a few peculiarities (read: what I think are
bugs) in MWC version 2.0.1:
1) Declaration of integers: you would think that
int i = -32768
would work, since this is a valid number in ones-complement
arithmetic, however this invariably results in the compiler message
'integer "i" promoted to long'. Also, changing the "int" to "unsigned
int" yields the same result whenever you are trying to assign
any number >=32768 (without sign, of course).
2) Try this:
main()
{
unsigned long int ii;
int a, b;
ii = 0L;
a = 4097;
b = 8;
ii += a * b;
printf( "%D\n", ii );
}
The result I am lead to expect from all my reading is that the number
4097*8=32776 would be stored in "ii", however the compiler fails to
convert the result of "a*b" to unsigned long before adding it to
"ii", so what gets stored is -32760, the ones complement of "a*b".
The only way you can get this to work correctly is by specifying the
type:
ii += (unsigned)(long)(a * b);
Notice also that I did not use "(unsigned long)", as this does not
work either.
Ok, is it just me, or are these truly bugs? I'd kinda like to know
before I send that small incendiary device off to Chicago...
Also, on the subject of the "f" I/O functions vs. the "F" ones, I
recently used fread to load a large (c300K) file directly into memory from my
hard disk. What I found was that not only did fread take about 4 times as long
to read the file, but it also started overwriting previously loaded data.
I tried loading it in different size blocks (starting at 16K, all the way down
to 128 bytes, which is smaller than the buffer size) with the same results.
Actually, in this case it made much more sense to Fread anyway, since it takes
a long as an argument, as opposed to an unsigned int for fread.
Sorry about the length of this, folx, I'm just making up for all those
times I wanted to put in my two bits and never got around to it...
Dan Wilga
------------------------------------------------------------------------------
AndOr@UMASS.Bitnet "In those days, men were real men, women were real
(Arpa? Don't ask!) women, and small furry creatures from Alpha Centauri
were real small furry creatures from Alpha Centauri"
-- Hitchhikers
------------------------------
Date: 12 Nov 87 19:08:39 GMT
From: lakesys!martin@csd1.milw.wisc.edu (Martin Wiedmeyer)
Subject: Re: Zmodem. (no <> in P.Partner fonts, GULAM)
To: info-atari16@score.stanford.edu
The beta version of GULAM had been posted to comp.binaries.atari.st
not long ago. It is terriffic, only I have been having trouble having it run
out of an AUTO folder at boot. It crashes with two bombs...:-<. The alpha
version ran that way with no trouble. Any suggestions?
Marty
--
| Martin Wiedmeyer - Lake Systems, Milwaukee, WI |
| UUCP: {ihnp4,uwvax}!uwmcsd1!lakesys!martin |
| Disclaimer: "I take the heat for my own (mis)statements!" |
------------------------------
Date: Fri, 13 Nov 87 11:13:33 +0200 (Central European Sommer Time)
From: XBR3D815%DDATHD21.BITNET@forsythe.stanford.edu (WERNER BRAUN, FB08
KERNCHEMIE)
Subject: ABSOFT F77 suppliers ?
To: info-atari16@score.stanford.edu
X-Vms-To: X%"info-atari16@score.stanford.edu",D815
I read the recent postings about ABOFT F77, and it seems to be what i'm
looking for.
Does anybody know where I can buy ABSOFT FORTRAN 77 here in Germany ?
The only advertising i can find in magazines is for prospero f77.
Thanks, Werner
------------------------------
Date: 12 Nov 87 03:50:02 GMT
From: cbosgd!osu-cis!tut!weaver@ucbvax.Berkeley.EDU (Andrew Weaver)
Subject: Re: Re: Binarys+source
To: info-atari16@score.stanford.edu
Jim:
Pluuuuuease do not discontinue the groups. I get your postings fine
and I appreciate your testing of the software. You won't hear any complaints
from this poor college student who appreciates the free software that floats
along here!
Cheers,
--
Andrew Weaver, The Ohio State University College of Business
UUCP: ...!cbosgd!cis.ohio-state.edu!weaver | "This ain'ta my planet,
ARPA: weaver@tut.cis.ohio-state.edu | monkey-boy!"
| - Emilio Lizardo
------------------------------
Date: 13 Nov 87 07:50:40 GMT
From: zen!dorothy.Berkeley.EDU!c9c-eh@cad.Berkeley.EDU (Warner Young (WHY))
Subject: Re: FILE I/O
To: info-atari16@score.stanford.edu
In article <2064@homxc.UUCP> jdn@homxc.UUCP (J.NAGY) writes:
>In article <2862@batcomputer.tn.cornell.edu>, braner@batcomputer.tn.cornell.edu
(braner) writes:
>>
>> The raw GEMDOS functions are faster (due to
>> no buffering) but you should set up your own buffering.
>
>I don't quite understand this. If I have to do my own buffering with
>Fread, while fread does the buffering for me, then the fread call
>appears easier to use. And since the application has to buffer Fread
>calls itself, any speed advantage of Fread (due to no buffering!) is
>negated. So I can see no advantage to the Fread.
>
I wondered about this also, for some time. Then I decided to
test it out. A friend and I each wrote the same program, but
I used the capital F calls, and he the lower case f calls. I
even put more bells and whistles into my program, and the speed
is significantly higher, even accounting for the fact that I
have to do my own buffering and managing.
8K to 16K are the best speeds, to get the most out of your
floppies. I haven't done any tests to see how much difference
buffer size makes on a hard disk (my Supra died!).
\ /
Disclaimer: I'm not associated \ /\ /arner
with the latest revision \/ \__/
of SANITY. |oung
\___|
Last known address: c9c-eh@dorothy.Berkeley.EDU
or
ucbvax!dorothy!c9c-eh
------------------------------
Date: 12 Nov 87 23:42:43 GMT
From: well!dhawk@hplabs.hp.com (David Hawkins)
Subject: Re: GULAM PROBLEMS
To: info-atari16@score.stanford.edu
In the referenced article, jdn@homxc.UUCP (J.NAGY) wrote:
>
>Has anyone succesfully uudecoded the recent GULAM postings?
Yup. I saved all three parts to one file. Edited it with vi
and removed the header of the first part. Searched for the
line that started with include
and deleted it down to the table line of the second part and
make it seamless, i.e. all lines starting with X
and did the same connecting the second part to the third part.
so when I finished the whole file looked the same (after the
first table header) with each line starting with the same character.
Ran uudecode on it.
Ditto for the doc file. arc said they were ok, so I downloaded them
to the ST and de-arced them there. They were fine and I've enjoyed
using the new Gulam.
Hope that helps.
--
David Hawkins {ptsfa,hplabs,ucbvax}!well!dhawk
It is a luxury to be understood. - Ralph Waldo Emerson -
------------------------------
Date: 13 Nov 87 04:08:49 GMT
From: dalcs!aucs!870646c@uunet.uu.net (comer)
Subject: SPICE?????
To: info-atari16@score.stanford.edu
A few weeks ago I saw some people talking about "SPICE", from what I have
been told this is a digital simulator. Has it been ported to the ST, and
if so is it public domain/shareware? If it has been ported, and it is share
ware/pd, could someone please post it to the binaries section. This section
sure seems to be dead when compared to the Mac and IBM side of things.
Why is it so dead.
later
Barry
------------------------------
Date: 13 Nov 87 07:01:00 GMT
From: iuvax!silver!ferneau@rutgers.edu
Subject: Wanted: GKS, PD Languages INFO
To: info-atari16@score.stanford.edu
Does anyone have any information on a public domain GKS for the
ST? I am thinking about creating one for a project, but will
not spend the time if one exists.
Also, What type of public domain languages are available (high-level)
preferred. Possible languages: Fortran (not preferred), Pascal,
or C. I would be writing the aforementioned GKS in a PD language
as it would be used for a college graphics class, and we don't
want to spend a lot of money if we can help it.
--If you have any information on any of the above, please send me
mail, or post it to the net.
-----------------------------------------------------------------
Mark R. Ferneau
(ferneau@silver.cs.indiana.edu)
Indiana University, Bloomington, IN
------------------------------
Date: 13 Nov 87 12:09:38 GMT
From: singer@XN.LL.MIT.EDU (Matthew R. Singer)
Subject: Re: FILE I/O
To: info-atari16@score.stanford.edu
In article <12361@felix.UUCP>, preston@felix.UUCP (Preston Bannister) writes:
>
> There is a much simpler way to find the length of a file. You simply
> do an Fseek to the end of the file. This means of getting the length
> of a file is also usable with Unix and MSDOS (if not always necessary).
> (I'm doing this from memory):
>
> void
> Example (filename)
> char *filename;
> {
> int f, length;
> f = Fopen(name,0);
> if (f > 0)
> {
> length = Fseek(f,0,2); /* seek to end of file */
> Fseek(f,0,0); /* seek back to beginning of file */
> /* we now know the size of the file */
> ProcessFile(f,length); /* for instance */
> Fclose(f);
> }
> }
> --
> Preston L. Bannister
This is a VERY slow way to do it. Especially on LARGE files where
the seek is worse than the open.
Why not just use Fsfirst and read the file size out of the DTA?
This works on both Gemdos and MSdos.
Matt Singer
------------------------------
Date: Fri, 13 Nov 87 11:51:15 EST
From: csrobe@icase.arpa (Charles S. Roberson)
To: info-atari16@score.stanford.edu
Subject: sending files to listserv@canada01 -- how?
i have some files that i was thinking about sending to prog-a16 at
listserv @ canada01. i have a couple of the listserv "memos" but
they aren't very clear. how should i go about sending something
up there to be added to the archives?
thanks,
-chip
-------------------------------------------------------------------------
Chip Roberson ARPANET: csrobe@icase.arpa
1105 London Company Way BITNET: $csrobe@wmmvs.bitnet
Williamsburg, VA 23185 UUCP: ...!uunet!pyrdc!gmu90x!wmcs!csrobe
-------------------------------------------------------------------------
icase.arpa is now at 128.102.23.51. update those host tables (/etc/hosts)
------------------------------
Date: 13 Nov 87 08:13:42 GMT
From: zen!dorothy.Berkeley.EDU!c9c-eh@locus.ucla.edu (Warner Young (WHY))
Subject: Hard Disk woes
To: info-atari16@score.stanford.edu
Well, here's to hoping that someone on the Net can help me with
my hard disk problems. My Supra 20Mb recently took a dislike to booting.
It usually won't autoboot, and even booting from floppy doesn't seem to
work. Most of the time it acts like it wasn't connected, but I have checked
to make sure the cable connections are tight, the power is plugged in okay,
and stuff. It's not too warm, nor too cold. And I've had it do this (i.e.
act like it was disconnected) while I was using it; suddenly I'll get
"Data on drive ?: may be damaged..." pop up.
Has anyone else had this problem? I called Supra's technical
support line, but the guy on the other end wasn't too helpful, and before
I send the entire thing back to Supra, I want to see if it can be fixed
easily. (I'm hoping that it's just something stupid I've overlooked, so
I won't have to mail it.)
Oh, and I have tried hooking it up to another ST. It didn't boot.
\ /
Disclaimer: I'm not associated \ /\ /arner
with the latest revision \/ \__/
of SANITY. |oung
\___|
Last known address: c9c-eh@dorothy.Berkeley.EDU
or
ucbvax!dorothy!c9c-eh
------------------------------
From: AB084%DK0RRZK0.BITNET@forsythe.stanford.edu
Date: Fri, 13 Nov 1987 19:22:29 CET
To: INFO-ATARI16@score.stanford.edu
Subject: OS-9 , gulam
Two questions:
1. Recently I read in the atari digest that a new version of the gulam shell
has been posted. Does anybody know whether I can get it from a LISTSERV?
2. I'm thinking of buying OS-9. Could OS-9 users (on Atari ST) report their
experiences? Has anyone used both, OS-9 and RTOS-UH? Which is better?
Thank you
Michael Eibl
------------------------------
Date: 13 Nov 87 13:50 EST
From: Brantly.henr@Xerox.COM
Subject: RF Modulator for the 1040?
To: Info-Atari16@Score.Stanford.edu
At one time (quite a while ago) there was quite a bit of discussion
about "Someday SOMEBODY is going to come up with the means to drive a TV
from a 1040ST".
I like my monochrome system, but I'm missing out on a lot of pgms that
only support color. I REALLY hate the idea of spending the $300+for a
color monitor.
Soooo, did the idea of a RF Modulator for the 1040 ever take off? Did I
miss something or did the idea get thrown out? I know it's not a real
"hot button" for you guys/gals out there with color systems....
Thanks,
Dennis
------------------------------
Date: 13 Nov 87 14:42:04 GMT
From: cbmvax!bill@rutgers.edu (Bill Koester CATS)
Subject: Re: PD Smalltalk on AMIGA/ATARI-ST
To: info-atari16@score.stanford.edu
In article <174@bnr-vpa.UUCP> mike@bnr-vpa.UUCP (Mike Norman) writes:
>I'm interesting in finding out if a public domain Smalltalk (source
>preferred, of course!) exists for either the Amiga or the ST?
>
>Thanks in advance,
Try Fisk disk #37
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Bill Koester -- CBM >>Amiga Technical Support<<
UUCP ...{allegra|burdvax|rutgers|ihnp4}!cbmvax!bill
PHONE (215) 431-9355
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pleese desrigard eny spealing airors!!!!!!!!!!!
------------------------------
End of Info-Atari16 Digest
**************************
-------Postman@UOFMCC.BITNET (11/16/87)
Your mail was not delivered to some or all of its
intended recipients for the following reason(s):
5001 mailbox invalid -> CHARLTO@UOFMCC.BITNET
----------------------------------------------------------------------
Date: Sun, 15 Nov 87 18:36 CST
To: CHARLTO@UOFMCC.BITNET
From: Info-Atari16 Digest <INFO-ATARI16@SCORE.STANFORD.EDU>
Subject: Info-Atari16 Digest V87 #416
Received: by CANADA01 (Mailer X1.24) id 4929; Sun, 15 Nov 87 19:03:26 EDT
Date: Sat 14 Nov 87 09:14:40 PST
Reply-To: Info-Atari16@Score.Stanford.edu
Sender: INFO-ATARI16 Discussion <INFO-A16@CANADA01>
From: Info-Atari16 Digest <INFO-ATARI16@SCORE.STANFORD.EDU>
Subject: Info-Atari16 Digest V87 #416
To: Name Unknown <BUSU@UOFMCC>,
Jim Charlton <CHARLTN@UOFMCC>,
MIKE CHARLTON <CHARLTO@UOFMCC>,
Werner Ens <ENS@UOFMCC>,
Name Unknown <HABKE@UOFMCC>
Info-Atari16 Digest Saturday, November 14, 1987 Volume 87 : Issue 416
This weeks Editor: Bill Westfield
Today's Topics:
IKBD commands/reads
Re: RF Modulator for the 1040?
uw & different fonts for microemacs
ROM availablity
Re: What's the deal with the repair kits, Neil?
Re: Atari/Perihelion Transputer Machine Spec
file i/o functions
Re: Worst product name award
Re: Hard drive problems
Re: Lies (was: Re: Atari/Perihelion Transputer Machine Spec)
Re: PC-ditto
----------------------------------------------------------------------
From: JEMCCABE%MTUS5.BITNET@forsythe.stanford.edu
Date: 13 November 87 14:19-EST
To: INFO-ATARI16@score.stanford.edu
Subject: IKBD commands/reads
Is there an easy way to get the clock time from the keyboard?
It would be nice to use a clock with one second resolution instead
of GEMDOS's 2 second clock.
I would also like to be able to set this clock.
I know that there is an XBIOS call to send bytes to the keyboard,
but how do we receive them? (I have no idea where the keyboard
packets are sent or what format they have or ... you get the picture. :)
Just in case anyone cares, I'm using Personal Pascal.
Jim McCabe
jemccabe @ mtus5.bitnet
------------------------------
Date: 13 Nov 87 23:01:06 GMT
From: web8b.berkeley.edu!c60a-2ae@jade.Berkeley.EDU (John Kawakami -O~O-,510d
or 260E,6431816,6667734)
Subject: Re: RF Modulator for the 1040?
To: info-atari16@score.stanford.edu
Brantly.henr@XEROX.COM asks
]At one time (quite a while ago) there was quite a bit of discussion
]about "Someday SOMEBODY is going to come up with the means to drive a TV
]from a 1040ST".
And so do I!
I know this can be done; there was a description and a sample of a circuit
that would do this in Bruce "sublogic" Artwick's book on computer graphics.
I believe it was titled _Microcomputer_Graphics_and_Animation_.
I also keep hearing about some company called JNL Technologies that
apparantly made one of these dodads.
This device would be a boon to all the ST owners without RF output (520ST[f]s
have RF output as you all know) who want to videotape some screens.
John "why buy a color screen when I know I'll use it only to play
some games" Kawakami
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JoHn KaWaKaMi alias spectacle -O~O- alias c60a-2ae@widow.berkley.edu |
+ +
| OH NO! CLONES -0~0- | \ -o~o- / -<xxxxx>- |
+ -@~@- O 0 O -()-()- ~from +
| ]OO[ > 0 O Star Trek |
+ O \ / The Drek +
| -P=P- | ~+~ Generation |
------------------------------
Date: 14 Nov 87 01:08:58 GMT
From: moe@athena.mit.edu (Moezeddin K. Karimeddiny)
Subject: uw & different fonts for microemacs
To: info-atari16@score.stanford.edu
I have 2 questions for neters concerning uw and emacs:
1. What exactly is uw ? Is it a window manager ? Is it compatible with X
window
system version 11 ? If it is, can it run over dial-up phone line or does
it need to
have a high speed network to work ?
2. Is it possible to load a 6x10 font to be used with mg(micrognuemacs) or
me(microemacs) (I have a ME version 3.9 that has 40 lines display on
monochrome
with font width of 8 pixels, and also a MG version 1a that can display 50
lines
if I run "hi50.tos" first but the width of the character is 8 pixels so
it is
kinda hard to read). Better yet can proprotional fonts be used instead of
monospaced
fonts. I realised that it is hard to used get a font with width of 6 to
work with
TOS (since 640 divided in to 6 is 106. something) but is it impossible?
Thanks in advance for any helpful information,
Hai
PS: I guess that was more than 2 questions...
------------------------------
Date: 13 Nov 87 02:03:07 GMT
From: imagen!atari!portal!cup.portal.com!Mark_H_Brandwein@ucbvax.Berkeley.EDU
Subject: ROM availablity
To: info-atari16@score.stanford.edu
I recently picked up an ANCIENT 520St with the old TOS-on-disk operating
system. I have looked in every mag I can find, but have not found anyone
who carries the TOS rom chips. Any help on this would be immensly
aappreciated.
M. H. Brandwein
------------------------------
Date: 12 Nov 87 05:49:44 GMT
From: ihnp4!homxb!mtuxo!mtgzz!drutx!druhi!med@ucbvax.Berkeley.EDU (DrapalME)
Subject: Re: What's the deal with the repair kits, Neil?
To: info-atari16@score.stanford.edu
In article <881@atari.UUCP>, neil@atari.UUCP (Neil Harris) writes:
> > In any case, I think that the decision on whether or not to buy this repair
> > kit should be the dealers choice, not a prerequisite of becoming an
> > "authorized service center".
>
> I totally disagree.
>
> One current problem is the slow turnaround from repair centers lacking in
> spare parts.
>
> Having the dealer carry a substantial inventory of these is a good way to
> ensure that our consumers get prompt service.
And I guess that is the real problem here... I talked with
one of the local dealers, and they plan to fix MEGAS just like they
fix 520/1040's ===> "Oh, so your ST is sick? Bring it in and we'll charge
you X dollars, and you can take it with you... Never mind that the
serial number is different." That's right... most dealers here fix STs
by simply replacing them with a new one - very "prompt service", and they
don't need (or intend) to use your $4000 worth of parts!
And besides, who do you think really pays for those part
anyway ;-(. I think that this whole thing boils down to Atari wanting
the "image" (or should that be "look and feel" ;-)) of an IBM
dealer - high prices, fast service, and very few customers who can
afford all of that glitter.
Myron Drapal
AT&T
Denver, Co.
..!ihnp4!druhi!med
------------------------------
Date: 12 Nov 87 15:43:58 GMT
From: umn-d-ub!umn-cs!ems!nis!stag!trb@speedy.wisc.edu ( Todd Burkey )
Subject: Re: Atari/Perihelion Transputer Machine Spec
To: info-atari16@score.stanford.edu
If I hadn't seen the exact same CD-ROM being displayed in several
non-Atari booths (i.e. for the IBM PC) I would be skeptical about
whether it would ever make it out either. My only concern is that
it sells for $999 on the PC. It really was the same unit, too. Only
the case color was different. As for the Transputer, I was really
impressed with the progress they (Perihelion) had made. We have some
Transputer's at work (boards for the AT) that are pretty loosely
integrated (kind of like an exerciser kit), and the ABAQ definitely
had progressed far beyond that. I ALMOST ordered the $100 set of
preliminary manuals to become a developer (I can think of lots of
CAD tools that would be nice to port...Place and Route Previewers,
GDSII compatible layout editors, etc...but I couldn't get any good
feel for what the final costs would be to get a full set of developer
hardware.) If any of people actually do order the kit, let us on the
net know how it looks.
-Todd Burkey
trb@stag.UUCP <--faster path
or tburkey@eta.swde.com <--shaky sun<->apollo (I want Aegis 10!)
P.S. I just got through porting HDSCAN to my Symmetrics, the Apollo,
and the Sun. It runs very nicely on any standard 4.2 system (kind
of slow on the Apollo...usable on a 3000). After I clean up a few
things and add some more sort options (gid/uid/other times?) I
will have to decide if I am going to make it public domain at the
source level or what...BTW, it takes a lot longer to traverse
trees using Unix opendir/readdir/stat calls than it does on the
ST ( 3 secs/30 megs on the ST vs 40 secs/24 megs on the SUN 3/60
with Eagle drives...>2 minutes for the same on the Apollo).
------------------------------
Date: 12 Nov 87 17:29:35 GMT
From: umn-d-ub!umn-cs!ems!nis!stag!daemon@speedy.wisc.edu (Dale Schumacher)
Subject: file i/o functions
To: info-atari16@score.stanford.edu
Hopefully the following will help clear up the confusion about file i/o
functions...
Fread() is one of the macros which calls Gemdos through trap #1. This is
an exerpt from the <osbind.h> file containing there macros:
#define Fcreate(fn,mode) gemdos(0x3C,fn,mode)
#define Fopen(fn,mode) gemdos(0x3D,fn,mode)
#define Fclose(h) gemdos(0x3E,h)
#define Fread(h,cnt,buf) gemdos(0x3F,h,cnt,buf)
#define Fwrite(h,cnt,buf) gemdos(0x40,h,cnt,buf)
#define Fdelete(fn) gemdos(0x41,fn)
#define Fseek(where,h,how) gemdos(0x42,where,h,how)
These functions work much like the standard low-level i/o calls. They
use a small integer (returned by Fcreate/Fopen) called a file handle to
refer to the file (the 'h' parameter in other calls). As was mentioned,
the parameter order is different from the standard low-level i/o calls,
and the 'cnt' parameters are long values rather than the int than is normally
used. The following are macros which define some of the low-level i/o
calls in terms of their Gemdos equivalents.
#define open(filename,iomode) ((int)gemdos(0x3D,filename,iomode))
#define close(h) ((int)gemdos(0x3E,h))
#define read(h,data,len) ((int)gemdos(0x3F,h,((long)(len)),data))
#define write(h,data,len) ((int)gemdos(0x40,h,((long)(len)),data))
#define lread(h,data,len) (gemdos(0x3F,h,len,data))
#define lwrite(h,data,len) (gemdos(0x40,h,len,data))
#define unlink(filename) ((int)gemdos(0x41,filename))
#define lseek(h,where,how) gemdos(0x42,where,h,how)
#define tell(h) gemdos(0x42,0L,h,1)
The creat() call is notably missing from the above due to a bug in the
underlying gemdos 0x3C function which sometimes creates a new file with the
same name as an existing file instead of overwriting the old file. Thus
creat() is implemented as a function something like this:
int creat(filename, pmode)
register char *filename;
register int pmode;
{
register int rv;
rv = Fdelete(filename);
if((rv == 0) || (rv == -33)) /* SUCCESS or FILE-NOT-FOUND */
rv = Fcreate(filename, pmode);
return(rv);
}
Now we come to the fread()/fwrite() functions. These are standard i/o
functions which deal with STREAMS rather than simply with FILE HANDLES.
Unlike the above, these functions provided buffering and translation of
newlines, if desired. They are used with fopen()/fclose() functions.
The fopen() function returns a pointer to a FILE structure, which contains
information about the stream that was opened. The fopen() function also
handles the open()/creat() distinction, creat()ing a file if is doesn't
already exists, etc. As was said before, this kind of processing does
make the i/o a little slower, but also easier to use. The fputc()/fgetc()
functions are normally used with streams (getchar()/putchar() are written
in terms of fputc()/fgetc()) to do i/o a character at a time, while
internally buffering the calls to prevent a system call for every character
processed (which would be slow). The fread()/fwrite() functions do
block i/o on streams, and are buffered just like single characters.
In summary, you should avoid using Gemdos calls directly, since it is not
portable and it doesn't gain you any speed. Use the low-level i/o if you're
really concerned about speed and use the stream i/o functions if you're
doing mostly character or string i/o and/or want the buffering done efficiently
for you.
The preceeding examples were taken from the dLibs public domain standard
library for Alcyon C. This implmentation is far freer of bugs and much
more efficient in general than the Alcyon/DRI libraries. dLibs also contains
many Un*x standard functions which were not included in Alcyon/DRI. You
can get a copy of dLibs with complete source code and documentation by
sending $3 to:
Dale Schumacher
399 Beacon Ave.
St. Paul MN 55104
Of course, I won't refuse donations of >$3, but I need to at least break
even with buying the disks and mailers and sending them.
Dale Schumacher
..ihnp4!meccts!stag!syntel!dal
(alias: Dalnefre')
------------------------------
Date: 14 Nov 87 00:12:41 GMT
From: imagen!atari!portal!cup.portal.com!ANKH@ucbvax.Berkeley.EDU
Subject: Re: Worst product name award
To: info-atari16@score.stanford.edu
Moses *did* reach the Promised Land, but he was not allowed to enter it
because he disobeyed God in the wilderness. He died on a mountain just
outside the land.
------------------------------
Date: 13 Nov 87 23:58:41 GMT
From: imagen!atari!portal!cup.portal.com!ANKH@ucbvax.Berkeley.EDU
Subject: Re: Hard drive problems
To: info-atari16@score.stanford.edu
I logged onto the ICD support bbs and saw their listing of products. The
ADAPTEC controller that they are using is 4070A (note the 'A') This may
seem that is same as 4070, but it's quite possible that it is quite a
different thing than you need. Call their bbs and leave mail or whatever
to see if you can get help. The # is 1-815-968-2229. Good Luck
------------------------------
Date: 13 Nov 87 22:49:07 GMT
From: imagen!atari!neil@ucbvax.Berkeley.EDU (Neil Harris)
Subject: Re: Lies (was: Re: Atari/Perihelion Transputer Machine Spec)
To: info-atari16@score.stanford.edu
> >A single transputer can deliver over ten times the power of
> >an IBM PC AT. However, there's even greater strength in numbers. You can
> >connect two, 10, 100 or even MORE transputers to create a relatively
> >low-cost computer workstation with the power of a supercomputer.
>
> False. The "standard" number of Transputers on the ABAQ system is 1 (ONE).
> The maximum is 13.
Internally.
The ABAQ includes 3 "links", which are 10-megabit-per-second serial
interfaces for talking to off-board transputers.
Jack Lang, in his talk at the Atari press conference at Comdex, supposed a
setup where workers each had their own transputer system on their desks,
with all of them linked together and linked to a separate box containing
many transputers. As an application's need for processing power increased,
it could pull more transputers in. An intriguing concept -- throw the
computer into high gear.
--
--->Neil Harris, Director of Marketing Communications, Atari Corporation
UUCP: ...{hoptoad, lll-lcc, pyramid, imagen, sun}!atari!neil
GEnie: NHARRIS/ WELL: neil / BIX: neilharris / Delphi: NEILHARRIS
CIS: 70007,1135 / Atari BBS 408-745-5308 / Usually the OFFICIAL Atari opinion
------------------------------
Date: 13 Nov 87 22:26:07 GMT
From: phri!dasys1!schuster@NYU.EDU (Michael Schuster)
Subject: Re: PC-ditto
To: info-atari16@score.stanford.edu
In article <24821L9D@PSUVMA> L9D@PSUVMA.BITNET writes:
>Does anyone know how to get PC-ditto to work with a monochrome monitor? I've
>read that a lot of other people are having problems with using monochrome,
>and I am wondering if a fix has been made yet?
The current version works only with a color monitor as the packaging states.
There is a zap to 'turn on' the screen in a monochrome system but it is
NOT a fix and the resulting screen is barely readable.
Version 3.0 is at the duplicating house. It features mono support, Microsoft
mouse emulation, TOS time/date transfer, bug fixes, etc.
To get it -- SEND IN YOUR REGISTRATION CARD.
--
l\ /l' _ Mike Schuster {sun!hoptoad,cmcl2!phri}!dasys1!schuster
l \/ lll/(_ Big Electric Cat schuster@dasys1.UUCP
l lll\(_ New York, NY USA DELPHI,GEnie:MSCHUSTER CIS:70346,1745
------------------------------
End of Info-Atari16 Digest
**************************
-------