(Apologies if this appears twice - original sent to wrong address which may
or may not arrive :-)
May be of interest to some list members - appeared in The Age today.
<http://www.theage.com.au/it-pro/business-it/nine-technologies-that-have-fad
ed-into-history-20140128-hva22.html>
++++++++++
Kevin Parker
++++++++++
On 2014-01-29 14:13, Kyle Owen<kylevowen at gmail.com> wrote:
>
> On Wed, Jan 29, 2014 at 1:51 PM, Johnny Billquist<bqt at update.uu.se> wrote:
>
>> >
>> >Eh? What? There was an option for 8-bit clean communication in the ASR33,
>> >as well as other parity choices. But by default an ASR33 have*MARK* parity.
>> >And all older PDP-8 software that I've ever seen also assumes MARK parity.
>> >If you try running older PDP-8 software with your terminal set to even
>> >parity, it will not work.
>> >
>> >If you are ever near an ASR33 with a paper punch, you can easily verify
>> >that it is doing mark parity by just enabling the punch, and check what
>> >codes you get there as you type, with the ASR33 in local mode.
>> >
>> > Johnny
>> >
> I punched this tape on a Model 33 ASR in local mode and it seems to have
> even parity. Bonus points for deciphering it!:)
>
> http://i.imgur.com/R3GPWIS.jpg
Indeed. So you have the parity option installed in your ASR33. I punched
a bit of paper tape on an ASR33 only two weeks ago, which did not.
Unfortunately I didn't keep the paper, but that one certainly did not
have a parity option installed, so it was pretty obvious what the
"default" for parity is on an ASR33...
I'm tempted to decode it, but don't have the time right now...
> I'll try some more software with mark parity, but I believe CHECKMO II (the
> chess game) really wants even parity.
Please do. I would be surprised. But who knows. But I know OS/8 inside
and out (pretty much), and believe me. Older software really do use MARK
parity in general.
(And, like I said, I verified the ASR33 only two weeks ago. Besides, the
ASR33 manuals are online, and you can check it there too. I've read them
in the past, and they also say that it is mark parity.)
Johnny
There is a link to the official BP response on The Register. Sorry not easily able to send link from here
Rob
-----Original Message-----
From: "Dave Caroline" <dave.thearchivist at gmail.com>
Sent: ?29/?01/?2014 17:05
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
Subject: Re: "Deciphering dissent" at Bletchley Park. TNMOC trustees'statement. | The National Museum of Computing
In this context Trustees are the people who make sure a charity/museum
follows its objects ( statements of what the entities primary purpose
is).
They are sometimes independent of the entity or may combine with being
a director/officer of the entity.
Dave Caroline
On 29/01/2014, Pontus Pihlgren <pontus at update.uu.se> wrote:
> You can colour me stupid if you like. But I thought that statement is
> from the TNMOC trustees.
>
> And for a non-Brit, what is a trustee in this context?
>
> /P
>
> On Wed, Jan 29, 2014 at 10:21:12PM +0800, Simon Fryer wrote:
>> That is the official statement.
>>
>>
>> On 29 January 2014 18:25, Pontus Pihlgren <pontus at update.uu.se> wrote:
>>
>> > The picture painted of The Bletchley Park Trust is not very flatering,
>> > have they made an official statement?
>> >
>> > /P
>> >
>> > On Wed, Jan 29, 2014 at 07:57:18AM +0000, Dave Wade wrote:
>> > >
>> > http://www.tnmoc.org/news/news-releases/deciphering-discontent-statement-tn…
>> > >
>> > > Dave
>> > > G4UGM
>> >
>>
>>
>>
>> --
>> Simon
>>
>> --
>> ------------------------------------------------------------------------
>> "Well, an engineer is not concerned with the truth; that is left to
>> philosophers and theologians: the prime concern of an engineer is
>> the utility of the final product."
>> Lectures on the Electrical Properties of Materials, L.Solymar, D.Walsh
>
On 2014-01-29 10:00, Paul Koning<paulkoning at comcast.net> wrote:
>
> On Jan 29, 2014, at 1:39 AM, Johnny Billquist<bqt at Update.UU.SE> wrote:
>
>> >Right. Different PDP-11 OSes use different formats, so it's not really meaningful to ask about "PDP-11 backup". You need to specify which backup format you are talking about.
>> >I think I know of at least four.
>> >
>> >RSX used to use something called DSC (which stood for Disc Save and Compress), which was eventually replaced by BRU.
> There was an irreverent reading for DSC: ?disk smash and corrupt?.
Ayup. I usually pretend I've never heard of DSC. :-)
> I forgot what IAS (and RSX11-D) used. DSC possibly.
Yes. As far as I can remember. I'm also pretty sure IAS got BRU by the end.
>> >I assume RSTS/E had some backup format in the older days. With RSTS/E V9 (I think it was), a new backup utility was created, which is the VMS compatible one.
> V9 sounds right. It was coincident with support for streaming tape drives, which needed asynchronous (queued) I/O to work properly, and that in turn meant serious work on the backup program. The designer decided to adopt the VMS backup format as a good one to use (because of things like XOR block redundancy and CRC data integrity checks).
Makes sense, and it's a nice idea to use the same format. In a way, it
would have been nice if RSX had done the same. BRU, while good in many
ways, is a hairy piece of code. It could have used another rewrite...
> Before then there was a crude program also called Backup (but entirely unrelated) that could do partial backups. And an entirely different program called SAVRES (save/restore) that would do whole disk backup but could, I think, do partial restores. And going back even further, there was ROLLIN ? that?s just a full disk image copy, to another identical disk, or DECtape(s) (or perhaps also magtape, I don?t remember). None of those older programs were compatible with any other OS.
SAVRES and ROLLIN rings bells, now that you mention them. Thanks. :-)
>> >I'm not aware if RT-11 also had some backup tool, but I would assume so.
> There?s always PIP, of course.
Of course. But that implies some structure on the tape that (at least
under RSX) is outside the control of PIP.
But yes, DOS-11 is the plain format for files on tapes used by RT-11, as
far as I know.
Johnny
The NEC uPD7201(A) and Intel 8274 have a misfeature that makes them almost
unusable with modems that employ synchronous modulation (which is almost
all common PSTN modems at bit rates of 1200 bps or higher, except bell 202
and V.23), except when an error control (e.g. MNP or V.42) used between the
modems and flow control is used between the modem and the 7201/8274.
The problem is that due to rate mismatches between the hosts, and between
the host and the modem's sychronous modulation, the receiving end modem may
receive data at a slightly higher rate than it can be sent over the
asynchronous serial line to receiving host. In order to deal with this, the
receiving modem is allowed to send the characters to the receiving host
with a stop bit that is shorter than usual. The stop bits can be as short
as 7/8 of a bit time, or (optionally for an extended signalling range,
which I've never actually uses) as short as 3/4 of a bit time.
This stop bit shaving is part of the ITU-T V.14 standard.
Most UARTs don't have any problem with it, as they typically only sample
the start bit at the middle of the expected bit time. However, the
7201/8274 looks at at least one sample in the bit time, and will consider a
shaved stop bit to be a framing error, which IIRC causes the loss of at
least the next character and usually multiple consecutive characters.
This was a huge problem with 1200 bps and 2400 bps modems on the AT&T 7300
and 3B1 "Unix PC" before the error control protocols (MNP or V.42) became
commonly available in modems.
I learned far more than I (n)ever wanted to know about V.14 when I worked
at Telebit, especially when I was in charge of adding Appletalk Remote
Access Protocol (ARAP) support to the NetBlazer router. ARAP used MNP 3 and
V.42bis compession (a non-standard configuration) on the Macintosh, and
required that any error control (MNP or V.42) and compession be disabled in
the modem. This was done because Apple engineers found at the time that
hardware flow control between the Macintosh and commodity modems was
unreliable, due to limitations of both.
We were implementing a multiline ARAP server on the NetBlazer router and
didn't have enough CPU power to do compession for more than a few lines.
Since we only officially supported use of our own modems on the NetBlazer,
the solution was for us to implement the unusual combination of MNP 3 and
V.42bis in our modems (T1600, T3000, and WorldBlazer), and rely on reliable
flow control between the router and the modem.
Running V.42bis compression used nearly all of the available CPU cycles of
the modem. We also had to deal with another aspect of V.14, stop bit
deletion, which happens when the async data to be transmitted is overspeed
with regard to the modulation. It allows the transmiting modem to
completely discard the stop bit of up to one out of eight consecutive
characters (one of four for dxtended rate), and the receiving side has to
reinsert them. Our modem used an SCC channel of the MC68302 to send clocked
asynchronous characters to the DSP bit pump (when not using V.42 error
control, and V.42 is not used when dping MNP 3). Unfortunately the SCC
channel doesn't know about V.14 stop bit deletion (or the corresponding
reinsertion on receive), so the SCC has to be used in "raw" mode rather
than clocked asynchronous mode, which means that the control CPU has to run
a software UART to convert the character stream to a suitable raw bit
stream for the SCC.
A softwate UART is a piece of cake, you might say, and normally you'd be
right. Unfortunately the modem engineers had written the world's fanciest,
all-singing, all-dancing software UART, which took nearly all of the CPU
time of the control processor. Which was normally fine, since you never
used V.42bis compression over an asynchronous data stream over the
synchronous modulation. Except, of course, when you're running V.42bis
compression over MNP 3 error control to support ARAP.
I offered to write a more efficient software UART, using under 10% of the
CPU instead of over 70%, and the modem engineers claimed that it couldn't
be done. The fundamental problem was that their software UART was in fact
doing everything a single bit at a time. To do it efficiently, you do as
much as possible a byte at a time, using a few kilobytes of data tables to
assist.
Another problem was that the modem control code was written as a series of
tasks that all were called in round-robin sequence all of the time, whether
there was anything to do or not. There was no easy way to determine CPU
utilization because you couldn't do it as the complement of the idle time
because there was no idle time to measure. Even when it was doing nothing
it was running full-tilt.
I'm told that eventually Apple switched from their wacky proprietary ARAP
protocol to PPP, with the modem doing normal V.42 error control and V.42bis
compression, but by then I had moved on to other projects that were less
Sisyphean.
Somewhat by coincidence, before working for Telebit I worked at Apple doing
QA for (among other things) the Macintosh MNP 3 and V.42 drivers used by
Appletalk Remote Access, then known by the codename "976".
Eric
On Jan 29, 2014 11:36 AM, "Paul Koning" <paulkoning at comcast.net> wrote:
> Or "pounds" for mass.
That one seems controversial, depending on which standards organization or
reference you consider definitive. The slug is the Imperial unit of mass,
but the US pound is ambiguous, and the avoirdupois pound is definitely a
unit of mass. All the more reason to ditch the pound for kilograms and
newtons.
> Or "kilograms" for force.
Atrocious!
Anyone got a copy of APEX / XPL0 for the Apple ][?
I don't know why I didn't have it back in the day, it would have been
perfect for what I was trying to do. It probably cost a bunch of
money and I was a kid...
--
Yoyodyne Propulsion Systems: "The Future Begins Tomorrow"
Visit us at: http://www.yoyodyne-propulsion.net
--------
"It's easy to win. Anybody can win."
-- Philip K. Dick, A Scanner Darkly
At 02:32 PM 1/28/2014, Kyle Owen wrote:
> >From the OS/8 Software Support Manual, I can see that the handlers
> should
>be located within blocks 16 through 25, octal. Should I be attempting to
>dump those blocks and try to reverse engineer it that way, or is there a
>way in OS/8 to directly dump each individual handler?
I don't remember any way to do this "directly", but you can write a
tiny program that does a FETCH on a handler, which then loads it into
memory. Now you can open a file and write a copy of that handler to disk.
Reverse engineering it would mean looking at the handler table that
RESORC displays and using that to determine what block on the disk
contains each handler.
-Rick
Hi all,
I am attempting to get Helios running on a 64-core T805-based Transputer
array. This is a one-of-a-kind system with a custom case. It uses a
single-board 486DX with 8MB of RAM on an ISA card for the host system. The
PC front end runs Windows 3.1 or MS-DOS 6. There are eight T805s on eight
custom cards. It doesn't use TRAMs, but I have a feeling these are wired
like such on the board. Pictures of the system can be found here:
http://imgur.com/a/fCA3C
I've been getting all of my Helios editions from
http://www.classiccmp.org/transputer/helios.htm. I first tried version 1.1,
and after copying the contents over to the hard drive from a single floppy
disk, running the server results in an error:
ns : Incompatible version of Rmap 6e627573
ns : error is fatal, exiting.
I finally got 1.31 working on the system by downloading another DOS
executable of the server and playing with some configurations. I also used
ispy and mtest to see the structure of the system, which uses several C004
cross links. Unfortunately, ispy only reports a single T805-25 processor
connected to the host at address 0x150.
Does anyone have any ideas as to why the other 63 T805s and several C004s
aren't showing up?
Thanks in advance,
Kyle
On Tue, 28 Jan 2014 01:55:51 -0600, you wrote:
>From: Rick Murphy <rick at rickmurphy.net>
>To: cctalk at classiccmp.org
>Subject: Re: Using two RL02 drives on OS/8? (cont'd)
>Message-ID: <201401280235.s0S2Z0Es004934 at rickmurphy.net>
>Content-Type: text/plain; charset="us-ascii"; format=flowed
>
>At 04:13 PM 1/27/2014, Charles wrote:
>
>>More info. OS/8 is running on Drive 0. I am able to use RLFRMT (or
>>RL2FMT) to format the pack in Drive 1 (and it does not access or
>>overwrite Drive 0)... so at least SOME part of OS/8 recognizes that
>>there are two RL02 drives!
>
>Those programs access the drive hardware directly and don't use OS/8
>for anything.
>
>
>>BUILD defaults to DSK=SYS if SYS is not changed. BUILD showed
>>initially DSK=RL20:R2A0 which is indeed the same as SYS.
>>
>>However, if a SYS command is issued during BUILD, according to the
>>manual when issuing the BOOT command it is supposed to ask if you want
>>a new DSK or not. This does not happen - it just says "SYS BUILT" and
>>goes back to the dot prompt.
>>
>>I found that I can manually type DSK=RL21:R2A1 in BUILD and it accepts
>>that without error. Then a "SAVE SYS BUILD 0-7577, 10000-17577=0;200"
>>per the manual.
>>At that point, rubbing BUILD again shows DSK=RL21:R2A1. OK so far.
>>
>>But when I ask OS/8 for the directories of each partition on RL21:
>>(R2A1, R2B1, R2C1, R2D1) what is displayed is the corresponding
>>directory of RL20: (R2A0, R2B0, R2C0, R2D0)! The Drive 1 light never
>>flashes.
>
>You can't change DSK to a device that doesn't have an active handler.
>
>And, your unit convention is wrong - OS/8's device name mapping scheme
>is a pain, so you have to be careful how you reference things.
>
>What you should have in BUILD for this configuration is the following
>drivers:
>R0AB which gives devices R20A and R20B
>R0CD which gives devices R20C and R20D
>R01E which gives devices R20E and R21E
>R1AB which gives devices R21A and R21B
>R1CD which gives devices R21C and R21D
>
>If you don't have those, you'll have to LOAD them into build.
>
>So, you need to insert the drivers for drive one:
>$ RUN SYS BUILD
>
>$ IN R1AB:R21A
>$ IN R1AB:R21B
>$ IN R1CD:R21C
>$ IN R1CD:R21D
>$ IN R01E:R21E
>
>If you have enough driver slots, of course. Now device R21A: will go to
>the right place.
>The unit number is hard coded into the drivers so you need to use a
>driver binary built for the right unit number.
> -Rick
Thanks for the info, Rick! That sheds considerable light on my
puzzlement. Although I won't have enough slots to use the "wedgies"
(the small E partitions), 80% of two RL02's is more than enough!
However. Where do I find the R0AB, R0CD, R1AB, R1CD drivers? They
don't appear to be on the diagpack2.rk05 image where all the "good"
OS/8 stuff seems to be. All I see there is:
RL0 .BH 2 4-JAN-81
RL1 .BH 2 4-JAN-81
RL20 .BH 2 4-JAN-81
RL21 .BH 2 4-JAN-81
RL2E .BH 2 4-JAN-81
RL2SY .BH 2 4-JAN-81
RLC .BH 2 4-JAN-81
RLSY .BH 2 4-JAN-81
Of those, RLSY, RL0, RL1 and RLC are for an RL01 drive;
RL2SY, RL20, RL21 (which I have installed) and RL2E (which I omitted
as noted above) are for RL02.
Also the only OS/8 Extensions manual I can locate is the one that
shows how to install and boot an RL01, not a pair of RL02's.... I
think most of the RL02's ended up on PDP-11 systems ;)
-Charles