Re: IBM 360 Model 50 information?
Which brings us to the real problem: we don’t have 360 Model 50 ALDs. Anyone has them? Marc From: cctalk on behalf of "cctalk@classiccmp.org" Reply-To: Jon Elson , "cctalk@classiccmp.org" Date: Friday, March 29, 2019 at 8:45 AM To: Ken Shirriff , , "cctalk@classiccmp.org" Subject: Re: IBM 360 Model 50 information? On 03/28/2019 11:46 AM, Ken Shirriff via cctalk wrote: I'm writing a S/360 Model 50 emulator that runs at the microcode level, in order to drive a Model 50 front panel accurately. I'm about 80% of the way there, but there are some microcode operations that I haven't figured out. So I figured I'd ask if anyone has obscure Model 50 manuals that aren't on bitsavers, or perhaps even the ALDs. I was surprised at how extremely different the microcode is from the 360 instruction set. If you had a 360 instruction set, why would you implement a 360 by an emulator? It would be most common that a microcode emulator would be a quite different scheme, kind of implementing an RTL (Register Transfer Logic) in a "language". I've figured out a bunch of the strange micro-instructions, such as S47ΩE, which ORs the emit field into flags 4 through 7. But there are many micro-instructions that still puzzle me, like F→FPSL4 which maybe a floating point shift left 4 and 1→BS*MB which does something with byte stats. So if anyone happens to have a Model 50 microcode programming manual sitting around, please let me know :-) Wow, what a project! I think the only way to understand the microcode is to follow the signals through the ALD schematics. A microcode programming manual would be of no use to anyone, as the microcode bit pattern was stored in the serpentine word-line traces of the control store boards. 360/50 and 360/65 used CCROS (capacitor-capacitor read only storage) where there were two word lines on one board, one driven and one grounded through a resistor, called drive lines and balance lines, respectively. If there was a wide pad on the drive line opposite the pad on the bit line, that generated a 1 in the control store word, if the wide pad was on the balance line, you got a zero. A very thin Mylar sheet separated the two boards, and pressure was applied by a pressure plate and foam pad. So, a microcode change required a board master artwork to be changed and a new board etched. Not a practical field operation. The only custom microcode I heard of in these models was for the National Airspace System for the FAA traffic control computers. The variant of the 360/50 was called a 9020D display element, and the 360/65 variant was called the 9020E compute element. So, somebody used the required documents for that project. Oh, one other issue is the 360's had no FFs. All storage elements were transparent latches, and they generally used a 4-phase clock. All this is pretty well documented between the ALDs and the FEMM's for the particular model. Jon
Re: Byte Magazine
On 3/29/2019 3:37 PM, Nemo Nusquam via cctalk wrote: On 03/29/19 14:08, Liam Proven via cctalk wrote: On Fri, 29 Mar 2019 at 19:01, ben via cctalk wrote: I have been trying to read the Dr Dobbs PDF scans and a few other PDF's. They seem to work only with the NAME BRAND pdf reader. Of course I use the OTHER brand. Since you don't name names, I can't directly comment. We don't know what OS you're running. If you have a Mac, then you can get Adobe Reader for it. [...] For just reading, I find FOSS viewers fine. Indeed, I am really curious as to which PDFs cannot be read by Preview (Mac) or xpdf (X). Could the OP please provide a link? N. Jelly baby o/s . Ops too much Dr Who , Jelly bean for the android. I did install Adobe Reader, but it way too slow. I need to Install it for my pc, if I can find it among all the other stuff they want bundle you with. Ben.
Re: Byte Magazine
On 03/29/19 14:08, Liam Proven via cctalk wrote: On Fri, 29 Mar 2019 at 19:01, ben via cctalk wrote: I have been trying to read the Dr Dobbs PDF scans and a few other PDF's. They seem to work only with the NAME BRAND pdf reader. Of course I use the OTHER brand. Since you don't name names, I can't directly comment. We don't know what OS you're running. If you have a Mac, then you can get Adobe Reader for it. [...] For just reading, I find FOSS viewers fine. Indeed, I am really curious as to which PDFs cannot be read by Preview (Mac) or xpdf (X). Could the OP please provide a link? N.
Re: IBM 360 Model 50 information?
>From an emulation standpoint, latch or flop is not necessarily an issue. It is >that it is a state holding element. The only potential issue is if he was >doing clock cycle emulation. He'd need to understand what was originally >considered a clock cycle. Dwight From: cctalk on behalf of Paul Koning via cctalk Sent: Friday, March 29, 2019 9:51 AM To: Jon Elson; General Discussion: On-Topic and Off-Topic Posts Cc: Ken Shirriff Subject: Re: IBM 360 Model 50 information? > On Mar 29, 2019, at 11:18 AM, Jon Elson via cctalk > wrote: > > ... > Oh, one other issue is the 360's had no FFs. All storage elements were > transparent latches, and they generally used a 4-phase clock. The same is true for the CDC 6600. Not a big surprise; a transparent latch can be made of two cross-connected gates, while a flip-flop (edge triggered) requires more stuff (four gates?). And the 6600 uses at least four clock phases; in parts of the CPU there are additional clocks so some of the hairy parts are more like 6 or so phases. paul
Re: Byte Magazine
On 3/29/2019 12:18 PM, Hagstrom, Paul wrote: Perhaps an obvious thing to say, but I'm sure others who have encountered this would appreciate your efforts if you were to re-scan these things or convert existing scans from the format you are having difficulty with into a format that is less proprietary. I am using a PDF reader ( B&W ) that runs android 4.2. I need a DATABOOK for say a 74H00 I got it. Other books I am less lucky with. Right now I am looking modifying the Small C compiler from Dr Dobbs for the homebrew computer I have (living now on a DE1 FPGA card) . A nice 10/20 bit cpu but non standard to check the old back issues for finer details. There are definitely scans out there that would be better if they were made today or even made with more care. Some things could use re-scanning. Nevertheless, I appreciate the fairly significant amount of effort that went into scanning things originally, particularly when scanners were worse, computers were slower, and disk space was expensive. I am not angry at them for not doing a bunch more work than they actually already did. Well CD roms have been around a long time, so archiving data was never a problem. The real problem was all the libraries dumping the older books for the latest windows95 c++ or Microsoft application. They are not online. Google will find a lot books for 2018 but very few from 1975. I am looking for bare metal OS right now, I just finished the I/O for SD card and burned the eeproms on the DE1 card. The hardware has more than 32KB of memory but I would like see if I can get the small c compiler in 24KB of memory with a 8Kb OS. Ben.
Re: Byte Magazine
> On Mar 29, 2019, at 2:01 PM, ben via cctalk wrote: > > I have been trying to read the Dr Dobbs PDF scans and a few other PDF's. They > seem to work only with the NAME BRAND pdf reader. Of course I use the OTHER > brand. It would be nice if when scanning a file THEY used a generic output > rather than latest bells and whistles.Some PDF's seems > to raw bit mapped images that take forever to display. If you can't read > them what is use of archiving them. > Bitsavers works for everybody but they don't have books in general. > Ben. Perhaps an obvious thing to say, but I'm sure others who have encountered this would appreciate your efforts if you were to re-scan these things or convert existing scans from the format you are having difficulty with into a format that is less proprietary. There are definitely scans out there that would be better if they were made today or even made with more care. Some things could use re-scanning. Nevertheless, I appreciate the fairly significant amount of effort that went into scanning things originally, particularly when scanners were worse, computers were slower, and disk space was expensive. I am not angry at them for not doing a bunch more work than they actually already did.
Re: Byte Magazine
On Fri, 29 Mar 2019 at 19:01, ben via cctalk wrote: > I have been trying to read the Dr Dobbs PDF scans and a few other PDF's. > They seem to work only with the NAME BRAND pdf reader. Of course I use > the OTHER brand. Since you don't name names, I can't directly comment. We don't know what OS you're running. If you have a Mac, then you can get Adobe Reader for it. https://helpx.adobe.com/acrobat/kb/install-reader-dc-mac-os.html If you run Windows, well, I favour FOSS so I use Sumatra: https://www.sumatrapdfreader.org/free-pdf-reader.html Failing that, there's Foxit which is relatively light: https://www.foxitsoftware.com/pdf-reader/ On Linux, where I use XFCE, I favour Xreader as it has a traditional UI rather than the modern GNOME weirdness: https://github.com/linuxmint/xreader/ Original Adobe Acrobat Reader is still available and still works, though. I no longer use KDE but I hear Okular is good: https://okular.kde.org/ The reason I sometimes install the real Adobe thing on my Mac and my Linux machines is that it seems to cope with fancy stuff such as embedded 3D models, forms which must be filled in, stuff like that. For just reading, I find FOSS viewers fine. -- Liam Proven - Profile: https://about.me/liamproven Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: Byte Magazine
On 3/29/2019 4:57 AM, Will Cooke via cctalk wrote: In a previous thread I asked for a couple of specific pages from Byte magazine, which I got (thanks to all, especially Peter, for helping out!) But that brings up a bigger issue (no pun intended.) About a year ago I found the Byte scans on americanradiohistory.org and started reading from the start. I found that those scans were less than great, with many missing pages, pages out of order, pages scanned at resolutions too low to read, and a few other problems. I went searching the web for other scans and, with a few exceptions for individual issues, found that ALL the collections of scans seemed to be the same ones, with the same bad pages. I have been trying to read the Dr Dobbs PDF scans and a few other PDF's. They seem to work only with the NAME BRAND pdf reader. Of course I use the OTHER brand. It would be nice if when scanning a file THEY used a generic output rather than latest bells and whistles.Some PDF's seems to raw bit mapped images that take forever to display. If you can't read them what is use of archiving them. Bitsavers works for everybody but they don't have books in general. Ben.
Re: IBM 360 Model 50 information?
> On Mar 29, 2019, at 11:18 AM, Jon Elson via cctalk > wrote: > > ... > Oh, one other issue is the 360's had no FFs. All storage elements were > transparent latches, and they generally used a 4-phase clock. The same is true for the CDC 6600. Not a big surprise; a transparent latch can be made of two cross-connected gates, while a flip-flop (edge triggered) requires more stuff (four gates?). And the 6600 uses at least four clock phases; in parts of the CPU there are additional clocks so some of the hairy parts are more like 6 or so phases. paul
Re: Apollo Ethernet EPROM mystery
My DN3000 has a 3C505 that I got off of eBay in 2012. It does *not* have a boot ROM, just the firmware EEPROMS - National NMC27C64N. Works fine, if I recall correctly. I expect I would have tested it as soon as I got it, and I did an assign an IP address to it. Unfortunately, my "lab notes" are eluding me at present -- they may be offsite from a recent remodel. But I am almost positive I tested it. My Apollo manual on the adapter, 009741-00, "Unpacking and Installing the EtherController-AT" is offsite (5 miles, accessible if needs be). I just dumped the firmware: U15 and U16. From looking at the information online on the 3C505 at Bitsavers, those would be required even in an Apollo -- but only for the on-board processor - the Apollo itself would presumably not even be aware of them, so unless the MAME folks are trying to simulate the processor on the adapter, they would not need these ROMS. Still, let me know if you want me to post the firmware onto my Google drive. I also came across the following in my files, dated in 2012, which indicates, as another post here pointed out, that the Apollo Boot ROM is only needed for diskless boot. That rings true - the manual I cited above would confirm that, if needs be. === - Installing an Ethernet Controller in an Apollo DN4000 and Living to Tell About It April 20, 1992 Mark C. DiVecchio Silogic Systems 9888 Carroll Center Road Suite 113 San Diego, CA 92126 email ...!ucsd!celit!silogic!markd ma...@silogic.uucp Table of Contents 1.0 Environment. . . . . . . . 4 2.0 3C505. . 4 3.0 Run the Jumper Program . . 4 4.0 Test tcp/ip. . . . . . . . 6 5.0 Shut Down the Node . . . . 6 6.0 Installation of the Ethernet Card. . . . . . 6 7.0 Test the Ethernet Card . . 6 8.0 Boot the Node. . . . . . . 6 9.0 Edit These Files . . . . . 7 9.1 /etc/hosts . . . . 7 9.2 /etc/hosts.equiv . 7 9.3 /etc/networks. . . 8 9.4 /etc/rc. . . . . . 8 9.5 /etc/rc.local. . . 9 10.0 Check Files . . . . . . 10 10.1 /etc/inetd.config . . . . . . . . 10 11.0 Edit /etc/daemons . . . 11 12.0 Reboot the Node . . . . 11 13.0 Check It Out. . . . . . 11 14.0 Edit /etc/hosts files . 12 15.0 Test tcp/ip . . . . . . 13 16.0 tcpst Utility . . . . . 14 16.1 tcpst Options . 14 16.2 tcpst Listing . 14 17.0 Acknowledgements. . . . 17 1.0 Environment Our shop is running an Apollo Token Ring (ATR) with one DN4000, 2 DN3010 and 2 DN3000. The DN4000 and two of the DN3010 are running SR10.3. The remaining two DN3000 are running SR10.1. We also have an Ethernet connecting a Sun IPX, a PC running ESIX Unix 4.0.3 and three PC's running NCSA Telnet. We wanted to install a gateway so that every machine on the ATR could have access to every machine on the Ethernet. The ESIX Unix box has all our modems connected to it. We were already running tcp/ip over the ATR and Ethernet separately. There is no need to boot anything diskless over Ethernet. 2.0 3C505 Buy a 3Com 3C505 Ethernet card. This is just a generic off the shelf card. I will not have a diskless boot ROM on it. If you have need to boot diskless, you will have to buy the card from Apollo. 3.0 Run the Jumper Program Run /systest/ssr_util/jumpers and set the jumpers on the card. See Figure 1. The jumper program shows two selections for jumper settings. They are actually both the same. Select DIX if you use thick cable, BNC for thin cable. This sets up the card with : DMA Channel 6 I/O Base 300h Interrupt 10 Memory Address : Unit 0 Address 8 4.0 Test tcp/ip Make sure that tcp/ip is up and running by pinging each host on the ATR. % ping m07 PING m07: 56 data bytes 64 bytes from 198.8.6.54: icmp_seq=0. time=17. ms 64 bytes from 198.8.6.54: icmp_seq=1. time=10. ms 64 bytes from 198.8.6.54: icmp_seq=2. time=11. ms m07 PING Statistics 3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms) min/avg/max = 10/12/17 5.0 Shut Down the Node Shut down the node and turn off the power. Put the service/normal switch into the service position. 6.0 Installation of the Ethernet Card Install the card into any slot. Power on the node. I did not find it necessary to tell CONFIG that I have installed the 3C505. If you do run CONFIG, set up the machine to have two network controllers, the Ring and the Ethernet card. Select the Ring as the primary network. When I did this, the boot diagnostics had trouble finding the card even though everything worked fine. Try whatever works. I decided not to tell CONFIG about the card so the machine would still automatically boot. I had no problems with this. 7.0 Test the Ethernet Card Press RETURN a few times until you get the '>' MD prompt. Type RE and RETURN a few ti
Re: IBM 360 Model 50 information?
On 03/28/2019 11:46 AM, Ken Shirriff via cctalk wrote: I'm writing a S/360 Model 50 emulator that runs at the microcode level, in order to drive a Model 50 front panel accurately. I'm about 80% of the way there, but there are some microcode operations that I haven't figured out. So I figured I'd ask if anyone has obscure Model 50 manuals that aren't on bitsavers, or perhaps even the ALDs. I was surprised at how extremely different the microcode is from the 360 instruction set. If you had a 360 instruction set, why would you implement a 360 by an emulator? It would be most common that a microcode emulator would be a quite different scheme, kind of implementing an RTL (Register Transfer Logic) in a "language". I've figured out a bunch of the strange micro-instructions, such as S47ΩE, which ORs the emit field into flags 4 through 7. But there are many micro-instructions that still puzzle me, like F→FPSL4 which maybe a floating point shift left 4 and 1→BS*MB which does something with byte stats. So if anyone happens to have a Model 50 microcode programming manual sitting around, please let me know :-) Wow, what a project! I think the only way to understand the microcode is to follow the signals through the ALD schematics. A microcode programming manual would be of no use to anyone, as the microcode bit pattern was stored in the serpentine word-line traces of the control store boards. 360/50 and 360/65 used CCROS (capacitor-capacitor read only storage) where there were two word lines on one board, one driven and one grounded through a resistor, called drive lines and balance lines, respectively. If there was a wide pad on the drive line opposite the pad on the bit line, that generated a 1 in the control store word, if the wide pad was on the balance line, you got a zero. A very thin Mylar sheet separated the two boards, and pressure was applied by a pressure plate and foam pad. So, a microcode change required a board master artwork to be changed and a new board etched. Not a practical field operation. The only custom microcode I heard of in these models was for the National Airspace System for the FAA traffic control computers. The variant of the 360/50 was called a 9020D display element, and the 360/65 variant was called the 9020E compute element. So, somebody used the required documents for that project. Oh, one other issue is the 360's had no FFs. All storage elements were transparent latches, and they generally used a 4-phase clock. All this is pretty well documented between the ALDs and the FEMM's for the particular model. Jon
Re: VCF/PNW Exhibit & Trip Report - The Old Calculator Museum
Noel Chiappa wrote: > > It has been in use at STACKEN at least since the beginning of the 80ies > > I was meaning before that; somewhere in Scandanavia, I expect? Eh, not that > important, I guess. >From Finland. Sold used by DEC Sweden to Stacken, for 1 SEK (aound 20 cents at that time). >Noel --Johnny /\_/\ ( *.* ) > ^ <
Re: VCF/PNW Exhibit & Trip Report - The Old Calculator Museum
> From: Mattis Lind >> Ah. I wonder where it came from originally? > It has been in use at STACKEN at least since the beginning of the 80ies I was meaning before that; somewhere in Scandanavia, I expect? Eh, not that important, I guess. >> And it's odd (to me, at least) to see TU56's on a KA10. > It is TU55s as far as I can see. Ah, I was confused by an aspect of the pictures on that page which I hadn't noticed before! The fourth picture in that set: https://mobile.twitter.com/LivingComputers/status/1102063746019549184/photo/4 which is where I saw the TU56's (along with at least one TU55), shows a different machine! I just assumed all four were of the KA, but the last shows them in front of a KI. Although one has to look carefully to notice that, though, as the size, colours, etc are very similar; it thus looks _very_ similar to the KA in the first ones. I'd still love to find out if there are any other KA's left - does anyone know of any? Noel
Byte Magazine
In a previous thread I asked for a couple of specific pages from Byte magazine, which I got (thanks to all, especially Peter, for helping out!) But that brings up a bigger issue (no pun intended.) About a year ago I found the Byte scans on americanradiohistory.org and started reading from the start. I found that those scans were less than great, with many missing pages, pages out of order, pages scanned at resolutions too low to read, and a few other problems. I went searching the web for other scans and, with a few exceptions for individual issues, found that ALL the collections of scans seemed to be the same ones, with the same bad pages. I certainly appreciate the considerable effort of whoever did those scans, but I think Byte is too important to not have good scans available. Perhaps a project to get those good scans created would be something worthwhile for the members of this list to take on. I realize what a huge project it is. Just going through the currently available scans to find which pages are bad or missing is a large and time-consuming effort. But my opinion is that it is important and worthwhile. Any thoughts? Thanks, Will "He may look dumb but that's just a disguise." -- Charlie Daniels "The names of global variables should start with // " -- https://isocpp.org
Re: Looking for Byte Jan 78 missing page
On Thu, 28 Mar 2019 at 10:29, Tor Arntsen wrote: > > On Mon, 25 Mar 2019 at 01:41, Randy Dawson via cctalk > wrote: > > > > The american radio history site has this byte issue intact, with your > > missing pages: > > > > https://www.americanradiohistory.com/Archive-Byte/70s/Byte-1978-01.pdf > > That copy has page 97/98 missing as well - I meant to say 96/97, but that's actually wrong too - the missing sheet contains pages 95/96. And page 96 is the article page that Peter Cetinski provided a photo for.
IBM 360 Model 50 information?
I'm writing a S/360 Model 50 emulator that runs at the microcode level, in order to drive a Model 50 front panel accurately. I'm about 80% of the way there, but there are some microcode operations that I haven't figured out. So I figured I'd ask if anyone has obscure Model 50 manuals that aren't on bitsavers, or perhaps even the ALDs. I was surprised at how extremely different the microcode is from the 360 instruction set. I've figured out a bunch of the strange micro-instructions, such as S47ΩE, which ORs the emit field into flags 4 through 7. But there are many micro-instructions that still puzzle me, like F→FPSL4 which maybe a floating point shift left 4 and 1→BS*MB which does something with byte stats. So if anyone happens to have a Model 50 microcode programming manual sitting around, please let me know :-) Thanks, Ken
