Comment:

Please delete "info-atari" from your distribution list.  The "info-atari"
list has been deleted from Walker-EMH.ARPA.

                                Wendell D. Lane
                                Host Administrator
                                Walker-EMH.ARPA
Forwarded message(s):  
-----------------------------------------------------
Date:  Fri, 31 Jul 87 22:45:43 GMT
From: daemon @ walker-emh.arpa
Subject:  Undeliverable mail
To: InfoMail-Mailer @ walker-emh.arpa
Text:
Mail addressed to Info-Ata@score.stanford.edu has not been sent after 1 days
because score.stanford.edu has been down.  The mailer will continue attempting
to deliver this mail until 4 days have elapsed since the time
you sent it.  At that time, the mail will be returned to you.

------- Beginning of unsent message is below -------

Date: 30 Jul 87 22:28 GMT
From: InfoMail-Mailer @ Walker-EMH.arpa
Subject: Undeliverable Mail
To: Info-Atari8 @ SCORE.STANFORD.EDU

Mail was not delivered to the following users because
there were bad address(es) in TO and/or CC field(s):
        info-atari
UNDELIVERED-MESSAGE:
----------------------------------------------------------------
Received:  from score.stanford.edu by BBN.COM id aa26500; 30 Jul 87 18:00 EDT
Date:  Thu 30 Jul 87 12:28:35 PDT

                        . . .

-------------END OF FORWARDED MESSAGE(S)-------------

<running Turbo Basic on an 800> but

        This looks like a good place to recommend the Boss XL operating
system chip for 800XL owners.  It also acts as a translator, SpartaDOS
runs under it, and I haven't experienced any stray bugs like those
described above for OmniView.
     I have my Boss installed with a public-domain OS switch (Boss
piggybacked on the Atari OS, little switch on the back of the XL
selects which OS to use).  Since the Boss has a built-in software
coldstart, I can always recover the contents of a RAMdisk should the
computer lock up.  I simply switch operating systems and hit System
Reset while holding Start down, then SR again.  Machine reboots
without powering down, and I can reinit the RAMdisk without formatting
it.  (yay SpartaDOS!)

   --Mark Knutsen
--
_________________________________ Jersey\\\\\\\\ _____________________________
ARPA: knut@rutgers.edu       | \\\Atari\\\\\\ | GEnie GE Mail: M.KNUTSEN
UUCP: {...}!rutgers.edu!knutsen | \\\\\\Computer | The JACG BBS: (201)298-0161
--------------------------------- \\\\\\\\\Group -----------------------------

In article <870731102911.8.@GRACKLE.SCRC.Symbolics.COM> j@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) writes:

        I am, and I suspect others are too.  Lots of us are using
interfaces other than the 850, and need to insert the appropriate R:
handler to get things running.  In my particular case, the SpartaDOS
AT_RS232.COM file needs to be loaded to run the ATR 8000 as an R:
device.

  --Mark Knutsen
--
_________________________________ Jersey\\\\\\\\ _____________________________
ARPA: knut@rutgers.edu       | \\\Atari\\\\\\ | GEnie GE Mail: M.KNUTSEN
UUCP: {...}!rutgers.edu!knutsen | \\\\\\Computer | The JACG BBS: (201)298-0161
--------------------------------- \\\\\\\\\Group -----------------------------

In private correspondence with John Dunning the chicken-and-egg problem
came up of getting _a_ Kermit, any Kermit, onto a micro that doesn't have
one.  Once you have even the most kludgeful ancient copy you can always
use it to snag a different version.  Experienced modem users will have
at least one program that can capture stuff coming off the modem and dump
it to disk files; these people will have no problem reading UUDECODE.BAS
and the encoded KERMIT.UUE, and running uudecode to create KERMIT.COM (or
whatever the filenames are).  These people are not who I'm concerned about.
A fair number of people will be relatively new to modeming and will have
only dumb-terminal software, either booted off the modem or from a disk
that came with the modem.  What they need is something that will vacuum
characters off the modem port and tuck them away in memory, and then
write that large buffer out to disk at the end.  The right way to do this,
of course, is to figure out how to get characters back from the modem and
embed that in the main program's loop, but the variety of modems and
interfaces means that you will have to deal variously with packetized/
serialized/parallelized/nybblized data and be able to provide simple
instructions (remember, this is supposed to be a novice user) that say,
here, type in this one-screen BASIC program and do thus-and-so to get
KERMIT.UUE and UUDECODE.BAS onto disk.  Then you're home free.  But
the instructions are bound to miss somebody's modem or interface or be
not quite debugged so that Joe_luser is guaranteed to understand them
and do the right thing, or some exception will pop up, or whatever.
Basically, this would be easier if we had a standard environment.  Hmmmm.

*Everyone* has a PIA.  And just about everyone reading this newsgroup is
reading it using an account on either a university or company computer.
This computer almost certainly has at least _one_ RS232 port that could
be borrowed at least _once_ for a special occasion when you bring in
your Atari to download Kermit to it.  ('Course, you probably have a
perfectly good 232 snaking up to your desk even as you read this and
using it for other purposes it would be _no_ _big_ _deal_.)
SOOooo, having justified my reasoning in the hope of warding off
massive flames about all the rules I'm about to break below, on to
the meat of the article.  This is my proposal:  Have someone write
a short 6502 routine that shifts bits in from port A of the PIA and
on cue calls CIO to write the whole mess out to disk.  Or let BASIC
do the disk I/O, I really don't care.  Following is the level-shifter
that prompted all these musings:

       PIA port A, MSB                                   RS232 RxD, pin 3
       TTL input  ---------------+---------------------  +/- 12 V
                                 |cathode
                                 -
                5 V Zener diode  ^
                                 |anode
          PIA GND ---------------------/\/\/\/\/-------  RS232 SGND, pin 7
                                     10K resistor

1E3 apologies for not posting the joyport pinouts!  John Dunning said he'd
look them up tonight; I just don't have that info, here.

I messed around with this circuit a fair amount before posting it and am
pretty confident that it shouldn't damage any equipment, but don't blame me
when you kill your Atari or your host's terminal driver.  Be particularly
careful that you don't short out the 10K or insert the Zener backwards.
The band on the           +----++                   |\-+
diode marks the      -----|    ||-------       -----| >|-------
cathode end:        anode +----++ cathode     anode |/ +- cathode
I don't see how I could make it much clearer than that.  You've been warned.

The 10K simply protects the RS232 driver from having to drive too much
current.  I initially tried it between RxD and the diode but found that
I couldn't drive the TTL input to ground: the diode would open up and the
input would just float high.  It currently limits current to a little over
a mA.  Feel free to use larger values.

The Zener protects the TTL input from ever seeing any voltage outside the
range (5V, -0.7V).  I used Radio Shack Cat. No. 276-565, a 5.1V Zener, and
had no problems.  Presenting a -0.7V input isn't actually quite Kosher
(you're theoretically never supposed to go below either 0 or -0.3V), but it's
no great stress either.  Ideally you should pick about a 4.2V Zener that
turns on at 0.3V instead of 0.7V.  Don't go above 5.1.

Theory of operation:  When pin 3 is between -12V and -0.7V, the diode
conducts and the TTL input is connected to ground (actually it sees -0.7,
not 0 -- I measured -0.5 for my Zener).  The -12V or whatever is across a
10K, so ~1mA flows.  This is the normal (no data) case.  When pin 3 is
between -0.7V and 5V, the Zener is an open circuit and the TTL input is
connected to pin 3.  Somewhere in this region the TTL will discriminate
between logic low and logic high (my 7400 turned on at pin 3= 0.7V; it also
exhibited a little hysteresis: it didn't turn off until pin 3 dropped to
about 0.2V).  When pin 3 is between 5V and 12V, the diode zeners, preventing
the voltage across it from _ever_ going above 5V.  Excess voltage goes
across the 10K, letting as much as 0.6mA of current flow.  This is the
case for data bits being sent or break being held.

I should mention that I haven't actually hooked this up to a PIA (because
I'm living about 60 miles away from my Atari and we don't have any PIA's
around here), but I _have_ tested this with real 12V RS232's and real low
power Schottkey TTL circuits: a 7400, with input going to a NAND gate and
another one used to double-invert to drive a LED.  Never fried the '00,
and it seemed to work fine from 110 to 9600 baud (use a small (~40 ohm)
resistor on the LED to catch those 9600 flashes).

So, there's the hardware part: 2 whole parts and probably way more explanation
than was necessary.  Now will someone out there with better access to an Atari
than me hack out the timing needed to shift bits in from the PIA and buffer
them up?  No need to do spiffy autobauding or anything.  To get the inital
timing down, I suggest you run a tight loop of fetch data-bit from PIA,
store, increment address to store to, loop.  Looking at how long values
repeat for will give you an idea of how many instructions you can execute
before the bit changes, and how stable that number is.

Good luck!

                   --John Hanley,
 /  /   ____ __  __  System Programmer, Manhattan College [ ..cmcl2!mc3b2!jh ]
/__/ /__ /  /-< /-/  Researcher, NYU Ultracomputer Labs   [  Han@NYU.arpa ]

"The Ultracomputer: to boldly go in log N time where no N processors have
 gone before."

in article <7@shemp.UCLA.EDU>, k@MATH.UCLA.EDU says:

WOW...this sounds like _ALLOT_ of work.  Before I started writing programs,
I would try to convince my friend to buy a $35-$40 XM-301 modem for his
Atari.  You could then download binarys/text to your Mac and transfer them
over to him.

Anyway, to answer your question:
(this stuff comes from _De_Re_Atari_)

Ataris write fixed-length blocks at 600 baud (to tape).

Two frequencies are used:
5327 hz. for a mark (or 1) and
3995 hz. for a space (or 0).

A byte is defined by:

1 start bit (space)
0-7 data bits (marks and spaces)
1 stop bit (mark)

Records should be written to the tape in the form of:

01010101      1st marker
01010101      2nd marker  (markers are for speed measurement)
control byte
128 data bytes
checksum

The control byte is defined as:

$FC  indicates the record is a full 128 byte data record.
$FA  indicates the record is a partial record (less than 128 bytes).
$FE  indicates the record is an EOF.

NEED I SAY MORE?

Thanks a lot to all who responded to my question. I'm all set,
having received lots of detailed data from at least two sources.
I'll try to play with it, realizing very well that it would
be much easier to simply get a disk drive for my friend (as for
the option of sending stuff via modem: if you had anything to
do at all with the Polish telephone system, you wouldn't say a
single bad word about MCI & the like - so that's out. I mentioned
in my first posting that the source of all problems is my friend's
geographic location.)
                              Thanks again -
                                              Eric
-----------------------------------------------------------
I'm sick & tired of editing my incorrect address in the header.
The *correct* one is k@MATH.UCLA.EDU; I have no connection
with the CS Department, except that we breathe the same smog.

In article <4@sugar.UUCP>, p@sugar.UUCP (Peter da Silva) writes:

There seems to be (based on the 16 bit traffic) plenty of reasons to be less
than satisfied with some aspects of ATARI, but the cost of the 65XE compared
to the C64 and the 130XE compared to the C128 is not one of them.

When my old 800 began to bite the dust (~$900) I definitely went for the
extra memory in the 130XE (~$125!).  Ramdisks are very nice on the ATARI.
You can use the extra memory for program/data space, but my guess would be
that most use of the memory is for ramdisk.

Daryl Monge                             UUCP:   ...!ihnp4!ihcae!daryl
AT&T                                        CIS:    72717,65
Bell Labs, Naperville, Ill              AT&T        312-979-3603

The version of SHRINK.COM posted by Paul Kopp, like the previous one I got
from someone else, did not work.  I am beginning to wonder if it is I who
need a SHRINK.  The programs both downloaded OK, uudecoded OK, and... failed
to load.  The error message from DOS in both cases was 136, "Attempt to Read
Past End Of File", which suggests that the original file has a problem with
its load vectors.

Has anyone else experienced this problem with the version of SHRINK.COM
that was posted?  Has anyone else successfully uudecoded and loaded it?

Aside from all that, I STILL don't have a working SHRINK program or
equivalent, so I am unable to post Turbo BASIC / FROST BASIC for those
800 owners who are eagerly awaiting it.  Since we are THIS close to a way
of posting it, however, I would like to urge someone to find a version of
SHRINK or an equivalent program, test it, and e-mail it to me or post it.
Better yet, uuencode it, uudecode it using my UUDECODE.BAS, and test the
decoded version.  If THAT works, then send me the uuencoded version and
there is a fighting chance it will work at my end.  If that fails, maybe
we should ftp it?

Heeeelllllpppp!

-John Sangster / j@mitre-bedford.arpa

For real this time :-)

This is to notify everyone that the 8 bit C compiler I threatened to
post last May will be posted in the next day or two (1 doc + 1 uuencoded
binary).

Steve Kennedy           cbosgd!smk

Mail was not delivered to the following users because
there were bad address(es) in TO and/or CC field(s):
        info-atari
UNDELIVERED-MESSAGE:
----------------------------------------------------------------
Received:  from score.stanford.edu by BBN.COM id aa02171; 3 Aug 87 17:23 EDT
Date:  Mon 3 Aug 87 12:59:30 PDT
Subject:  Info-Atari8 Digest V87 #65
From: Info-Atari8 @ SCORE.STANFORD.EDU
Errors-to:   Info-Atari8-requ@Score.Stanford.EDU
Maint-Path:  Info-Atari8-requ@Score.Stanford.EDU
To: Info-Atari8 Distribution List:
Reply-to:  Info-Ata@SCORE.STANFORD.EDU
Text:
Info-Atari8 Digest   Monday, August  3, 1987   Volume 87 : Issue 65

This weeks Editor: Bill Westfield

Today's Topics:

                   Is anyone else upset at Tramiel?
                    Re: Question for 800XL experts
                    Re: Question for 800XL experts
                                SHRINK
                 Re: Is anyone else upset at Tramiel?

----------------------------------------------------------------------

Date: 26 Jul 87 21:32:55 GMT
From: ptsfa!hoptoad!academ!uhnix1!nuchat!sugar!pe@ames.arpa  (Peter da Silva)
Subject: Is anyone else upset at Tramiel?
To: info-ata@score.stanford.edu

Is anyone else upset at Tramiel submerging the best 6502-based micro on
the market under a so-so 68000-based machine? It's nice to have all that
extra memory, sure, but not if it makes the machine more expensive than
the (ick) C=64? Is there any real advantage to the extra RAM in the 130
over the 800XL?
--
-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)

------------------------------

Date: 2 Aug 87 13:56:34 GMT
From: mtune!codas!novavax!houligan!pk@RUTGERS.EDU  (Paul Kopp)
Subject: Re: Question for 800XL experts
To: info-ata@score.stanford.edu

in article <7@shemp.UCLA.EDU>, k@MATH.UCLA.EDU says:

WOW...this sounds like _ALLOT_ of work.  Before I started writing programs,
I would try to convince my friend to buy a $35-$40 XM-301 modem for his
Atari.  You could then download binarys/text to your Mac and transfer them
over to him.

Anyway, to answer your question:
(this stuff comes from _De_Re_Atari_)

Ataris write fixed-length blocks at 600 baud (to tape).

Two frequencies are used:
5327 hz. for a mark (or 1) and
3995 hz. for a space (or 0).

A byte is defined by:

1 start bit (space)
0-7 data bits (marks and spaces)
1 stop bit (mark)

Records should be written to the tape in the form of:

01010101      1st marker
01010101      2nd marker  (markers are for speed measurement)
control byte
128 data bytes
checksum

The control byte is defined as:

$FC  indicates the record is a full 128 byte data record.
$FA  indicates the record is a partial record (less than 128 bytes).
$FE  indicates the record is an EOF.

NEED I SAY MORE?

------------------------------

Date: 2 Aug 87 22:26:22 GMT
From: k@locus.ucla.edu
Subject: Re: Question for 800XL experts
To: info-ata@score.stanford.edu

Thanks a lot to all who responded to my question. I'm all set,
having received lots of detailed data from at least two sources.
I'll try to play with it, realizing very well that it would
be much easier to simply get a disk drive for my friend (as for
the option of sending stuff via modem: if you had anything to
do at all with the Polish telephone system, you wouldn't say a
single bad word about MCI & the like - so that's out. I mentioned
in my first posting that the source of all problems is my friend's
geographic location.)
                              Thanks again -
                                              Eric
-----------------------------------------------------------
I'm sick & tired of editing my incorrect address in the header.
The *correct* one is k@MATH.UCLA.EDU; I have no connection
with the CS Department, except that we breathe the same smog.

------------------------------

Posted-From: The MITRE Corp., Bedford, MA
To: info-ata@score.stanford.edu
Subject: SHRINK
Date: Sun, 02 Aug 87 22:32:37 EDT
From: j@mitre-bedford.ARPA

The version of SHRINK.COM posted by Paul Kopp, like the previous one I got
from someone else, did not work.  I am beginning to wonder if it is I who
need a SHRINK.  The programs both downloaded OK, uudecoded OK, and... failed
to load.  The error message from DOS in both cases was 136, "Attempt to Read
Past End Of File", which suggests that the original file has a problem with
its load vectors.

Has anyone else experienced this problem with the version of SHRINK.COM
that was posted?  Has anyone else successfully uudecoded and loaded it?

Aside from all that, I STILL don't have a working SHRINK program or
equivalent, so I am unable to post Turbo BASIC / FROST BASIC for those
800 owners who are eagerly awaiting it.  Since we are THIS close to a way
of posting it, however, I would like to urge someone to find a version of
SHRINK or an equivalent program, test it, and e-mail it to me or post it.
Better yet, uuencode it, uudecode it using my UUDECODE.BAS, and test the
decoded version.  If THAT works, then send me the uuencoded version and
there is a fighting chance it will work at my end.  If that fails, maybe
we should ftp it?

Heeeelllllpppp!

-John Sangster / j@mitre-bedford.arpa

------------------------------

Date: 3 Aug 87 01:13:54 GMT
From: ihnp4!ihlpe!da@ucbvax.Berkeley.EDU  (Daryl Monge)
Subject: Re: Is anyone else upset at Tramiel?
To: info-ata@score.stanford.edu

In article <4@sugar.UUCP>, p@sugar.UUCP (Peter da Silva) writes:

There seems to be (based on the 16 bit traffic) plenty of reasons to be less
than satisfied with some aspects of ATARI, but the cost of the 65XE compared
to the C64 and the 130XE compared to the C128 is not one of them.

When my old 800 began to bite the dust (~$900) I definitely went for the
extra memory in the 130XE (~$125!).  Ramdisks are very nice on the ATARI.
You can use the extra memory for program/data space, but my guess would be
that most use of the memory is for ramdisk.

Daryl Monge                             UUCP:   ...!ihnp4!ihcae!daryl
AT&T                                        CIS:    72717,65
Bell Labs, Naperville, Ill              AT&T        312-979-3603

------------------------------

End of Info-Atari8 Digest
**************************
-------

-------------------END OF UNDELIVERED MESSAGE-------------------