test-drb March 2016

test-drb@ccmp.vtda.org

189 participants
229 discussions

Honneywell multics? from panels. the inline phots in this message folks -smecc

by jnc＠mercury.lcs.mit.edu

> From: Mouse >> simulating a segmented machine on a non-segmented machine, i.e. one >> with large unidirectional addresses (segmented being a >> bi-directionally addressed machine) - [...] > Hm, "unidirectional" and "bidirectional" are terms I'm having trouble > figuring out the meaning of here. You seem to be using them as, > effectively, synonyms for "non-segmented" and "segmented" Yes. > but I don't see any way in which directionality makes any sense for > either, so I can only infer I'm missing something. Imagine a graphic model of the memory in non-segmented, and segmented, machines. The former can be modeled as a linear array of memory cells - hence 'uni-directional'. The latter can be modelled by a two-dimensional array - segment number along one axis, word/byte within segment on the other - hence 'bi-directional'. Maybe 'uni-axis' or 'bi-axis' would have been a bit more techically correct, but 'uni-directional' and 'bi-directional' were the first terms that came to mind - and I didn't think of how they could be confusing (in terms of their common meanings, when used for flows). Sorry! Noel PS: I'm trying to remember all my thoughts about simulating a segmented memory with a large flat address space. One was that one can prevent pointer incrementing from 'walking' from one segment into another by leaving a 'guard band' of a few empty pages between each 'segment'. However, this points out an issue with such simulation: one cannot easily grow a 'segment' once another 'segment' has been assigned space above it.

8 years, 9 months

OT: where I've landed

by isking＠uw.edu

Hi all, I informed the list when I left the Living Computer Museum, so it seems appropriate to tell you where I've landed. My new employer was in the news this week: http://arstechnica.com/science/2016/03/behind-the-curtain-ars-goes-inside-b… The second photo is the view from where I ate lunch yesterday. The fun literally never stops.... living the dream! -- Ian PS: of course I'm finishing my doctorate - I'm kind of vested in it by now. :-) -- Ian S. King, MSIS, MSCS, Ph.D. Candidate The Information School <http://ischool.uw.edu> Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical Narrative Through a Design Lens Archivist, Voices From the Rwanda Tribunal <http://tribunalvoices.org> Value Sensitive Design Research Lab <http://vsdesign.org> University of Washington There is an old Vulcan saying: "Only Nixon could go to China."

8 years, 9 months

OKI if800 CP/M

by silent700＠gmail.com

Does anyone have, or has anyone used, one of these machines? Specifically the M10/M20 models, with 5.25" disks? I have a vendor box here with manual and CP/M 2.2 boot disk for the if800 and I've been trying to make a usable[1] image of the disk, currently with the Kryoflux and their dtc conversion tool. I sent the flux reads of the disk off to the KF team and they found it interesting enough to study, but there is precious little documentation out there about this machine, much less its disk format. Looking at the scatter plots of the magnetic flux on the disk, I can see that it's 40 track and double sided. Converting the dump to a DS/DD MFM disk image yields many warnings and errors, but also a file with plenty of discernible strings, so that's at least on the right track. Images of reads of the two sides done separately show alternating fragments of the strings of the full read, telling me that it is a contiguous volume using both sides and not two single-sided volumes. One ad I found (mostly in Japanese,) suggests that the if800 drives are 280K. That's an odd number (to me) for a 5.25" disk. -j [1] I have neither the real machine nor an emulator to use them, so this is mostly just an academic exercise in learning about disk formats and disk imaging, for now. But AIUI, if the disk's attributes are known, it should be browsable with a tool like cpmls from the CPMTools package.

8 years, 9 months

DEC RK05 Emergency Retract Batteries

by bob＠theadamsons.co.uk

Interestingly(?) both my RK05 and RK05J had an assembly of 3, not 4, 2/3rd AA NiCd cells for retract, completely decayed of course. I replaced them with 3 discrete tagged NiMh AA cells (plenty of headroom) soldered and shrinkwrapped. They work fine, lots of retract force. The clip which holds them is shaped for only 3 cells so it seems as though there were at least 2 variants. I read the circuit diagram and could see that it would make little difference whether it was NiCd or NiMh (or for that matter 3 or 4 cells). I think DEC were a bit overgenerous with the trickle current (though IIRC NiCds were rather leakier back then). > From: tony duell <ard at p850ug1.demon.co.uk> > > The DEC RK07 (and I assume RK06) used 8 1/2 AA cells in a pack (like > 2 RK05 retract batteries in series). When I replaced those, I used 2 of > the cordless telephone batteries (that have been recommended for > the RK05) in series. > > -tony

8 years, 9 months

Honneywell multics? from panels. the inline phots in this message folks -smecc

by jnc＠mercury.lcs.mit.edu

> From: Charles Anthony > I desperately want to port Multics to a modern architecture Funny you should mention this! Dave Bridgham and my 'other' project (other than the QSIC) is something called iMucs, which is a Multics-like OS for Intel x86 machines. The reason for the x86 machines is that i) they have decent segmentation support (well, not the very latest model, which dropped it since nobody was using it), and ii) they are common and cheap. The concept is to pretty much redo Multics, in C, on the x86. The x86's segmentation support is adequate, not great. The Multics hardware had all those indirect addressing modes that the compiler will have to simulate, but the machines are now so freakin' fast (see simulated PDP-11's running at 100 times the speed of the fastest real ones - on antique PC's), that shouldn't be a huge problem. We did identify some minor lossage (e.g. I think the maximum real memory you can support is only a couple of GB), but other than that, it's a pretty good match. The x86 even has rings, and the description sounds like it came out of the Multics hardware manual! Although I have to say, I'm not sure rings sare what I would pick for a protection model - I think something like protection domains, with SUID, are better. (So that e.g. a cross-process callable subsystem with 'private' data could have that data marked R/W only to that user ID. In 'pure' Multics, one can move the subsystem/data into a lower ring to give it _some_ protection - but it still has to be marked R/W 'world', albeit only in that lower ring, for other processes to be able to call the subsystem.) It will need specialized compiler support for cross-segment routine calls, pointers, etc, but I have a mostly-written C compiler that I did (CNU CC is large pile, I wouldn't touch it with a barge-pole) that I can re-purpose. And we'll start with XV6 to get a running start. There would be Standard I/O, and hopefully also something of a Unix emulation, so we could take advantage of a lot of existing software. Anyway, we've been focused on the QSIC (and for me, getting my 11's running), but we hope to start on iMucs in the late spring, when Dave heads off to Alaska, and QSIC work goes into a hiatus. Getting the compiler finished is step 1. > but there is a profound road-block: the way that Multics does virtual > memory is very, very different, and just does not map onto current > virtual memory architecture. You refer here, I assume, to the segmentation stuff? > then you need to extend the instruction set to support the clever > indirect address exceptions that allow directed faults and linkage > offset tables I think the x86 has more or less what one needs (although, as I say, some of the more arcane indirect modes would have to be simulated). Although my memory of the details of the x86 is a bit old, and I've only ever studied the details of how Multics did inter-segment stuff (in Organick, which doesn't quite correspond to Multics as later actually implemented). > Then there is subtle issue in the way the Multics does the stack .. > This means that stack addresses, heap address and data addresses are > all in separate address spaces Well, Multics had (IIRC) 4 segment registers, one for the code, one for the stack, one for the linkage segment, and I don't remember what the 4th one was used for. (I don't think Multics had 'heap' and 'data' segments as somone might read those terms; a Multics process would have had, in its address space, many segments to which it had R/W access and in which it kept data.) But the x86 has that many, and more, so it should be workable, and reasonably efficient. > I think it is possible to move them all into the same space You wouldn't want to put them all in the same segment - that's the whole point of the single-level-store architecture! :-) Or perhaps I'm misunderstanding your point, here? > Also, Multics stacks grow upward -- great for protection against buffer > overrun attacks, but a pain in a modern architecture. Sorry, I don't follow that? Why does the stack growth direction make a difference? It's just a convention, isn't it, which direction is 'push' and which is 'pop'? Noel

8 years, 9 months

Honneywell multics? from panels. the inline phots in this message folks -smecc

by jnc＠mercury.lcs.mit.edu

> From: Mouse > Well, what was the largest virtual memory space available on various > machines? I have thought, on occasion, about simulating a segmented machine on a non-segmented machine, i.e. one with large unidirectional addresses (segmented being a bi-directionally addressed machine) - in fact, I think it was in the context of the VAX that I went through this mentally. I don't recall any more the exact outcome of my mental design processes (it was a _long_ time ago), but I have this vague recollection that it could sort of work, but that it would be ugly (as in, the compiler would have to simulate cross-segment pointers, etc - they don't look just like normal pointers as there has to be provision for binding them when first used, etc). > Now that 64-bit address space is becoming common Large unidirectional machines do have one advantage, which is that the canonical flaw of single-level-storage on a segmented machine is that really large objects don't fit in a single segment, unless you have ridiculously large addresses (e.g. 80 bit). When simulating segments on a unidirectional machine, one can of course make any individual segment as large as one likes - up to the total size of the unidirctional machine's address space. Noel

8 years, 9 months

Fw: Trashed PDP-11/70 system for sell in Pittsburgh

by tosteve＠yahoo.com

See below::: > >> On Feb 23, 2016, at 5:24 PM, Christopher Eddy <ceddy at nb.net> wrote: >> >> I have an 11/70 that I want to find a new home for.. >> 11/70 CPU chassis, with CPU rack and cards in place. The CPU control panel is damaged.. all of the toggle caps and switches have been smashed. No paper or tape drives. >> 11/70 memory chassis, with rack and cards in place. >> Also, I have a separate 11/70 rack, with no cards, but with a control panel attached. Many WW pins are bent. The caps and switches are again very damaged. >> I have not powered it, and don't think that I should. I am partway through a couple of projects to restore it, mainly a project to replace the power supplies with PC style supplies, and another project to replace the switch panel with a touch panel + USB that would allow the unit to operate without the switches. I did not complete either project. >> As it is an incomplete system, or at least the CPU/memory is there, but not complete enough to operate, I was planning to augment it with these projects in order to operate it as is. >> The ribbon cables that join CPU to memory were just cut in two. >> Someone was very rough with it. >> I would like to sell it to someone that wants to proceed with the restoration of it.. but have no idea where to begin. >> I am in Pittsburgh. >> Thanks! >> Chris~ >> 412-369-9920 >> 412-916-7664 >>

8 years, 9 months

Computer for sale

by sellam＠vintagetech.com

I am raising capital for a forthcoming venture dealing with vintage computers and thus am putting the following systems up for sale. Please visit the URL for photos and information (located in the Information file, if applicable) for each system. All prices are negotiable. PDP 8A System 1: http://vintagetech.com/sales/Big%20Iron/PDP%208a/Chassis%201/ Asking $900 System 2: http://vintagetech.com/sales/Big%20Iron/PDP%208a/Chassis%202/ Asking $450 System 3: http://vintagetech.com/sales/Big%20Iron/PDP%208a/Chassis%203/ Asking $300 Heathkit H11 http://vintagetech.com/sales/Big%20Iron/Heathkit%20H11/ Asking $750 ADM 3A http://vintagetech.com/sales/ADM%203A/ Asking $250 Friden 132 http://vintagetech.com/sales/Friden%20132/ Asking $1,500 ATR8000 (Atari 800 Z80 coprocessor box for running CP/M) http://vintagetech.com/sales/Micros/ATR8000/ Asking $500 Digital Microsystems CP/M computer http://vintagetech.com/sales/Micros/Digital%20Microsystems/ Asking $350 Integrated Computer Systems Microprocessor Training Lab http://vintagetech.com/sales/Micros/Integrated%20Computer%20Systems/ Asking $400 SWTPC 6800 http://vintagetech.com/sales/Micros/SWTPC%206800/Information Asking $950 Teleram 3000 http://vintagetech.com/sales/Micros/Teleram%203000/ Asking $650 Fulcrum Computer Products IMSAI 8080 clone http://vintagetech.com/sales/S-100/Fulcrum/ Asking $1,200 MITS Modem boardset http://vintagetech.com/sales/S-100/MITS%20Modem/ Asking $250 Polymorphic Systems POLY-88 http://vintagetech.com/sales/S-100/Polymorphic%20Systems%20POLY88/ Asking $1,250 Wang 380K Programmable Calculator with 362E terminal http://vintagetech.com/sales/Wang%20362E/ Asking $1,100 Please also see additional systems for sale (including a pair of IBM 3420 tape drives with 3803 controller) in the photos here: http://vintagetech.com/sales/Big%20Iron/ Please inquiry directly for more information. Thanks! -- Sellam Abraham VintageTech ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintagetech.com Whatsoever a man soweth, that shall he also reap. The truth is always simple. * * * NOTICE * * * Due to the insecure nature of the medium over which this message has been transmitted, no statement made in this writing may be considered reliable for any purpose either express or implied. The contents of this message are appropriate for entertainment and/or informational purposes only. The right of the people to be secure in their papers against unreasonable searches and seizures shall not be violated.

8 years, 9 months

A gold mine for anybody in Austin...

by barythrin＠gmail.com

Ditto. ?Talked to him last year some time. I think he's a nice guy and cou himself in a situation that any of us and some do end up in. ?Too much of a good thing. Funnier is i always read his posts and could pretty much copy and paste them as my own.? Either way i think he does have some nice gear but he knows like us the value and isn't looking to get rid of things afaik. Nothing wrong with that. At the time we talked we also spoke about trades being desirable more than cash flow. ? Not sure if he hangs out here or other forums.? <div>-------- Original message --------</div><div>From: George Currie <g at kurico.com> </div><div>Date:03/14/2016 10:52 AM (GMT-06:00) </div><div>To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> </div><div>Subject: Re: A gold mine for anybody in Austin... </div><div> </div>On Sun, 13 Mar 2016 18:50:56 -0500, James Vess <theevilapplepie at gmail.com> wrote: > Probably true, but it's a weekend and I have time to deal with it so > we > will just see how it goes, I have some hope but low expectations. > I've communicated with him in the past. He seems like a nice enough fellow, but IMHO the prices he was asking for his stuff was way to high. His ads have been in the local CL for a long time now, so I assume he's not in a big hurry to sell or let things go at firesale prices (though maybe it's been long enough now that he'd be more open to it).

8 years, 9 months

Honneywell multics? from panels. the inline phots in this message folks -smecc

by jnc＠mercury.lcs.mit.edu

> From: Charles Anthony > I get bloody impressed just watching it on the emulator; doing it in a > production environment must have been spectacular. Even though I never did do any programming on Multics myself (I had an account on the MIT system, and logged in a bit), I still feel that _as an environment for system programming_, it's _still_ far ahead of almost all the available competition. Unix V6 at least had the grace of simplicity and incredibly small size; its descendants have lost that, and so to me Linux, for example, is entirely inferior to Multics. Which to me is a pretty awesome accomplishment, in a field as fast-moving as computers - the only thing that even vaguely compares is the A-12/SR-71, which today, 17 years after it retired in 1998 (it first flew in 1962), _still_ holds the record for the fastest air-breathing aircraft. There is one axis along which I concede that things have advanced since Multics, which is away from monolithic kernels - Multics is pretty much one big lump in ring 0, except a few things in ring 1. But the complete structing of the system around a segmented, single-level memory system (at least, in terms of the environment the user sees) is such a fantastic idea that I simply don't understand why that hasn't become the standard. (The ability to map files in, and DLL's, do get a lot of that power, but in an ad hoc, inelegant, and less powerful way.) A few now-defunct system (e.g Apollo) picked up on it, but the only OS today I know of based around the concept is the IBM i, the descendant of the Control Program Facility OS on the System/38. Sigh. (And apologies for the rant, it's one of my hot buttons.. :-) Noel

8 years, 9 months

← Newer
1
...
10
11
12
13
14
15
16
...
23
Older →

Jump to page:

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 March 2016