test-drb July 2018

test-drb@ccmp.vtda.org

148 participants
163 discussions

Making a bootable LIF CD for the 9000/382

by aek＠bitsavers.org

brain fade, I know I've made a HPUX 9 install CD before but I've forgotten how you make one that can be booted by the LIF boot rom in the machine.

6 years, 5 months

For Sale SGI Phobos G160 NIC card for Indigo2, brand new, unopened box

by carlojpisani＠gmail.com

up for sale is an Ethernet 10/100Mbps Card for Indigo2/MaxImpact Brand New, Original, Never opened, Never Used! Comes with manual and drivers, still enclosed within cellophane! Phobos G160 are very rare nowadays looking for 170 Euro + S/H I can also give you a second hand (tested, working) SolidImpact GfX for 30 euro, thus 200 Euro both, combined shipping to save your money Located in Italy (my parent's house)

6 years, 5 months

Classic TMS1000

by charles7＠slingshot.co.nz

Hi Who has experience with the TMS1000 in a lot of games. Want to dump ram electronically (by 'test mode' ?) not decapping. Must be some new software out there that can do this now, or am I daydreaming. Thanks Charles Harris

6 years, 5 months

Odd MSV11-J bug (Was: MSV11-J engineering info)

by jnc＠mercury.lcs.mit.edu

> it is not board-dependent - two different boards give incorrect read > data for the same write values!! ... I wonder if the board is storing > wrong values a _lot_, and the ECC is normally catching them? Anyone have any idea what might be going on here? I ask because I'm fixing to repair a broken MSV11-J for a list member, and the combo of ECC and this might make it hard to track the problem down. (If only one chip is dead, the ECC _should_ be able to 'paper over it'. So there are probably two? But if I turn off ECC, to be able to find the bad chip, will I get deceived by this other problem?) Noel

6 years, 5 months

Odd MSV11-J bug (Was: MSV11-J engineering info)

by jnc＠mercury.lcs.mit.edu

> none of the other values used in that seemed to have a problem; but of > course the program didn't include all 2^16 patterns. I suppose I should > whip up a small program to try other values, and see if anything else > does this... And it does! Quite a few values come back wrong, when ECC is disabled - I'm going to guess about 25% of the time. (Out of 0-020, 4 were wrong.) And it is not board-dependent - two different boards give incorrect read data for the same write values!! And the ones that were OK were OK on both. (And it doesn't appear, from a bit of spot-testing, to be address-dependent.) This is _very_ strange. There's nothing in the manual about 'disabling ECC causes incorrect data to be returned' that I could see. I wonder if the board is storing wrong values a _lot_, and the ECC is normally catching them? (Maybe DEC did it this way to test the ECC hardware all the time, and quickly catch failing ECC? But why doesn't the manual mention that?) One thing I noticed is that while I was doing the 'which bit goes in which chip' stuff, on some of the data lines, there was a lot of grup - some of it fairly long pulses, and some spikes that looked like they might be hazard outputs. I wonder if they are part of the cause? I guess the next step is to set up a loop which stores one of the values which always gives a bad output, and see what the board is actually writing into the chip... Very, very strange! Noel

6 years, 5 months

Odd MSV11-J bug (Was: MSV11-J engineering info)

by jnc＠mercury.lcs.mit.edu

> I first have to tweak my 'scope loop program, to turn on memory mapping So while doing that I just discovered what I _think_ (maybe I'm just not being smart enough to see that it's somehow 'doing the right thing') is the wierdest hardware bug I've ever seen. Plug in an MSV11-J, disable ECC (store an '04' into the CSR), and then store '0172344' into any location. Now read it back! And it's not a bad RAM chip, which turning off the ECC is letting show through, because I tried several boards, and they all do the exact same thing. So either they've all got the same bad chip, or... :-) I found this when my modified 'scope loop program (above) blew out, but none of the other values used in that seemed to have a problem; but of course the program didn't include all 2^16 patterns. I suppose I should whip up a small program to try other values, and see if anything else does this... Noel

6 years, 5 months

MSV11-J engineering info

by jnc＠mercury.lcs.mit.edu

> From: Glen Slick > What signal were you probing on the M8186 KDF11-A board? BDOUT; I'm triggering on that, and without any prints it wouldn't be easy to find on the MSV11-J. Picking it up off the KDF11-A was the easy way to go. > If you run the XXDP VMJAB0 diagnostic and there are failures, does it > tell you which data bit and/or ECC bit positions have failures? I > suppose it must, otherwise there wouldn't have been much point in the > bit mapping exercise. I dunno; I don't have it. There's also the built-in memory tester in the bootstrap code in the EEPROM on the KDJ11-B, and according to EK-KDJ1B-UG-001 (pp. 4-24, -26) that prints the address and bad data when an error is detected. I have my own little memory diagnostic that I wrote which I tend to use (since I know exactly what it's doing). I'll probably whip up a modified version to check the ECC bits in the MSV11-J (in diagnostic mode, they can be read/written). The MSV11-J does have this feature where you can leave the ECC enabled on the low 32KB (or optionally, the second 32KB) even when ECC is turned off for most of the memory; that's so a diagnostic can live in that memory while testing the rest. I think I'm probably going to ignore that, and plug in a small memory card for the diagnostic to live in, since the MSV11-J can be set to start at any 16KB boundary. That way I can test the entire MSV11-J without any fancy dancing. Noel

6 years, 5 months

MSV11-J engineering info

by jnc＠mercury.lcs.mit.edu

> From: Tor Arntsen > So, here's how to see the updated page while not logged in: Thanks for posting the 'fix'; the problem, and that workaround, are described on the 'News' sidebar on the Main Page, but of course people going straight to a URL won't see that - and since I'm always logged in, I often forget that un-logged in visitors have this issue. Maybe I should try and edit the CSS or something to include a note with every page? (Any pointers on how to do that gratefully accepted! :-) > Hopefully Tore S. or someone can figure out what's wrong with this > Mediawiki version. Alas, only Tore has the access needed to fix it (and the other current major problem). Noel

6 years, 5 months

MSV11-J engineering info

by jnc＠mercury.lcs.mit.edu

>> I'll add the info to the MSV11-J page on the CHWiki, once I have it. > Alas, it's down at the moment ... but once it's back, I'll get them > right up. It's back, and I've added the chip info for the low 1MB bank: http://gunkies.org/wiki/MSV11-J_QBUS_memory#Technical_information I'll do the other bank 'soon' (I first have to tweak my 'scope loop program, to turn on memory mapping, to get to the high bank). Here's my test rig, BTW: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/MSV11JTester.jpg Simple, but it did the job! Noel

6 years, 5 months

Needing help fixing an irix boot disk

by mazzinia＠tin.it

Hello, Long story short, a while ago I cloned the hd of a Fuel I got given (6.5.16, original installation from an iconic car designer, Bertone), and all was ok. The original hd was then left in place but unpowered, the cloned was upgraded to 6.5.22 to maintain the classic applications. Fast forward to the present : Had the smart idea to install an Audigy 2 zs pro ( the kind with the external box, and that takes current using a molex from the computer psu - I used the rail going also to the boot hd ), and the Fuel started acting weird ... not turning on unless pressing more than once the power button, one of the front fans speeding up and down and even stopping, Display Expander I/O errors ( I should note that from the moment I got the Fuel I had to disable env since the I2C on the V10 board is acting crazy ). I managed to boot / use it a couple of times... then it didn't go past the Prom. Removed the Audigy , after a while ( and 2 times left disconnected from the wall outlet for a bit ) it sort of restarted to power on consistently on pressing the button, but it always ended stopping at the prom splashscreen Invoking a manual boot resulted in this https://snag.gy/eMHafJ.jpg after going in circles for a bit, had the brilliant idea of doing this from the prom sash : https://snag.gy/eTzqEP.jpg thus getting more puzzled... the boot drive appeared readable, so why the scsi hard errors. Then I simply reconnected the original hd, and from that one boots with no issues... result, probably the last or both shutdowns while the Audigy was plugged were not so clean. Ideally I would prefer not to clone + upgrade + readd programs again, and I think that repairing the damaged installation would be better especially in case it happens again in the future. I've tried to ask around, but I've not got any hint, and if there was something in an old neko thread... well, we all know that those are unavailable. Bottom line, anyone ever got in this situation and has some tips on what to do ? Thanks in advance, Alessandro

6 years, 5 months

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 July 2018