test-drb February 2019

test-drb@ccmp.vtda.org

136 participants
165 discussions

HP 1000 M-series KEY PANEL BOARDS ( with Keys ;-) ) EBAY

by gerardcjat＠free.fr

Did you see it ?? Someone interested ?? LOT of 6 units Qty 6 !!! Seller asking $200 or OFFER https://www.ebay.com/itm/323685640463?ul_noapp=true Not affiliated .... etc etc

5 years, 10 months

VAX-11/780 print set on eBait

by jnc＠mercury.lcs.mit.edu

For those who are intrigued by the VAX-11/780, here: https://www.ebay.com/itm/321399703349 If you can't have a real 780, at least you can have the prints! :-) Noel

5 years, 10 months

Mounting HP7970e 9-Trk 1/2" Tape Drive

by flash688＠flying-disk.com

Jack Harper <harper at secureoutcomes-hq.com> wrote: > I got both drives into the rack this past weekend and I am an old guy > (67) - I carefully stared at the thing before I started and finally > figured out that I could, in fact, lift the drive from a waist high > cart for a few seconds, but definitely could not lift it or lower it > vertically with my arms - no way - and I would have one shot at > getting the drives into the rack on the rails. Harbor Freight sells a nice hydraulic lift table for under $200 that I have found very useful for that sort of thing. It doesn't go up very high (like for the top of a rack), but I used it with some wood blocks to lift a DEC ES45 Alpha system into a rack by myself. 500 pound capacity, 28.5" lift height, $170 https://www.harborfreight.com/500-lbs-capacity-hydraulic-table-cart-61405.h… 1000 pound capacity, 34.5" lift height, $260 https://www.harborfreight.com/1000-lbs-capacity-hydraulic-table-cart-69148.… Alan Frisbie

5 years, 10 months

HP 1000, 9000, AS/400, Sun, etc.

by sales＠elecplus.com

Hi Cindy, Thanks for the email. We have a large inventory of HP gear in Minneapolis. I have a lot of older HP stuff too from the 1980's and 1990's to current. I don't know what you are looking for HP1000's? old workstations and servers? Here is our store but I only listed a very small amount of our stock..... https://store.flagshiptech.com/ Brad Ziton HP Product Manager SKYPE: bradz at flagshiptech.com Trillian: BradZFTI bradz at flagshiptech.com 3939 County Road 116 Hamel, Minnesota 55340 (800) 416.8900 t: 763.516.1346 f: 763.516.1310 c: 612.708.3960 RS/6000 pSeries ? AS/400 iSeries ? Sun Microsystems ? HP9000 ? HP Proliant ? Cisco ? Dell Not affiliated with seller, etc. Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sales at elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

5 years, 10 months

GSX-80 software

by pat＠vax11.net

I'm wondering if anyone knows of any CP/M software using GSX-80, which could be an interesting demo, or game. I have found Kasekastchen ( http://atariage.com/forums/topic/244781-kaesekaestchen-a-new-gsx-based-game…) (misspelled without accents to make the mailman happy), but it mostly just freezes after loading GSX-80 on my TS-803 so far (under the 'remote processor' version of the OS at least). Thanks, Pat

5 years, 10 months

PDP-11/45 RSTS/E boot problem

by jnc＠mercury.lcs.mit.edu

> From: Jon Elson > I'm thinking it is bad memory. ... I think it is just a bad memory chip Nothing so simple, I'm afraid! The memory actually contains: PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144 and it's _supposed_ to be holding: PA:171600: 110024 010400 000167 000016 010500 010605 010446 010346 This together with Fritz's discovery of that first 'bad memory' pattern _elsewhere_ in the binary for the command makes it look pretty likely that some sort of other error has wound up with stuff being put in the wrong location. Noel

5 years, 10 months

Looking for: 68000 C compilers

by commodorejohn＠gmail.com

I know there's an old (I think) official Sega Genesis devkit that's, erm, "around" on various console homebrew sites. No idea which exact C compiler is included, but it's not too difficult to find.

5 years, 10 months

PDP-11/45 RSTS/E boot problem

by jnc＠mercury.lcs.mit.edu

> From: Brent Hilpert > what about the refresh circuitry of the memory board? > ... > It might also explain why a number of 4116s were (apparently) failing > earlier in the efforts ... replacing them might have just replaced them > with 'slightly better' chips, i.e. with a slightly longer refresh tolerance. Ooh, excellent idea! Noel

5 years, 10 months

PDP-11/45 RSTS/E boot problem

by jnc＠mercury.lcs.mit.edu

> From: Fritz Mueller > It looks like the question boils down to either "how did that part of > the binary get to that part of memory?", or "how did we end up > executing out of that part of memory?" More the former, I think. UISA0 contains 001614, and physical memory at 0161400 does contain the first few instructions of the command's binary, so that 01614 is probably correct for the base address of segment (page) 0, which contains all the code for the command. (Without looking through the OS's guts, I can't confirm, from interal data structures, that that's where it decided to put the command's binary.) The PC at fault time is 010210, which is correct for the frame setup function, CSV; and looking at the contents of the stack, registers etc makes it pretty certain it had just done the "JSR R5, CSV" to get there. And 0161400 + 010210 = 0171610, which contains something completely different >from what's in the command binary at 010210! > Could still be a memory issue _elsewhere_ that lands us there, of > course... Could also be a translation error lurking in the KT11, or a > CPU bug not found by any of the DEC diagnostic suites. Yup. Like I said, good news is we're down to one problem; bad news is it's a Duesie! Noel

5 years, 10 months

PDP-11/45 RSTS/E boot problem

by jnc＠mercury.lcs.mit.edu

> From: Mattis Lind >> we've also looked at what's in memory at that location, and the low >> part of the text segment seems to be correct, but there was junk at >> the top, around the target of the JSR (i.e. at 'csv'). Not just one >> word, but everything around that location was wrong, which would >> suggest to me that the cause is not a simple memory failure there. >> I've suggested to Fritz that we look at that again, to see if what was >> recorded before is accurate > Would it be possible to insert a breakpoint or halt and run the > program, insert original instruction and single step? I'm not sure that's going to tell us much: the latest development is that Fritz looked at the actual memory contents again, and it is once again trash; _almost_ identical to what was there before: PA:171600: 016162 004767 000224 000414 006700 006152 006702 006144 but with some extra 010000 bits: PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144 (It's not clear if this represents a real difference, or if that front panel issue Fritz mentioned caused the contents to be displayed incorrectly.) The exciting thing is that if the latter really is what's in main memory, that '16700 16152' at the PC of the MM trap could indeed generate the MM trap we're seeing: it's "MOV 26364, R0", and that address is in segment (page) 1, which is only 03500 long.... If so, i) we're down to one problem (good news), and our problem turns into finding out how that section of the code got trashed (bad news). Which is not going to be simple, alas, I suspect. I don't think it's the RK11, because Unix reads the program image into system buffers in low memory, and that's clearly working OK in the 'sleep;ls' case. (It may not use the exact same buffers, though...) It then copies it out to the memory where it's going to execute from, using an MTPI loop. So maybe the memory still has issues, or maybe the MTPI isn't working with some main memory locations or or or... Noel

5 years, 10 months

← Newer
1
...
10
11
12
13
14
15
16
17
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 February 2019