[cctalk] Re: IBM 1410 FPGA Status
On Mon, 2023-07-10 at 21:32 -0500, Jay Jaeger via cctalk wrote: > Over the past couple of months I have been working on my FPGA > implementation of the IBM 1410 ... What are your plans for implementing I/O? Are you going to emulate a card reader and line printer using an SD card and a FAT filesystem? Or maybe an Ethernet connection? It's a batch system; how will you submit jobs to it? Just curious... Thanks, Bob
[cctalk] Re: DEC VT180 "Robin" Maintenance Prints?
>Rob Jarratt wrote: >Have you checked here: http://9track.net/roms/ ... Hey, thank you! I didn't know about this particular collection, and he does have the ROM dumps for the VT180 Z80 board. I'd still like to find a schematic, though! Thanks again, Bob
[cctalk] DEC VT180 "Robin" Maintenance Prints?
Does anybody have the maintenance prints for the DEC VT180?The VT180, aka "Robin" was DEC's CP/M machine in a VT100 chassis. The terminal part is just a standard VT100 and maintenance prints for that are easy to find, but I need a schematic for the actual Z80 CP/M Robin option card. Can't seem to find that anywhere. Bitsavers and Manx have the technical manual which has some information (although it wastes way too many pages explaining how a VT100 works!) but no actual schematics. On the same topic, has anybody dumped the ROMs for this machine? Again, not the VT100 ROMs, but the CP/M boot/POST ROMs that are on the VT180 Z80 card. Thanks, Bob
[cctalk] Power supply for DEC VK100 GIGI?
A friend gave me a DEC VK100 (aka GiGi) recently. It's in really nice shape, but it is missing the power supply. Before I try to kludge something up with an ATX supply, I thought I'd ask if anybody knows where I might find an official replacement. Thanks, Bob
[cctalk] Re: Replacement tachometer sensor for DEC RA80/1/2 drives ...
>Paul Koning wrote: >Does the tachometer have to be accurate, or does it just have to indicate > "spinning fast enough" to satisfy the spin-up logic? It's not just spin up - the firmware monitors the disk speed all the time it's running. But AFAIK the tachometer has nothing to do with how the bits are recorded on the media. It's just there to be sure the disk is actually rotating. >If not, you could just use a 555 to generate a pulse train ... Maybe, probably, but I'm not sure why you'd want to. That's way more complicated than just fixing the tachometer sensor, and having the firmware shut down the motor in the event the belt breaks or jams, or if the motor brake (yes, it has a brake!) freezes, etc is an advantage. It's a fairly big motor and a fairly (by PC standards at least) heavy disk - there's a lot of mechanical energy there. Bob
[cctalk] Replacement tachometer sensor for DEC RA80/1/2 drives ...
I have three DEC RA8x drives that have failed (all of them fault with "spin error") because of bad photo-interrupter tachometer sensors. After talking to a few friends, it sounds like this is a pretty common fault. Photo sensors like this are fairly common, even today, but the specific parts DEC used are weird and unobtainable. I designed a little PC board that uses an ITR9606 photo interrupter, a 2N3904 and a resistor as a replacement. Works great - gives a beautiful 5V P-P clean waveform and with the PCB it's a mechanical drop in replacement. Just screws right onto the original mounting holes and plugs into the original connector. I put the PCB design up on OSH Park https://oshpark.com/shared_projects/z8DSkQsP If anybody needs one you're welcome to order some PCBs and build your own. The ITR9606 is as common as dirt, and you can buy bags of ten on Amazon for a few bucks. I've also put a few pictures on the Facebook DEC Computer Users group. I'd post the pictures here, but I don't think cctalk accepts attachments. It's not really worth making a web page for it. Bob
[cctalk] Re: PDP 8a front panel hardware
>Tony Duell >Is that the 3U (5.25" high) one? Yes.. >If so, there's a metal sleeve that is screwed in the rack. Oh yeah, that would make sense. There was a QBUS chassis that worked the same way. Was that a BA11-N? I forget - too many years have gone by :) Bob
[cctalk] Re: PDP 8a front panel hardware
> Tony Duell >I wonder if that's because on the 11/04 and 11/34 the boards go in >from the top of the box whereas on the 8/a the boards go in from the >front. Therefore you have to remove the frontpanel to insert/remove >boards on the 8/a but you don't on the 11's. The 11's panel is rarely >removed. Yeah, kind of. I actually have an 11/04 too, and the console there just screws on to the front of the BA11-K. Since the BA11-K has slides and pulls out of the rack and (as you said) the boards are accessed from the top, there's no need to ever remove the front panel. Don't know what the BA11-L (that's the short box for the 11/04) did. I don't think it had slides, but I'm not sure. The BA8-C, OTOH, doesn't have slides and (as you said) the cards go in from the front. So you need to remove the front panel anytime you want access to the cards, which is a major pain. Bob
[cctalk] Re: PDP 8a front panel hardware
>Bill Degnan mbilldeg...@gmail.com> wrote:
>Is there a 3D print gcode for the hardware that connects a PDP8a front
>panel to the chassis?
Assuming you're talking about the KC8-A (the panel with the push buttons and
7 segment displays) then I think there were at least two versions. The older
version was pressed onto those plastic ball things that all DEC "pop panels"
used. That didn't work very well, because those plastic pop panel mounts are
super easy to break.
There was a later version that mounted with two metal brackets. The brackets
screwed to the rack rails and were bent to conform to the inside contour of the
KC8. There's a setscrew in each bracket that attached it to the KC8, and
there's a small hole drilled in the bottom of both sides of the KC8 so you
could access the screw from the outside.
Annoyingly the PDP-11/04 and 34, which had a panel that was mechanically
nearly identical, used an entirely differently mounting scheme, so there's no
help there.
I've never seen one of these brackets nor a mechanical drawing for one, but
if you find out anything please let me know. I have an 8/A in the garage with
the front panel held on by wire ties ('cause I don't have anything better!).
Bob
[cctalk] Replacement tachometer photosensors for RA8x drives?
I've discovered that three of my four RA8x drives (one 82 and two 81s) now refuse to spin up. All the failing drives give "SPIN ERROR" as the reason and I've discovered, by an combination of educated guessing and parts swapping with the working drive, that all three have bad optical sensors for the tachometer disk. Surfing around I see that this is a known problem. Apparently the compound that was originally used to pot these sensors turns opaque over time and, being as they're optical sensors, that really reduces their effectiveness. I've seen some reports of people trying to repair the sensors by either sanding off a layer of the epoxy potting compound, or even trying to dissolve it somehow, but that seems to be a little bit hit or miss. Doesn't seem like these should be hard to replace though. They're just an infrared LED and a phototransistor in a cute plastic case, and that technology is still pretty common today. Has anybody found a replacement for them? Does anybody have any suggestions? Thanks, Bob
[cctalk] Re: DECnet to be dropped from Linux
> Grant Taylor wrote: >Isn't Tru64 a DEC product? I did say, "Excepting the Un*x derivatives"... >Would you stop using DECnet b/c it was removed from the kernel? Well, I wouldn't be able to upgrade that machine anymore. That wouldn’t be the end of the world, but eventually one of two things will happen - either I'll want to run some software thing that doesn't work with an older distro, or I'll need to upgrade the hardware and driver support for some piece of hardware won't be available in the older distro. Then I'll just have to quit using DECnet on Linux. I won't quit using DECnet, of course, as I have other systems which speak only that. I just won't be able to talk to them from Linux anymore. Bob
[cctalk] Re: DECnet to be dropped from Linux
>Grant Taylor >Okay. I hadn't considered other DEC OSs that don't support TCP/IP. AFAIK, VMS was the only DEC operating system (well, excepting the Un*x derivatives) that supported TCP/IP. There were several third party TCP/IP implementations for VMS (e.g. Wollongong, CMU, Process Software, ...) and eventually DEC came out with their own official implementation. Johnny Bilquist has a TCP suite for RSX, but that's a recent development and was never a DEC product. >I'm trying to understand how many installations are actually using >DECnet in Linux / how big the potential problem is / will be. You mean now, today, for actual real work? I have no idea, but I doubt it's very many if any at all. There are some of us hobbyists out there though, that still use DECnet. We even have a worldwide DECnet network tunneled over the Internet, and it's useful for some of us to have DECnet on Linux. I have such a machine here, with Ubuntu 16.04.7LTS and ESM, kernel 4.4.0-148. I would have upgraded it, but getting some of the user mode DECnet programs to run on later releases is problematic. Not impossible, but tricky. Are you part of the kernel team? I'm not really suggesting that DECnet support be kept, although there are a few of us who would appreciate it. Bob
[cctalk] Re: DECnet to be dropped from Linux
> Bill Degnan wrote: >Multinet Are you suggesting running Multinet on VMS so it can talk to the TCP world? Umm... The problem is that there are a lot more DECnet systems than just VMS. Bob
XXDP on a really small system?
I have an 11/03 (unmapped, of course) with 28kW memory and two DLV11s. I'm trying to build an XXDP image on TU58 that I can boot on this system, using an XXDP 2.5 RL02 image and simh. My simh configuration is - CPU 11/03, NOEIS, NOFIS, BEVENT disabled, autoconfiguration enabled, idle disabled . TTI address=1560-1563, vector=60, BR4 TTO address=1564-1567, vector=64, BR4 TDC controllers=1, address=17776500-17776507, vector=300*, BR4, 2 units . RL RLV12, address=17774400-17774411, vector=160, BR5, 4 units I can boot from the RL02 OK - MEMORY MANAGEMENT UNIT NOT FOUND BOOTING UP XXDP-SM SMALL MONITOR XXDP-SM SMALL MONITOR - XXDP V2.4 REVISION: D0 BOOTED FROM DL0 28KW OF MEMORY NON-UNIBUS SYSTEM RESTART ADDRESS: 152010 TYPE "H" FOR HELP But running UPDAT to create a new system image on the TU58 dies .R UPDAT UPDAT .BIC HALT instruction, PC: 10 (12) If I change the CPU to an 11/23 (but keep the same memory and other configuration) then UPDAT works. Is there some issue or limitation in running XXDP on a 11/03? Is it just UPDAT that doesn't work, or are there bigger problems? Thanks Bob
XXDP diagnostic sources
Hopefully this is an easy question - are the sources for the XXDP diagnostics online anywhere? I particularly looking for NKXA, the Falcon-11/KXT11/DCT11 one. Thanks, Bob
Gateway Electronics (was Al Lasher's electronics closing.)
> Jon Elson >And, our one remaining place in St. Louis, Gateway Electronics has also closed >recently. No - say it's not true!! I live in California but occasionally we drive cross country to visit my family in Indiana, and I always stopped there. We were last there in 2019... Bob
RK11-D "diskless" test ZRKJE0???
I have an 11/04 with an RK11-D. I have a couple of RK05s, but I wanted to test the controller before I start working on the drives. The PDP11 Diagnostic Handbook says that ZRKJ?? "checks only the drive-independent logic of the RK11 controller. no drive is needed..." I assumed that meant it was a diskless test, but now I'm not sure that's true. Can anyone confirm or deny this? Does anyone have a listing of ZRKJE0? My RK11-D has the BC11 drive cable plugged into the backplane, but the free end of the cable is just lying on the floor. No drive is connected. The test fails with RK11 LOGIC TEST I MAINDEC-11-DZRKJ-E REGISTER NOT CLEARED PC REGADD RECVD 002560 177402 10 177402 is the RKER register and bit 15 is DRE - "Drive Error". According to the manual this bit is set when the AC power to the drive is lost, which given that I don't have a drive at all, doesn't sound unreasonable. Continuing ZRKJ?? also gives REGISTER NOT CLEARED PC REGADD RECVD 002560 177404 140200 RKCS ERROR PC WROTE READ 002636 02 140202 177404 is the RKCS register and the first two bits are ERROR and HARD ERROR. These are both set by the DRE bit in RKER and aren't really a surprise. I'm starting to wonder if this diagnostic really works w/o a drive attached, or if these errors are expected. Thanks, Bob
RE: Fixing an RK8E ....
>Josh Dersch > one half-height (used upside down). Thanks, Josh - I hadn’t thought about using an extender card "backwards". That's a good idea. Next question is "how many extender cards do I have?"... Better go start digging. In the meantime I did some more fooling around with the diagnostic and discovered that it's apparently not really a stuck command bit after all. The tests are failing are #30 and #31, "VERIFY THAT RECALIBRATE INHIBITS LOAD COMMAND" and "VERIFY THAT RECALIBRATE INHIBITS LOAD DISK ADDRESS". Sounds like a problem with the recalibrate function instead. Bob
Fixing an RK8E ....
It appears that my RK8E has a problem - it fails the diskless control test with .R DHRKAE.DG SR= COMMAND REGISTER ERROR PC:1160 GD: CM:0001 DHRKAE FAILED PC:6726 AC: MQ: FL: WAITING Ok, maybe a bad bit in the command register so I'll check it out. But then it dawns on me - how do you work on this thing? It's three boards connected with "over the top" connectors - you can't use a module extender on it. Worse, the M7105 Major Registers board is the middle one of the stack! Is there some secret to working on this thing? Has anybody fixed one? Any suggestions? I hadn't thought about it before, but the KK8E CPU would have the same problem. Fingers crossed that one never dies... Bob
RE: Schematic for DEC H7441 (not the H744!)
>Eric Smith wrote: >DEC MK11-B Field Maintenance Print Set, October 1977 Thanks, Eric! I was just about to post that I discovered it's also in the PDP-11/04 maintenance print on Bitsavers, although it's not in the 11/34 print - go figure... I didn't actually need the schematic, although I certainly used it this time. The H7441 has a giant inductor (L1 in the schematic) that's physically bolted to the PCB. It a U-channel thing that looks like a transformer but is actually just a big 30+ amp choke. Some PCB layout guy decided it was a good idea to run the +5V output and ground traces directly under this choke so, unless it's elevated above the PCB, it will short the output! I think it must have originally had some kind of rubber or fiber washers underneath it, but in mine the washers had disintegrated and were nowhere to be found. I could tell that it was shorted somewhere, but I kept thinking that it must be a bad capacitor or a shorted crowbar, and I'm embarrassed to say that it took me more than an hour to figure out that it was the frame on the choke. I carved up a rubber grommet with an X-acto to make some spacers and now it's as good as new. Bob
Schematic for DEC H7441 (not the H744!)
Is there a schematic for the H7441 regulator anywhere? There are several out there for the H744 but, although they are plug compatible, the H7441 is totally different. The H744 uses an LM723, but in the 7441 DEC appears to have rolled their own regulator using a bunch discrete parts and opamps. Bob
DS20E power supply question
I have a DS20E Alpha machine. It's pretty fully configured, with two 666 MHz CPUs, 4GB RAM and 4x10K SCSI drives. In other words, it's a real power hog. It has three power supply modules installed, and if I understand the configuration rules then at least two should be required to run the machine and the third is a hot spare. But, when do SHOW POWER at the SRM prompt, I get P00>show power Status Power Supply 0 * BAD * Power Supply 1 not present Power Supply 2 not present System Fan 0good System Fan 1 * BAD * CPU Fansgood Temperature good What? If I believe that then I have no functioning power supplies installed?!? At this point I should mention that the machine boots VMS and runs just fine. Obviously something is not telling me the truth. Does anybody know what would cause this? BTW, what do the red LEDs on the front of the power supply modules mean? Is LED ON a good thing (i.e. power OK) or a bad thing (i.e. fault)? FWIW, none of the LEDs on my three power supplies is on. Oh, and it's right about System fan #1 - one of the fans is not running. I don't know if it's seized up, or if it's related to the power supply issue. Thanks, Bob
RE: ACM library opened
>Paul Koning wrote: >... >ACM has currently opened up all of its digital archives during these pandemic times This is great - thanks for passing along the information! Now, if the IEEE would just do the same thing... Bob
RE: H7874 power supply
> Jon Elson wrote: >The VAX 11/780 absolutely had power fail, and it DID work. So did the 11/730 and I imagine the 750 as well. No core, but there was a battery backup option to keep main memory alive and refreshed even in the event of power failure. >I did this quite often while swapping I/O devices and such >after device drivers became loadable. It was (is!) quite handy on the 730 as well. If your configuration has a separate BA11-K for the UNIBUS peripherals, then you can power down that box without turning off the CPU. It took 20-25 minutes to boot up the 730 from a dead start, so this was a great time saver. Bob
RE: H7874 power supply
>Looks like for this enclosure an ATX supply could well work. > For my VAX my notes say it didn't. A VAX would certainly be harder. You'd have to kludge up the ACOK and DCOK signals for one thing, which I don't think the R400x uses. It'd be really handy to find even a schematic for the backplane so we could see which signals are actually connected, but I did some searching and came up with nothing. Oh, and I did try to power up the H7874 on the bench for testing, but it wouldn't turn on there either. It probably has a minimum load requirement, or it needs some signal from the backplane to turn on. FWIW, the R400x does not have a power switch - the only way to turn it on or off is thru the H7874, either by the circuit breaker or the power control bus. The R400x also has several large power resistors on the M7493 SCSI connector module; those may be there to provide a minimum load for the power supply. Bob
RE: H7874 power supply
Remembering that I have the R400x enclosure and I'm only interested in powering disk drives - I looked up the specs for the RF7x drives, and they all use about 1.5A at 5V and 2.5-3A operating at 12V. There's a 5-6A spinup surge on the 12V supply, but as long as you spin them up in sequence you can probably gloss over that. Anyway, I have 4xRF7x drives and two SCSI drives, so figure maybe 20A at 12V and 10A at 5V. That's entirely doable with an ATX supply. The fans, annoyingly, are 24VDC so those would either have to be replaced with 12V fans or I'd have to kludge up an extra 24V supply. My next step was to figure out the pinout of the connectors on the back of the H7874. The big, high current, pins aren't marked anywhere inside the H7874 that I could find but, conveniently, they ARE marked on the R400x backplane. There are also a couple of high density connectors sandwiched in between the power pins; the lower one doesn't appear to be used but the upper one has a few connections. From looking at the backplane it appears that only four pins in the upper connector are actually connected. That's a guess though, because I can't see that back side of the backplane. I needed to see more of the backplane to figure out where these four connections went, so I removed all the drives from the R400x. Then, on a whim, I stuck the H7874 back in there and tried to power it up. It works! It appears that I don't have a bad power supply after all; I have a bad drive somewhere. Don't I feel silly :) So I don't need to fool with the ATX supply after all, or at least not until my PS really does die. Thanks for the help, and sorry for the false alarm. Bob -Original Message- From: Rob Jarratt [mailto:robert.jarr...@ntlworld.com] Sent: Sunday, March 29, 2020 2:05 PM To: b...@jfcl.com; 'General Discussion: On-Topic Posts'; 'Maciej W. Rozycki' Cc: r...@jarratt.me.uk Subject: RE: H7874 power supply I have some notes I made about trying a PC PSU, I don't think it really worked, there are signals to indicate power OK and perhaps others. But perhaps a more concerted effort might yield something that could work. Regards Rob > -Original Message- > From: cctech On Behalf Of Robert > Armstrong via cctech > Sent: 29 March 2020 19:15 > To: 'Maciej W. Rozycki' ; 'General Discussion: On- > Topic Posts' > Cc: r...@jarratt.me.uk > Subject: RE: H7874 power supply > > >Maciej W. Rozycki wrote: > >numerous Chemi-Con SXF parts scattered across all boards, some leaking > > Yeah, mine is full of "Nippon Chemi-Con" electrolytic too. > > What about just gutting the PS chassis and sticking in an ATX power supply? > I > don't know how the maximum current per output breaks down, but as I > understand it the H7874 is only a 600W supply. That's not a problem for an > ATX supply, and it would have all the required output voltages. You'd have to > run the cabinet fans at a fixed speed and you'd lose the power control bus > feature, but that's not a show stopper. > > Actually my unit is in an R400x chassis full of RF drives, so I believe I > only need > +12 and +5. I don't think the 3.3v and -12 are used in that case. I wonder > how > much current I really need for the drives? I should look that up and I might > be > able to find a surplus dual output supply that would do the job. > > Thanks again, > Bob
RE: H7874 power supply
>Maciej W. Rozycki wrote: >numerous Chemi-Con SXF parts scattered across >all boards, some leaking Yeah, mine is full of "Nippon Chemi-Con" electrolytic too. What about just gutting the PS chassis and sticking in an ATX power supply? I don't know how the maximum current per output breaks down, but as I understand it the H7874 is only a 600W supply. That's not a problem for an ATX supply, and it would have all the required output voltages. You'd have to run the cabinet fans at a fixed speed and you'd lose the power control bus feature, but that's not a show stopper. Actually my unit is in an R400x chassis full of RF drives, so I believe I only need +12 and +5. I don't think the 3.3v and -12 are used in that case. I wonder how much current I really need for the drives? I should look that up and I might be able to find a surplus dual output supply that would do the job. Thanks again, Bob
RE: H7874 power supply
> Rob Jarratt >robert.jarr...@ntlworld.com> wrote: > I reverse engineered the schematic of the 12V output board. I >don't know if that would be of any use? How correct it is I don't know. Sure, if you don't mind sharing. Everything helps. Looks like there are five separate PCBs in there. There's one long, skinny one that's obviously the AC input and rectifier board, which probably produces something like 300VDC for the regulator boards. There are two similar but not identical boards with huge heat sinks that are obviously the output regulators. I think this PS has +5, +3.3, +12 and -12 volt outputs, but I've no idea which board does which. And then there's a giant PCB, almost 11" square, covered with opamps, 74LS logic and discrete parts. There are filter caps, a transformer, and switching transistors on this board too so it obviously produces yet another power output for something. Oh, and I think this cabinet has variable speed fans, right? SO there's probably a fan speed controller on here as well. You'd think that will all this logic it could at least have some LEDs or something to tell me which output has failed, but it doesn't seem like it. Thanks Bob
H7874 power supply
Does anybody have a maintenance print or service manual for the DEC H7874? This is the power supply used in the BA4xx and R400x cabinets. As you might guess, I have one that tries to power up but shuts down after a second. Probably a bad capacitor (or several), but this thing is ridiculously complicated and not all that easy to disassemble, either. I'd like to be able to trouble shoot it rather than just firing the proverbial parts cannon at it. FWIW, none of the electrolytic (of which there are many) have obviously failed - no leaking, no bulges, etc. Of course, that proves fairly little. Thanks, Bob Armstrong
RE: Simulators for NCR Century series computers
On 7/17/19 6:12 PM, Al Kossow via cctalk wrote: > I'm not even aware of any surviving Century software That was to be my next question. I'd write my own simulator if I had something to run on it. A Century 50 and a DECSYSTEM-10 are tied for the first computer I ever got to use, sometime back in the mid-70s. I still have happy memories of programming in Neat/3 and punching up decks of cards for the NCR. Bob
Simulators for NCR Century series computers
Is anyone aware of a simulator for the NCR Century series computers? And no, simh doesn't do them. Thanks, Bob Armstrong
RE: DecNet / Linux
On 7/3/19 6:39 AM, John Many Jars via cctalk wrote: > Say, can anyone tell me which version of the kernel was the last one to > work with Decnet? Version 4.4.x kernels (Ubuntu 16.04.x) and maybe later can be made to work with some tweaking. See http://rullf2.xs4all.nl/decnet/ Bob
RE: RC25 (was Re: Modifying microcode)
>Eric Smith wrote: >There's SDI protocol documentation? You know, after I wrote that I realized that I was wrong about SDI. I've seen some electrical specs, but not the protocol. Bob
RE: RC25 (was Re: Modifying microcode)
I too have heard that RC25s and PDP-11s were used in nuclear subs for some
kind of sonar thingie. I've no idea how that worked, except that maybe DEC
gave all the good drives to the Navy and the rest of us got the crappy ones.
They worked as long as you didn't spin them down or try to change the
removable pack. The removable part would crash at the drop of a hat and, of
course given the clever shared spindle design, if the removable part wouldn't
spin up then neither would the fixed part.
I have (I think) three drives, or maybe just two. Two are internal drives
for the 725 and one is in the table top enclosure. None work. If anybody has
any tips for fixing them, or even just a kludge to spin up the Winchester part
without needing the removable part to work too, I'm all ears.
> Ethan Dicks wrote:
>I often wonder how hard it would be to develop some other storage
>device for the KELSI
AFAIK the LESI ("Low End Storage Interconnect") protocol is not documented
anywhere, unlike SDI or MASSBUS which are. If it is, I've never found it. I
have several UNIBUS KLESI boards and I've often thought the same thing, but I'm
not really interested in trying to reverse engineer the protocol w/o
documentation.
Bob
RE: Modifying microcode
> Ethan Dicks wrote: >We used to purchase 11/725s for parts to keep our 11/730 running. I remember when the 725 first came out. I was working for DEC at the time, and up until then the only VAXes I'd ever seen were 780s. Somebody rolled this little end table sized thing into the lab and said "Here - this is a VAX." I was flabbergasted - a VAX?!? In a box that small??? No way!! I kept it by my desk until the MicroVAX-II came out. By then I was getting pretty tired of it. Still, the 725 and 730 are the smallest UNIBUS VAXes ever made, which ought to earn them some kind of recognition. FWIW, I have a 725 complete and working. Well, except for the RC25, which never worked even when they were new. It needs the skins for the chassis, though - the previous owner used it as a test system. He never put the cover back on it and eventually lost that part. If anybody has a 725 chassis and would be willing to part with some of the sheet metal, let me know! Bob
RE: Modifying microcode
On 02/06/18 15:17, allison via cctech wrote: > > It was my understanding from using the 730 that there was limited > (really limited) microcode > enough to load the WCS as the tu58 was a serial device (standard tu58) > and the 730 had to > unpack and stuff the WCS.� You need little to do that but far from even > PDP11 instruction set. > The Microcode was loaded was the "what made it a VAX stuff". > > Allison What you're describing is the 750, not the 730. Unlike the 78x and 730/725, the 750 had no console front end processor. The microcode did it all, including loading any additional microcode from TU58. As others have said, the 730 had an 8085 CFE processor that loaded all the VAX microcode. The main CPU had no ROMs and could do absolutely nothing until the CFE loaded the microcode. FWIW, the CFE in the 730 had a 2K ROM and (I think) about 8K of RAM. The first thing the CFE did after power on, before it did anything with the VAX CPU, was to load the rest of the 8085 code from the TU58 into that CFE RAM. The 2K of ROM had just enough code to type characters on the console and to talk to the TU58, and even the CFE couldn't really do much until the rest of its code was loaded from the TU58. Once that was done, the CFE command line interpreter executed a script (one of four possible ones, depending on the HW configuration) and that script had the CFE commands to load the VAX microcode. FWIW, when you first turn on the 730 it types "CONV11" on the console, followed by the rest of the startup dialog. If you pay attention, there's a tiny pause between the "CON" and the "V11". That's because the first part was typed by the 8085 ROM just to let you know that the CFE was alive, and the version number was actually typed by the RAM part of the CFE code after it was loaded from the tape. Bob
RE: Modifying microcode
> Tony Duell wrote: >Incidentally, did DEC ever release any details (flowcharts, source listings, >etc) of the 11/730 microcode? And what about the control PROMs for the >memory system. The technical manual implies there was a listing of those, >but I've never found it. I thought that DEC had a whole microcode development suite for the 730 to support customer written extensions to the microcode, but I've never seen it nor any documentation for it. If such a thing did exist then I seriously doubt anybody ever bought it. The 730 was never a super popular machine to start with, and the market for a customized version would have been very small. I've heard a persistent rumor over the years that the WPS/8 and PDP-8 software group at DEC had modified the 730's microcode to support a PDP-8 emulation of some kind, and that they used that internally for development 'cause it was faster than a real -8. I've not idea if that's true, but it would be cool if they did. And no, I'm not talking about PDP-11 compatibility mode - even the stock 730 had that (all the 7xx VAXes did, I believe). Certainly if you had the right tools and the right knowledge, it would have been easy to modify and replace the 730's microcode with something of your own. Just copy the binary images to the console tape and reboot. Bob
Fairchild 9440/445 MicroFlame?
I'm looking for manual scans, software, really any documentation of any kind for the Fairchild F9440 or 9445 (aka the MicroFlame) microprocessors. Yes, bitsavers and a few other places have datasheets for the chips, but that's really about all the documentation I've found. And yes, I know that they're Nova clones and can run DG software, but Fairchild had their own development tools too that seem to have disappeared completely. In particular, Fairchild had a single board computer for the 9445 called (I think) the PEP-45. It had a built in EPROM monitor called PEPBUG-45. I'd love to find manuals and schematics for that gizmo. Actually I'd be interested in documentation for any systems that used either of the 944x chips. Bob
RE: Modifying microcode
>Eric Smith wrote: >The control stores of the 11/785, 8600, and 8650 were entirely WCS. > >All other VAXen had (relatively) large ROM control store and tiny WCS or >patch store. You forgot the 11/730 and 725. The KA730 used 2901 bit slicers and the control store was entirely in RAM. After power on it was a paperweight until the 8085 CFE loaded the microcode. Bob
Manual for Data Media Elite 2500 terminal?
Can anyone point me to a technical manual for the DataMedia Elite 2500A terminal? I'm especially interested in documentation on the escape sequences and the special character sets. This was a fairly high end smart terminal from the late 70s or early 80s. Bitsavers has a short manual for the 1500 which I'm guessing to be similar, but the 2500 has some extra features (e.g. insert line/character, delete line/character, etc) that aren't present there. Thanks, Bob Armstrong
RE: CXY08 and DELQA compatible with 2.11bsd?
> Josh Dersch dersc...@gmail.com wrote: >Correction: it's the "qt" driver for the DELQA. FWIW, looks like the CXY08 in DHV mode works find with 2.11bsd. The qt driver, however only works if you have the very late model DELQA that has "turbo" mode. I think that was called the DETQA, but I'm not sure about that. If you have an earlier DELQA then the qt driver simply says "qt0: !Turbo" and quits. Gotta love those terse Un*x error messages! The older non-turbo DELQAs and the DESQA (M3127, which is what I have) only seem to work with the qe driver. It correctly recognizes and identifies them as a DELQA. I believe the DESQA was identical to the DELQA but with S-box handles and a built in thinwire transceiver. Bob
CXY08 and DELQA compatible with 2.11bsd?
Does anyone know offhand if the CXY08 (M3119) and DELQA (M7516) work with 2.11bsd? I think the CXY08 has the same programmer interface as the DHV11, and I'm hoping it works with the 2.11bsd dh driver. Ditto for the DELQA and the qe driver. If somebody knows for sure, though, I'd appreciate it if you can save me the trouble of installing it all just to find out it doesn't work. Thanks, Bob
RE: XT/370 microcode
>You might look up Nick Tredennick's book "Microprocessor Logic Design: >The Flowchart Method" which is sold at Amazon for an obscene price FWIW, there are several copies on Abe Books ranging in price from "only" $800 (a steal!) to almost $1200. I'd love to read it, but that's ludicrous. Is this book bound in solid gold or something??? Bob
