test-drb January 2014

test-drb@ccmp.vtda.org

224 participants
263 discussions

Nine technologies that have faded into history

by trash80＠internode.on.net

(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 ++++++++++

12 years, 1 month

ASR33 parity (was: Re: "stop bits")

by bqt＠update.uu.se

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

12 years, 1 month

"Deciphering dissent" at Bletchley Park. TNMOC trustees'statement. | The National Museum of Computing

by robert.jarratt＠ntlworld.com

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 >

12 years, 1 month

DEC Data Retrieval

by bqt＠update.uu.se

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

12 years, 1 month

NEC uPD7201 misfeature, and V.14 (was Re: NEC uPD7201C Datasheet, Pinout?)

by spacewar＠gmail.com

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

12 years, 1 month

Units (was Re: "stop bits"; was: NEC uPD7201 misfeature)

by spacewar＠gmail.com

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!

12 years, 1 month

APEX / XPL0

by john＠yoyodyne-propulsion.net

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

12 years, 1 month

Recovering OS/8 Device Handlers

by rick＠rickmurphy.net

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

12 years, 1 month

Helios for Transputer

by kylevowen＠gmail.com

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

12 years, 1 month

Using two RL02 drives on OS/8? (cont'd)

by charlesmorris800＠centurytel.net

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

12 years, 1 month

← Newer
1
2
3
4
5
6
7
8
...
27
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb January 2014