How feasible is it to add a second CPU to the ZX Spectrum?

edited June 2009 in Hardware
Today with IDE, and USB, and TCP/IP and other wonderful technologies arriving on the ZX Spectrum, I'm beginning to wonder if we'll run out of CPU time, for handling all of these devices on the weak Z80 @ 3.5MHz.

But, say, if a second (and maybe a third and fourth?) Z80 shared our contended memory, then we could "easily" (at least, from a software perspective) expand the computational power of the ZX Spectrum. Let me detail the interface I've been inventing in my dreams:

This second Z80, I call CPU1, has access to the contended memory, but only when neither CPU0 nor the ULA are using it. This ensures 100% compatibility with the existing 48K Spectrums. Interfacing with this is simple:

Two bytes are the address.
One byte for data.
One byte for control: let 0 mean ready, or no-op, 1 mean write, 2 mean read, 4 mean execute (i.e. jump to the address), and the other values can have other meanings.

So, if you want to write to the memory of CPU1, then simply put the address and data in place, put 1 into the "control register", and wait for the CPU1 to clear this register again. Maybe this would be slow, but write a very short program onto CPU1 to copy the screen memory, and voila, we have a kind of DMA...

Maybe we'd like to be able to write into the CPU registers AF, BC, DE, IX etc also? Or be able to write multiple values in adjacent memory locations, by having CPU1 automatically increment the address pointer? then we just assign other values in the control register for this.

Now let me pose two questions to the other enthusiasts here:
A) Is the hardware for this feasible to design and construct?
B) Is having more CPUs desirable on such a computer?
EDIT: And let me ask another few:
C) Have I described my implementation comprehensibly?
D) Are there better ways to implement ASMP technologies with such limited resources on the master processor?
E) We know from experience that SMP tends to perform better in parallel processing than ASMP, but as far as I understand, SMP needs both processors to have access to the same memory. So, if we replace the existing memory with faster memory, would we then be able to have both CPU0 and CPU1 access the uncontended memory too?
Post edited by wilsonsamm on

Comments

  • edited June 2009
    http://translate.google.com/translate?u=http%3A%2F%2Fwww.nedopc.com%2Fgs%2Fngs.php&sl=ru&tl=en&hl=cs&ie=UTF-8

    This interface contain also faster Z80CPU and work parallel with main CPU.....
  • edited June 2009
    Decent data transfer rates can be had without a DMA. Hardware add-ons can contain their own CPUs if it's appropriate. The Timex FDD system had its own Z80 as well and only used the Speccy for keyboard I/O and generating the display. On the other hand, if you reduce the Speccy to working as a dumb terminal does it still count?
  • edited June 2009
    The Timex FDD system had its own Z80 as well and only used the Speccy for keyboard I/O and generating the display.?
    Ah yes, like the 1541 disk drive with the Commodore computers. People had these do on-the-fly compression/decompression as they read/wrote the disk, IIRC. Is it possible to have the Timex FFD run your own software?
    On the other hand, if you reduce the Speccy to working as a dumb terminal does it still count?
    I suppose so, but why would you? The point is to expand the capabilities of the ZX Spectrum :-) If you add another dozen Z80s, then the primary CPU still works, so why not use it to do calculations? I picture such setups using the first CPU to delegate tasks to the other CPUs.
  • I know this is an old thread but just out of interest has anyone ever tried building a Z80 based parallel processing system? Wouldnt or couldnt 4 of the little buggers be set up to deal with a 32 bit bus? Of course its 'slow' compared to modern processors but really when you stop and think about it 3.5MhZ is still bloody fast switching by anyones money.
  • Directly sharing memory probably isn't an option, Z80 is too "chatty" on the bus and, in any case, lacks the kinds of atomic instructions really needed to implement the necessary synchronisation primitives required to prevent corruption due to race conditions. Doing something more like the 1541 on the C64, where the two CPUs are disconnected and use a serial (or parallel) interface to communicate is certainly possible but I suspect of questionable value unless the secondary CPU and comms protocol is based around a very specific use case.
    Thanked by 1mik3d3nch
  • There's a big question to ask which is "what would be the point".

    Building a Z80 based multi-processor system might be an interesting project (as a project for its own sake) but starting out with a spectrum seems pointless to me. You probably wouldn't end up with something that's recognisable or usable as a spectrum by the end so why not start from scratch with no constraints?
    My rubbish website including the redrawn Amstrad schematics and the new home of the Sinclair FAQ wiki.
    Thanked by 1mik3d3nch
  • The Bus request and bus acknowledge controls mean it is possible for more than one Z80 CPU to share a common memory and / or IO area. However, it's not going to be much faster, as only one of the CPUs can be doing any useful work at a time.

    If you now give each CPU some memory of it's own, and add isolating circuitry (lots of tri-state buffers), then a control CPU can dish out instructions and data for the other CPUs to work with. If done correctly, this can offer a fair bit of speed to some applications.

    But, and this is the problem, software has to be written to use this arrangement. As as there will only ever be a very limited number of these made and used, there is little incentive for much software to be written to make use of it.

    And this would be more expensive than redesigning a system to use a more modern, faster CPU with much faster memory...

    Mark
    Thanked by 1mik3d3nch
  • 1024MAK wrote: »
    If you now give each CPU some memory of it's own, and add isolating circuitry (lots of tri-state buffers), then a control CPU can dish out instructions and data for the other CPUs to work with. If done correctly, this can offer a fair bit of speed to some applications.Mark

    Presumably that's how things like the Galaga coin-op can work, then? With each Z80 connected to its own seperate ROM chip to run code from, but sharing a common small chunk of RAM?

    On the general point, though, more is always better, lol. Why not have two or three CPUs, if we can :)

    Just a thought, would it be possible to build a system with a BBC B type arrangment using, say 7mhz RAM but with each 3.5mhz Z80 taking alternate clocks? That would be fun to fiddle around with.

    M
    Thanked by 1mik3d3nch
  • The relationship between the clock and the operations of a Z80 is complex, unlike a 6502 CPU, where it only controls the bus when the phase 2 clock is high. With the 6502's architecture, it's possible to have two 6502 CPUs running on alternate clock phases...

    However, trying to do this with two Z80 CPUs requires lots of support circuity, as each Z80 CPU has to be synchronised. Z80 instructions take anything from 4 T states (clock cycles) up to 23 T states (clock cycles). And the Z80 does not release the bus on set even or odd clock cycles. Indeed, for I/O instructions, automatic wait cycles are added. Further, when possible, the Z80 fetches the next instruction while finishing the last part of the current instruction... Also, after the instruction fetch, while decoding or processing the instruction, it outputs a refresh address to memory to refresh Dynamic RAM chip memory.

    Worse, if you were to synchronise a Z80 CPU, this actually means slowing it down slightly :-(

    Mark
    Thanked by 1mik3d3nch
  • Z80 instruction timing and effects when a wait has to be added... http://map.grauw.nl/resources/z80instr.php

    Mark
  • I don't think trying to share a bus is the way to go about building a multi-Z80 system. Something more like old arcade boards where one Z80 is in charge of sound production and another running the main game, with only minimal interaction between the two, is really the way you'd want to design things. It's just not something you can usefully add-on as an afterthought to an existing design like the Spectrum. Sometimes less is more and trying to shoehorn it onto an existing design is most likely to just trade away all the advantage (and possibly more) trying to synchronise the two CPUs.
    Thanked by 1mik3d3nch
  • edited December 2016
    1024MAK wrote: »
    However, trying to do this with two Z80 CPUs requires lots of support circuity, as each Z80 CPU has to be synchronised. Z80 instructions take anything from 4 T states (clock cycles) up to 23 T states (clock cycles). And the Z80 does not release the bus on set even or odd clock cycles. Indeed, for I/O instructions, automatic wait cycles are added. Further, when possible, the Z80 fetches the next instruction while finishing the last part of the current instruction... Also, after the instruction fetch, while decoding or processing the instruction, it outputs a refresh address to memory to refresh Dynamic RAM chip memory.

    Worse, if you were to synchronise a Z80 CPU, this actually means slowing it down slightly :-(

    Mark

    With all that hassle, it makes me wonder why the designers working at Namco and such bothered with complex multi-CPU boards. What advantage are they getting out of it that's worth all the effort? Why not just use a single, but faster clocked chip? Memory speeds, possibly?

    M
    Post edited by Mysterion on
  • Mysterion wrote: »
    1024MAK wrote: »
    However, trying to do this with two Z80 CPUs requires lots of support circuity, as each Z80 CPU has to be synchronised. Z80 instructions take anything from 4 T states (clock cycles) up to 23 T states (clock cycles). And the Z80 does not release the bus on set even or odd clock cycles. Indeed, for I/O instructions, automatic wait cycles are added. Further, when possible, the Z80 fetches the next instruction while finishing the last part of the current instruction... Also, after the instruction fetch, while decoding or processing the instruction, it outputs a refresh address to memory to refresh Dynamic RAM chip memory.

    Worse, if you were to synchronise a Z80 CPU, this actually means slowing it down slightly :-(

    Mark

    With all that hassle, it makes me wonder why the designers working at Namco and such bothered with complex multi-CPU boards. What advantage are they getting out of it that's worth all the effort? Why not just use a single, but faster clocked chip? Memory speeds, possibly?

    M

    Memory speeds lagged for a loooong time, and if higher clocked cpus existed, they were probably way more expensive than using several "normal" ones.

    Today, CPUs are the most expensive single piece of circuitry in your computer, but back in the day they put the same CPU on the c64 disk drive as they have on the computer.. could you imagine your floppy drive including a core-i7? =)
    http://iki.fi/sol | http://iki.fi/sol/speccy/ | https://github.com/jarikomppa/speccy
    http://goo.gl/q2j0NZ - make ZX Spectrum choose your own adventure games, no programming needed (release 3)
  • With arcade boards, more than one CPU made sense, as each was dedicated to a particular function or task, each with its own ROM and RAM. So no common memory bus to hold things up.

    In the same way, in some later 1980's and thereafter computers, you will actually find the system has extra MPUs or microcontrollers, for example to handle the keyboard (QL, IBM PCs, Atari ST etc...)

    Mark
  • Thanks to everyone who took the time and trouble to try and answer my enquiry without taking the mickey as its pretty obvious my knowledge of what goes on under the hood is pretty abysmal

    The reason I posed that speculative enquiry is that many years ago, (decades?) i got contacted by SETI (I think thats the group).inviting me and anyone else to allow them to install software on my computer and leave it switched on at night because somehow they were trying to combine lots of personal computers to aid in their search.

    I have no idea if it worked or what if anything was gained by this experiment and naturally I was pretty suspicious at first thinking this was an ideal way to get a really nasty virus or worse but after a month or two I switched machines and didnt try and get back into the network or whatever it was.

    I did vaguely recall having been given a link to the main site which gave an explanation of what they hoped to achieve and how it was supposed to work, after all with an eclectic mix of PC's how the hell could any software pull that lot together to achieve something useful? If I remember rightly I was on a summer internship at NASA at the time which is how I learned about the project and that memory is what sparked this idea.
  • edited December 2016
    SETI (Search for Extra-Terrestrial Intelligence) have a screen-saver that does its work whenever you're not using the computer. They're looking for signs of intelligent signals in data they collect from space using radio telescopes when they're not in use either.

    It's not really doing anything particularly clever with shared processing power. It simply downloads a chunk of signal data to you for your computer to analyse. Your computer then sends back its results and asks for another chunk to work on. A central server sees that everyone gets to work on a different bit of data, so it doesn't matter if one machine takes longer than another to finish.

    There are similar 'shared' projects that try to solve complex problems by just running through all the possible answers ('brute force' approach), such as one researching chemical compounds to use as cancer drugs. Some turn them into games, such as the 3D puzzle that is protein folding.
    Post edited by joefish on
    Joefish
    - IONIAN-GAMES.com -
  • edited December 2016
    The problem with multiple processors on 8-bit machines is you'd spend so long trying to juggle the contention or communication between the processors, you'd have no time left to do anything.

    As has been mentioned already, you could give a second processor a specific job (such as sound) and give it its own memory and program code, and just communicate with it over a simple bus to send it one of a few pre-arranged commands. But then if it's a particular task you have in mind (e.g. sound) then you might as well just use a sound chip instead.

    Some computers had co-processors to do floating-point maths, which could work in parallel, but in practice by the time you'd told it what to do it was ready to give you the answer, so you were just relying on it coming up with the result quicker than the main processor for the speed-up. You weren't practically doing anything on the main processor while the co-processor did its thing.

    In fact, writing code for multiple processors (like you have now with multi-core processors) to ensure that they all have something to do but don't fight over memory or get out of step, is extremely difficult indeed. It requires an extra layer of control functions, which always runs the risk of slowing things down more than you gain in speed from having multiple processors.
    Post edited by joefish on
    Joefish
    - IONIAN-GAMES.com -
    Thanked by 1mik3d3nch
  • Thanks Joe, good explanation.
  • wilsonsamm wrote: »
    The Timex FDD system had its own Z80 as well and only used the Speccy for keyboard I/O and generating the display.?
    Ah yes, like the 1541 disk drive with the Commodore computers. People had these do on-the-fly compression/decompression as they read/wrote the disk, IIRC. Is it possible to have the Timex FFD run your own software?
    On the other hand, if you reduce the Speccy to working as a dumb terminal does it still count?
    I suppose so, but why would you? The point is to expand the capabilities of the ZX Spectrum :-) If you add another dozen Z80s, then the primary CPU still works, so why not use it to do calculations? I picture such setups using the first CPU to delegate tasks to the other CPUs.

    Why not just have a Z80 FPU and DMA? I dont think the Z80 have work in parallel with another Z80 tbh
Sign In or Register to comment.