derschjo at gmail.com
Mon Aug 7 18:01:51 CDT 2017
On 8/7/2017 3:50 PM, Rod Smallwood via cctalk wrote:
> On 07/08/2017 22:52, Ian S. King via cctalk wrote:
>> On Mon, Aug 7, 2017 at 2:40 PM, Pete Turnbull via cctalk <
>> cctalk at classiccmp.org> wrote:
>>> On 07/08/2017 18:37, Rod Smallwood via cctalk wrote:
>>> So to-morrow connect up a terminal that will do 110 baud and try an
>>>> Next part is interesting. There should be a way to fake a reader /
>>>> and feed in tape images.
>>> There is. Look on Kevin McQuiggin's site:
>>> In the section called "Software", about 1/3 of the way down, look for
>>> send.c or better still new-send.c (I call it rsend, on my system). You
>>> might also find rim.c and the BIN loader useful.
>>> They're also on my webpage, with the corresponding manpages:
>>> That's the easiest place to get the manpages for rim.c, send.c,
>>> Here's the gist (top parts of the manpages):
>>> rim - create RIM-format file from ASCII addr/instr
>>> rim is a very simple converter. It reads in a file containing two
>>> columns of ASCII digits; the first column is a list of addresses (in
>>> octal) and the second is a list of machine instructions (also
>>> Output is a file suitable to feed to the RIM loader on a PDP-8.
>>> send, rsend - send a file in RIM or BIN format to a PDP-8
>>> send and rsend are utilities to transmit a RIM format or BIN format
>>> file from a UNIX (or other) host to a PDP-8 over a serial line. The
>>> PDP-8 should be running the RIM loader routine prior to starting
>>> either of these programs.
>>> Input should be a file in RIM format or BIN format. Output goes to
>>> the host serial port, which should be connected via appropriate
>>> to the PDP-8.
>>> send is a simple version, with built-in serial port settings and a
>>> fixed delay between characters. rsend is more sophisticated; it can
>>> be controlled by command-line options or environment variables, and
>>> can accept input on stdin.
>>> On a Unix (or Linux etc) machine you can pipe the output from rim to
>>> rsend, and if you're using papertape images (of which there are load
>>> on the
>>> net), rsend can strip the headers for you.
>>> Pete Turnbull
>> Once upon a time I wrote a Python program to stand in for an ASR-33,
>> providing both a terminal session and a papertape image reader/punch.
>> N.B.: much PDP-8 software likes 7E1, but PTR/PTP is 8N1. ISTR that even
>> when I fiddled with SLU settings, I couldn't get away from 7E1 for
>> some of
>> the diagnostics. Of course, I've slept since then. -- Ian
> Thank you that's interesting.
> So far to-day I hooked up a three wire RS232 connection to an old
> Compaq notebook and ran msk315 (kermit)
> Next SET BAUD 110
> Then toggle in the print test on the 8/e.
> Yup prints the character set on the notebook
> Then echo test - nope.
> The M8650 probably needs DTR or whatever.
> Three wires was a bit cheeky I guess
> In the hardware docs for the 8/e there's a load of info about the 8650.
> I'll go read that.
Three wires should be enough, no DTR necessary. Double-check your
wiring and the jumpering on the M8650.
> One other thing - I have a working TU58.
> The two cassette drives in a box type with serial interface.
> Now the pdp-8/e DECTapes were also called TU58.
The typical DECtapes used with the PDP-8 were TU56's, a completely
different (and much more rare) beast.
> The M8650 is on the list of what you can connect it to.
> So does the one substitute for the other and raise the possibility of
> booting from tape?
No, they're not substitutes. I'm not aware of any PDP-8 systems booting
and running from a TU58, but I suppose it's not impossible. Mostly the
problem with the TU58 at this point is that (a) the capstan rollers in
your drives are most likely tar, and (b) the rubber parts in the tape
itself have done the same, and (c) the tape itself probably isn't in
great shape either.
More information about the cctech