TL;DR: this longish answer address the "mystic" property of the question; i.e., the sense of wonder about how this could be possible; not the actual workings of the specific components.
The gory details have been given in other answers, but here is a broader outlook on the issue:
Remember that in that time, computers (certainly home computers) were, compared to today, very simple things. For example, at the days of the 8 bit computers like Atari 800XL, C64 and so on, it was not unheard of for a kid to own a big book which not only had the complete schematic of the whole computer, but also in such great detail that you could literally "see" and eventually comprehend every single detail right into the deepest depths of it.
There were many discrete parts (e.g., many logic chips of the 74xx family) which in themselves were very easy to understand. The most complex item was the CPU, the separate video chip, and the separate sound chip, but every one of these items was of very finite complexity. You could easily get a 100% intuitive understanding of any of them; their whole functional and internal description would fit into a not too thick physical paper book each.
In that time, if you did things like plug a different processor (card) into a computer, if you had the documentation of what it did, you could readily trace the electrical connection and see where what took place. Another example; you could retrofit one of those 8bit computers with an enormous amount of RAM (256KB, making it a total of unbelievable 320KB of RAM, albeit with heavy paging involved); and here also the actual mechanism was right in front of your eyes, in plain sight, even if those computers didn't even had provisions to fit additional RAM, coming from the factory. One would directly solder the RAM expansion to the actual CPU pins (or PCB traces).
This was very different from today where individual systems-on-a-chip are very much incomprehensible, and even a complete description of their outward interface would take not a single book, but whole libraries, if printed out on paper.
Finally, back then there was no OS to speak of; while they already had something vaguely akin to a BIOS, using it was almost optional (when you were programming at the assembler/machine code level, which was very much achievable by kids teaching themselves from paper books). There was no user/kernel-space distinction, no memory protection, no virtualization, nothing of that kind. Even in BASIC, it would not take long until you used PEEK and POKE to manipulate the whole RAM and especially control registers, the video chip etc., directly and freely.
Reading this book means I can imagine building a CPU out of logic gates and logic components, but can't imagine how you would switch control from one to another.
But this is what happens every day when multiple MCUs communicate. For example, even on the arguably simplest bus around, the I2C bus, which uses only two wires, there is a very well defined protocol of who gets to talk when, which even allows multiple masters at the same time.
Scale that up to your question, and it is a simple matter to craft a protocol where one of the CPUs more or less "shuts up" and waits until it gets signaled to pick up work again. It could be as simple as each CPU having an "enable" pin, and a simple discrete logic, probably involving a flipflop, making sure that only one CPU is enabled at any one time. There certainly is no magic about this; and yes, if by chance both CPUs were active at the same time, things would go wrong quickly, there certainly was true no multiprocessing back then, in home computers.
(Or vice versa - plugging an Intel card into a Mac and running Windows programs on the hardware.) That actually exists Here you can see an example
– ACGuy Jan 09 '17 at 11:16