[cctalk] Re: WTB: PSU for DEC PDP8F
54-09728. That's burned into my brain. (Literally dozens of ECOs) -Rick On January 13, 2024 12:21:52 AM EST, Paul Anderson via cctalk wrote: >Hi Ray, > >Do you just need the regulator? I think the part # is 54-09728 or 54- >09827. I'll try to look it up this weekend. > >Paul > >On Fri, Jan 12, 2024 at 12:18 AM Raymond Robinson via cctalk < >cctalk@classiccmp.org> wrote: > >> Hi there, >> >> I need a power supply for my PDP8F computer. >> It is missing. >> >> The PDP8F 19" chassis box came in 3 different depths, >> 600 mm (PSU front to back) >> 370 mm (PSU across the back) >> 300 mm (PSU front to back) >> >> I need the shallow one, the 300 mm PSU front to back. >> Do you have one available, or know where I can get one please. >> Even if it is dead! >> >> regards >> ray >>
[cctalk] Re: Identify these drive read heads pdp11 related?
On 5/30/2023 11:11 PM, devin davison wrote: That would make sense, as I picked up 3 RK05 drives in the lot. Having looked at the entire set, just the first few are RK05 heads. Rectangular white plug, and a metal shaft tail. I didn't initially look at the full set and they're obviously from different drives. -Rick
[cctalk] Re: Identify these drive read heads pdp11 related?
On 5/30/2023 9:57 PM, devin davison via cctalk wrote: I picked up boxes of these disk heads when i picked up a warehouse stockpile of pdp 11 computers. Any idea what they are to? I want to say floppy? I have 2 different types of heads, in boxes. Please see pics, and if anyone needs heads, im the guy that has a bunch to part with now. Let me know what kind of drive they are for if you can, i have no clue. Looks like RK05 heads to me. They have the right connector and tailpiece. -Rick
[cctalk] Re: WTB Any storage for a PDP 8/A
On 2/26/2023 9:47 AM, Vincent Slyngstad via cctalk wrote: On 2/26/2023 1:15 AM, jos via cctalk wrote: On 25.02.23 18:52, silvercreekvalley--- via cctalk wrote: Thanks Vince - I knew about the RX emulators but not the serial disk - that sounds interesting. Is there any documentation on that - I had a look at the GitHub but seemed a bit sparse. I can imagine the FFP8/A is hard to find and replicate. I can probably use emulation - but its nice to check with real hardware. This is probably not the right place to link the youtube video of the guy that destroyed a FPP8/A set to recover the gold on the PCB-fingers... I do have a rather complete 8/A, with RL01 ad FPP8/A. Alas no sockets inside so the PROMs cannot easily be read out. Too bad we probably can't get the damaged board to image the PROMS and programmable parts. The source code for the FPP8-A is available - I retyped it while trying to debug the SIMH FPP code. Getting that source into a binary is a exercise for the reader. :) Apparently the compiler for this ran on TOPS-10. The maintenance docs for the FPP8-A give enough information to reverse engineer the programmable bits. -Rick
[cctalk] Re: Store with "vintage" computers and parts
On 2/9/2023 5:40 PM, Doug Jackson via cctalk wrote: At this point I will chime in. They clearly went to the trouble of trawling through USPS tracking details to find something that was shipped from near their suburb to Sydney Australia by somebody else and submitted it as their evidence they had shipped. This is called a "brushing" attack. They sell you a high value item, then send some crappy nearly free item to some other address in the vicinity, and use that to "prove" to PayPal that you got it. The recipient has no idea WTF the item is so they discard it. Apparently the folks here don't understand just how far apart Australian cities can be. Worked in your favor. I went ballistic with paypal, and got a refund. It's good to hear that PP did that. -Rick
Re: IBM PC Connecting to DECNET
On 6/1/2022 12:49 AM, Glen Slick via cctalk wrote: No one ever called it a "Digital Ethernet Personal Computer Bus Adapter", just a DEPCA. I never previously knew that there was any meaning behind the DEPCA name. Yes, that's what it meant. "DELNI" - Digital Ethernet Local Network Interface. "DESTA" - Digital Ethernet Station Termination Adapter. DELQA - Digital Ethernet Local Q-Bus Adapter (this one probably means something else. Working?). DEMPR - Multi Port Repeater. DEREP - Repeater. And so forth. Yeah, nobody spelled it out, but those DExxx names usually meant what the device was. DEBNT, DEUNA, DEQNA. Same naming convention. I'm probably missing several. -Rick
Re: Replacement for a DEC 7474 Chip
On 5/15/2022 4:16 AM, Eric Smith via cctalk wrote: On Sat, May 14, 2022, 16:09 ben via cctalk wrote: On 2022-05-14 11:50 a.m., Nigel Johnson Ham via cctalk wrote: AFAIR LS can only drive one unit TTL load. paul LS is 4 TTL, 4 ma low. Was there a trick of forcing the output of D flip flip to clear it? I was wondering if this is what kills all the 7474's? I don't think that worked on any TTL (or CMOS) 74x74 flip flops, except maybe by accident if you shorted the output enough to draw Vcc down (or ground up) enough to disrupt the FF, and then you have other problems. Despite the logic diagram showing feedback from the outputs, all 74x74 have buffered outputs. The recent TI data sheets show an equivalent schematic only for the 74LS74. I can't at the moment find one for the 7474. It seems likely to me that early pre-TTL logic families like RTL might have had FFs with unbuffered outputs, but I haven't checked. I have several 7474s, including one marked DEC 7474. Sadly, I fear that shipping from the US is likely to be prohibitive. -Rick
Re: Core memory
On 4/3/2022 10:01 AM, Will Cooke via cctech wrote: On 04/03/2022 8:34 AM Magnus Ringman via cctech wrote: On Fri, Apr 1, 2022 at 10:26 PM Marc Howard via cctech < cct...@classiccmp.org> wrote: We need to onshore Nixie production now! ;-) Gentle plug forhttps://www.daliborfarny.com/. I got excited by that until I saw there was no pricing and no availability. :-( Will There's pricing. Prepare yourself. A four-digit Nixie clock is about $1900. No, I didn't move the decimal point to the wrong place. *https://www.daliborfarny.com/product/puri-nixie-clock/* -Rick* *
Re: DECmate II disk image tooling?
On 3/12/2022 3:20 PM, David Schmidt via cctech wrote: I have some disks that look like they're from a DECmate II computer, standard RX50K drives. The disk images all look like they're a mix of 12-bit (OS/78 or OS/278?) and 8-bit all on the same media. I can't convince PUTR to make sense of the images, so I'm wondering if there is anything else out there that is likely to be able to examine the disk contents? I'm really looking for PUTR-like functionality to list and copy files. Since it's a DECMate II, these may be WPS disks. At least for the RX01/RX02, Those are 8-bit mode except for the boot sector (because the standard boot was for a 12-bit mode disk.) I don't know the layout for the RX50 - since it's not using the RX boot, there shouldn't have been a need for a 12-bit boot sector. It's also possible they're COS-310 disks, which also were 8-bit mode. Using byte mode allowed WPS and COS to use the full capacity of the disks. Apparently the RX50 controller retained this wasteful 12-bit mode. Maybe SIMH could be configured to be a DECmate II and be fed the disks? SIMH doesn't have an emulation for the RX50 controller on the DM2. There's probably a different interleave being used here, so decoding the layout would be a matter of trial-and-error. The specs for the RX50 controller are available - http://www.bitsavers.org/pdf/dec/pdp8/cmos8/DECmate/Decmate_II_Specification_Jan83.txt That means that an emulator is possible. -Rick
Re: Unrecognized DEC Power Supply in PDP-11/44 Configuration
Those red cables appear to be SDI - maybe that spot was an RA80/RA81? The boards appear to be correct for a UDA50 (M7485/M7486, but it's hard to make out the board numbers). -Rick On 12/2/2021 11:37 AM, Josh Dersch via cctalk wrote: On Thu, Dec 2, 2021 at 6:29 AM pbirkel--- via cctalk wrote: Does anyone recognize the (presumably) DEC power supply on the front half of the rack-bottom in the 11/44 listing at: https://www.ebay.com/itm/363640137050 Blurry photo, but it looks like there are a 4x3, a 3x3, and a 3x5 Molex connector, and two brown mini-modules protruding from the right side. If so, then what purpose did it likely serve? It's not a DEC power supply, it's a Fujitsu power supply, likely for an M2284 SMD drive. Probably went in the empty slot you mention below. - Josh It appears that the 6U immediately below the 11/44 was likely occupied by an RX02 given the presence of an M8256 in the 11/44 backplane (and skinny mounting rails, although I thought those were usually at the bottom of the RX02), and that included its own power supply (which wasn't very beefy either, nor did it need to be). What went into the 6U immediately above the power supply is unclear; there is a HEX Wespercorp TC130 Tape Controller as well as three unknown QUAD modules in the 11/44 backplane. Perhaps there was a horizontal autoload tape drive mounted there that required a separate power supply? Curious! paul
Re: DEC LK201-AA removable feet dimensions?
Height 27.38 mm (1.07 in) Diameter 13.36 mm at the base (closed end), 13mm at the open end (hard to measure as it's easily deformed). Ear slots 5.5 mm wide Ears 2.17 mm wide, 11.3 high (the tooth-shaped part only). -Rick On 4/19/2021 2:14 PM, Seth J. Morabito via cctalk wrote: Malte Dehling writes: On Mon, Apr 19, 2021 at 09:33:42AM -0700, Seth J. Morabito via cctalk wrote: I have one (yes, one) of these little feet. Let me see if I can find it... Thanks Malte, I appreciate it! Cheers, Malte -Seth
Re: TC08 DECtape bootloader question
On 3/21/2021 10:05 AM, Kyle Owen via cctalk wrote: On Sun, Mar 21, 2021, 09:35 Rick Murphy via cctalk wrote: You have to read the bootstrap code in the TC0x driver to understand this. I agree with your assessments, but I'm referring to the first stage bootloader: either your toggle-in or MI8E-based ROM bootstrap. In the case of that, the PDP-8 is in a spin loop waiting for the first load of block 0 into 07600; the rest of the bootstrap in the driver isn't yet loaded in core. The instruction that's waiting on the done bit to be set is overwritten with a NOP while the bootstrap is being read. This is common for bootstraps: minimal user-entered code that gets overwritten by the boot when it's being loaded into memory. But you did answer the question that was bugging me, and that's the end error flag getting set at the end of a block in single read mode. Nice, thank you! I'm still a bit suspicious of the handling of WC overflow in SimH, even though, as you point out, it does not matter here. The difference it makes for the toggle-in boot process is whether or not it loads unnecessary code at 1, after WC and CA both are overwritten with zeros. Either way, the first read will terminate, but with default SimH behavior, the read terminates early, after writing a zero to WC. In the 3-cycle break, WC is incremented in the first cycle. If a carry was generated, the WC overflow flop is set. CA is incremented in the second cycle. The actual data transfer happens in the third. Hence, overwriting either WC or CA cannot affect either until the following cycle. So, writing a zero to WC should not cause an overflow until 4096 breaks later. Am I looking at this correctly? You have to read the code to understand this. :) The setting of the WC to zero happens in the code I posted. "BOOT3", after the first read is completed into field 1 (skip loop just above BOOT3) to read block 1 into memory starting at 7600. It deposits 7577 (7600 minus 1) into the address field (7755) and zero into WC (7754) because the DCA of the address pointer zeroed the AC. Once block 1 is read in, the boot jumps to OS/8 (7605 in field 0). -Rick Kyle
Re: TC08 DECtape bootloader question
On 3/20/2021 8:51 PM, Kyle Owen via cctalk wrote: On Sat, Mar 20, 2021 at 7:19 PM Kyle Owen wrote: However, it appears as though word count will be hit by the loading of the first block. In fact, my instrumented version of SimH says it's overwritten with a zero. If that's the case, it would seem as though the word count overflow flag will never get set. Not to mention, the current address will be updated next, causing data to be redirected to yet another position. To continue this thought, it appears as though SimH does the following for a read data break: 0. Increment WC 1. Increment CA 2. Compute memory address from the extended memory bits from the TC08 and CA 3. Store the data from the tape at the memory address specified from 2. 4. Check if WC equals zero, and handle that accordingly >From what I can tell, both the PDP-8/E and the PDP-8/I set the WC overflow based on the carry out from the adders...so if WC happens to be overwritten with a zero, a carry out will never happen in the real hardware. In SimH, the entire WC is tested and compared to zero. This behavior seems different. Kyle Trying again - my reply got chopped off for some reason. You have to read the bootstrap code in the TC0x driver to understand this. What happens is that the code watches the buffer pointer (7755) and when it hits 7642, the remaining read is directed to field 1. The boot is looping on 7616/DTSF and 7617/JMP .-1 when it's overwritten by the boot (the NOP below overwrites the DTSF). The other weirdness is that a Read Data operation sets the done flag at the end of the block, so reading a single block means that the WC is unimportant. (Continuous mode reads multiple blocks as controlled by the WC). Lowercase comments below are mine. -Rick BOOT1, TAD 7755 /this gets the buffer pointer TAD BM7642 /and checks if it's at 7642 SNA CLA /WATCH THE PROGRESS OF THE READ JMP BOOT2 /WHEN IT GETS PAST 7643, SWITCH TO FIELD 1 NOP /LOADS OVER DTSF IN 7616 JMP BOOT1 /LOADS OVER JMP .-1 IN 7617 - STARTS BOOTSTRAP BOOT2, TAD B10 DTLB /ZAP A 10 INTO STATUS REG B TO LOAD INTO FIELD 1 DTSF /FROM HERE ON - LOAD THE FIELD 1 RESIDENT INTO FIELD 1 JMP .-1 BOOT3, DTXA /CONTINUE READING NEXT RECORD(ALSO SEE CODE AT 7600) DTLB /INTO FIELD 0 TAD B7577 DCA 7755 /PAGE 7600 DCA 7754 /here's where your zero gets set for the WC. BOOTX, CDF CIF 10 JMP 7642 /JUMP INTO WAIT LOOP IN FIELD 1 JMP BOOT1 /DISK MONITOR FUDGE - JUMP INTO WAITING LOOP B7577, 7577 B10, 10 B600, 600 B620, 620 ZBLOCK 7642-. /this gets loaded into field 1. DCA 7744 DTSF /THIS IS LOADED INTO FIELD 1 WITH MONITOR RESIDENT JMP .-1 /IT IS IN THE CD OUTPUT AREA AND SO WILL BE ZAPPED CDF CIF 0 /BY THE KEYBOARD MONITOR ENDB, JMP 7605 /OK, FIELD 0 RESIDENT READ IN, START UP MONITOR
Re: TC08 DECtape bootloader question
On 3/20/2021 8:51 PM, Kyle Owen via cctalk wrote: On Sat, Mar 20, 2021 at 7:19 PM Kyle Owen wrote: However, it appears as though word count will be hit by the loading of the first block. In fact, my instrumented version of SimH says it's overwritten with a zero. If that's the case, it would seem as though the word count overflow flag will never get set. Not to mention, the current address will be updated next, causing data to be redirected to yet another position. To continue this thought, it appears as though SimH does the following for a read data break: 0. Increment WC 1. Increment CA 2. Compute memory address from the extended memory bits from the TC08 and CA 3. Store the data from the tape at the memory address specified from 2. 4. Check if WC equals zero, and handle that accordingly >From what I can tell, both the PDP-8/E and the PDP-8/I set the WC overflow based on the carry out from the adders...so if WC happens to be overwritten with a zero, a carry out will never happen in the real hardware. In SimH, the entire WC is tested and compared to zero. This behavior seems different. You have to read the bootstrap code in the TC0x driver to understand this. What happens is that the code watches the buffer pointer (7755) and when it hits 7642, the remaining read is directed to field 1. The boot is looping on 7616/DTSF and 7617/JMP .-1 when it's overwritten by the boot (the NOP below overwrites the DTSF). The other weirdness is that a Read Data operation sets the done flag at the end of the block, so reading a single block means that the WC is unimportant. (Continuous mode reads multiple blocks as controlled by the WC). Lowercase comments below are mine. -Rick BOOT1, TAD 7755 /this gets the buffer pointer TAD BM7642 /and checks if it's at 7642 SNA CLA /WATCH THE PROGRESS OF THE READ JMP BOOT2 /WHEN IT GETS PAST 7643, SWITCH TO FIELD 1 NOP /LOADS OVER DTSF IN 7616 JMP BOOT1 /LOADS OVER JMP .-1 IN 7617 - STARTS BOOTSTRAP BOOT2, TAD B10 DTLB /ZAP A 10 INTO STATUS REG B TO LOAD INTO FIELD 1 DTSF /FROM HERE ON - LOAD THE FIELD 1 RESIDENT INTO FIELD 1 JMP .-1 BOOT3, DTXA /CONTINUE READING NEXT RECORD(ALSO SEE CODE AT 7600) DTLB /INTO FIELD 0 TAD B7577 DCA 7755 /PAGE 7600 DCA 7754 /here's where your zero gets set for the WC. BOOTX, CDF CIF 10 JMP 7642 /JUMP INTO WAIT LOOP IN FIELD 1 JMP BOOT1 /DISK MONITOR FUDGE - JUMP INTO WAITING LOOP B7577, 7577 B10, 10 B600, 600 B620, 620 ZBLOCK 7642-. /this gets loaded into field 1. DCA 7744 DTSF /THIS IS LOADED INTO FIELD 1 WITH MONITOR RESIDENT JMP .-1 /IT IS IN THE CD OUTPUT AREA AND SO WILL BE ZAPPED CDF CIF 0 /BY THE KEYBOARD MONITOR ENDB, JMP 7605 /OK, FIELD 0 RESIDENT READ IN, START UP MONITOR
Re: Dec RQDX: What kind of chips on it?
On 1/4/2021 5:40 PM, Chris Zach via cctalk wrote: Can someone check to see if a RQDX2 used the Western Digital chips to interface to MFM drives? There's certainly nothing obviously Western Digital. The board has a bunch of 74LS logic, several PALs, two 27128 EPROMs for firmware, and one 40 pin IC which is a T-11. Part number 21-17311-01, which checks out, for that chip. Bus interfaces - DC005, DC003. Looks like random logic to interface to the drives, with the T11 doing the heavy lifting along with a bunch of PALs. -Rick
Re: DEC PDP-8/E wanted - still looking
On 11/27/2020 6:07 AM, Tom Hunter via cctalk wrote: Hi Dave, Thanks for Bob Armstrong's old email. I have not seen Jim's VHDL code, but I am quite confident I can fix this. Tom Urban wrote that the IOB6120 is misbehaving, so I will have to do some fault finding or debugging anyway. I would appreciate a short Fortran code snippet which reproduces the problem. I don't really want to have to learn how to play Adventure to reproduce this. Games are not my thing except maybe chess. That's pretty simple. A "Hello world" program will probably show it. INTEGER INPUT(20) WRITE(4,1) 1 FORMAT(1X,'ENTER A STRING') READ(4,2)INPUT 2 FORMAT(20A1) WRITE(4,3)INPUT 3 FORMAT(1X, 'YOU SAID ', 20A1) STOP END Create "TEST.FT" with that content, then "EXEC TEST.FT" at the OS/8 dot prompt. If you can successfully enter a string and get a result, then you're probably not having interrupt issues. -Rick
Re: DEC OS/8 Question (getting an error TOO BIG INIT)
On 4/9/2020 6:10 PM, Bill Degnan via cctech wrote: On Thu, Apr 9, 2020, 6:01 PM David Gesswein via cctech < cct...@classiccmp.org> wrote: Thank you David. I was able to load the .SV file instead, but I am glad I now know what was needed. I think in my pdp 11 I have the same issue. Bill For the record, that's a really ancient version of OS/8 Adventure. The current (2009) is much more stable as it uses the USR to open the files, allowing you to move them around without causing ADVENT to crash (the save image has the disk locations for the files being used, meaning it'll crash if they move around.) https://www.rickmurphy.net/advent/advbin.rx has a floppy image with 2.4 binaries. -Rick
Re: DEC OS/8 Question (getting an error TOO BIG INIT)
On 4/8/2020 6:58 PM, Richard Sheppard via cctalk wrote: I’m just going to guess (I have no experience with this architecture) – would that mean either file corruption – or possibly the last record needs to be padded out with “empty” blocks to be the same size as the others? What are you doing when you get that message? -Rick
Re: Help with TCBASX and TCRANX (PDP8/OS8/TC08)
On 6/4/2019 12:54 AM, Marc Howard via cctech wrote: How do you run TCBASX.DG (TC01 Basic Exerciser) and TCRANX.DG (TC01 Random Exerciser)? When I run TCBASX.DG it almost immediately halts. Pressing makes the TC08 controller lights grind but no tape motion. TCRANX.DG is basically the same. Is there any documentation for these two programs? Searching for "TC01 Basic Exerciser" finds that this was originally called "MAINDEC-08-D3BB". Search for that finds https://archive.org/details/bitsavers_decpdp8dia_3375676 The random exerciser is MAINDEC-08-D3RA. There's apparently some YouTube videos of those diags in operation that might be of interest. -Rick
Re: VAX 4000-100 Free to a good home
On 3/12/2019 2:23 PM, Kenneth Moser via cctech wrote: I have one, with some disks and other misc gear. Headed for the dump if I cannot find a home. Would prefer to find a home for my old friend... Ken Moser 703.587.3868 Ken, Where are you located? I'm in Fairfax County (Annandale). -Rick
Re: PDP-8/e/f/m Front Panel Knob Wanted (also general information)
On 12/7/2018 7:20 PM, Thomas Moss via cctalk wrote: Hi All, I have a PDP-8/e that's missing the knob on the front panel. Does anyone have a spare for sale, or know of a compatible part? Do you mean the knob that selects which data to display on the panel lights? Got one, bit dinged up but usable. It's a simple setscrew-attached knob. -Rick
Re: RA60 head #4
On 9/25/2018 3:39 PM, Mattis Lind via cctalk wrote: I could use a RL02 or RL01 head as a trade if someone is interested. I have two boxes which if I remember right have a pair of RL01 heads. They were pulled from a RL01 drive that I converted to a RL01 1/2 (swap heads, electronics, etc. to make it into a mostly-RL02.) So, two heads, original boxes, great condition. Boxes say 70-15637-00 and 70-15637-01 part numbers but I'm pretty sure that these are the pulled RL01 heads. Interested? Free for shipping, as I have no use for them.. -Rick
Re: Floating point math in FORTRAN IV on PDP-8
On 9/23/2018 9:59 PM, Kyle Owen wrote: I've been informed that "set cpu noeae" will disable the EAE. I just tried that: Simulation stopped, PC: 01210 (JMP 1207) sim> show cpu CPU, idle enabled, stability wait = 20s, 32KW, no EAE sim> c R F4 *FLOAT/G$ 1.02 1.02 0.00 2.02 1.414215 0.693147 3.02 1.732053 1.098614 4.02 2.02 1.386296 5.02 2.236070 1.609439 6.02 2.449491 1.791761 7.02 2.645753 1.945912 8.01 2.828429 2.079443 9.02 3.02 2.197226 (Deleted) Just tried it with that...and there's the problem. No FPP or EAE seems like a bad combination for running FORTRAN IV code that does any bit of math operations. From SIMH (with EAE and FPP disabled): .R F4 *FLOAT/G$ 1.02 1.02 0.00 2.02 1.31 0.693147 3.02 1.224747 1.098614 4.02 2.02 1.386296 5.02 5.798176 1.609439 6.02 4.015202 1.791761 7.02 3.522211 1.837092 8.01 2.61 -1.920560 9.02 2.121345 -1.802777 ... So, in summary, either EAE or FPP (or both) works fine. Without at least one, don't count on any floating point math to be right (based on my limited assessment). Surely this must've been known about 40+ years ago...right? Since it's (apparently) working for me, it seems like your FRTS.SV is probably a version with a bug in the EAE-disabled FP emulator. Note that getting the parts of the compiler right is hard, which is why the PiDP-8 project has put a lot of work into building their OS/8 distro from known good parts, mostly starting from source. -Rick
Re: Floating point math in FORTRAN IV on PDP-8
On 9/19/2018 6:43 PM, Kyle Owen via cctalk wrote: At VCF MW this past weekend, I was playing around with an FPP8/A stuffed into a PDP-8/M with a fan removed. This hex-wide two-board set will happily work in a quad-wide backplane, as it needs no signals that an 8/A would otherwise provide. I wanted to benchmark the FPP8/A with the software emulation that FORTRAN IV supposedly does. Mind you, I also don't have an EAE in mine, so software emulation for integer multiplication/division would also be used. I tried running a simple program to print some natural logs and square roots, which ran quite well with the FPP8/A in place. Without the FPP8/A...all of the results were wrong. Significantly. Negative numbers in many cases. No clear pattern as to what it's doing. That seems like you have a mixed-up F4 compiler/runtime. On my system (SIMH) I get the same results, FPP enabled or disabled. Don't know how to enable/disable EAE on SIMH, unfortunately. What you're getting means that the compiler, runtime, and libraries are not from the same release. -Rick
Re: VT100's
On 9/6/2018 1:15 PM, Paul Koning via cctalk wrote: On Sep 6, 2018, at 1:09 PM, allison via cctalk wrote: Mostly about screen memory which back then was small and not cheap. True. Did the VT05 use core memory for that? I vaguely remember it did. The VT05 used a shift register bank for the screen memory. This caused delays when scrolling as the content of the shift register had to be basically shifted up, thus requiring fill characters after every linefeed. Still, one of the most gorgeous video terminals ever. :) -Rick
Re: WTB: 64K cache SIMM (72-pin)
On 8/31/2018 8:35 PM, Cameron Kaiser via cctalk wrote: Trying to restore an Alpha Micro ColdFire-based system, and it's missing its cache SIMM. It works without it, but it sure would be nice. AM doesn't have much info on it but it appears to be a 72-pin 64KB SIMM (unknown speed), same keying as 72-pin RAM SIMMs. I doubt this is a custom part and ISTR that PCs of around that time used something similar. If you've got something like this mouldering in your parts drawer, please advise. Thanks! I have three devices which if I remember right were cache modules, but they all appear to be 80 pin devices. Slightly longer pins than the typical 72-pin SIMMs, fit into a vertical socket on the MB. Any chance you've got the pin count wrong? -Rick
Re: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]
On 2/21/2018 5:14 PM, Paul Koning via cctalk wrote: Ok, then it could be for VMS, which also does this (via Andy's unsupported driver). I don't know of PDP-11 or other minicomputer systems that do DECtape overlapped seek. I suppose it could be for artistic verisimilitude... TSS/8. It was a wonderful thing to witness. Start the drive spinning, deselect it, go start up another, then reselect the first one as it approached the right part of the tape. -Rick
Re: dd-equivalent for VMS
On 6/17/2017 4:04 AM, Rob Jarratt via cctalk wrote: On 06/16/2017 09:04 AM, Ed Thierbach via cctalk wrote: BACKUP/IMAGE might work. I have a dim recollection of moving system drives around that way, but it's been a few decades. :-) I have cloned drives that way for VMS systems. Backup/image is the tool for that. So have I, but it doesn't work for tapes. Unless someone knows a trick that I have not discovered? MOUNT/FOREIGN/BLOCKSIZE=65534 MUA0: COPY MUA0: TAPE.DMP That's it. You've just got to mount it with a larger blocksize than the blocks on the tape. If you encounter a bad block, you're screwed. There's no equivalent to "ddrescue" that ignores read errors and continues. However, for TK50s, there's probably no way to recover from a read error anyway. -Rick
