And Carl Claunch has an IBM 1130 in VHDL. Marc Sent from my iPad wrote: Sotomayor Jr provide the functions of the IC and use that in their designs. I?ve seen at least two interesting classic computer recreations using this approach (re-implemenation of the CADR lisp machine in verilog and an IBM 360/30 in verilog). combinatorial equations which are relatively easy with the verilog ?assign? statement.

And I'm very close to having a 360/65 in VHDL. ----- Sweet :->. What FPGA platform are you using? Lawrence used a Spartan

On Jul 11, 2016, at 5:31 PM, Camiel Vanderhoeven <iamcamiel at gmail.com> wrote: And I'm very close to having a 360/65 in VHDL. Op 11 jul. 2016 2:44 a.m. schreef "Curious Marc" <curiousmarc3 at gmail.com>: > And Carl Claunch has an IBM 1130 in VHDL. > Marc > > Sent from my iPad > >>> On Jul 10, 2016, at 10:23 PM, Lawrence Wilkinson <ljw-cctech at ljw.me.uk> >> wrote: >> >> That'll be me, I guess, It's in VHDL. URL in sig. >> >>> On 10/07/16 15:21, Paul Birkel wrote: >>> -----Original Message----- >>> From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Guy > Sotomayor Jr >>> Sent: Monday, June 20, 2016 4:04 PM >>> To: General Discussion: On-Topic and Off-Topic Posts >>> Subject: Re: How do they make Verilog code for unknown ICs? >>> >>> What you can do (and I?ve seen it done) is define verilog modules that > provide the functions of the IC and use that in their designs. I?ve seen > at least two interesting classic computer recreations using this approach > (re-implemenation of the CADR lisp machine in verilog and an IBM 360/30 in > verilog). >>> >>> ROMs are easy (just instantiate a lookup table). PLCs are just > combinatorial equations which are relatively easy with the verilog ?assign? > statement. >>> >>> TTFN - Guy >>> >>> ====****==== >>> >>> Do you have a pointer to that "IBM 360/30 in Verilog", Guy? >>> >>> ----- >>> paul >> >> -- >> Lawrence Wilkinson lawrence at ljw.me.uk >> The IBM 360/30 page http://www.ljw.me.uk/ibm360 >

On Jul 12, 2016, at 1:11 AM, Jon Elson <elson at pico-systems.com> wrote: 360/50 is a 32-bit machine, the real thing has a core memory "local store" and (3, IIRC) built-in channels. it does not allow memory interleaving. The 360/65 has a 64-bit path to memory, and does permit interleaving. it also allows two /65s to be put together in a multiprocessor system. There are a few additional instructions to communicate between CPUs. The 65 has solid state local store, and a 56-bit ALU, so it can do double-precision floating-point arithmetic without having to double up the cycles, as the /50 does. The /65 has no built-in channels. Jon

On Jul 12, 2016, at 11:31 AM, Jon Elson <elson at pico-systems.com> wrote: Not really! The 360/50 had 4 "rollers" for 4 rows of lights, and one row of data switches, and 2 rows of dedicated lights. The 360/65 had 6 rollers with 6 rows of lights, plus TWO rows of data switches, and pretty much no dedicated lights other than associated with the rollers. Both had a row of address switches under the data switches. So, yes, in GENERAL, they had a similar look and layout, but in detail, there was a lot different, some of it specifically related to the memory word width. The only machine that looked really different was the 360/30, that had a panel more reminiscent of the 1401. And, of course, the 360/85, which was really a prototype of the 370/165. As far as software was concerned, it was just a really fast 360, but the hardware was MUCH more advanced. Jon

> -----Original Message----- > From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Curious > Marc > Sent: 12 July 2016 08:58 > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> > Subject: Re: IBM 360/30 in verilog > > Darn. My hopes are shattered. Lots of Verilog in my future, that is if

can It actually might be easier to produce a generic S/360 clone in FPGA using the POP rather than individual ALU's. Having built a very simple CPU (in VHDL not Verilog) and planning to start on a more complex (Ferranti Pegasus) Of course it wouldn't be cycle accurate, but perhaps that wouldn't be important.

I think you are correct. I had assumed that the panel only displayed the normal 360 registers, in which case the VHDL could easily route these to a panel, but on reading the 360/65 Functional Characteristics http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/360/funcChar/A22-6884-… I can see several registers are displayed that are not mentioned or defined elsewhere so you would need a Set of ALDs for the 65 (or possibly a 67 as that?s basically the same machine) to get a full panel display. It would Also be nice to see what is on the roller selector switchs as that page in the manual has not scanned very well..

Op 12 jul. 2016 10:14 a.m. schreef "Dave Wade" <dave.g4ugm at gmail.com>: we Sure, a generic one would be simpler, but the point of doing an accurate one of a specific model (65 in my case) is to accurately drive the panel that shows the internal registers and opening of gates.

On Jul 12, 2016, at 5:14 PM, Dave Wade <dave.g4ugm at gmail.com> wrote: It actually might be easier to produce a generic S/360 clone in FPGA using the POP rather than individual ALU's. Having built a very simple CPU (in VHDL not Verilog) and planning to start on a more complex (Ferranti Pegasus) Of course it wouldn't be cycle accurate, but perhaps that wouldn't be important.

http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/360/princOps/A22-6821-0 It depends on what you're trying to emulate. If you want an instruction level simulator, sort of a SIMH in silicon, then going from the POP or analogous documents (processor reference manuals, computer family architecture manuals such as DEC published for the PDP-11 and VAX) will do nicely. Such an approach is not going to show you the peculiarities of a particular implementation, details too deep for the sort of documentation you're using, let alone implementation bugs. By way of analogy, if you build a CDC 6000 emulation using that approach, it won't do the "zero written to memory at PC at deadstart time" property, because that is nowhere documented or explained in any printed document I have ever seen. But it's part of the unwritten lore of that machine. If you build a gate level model from the engineering drawings, you can see it clearly (and you can readily discover its cause). Building an accurate model from a POP requires a great deal of intellectual effort, to understand all the critical details sufficiently to model them in behavioral models. You can perhaps lift them from existing software emulators (SIMH, Hercules) and get "close enough". Debugging would be hard, especially if the documentation isn't quite accurate enough to allow all the diagnostics to pass. A gate level model constructed from the engineering drawings is more cumbersome in certain ways, almost certainly less efficient in FPGA resources -- but it's much more a mechanical process. If the drawings are accurate (that's an "if" indeed), then the model will be accurate. The diagnostics should pass without major effort, serving more as confirmation tools than as debugging aids. paul

And I'm very close to having a 360/65 in VHDL. Op 11 jul. 2016 2:44 a.m. schreef "Curious Marc" <curiousmarc3 at gmail.com>:

From memory, the 65 is the bigger brother to the 50 with a wider memory bus.

The microcode was in the ALD drawings, and might even be in bitsavers archive, if they have the right manual.

Al said: Indeed they must be. I've been looking for /40 ALDs for some time but haven't struck any. I wonder if they're scarce becase the 40 was a AFAIK a british-developed 360. My dad was posted to Hursley to learn the /40 in 64-65. The only Model 40 docs I have left are less than a dozen pages of 'IBM SYSTEM/360 MODEL 40 DEVELOPMENT MANUAL' from March 1965 from 'IBM BRITISH LABORATORIES'. Why do I have these? Dad used to bring home Model 40 binders in the late 60s so my brother and I had a good supply of paper to scribble and paint on as kids. All the pages I have left have drawings on the blank side and that was why my parents kept them :) Steve.

Mike said: > On Tue, Jul 12, 2016 at 10:36 AM, <steven at malikoff.com> wrote: >> Al said: >>> On 7/11/16 9:14 AM, Jon Elson wrote: >>>> The microcode was in the ALD drawings, and might even be in

>>> >>> 360 CPU ALDs are extremely difficult to find. >>> If the 65 set could be scanned, I'd be happy to upload them to

>> >> Indeed they must be. I've been looking for /40 ALDs for some time but

>> scarce becase the 40 was a AFAIK a british-developed 360. My dad was

Camiel said: Yes, the wiki does say that, but I am sure Hursley was involved in designing hardware as well, for instance TROS. This PDF by Pugh states that a team at Hursley were designing the Model 40: http://ed-thelen.org/Pugh-Technology_Transfer.pdf As a CE, my dad was there to study the hardware only.

Indeed they must be. I've been looking for /40 ALDs for some time but haven't struck any. I wonder if they're scarce becase the 40 was a AFAIK a british-developed 360. My dad was posted to Hursley to learn the /40 in 64-65.

Jon said: I didn't know that every machine came with a set of ALDs but you are right that a lot of /40's were sold stateside. My dad was re-posted directly from Hursley to Poughkeepsie in '65 which I was where some (or all?) the /40s were assembled. One of the IBM Journals (75 years?) has a large colour photo of a row of 40s on the final assembly floor at Poughkeepsie, everyone in it striking that characteristic 60s/70s IBM-photo-pose, eg. someone leaning over a table, another reaching for a console knob, one changing a tape and at least two people earnestly discussing a printout.

Most weren't sold, but leased. The ALDs would be used by the IBM CE, not the customers themselves. I don't know if machines that were sold rather than leased came with ALDs or if IBM kept these, I suspect the latter to be the case.

On Jul 12, 2016, at 2:00 AM, Al Kossow <aek at bitsavers.org> wrote: 360 CPU ALDs are extremely difficult to find. If the 65 set could be scanned, I'd be happy to upload them to bitsavers.