- test-drb@ccmp.vtda.org - classiccmp.org

by aek＠bitsavers.org

https://www.ebay.com/itm/132933407806 this is interesting because of the price and that all of the Sun drives I've ever come across had the 800bpi option in them

7 years, 2 months

12
16
0 0

sun 88780 on ebay

by jlw＠jlw.com

*Eric Smith *writes: > On Mon, Feb 11, 2019 at 11:18 AM Al Kossow <aek at bitsavers.org <http://www.classiccmp.org/mailman/listinfo/cctech>> wrote: > > >/Does it have the 800 bpi option board? />// > I haven't yet unboxed it. I took photos of the outside of the destroyed box > to send to the shipper. The front bottom left corner of the 88780 is > visible through a hole in the box, and is visibly mangled. > I acquired mine as a piece of decommissioned hardware where I worked.? It came home with me in my car. Some time later (mid 90s) I loaned it to a friend for some contract work at <a likely-bankrupt public utility in San Francisco>.? I drove it up there and delivered it on a cart.? The stars, however, did not align for getting it back to me the same way so they shipped it to me where I worked.? There was some damage to the plastic front cover and control panel mounts.? I was able to repair or work around most of it, and the unit still works fine to this day. (Well, the plastic take-up reel is loose...) Pretty much everything I have that could go in a rack I fetched myself rather than having it shipped to me.? While one can't always do that, I recently carted home an HP 3455A multimeter from Los Angeles, some 400 miles.? I was already in the area, otherwise I don't think I'd've made the round trip just for it. > Based on the service manual, it appears that option 800 requires: > * buffer PCA 07980-6xx14 (512K) or 07980-6xx34 (1M) > * read/write/formatter PCA 07980-6xx31 > Mine has the 800 bpi option.? Not by inspection, but by operation. -- Jeff Woolsey {{woolsey,jlw}@jlw,first.last@{gmail,jlw}}.com Nature abhors straight antennas, clean lenses, and empty storage. "Delete! Delete! OK!" -Dr. Bronner on disk space management Card-sorting, Joel. -Crow on solitaire

7 years, 2 months

1
0
0 0

SGI Personal Iris 4D/35

by ball.of.john＠gmail.com

Hey Kyle. You can narrow things down a bit by removing the optional Z-buffer and additional bitplane memory (ZB3 and BP4). While that removes those two masses of memory out of the equation that still leaves the still massive amount of ZIPP base video memory. for the later Onyx systems I've only seen pinstriping when the video memory or supporting glue has been allowed to overheat. I can't recall if it tests the graphics as well but have you tried running the ide diagnostics in case that refines the error a little? -John >I've got a graphics issue in my 4D/35, and I suspect it's a VRAM chip. I've >got vertical lines appearing on the screen, but not everywhere on the >screen; that seems to hint at an issue with one buffer having bad memory. >It was especially evident in the flight simulator demo, where alternating >frames flashed with and without lines. > >The ever helpful self test says, "ERROR: Failure detected in the >Electronics Module (graphics). press <Enter> to continue". > >The system is equipped with the ZB3 and BP4 on a GR1.2. > >How can I better diagnose this issue? There are so many RAM chips soldered >on these three boards. Tracking it down to a single chip sure would be >nice. > >Thanks! > >Kyle

7 years, 2 months

2
1
0 0

Bellmac 8 Tutor on ebay

by couryhouse＠aol.com

although? ?I? think? ?most? production? ? for? switch gear? ?was? ?done? ?with the later? ?32? bit? ?unit Ed# In a message dated 2/10/2019 12:49:36 PM US Mountain Standard Time, cctalk at classiccmp.org writes: telephone? gear? ed# In a message dated 2/10/2019 12:26:20 PM US Mountain Standard Time, cctalk at classiccmp.org writes:Bringing up a bit of an old thread here, as I just picked up one of theseyesterday. Typed in some example programs, which took far too long thanksto a bouncy keypad. But hey, at least it works! Were there any real applications for the MAC-8? Haven't been able to findmuch. Thanks, Kyle

7 years, 2 months

1
0
0 0

PDP-11/45 RSTS/E boot problem

by jnc＠mercury.lcs.mit.edu

> From: Jerry Weiss > it is impressive that UNIX booted successfully without tripping over a > boundary. Well, V6 is (or can be configured to be) extraordinarily small, so I'm not surprised it booted OK without going over the 0170000 mark. I have this persistent memory that the -11/40 in the CSR group at MIT had only 3 banks of MM-L (@16KB each) when I first got there! Which is plausible; the smallest V6 config would have about 22KB of core text, and about 2KB of initialized data. If you cut all the parameters to the bone (minimal number of disk buffers, etc) you could probably get away with say 6KB of un-initialized data. That would leave you 18KB for user programs on such a system, a bit less than their recommendation of 24KB minimum for users, but probably minimally useable. We quickly added more memory, I'm sure, but I don't now remember how/what! Later on it was converted to an -11/45, and then we got an Able ENABLE, but that would have been a couple of years later. Noel

7 years, 2 months

1
0
0 0

PDP-11/45 RSTS/E boot problem

by jnc＠mercury.lcs.mit.edu

> From: Jerry Weiss > Though not a disk controller, the DEC DR11-B/DA11-B would not cross 64K > boundaries. Interesting! What's odd is that the DR11-B uses the Bus Interface card (M7219) >from the RC11 controller, and that _can_ cross moby boundaries, so clearly it has the right overflow output; someone just decided not to implement it - the DR11-B sets ERROR instead on an address overflow. Wierd. Anyway, it will be interesting to see if RSTS operates correctly once this problem is fixed... Noel

7 years, 2 months

2
1
0 0

Mounting HP7970e 9-Trk 1/2" Tape Drive

by harper＠secureoutcomes-hq.com

Greetings to the List - I am mounting a couple of heavy (130-pounds each) HP7970e tape drives to a 19" rack. The screw holes that mate to the standard spaced holes on the right side of the drive after you open the case are visible and obvious. However, the holes on the left are hidden under the heavy die-cast(?) frame of the drive. Anyone know how to get to those three screw holes with a horrible disassembly. There has to be a trick to this that I don't see (so what else is new? :) Best, Jack ---------------------------------------------------------------------------------- Jack Harper, President Secure Outcomes Inc 2942 Evergreen Parkway, Suite 300 Evergreen, Colorado 80439 USA 303.670.8375 303.670.3750 (fax) http://www.secureoutcomes.net for Product Info.

7 years, 2 months

9
33
0 0

PDP-11/45 RSTS/E boot problem

by jnc＠mercury.lcs.mit.edu

> From: Fritz Mueller > If, as you are suspecting, we find damning evidence pointing > specifically to the RK11 I got an update from Fritz. As you all will recall, the problem seemed to be a corrupted 'pure text'. So the question was 'when was it damaged, and how'. After some confusion caused by different OS images (the 'Ritchie' and 'Wellsch' distros), he managed to get a look at the text in main memory after it was first read in from the file system, and before it was swapped out (it was showing up damaged after a swap out/in cycle); it looked good at that point. The copy written out to the swap disk however, not so good. A look at the RK11 registers after the swap-out showed an anomaly; something about the extended memory address bits? (Maybe a multi-block transfer than crosses a 64KB boundary? That would explain the address sensitivity we were seeing.) Hopefully he'll track it to its lair shortly. We also need to characterize exactly what the fault is, because the DEC RK11 diagnostics weren't finding it, so it seems the diagnostic suite could use an enhancement.... Noel

7 years, 2 months

5
5
0 0

Mounting HP7970e 9-Trk 1/2" Tape Drive

by jnc＠mercury.lcs.mit.edu

> From: Alan Frisbie > 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 Thanks for the tip! I got one on sale for about US$140; it's _very_ sturdy. And the top is just large enough to hold two milk crates (available at Home Depot, BTW), so it's guite easy to build up a stack as high as one needs to reach the top of a 6' rack. Noel

7 years, 2 months

1
0
0 0

PDP-11/45 RSTS/E boot problem

by jnc＠mercury.lcs.mit.edu

> From: Jon Elson > Likely some disk controllers did NOT SUPPORT crossing 64K boundaries! No; the RK11 spec says "[the two extended memory bits] make up a two-bit counter that increments each time the RKBA overflows". The actual error turns out to be slightly different to my guess; there's a spurious overflow from the low 16-bit register to these bits at 0170000. I can see how the diags didn't catch that one! Unless you try a multi-block xfer that walks across the boundary.... A perfect example of Vonada #12. Noel

7 years, 2 months

3
2
0 0

HP1000 L series, FULL LIST ( UPDATED )

by gerardcjat＠free.fr

All boards are corroded. May be some can be saved ? I am offering : 12002 B XL Ctrl 512 Kb 51x0-013 x = ? Pictures available 12001 C CPU 12001-80001 Has the 1AB5-6001 "HP SoS processor" with Two EPROM ( 12001-80006 and 80007 ) Any interest in imaging these ? BUT, ** I ** cannot do it ! A ser Qty TWO 12005-60010 Has the 1AF5-6001 "HP SoS processor" HP_IB 12009-6x00 x=? with 1AA6-6004 and 1AC5-6001 12021A Cntrl R 12021-60001 has the 3 Eprom and Nec P16175-12 / Intel D8291A / ? FD1791A Eprom : 2116, white ceramic, labeled : 5180 - 0144, 0137, 0136 ( U43, U53, U63 ) Any interest in imaging these ? BUT, ** I ** cannot do it ! Backplane 2 column, 4 row .... a slight scrubbing may be enough Card Cage, if needed : Fine Power supply seems in great condition. Will check more closely, if needed. Battery board !!!!! Only the relays and buzzer can be saved ! Case ?? Who would like a case ?? ;-) TERMS : Remember : I live in France ( shipping ..... ) Small item ... free Medium items ( cards ) ..... shipping cost Large items .... shipping cost plus a fee for packing material and my time. Will wait a full week, to see if BOARDS are asked for, before making PARTS available.

7 years, 2 months

1
0
0 0

Hickok MEM-70 Core Memory Trainer

by kylevowen＠gmail.com

Picked up this core memory trainer yesterday. Seems pretty obscure. http://imgur.com/a/TIOvt7r Has anyone seen one before? Would love to find some documents someday. Thanks, Kyle

7 years, 2 months

2
1
0 0

SGI Personal Iris 4D/35

by kylevowen＠gmail.com

I've got a graphics issue in my 4D/35, and I suspect it's a VRAM chip. I've got vertical lines appearing on the screen, but not everywhere on the screen; that seems to hint at an issue with one buffer having bad memory. It was especially evident in the flight simulator demo, where alternating frames flashed with and without lines. The ever helpful self test says, "ERROR: Failure detected in the Electronics Module (graphics). press <Enter> to continue". The system is equipped with the ZB3 and BP4 on a GR1.2. How can I better diagnose this issue? There are so many RAM chips soldered on these three boards. Tracking it down to a single chip sure would be nice. Thanks! Kyle

7 years, 2 months

1
1
0 0

Bellmac 8 Tutor on ebay

by couryhouse＠aol.com

telephone? gear? ed# In a message dated 2/10/2019 12:26:20 PM US Mountain Standard Time, cctalk at classiccmp.org writes: Bringing up a bit of an old thread here, as I just picked up one of these yesterday. Typed in some example programs, which took far too long thanks to a bouncy keypad. But hey, at least it works! Were there any real applications for the MAC-8? Haven't been able to find much. Thanks, Kyle

7 years, 2 months

1
0
0 0

Bellmac 8 Tutor on ebay

by couryhouse＠aol.com

there should be a yellow covered 8x11 manual out there if not.. let me know... Sent from AOL Mobile Mail On Sunday, January 13, 2019 Jason T via cctalk <silent700 at gmail.com; cctalk at classiccmp.org> wrote: On Sun, Jan 13, 2019 at 7:47 PM ED SHARPE via cctalk <cctalk at classiccmp.org> wrote: > > If any the? group? gets the? bell mac? we would love? a scan? or? hi? res? photo of that multi? colored? sheet. It? would? look? nice? printed in the? back? of? a? display? of? ? one of these units? here.We? have? 3 of these units as? I remember...? and? actually? when I? get my hands around them one? will be? up? for? grabs. Please? advise? ------Ed# SMECC Seconded - I have one of these boards (without the fancy case) but I have zero docs for it, save for what little is online.? The auction seemed to have a few booklets, as well as the poster. j

7 years, 2 months

3
2
0 0

various scans

by nw＠retrocomputingtasmania.com

Been catching up on a backlog of scanning, grab what you like. Manuals indicated with an asterisk are available for cost of packing+shipping if you want something printed. This offer will expire in about a week so please indicate interest early. Burroughs [1] * B2000_B3000_B4000 Work Flow Language Reference Manual Oct-1980 * B4000_B3000_B2000 Series BPL Reference Manual Jul-1978 * B4000_B3000_B2000 Series Data Management System II Users Manual Mar-1979 * B4000_B3000_B2000 Series DMS II DASDL Reference Manual May-1979 * B4000_B3000_B2000 Series DMS II Host Language Reference Manual May-1979 BJ-8-B8500 System Reference Manual May 1967 Various B6700 manufacturing documents Burroughs TD700 manuals [2] TD700 Central Control Schematic TD700 Display Assembly (Head Unit) A2 TD700 Keyboard Assembly A1 TD700 Logic and Power Supply Assembly TD700 Power Supply schematic TD700 PW Board Assembly driver (interim) TD700 Unit Travel Log Misc [3] * Freedom 220 USERS MANUAL Preliminary Edition * Microsoft utility software package reference manual for 8080 microprocessors 8102-343-04 * The COPS Programming Manual National Semiconductor Feb 1985 [2] * Users Manual for the VG-920 Terminal (Tentative) * CPL is a First Aid Kit by Dr AA Grainger UTAS CC [1] https://drive.google.com/drive/folders/1GXEU_kWWKo4btixnrQLRa5qFjZm9uqCM [2] https://drive.google.com/open?id=1iihVNRfkd_zX_PwV30gKQTNLzLcnMEvm [3] https://drive.google.com/drive/folders/1VEiZs1j11VPBYaZrNUaDxSpKWiZasfCC

7 years, 2 months

1
0
0 0

Looking for: 68000 C compilers

by jnc＠mercury.lcs.mit.edu

> From: Al Kossow > I have a source tape. I'm trying to figure out why modern tar doesn't > understand it. I had an issue reading some TAR's of Unix V7 stuff; I brought up an older version of TAR under Windoze and they read fine with it. I don't recall if I figured out what the problem was, or if I just wanted the bits, and as soon as I had them, dropped it. Noel

7 years, 2 months

1
0
0 0

Looking for: 68000 C compilers

by jnc＠mercury.lcs.mit.edu

> From: Bill Gunshannon > What about all the cross compilers that ran on PDP-11's? Good point; by coincidence, I just found the stuff about the 68K cross-compiler from Alcyon (in San Diego) which we used at Proteon; it ran on an -11/73 running Ultrix. According to the ad sheet, it also ran on VAXen, HP9000s, Textronix 8560s, etc; OS's were various Unix flavours, VMS, VersaDOS, and Regulus. I have the man pages for it, the assembler and linker, the c.out format it produced, etc if those are any use/interest. Noel

7 years, 2 months

6
8
0 0

PDP-11/45 RSTS/E boot problem

by jnc＠mercury.lcs.mit.edu

> From: Fritz Mueller > This seems the best place to start with the LA this weekend then. I'm going to respectfully semi-disagree! I think that at this point there's a good chance we can localize to within a gate or two before we start applying test instuments. My thinking starts with two pieces of data; i) your discovery that when the MM trap happens, the end of the pure text segment contains a fragment of code >from 04000 lower in the text, and ii) the data that the location in main memory where that _should_ have been is full of zeros - i.e. never been written into. The latter is, I think, due to the fact that Unix clears all of main memory on startup; I think it's just chance that that memory hasn't been used yet for something else, and is still 0's. (Unix does clear main memory in a few places during regular operation - e.g. when expanding the stack, the newly added area is 0'd - but in general, e.g. when swapping in a pure text, it doesn't seem to bother, which makes sense since it's all about to be over-written anyway.) Anyway, those two, together with my previous analysis that this was unlikely to have happened when the text was first being read in from the file, block by block, lead me to believe that the likely cause is that the BAR on the RK11 skipped up a whole bunch (setting the 04000 bit at some point) when it was reading the pure text back in from the swap, and skipped writing into that zero-filled block of main memory, putting the stuff that should have gone there up 04000, instead. (Why it's swapping the text back in is too complicated to be worth explaining here; anyone who _really_ wants to know should look here: http://gunkies.org/wiki/Unix_V6_internals in the last section, "exec() and pure-text images".) It's easy to confirm all these suppositions/deductions fairly easily, without having to connect up, configure, etc the LA: we can just stop the machine after the text is first read in (in xalloc()) from the file-system, and confirm that the text looks good there; if so, either the swap-out (albeit unlikely, since that doesn't account for the 0's) or subsequent swap-in had an issue. The latter would be easy to confirm: just halt the machine after the text is swapped in, and see what the RK registers contain. At that point, as I said, we'll know to within a few gates where the issue is, and then it'll be time to bring out the LA. Actually, a plain oscilloscope would do; it's interesting to recollect that these machines were designed and maintained without benefit of a LA, purely with an oscilloscope! We're so spoiled now! :-) Noel

7 years, 2 months

2
1
0 0

PDP-11/45 RSTS/E boot problem

by jnc＠mercury.lcs.mit.edu

> From: Fritz Mueller > is it possible for you deduce where Unix _should_ be placing these "bad" > bits (from file offset octal 4220)? Yes, it's quite simple: just add the virtual address in the code to the physical address of the bottom of the text segment (given in UISA0). The VA is actually 04200, though: the 04220 includes 020 to hold the a.out header at the start of the command file. So, with UISA0 containing 01614, that gives us PA:161400 + 04200 = PA:165600, I think. And it wound up at PA:171600 - off by 04000 (higher) - which is obviously an interesting number. > Maybe a comparison of addresses where the bits should be, with > addresses where the "bad" copy ends up, could point us at some particular > failure modes to check in the KT11, CPU, or RK11... Here's where it gets 'interesting'. Executing a command with pure text on V6 is a very complicated process. The shells fork()s a copy of itself, and does an exec() system call to overlay the entire memory in the new process with a copy of the command (which sounds fairly simple, at a high level) - but the code path to do the exec() with a pure text is incredibly hairy, in detail. In particular, for a variety of reasons, the memory of the process can get swapped in and out several times during that. I apparently used to understand how this all worked, see this message: https://minnie.tuhs.org/pipermail/tuhs/2018-February/014299.html but it's so complicated it's going to take a while to really comprehend it again. (The little grey cells are aging too, sigh...) The interesting point is that when V6 first copies the text in from the file holding the command (using readi(), Lions 6221 for anyone who's masochistic enough to try and actually follow this :-), it reads it in starting from the bottom, one disk block at a time (since in V6, files are not stored contiguously). So, if it starts from the bottom, and copies the wrong thing from low in the file _up_ to VA:010200, when it later gets to VA:010200 in the file contents, that _should_ over-write the stuff that got put there in the wrong place _earlier_. Unless there's _another_ problem which causes that later write to _also_ go somewhere wrong... So, I'm not sure when this trashage is happening, but because of the above, my _guess_ is that it's in one of the two swap operations on the text (out, and then back in). (Although it might be interesting to look at PA:165600 and see what's actually _there_.) Unix does swapping of pure texts in a single, multi-block transfer (although not always as an integral number of blocks, as we found out the hard way with the QSIC :-). So my suspicions have now switched back to the RK11... One way to proceed would be to stop the system after the pure text is first read in (say around Lions 4465), and look to see what the text looks like in main memory at _that_ point. (This will require looking at KT11 registers to see where it's holding the text segment, first.) If that all looks good, we'll have to figure out how to stop the system after the pure text is read back in (which does not happen in exec(), it's done by the normal system operation to swap in the text and data of a process which is ready to run). We could also stop the system after the text is swapped out, and key in a short (~ a dozen words) program to read the text back in from the swap device, and examine it - although we'd have to grub around in the system a bit to figure out where it got written to. (It might be just easier to stop it at, say, Lions 5196 and look at the arguments on the kernel stack.) > a suggestion here to check the KT11 address translation adders ... A > bug in one of the carry lookahead generators used between the bit > slices of that adder could cause a mistranslation on only a fairly > selective subset of virtual addresses This could be happening, but from the reasoning above about the order that the blocks of the text are read in, something would have to interfere with the later read of the higher memory blocks, too, no? So I'd discount the KT11 _for the moment_. > *IF* that's the case and we can chase the IR trace upstream to the > place of an unlucky mistranslation, it will be pretty easy to track > down then in the hw and fix. It'll be interesting to look at the text after it's read in (i.e. before it's swapped out). If it's OK there, that's pretty conclusive that it _can't_ be the KT11 - because from then on, the kernel doesn't _do anything_ to that binary, except swap it out and in with the RK11. And since those are both single I/O operations (with swapping on the RK11, at least, which can do multi-block transfers), _and_ the bottom of the text segment comes in OK (so the RK11 is being set up with correct disk and main memory addresses for both the out and in), I can't think of a fault _elsewhere_ in the system that could cause that 'stuff winds up in the wrong place' error. I know this is complicated, but look at the bright side: we started with three apparently un-connected problems: * R5 trashage * an 'impossible' MM fault * bad text data The first one turned out to be non-existent (my fault in interpreting the kernel stack in the process core dump), the second was also not really there (although a hardware fault in the console gave us bad data, so there really was a hardware issue there), and now we're down to one - albeit a tricky one. So we were dealing with two un-related hardware problems - now we're down to one, and hopefully soon will have it isolated to a single sub-system! (And thanks to whoever gave us the voltage tip, that fixed the first one.) Noel

7 years, 2 months

5
6
0 0

Looking for: 68000 C compilers

by technoid6502＠gmail.com

On Fri, 2019-02-08 at 12:00 -0600, cctalk-request at classiccmp.org wrote: > Re: Looking for: 68000 C compilers There is a GNU OS for the Atari 68k-based ST, TT, and Falcon computers which might be fun to play with. It is called MiNT. FreeMiNT and SpareMiNT are two distros. They are available. Aranym/Afros are current projects. Of course tools are available within. Best regards, Jeff

7 years, 2 months

1
0
0 0

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

7 years, 2 months

1
0
0 0

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

7 years, 2 months

1
0
0 0

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

7 years, 2 months

2
1
0 0

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

7 years, 2 months

1
0
0 0

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

7 years, 2 months

2
1
0 0

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

7 years, 2 months

2
1
0 0

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.

7 years, 2 months

2
1
0 0

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

7 years, 2 months

5
12
0 0

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

7 years, 2 months

2
1
0 0

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

7 years, 2 months

4
3
0 0

Unused Sun keybaord and accessories

by sales＠elecplus.com

This keyboard has now been sold! 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

7 years, 2 months

1
0
0 0

another dealer going under

by sales＠elecplus.com

Leslie is preparing a list. She has also contacted another friend who is quitting the biz, to see if they want to get rid of equip. 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

7 years, 2 months

1
0
0 0

Unused Sun keyboard and accessories

by sales＠elecplus.com

1 keyboard PN 3201072-01 still in plastic and foam (Type 5) 1 metallic type mousepad, never used 1 mouse 370-1170-01, used 1 cable 530-1594-01 used 1 cable 530-1662-01 new 1 cable 530-1442-02 used 1 battery holder that is plugged into the 530-1594-01, used, no battery installed These are in my stock. All fits in one box. Make offer. 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

7 years, 2 months

1
0
0 0

NIB 1986 phones and used USR modems

by sales＠elecplus.com

Pics of equipment on request . Hi, we occasionally get some. For example, we have the following: 2x Phones ROLM 61000 in boxes (see photos) ('86 year of manufacture); Bunch of (see photos): FAX-MODEM USRobotics 33.6K Model 0459 PN: 00083907 FAX-MODEM USRobotics 56K Model 0701 PN: USR5686D FAX-MODEM USRobotics 56K V.92 PN: 5686 Let me know what you think. I'll keep you posted on any antique equipment we will be receiving. Nick Makarovskiy, nick at ictcompany.com Office: +1-781-912-1717 x 710 Direct:+1-781-912-1710 Cell/WhatsApp: +1-617-309-8705 400 Tradecenter, Ste 5900 Woburn MA 01801 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

7 years, 2 months

1
0
0 0

Looking for: 68000 C compilers

by jnc＠mercury.lcs.mit.edu

> From: Phil Pemberton > * Anything not on this list ;) The TRIX project at MIT-LCS did a 68K compiler very early on (soon after the first 68K wa released)x, using Steve Johnson's Portable C Compiler as a base. Noel

7 years, 2 months

1
0
0 0

Looking for: 68000 C compilers

by jfoust＠threedee.com

At 12:26 PM 2/6/2019, Ethan Dicks via cctalk wrote: >OTOH, at home, I'd had an Amiga since 1986 and used a variety of >native tools (Lattice C later SAS/C, and various assemblers either >commercial or from a Fish Disk). Somewhere I have the DOS-hosted C compiler for the Amiga that was part of the first developer kits. I think they were Sage-hosted for a while, too. - John

7 years, 2 months

1
0
0 0

old barcode and scanner equip

by sales＠elecplus.com

Preowned Barcode Ltd John Gallant Halifax NS Canada PH (902) 468 8210 Cell (902)719 6031 Email: sales at preownedbarcode.com This gent has stuff from the 80s and 90s in the barcode and scanner departments. 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

7 years, 2 months

1
0
0 0

360Tech is gone

by sales＠elecplus.com

Last May Steve auctioned off the assets, and and printer/plotter co bought the name and website. Steve retired to Hawaii. All is gone L 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

7 years, 2 months

1
0
0 0

Looking for Limited Function Board

by anders＠abc80.net

> Date: Sun, 3 Feb 2019 22:22:42 +0100 > From: Pontus Pihlgren <pontus at Update.UU.SE> > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Subject: Looking for Limited Function Board > Message-ID: <20190203212242.GF24947 at Update.UU.SE> > Content-Type: text/plain; charset=us-ascii > > Hi > > I'm restoring a PDP-8/a with the help of some > friends. The CPU is now passing the MAINDECs I've > thrown at it. The memory is a modern semiconductor > board my friend Anders Sandahl made. > > This machine is pieced together from several others > and the limited function panel I got does not match > the backplane I have. > > My theory is the DEC simplified the design of the > boardto cut costs and simpler design is not > compatible. Mine is labeled (on the PCB): > > "LIMITED FUNCTION BD. > 5411507 > 5011506C-P2" > > And the one I need is: > > "LIMITED FUNCTION > 5411165 > 5011167" > > However, the picture I have of the other is not so > good. I may have read the numbera wrong. > > I would very much like to buy one to finish this > project. > > /P F?r du inget napp s? ritar jag upp ett kort till dig, det borde g? att flytta ?ver brytarna fr?n det du har. Lite synd att scrappa ett originalkort bara, men ?r man f?rsiktigt s? man inte tar s?nder det s? g?r det ju att ?terst?lla... /A

7 years, 2 months

3
4
0 0

PDP-11/45 RSTS/E boot problem

by jnc＠mercury.lcs.mit.edu

> From: Paul Koning > Another possibility occurs to me: bad bits in the MMU (UISAR0 register > ... if UISAR0 has a stuck bit so the "plain" case maps incorrectly > you'd expect to come up with execution that looks nothing at all like > what was intended. One would hope that the DEC KT11 diagnostic would check for this... but just to be thorough, we have in fact written a short diagnostic which stores every possible value in each UISA register and checks that it's correct. So unless there is some sort of pattern sensitivity (e.g. when A is in UISAm and B is in UISAn), that's not it. Also, and perhaps more significantly, when checked after the trap happens, all the UISA registers and all the KISA registers contain correct data. So, unless it's something where _sometimes_ one reads UISAn and gets X when it actually contains Y, I'm not sure the SARs (PARs) are involved. > From: Jon Elson > OK, here's a really complicated thing to try. If you know the physical > memory address of ls when it has the problem We do (see above), and 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 (i.e. if we see the same wrong contents), to make sure we didn't make a mistake somehow. > write a machine language program that loads a copy of ls into that > location and then tries to read it back. Yeah, it may come to that. One issue we've been having is doing specialized test programmes; trying to run the C compiler fails. I don't know about the assembler, though. And as Fritz mentioned, it takes hours to load a new disk image. I think we've come up with a way around that, though; produce binary of stand-alone tests elsewhere (I've often/always got a v6 running on Ersatz-11 here), and load them into the /45's main memory with PDP11GUI. Noel

7 years, 2 months

6
9
0 0

PDP-11/45 RSTS/E boot problem

by jnc＠mercury.lcs.mit.edu

So I've been helping Fritz look into his -11/45 problem, and things have gotten to a point where I'd like to reach out for help, more eyes, etc. I have to say, I spent almost a decade at the start of my career working on PDP-11 hardware ('new build' DMA devices, as well as fixing broken stuff), and software, and this is, I think, the most confusing and difficult problem I have _ever_ seen on one. Hence the above... What's _particularly_ confusing and difficult is that it seems like _three_ separate, un-related things all go wrong at exactly (2 of 3) or close to (the other) the same time. And the machine now passes all the diagnostics that have been thrown at it, particularly the KT11 and RK11 diagnostics (why this is important will become clear). So here's what we've found to date. The failure we're looking at is that an attempt to execute the 'ls' command under Unix V6 fails; it gets a memory mangement fault, and dumps core. AFAICT, the shell successfully forks, and its attempt to do an exec() of 'ls' sort of works (more below), but a few instructions in, we get the MM fault - but there's even more wrong when that happens (details toward the end below). I've been looking at the core dump produced by the process, which gives me the registers at the time of the trap, the user's stack, etc - but not a copy of the binary code - the 'ls' command is a so-called 'pure text', i.e. the binary is segregated into separate, potentially shared, read-only 'segment(s)' (only 1 in this case) of the PDP-11's User mode address space, and is not included in the process dump. (I use the term 'segment', which is actually what DEC called them in the first version of the PDP-11/45 processor handbook, because that's what they are, not pages, as pages are on most systems. I assume they changed to 'page' for marketing reasons. And please, can we hold debate about this and focus on the problem? Thanks! :-) I do have the ability to look at the binary that it _should_ be executing, by examining the command in its file. Also, Fritz has worked out that he can patch the MM trap vector (before trying to do the 'ls') to halt the machine when it happens, so he can read out all the KT11 registers, look at the actual program in main memory, etc. First oddity - the problem is dependent on the location of the command in main memory! If Fritz says "sleep 360 &", to run a trivial command in the background, and _then_ says 'ls' - it works (so we know the binary of 'ls' on disk is OK)! We _think_ this is because the process executing the 'sleep' takes up a chunk of main memory, and thus changes the location of the process executing the 'ls'. The problem is that I'm reluctant to try and change anything (e.g. to have the OS print out anything) because that will change the location of things, and we may (likely?) will not get the problem. With nothing changed, it _reliably_ fails - I've looked at two different core dumps, and all the essential data (registers, user stack etc) are identical. The KT11 registers all seems to be the same, too. So, on to details. I'm pretty sure the command only gets a few instructions in before it blows up. Here are the process' registers, and the _entire_ contents of the user mode stack: R0 177770 R1 0 R2 0 R3 0 R4 34 R5 444 SP 177760 PC 010210 060: 000000 000020 000001 177770 177774 177777 071554 000000 010210 turns out to be the first word in 'csv', which is an internal routine which PDP-11 C uses to build a stack frame - _every_ C routine starts with a "JSR R5, CSV" instruction as the first thing it does. So looking at the stack (which looks good; it contains a valid 'argc' and 'argv' that the process would be started with), and the registers, I'm pretty sure it does these starting instuctions OK: start: setd mov sp,r0 mov (r0),-(sp) tst (r0)+ mov r0,2(sp) jsr pc,_main _main: jsr r5,csv and then blows up on: csv: mov r5,r0 So it's the 8th instruction in that blows up (*): but not only is what's in memory at that location _not_ 'mov r5,r0', it also gets an MM trap that makes no sense. (*: In user mode: if you don't have an FPP, the first one will trap, which UNIX ignores.) Fritz has looked at the KT11 register when the trap happens, and the PARs and PDRs all look good. The SSRs contain: > SSR's: 040143 000000 010210 000000 SSR2 gives the PC at the time of the fault (again 010210); SSR0 shows: Abort - segment (page) length error User mode Segment (Page) 1 which is the first thing that's wrong - neither the instruction that's _supposed_ to be there (next), nor the one that's _actually_ there, contains any reference to segment 1! The _actual_ code it's trying to execute is: > 171600: 016162 004767 000224 000414 006700 006152 006702 006144 (Per UISA0, text base is 0161400, plus a PC of 010210, gives us 0171610, which is right in the middle there.) That does not, alas, look anything _at all_ like what's _supposed_ to be there, which is: 010200: 110024 10400 mov r4,r0 167 jmp 10226 (cret) 16 PC-> 10500 mov r5,r0 (start of CSV) 10605 mov sp,r5 10446 mov r4,-(sp) 10346 mov r3,-(sp) So somehow the command (at least, this part of it - Fritz is going to check on the first few instructions, but I'm pretty sure they will be OK) has gotten read in wrong - but that's the least of our problems! 06700 is 'SXT R0', and neither that nor 'MOV R5, R0' can _possibly_ cause an MM violation - least of all one on segment 1 (this code is in segment 0)! I could see there having been an error reading in the command binary (e.g. maybe the RK11 has an issue), but WTF is happening here? Just to make things triply confusing, R5 contains trash! The 'JSR R5, CSV' _should have put the old PC in R5; but that call to CSV is at 030, so R5 _should_ contain 034, not 0444. Needless to say, this is a real head-scratcher. What's confusing the heck out of me are the three separate issues, all happening together - R5 contains junk, the spurious (?) MM trap, etc. The bad command binary in main memory could be caused by any number of things: to get it, Unix reads file system blocks off the disk into buffers in low memory, and then writes them out to the user's memory with MTPI. So an RK11 glitch could be doing it, but also a KT11 problem, etc. I'm having a hard time seeing a common thread here - maybe a KT11 issue? But how would that cause R5 to contain trash? That should only involve the KB11. And the JSR R5, CSV must have been executed more-or-less OK, otherwise how did it wind up at CSV? I was wondering if some noise could be causing it - some sort of pattern sensitiity - but how is it bashing R5 _and_ causing a spurious MM trap? That's some glitch! Most of the data above (e.g. SSR contents at trap time) has been re-checked, and Fritz is going to check the rest (e.g. actual main memory contents for the start of the code, and the user's stack - to check that the process' core dump worked OK - although given the consistent stack contents, I'm expecting those to be good). I suggested to him that the time had come to apply the logic analyzer; I'd love to see (from the IR in the CPU) the instruction that faults, and where it came from. And also what the bus cycle is that's causing the fault; is it the instruction fetch (possibly) or something that instruction is trying to do? Does anyone have any comments/insight that could help work out what's going on here? Or suggestions on things to look at? If so, thanks! Noel

7 years, 2 months

8
17
0 0

Another dealer going under

by sales＠elecplus.com

I don't get replies from here yet, so I have seen no replies to my posts, nor the posts themselves. There is a shop that has been in biz for over 25 years that is closing in California. I asked for anything old Apple, Sun, HP, IBM, and any old keyboards. She will call me back tomorrow. She never dealt with the off brands, just major maintenance contracts. 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

7 years, 2 months

2
1
0 0

Penn Computer is out of biz

by sales＠elecplus.com

Unfortunately, they have already scrapped everything! They were distributors of old HP and IBM hardware. 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

7 years, 2 months

1
0
0 0

DZ11 H3006 8-line EIA distribution panels

by jnc＠mercury.lcs.mit.edu

If anyone out there needs an EIA distribution panel to go with their DZ11, here: https://www.ebay.com/itm/321225351590 are some of the 8-line ones (as used in the later modular back panel system). The seller (Efi) is good people. Noel

7 years, 2 months

1
0
0 0

IBM M122 keyboards in Quebec

by sales＠elecplus.com

Daniel Fecteau 6025 Arthur sauv? Mirabel, Quebec J7N 2W4 TEL: 450-969-1616 ext 101 Mail: save at savesysteme.com He has a variety of Model M 122 key keyboards. Contact him if you are interested. 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

7 years, 2 months

1
0
0 0

Not a test (Was: test)

by jnc＠mercury.lcs.mit.edu

> From: Cindy Croxton > I changed email providers, and received no emails for a week. If you > tried to contact me, please ask again! Perhaps 'test' was not an optimal Subject: line - a lot of people think that flags a message they can ignore, and not even look at - which was not what you wanted! :-) Noel

7 years, 2 months

1
0
0 0

WTB : Card extender for HP 21xx ( Fit from 2116 to 21MX )

by gerardcjat＠free.fr

Hi Al. $ 60, plus shipping ? I live close to Paris, France. Zip Code : 77310 ( Payment through Paypal seems the only way ?? ) On an other subject, did you see my previous cctalk post on imaging HP 1000 L series Eprom ? Any interest ? Best regards Gerard

7 years, 2 months

1
0
0 0

HP 1000 L series, parts available, anyone ??

by gerardcjat＠free.fr

I own a HP 1000 L series 200 Cards are badly corroded at connectors level BUT some other parts are in very good shape. I can offer, HP "special SoS" processors : 1AA6-60004, 1AC5, 1AB5, 1AF5 ( - 60001 ) The set of (3) Eprom .... I cannot image them, but I am willing to send them to someone that will do it. Al. may be ? The power supply seems in pristine state. Just have to check more closely if needed. Other parts ? .... just ask. "fee" : Eprom, free Processors : shipping cost Power supply : shipping cost + a little more for packing material and my time. I am in France, close to Paris.

7 years, 2 months

2
1
0 0

test

by sales＠elecplus.com

I changed email providers, and received no emails for a week. If you tried to contact me, please ask again! 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

7 years, 2 months

1
0
0 0

2026

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