Re: Odd MSV11-J bug (Was: MSV11-J engineering info)
> 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
Re: Odd MSV11-J bug (Was: MSV11-J engineering info)
> 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
Odd MSV11-J bug (Was: MSV11-J engineering info)
> 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
Re: MSV11-J engineering info
> 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
Re: MSV11-J engineering info
> 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
Re: MSV11-J engineering info
On 6 July 2018 at 09:48, Tor Arntsen wrote: > On 6 July 2018 at 05:29, Al Kossow via cctalk wrote: >> >> >> On 7/5/18 8:20 PM, Glen Slick via cctalk wrote: >> >>> I don't see any chip info update at that #Technical_information page. >> >> The gunkies wiki is broken, none of his changes are getting out to the world. > > Yes, that's very strange.. if I'm logged in I see the updated page, > with all the changes. If not, I see an old page from 2016. So, here's how to see the updated page while not logged in: - Go to the page - Click 'history' - Change 'From year (and earlier) 2017 ' to 2019 - Click Go - Click on the newest link in the list Not exactly convenient. Hopefully Tore S. or someone can figure out what's wrong with this Mediawiki version.
Re: MSV11-J engineering info
On 6 July 2018 at 05:29, Al Kossow via cctalk wrote: > > > On 7/5/18 8:20 PM, Glen Slick via cctalk wrote: > >> I don't see any chip info update at that #Technical_information page. > > The gunkies wiki is broken, none of his changes are getting out to the world. Yes, that's very strange.. if I'm logged in I see the updated page, with all the changes. If not, I see an old page from 2016.
Re: MSV11-J engineering info
On 7/5/18 8:20 PM, Glen Slick via cctalk wrote: > I don't see any chip info update at that #Technical_information page. The gunkies wiki is broken, none of his changes are getting out to the world.
Re: MSV11-J engineering info
On Thu, Jul 5, 2018 at 4:43 PM, Noel Chiappa via cctalk wrote: > >> 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 I don't see any chip info update at that #Technical_information page. It currently says "This page was last modified on 26 December 2016, at 19:13" What signal were you probing on the M8186 KDF11-A board? 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.
Re: MSV11-J engineering info
>> 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
Re: MSV11-J engineering info
> I'm going to need this info real soon ... so I'll probably start on > this later today if nobody has the info. > ... > write a two-instruction loop .. which writes a word with only a single > '1' bit, hook up a 'scope ... to a DRAM input, and walk the bit through > ... just disable ECC, and write all 0's to all the ECC bits > ... > I think that ... it'll go reasonably quickly, actually; the more bits > I ID, the fewer values I'll have to try on each succeding DRAM chip. That was pretty easy; thanks for knocking my brain into gear! :-) The first couple of bits I had to fish around, but pretty quickly it became apparent there was a system, and for the rest it was just 'confirm that this chip does indeed hold that bit'. I now have the chip<->bit table for the even words, and most of the ECC bits for them (there are two that have resistor headers next to them, so I can't easily get a DIP clip on them to see which is which), but I'm getting bored, I'll do the odd ones tomorrow. Probably they'll be very similar (the array looks like a mirror image of the one for the evens). Also, I was using a 1MB card, so I only had the low bank to worry about; so then I'll have to do the high bank - again, probably pretty easy, from here. The blasted card doesn't have the usual DEC Exx chip numbers, though! I had to make up my own for it... > I'll add the info to the MSV11-J page on the CHWiki, once I have it. Alas, it's down at the moment (the server is actually up, but its DNS entry has gone away again), but once it's back, I'll get them right up. Noel
Re: MSV11-J engineering info
> From: Glen Slick > There are 88 41256 256Kx1 DRAMs on a 2MB MSV11-J. Each 512KB bank has > 22 256Kx1 DRAMs organized as 16 data bits plus 6 ECC bits. Umm, I think the internal organization is paired banks (one for even word addresses, one for odd); the manual talks about doing double-word reads (although only one word gets transferred over the bus at a time, but the PMI has some optimization for double-word cycles, IIRC). > If someone was sufficiently motivated I suppose they could probe each > of the 88 DRAMs while writing various bit patterns of data to various > memory locations and work out the mapping that way. ... I'm not sure > which would be more work, probing one or a small number of DRAMs at a > time Oh, that's an improvement on what I was thinking of as a fall-back, if nobody has the info (which was to tie the outputs of individual DRAM chips high or low - depending on how they implement their output stages - through a suitably-sized resistor, and look to see what effect it had on writing and then reading - all 0's or 1's, depending on the tie - still a lot less work than pulling chips :-). Dunno why it wasn't obvious this would be easier! :-) I would/will just write a two-instruction loop (in the PARs) which writes a word with only a single '1' bit, hook up a 'scope (I'm too lazy to hook up a logic analyzer :-) to a DRAM input, and walk the bit through the odd and even words until I see it on the 'scope. I thought about doing the ECC bits first, using the maintenance mode (to walk a '1' through the ECC bits), to avoid getting confused by 1's being written to them during the above process, but that would be a lot more work, since I'd have to look at all the chips in the array to find the one that's getting the '1' ECC bit. It'll probably be a lot easier to just disable ECC, and write all 0's to all the ECC bits while doing the data bit discovery (above); once those are done, the remaining chips are known to be ECC, and I can walk a '1' through the ECC bits to work them out. > From a brief look at the manual it might be possible to use diagnostic > modes to write specific ECC bit patterns and work out the ECC bit > mappings as well. Yup, that was my take too. Although I'm having to re-read the manual a few times to fully grok how all the various mode bits interact! > Might be very tedious, so might need lots of motivation. I think that using the procedure above, it'll go reasonably quickly, actually; the more bits I ID, the fewer values I'll have to try on each succeding DRAM chip. > If I ever get really bored some day maybe I'd take a look and try to > see just how tedious it might be. I'm going to need this info real soon (to hopefully fix a broken MSV11-J), so I'll probably start on this later today if nobody has the info. I'll add the info to the MSV11-J page on the CHWiki, once I have it. Noel
Re: MSV11-J engineering info
On Mon, Jul 2, 2018 at 7:14 PM, Noel Chiappa via cctalk wrote: > Hi, I'm looking for engineering info on the MSV11-J. I was unable to find any > prints online, or even a technical manual. (I have the User Manual, but it > doesn't > have much detail.) > The main issue I'm after is working out which bits go into which chips. I > have some other QBUS memory boards with no documentation where I created the > mapping by just pulling chips, e.g.: > I'm not sure it's going to be possible to work it out from looking at board > traces, since the MSV11-J is ECC memory, and I expect all the data lines just > disappear into the two huge gate array chips. > There are 88 41256 256Kx1 DRAMs on a 2MB MSV11-J. Each 512KB bank has 22 256Kx1 DRAMs organized as 16 data bits plus 6 ECC bits. If someone was sufficiently motivated I suppose they could probe each of the 88 DRAMs while writing various bit patterns of data to various memory locations and work out the mapping that way. From a brief look at the manual it might be possible to use diagnostic modes to write specific ECC bit patterns and work out the ECC bit mappings as well. Might be very tedious, so might need lots of motivation. I'm not sure which would be more work, probing one or a small number of DRAMs at a time, or hooking up an old school large channel count logic analyzer to probe all 88 DRAMs at the same time. (You can get around 200 data channels with a couple of HP 16550A modules or three HP 16555A modules in an HP 16500 or 16700 series mainframe). If I ever get really bored some day maybe I'd take a look and try to see just how tedious it might be.
MSV11-J engineering info
Hi, I'm looking for engineering info on the MSV11-J. I was unable to find any prints online, or even a technical manual. (I have the User Manual, but it doesn't have much detail.) The main issue I'm after is working out which bits go into which chips. I have some other QBUS memory boards with no documentation where I created the mapping by just pulling chips, e.g.: http://gunkies.org/wiki/Q-RAM_11 but, alas, on all the MSV11-J's I've seen, the DRAM chips are not socketed - unlike QBUS memory boards by almost all the other manufacturers (e.g. National Semiconductor, Camintonn, etc - in fact, pretty much everyone _except_ DEC). Anyway, if anyone _does_ have an MSV11-J with the chips in sockets, I'd _really_ appreciate hearing from them! I'm not sure it's going to be possible to work it out from looking at board traces, since the MSV11-J is ECC memory, and I expect all the data lines just disappear into the two huge gate array chips. Anyway, I would appreciate hearing from anyone with anything on the MSV11-J. Noel
