Thanks! ?I'm definitely enjoying my trips back to 1976. ?My house is early 70s and in the basement with an old table and the terminal, computer and monitor I'm pretty much in 1976. ?I really am hoping to learn how to program using the monitor... still don't completely understand how adding two digits to memory addresses makes it do something.
I'll probably leave the machine be.. it's a bit fragile. ?Might be fun to get the disk card working and get a working drive for it.. although I have no software on disk.
Re: EPROM programming.. wish I could do that with my MSI 6800.. and get it back to stock config. ?The homemade monitor it has is useless!
Sent from my Samsung device
-------- Original message --------
From: Brent Hilpert <hilpert at cs.ubc.ca>
Date: 2016-08-12 9:39 PM (GMT-08:00)
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
Subject: Re: SWTPC 6800
On 2016-Aug-12, at 7:39 PM, Brad H wrote:
> There's no way to have both the MP-C and MP-S cards in the same machine and
> have the computer connected to one at a faster rate of speed is there?
As far the hardware goes, yes, you can have both cards in there operating at different speeds.
Your problem is getting SWTBUG to use the alternative serial card (port) for the loader command, rather than the console port.
To my recollection it (SWTBUG) is not programmed to provide for that.
I have a vague recollection of some monitor that allowed one to redirect the I/O port for the subsequent command or something like that
but it was probably for some other machine (don't have the command list for SWTBUG at hand).
So you could modify SWTBUG (typically with hand-assembled patches) and add a new facility and
burn a new EPROM to give you a monitor tailored for your system config.
Welcome to the world of hobbyist computing, 1976.
If you are importing files into VMS, you need to become familiar with the
EXCHANGE command.
(found via
Google)
http://h20565.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c04623262
It can do stream and carriage control conversions on various RMS fixed formats.
When we first brought up DECnet-DOS network file transfer, we had
some "discussions" with the VMS RMS
engineers that didn't like us doing auto conversions. This was their
"compromise".
Oh and if you are doing serial transfers, yes, keeping the baud rate
low is a good strategy.
I had to spend some time working on the DECnet-DOS DDCMP driver
developing better character overrun recovery strategies. Yes, you may
be coming in via a terminal line, but that line can hiccup from time to time.
Dave.
On 8/12/2016 01:00 PM, cctech-request at classiccmp.org wrote:
>Date: Thu, 11 Aug 2016 16:08:39 -0400
>From: Douglas Taylor <dj.taylor4 at comcast.net>
>To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
>Subject: VAX file format conversion
>Message-ID: <d54db4aa-efc8-d332-971f-57250d5fd0f5 at comcast.net>
>Content-Type: text/plain; charset=utf-8; format=flowed
>
>I have a MicroVax 4000 that I am trying to update the license PAKs on,
>the last time I had valid PAKs on this machine was in 2002 (Hobbyist
>Licenses).
>
>I registered and have received the new Hobbyist License PAKs.
>
>I connected a laptop and transferred the text file using C-Kermit on the
>VAX and hyperterminal on the laptop.
>
>When I go to execute the file, I get an error:
>
>$(a)hobbyist-use-only-va.txt
>
>%RMS-W-RTB 512 bye record to large for user buffer
>
>It appears that when the file was transferred it showed up on the vax
>with fixed length records of 512 bytes, not variable length.
>
>Can I convert the file on the VAX?
>
>Is there a setting for C-Kermit that I need to change?
>
>Is Hyperterminal screwing things up?
>
>Doug
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Interesting. ?I thought the CT-1024 was sort of the intended companion for the 6800 (It came out first, I think). ?I wonder what they expected people to do if they had just those two devices?
I'll probably try cable swap and see how onerous that is. ?I'm hoping to one day acquire an AC-30.. of course then I'd need to find tape files...
Do you know of any good repository for the kind of loader files you can load via serial? ?I've found a few here and there but not all of them.?
Sent from my Samsung device
-------- Original message --------
From: Chris Elmquist <chrise at pobox.com>
Date: 2016-08-12 4:01 PM (GMT-08:00)
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
Subject: Re: SWTPC 6800
On Friday (08/12/2016 at 07:33AM -0700), Brad H wrote:
>
>????
> I've a question. ?I've now got my CT1024 working properly with my 6800.. is there an easy way to load txt loader files into it while it is still connected to the CT? ?Or do I have to load something in via PC first and then swap cables?
The "usual" method in the day was that the paper tape reader on the
M33 teletype connected to the 6800 as the console was used to load your
s-records in through MIKBUG.? When you started the tape reader, it was
just like you were typing it on the TTY's keyboad.
Later, a cassette interface such as SWTPC AC-30 or the PERCOM CIS-30 was
used and it sat between the terminal's RS232 interface and the SWTPC's
console interface.?? When you were loading a tape, the terminal got
disconnected (electrically) and the data coming off the tape was sent
to the console input of the 6800.
So, in simple terms, the cassette interface was in series with the
terminal and could preempt the terminal when loading from tape.? To save
to tape, the output from the 6800 would essentially go to both the tape
and the terminal at the same time.
The modern equivalent is probably an RS232 A/B switch that either
connects your CT-1024 or a PC to the 6800's console.? When you want to
"load a tape" you flip the switch so that the PC connects to the 6800
and sends the s-records in.? After the load is complete, you flip the
switch back and the CT-1024 becomes the console.
You could also diode-OR the transmit data from the CT-1024 and a PC to
the 6800's receive data input and wire the transmit data from the 6800's
output to both the CT-1024 and the PC but this might be sketchy depending
on the PC's RS232 interface characteristics.??? But I have done this
successfully with other RS232 interfaces where I wanted two devices to
be able to send to one receiver without having to physically disconnect
or flip a switch.
Chris
> -------- Original message --------
> From: Pontus Pihlgren <pontus at Update.UU.SE>
> Date: 2016-08-11? 11:27 PM? (GMT-08:00)
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
> Subject: Re: SWTPC 6800
>
> Very interresting read, thank you Ethan.
>
> /P
>
> On Tue, Aug 09, 2016 at 10:55:54AM -0400, Ethan Dicks wrote:
> > On Fri, Aug 5, 2016 at 2:58 PM, Chris Elmquist <chrise at pobox.com> wrote:
> > > On Friday (08/05/2016 at 06:50PM +0000), tony duell wrote:
> > >>
> > >> Am I the only person who rarely, if ever, has RS232 problems?
> > >
> > > No.? ;-)
> >
> > No, but I used to manufacture sync serial hardware and have deep
> > knowledge of how async serial in general, and RS-232/EIA works in
> > particular, and still have all the test gear from 30 years ago.? I get
> > why people find serial comms frustrating and do not take my
> > experiences as "typical".
> >
> > I pretty much don't hook up anything new that isn't on a "traffic
> > light".? I have several - DE9-DE9 for modern stuff, and multiple
> > DB25-DB25 for old and new stuff.? *Mostly*, if you plug everything in
> > and you get at least TxD and RxD to light up, you at least have
> > figured out where the primary gozintas and gozoutas go and can stop
> > adding null-modem adapters.? Past that, you have to know if either end
> > requires hardware handshaking and either plumb the right signals
> > (vintage setup documentation is invaluable for this) or bridge the
> > appropriate lines (documentation again) so that one or both sides
> > _thinks_ there's hardware handshaking.? If you defeat it, you might
> > run into overrun conditions, but at least you should be able to
> > establish basic comms and pass a few characters.? To that end, you do
> > have to match speeds on both sides, and the usual best place to start
> > is 8-N-1 for data bits, parity, and stop bits.? I've run into multiple
> > situations where 7-E-1 or 7-N-1 is the right answer.? With enough
> > experience, the "baud barf" from mismatched speeds takes on an often
> > recognizable pattern that can be used to quickly figure out what the
> > speed ought to be, but lacking instrumentation like a serial analyzer
> > or an oscilloscope, one can try "all the speeds" until cleartext comes
> > through.? I also try the speeds in "most popular order", 9600, 1200,
> > 300, 2400, 4800, 19200, 600... in the hopes of saving time.? Every
> > once in a while, you run into some oddball stuff, like 9600/150, etc.,
> > split speeds from the days of timesharing setups where the CPU wanted
> > to get data to the users as fast as possible but wanted to minimize
> > input interrupts and more closely match the input flow to (slow) human
> > typing speeds.? This wasn't common with microcomputers, but I've seen
> > it with PDP-11 and PDP-8 setups and isn't something to look for first,
> > but it does exist and highlights how strange things can get if all
> > you've ever done is plug a high speed modem into a PC for dial-up
> > internet.
> >
> > One important tip about USB serial dongles (and some laptops DE9
> > serial ports) - I've had problems with some of them and 1970s gear
> > because the EIA/RS-232C (1969) level specification is +5V to +15V for
> > space (0) and -15V to -5V for mark (1) (with +/-3V min sensitivity)
> > and a lot of old gear is expecting +/-12V and not happy with
> > lower-voltage lines and thin wires that don't help signal losses.? One
> > case in particular was a 1977-era Bridgeport Series II CNC mill with a
> > LSI-11/03 CPU and a lot of custom Bridgeport boards.? Everyone else
> > who tried to talk to the Bridgeport before me had zero success.? I
> > checked all the things on the list and finally pulled out the laptop
> > and set up a Dell desktop which worked the first time.? When
> > connecting to pre-1982 gear, I'd definitely try it from a desktop if a
> > laptop is just not working.? Checking the lines with an oscilloscope
> > could also help verify this what's giving the grief (I did not have
> > one handy when we were trying to get that CNC mill working).
> >
> > In terms of serial analyzers, there are several types out there, and
> > the ones that I've had the most time on are the HP 4951/4952 series.
> > There are different models with different features, but if you are
> > going to shop for one, ensure it comes with the "keyboard lid" because
> > that's where the line drivers and serial connectors are.? The large
> > connector on the back goes to a "pod" that happens to snap on the
> > front of the unit when the keyboard is flipped up.? It's much easier
> > to find the base units than loose pods, IME.? Check which pod.? I've
> > seen many with DB25s, which is probably what you want, but I've also
> > seen DC-37 connectors, and non-EIA (RS-232) level shifters.? The good
> > news is that among these different models, the pods should be
> > interchangable, so if you end up picking up 2 units (not unusual) with
> > different base capabilities (some have DC-150 cassette tape, some have
> > 3.5" floppy, plus some minor differences) and only one has a DB25 EIA
> > pod, you can at least migrate it between the units.? I find the serial
> > analyzers invaluable for snooping on the details of what's happening
> > on the wire, but any analyzers I have seen have a handy "autoconfig"
> > button to sniff traffic and configure the line for monitoring, so it's
> > often a quick click to get all the parameters if you don't already
> > know them.? Where they really shine is looking for troubles at the
> > application layer, debugging Kermit or XMODEM traffic that isn't
> > working for any obvious reason.? The advanced stuff you can do is to
> > write programs for some analyzers to simulate a host or a client for
> > software debugging or to reproduce a problem for deeper analysis -
> > this is far beyond the usual "why can't I get this terminal working
> > with this vintage machine" but when you need it, you need it.
> >
> > In summary, I start by scoping the line with an LED traffic light
> > (swapping lines or making custom cables where necessary), then move on
> > the speed and parity settings (and changing the easier-to-change end),
> > then look deeper when the easy stuff doesn't work.? Easy problems take
> > minutes or less.? Hard problems can take a long time to resolve.
> >
> > -ethan
--
Chris Elmquist
I successfully took a (factory new) DEC TSZ07 SCSI tape drive into operation using a Sun SS20 and a Linux box.
Now I do have a big pile of CDC, DEC, HP, Convex and IBM tapes and I'd like to create tape images to file to save the tapes content.
What is the to be preferred procedure to image the tapes, which software to use and which kind of format to store the images?
-- Andreas
Joining the list of "my format" posts ...
Mine also records retry information (because MPE on the HP 3000
optionally reports if a retry was done to get a successful tape read),
and setmarks (which differ from EOFs), as well as error information.
(That retry information is important ... it could indicate a silent loss
of information.)
But, I must admit...it didn't occur to me to store metadata like
a photo of the tape, etc. Nice!
When copying / archiving tapes ...
One important thing to do, depending upon your operating system
and tape drive characteristics of course, is to issue read requests
for a few bytes more than you expect ... because with some OSs and
some kinds of drives, if you ask for X bytes and the record has more than X,
you'll quietly get X and the rest will be discarded. (That came up in a
court case where I was an expert witness ... an alleged 'expert' had
copied a 9-track tape (badly) and lost data because the records were larger
than
he expected, and his copying tool didn't have that simple safeguard in it.)
A second thing is to be somewhat aggressive in reading the 'end' of the
tape.
The backup tapes I frequently encounter supposedly end with two EOFs
in a row ... except for a few that happen to have extra data past that
point :)
(Of course, with 9 track tapes, you run the risk of going off the end!)
(Yes, that begs the question...if you're archiving a tar tape ... do you
*want*
the data past the first EOF? (Which could be part of a prior (and longer)
tar,
or something else.)) (And then there are the people who put tar after tar
after tar on the same tape :)
Stan
>> Something I forgot to note was that this instrument (the 4261A) was
>> actually manufactured for HP by Yokogawa, I'm not too sure where the
>> HP part ends and the Yokogawa begins, maybe it was designed by HP and
>> built by Yokogawa, or maybe the whole thing was a contracted design
>> for HP by Yokogawa.
>
>Yokogawa is not on the list of HP acquisitions.
Well, hardly an acquisition if they (partially) owned it from the start.
http://www.hpmuseum.net/divisions.php?did=39
YEW is still around today, my dad has purchased scopes for the lab at work
>from them. YHP is separate from YEW, I guess.
>The y have used Fairchild for their source.
>
>If so, that explains the high rate of failure.
>
>Years ago when at Intel, we disqualified Fairchild
>
>as a source for parts because of the poor testing
>
>and high failure rates.
>
>Dwight
I seem to remember the 7474 that failed was actually a TI part, but
I'm not entirely sure now.
Something I forgot to note was that this instrument (the 4261A) was
actually manufactured for HP by Yokogawa, I'm not too sure where the
HP part ends and the Yokogawa begins, maybe it was designed by HP and
built by Yokogawa, or maybe the whole thing was a contracted design
for HP by Yokogawa.
>On Sunday, July 24th, 2016 at 22:17:24 -0700, Don North wrote:
> >On 7/24/2016 2:37 PM, Paul Koning wrote:
>
>>> >On Jul 24, 2016, at 11:06 AM, william degnan <billdegnan at gmail.com>
>>> wrote:
>>>
>>>> ...
>>>> Attempts to boot from RT11SJ.SYS under V04.00 of RT-11 with 24K
>>>> bytes of memory were successful. Attempts to boot with 16K bytes of
>>>> memory were also successful. An RK05 was used as the disk drive. The
>>>> error message "Insufficient memory" is displayed, but some useful work
>>>> might be done with just 16K bytes of memory. However, you did not
>>>> ask if useful work being done was one of the criteria?
>>>
>> FWIW, I used to run RT11SJ on an 11/20 with 8 kW (16 kB) of memory
>> and RC11 system disk, in college. That fit with no trouble, enough
>> room to run RT BASIC and a reasonably application program.
>>
>> paul
>
> And it still works today:
>
> PDP-11 simulator V4.0-0 Beta git commit id: 4065f47f
> sim> set cpu 11/05 16k
> sim> sho cpu
> CPU 11/05, idle disabled, autoconfiguration enabled
> 16KB
> sim> att rk0 rt11.dsk
> sim> boot rk0
>
> RT-11SJ V02C-02
>
> .
> .R PIP
> */L
>
> DTMNSJ.SYS 46 27-NOV-75
> DTMNFB.SYS 58 27-NOV-75
> DP .SYS 2 27-NOV-75
> RK .SYS 2 27-NOV-75
> RF .SYS 2 27-NOV-75
> TT .SYS 2 27-NOV-75
> LP .SYS 2 27-NOV-75
> BA .SYS 7 27-NOV-75
> SYSMAC.SML 18 27-NOV-75
> SYSMAC.8K 25 27-NOV-75
> BATCH .SAV 25 27-NOV-75
> EDIT .SAV 19 27-NOV-75
> MACRO .SAV 31 27-NOV-75
> ASEMBL.SAV 21 27-NOV-75
> EXPAND.SAV 12 27-NOV-75
> CREF .SAV 5 27-NOV-75
> LINK .SAV 25 27-NOV-75
> PIP .SAV 14 27-NOV-75
> PATCH .SAV 5 27-NOV-75
> ODT .OBJ 9 27-NOV-75
> VTHDLR.OBJ 8 27-NOV-75
> DEMOFG.MAC 5 27-NOV-75
> DEMOBG.MAC 4 27-NOV-75
> KB .MAC 33 27-NOV-75
> LIBR .SAV 15 27-NOV-75
> MONITR.SYS 46 27-NOV-75
> RKMNFB.SYS 58 27-NOV-75
> RFMNSJ.SYS 46 27-NOV-75
> RFMNFB.SYS 58 27-NOV-75
> DPMNSJ.SYS 46 27-NOV-75
> DPMNFB.SYS 58 27-NOV-75
> DXMNSJ.SYS 46 27-NOV-75
> DXMNFB.SYS 58 27-NOV-75
> DT .SYS 2 27-NOV-75
> DX .SYS 2 27-NOV-75
> CR .SYS 3 27-NOV-75
> MT .SYS 6 27-NOV-75
> MM .SYS 6 27-NOV-75
> PR .SYS 2 27-NOV-75
> PP .SYS 2 27-NOV-75
> CT .SYS 5 27-NOV-75
> DS .SYS 2 27-NOV-75
> FILEX .SAV 11 27-NOV-75
> SRCCOM.SAV 11 27-NOV-75
> DUMP .SAV 5 27-NOV-75
> PATCHO.SAV 33 27-NOV-75
> VTMAC .MAC 7 27-NOV-75
> SYSF4 .OBJ 33 27-NOV-75
> BASIC .SAV 36
> BAS8K .SAV 34
> DEMO .BAS 3
> 51 FILES, 1014 BLOCKS
> 3760 FREE BLOCKS
> *
> .
> .R BAS8K
>
> BASIC V01B-02
> *
>
> READY
>
> OLD
> OLD FILE NAME--DEMO
>
> READY
>
> LIST
>
> DEMO BASIC V01B-02
>
> 10 REM BASIC PROGRAM TO GENERATE N TERMS OF A FIBONACCI SERIES,
> 20 REM THE FIRST TWO TERMS OF WHICH ARE SPECIFIED BY THE USER.
> 30 REM
> 40 REM PRINT IDENTIFYING MESSAGE
> 50 PRINT "PROGRAM TO GENERATE A FIBONACCI SERIES"
> 60 REM
> 70 REM GET THE LENGTH AND FIRST TWO TERMS OF THE SERIES
> 80 PRINT "HOW MANY TERMS DO YOU WANT GENERATED";
> 90 INPUT L
> 100 IF L<>0 THEN 130
> 110 REM IF HE REQUESTS 0 TERMS,TERMINATE EXECUTION
> 120 STOP
> 130 PRINT "WHAT IS THE FIRST TERM";
> 140 INPUT T1
> 150 PRINT "WHAT IS THE SECOND TERM";
> 160 INPUT T2
> 170 REM MAKE SURE L IS NOT NEGATIVE OR TOO LARGE
> 180 IF L<3 THEN 200
> 190 IF L<50 THEN 220
> 200 PRINT L;"TERMS DOES NOT REALLY MAKE SENSE."
> 210 GO TO 80
> 220 REM PRINT THE FIRST TWO TERMS OF THE SERIES
> 230 PRINT "THE REQUESTED SERIES IS"
> 240 PRINT T1
> 250 PRINT T2
> 260 L=L-2
> 270 REM CALCULATE NEXT TERM AND PRINT IT
> 280 N=T1+T2
> 290 T1=T2
> 300 T2=N
> 310 PRINT N
> 320 REM DETERMINE IF SERIES IS FINISHED. IF SO,DO NEXT ONE.
> 330 L=L-1
> 340 IF L<=0 THEN 80
> 350 GO TO 280
> 360 END
>
> READY
>
> RUN
>
> DEMO BASIC V01B-02
>
> PROGRAM TO GENERATE A FIBONACCI SERIES
> HOW MANY TERMS DO YOU WANT GENERATED?4
> WHAT IS THE FIRST TERM?12
> WHAT IS THE SECOND TERM?5
> THE REQUESTED SERIES IS
> 12
> 5
> 17
> 22
> HOW MANY TERMS DO YOU WANT GENERATED?0
>
> STOP AT LINE 120
>
> READY
V02C-02 is just one of the versions (out of about 23 versions) that are
available on the CD image at classiccmp which is available for download.
The V02C-02 version of RT-11 on the CD has 58 files with 1212 blocks,
although the date on all of the files is November 20th, 1975 or a week
earlier.
It would be interesting to compare all of the common files to see if
they are
identical. I suspect that they probably are.
What I am curious about are the two files:
ASEMBL.SAV
EXPAND.SAV
Did these two files do anything special?
For historical purposes, it would also be interesting to also preserve
the files:
BASIC.SAV
BAS8K.SAV
DEMO.BAS
that you have along with the F4.SAV (or FORTRA.SAV) which DEC
released in 1975 - probably V2 of FORTRAN IV. The early versions
of FORTRAN IV are available elsewhere for download
Jerome Fine
