On Mon, 28 Jul 2014, Eric Smith wrote: Speaking of microcode and data paths: let's add the Dietz Mincal 523. It's a very cleverly designed microprogrammed minicomputer (19 bit word length) from around 1970 (the precursor was the Mincal 4 series). The most exciting thing about it (apart from the odd word length) are 1. the microcode lies in normal address space and 2. the copper trace/transformer ROMs (some pics can be found on the preliminary page at http://computermuseum.informatik.uni-stuttgart.de/dev/mincal523/). Point 1 along with the fact that the macrocode (i.e. machine language) registers are in core memory makes the machine incredibly slow, but makes it possible to execute arbitrary microcode from core memory, too. The machine has complex I/O and interrupt hardware suited for all kinds of process control and the like, but the CPU itself consists of only several not so big circuit boards with LSI TTL parts (I think the most complex part are the five 7483 ALU ICs). Christian PS: I had to completely reverse-engineer the machine and microcode due to the complete absence of any information on this machine.

On Jul 29, 2014, at 10:45 AM, dwight <dkelvey at hotmail.com> wrote: Instruction length has little to do with it. CDC Cybers have 6 bit opcodes and hardwired execution; VAXen have 8 bit opcodes and microcode; MIPS has fairly long opcodes and is hardwared. The choice comes to what?s the best answer given the product requirements. If use of microcode makes the implementation less expensive while still achieving the performance requirement, that would be the optimal answer. If not, then hardwired logic is the solution. That tradeoff, of course, varies over time as technology, speeds, and costs change. And it?s not a binary decision, either. When microcode is used, there tends to be some machine-specific hardwired logic. For example, in the PDP-11 microcode you can see initial opcode dispatch done in straight logic, then once the dispatch has taken place the microcode takes over to handle that particular case. When machines have a mix of simple and complex instructions, it might make good sense to do the simple ones in logic and the complex ones in microcode. I wonder if the 68040 did that ? it had a clearly recognizable ?RISC subset?, instructions that execute in just one or two cycles, and ?the rest?, complicated instructions that took a lot longer. paul

On Jul 29, 2014, at 12:13 PM, Chuck Guzis <cclist at sydex.com> wrote: The PowerPC 601 retained a number of instructions inherited CPUs (603/604). It wasn't a straightforward shrink, though, as some additional instructions were added (FRES, for example, the fast floating-point reciprocal estimate, is 603 and up and is optional). A lot of the POWER instructions jettisoned were ones one might traditionally associate with "business logic" like one might see on an IBM mainframe; instructions like lscbx, which is a weird-ass instruction but could certainly have applications in a specific domain. - Dave

On Jul 29, 2014, at 4:15 PM, Chuck Guzis <cclist at sydex.com> wrote: Along those lines, the 6502 in the Nintendo Entertainment System (apparently intentionally) broke the BCD functionality. The 6502 used a PLA for instruction decoding, but interestingly, the BCD breaking wasn't done there; there were some linkages between the main ALU and the BCD adjustment circuitry that were broken. I don't know exactly why they would have done such a thing, other than to restrict the target market of the eventual device. The 6502 portion of the NES' 2A03 CPU/sound generator/etc. chip is otherwise a copy/paste job of the standalone version; perhaps MOS offered a cheaper license for chips without BCD? - Dave

That reminds me of the Tektronix 4050 series. The 4051 used a Motorola 6800. The 4052 and later used a 16-bit microcoded processor based on the AMD2900 series. The microcode emulated a 6800, but without BCD. Instead, it added some memory management: separate instruction (F, I think standing for Fetch) and data (D) spaces, for 128K bytes of physical memory. One really nice feature was the FSWP instruction - swap the fetch space. This set a flip-flop, but didn't actually toggle the high bit of the fetch address until the next jump instruction (or related - I think jumping to or returning from subroutines did also implemented any pending FSWP.) I think, but I am not sure, that the choice of opcodes that updated the F bit was hard coded, not a microcode thing. On the other hand, the machine was made more general purpose than you might expect by having a large chunk of hard-coded instruction decode stored not in logic, but in another ROM. Philip.

On 07/29/2014 02:05 PM, Paul Koning wrote: I've never seen a 1623 expansion unit in the metal, so to speak--they must have been very scarce indeed--all of the 1620s that I've run into have been CADETs, though some of the front panels used on "The FORBIN project" as props probably were Mod IIs or maybe even 1710s. Funny, the movie itself that used old computer junk is itself an antique now. Funny thing is that I can still remember many numeric opcodes for the thing--and always start an instruction on an even-digit boundary... My, how time flies. --Chuck

On 07/30/2014 06:59 AM, Paul Koning wrote: Well, hydraulics stayed around long after the 1311--CDC used it extensively on drives like the big 808--and I don't have to remind you about the Bryant drives with their "leak jugs". The sites I knew of that used the 1620 generally went straight to the 1130 or something larger. Yup, the FANDK control statement--I think that even the card-only FORTRAN compiler had something very akin to that. I used that a few times. Read in the compiler, then your program, collect the cards that got punched, read in the second pass and the newly-punched cards, get an object deck, read in the runtime and your object deck(s) and run your code. There was also a NOISE DIGIT statement, I seem to remember. Have you checked the 1620.ZIP file in the software section of Bitsavers? Seems to me that SPS II-D (and probably other versions) was in there. --Chuck

On Jul 29, 2014, at 12:13 PM, Chuck Guzis <cclist at sydex.com> wrote: VAX is an example ? the subsets came later, under the pressure of fitting all that into a single chip. paul

On Tue, Jul 29, 2014 at 09:13:42AM -0700, Chuck Guzis wrote: [...] Reasonably interesting CPUs effectively have two instruction sets: user instructions in which applications are implemented, and system/supervisor instructions for use by the operating system. The latter are more malleable than the former, since the operating system is expected to be upgraded to take the different functionality into account. As an example of changes to the OS functionality, the 68030's MMU offered a wide range of page table sizes, but in the 68040 this was reduced to just two, with corresponding changes to the supervisor instruction set. When Freescale evolved the 680x0 line with their "Coldfire" series of CPUs, they also removed a whole swathe of instructions and addressing modes such as DBcc and BCD instructions. At one point in ARM's evolution, they added a new operating mode called Jazelle which could execute the simpler JVM instructions and would trap for hard-to-implement instructions. Contemporary ARM chips have stub support which trap on *all* instructions. When x86 was extended to 64 bits, segmentation support was gutted (yay!) and remain as just a pair of extra base registers, typically used to locate thread-local storage.

On 07/30/2014 10:20 AM, Dave G4UGM wrote: I thought Read Direct and Write Direct were grandfathered into S/360 channel-to-channel interface. The idea being that you could have one system handle I/O for the compute-intensive big machine. Ah yes, IBM VECTRAN, the source of many ANSI X3 squabbles. --Chuck

I don't think these Read Direct and Write Direct were anything to do with intersystem comms, as there were Channel to Channel adaptors which were I think included with the original S/360 announcement... .. but perhaps not. I am sure some one will say if its so... Dave -----Original Message----- From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Chuck Guzis Sent: 30 July 2014 18:53 To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: microcode store (was Re: Looking to get into a MiniComputer...) On 07/30/2014 10:20 AM, Dave G4UGM wrote: I thought Read Direct and Write Direct were grandfathered into S/360 from the 7040/7090 DCS setup, where it was essentially a channel-to-channel interface. The idea being that you could have one system handle I/O for the compute-intensive big machine. Ah yes, IBM VECTRAN, the source of many ANSI X3 squabbles. --Chuck

Thanks Chuck, Didn't have time to check the PLM, Any one got any pics of what the wiring is like.... Dave G4UGM -----Original Message----- From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Chuck Guzis Sent: 30 July 2014 21:49 To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: microcode store (was Re: Looking to get into a MiniComputer...) On 07/30/2014 11:13 AM, Dave G4UGM wrote: Out comes the Red Book (Principles of Operation): Under "Read Direct": "The direct-out lines of one CPU may be connected to the direct-in lines of another CPU, providing cpu-to-cpu static signaling. Further, the write-out signal of the sending CPU may serve as the hold signal for the re- ceiving CPU, temporarily inhibiting a READ DIRECT when the signals are in transition. Equipment connected to the hold-in line should be so constructed that the hold signal is removed when READ DIRECT is performed. Absence of the hold signal should correspond to absence of current in such a fashion that the CPU can proceed when power is re- moved from the source of the hold signal." Basically, yes, it's a parallel port with handshaking a few extra bits--and apparently, everything stops during the transfer. From WD: "The byte at the location designated by the operand address is made available as a set of direct-out static signals. Eight instruction bits are made available as signal-out timing signals. The eight data bits of the byte fetched from storage are presented on a set of eight direct-out lines as static signals. These signals remain until the next WRITE DIRECT is executed. No parity is presented with the eight data bits. Instruction bits 8-15, the I2 field, are made available simultaneously on a set of eight signal-out lines as 0.5- microsecond to 1.0-microsecond timing signals. On a ninth line (write out) a 0.5-microsecond to 1.0-micro- second timing signal is made available coincident with these timing signals. The leading edge of the timing signals coincides with the leading edge of the data signals. The eight signal-out lines are also used in READ DIRECT. No parity is made available with the eight instruction bits." HTH, Chuck

On 07/30/2014 03:28 PM, Al Kossow wrote: Don't know exactly what you mean by "real". I bought it in 1967. --Chuck

On 07/30/2014 09:45 AM, Peter Corlett wrote: So the CDC 6600 isn't interesting? :) Actually, if you look carefully, the "supervisor" instructions are effectively another CPU--the PPUs. --Chuck

On Tue, 29 Jul 2014, Al Kossow wrote: Yes, see at the bottom of http://computermuseum.informatik.uni-stuttgart.de/dev_en/mincal523/ I've created English pages in the meantime and added more pictures. More will follow as time permits. Christian