jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) (07/31/87)
I've been porting Kermit-65 from the Commodore world to the 800 environment, and am in the last throes of cleaning it up for first release to the net. (Maybe it'll satisfy some of the folks clamoring for PD terminal emulators...) The question of the day is: How would anyone like to see it posted? In its current form, there's two files, a binary executable of about 24K, and a doc file of about 32K. My preference would be to ARC them up, and distribute the uuencoded archive, but I don't know how many folk might find that inconvenient, or what other cosiderations there are. Also, it's arranged such that the loader for the RS232 handler is a separate load segment, which means you can use your own (mine's an 850). How many people are interested in the kermit module by itself, without the RS232 loader? Finally, is anyone interested in the sources? They're about 400K, so I'm certainly not going to mail them around, but something else can be worked our for anyone who cares. I'm amenable to any suggestions about how best to distribute the thing, but get your responses in soon, I'd like to get this out of the way by next week.
knutsen@aramis.rutgers.edu (Mark Knutsen) (08/01/87)
In article <870731102911.8.JRD@GRACKLE.SCRC.Symbolics.COM> jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) writes: > How many people are interested in the > kermit module by itself, without the RS232 loader? 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: knutsen@rutgers.edu | \\\Atari\\\\\\ | GEnie GE Mail: M.KNUTSEN UUCP: {...}!rutgers.edu!knutsen | \\\\\\Computer | The JACG BBS: (201)298-0161 --------------------------------- \\\\\\\\\Group -----------------------------
hanley@cmcl2.NYU.EDU (John Hanley) (08/05/87)
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 [ Hanley@NYU.arpa ]
"The Ultracomputer: to boldly go in log N time where no N processors have
gone before."