https://forum.vcfed.org/index.php?threads/multiple-microprocessors-as-a-single-cpu-not-multiprocessing.1245942/ Vintage Computer Federation Forums Upcoming Events: * VCF SoCal - February 17 - 18, Hotel Fera, Orange CA * VCF East - April 12 - 14, Infoage Museum, Wall NJ * VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas * VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA * VCF Midwest - App. Sept 2024, Waterford Banquet, IL Vintage Computer Federation Forums * VCFed Website * Forums New posts Search forums * What's new New posts New profile posts Latest activity * Members Current visitors New profile posts Search profile posts Log in Register What's new Search Search [ ] [Everywhere ] [ ]Search titles only By: [ ] Search Advanced search... * New posts * Search forums Menu Log in --------------------------------------------------------------------- Register --------------------------------------------------------------------- Install the app Install * Please review our updated Terms and Rules here * Forums * Genres * Other JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding. You are using an out of date browser. It may not display this or other websites correctly. You should upgrade or use an alternative browser. Multiple microprocessors as a single CPU (not multiprocessing) * Thread starter jplr * Start date Today at 9:54 AM J jplr Experienced Member Joined Sep 3, 2022 Messages 119 Location Brittany/France * Today at 9:54 AM * * #1 Beware this is a weird idea! I know that some Sun stations used two 68000 CPUs to implement virtual memory (one in advance of one instruction wrt the other). There is also a smart contraption named KimKlone which adds registers to a regular 6502. Are there other examples using microprocessors to implement maybe also: - Extended range of memory addresses (one CPU provides the low addresses, the other provides the high addresses maybe to a rudimentary MMU) - Extended words in CPU with only ADC/SBC/shifts/rotations by reducing the data path by two bits to generate carry out as carry in the next CPU. Thanks! F Frio Member Joined Jan 8, 2020 Messages 21 Location Toronto, Canada * Today at 2:05 PM * * #2 Well, some systems (mainframes mainly) use multiple CPUs in tandem for redundancy against cosmic rays, not sure if that qualifies :)(y) * Like Reactions: daver2 and jplr J jplr Experienced Member Joined Sep 3, 2022 Messages 119 Location Brittany/France * Today at 4:11 PM * * #3 > multiple CPUs in tandem for redundancy against cosmic rays Thanks, indeed that qualifies! K krebizfan Veteran Member Joined May 23, 2009 Messages 6,102 Location Connecticut * Today at 4:20 PM * * #4 Some of the Pocket Computers used a pair of 4 bit CPUs. https:// www.floodgap.com/retrobits/tpm/138.html has a description of how one worked. * Like Reactions: Frio J jplr Experienced Member Joined Sep 3, 2022 Messages 119 Location Brittany/France * Today at 4:33 PM * * #5 > Tandy PC-1 dual-cpu Thanks, that's a nice addition! seat safety switch seat safety switch Experienced Member Joined May 24, 2018 Messages 69 Location Alberta * Today at 4:36 PM * * #6 Do bit-slice setups like the Am2900 count? * Like Reactions: NeXT J jplr Experienced Member Joined Sep 3, 2022 Messages 119 Location Brittany/France * Today at 4:38 PM * * #7 > Do bit-slice setups like the Am2900 count? As long it is an unusual implementation. F Frio Member Joined Jan 8, 2020 Messages 21 Location Toronto, Canada * Today at 5:07 PM * * #8 I would add the Fujitsu FM-8/7/77 series, where two identical CPUs perform different tasks: one Motorola 6809 acts as the main system CPU, while the second (identical) one operates as a graphics coprocessor, with exclusive access to VRAM, executing its own separate code from ROM and a tiny RAM. It is interesting because the second CPU can be coerced into executing tasks other than graphics too, but it was really meant to be a graphics coprocessor. J jplr Experienced Member Joined Sep 3, 2022 Messages 119 Location Brittany/France * Today at 5:08 PM * * #9 Thank you @Frio! Eudimorphodon Eudimorphodon Veteran Member Joined May 9, 2011 Messages 6,478 Location Upper Triassic * Today at 7:59 PM * * #10 krebizfan said: Some of the Pocket Computers used a pair of 4 bit CPUs. https:// www.floodgap.com/retrobits/tpm/138.html has a description of how one worked. Click to expand... Nitpick: Floodgap's description is pretty vague and not really accurate. The TL;DR is that one of the chips was the "CPU" running user programs and the other was an I/O processor handling the keyboard and display. This is not an unusual architecture in and of itself, plenty of computers have multiple "CPUs" once you count I/O handlers, and doesn't count as some kind of "merged" CPU. (For instance, most computers with detatched keyboards, and plenty that don't, have a microcontroller in there handling the matrix scanning.) It seems a *little* weird to us today, maybe, to have I/O processors are the same (or nearly the same) as the "main" CPU, but in the 8 bit era this was par for the course. For more examples of this you don't have to look any further than your typical terminal; "hardwired" serial terminals without CPUs were pretty much extinct for new designs by 1977 or so because at this point it became cheaper (and a *lot* more flexible) to drop a CPU or microcontroller onto your circuit board than it was to implement anything but the most rudimentary text handling and cursor controls with hardware state machines. Therefore probably the majority of 8-bit S100 computers had a CPU handling the display and keyboard that was of comparable power to the one in the box. (Heck, some "video cards" for S100 machines were effectively just terminals on a card eliminating the serial connection, and had their own Z80 CPU on them. Machines like the Heath/Zenith H/Z-89 have dual Z80 CPUs for this very reason; the Z-89 is just a Z80-powered Z-19 terminal with a second PCB containing the "computer" stuffed into it.) Possibly a better example of two CPUs working in extremely tight lockstep might be the how Commodore's old IEEE disk drives (2040/4040 /8050/etc) worked. These drives contained not one but *two* 6502-family CPUs (a 6502 and a 6504, I believe?) clocked 180 degrees out of phase with each other, allowing them to share a common memory buffer with no contention. One CPU ran the "DOS" and communicated with the host computer, the other was a dedicated disk controller running code to handle the actual disk mechanics, etc. These CPUs ran at the same 1mhz as the 6502 in your Commodore PET, so technically buying one of these drives tripled the theoretical power of your computer. I think it may have even been technically possible to manipulate the memory of the "DOS" processor in the drive to run arbitrary code, like people do with the C64's 1541, so in a pinch you might even be able to use one of them as a "coprocessor" for user code, although whether anyone ever actually did that or not I have no idea. That said, though, the two CPUs in a Commodore 4040 are still doing separate "things", they're not somehow merged into a "super-6502". jplr said: There is also a smart contraption named KimKlone which adds registers to a regular 6502. Click to expand... FWIW, this is kind of reminiscent to how the 8087 math coprocessor for the 8086 works. (And also the fairly rarely used 8089 I/O coprocessor.) These chips run in lockstep with the main CPU snooping instruction fetch transactions. grabbing relevant opcodes directly off the bus and, when necessary, grabbing the bus by instigating a DMA request. Obviously it's not quite the same thing because Intel specifically assigned an "escape" bit sequence to be used to prefix coprocessor opcodes (thereby allowing a software handler to respond appropriately if these opcodes came up without the coprocessor installed, as opposed to whatever undefined behavior might happen when an "illegal" opcode is thrown at a CPU that doesn't know how to trap it), but it was once upon a time a "legit" technique. Intel moved away from this idea to a "private" coprocessor connection with the 286 and later because having to duplicate all this bus interface circuitry in every coprocessor is pretty stupidly inefficent. A subset of this "trapping" technique was sometimes used to patch errors in system ROMs, back when memory was expensive enough to actually justifying slapping a PCB with several chips into a system to salvage the existing ROM vs. just replacing it. jplr said: Extended words in CPU with only ADC/SBC/shifts/rotations by reducing the data path by two bits to generate carry out as carry in the next CPU. Click to expand... ... so how is that supposed to work exactly? I mean, honestly curious if this is a thing you've seen. I would definitely say that bit-slice "CPUs" do not count here. They are, by definition, not "complete" CPUs on their own, and are explicitly designed to be used in arbitrarily ganged configurations. Last edited: Today at 8:06 PM * Like Reactions: jplr K krebizfan Veteran Member Joined May 23, 2009 Messages 6,102 Location Connecticut * Today at 8:14 PM * * #11 Multiple chip CPUs were common enough. The two I remember were the Intel 432 and the DEC LSI-11 but I don't recall if the supporting chips would ever be working on their own. seat safety switch seat safety switch Experienced Member Joined May 24, 2018 Messages 69 Location Alberta * Today at 8:46 PM * * #12 krebizfan said: Multiple chip CPUs were common enough. The two I remember were the Intel 432 and the DEC LSI-11 but I don't recall if the supporting chips would ever be working on their own. Click to expand... Early versions of the Motorola 88k as well, I think. They later merged the support chip into the main CPU. I was looking briefly at them to make a homebrew but prices are silly for both chips, as well as the later revision of the CPU. Eudimorphodon Eudimorphodon Veteran Member Joined May 9, 2011 Messages 6,478 Location Upper Triassic * Today at 9:53 PM * * #13 krebizfan said: Multiple chip CPUs were common enough. The two I remember were the Intel 432 and the DEC LSI-11 but I don't recall if the supporting chips would ever be working on their own. Click to expand... The NatSemi IMP-16 was an early example (1973) of something kind of halfway between a "generic" bitslice like the am2900 family and a multi-chip CPU. In a normal configuration it needed 4 "RALU" 4-bit register/ALU components, roughly equivalent to the AM2901 but a little bit more "complete" (but less flexible), and a single CROM control/microcode ROM to tie them together and implement an instruction set heavily reminiscent of a Data General NOVA. (An optional second CROM implemented 16 bit multiply/divide instructions.) Because the "slices" were intended to be basically proprietary to the set they weren't used as tinkertoys like the AM2900 series were, but there was *very briefly* a NatSemi application note and datasheet covering an alternate CROM to let you build an "IMP-8" with two RALUs. There might have been a month or two when that looked like a good idea but the 8080 and 6800 coming out firmly drove a fistful of nails into that coffin. You must log in or register to reply here. Share: Facebook Twitter Reddit Pinterest Tumblr WhatsApp Email Share Link * Forums * Genres * Other * Default style * Contact us * Terms and rules * Privacy policy * Help * Home * RSS Community platform by XenForo^(r) (c) 2010-2022 XenForo Ltd. Top [ ]