How did people program for Consoles with multiple CPUs? The Next CEO of Stack OverflowHow were analytics gathered on software built for retrocomputing platforms?Did Apple not originally allow anyone to develop software for the Macintosh?How did software engineers test their code in 19xx?Did any major corporation ever successfully sue Microsoft for intellectual property theft?Instruction set support for multiplication with a constantBack in the late 1980s, how was commercial software for 8-bit home computers developed?Why did some CPUs use two Read/Write lines, and others just one?

Why don't programming languages automatically manage the synchronous/asynchronous problem?

What steps are necessary to read a Modern SSD in Medieval Europe?

Rotate a column

Example of a Mathematician/Physicist whose Other Publications during their PhD eclipsed their PhD Thesis

Powershell. How to parse gci Name?

Running a General Election and the European Elections together

How to place nodes around a circle from some initial angle?

Is there a difference between "Fahrstuhl" and "Aufzug"

Which one is the true statement?

Why does standard notation not preserve intervals (visually)

How to avoid supervisors with prejudiced views?

If Nick Fury and Coulson already knew about aliens (Kree and Skrull) why did they wait until Thor's appearance to start making weapons?

Why didn't Khan get resurrected in the Genesis Explosion?

Why the difference in type-inference over the as-pattern in two similar function definitions?

How to get from Geneva Airport to Metabief?

Is it possible to replace duplicates of a character with one character using tr

Does Germany produce more waste than the US?

What does "Its cash flow is deeply negative" mean?

Is it convenient to ask the journal's editor for two additional days to complete a review?

Some questions about different axiomatic systems for neighbourhoods

Dominated convergence theorem - what sequence?

Would a completely good Muggle be able to use a wand?

Help understanding this unsettling image of Titan, Epimetheus, and Saturn's rings?

Why isn't the Mueller report being released completely and unredacted?



How did people program for Consoles with multiple CPUs?



The Next CEO of Stack OverflowHow were analytics gathered on software built for retrocomputing platforms?Did Apple not originally allow anyone to develop software for the Macintosh?How did software engineers test their code in 19xx?Did any major corporation ever successfully sue Microsoft for intellectual property theft?Instruction set support for multiplication with a constantBack in the late 1980s, how was commercial software for 8-bit home computers developed?Why did some CPUs use two Read/Write lines, and others just one?










28















I'm specifically interested in the Sega Mega Drive/Genesis, which used a 68000 CPU, but also a Z80, mainly used to control the sound hardware and provide backward compatibility with the Master System.



There was also the Atari Jaguar, with it's Tom and Jerry RISC chips, the Sega Saturn, Featuring a total of eight processors, and probably a lot more.



When writing code (assuming ASM), how would these additional processors be used/accessed? Did one write regular 68000 code (even for sound) and the 68000 itself handled talking to the Z80? Did one need to write two different programs, one for each CPU? If yes, how did they communicate with each other? Or is memory mapping used, which would require a binary that has both 68000 and Z80 instructions in them, making sure that the Z80 code is in a specific memory region?



(This isn't about "regular" multi-processing, like on newer consoles with multi-core CPUs that are all the same. This is about consoles with a main CPU and specialized co-processors for e.g., Sound. Basically, the Sega Genesis, though I'm looking at building my own custom system, so I'm more interested in the basic principles.)










share|improve this question







New contributor




Michael Stum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.















  • 3





    "CPU" probably isn't the best term here, though I'm not certain what the idiomatic one of the time is; while you could have a 68k and a Z80, it was also common to see more specialized support chips. The general concept is called asymmetric multiprocessing.

    – chrylis
    yesterday







  • 1





    Although not a console, in the 1980's, the ATR8000 was a Z80 CP/M system that had an option of replacing the socketed Z80 with a socketed small board that contained a Z80 and a 8088 and 512KB of ram. The 8088 could run MSDOS 2.11, using the Z80 to interface with the peripherals, floppy disks, serial port, printer, and a second serial port used for the ASCII terminal. In CP/M mode, the 512KB of ram could be used as a ramdisk. There was an 8 bit bus used to communicate between the Z80 and the 8088.

    – rcgldr
    yesterday






  • 1





    The ATR8000 could also be used with an 8 bit Atari 400/800/65XE/130XE, with the Atari used as a terminal, or with the ATR8000 used as a peripheral controller for the Atari, adding a 6502 cpu into the mix, although even if present, the 8088 would not be used if using the ATR8000 as an Atari controller.

    – rcgldr
    yesterday






  • 1





    Fun fact: New Phones have a similar model; they have a set of several processors of varying power needs/capabilities (at face value, to keep lower-need tasks on lower-power cores to save battery life). Could be worth looking into those for a modern approach to the given problem. IIRC in phones' case, though, it's all handled by the OS.

    – Delioth
    yesterday







  • 2





    @Delioth While new phones have multiple cores of different speed (i.e. big.LITTLE), they all run the exact same ISA and are completely coherent, so it is transparent to the programmer. The modern equivalent to this problem is more like GPU vs CPU computing.

    – user71659
    18 hours ago















28















I'm specifically interested in the Sega Mega Drive/Genesis, which used a 68000 CPU, but also a Z80, mainly used to control the sound hardware and provide backward compatibility with the Master System.



There was also the Atari Jaguar, with it's Tom and Jerry RISC chips, the Sega Saturn, Featuring a total of eight processors, and probably a lot more.



When writing code (assuming ASM), how would these additional processors be used/accessed? Did one write regular 68000 code (even for sound) and the 68000 itself handled talking to the Z80? Did one need to write two different programs, one for each CPU? If yes, how did they communicate with each other? Or is memory mapping used, which would require a binary that has both 68000 and Z80 instructions in them, making sure that the Z80 code is in a specific memory region?



(This isn't about "regular" multi-processing, like on newer consoles with multi-core CPUs that are all the same. This is about consoles with a main CPU and specialized co-processors for e.g., Sound. Basically, the Sega Genesis, though I'm looking at building my own custom system, so I'm more interested in the basic principles.)










share|improve this question







New contributor




Michael Stum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.















  • 3





    "CPU" probably isn't the best term here, though I'm not certain what the idiomatic one of the time is; while you could have a 68k and a Z80, it was also common to see more specialized support chips. The general concept is called asymmetric multiprocessing.

    – chrylis
    yesterday







  • 1





    Although not a console, in the 1980's, the ATR8000 was a Z80 CP/M system that had an option of replacing the socketed Z80 with a socketed small board that contained a Z80 and a 8088 and 512KB of ram. The 8088 could run MSDOS 2.11, using the Z80 to interface with the peripherals, floppy disks, serial port, printer, and a second serial port used for the ASCII terminal. In CP/M mode, the 512KB of ram could be used as a ramdisk. There was an 8 bit bus used to communicate between the Z80 and the 8088.

    – rcgldr
    yesterday






  • 1





    The ATR8000 could also be used with an 8 bit Atari 400/800/65XE/130XE, with the Atari used as a terminal, or with the ATR8000 used as a peripheral controller for the Atari, adding a 6502 cpu into the mix, although even if present, the 8088 would not be used if using the ATR8000 as an Atari controller.

    – rcgldr
    yesterday






  • 1





    Fun fact: New Phones have a similar model; they have a set of several processors of varying power needs/capabilities (at face value, to keep lower-need tasks on lower-power cores to save battery life). Could be worth looking into those for a modern approach to the given problem. IIRC in phones' case, though, it's all handled by the OS.

    – Delioth
    yesterday







  • 2





    @Delioth While new phones have multiple cores of different speed (i.e. big.LITTLE), they all run the exact same ISA and are completely coherent, so it is transparent to the programmer. The modern equivalent to this problem is more like GPU vs CPU computing.

    – user71659
    18 hours ago













28












28








28


4






I'm specifically interested in the Sega Mega Drive/Genesis, which used a 68000 CPU, but also a Z80, mainly used to control the sound hardware and provide backward compatibility with the Master System.



There was also the Atari Jaguar, with it's Tom and Jerry RISC chips, the Sega Saturn, Featuring a total of eight processors, and probably a lot more.



When writing code (assuming ASM), how would these additional processors be used/accessed? Did one write regular 68000 code (even for sound) and the 68000 itself handled talking to the Z80? Did one need to write two different programs, one for each CPU? If yes, how did they communicate with each other? Or is memory mapping used, which would require a binary that has both 68000 and Z80 instructions in them, making sure that the Z80 code is in a specific memory region?



(This isn't about "regular" multi-processing, like on newer consoles with multi-core CPUs that are all the same. This is about consoles with a main CPU and specialized co-processors for e.g., Sound. Basically, the Sega Genesis, though I'm looking at building my own custom system, so I'm more interested in the basic principles.)










share|improve this question







New contributor




Michael Stum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












I'm specifically interested in the Sega Mega Drive/Genesis, which used a 68000 CPU, but also a Z80, mainly used to control the sound hardware and provide backward compatibility with the Master System.



There was also the Atari Jaguar, with it's Tom and Jerry RISC chips, the Sega Saturn, Featuring a total of eight processors, and probably a lot more.



When writing code (assuming ASM), how would these additional processors be used/accessed? Did one write regular 68000 code (even for sound) and the 68000 itself handled talking to the Z80? Did one need to write two different programs, one for each CPU? If yes, how did they communicate with each other? Or is memory mapping used, which would require a binary that has both 68000 and Z80 instructions in them, making sure that the Z80 code is in a specific memory region?



(This isn't about "regular" multi-processing, like on newer consoles with multi-core CPUs that are all the same. This is about consoles with a main CPU and specialized co-processors for e.g., Sound. Basically, the Sega Genesis, though I'm looking at building my own custom system, so I'm more interested in the basic principles.)







software-development cpu sega-genesis






share|improve this question







New contributor




Michael Stum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question







New contributor




Michael Stum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question






New contributor




Michael Stum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 2 days ago









Michael StumMichael Stum

24135




24135




New contributor




Michael Stum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Michael Stum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Michael Stum is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.







  • 3





    "CPU" probably isn't the best term here, though I'm not certain what the idiomatic one of the time is; while you could have a 68k and a Z80, it was also common to see more specialized support chips. The general concept is called asymmetric multiprocessing.

    – chrylis
    yesterday







  • 1





    Although not a console, in the 1980's, the ATR8000 was a Z80 CP/M system that had an option of replacing the socketed Z80 with a socketed small board that contained a Z80 and a 8088 and 512KB of ram. The 8088 could run MSDOS 2.11, using the Z80 to interface with the peripherals, floppy disks, serial port, printer, and a second serial port used for the ASCII terminal. In CP/M mode, the 512KB of ram could be used as a ramdisk. There was an 8 bit bus used to communicate between the Z80 and the 8088.

    – rcgldr
    yesterday






  • 1





    The ATR8000 could also be used with an 8 bit Atari 400/800/65XE/130XE, with the Atari used as a terminal, or with the ATR8000 used as a peripheral controller for the Atari, adding a 6502 cpu into the mix, although even if present, the 8088 would not be used if using the ATR8000 as an Atari controller.

    – rcgldr
    yesterday






  • 1





    Fun fact: New Phones have a similar model; they have a set of several processors of varying power needs/capabilities (at face value, to keep lower-need tasks on lower-power cores to save battery life). Could be worth looking into those for a modern approach to the given problem. IIRC in phones' case, though, it's all handled by the OS.

    – Delioth
    yesterday







  • 2





    @Delioth While new phones have multiple cores of different speed (i.e. big.LITTLE), they all run the exact same ISA and are completely coherent, so it is transparent to the programmer. The modern equivalent to this problem is more like GPU vs CPU computing.

    – user71659
    18 hours ago












  • 3





    "CPU" probably isn't the best term here, though I'm not certain what the idiomatic one of the time is; while you could have a 68k and a Z80, it was also common to see more specialized support chips. The general concept is called asymmetric multiprocessing.

    – chrylis
    yesterday







  • 1





    Although not a console, in the 1980's, the ATR8000 was a Z80 CP/M system that had an option of replacing the socketed Z80 with a socketed small board that contained a Z80 and a 8088 and 512KB of ram. The 8088 could run MSDOS 2.11, using the Z80 to interface with the peripherals, floppy disks, serial port, printer, and a second serial port used for the ASCII terminal. In CP/M mode, the 512KB of ram could be used as a ramdisk. There was an 8 bit bus used to communicate between the Z80 and the 8088.

    – rcgldr
    yesterday






  • 1





    The ATR8000 could also be used with an 8 bit Atari 400/800/65XE/130XE, with the Atari used as a terminal, or with the ATR8000 used as a peripheral controller for the Atari, adding a 6502 cpu into the mix, although even if present, the 8088 would not be used if using the ATR8000 as an Atari controller.

    – rcgldr
    yesterday






  • 1





    Fun fact: New Phones have a similar model; they have a set of several processors of varying power needs/capabilities (at face value, to keep lower-need tasks on lower-power cores to save battery life). Could be worth looking into those for a modern approach to the given problem. IIRC in phones' case, though, it's all handled by the OS.

    – Delioth
    yesterday







  • 2





    @Delioth While new phones have multiple cores of different speed (i.e. big.LITTLE), they all run the exact same ISA and are completely coherent, so it is transparent to the programmer. The modern equivalent to this problem is more like GPU vs CPU computing.

    – user71659
    18 hours ago







3




3





"CPU" probably isn't the best term here, though I'm not certain what the idiomatic one of the time is; while you could have a 68k and a Z80, it was also common to see more specialized support chips. The general concept is called asymmetric multiprocessing.

– chrylis
yesterday






"CPU" probably isn't the best term here, though I'm not certain what the idiomatic one of the time is; while you could have a 68k and a Z80, it was also common to see more specialized support chips. The general concept is called asymmetric multiprocessing.

– chrylis
yesterday





1




1





Although not a console, in the 1980's, the ATR8000 was a Z80 CP/M system that had an option of replacing the socketed Z80 with a socketed small board that contained a Z80 and a 8088 and 512KB of ram. The 8088 could run MSDOS 2.11, using the Z80 to interface with the peripherals, floppy disks, serial port, printer, and a second serial port used for the ASCII terminal. In CP/M mode, the 512KB of ram could be used as a ramdisk. There was an 8 bit bus used to communicate between the Z80 and the 8088.

– rcgldr
yesterday





Although not a console, in the 1980's, the ATR8000 was a Z80 CP/M system that had an option of replacing the socketed Z80 with a socketed small board that contained a Z80 and a 8088 and 512KB of ram. The 8088 could run MSDOS 2.11, using the Z80 to interface with the peripherals, floppy disks, serial port, printer, and a second serial port used for the ASCII terminal. In CP/M mode, the 512KB of ram could be used as a ramdisk. There was an 8 bit bus used to communicate between the Z80 and the 8088.

– rcgldr
yesterday




1




1





The ATR8000 could also be used with an 8 bit Atari 400/800/65XE/130XE, with the Atari used as a terminal, or with the ATR8000 used as a peripheral controller for the Atari, adding a 6502 cpu into the mix, although even if present, the 8088 would not be used if using the ATR8000 as an Atari controller.

– rcgldr
yesterday





The ATR8000 could also be used with an 8 bit Atari 400/800/65XE/130XE, with the Atari used as a terminal, or with the ATR8000 used as a peripheral controller for the Atari, adding a 6502 cpu into the mix, although even if present, the 8088 would not be used if using the ATR8000 as an Atari controller.

– rcgldr
yesterday




1




1





Fun fact: New Phones have a similar model; they have a set of several processors of varying power needs/capabilities (at face value, to keep lower-need tasks on lower-power cores to save battery life). Could be worth looking into those for a modern approach to the given problem. IIRC in phones' case, though, it's all handled by the OS.

– Delioth
yesterday






Fun fact: New Phones have a similar model; they have a set of several processors of varying power needs/capabilities (at face value, to keep lower-need tasks on lower-power cores to save battery life). Could be worth looking into those for a modern approach to the given problem. IIRC in phones' case, though, it's all handled by the OS.

– Delioth
yesterday





2




2





@Delioth While new phones have multiple cores of different speed (i.e. big.LITTLE), they all run the exact same ISA and are completely coherent, so it is transparent to the programmer. The modern equivalent to this problem is more like GPU vs CPU computing.

– user71659
18 hours ago





@Delioth While new phones have multiple cores of different speed (i.e. big.LITTLE), they all run the exact same ISA and are completely coherent, so it is transparent to the programmer. The modern equivalent to this problem is more like GPU vs CPU computing.

– user71659
18 hours ago










2 Answers
2






active

oldest

votes


















34














It varies machine to machine; at the simplest end is the Neo Geo — its 68000 and Z80 have completely independent buses. You write one program for the 68000 and one for the Z80 and a single pipe of communication joins the two: post a byte to the Z80 and it'll trigger an NMI; the Z80 can read the command byte from a certain port and write a response to another, the 68000 can poll for the response. Neo Geo also supplied a sample set of Z80 code so you could just treat it as an advanced sound generator and not worry about the implementation if you prefer.



The Mega Drive has a more complicated system of shared buses; the Z80 has some memory on a private bus but the cartridge bus is a shared resource and I think the Z80 can also share some RAM. In that system the VDP can also act as a bus master so in net it's the Z80 getting access to the shared resources only when nobody else is attempting an access, the 68000 having priority only when it doesn't chose to start a VDP transfer, and the VDP having top priority for those periods when the 68000 has command it to do something.



If you ever hear scratchy sampled audio in a Mega Drive game then it's likely to be the Z80 trying to stream from the cartridge but frequently losing out on access slots.



The Saturn is like a more advanced Mega Drive except that the main CPUs have caches that can also be configured as small local memory pools. So if you're careful you can mostly keep them off the shared bus, gaining a significant performance benefit — Virtua Fighter 2 manages to keep most of the data for each player local to a single CPU for most of a frame, the laziest PlayStation ports do nothing in particular and either end up only using a single CPU or effectively doing so as a result of collection.



The Jaguar is supposed to work similarly to the Saturn but, quelle surprise, Atari rushed it to market so there's a significant bug affecting the RISC CPU's accesses to RAM when performing certain types of jump. That's how it often ends up being treated as a machine with a 68000 central processor when really the 68000 was intended just to be an intelligent scheduler.



So: across these systems one generally writes a different program for each processor, and either nominates one as a coordinator or uses a series of ad hoc means of point-to-point communication.



If it sounds hard to get right, that's because it is — programmers much prefer systems like the original PlayStation with a single CPU that just goes quickly.






share|improve this answer






























    8














    There are two basic techniques: shared memory and dedicated communication ports.



    Shared memory simply allows both processors to access the same memory bus. There are some issues, as the bus has to be shared and one CPU has to get priority so code must be designed to take unpredictable extra delays into account. The Megadrive is a good example of that, with the Z80 CPU losing cycles to the 68000 and the graphics subsystem.



    It's actually a quite awkward system but they wanted the Z80 for backwards compatibility with Master System games. The system has a dedicated sound chip and the overhead for playing back music and sound effects is so low that there is little benefit to offloading it from the 68000.



    The other issue with shared memory is that if one CPU is writing to it while the other is reading it, the reading CPU can end up with corrupt data. Therefore some kind of arbitration is needed, often based on atomic update operations.



    Communication ports allow two CPUs on separate buses to communicate. Each CPU has its own bus, its own RAM, its own peripherals and a single I/O port that lets it communicate with the other CPU(s). The port usually allows commands and small amounts of data to be sent, often one way, from one CPU to another and an acknowledgement to be sent back. The Neo Geo is an example of a system that works that, or more common in the west was BBC Micro with its optional second processor via the "tube".



    Software for each CPU was written and debugged separately.






    share|improve this answer























      Your Answer








      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "648"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader:
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      ,
      noCode: true, onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );






      Michael Stum is a new contributor. Be nice, and check out our Code of Conduct.









      draft saved

      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9458%2fhow-did-people-program-for-consoles-with-multiple-cpus%23new-answer', 'question_page');

      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      34














      It varies machine to machine; at the simplest end is the Neo Geo — its 68000 and Z80 have completely independent buses. You write one program for the 68000 and one for the Z80 and a single pipe of communication joins the two: post a byte to the Z80 and it'll trigger an NMI; the Z80 can read the command byte from a certain port and write a response to another, the 68000 can poll for the response. Neo Geo also supplied a sample set of Z80 code so you could just treat it as an advanced sound generator and not worry about the implementation if you prefer.



      The Mega Drive has a more complicated system of shared buses; the Z80 has some memory on a private bus but the cartridge bus is a shared resource and I think the Z80 can also share some RAM. In that system the VDP can also act as a bus master so in net it's the Z80 getting access to the shared resources only when nobody else is attempting an access, the 68000 having priority only when it doesn't chose to start a VDP transfer, and the VDP having top priority for those periods when the 68000 has command it to do something.



      If you ever hear scratchy sampled audio in a Mega Drive game then it's likely to be the Z80 trying to stream from the cartridge but frequently losing out on access slots.



      The Saturn is like a more advanced Mega Drive except that the main CPUs have caches that can also be configured as small local memory pools. So if you're careful you can mostly keep them off the shared bus, gaining a significant performance benefit — Virtua Fighter 2 manages to keep most of the data for each player local to a single CPU for most of a frame, the laziest PlayStation ports do nothing in particular and either end up only using a single CPU or effectively doing so as a result of collection.



      The Jaguar is supposed to work similarly to the Saturn but, quelle surprise, Atari rushed it to market so there's a significant bug affecting the RISC CPU's accesses to RAM when performing certain types of jump. That's how it often ends up being treated as a machine with a 68000 central processor when really the 68000 was intended just to be an intelligent scheduler.



      So: across these systems one generally writes a different program for each processor, and either nominates one as a coordinator or uses a series of ad hoc means of point-to-point communication.



      If it sounds hard to get right, that's because it is — programmers much prefer systems like the original PlayStation with a single CPU that just goes quickly.






      share|improve this answer



























        34














        It varies machine to machine; at the simplest end is the Neo Geo — its 68000 and Z80 have completely independent buses. You write one program for the 68000 and one for the Z80 and a single pipe of communication joins the two: post a byte to the Z80 and it'll trigger an NMI; the Z80 can read the command byte from a certain port and write a response to another, the 68000 can poll for the response. Neo Geo also supplied a sample set of Z80 code so you could just treat it as an advanced sound generator and not worry about the implementation if you prefer.



        The Mega Drive has a more complicated system of shared buses; the Z80 has some memory on a private bus but the cartridge bus is a shared resource and I think the Z80 can also share some RAM. In that system the VDP can also act as a bus master so in net it's the Z80 getting access to the shared resources only when nobody else is attempting an access, the 68000 having priority only when it doesn't chose to start a VDP transfer, and the VDP having top priority for those periods when the 68000 has command it to do something.



        If you ever hear scratchy sampled audio in a Mega Drive game then it's likely to be the Z80 trying to stream from the cartridge but frequently losing out on access slots.



        The Saturn is like a more advanced Mega Drive except that the main CPUs have caches that can also be configured as small local memory pools. So if you're careful you can mostly keep them off the shared bus, gaining a significant performance benefit — Virtua Fighter 2 manages to keep most of the data for each player local to a single CPU for most of a frame, the laziest PlayStation ports do nothing in particular and either end up only using a single CPU or effectively doing so as a result of collection.



        The Jaguar is supposed to work similarly to the Saturn but, quelle surprise, Atari rushed it to market so there's a significant bug affecting the RISC CPU's accesses to RAM when performing certain types of jump. That's how it often ends up being treated as a machine with a 68000 central processor when really the 68000 was intended just to be an intelligent scheduler.



        So: across these systems one generally writes a different program for each processor, and either nominates one as a coordinator or uses a series of ad hoc means of point-to-point communication.



        If it sounds hard to get right, that's because it is — programmers much prefer systems like the original PlayStation with a single CPU that just goes quickly.






        share|improve this answer

























          34












          34








          34







          It varies machine to machine; at the simplest end is the Neo Geo — its 68000 and Z80 have completely independent buses. You write one program for the 68000 and one for the Z80 and a single pipe of communication joins the two: post a byte to the Z80 and it'll trigger an NMI; the Z80 can read the command byte from a certain port and write a response to another, the 68000 can poll for the response. Neo Geo also supplied a sample set of Z80 code so you could just treat it as an advanced sound generator and not worry about the implementation if you prefer.



          The Mega Drive has a more complicated system of shared buses; the Z80 has some memory on a private bus but the cartridge bus is a shared resource and I think the Z80 can also share some RAM. In that system the VDP can also act as a bus master so in net it's the Z80 getting access to the shared resources only when nobody else is attempting an access, the 68000 having priority only when it doesn't chose to start a VDP transfer, and the VDP having top priority for those periods when the 68000 has command it to do something.



          If you ever hear scratchy sampled audio in a Mega Drive game then it's likely to be the Z80 trying to stream from the cartridge but frequently losing out on access slots.



          The Saturn is like a more advanced Mega Drive except that the main CPUs have caches that can also be configured as small local memory pools. So if you're careful you can mostly keep them off the shared bus, gaining a significant performance benefit — Virtua Fighter 2 manages to keep most of the data for each player local to a single CPU for most of a frame, the laziest PlayStation ports do nothing in particular and either end up only using a single CPU or effectively doing so as a result of collection.



          The Jaguar is supposed to work similarly to the Saturn but, quelle surprise, Atari rushed it to market so there's a significant bug affecting the RISC CPU's accesses to RAM when performing certain types of jump. That's how it often ends up being treated as a machine with a 68000 central processor when really the 68000 was intended just to be an intelligent scheduler.



          So: across these systems one generally writes a different program for each processor, and either nominates one as a coordinator or uses a series of ad hoc means of point-to-point communication.



          If it sounds hard to get right, that's because it is — programmers much prefer systems like the original PlayStation with a single CPU that just goes quickly.






          share|improve this answer













          It varies machine to machine; at the simplest end is the Neo Geo — its 68000 and Z80 have completely independent buses. You write one program for the 68000 and one for the Z80 and a single pipe of communication joins the two: post a byte to the Z80 and it'll trigger an NMI; the Z80 can read the command byte from a certain port and write a response to another, the 68000 can poll for the response. Neo Geo also supplied a sample set of Z80 code so you could just treat it as an advanced sound generator and not worry about the implementation if you prefer.



          The Mega Drive has a more complicated system of shared buses; the Z80 has some memory on a private bus but the cartridge bus is a shared resource and I think the Z80 can also share some RAM. In that system the VDP can also act as a bus master so in net it's the Z80 getting access to the shared resources only when nobody else is attempting an access, the 68000 having priority only when it doesn't chose to start a VDP transfer, and the VDP having top priority for those periods when the 68000 has command it to do something.



          If you ever hear scratchy sampled audio in a Mega Drive game then it's likely to be the Z80 trying to stream from the cartridge but frequently losing out on access slots.



          The Saturn is like a more advanced Mega Drive except that the main CPUs have caches that can also be configured as small local memory pools. So if you're careful you can mostly keep them off the shared bus, gaining a significant performance benefit — Virtua Fighter 2 manages to keep most of the data for each player local to a single CPU for most of a frame, the laziest PlayStation ports do nothing in particular and either end up only using a single CPU or effectively doing so as a result of collection.



          The Jaguar is supposed to work similarly to the Saturn but, quelle surprise, Atari rushed it to market so there's a significant bug affecting the RISC CPU's accesses to RAM when performing certain types of jump. That's how it often ends up being treated as a machine with a 68000 central processor when really the 68000 was intended just to be an intelligent scheduler.



          So: across these systems one generally writes a different program for each processor, and either nominates one as a coordinator or uses a series of ad hoc means of point-to-point communication.



          If it sounds hard to get right, that's because it is — programmers much prefer systems like the original PlayStation with a single CPU that just goes quickly.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 2 days ago









          TommyTommy

          15.8k14577




          15.8k14577





















              8














              There are two basic techniques: shared memory and dedicated communication ports.



              Shared memory simply allows both processors to access the same memory bus. There are some issues, as the bus has to be shared and one CPU has to get priority so code must be designed to take unpredictable extra delays into account. The Megadrive is a good example of that, with the Z80 CPU losing cycles to the 68000 and the graphics subsystem.



              It's actually a quite awkward system but they wanted the Z80 for backwards compatibility with Master System games. The system has a dedicated sound chip and the overhead for playing back music and sound effects is so low that there is little benefit to offloading it from the 68000.



              The other issue with shared memory is that if one CPU is writing to it while the other is reading it, the reading CPU can end up with corrupt data. Therefore some kind of arbitration is needed, often based on atomic update operations.



              Communication ports allow two CPUs on separate buses to communicate. Each CPU has its own bus, its own RAM, its own peripherals and a single I/O port that lets it communicate with the other CPU(s). The port usually allows commands and small amounts of data to be sent, often one way, from one CPU to another and an acknowledgement to be sent back. The Neo Geo is an example of a system that works that, or more common in the west was BBC Micro with its optional second processor via the "tube".



              Software for each CPU was written and debugged separately.






              share|improve this answer



























                8














                There are two basic techniques: shared memory and dedicated communication ports.



                Shared memory simply allows both processors to access the same memory bus. There are some issues, as the bus has to be shared and one CPU has to get priority so code must be designed to take unpredictable extra delays into account. The Megadrive is a good example of that, with the Z80 CPU losing cycles to the 68000 and the graphics subsystem.



                It's actually a quite awkward system but they wanted the Z80 for backwards compatibility with Master System games. The system has a dedicated sound chip and the overhead for playing back music and sound effects is so low that there is little benefit to offloading it from the 68000.



                The other issue with shared memory is that if one CPU is writing to it while the other is reading it, the reading CPU can end up with corrupt data. Therefore some kind of arbitration is needed, often based on atomic update operations.



                Communication ports allow two CPUs on separate buses to communicate. Each CPU has its own bus, its own RAM, its own peripherals and a single I/O port that lets it communicate with the other CPU(s). The port usually allows commands and small amounts of data to be sent, often one way, from one CPU to another and an acknowledgement to be sent back. The Neo Geo is an example of a system that works that, or more common in the west was BBC Micro with its optional second processor via the "tube".



                Software for each CPU was written and debugged separately.






                share|improve this answer

























                  8












                  8








                  8







                  There are two basic techniques: shared memory and dedicated communication ports.



                  Shared memory simply allows both processors to access the same memory bus. There are some issues, as the bus has to be shared and one CPU has to get priority so code must be designed to take unpredictable extra delays into account. The Megadrive is a good example of that, with the Z80 CPU losing cycles to the 68000 and the graphics subsystem.



                  It's actually a quite awkward system but they wanted the Z80 for backwards compatibility with Master System games. The system has a dedicated sound chip and the overhead for playing back music and sound effects is so low that there is little benefit to offloading it from the 68000.



                  The other issue with shared memory is that if one CPU is writing to it while the other is reading it, the reading CPU can end up with corrupt data. Therefore some kind of arbitration is needed, often based on atomic update operations.



                  Communication ports allow two CPUs on separate buses to communicate. Each CPU has its own bus, its own RAM, its own peripherals and a single I/O port that lets it communicate with the other CPU(s). The port usually allows commands and small amounts of data to be sent, often one way, from one CPU to another and an acknowledgement to be sent back. The Neo Geo is an example of a system that works that, or more common in the west was BBC Micro with its optional second processor via the "tube".



                  Software for each CPU was written and debugged separately.






                  share|improve this answer













                  There are two basic techniques: shared memory and dedicated communication ports.



                  Shared memory simply allows both processors to access the same memory bus. There are some issues, as the bus has to be shared and one CPU has to get priority so code must be designed to take unpredictable extra delays into account. The Megadrive is a good example of that, with the Z80 CPU losing cycles to the 68000 and the graphics subsystem.



                  It's actually a quite awkward system but they wanted the Z80 for backwards compatibility with Master System games. The system has a dedicated sound chip and the overhead for playing back music and sound effects is so low that there is little benefit to offloading it from the 68000.



                  The other issue with shared memory is that if one CPU is writing to it while the other is reading it, the reading CPU can end up with corrupt data. Therefore some kind of arbitration is needed, often based on atomic update operations.



                  Communication ports allow two CPUs on separate buses to communicate. Each CPU has its own bus, its own RAM, its own peripherals and a single I/O port that lets it communicate with the other CPU(s). The port usually allows commands and small amounts of data to be sent, often one way, from one CPU to another and an acknowledgement to be sent back. The Neo Geo is an example of a system that works that, or more common in the west was BBC Micro with its optional second processor via the "tube".



                  Software for each CPU was written and debugged separately.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered yesterday









                  useruser

                  3,795817




                  3,795817




















                      Michael Stum is a new contributor. Be nice, and check out our Code of Conduct.









                      draft saved

                      draft discarded


















                      Michael Stum is a new contributor. Be nice, and check out our Code of Conduct.












                      Michael Stum is a new contributor. Be nice, and check out our Code of Conduct.











                      Michael Stum is a new contributor. Be nice, and check out our Code of Conduct.














                      Thanks for contributing an answer to Retrocomputing Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9458%2fhow-did-people-program-for-consoles-with-multiple-cpus%23new-answer', 'question_page');

                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      រឿង រ៉ូមេអូ និង ហ្ស៊ុយលីយេ សង្ខេបរឿង តួអង្គ បញ្ជីណែនាំ

                      Crop image to path created in TikZ? Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)Crop an inserted image?TikZ pictures does not appear in posterImage behind and beyond crop marks?Tikz picture as large as possible on A4 PageTransparency vs image compression dilemmaHow to crop background from image automatically?Image does not cropTikzexternal capturing crop marks when externalizing pgfplots?How to include image path that contains a dollar signCrop image with left size given

                      Romeo and Juliet ContentsCharactersSynopsisSourcesDate and textThemes and motifsCriticism and interpretationLegacyScene by sceneSee alsoNotes and referencesSourcesExternal linksNavigation menu"Consumer Price Index (estimate) 1800–"10.2307/28710160037-3222287101610.1093/res/II.5.31910.2307/45967845967810.2307/2869925286992510.1525/jams.1982.35.3.03a00050"Dada Masilo: South African dancer who breaks the rules"10.1093/res/os-XV.57.1610.2307/28680942868094"Sweet Sorrow: Mann-Korman's Romeo and Juliet Closes Sept. 5 at MN's Ordway"the original10.2307/45957745957710.1017/CCOL0521570476.009"Ram Leela box office collections hit massive Rs 100 crore, pulverises prediction"Archived"Broadway Revival of Romeo and Juliet, Starring Orlando Bloom and Condola Rashad, Will Close Dec. 8"Archived10.1075/jhp.7.1.04hon"Wherefore art thou, Romeo? To make us laugh at Navy Pier"the original10.1093/gmo/9781561592630.article.O006772"Ram-leela Review Roundup: Critics Hail Film as Best Adaptation of Romeo and Juliet"Archived10.2307/31946310047-77293194631"Romeo and Juliet get Twitter treatment""Juliet's Nurse by Lois Leveen""Romeo and Juliet: Orlando Bloom's Broadway Debut Released in Theaters for Valentine's Day"Archived"Romeo and Juliet Has No Balcony"10.1093/gmo/9781561592630.article.O00778110.2307/2867423286742310.1076/enst.82.2.115.959510.1080/00138380601042675"A plague o' both your houses: error in GCSE exam paper forces apology""Juliet of the Five O'Clock Shadow, and Other Wonders"10.2307/33912430027-4321339124310.2307/28487440038-7134284874410.2307/29123140149-661129123144728341M"Weekender Guide: Shakespeare on The Drive""balcony"UK public library membership"romeo"UK public library membership10.1017/CCOL9780521844291"Post-Zionist Critique on Israel and the Palestinians Part III: Popular Culture"10.2307/25379071533-86140377-919X2537907"Capulets and Montagues: UK exam board admit mixing names up in Romeo and Juliet paper"Istoria Novellamente Ritrovata di Due Nobili Amanti2027/mdp.390150822329610820-750X"GCSE exam error: Board accidentally rewrites Shakespeare"10.2307/29176390149-66112917639"Exam board apologises after error in English GCSE paper which confused characters in Shakespeare's Romeo and Juliet""From Mariotto and Ganozza to Romeo and Guilietta: Metamorphoses of a Renaissance Tale"10.2307/37323537323510.2307/2867455286745510.2307/28678912867891"10 Questions for Taylor Swift"10.2307/28680922868092"Haymarket Theatre""The Zeffirelli Way: Revealing Talk by Florentine Director""Michael Smuin: 1938-2007 / Prolific dance director had showy career"The Life and Art of Edwin BoothRomeo and JulietRomeo and JulietRomeo and JulietRomeo and JulietEasy Read Romeo and JulietRomeo and Julieteeecb12003684p(data)4099369-3n8211610759dbe00d-a9e2-41a3-b2c1-977dd692899302814385X313670221313670221