On Tue, 26 Apr 2016, William Donzelli wrote: Well - "are out there" I agree, but do you know of any PRIVATELY owned and ALIVE machines? There is lot of PDP* discussion here, but it is very hard to get in touch with people being working on Rolm stuff. Of course: In contrast to a non-working PDP8 (which still looks beautiful) a defunc Rolm processor is just a very heavy brick of metal. So any one out there also preserving Rolm computer hardware in working condition? ...and some airborne and land based MIL applications I am pretty sure... Did you also have some later Rolm machines (like MSE14?) or any interesting software (apart from the diagnostics)? Have you heared of the Micro Code development system for the 1602 (no -A or -B)? I have got one of these, reverse engineered it partly and rebuilt the missing panel... http://www.baigar.de/TornadoComputerUnit/EB-HDDsim-on-1602-w-Microcoder.jpg ...but it is still not working and of course I am missing the Micro Code assembler... Have a good time, Erik.

On Wed, 27 Apr 2016, Bob Rosenbloom wrote: I don't have any ROLM computers (not that I wouldn't love one) but I am proud to say that I have a complete ROLM SCBX 8000. I've tried to take some pictures and compile some information on my personal site: http://wildflower.diablonet.net/~scaron/rolmfieldguide/index.html I just need to figure out how to get the rack out of my basement and into my garage! I do have diskettes for the system ... hopefully they're still good ... someday I hope to have it up and running. Best, Sean P.S. Thanks, again, Bob for helping those two microVAX machines get to Michigan! So nice to have my Q-bus itch scratched again ;)

On Thu, 28 Apr 2016, Erik Baigar wrote: You're welcome! Mine is actually a relatively small example. It has 84 PCBs in total across six shelves and two conjoined racks with a little disk and control panel between them. If you've seen a picture of a lowboy PDP 11/60 ... I always use that as something to relate the general dimensions. The ROLM is maybe a little taller. I need to post some pictures of the complete system and rack. I would love to get the ROLM running someday and get it hooked up to a VoIP network... Another hobby of mine is collecting PBX systems and telephones and I've already done this for a Definity as well as a Nortel M1 and I have no doubt that the same could be done for the CBX [1]. The CBX (eventually) supported DS1 interfaces ... which would IMO be the coolest way to connect the CBX to a media gateway ... but one day once I get the PBX running, I should be able to get it routing calls again with something like a Cisco box acting as an external media gateway ... while designing a media gateway to sit on the ROLMbus would be a heck of a project ;) I find the design of the CBX really interesting. IMO, their appearance belies that ROLM was a computer vendor first a a phone equipment maker second. Not in a perjorative sense, just stylistically. Comparing them against boards from WECo/ATT/Lucent/Avaya, Nortel and Harris. Best, Sean [1] http://www.ckts.info

On Thu, 28 Apr 2016, Christian Kennedy wrote: Very cool, thanks for the perspective. My understanding was that the profits on the mil-spec computers side bankrolled the entry into the PBX market but I was never clear on how much overlap there was between the two divisions. Any awareness if the common control of the CBX is in any way architecturally related to the DG Nova? It seems like it would be advantageous to leverage the experience building mil-spec Nova processors on the other side of the business, and looking at the hardware, it is clear the CBX is a 16-bit machine. But never been able to confirm. One thing that would be a huge score for postierity and might help to answer some of these questions is a copy of the first half of the System Service Manual for the CBX. I have Part II which contains a command reference and some discussion of peripheral cards, but everything relating to system architecture and the design of the common control seems to be in Part I. Do you know of anyone who may have preserved this? I've spoken with a few old hands who were CBX switchmen in the past but all I've been able to get is Part II. I had watched a Youtube video which discussed a little bit about the design: https://www.youtube.com/watch?v=A8J6CGI6HA0 However what you write is much more detailed. I believe there is an apocryphal story behind that particular part and sampling rate although the specifics elude me at the moment ... I understand it caused trouble trying to interface the CBX to DS1 circuits. Sometimes my Definity gets confused and does that. Surprises the heck out of my partner and me. Good thing it hasn't happened in the middle of the night :O Thanks, Sean

On Thu, 28 Apr 2016, Christian Kennedy wrote: [Another snip] OK, so you are an insider to the Rolm MSC (=Mil-Spec-Computers?) division and in "your" years there, the design of the MSE series and probably beginning Hawk must have been accomplished? OK, this makes sense to me as you in MSC certainly knew how to design sequencers and things like the connection tables from designing the processors and the MMUs. A very nice example from my point of view is the 3761 card for the Rolms Computers, which is a MIL1553 bus interface: This one essentially is a dedicated sequencer capable of autonomously routing data (and doing simple processing of it on the fly) by a command queue which resides in the hosts memory and is accessed in the background via DMA cycles. This obviously delivers outstanding realtime performance which is not only important in controlling aircraft but the same know how may have inspired the CBX. As mentioned in another posting, there is a nice video from the old days giving a description on the CBX's internals: https://www.youtube.com/watch?v=A8J6CGI6HA0 Very funny - but those days a reboot of the whole system takes just a fraction of a second - nowadays restarting a complex telephone system containing several servers may take several minutes which is even a bigger nuisance than the lost connection... Thanks again and have a nice weekend, Erik.

Many thanks Chris for all the interesting recollections! On Fri, 29 Apr 2016, Christian Kennedy wrote: That sounds very interesting - although I do not know much about the Hawk/32 it sounds to be a very interesting machine. I do not know of anyone having one of these running, but I think some of them should be still in service. And by accident I have got a tool to load microcode onto the the Hawk/32 series: This tool is part of the test facility (I have been told, that it was called "Rolm Mother" in the factory) I got hands on and which is claimed having been used in the original factory. But software prior to ARTS was just copies of the DG stuff as far as I can tell from the paper tapes I have got (mainly diagnostics). Yeah for the later machines this may be true: E.g. the BITE of the MSE14 is claimed to detect almost all problems in the CPU and I have got seen a test report which shows that some poor moron randomly soldered bridges onto the PCB board or cut wires and recorded whether the fault was detected. The result was, that more than 89 percent have been reported correctly -> This is very remarkable in my opinion. Does anyone know how this result relates to testing of modern CPUs? Hmm, in the list of peripherals for the Rolm IO bus I see a "nucelar event detector" which probably forces the processor into some routine verifying its correct operation after the "local sun" event. Apart from this the earlier Rolms (1602) had indeed bugs which (according to some ECN (=engineering change notes) could lead to freezing and/or branching to wrong memory addresses). One of my 1602s is a very strange one as it contains a memory and IO protection facility realizing some form of protection to prevent critical code from getting crazy. This option consists of a special microcode realizing some form of kernel and user mode and an additional PCB in the CPU to detect access violations in core and IO - the whole thing was called APM (Access Protection Module or Mode or whatever (?)). This option is not listed in the standard IO options and to my knowledge is a very early form (dated before 1974) of such a feature ;-) What form of machine-machine communication was used in this case? Was this realized using the DG data channel transfers (MCA, would be very slow for a Hawk/32 I guess) or was it implemented in some newer hardware not depending on the DG IO bus? TEAC? The company we know from Audio devices and stuff like this? (Sorry for asking stupid questions!). It was extremely smart I must admit! I recently had two boards communication using the BCUED diagnostics and it was awesome how they sent messages, switched operation mode and changed roles (master, terminal,...). Yes that is indeed a very common sequence of commands ;-) ;-) That really is a design flaw. Together with two colleagues I built a harddisk simulator for the Rolms and lucky as we are today we used a FPGA to realize the interfacing - so we could repair our bugs easily by modifying the firmware. There is an other similar problem with the boot code as implemented in all 160x machines: Using the EPROM card and trying to boot from it via the usual JMP .-1 located at 377 and a channel boot fails as the boot code being executed in ROM places the JMP at address 377, does the start command and than branches to 377. But the EPROM PCB is so fast, that before the CPU "arrives" at 377 the JMP .-1 is already replaced and the code fails. So one has to toggle the start command and the JMP in manually at 376 and 377 and launch it there... Very good choice of acronyms - fortunately the IT world has lot of terms which can be arranged in many ways.... Thanks again, Erik.

Hi Chris, sorry, but there emerged more questions from my side ;-) On Fri, 29 Apr 2016, Christian Kennedy wrote: I only know ARTS from ads being sold on eBay - this is some form od Ada development environment (or a complete OS?)? The acronym probably means something like "Ada Real Time System" (?). Was this a cross compiler tool or did it run natively on the hardware? As there is a /32 variant, do you think a variant for the 16 bit machines like 16xx or MSE14 did survive some- where? Although I do not recognize the "PTE format", I guess the Eagle project is related to a widely sold US made aircraft, right? This one carried at least one Hawk/32 ;-) Some of the Rolm stuff I have got is from the company which serviced the equipment of the ATTAS aircraft... http://www.dlr.de/dlr/desktopdefault.aspx/tabid-10644#gallery/1751 http://www.dlr.de/dlr/Portaldata/1/Resources/documents/ATTAS_Handout_2001.p… ...and this also had Hawk/32 on board with the whole lot of Rolms interconnected by a fiber based MCA bus to exchange data. So this seemt having been common hardware those days ;-) I guess you have not been happy with context switching and how the Rolm microcode implemented it. Unfortunately, there is nothing on the internet related to the instruction set of the Hawk/32 family but the hardware contained lot of big custom chips and therefor I guess it was far more powerful and complex than e.g. the Eclipse or earlier machines. Best regards, Erik.

Hi Chris, thanks for the additional explanations. OK, that is helpful information - Stephen Merrony in the UK is taking care of the MV series hardware/software/documentation and he has some manuals on his page which enlightened me regarding MV/Hawk32 instructions and usage: http://www.stephenmerrony.co.uk/dg/doku.php What I have got is even smaller - called MSE14/Micro, it is 1/4 ATR with a CPU on only two cards thightly packed together back-to-back to ensure short connections and each full with discrete chips (AMD ALU, sequencer, 32kW RAM and memory map; photographs show both sides of the heavy CPU sandwich) - http://www.baigar.de/TornadoComputerUnit/MSE14-CPU-Arithmetics-Memory.jpg http://www.baigar.de/TornadoComputerUnit/MSE14-CPU-Microcode-Integer.jpg it even has got a hardware multiplier doing 16*16->32 in one processor cycle - so quite fast for those days. With the >20MHz, these are running at, I can imagine that the "full size" MSE14 may have had timing problems with the CPU distributed to several cards (and many plugs for the signals have to pass). Indeed - ;-) Hmm, I am not sure if this is a positive development. Special care has to be taken to make the software robust and independent of access to the internet. One does not want to run into trouble with viruses etc. in such a context ;-) Very funny - and understandable. Even in case of the MSE14 this BITE implemtend in microcode takes several seconds and it is easy to understand that it must have required a looooong time in the 1990ties if simulated. Hmm - here I am not sure. I just discovered, that I am proud owner of PCBs called "Event Detect" with part number 7100A - so they really existed, at least if mine are the right ones; They are IO boards and therefore I doubt they short the power supply. At some time in the future I will have a closer look to see what is on them. [snip] ;-) I think it is worth starting a separate thread here on the question which early systems had a facility for memory and IO protection facility. I still think, that 1975 is quite early for a Minicomputer architecture. interesting business life so far - congratulations! Many thanks again and best regards, Erik. On Sun, 1 May 2016, Christian Kennedy wrote: > > > On 5/1/16 04:10, Erik Baigar wrote: > >> sorry, but there emerged more questions from my side ;-) > > It's a trip down memory lane ;) > >> >> On Fri, 29 Apr 2016, Christian Kennedy wrote: >> >>> Hawk, but not the odd S/140 and MV/8000 punches) and software (ARTS, >>> ARTS/32) were ROLM designs. >> >> I only know ARTS from ads being sold on eBay - this is some >> form od Ada development environment (or a complete OS?)? The >> acronym probably means something like "Ada Real Time System" (?). > > Advanced Real Time System. Memory resident with hard latency limits for > servicing interrupts; it had nothing to do with the Ada compiler. > >> >> Was this a cross compiler tool or did it run natively on the >> hardware? As there is a /32 variant, do you think a variant >> for the 16 bit machines like 16xx or MSE14 did survive some- >> where? > > ARTS/32 was for Eagle architecture machines and actually made use of the > rings :P. Prior to the Hawk there was a punch (basically a > militarization of DG's prints) of the MV/8000 of which something like > three were sold; it was about the size of a large modern refrigerator > and was sufficiently massive that it had large lifting rings on the top > of the cabinet; while sometime someone would fire up the one that lurked > > I have no idea if any of the software survived anywhere :( > > It's funny that you mention the MSE14; it was the other punch done by > ROLM, basically a S140 stuffed into a 1/2 ATR chassis. IIRC it had a > somewhat painful gestation, because mapping the 15x15" S/140 processor > onto multiple smaller cards created interesting timing problems. > > The ADA compiler was developed in partnership with Rational; as part of > that deal ROLM was supposed to look at creating a militarized version of > the R1000. The R1000 was freaking huge -- much taller than a MV/8000, > to the point that getting it into the machine room was a bit of a > challenge -- and it turned out it was markedly slower executing Ada code > than a MV/8000 running code produced by the ROLM compiler, so in the end > that project went more or less nowhere. > > >> >>> Steve Wallach had incorporated into the PTE format for the Eagle in >>> order to turn memory references into I/O requests that would be >>> transparently resolved in the physical memory of another machine. >> >> Although I do not recognize the "PTE format", I guess the Eagle >> project is related to a widely sold US made aircraft, right? This >> one carried at least one Hawk/32 ;-) > > PTE ::= Page Table Entry. > > >> >> Some of the Rolm stuff I have got is from the company which serviced >> the equipment of the ATTAS aircraft... >> >> http://www.dlr.de/dlr/desktopdefault.aspx/tabid-10644#gallery/1751 >> >> http://www.dlr.de/dlr/Portaldata/1/Resources/documents/ATTAS_Handout_2001.p… > > Huh. Interesting :) > >>> deal from each other ("Yes, I know that the PATU instruction only occurs >>> twice in the body of AOS/VS, but it's executed on every context switch >>> and as such it's probably not a really good idea to implement it by >>> having the microcode scrub each entry in the TLB"). >> >> I guess you have not been happy with context switching and how >> the Rolm microcode implemented it. > > IIRC we caught the problem early enough that they were able to come up > with a hardware invalidation that did materially what the MV's did and > thus we didn't end up paying a terrible performance penalty on context > switching. > > >> Unfortunately, there is nothing >> on the internet related to the instruction set of the Hawk/32 >> family but the hardware contained lot of big custom chips and >> therefor I guess it was far more powerful and complex than >> e.g. the Eclipse or earlier machines. > > It's instruction set is identical to the MV/8000, but there's some > differences in how it treats "undefined" results and "undefined" > bitfields in a handful of instructions, enough to require tweaking the > diagnostics. > > > -- > Christian Kennedy, Ph.D. > chris at mainecoon.com AF6AP | DB00000692 | PG00029419 > http://www.mainecoon.com PGP KeyID 108DAB97 > PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97 > "Mr. McKittrick, after careful consideration?" >

Nice! Marc I have my Rolm 1603 working. No peripherals hooked to it, but you can toggle in stuff from the front panel. http://dvq.com/oldcomp/photos2/1k/rolm1603_f.jpg Bob

Sorry I mean "RuggedNova"

On Wed, 27 Apr 2016, Bob Rosenbloom wrote: Very cool, Bob - we have been in touch seom years ago and great, that your machine is still alive! Many thanks for the picture and two questions out of curiosity: (1) The panel is mounted on the rear side (where memory is) of the processor. Is it wired and powered internally or do you have to connect the panel to the plugs of the processor externally? (2) The 1603 uses the same 5605 processor "sandwich" also used by the 1602B and not the 9PCBs of the earlier 1602s? Keep up taking care of your Rolm, its a very nice and rare machine... Erik.

Hi Bob, many thanks for your email and for sharing the photos. Obviously the 1603 has a different processor card set (5604 as can be seen that the chronology was 1602 (9 PCB processor), 1603 (5604, 4 PCB procrssor), 1602B (5605, 2-PCB sandwich processor). Yours seems to have TTY in slot 13 and there are 5 IO slots (15- 11) as on the original 1602 (1602B has got more due to the re- duced number of PCBs in the CPU). The CPI controlling the panel in your case is at the very end opposite to the power supply and inbetween you have got two core stacks - in total 32kW I think. A 1602B can hold 64kW of memory (only accessible via a banking function proprietary to Rolm, so not usable e.g. for RDOS). Have you ever powered on your 1666 with the 1648 panel? Although the 1666 was quite popular in the US I think the non US customers preferred the MSE14 due to better compatibility with the DG Eclipse series... Very interesting and again many thanks for sharing! Erik. On Sun, 1 May 2016, Bob Rosenbloom wrote:

1666s are known as AN/UYK-64. Nitpick: the Rolm 1600s are not really avionics machines, although certainly quite a lot were put in aircraft. The military put them on land and ship installations, thus the "U". If they were primarily for aircraft installations, they would have been "AN/A**" and not "AN/U**" (and also not so freaking heavy!). -- Will

On Tue, 3 May 2016, Christian Kennedy wrote: [ snip ] Yes, these are extremely heavy - the 1602 with the additional 24kW memory extension can only be transported over larger distances using a barrow. It is not that big, but has a density close to water ;-) It is incredible to see, that there have been over 20 of the Rolm processors and chassis in the aforementioned ATTAS aircraft. And during some trials a F-16 had to carry three additinoal Hawk/32s ;-) https://en.wikipedia.org/wiki/General_Dynamics_F-16_VISTA TEMPEST? Not the play from Shakespeare I guess (sorry for stupid questions)... Good night, Erik.

Google JETDS. It will tell all. -- Will On May 3, 2016 4:35 PM, "Erik Baigar" <erik at baigar.de> wrote:

But then where does that leave RFC 1149 compliant networks? paul

Thanks - that is the perfect link. There is some information on the AN/AYK-14, an airborne computer, on the web...