test-drb

test-drb@ccmp.vtda.org

101090 discussions

by n2dvm＠arrl.net

>Message: 6 >Date: Sun, 19 Jan 2014 14:39:21 -0800 >From: Chuck Guzis <cclist at sydex.com> >To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> >Subject: Re: 1541 Alignment disk >Message-ID: <52DC5419.7020309 at sydex.com> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >On 01/19/2014 12:45 PM, geneb wrote: > > > I'm pretty sure Dan is after an analog alignment disk. There was a > > vendor mentioned here a couple of weeks ago, but I don't recall their name. > >Accurite: > >http://www.accurite.com/AAD.html > >--Chuck Ok, which disk would I purchase then?

11 years, 5 months

Fax (was Re: Nine technologies that have faded into history)

by spacewar＠gmail.com

On Jan 29, 2014 9:36 AM, "Paul Koning" <paulkoning at comcast.net> wrote: > > > On Jan 28, 2014, at 10:55 PM, tom <thomas.w.cranston at gmail.com> wrote: > > >> ... > > Legal - In some parts of the world documents faxed are considered legal, as if the had been hand delivered. > > The USA is such a place. I don't recall the exact wording, but basically any setup that scans a physical document, transfers a representation over a telecommunication system, and recreates it as s physical document again meets the US legal definition of facsimile. There doesn't have to be a "fax machine" as you would normally consider it, and Internet email should qualify for the telecommunication, but if the document doesn't start and end in physical form, it isn't a fax. In other words, if I sign a paper contract, scan it, email it to someone, and they print it, it has been faxed. But if I start with a PDF file, sign it in a graphics program, and email that, it has not been faxed because it did not originate as a physical document. If the PDF was originally a scan of a paper document, but I fill it in digitally, then email it, that's not a fax because the electronic document is not an accurate, unaltered representation of a physical document. [I'm not a lawyer, so take this with a suitably large grain of salt.]

11 years, 5 months

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

11 years, 5 months

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

11 years, 5 months

"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 >

11 years, 5 months

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

11 years, 5 months

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

11 years, 5 months

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!

11 years, 5 months

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

11 years, 5 months

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

11 years, 5 months

Jump to page:

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