test-drb March 2016

test-drb@ccmp.vtda.org

189 participants
229 discussions

by rodsmallwood52＠btinternet.com

Hello Guys The latest batch of PDP-8 panels are now reaching their new owners. We held shipping until now to make sure we had good product. The only way you can check the quality is to go through the whole production cycle We threw a fair few in the dumpster! We did extra on the current run and there may be some 8/e Type B (After the switch change) available. Next up are PDP-8/f and /m to fulfill existing orders. I will be making for stock after fulfilling the current order book . My policy is to ship from prepackaged stock. We have loads of custom boxes and soft wrap. We intend to hold manufacturing cycle stock numbers This means if takes three weeks to make a batch we will stock three weeks sales. I'll publish the stock position once a week or by email order enquiry We will be stocking: 8/e A (pre switch change) 8/e B (post switch change) 8/f (maynard address) 8/f (galway address) 8/m (maynard address) 8/m (galway address) Later pdp11/XX Order cycle should be same/next day dispatch against item in stock and PayPal transfer Delivery to UK next day, Europe 1-3 days and the US 2-5days Currency exchange rates are moving all the time and may affect costs. OEM quantities for reproduction makers of any panel, any manufacturer may be possible. (Email me) Bespoke one off for major restorations - email me. Rod Smallwood (Panelman)

9 years, 1 month

NetBSD TK70 question

by cc＠informatik.uni-stuttgart.de

I'm not sure where I should start asking, so I'm starting here ;-) I have a problem reading TK70 (and probably TK50) tapes in NetBSD 3.0 on a MicroVAX II. There is absolutely no way of reading a single tape block with a simple read(). All I get is mt0: unknown opcode 0x80 status 0xc01 ignored on the console, and then the driver hangs. The output is generated in /usr/src/sys/dev/mscp/mscp.c It is my impression that the code has *never* been tested on real hardware after all that years. BTW the TK70 is working fine otherwise (e.g. I can boot the MVII diagnostic tape). Now for something strange: the same procedure works in SimH (with the same system installation and kernel). So apparently SimH has a "bug", too. It doesn't behave like the real device. Background of the story: I want to image TK70 tapes as TAP files. Has anyone ever encountered the same behaviour? Christian

9 years, 1 month

MEM11A Update

by ggs＠shiresoft.com

Just wanted to let folks know where the MEM11A (as opposed to the UMF11) is. All of the verilog code is written for the CPLD and I?ve simulated full unibus transactions to the FRAM and everything seems to work. I?m almost done with schematic entry. I just have a few things to clean up and verify. I?ve done basic component placement (still have to finish placing the 40+ bypass capacitors). I?m planning on doing a 4 layer board so I can avoid having routing issues due to 3 different power supply voltages (yea, modern low voltage design meets 5v). I haven?t done a 4 layer design before, so I?m in for a bit of learning (mainly on how to ?pour? the inner layers). I?m still undecided if I?m going to place some (or all) of the bypass caps on the backside of the board. It would make things easier especially around the 100pin CPLD. At this point I?m hoping to FAB a set of prototype boards in about a month from now (mid to late April). I?ll hand populate a couple (total prototype FAB run will ~5 boards) and test them out. I?ll be using my 11/34, 11/40 and possibly my 11/20 for testing these so there should be pretty good coverage. I should know pretty quickly after I?ve started debugging the prototypes what the price will be for the assembled & tested boards. I?ll start taking orders then. I?ve also decided that the Unibus interface IC?s will be socketed (mainly I don?t want to deal with the ?wastage? from the assembly house for NLA parts). It also means that if some of my stock don?t work, it?s an ?easy? fix. For those that care, I?ll be using machined pin sockets (gold plated of course). Any for any that ask, no I will *not* be making the boards available without the drivers. I?ll be providing fully assembled and tested boards. TTFN - Guy

9 years, 1 month

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

by jnc＠mercury.lcs.mit.edu

> From: David Bridgham > how the GE processor mapped each segment to physical memory on its own > while the x86 maps the segments into a single 2^32 byte linear address > space first and then maps that to physical memory. Oh, right, I remember there was a 4GB limit on physical memory (which I mentioned in an earlier message in this thread), but I'd forgotten the details. The paging is done on that 4GB linear address space, so it's separate from segmentation - on the 645 at least, the two are jumbled in together, which I find over-complex. I like the clean separation between paging and segments. > The x86 got this one wrong, in my opinion, as it means you can't have > full-sized segments if you have more than one effective segment. Well, but that's in the implementation, invisible to the user (in a properly done OS). The user-visible architecture is 16K segments (8K local, 8K global), of up to 4G each, or 2^46 total address space (per process). Yes, not more than 4GB of them can be resident in memory at any one time, but I'm not convinced that's a problem. Noel

9 years, 1 month

ISO: VAX-11/75

by seefriek＠gmail.com

> My call for a VAX-11/750 a month or so ago actually bore some fruit > (locally, even!) and as of a couple of weeks ago, I now have a very > nicely configured 11/750 system taking up most of the basement. Some guys have all the luck. Now if anyone in the Southeast has a 750 they're no longer attached to... Congrats KJ

9 years, 1 month

PDP-11/05-NC with M9301?

by mattislind＠gmail.com

I was thinking of using a M9301 board to get a console emulator and some different bootstraps with the 11/05. But can I just put the M9301 in the slot where the M930 normally goes? Slot 4 AB. >From looking in the schematics I get that: 1. The bus grant pull ups on the M9301 is through jumpers. According to the note they should only be installed on 11/70 systems. But the M930 do pull these up (no jumpers here) so my guess is that these jumpers should be installed. 2. The M930 connects much more signals to a common ground. Except for the normal ones the M9301 uses for ground (AC2, BC2, AT1 and BT1) it also has connected AB2, BB2, AN1, AP1, AR1, AS1, AV2, BD1, BE1, BV2 to ground. Reading the pin assignments on a MUD slot I think that putting a M930 into it could potentially create a lot of smoke. BV2 is -5V and AV2 is +20V if the appropriate regulator is in the system. M9301 goes into MUD slots. But can it go into the slot where a M930 normally sits? My thinking is that it should work. What is your experience? /Mattis

9 years, 1 month

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

by jnc＠mercury.lcs.mit.edu

> From: Charles Anthony > Slightly at cross purposes here; I was speaking of porting Multics; you > are speaking of writing a Multics like OS. I was opining that I don't > think that porting would work due to Multics reliance on very specific > VM features. Yes; my un-stated assumption was that the existing Multics code was so tied to the peculiar Multics hardware (how many instances of "fixed bin(18)" do you think there are in the Multics source :-) that it would be impossible to run on any modern hardware except via (as you have so wonderfully done) emulation. Hence the re-implementation route... >> I think the x86 has more or less what one needs Intesting note here: I was just reading Schell's oral history (a _fascintating_ document), and it turns out he was a consultant to Intel on the 286 (which architecture the later machines more or less copied exactly, extending it to 32 bits). So I'm no longer surprised that the x86 has more or less what one needs! :-) >> 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 pulled down one of my many copies of Organick, and I had misremembered the details (and of course Organick describes the 645, not the 6180, which was subtly different). The code has its own set of registers; the PBR/IC (I was probably thinking of the x86's CS here). Of the four pointer-register pairs (which are effectively pointers to any segment, i.e. 'far' pointers, in a sense), two are indeed to the stack and linkage segments, and the others can be used for other things - one is typically a pointer to subroutine arguments. > 8 pointer registers .. > PL1 calling conventions reseverved certain regsiters for frame pointer, > etc. Yes, I got the 6180 processor manual, and a bunch of other things, and there had been significant changes since the 645 (which is the version I was somewhat familiar with, from Organick). Of the 8 pointer registers in the 6180, I was only able to find the usage of several: 0 - arguments 4 - linkage 6 - stack frame 7 - stack/linkage header I assume the others (most?/all?) were available for use by the compiler, as temporaries. One apparent big change in Multics since Organick was that the stack and linkage segments had been combined into one (not sure why, as I don't think having one less segment in the KST made much difference, and it didn't save any pointer registers); the header in the combined stack/linkage segment contained pointers to each in the combined segment. >> 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? > It's been a long time since I look at the x86 segment model, but my > recollection is that segments were mapped into the address space of the > process; that is not how the Multics memory model worked. Each segment > is in it's own address space; any memory reference was, per force, a > segment number and offset. In this last sentence, is that referring to Multics? If so, that is exactly how the x86 _hardware_ works, but most x86 OS's (in particular, all the Unix derivatives) don't really use segments, they just stick everything in a limited number of segments (one for code, one for all data - maybe one more for the stack, although perhaps they map those two to the same memory). > I am unconvinced that Multics could be ported to that architecture No disagreement there - "fixed bin (18)"! > an interesting Multics like operating system should be possible Exactly. > with he caveat that some things are going to have be done differently > due to incompatibilities in the memory model. I'm not so sure - I think you may be thinking that the x86 model is something other than what it is. It does indeed not have the infinite inter-segment pointer chaining possible on Multics hardware (where a pointer in memory points to another pointer which points to another pointer), but other than that, it does seem to have most of what is needed. In particular, it has local and global segment tables (indexed by segment number), and the ability to load pointer registers out of those tables, and the ability to have most (all?) instructions use particular pointer registers (including segment selection), e.g. if the linkage segment was pointed to by the ES register, there is an optional (per-instruction instance) modifier which causes most (all?) of the normal x86 instruction set to operate on that segment, instead of the primary data segment (pointed to by the DS register). Of course, until we get into the details, we can't say positively, but after reading the manuals, it seemed like it was doable. Noel

9 years, 1 month

LAST CHANCE for VCF East exhibit registration

by cctalk＠snarc.net

Everyone, There is less than one month until showtime. I'm declaring noon ET tomorrow as the final deadline for registering exhibits. Exhibits so far: http://vcfed.org/wp/festivals/vintage-computer-festival-east/vcf-east-exhib… Exhibit registration: http://www.vcfed.org/registration/east_exhibitor_register-online.php

9 years, 1 month

PDP-11/05-NC with M9301?

by jnc＠mercury.lcs.mit.edu

> From: Mattis Lind > I was thinking of using a M9301 board to get a console emulator and > some different bootstraps with the 11/05. But can I just put the M9301 > in the slot where the M930 normally goes? > ... > M9301 goes into MUD slots. But can it go into the slot where a M930 > normally sits? I haven't personally looked into doing this in detail, so I can't give a definitive answer, but your last question here makes alarm bells go off in my head. The M930 is designed to go in UNIBUS In/Out slots. These slots do have different wiring from the A/B MUD slots. (For instance, UNIBUS In/Out slots have _single_ pins assigned for BG4-7 and NPG, providing 'grant in' or 'grant out' functionality, depending on if it's an In or Out slot. I don't recall offhand what function/signal is on those pins in a MUD slot, but I'm pretty sure it's not a grant!) I would be fairly astonished if a device intended for a MUD slot would work in a UNIBUS In/Out slot, and vice versa. Noel

9 years, 1 month

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

by jnc＠mercury.lcs.mit.edu

> From: Mouse > As for buffer overruns, the point there is that a buffer overrun > clobbers memory addressed higher than the buffer. If the stack grows > down, this can overwrite stack frames and/or callers' locals. Oh, right. Duhhhh! Buffers typically grow upward, no matter which direction the stack grows. So the two directions for stack growth aren't purely a convention. Of course, in Multics, especially with AIM (Access Isolation Mechanism), stack buffer attacks are much less dangerous. E.g. even without AIM, the attacker can't load code into the stack, and return to it - generally the stack segment had execute permission turned off. And AIM really limits what 'bad' code can get up to. I keep ranting about it's pointless to expect programmers to write code without security flaws, it needs to be built in to the low levels of the system (one of Multics' many lessons - it wasn't _really_ secure until the 6180 moved the ring stuff into hardware, instead of simulating it in software, as on the 645). And so as long as we continue to allow Web pages to contain 'active' content (i.e. code), so that random code from all over the planet gets loaded into our computers and run, browsers will neve be secure; they need to be run in an AIM box. Noel

9 years, 1 month

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

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