Jarhmander wrote: ↑Tue Dec 08, 2020 5:42 am
How is the port pin $4016.2 wired between the CPUs? Is the one from the primary CPU directly wired to the IRQ line of the second CPU, and the $4016.2 port pin of the second CPU somehow connected to the primary CPU's IRQ line?
Assuming you mean "$4016.1", yes, exactly that, OUT1 on both CPUs is connected to /IRQ on the other CPU. The /IRQ pins are otherwise inaccessible.
Goose2k wrote: ↑Tue Dec 08, 2020 10:21 am
b) Is it safe to READ the shared memory even without first gaining "control" of the shared memory? Or is that needed for both WRITE and READ operations?
No, the RAM is only available to one CPU at a time, period.
c) What does "Primary CPU drives OUT1 high". I assume this means flip bit $2016.2 to 1? (I've just not heard the terms "drives OUT1 high" before)
$4016.1, in other words
LDA #2 / STA $4016. Is there another term that you would have already understood to mean that?
d) Would it not be valid to just constantly ping pong back and forth between the 2 cpus, rather than 1 CPU driving everything? eg. CPU 1 does what it needs to do, trigger IRQ on CPU2, CPU2 immediately does what it needs to do with shared RAM, triggers IRQ on CPU1, repeat forever. Perhaps this is wasteful of CPU time to be constantly triggering interrupts like this?
When will the CPUs do anything else? Keep in mind they still have to upload data to the PPU during vblanking, and the two PPUs will forever remain perfectly synchronized so both vblanks happen during the exact same moments: you'll really need to keep your OAM shadow and PPU update queue in non-shared memory.
e) How does this work when you have 2 different games in a dual system (eg. Mario on one side, Ice Climbers on the other)? I see this setup a lot, and it seems like the 2 games would have conflicting Shared RAM usage (eg. Mario stores coins at $6000, and Ice Climbers stores credits at $6000). Perhaps games that use shared RAM are required to be duplicated across both machines?
2-screen (2- or 4- player) games require the same game on both sides. 1-screen (1- or 2- player) games ignore /IRQ and – with the exception of Vs. SMB – don't use the shared memory.
You
could set up your game to automatically detect if there's one or two copies of your game installed, and automatically switch between 1-screen and 2-screen versions. But the existing games don't.
f) "There doesn't seem to be a way to send back safely or ack that is safe, so you just have to code the 2nd CPU such that is does it as fast as possible before it will get another." Couldn't CPU1 be waiting for IRQ as well before attempting to use the RAM?
Yes. One side sends an IRQ, other side marks completion with another IRQ. The secondary CPU can detect when it's lost access to shared memory as well: when it doesn't have access the corresponding region will be open bus.
(For example, you could read from $6000 and $7800 and if the first byte is $60 and the second byte is $78 even though they would point to the same address of physical memory, you know that the secondary CPU does not currently have access to the shared memory)
What is the behaviour on the Secondary CPU when the bit is LOW/HIGH? This sentence seems to only be describing the meaning of writing the bit from the primary CPU perspective.
Correct, only the primary CPU can control
which side gets the RAM.
Is this because only the primary CPU can write that bit? Can CPU2 not trigger the IRQ on CPU1?
No? That works fine?
Please help me rephrase this to be clearer, I really don't know how I can make this clearer:
In the DualSystem, does two things:
#1: When low, asserts /IRQ on the other CPU
#2: On the primary CPU, when high, the primary CPU can access 2 KiB of shared RAM mapped in the $6000-$7FFF region. When instead low, the the secondary CPU instead can access the same physical memory.