🚀 go-pugleaf

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
**************************
-------