Mixing
![Getting user login details without his permission. Is it not illegal [closed]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjbpfN9tAutmK93bJRC3ZoROZzi2TJDms5n8_qJuhgE0a9b52OOHayv3NGT8igAdFL7byXNst-_1DZK5SjrIJ28_6RQPUpBROqMs5s6jo-ZsjX8kjDwfxJufIitH3TaQRXWaGSQKRQib-f/s72-c/1.jpg)
Did the NES do anything special to support coprocessors?
Clash Royale CLAN TAG#URR8PPP
up vote
18
down vote
favorite
Some of the later NES/Famicom games contained not just ROM, but coprocessors for better sound and graphics than the original console hardware could provide, such as the MMC5: https://wiki.nesdev.com/w/index.php/MMC5
Did the console itself, the cartridge slot, do anything special to support these coprocessors, was it farsighted planning in the original design? Or is the ability to add such coprocessors later, an automatic consequence of the ability to address ROM? Looking at the pinout https://forums.nesdev.com/viewtopic.php?f=9&t=14924 the most suggestive thing I can see is IRQ; it does not seem that should be necessary just for ROM cartridges?
(I get the impression that by the time the SNES was designed, they were explicitly thinking about later coprocessor support, but I would not have expected such thinking at the time of design of the original Famicom, which is why I am curious.)
nes
asked 21 hours ago
rwallace
6,95922995
add a comment |Â
up vote
18
down vote
favorite
Some of the later NES/Famicom games contained not just ROM, but coprocessors for better sound and graphics than the original console hardware could provide, such as the MMC5: https://wiki.nesdev.com/w/index.php/MMC5
Did the console itself, the cartridge slot, do anything special to support these coprocessors, was it farsighted planning in the original design? Or is the ability to add such coprocessors later, an automatic consequence of the ability to address ROM? Looking at the pinout https://forums.nesdev.com/viewtopic.php?f=9&t=14924 the most suggestive thing I can see is IRQ; it does not seem that should be necessary just for ROM cartridges?
(I get the impression that by the time the SNES was designed, they were explicitly thinking about later coprocessor support, but I would not have expected such thinking at the time of design of the original Famicom, which is why I am curious.)
nes
asked 21 hours ago
rwallace
6,95922995
6
In my terminology, a "real" coprocessor can take over the bus and stop the main CPU - This does not seem to be possible, as the CPU RDY signal doesn't seem to be exposed on the cartridge slot - Apparently, the coprocessors can only work as intelligent I/O processors
– tofro
17 hours ago
Re: the SNES, didn't they move the DSP-1 off the main board only at a relatively late stage, after Pilotwings was already mostly finished? I don't have a concrete source for that. But it would more than support the idea that coprocessor support was being explicitly factored into the SNES design.
– Tommy
13 hours ago
You might be interested in watching youtube.com/watch?v=ar9WRwCiSr0 where a guy basically does that by observing the bus and really in the end uses the NES just as an i/o system and everything runs on the cartridge.
– PlasmaHH
5 hours ago
add a comment |Â
up vote
18
down vote
favorite
up vote
18
down vote
favorite
Some of the later NES/Famicom games contained not just ROM, but coprocessors for better sound and graphics than the original console hardware could provide, such as the MMC5: https://wiki.nesdev.com/w/index.php/MMC5
Did the console itself, the cartridge slot, do anything special to support these coprocessors, was it farsighted planning in the original design? Or is the ability to add such coprocessors later, an automatic consequence of the ability to address ROM? Looking at the pinout https://forums.nesdev.com/viewtopic.php?f=9&t=14924 the most suggestive thing I can see is IRQ; it does not seem that should be necessary just for ROM cartridges?
(I get the impression that by the time the SNES was designed, they were explicitly thinking about later coprocessor support, but I would not have expected such thinking at the time of design of the original Famicom, which is why I am curious.)
nes
asked 21 hours ago
rwallace
6,95922995
Some of the later NES/Famicom games contained not just ROM, but coprocessors for better sound and graphics than the original console hardware could provide, such as the MMC5: https://wiki.nesdev.com/w/index.php/MMC5
Did the console itself, the cartridge slot, do anything special to support these coprocessors, was it farsighted planning in the original design? Or is the ability to add such coprocessors later, an automatic consequence of the ability to address ROM? Looking at the pinout https://forums.nesdev.com/viewtopic.php?f=9&t=14924 the most suggestive thing I can see is IRQ; it does not seem that should be necessary just for ROM cartridges?
(I get the impression that by the time the SNES was designed, they were explicitly thinking about later coprocessor support, but I would not have expected such thinking at the time of design of the original Famicom, which is why I am curious.)
nes
nes
asked 21 hours ago
rwallace
6,95922995
asked 21 hours ago
rwallace
6,95922995
asked 21 hours ago
rwallace
6,95922995
asked 21 hours ago
rwallace
6,95922995
asked 21 hours ago
rwallace
6,95922995
6,95922995
6
In my terminology, a "real" coprocessor can take over the bus and stop the main CPU - This does not seem to be possible, as the CPU RDY signal doesn't seem to be exposed on the cartridge slot - Apparently, the coprocessors can only work as intelligent I/O processors
– tofro
17 hours ago
Re: the SNES, didn't they move the DSP-1 off the main board only at a relatively late stage, after Pilotwings was already mostly finished? I don't have a concrete source for that. But it would more than support the idea that coprocessor support was being explicitly factored into the SNES design.
– Tommy
13 hours ago
You might be interested in watching youtube.com/watch?v=ar9WRwCiSr0 where a guy basically does that by observing the bus and really in the end uses the NES just as an i/o system and everything runs on the cartridge.
– PlasmaHH
5 hours ago
add a comment |Â
6
In my terminology, a "real" coprocessor can take over the bus and stop the main CPU - This does not seem to be possible, as the CPU RDY signal doesn't seem to be exposed on the cartridge slot - Apparently, the coprocessors can only work as intelligent I/O processors
– tofro
17 hours ago
Re: the SNES, didn't they move the DSP-1 off the main board only at a relatively late stage, after Pilotwings was already mostly finished? I don't have a concrete source for that. But it would more than support the idea that coprocessor support was being explicitly factored into the SNES design.
– Tommy
13 hours ago
You might be interested in watching youtube.com/watch?v=ar9WRwCiSr0 where a guy basically does that by observing the bus and really in the end uses the NES just as an i/o system and everything runs on the cartridge.
– PlasmaHH
5 hours ago
6
6
In my terminology, a "real" coprocessor can take over the bus and stop the main CPU - This does not seem to be possible, as the CPU RDY signal doesn't seem to be exposed on the cartridge slot - Apparently, the coprocessors can only work as intelligent I/O processors
– tofro
17 hours ago
In my terminology, a "real" coprocessor can take over the bus and stop the main CPU - This does not seem to be possible, as the CPU RDY signal doesn't seem to be exposed on the cartridge slot - Apparently, the coprocessors can only work as intelligent I/O processors
– tofro
17 hours ago
Re: the SNES, didn't they move the DSP-1 off the main board only at a relatively late stage, after Pilotwings was already mostly finished? I don't have a concrete source for that. But it would more than support the idea that coprocessor support was being explicitly factored into the SNES design.
– Tommy
13 hours ago
Re: the SNES, didn't they move the DSP-1 off the main board only at a relatively late stage, after Pilotwings was already mostly finished? I don't have a concrete source for that. But it would more than support the idea that coprocessor support was being explicitly factored into the SNES design.
– Tommy
13 hours ago
You might be interested in watching youtube.com/watch?v=ar9WRwCiSr0 where a guy basically does that by observing the bus and really in the end uses the NES just as an i/o system and everything runs on the cartridge.
– PlasmaHH
5 hours ago
You might be interested in watching youtube.com/watch?v=ar9WRwCiSr0 where a guy basically does that by observing the bus and really in the end uses the NES just as an i/o system and everything runs on the cartridge.
– PlasmaHH
5 hours ago
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
13
down vote
accepted
You're correct about it being a consequence of cartridges being able to observe the PPU memory bus. The advanced video features of the MMC5 and other mappers might have been trivial to add if Nintendo provided more signals to expose the internal state of the PPU to the cartridge, but they didn't, so these chips function by carefully monitoring PPU memory accesses to infer what it is doing as there isn't a more direct line of communication.
It takes a lot of logic to do that which is why the advanced features didn't show up in earlier cartridges made with discrete TTL parts (outside of bankswitching which is trivial) until they could justify the cost of adding semi-custom parts (gate arrays) to implement the PPU bus monitoring.
Nintendo did have foresight to push the cost of graphics memory into the cartridges knowing memory gets cheaper over time, which allowed for interesting design choices like using RAM and large ROMs. But the special functions of the MMC2, MMC5, and scanline counting across various mappers were a consequence of the design rather than something intentional.
For audio it's a different matter, the Famicom had a dedicated audio input pin so they always intended for that kind of feature expansion.
The SNES has a high speed channel for moving data from external memory into video RAM which was what made things like the SuperFX and SA-1 possible. I don't think they envisioned those exact uses but understood that having a way to shuttle in data quickly would be beneficial which it turned out to be.
It's rather unfortunate their CD-ROM peripheral never took off because slow access to video memory is what hampered streaming video on the Genesis and TurboGrafx CD systems.
answered 18 hours ago
raisin-wrangler
78525
add a comment |Â
up vote
13
down vote
Yes and no. Since the cartridge slot contained a complete basic CPU bus (Address + Data + Clock + R/W), any memory mappable coprocessor can be implemented. No specific coprocessor handling lines are present - and the CPU wouldn't support such anyway.
(And the SNES was only specific in having designated lines to handle a game specific security chip - besides that it was again rather plain CPU/Memory design).
edited 18 hours ago
Community♦
1
answered 20 hours ago
Raffzahn
33.1k474132
1
What about IRQ? What is that for, if not a specific coprocessor handling line?
– rwallace
20 hours ago
4
IRQ is a general way to handle interrupts - and they are general purpose. Handling a coprocessor may involve interupts - much the same way as a parallel interface or a push button. Having one (or more) interrupts is a definite plus for an interface, but neither special for coprocessors nor required.
– Raffzahn
20 hours ago
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
13
down vote
accepted
You're correct about it being a consequence of cartridges being able to observe the PPU memory bus. The advanced video features of the MMC5 and other mappers might have been trivial to add if Nintendo provided more signals to expose the internal state of the PPU to the cartridge, but they didn't, so these chips function by carefully monitoring PPU memory accesses to infer what it is doing as there isn't a more direct line of communication.
It takes a lot of logic to do that which is why the advanced features didn't show up in earlier cartridges made with discrete TTL parts (outside of bankswitching which is trivial) until they could justify the cost of adding semi-custom parts (gate arrays) to implement the PPU bus monitoring.
Nintendo did have foresight to push the cost of graphics memory into the cartridges knowing memory gets cheaper over time, which allowed for interesting design choices like using RAM and large ROMs. But the special functions of the MMC2, MMC5, and scanline counting across various mappers were a consequence of the design rather than something intentional.
For audio it's a different matter, the Famicom had a dedicated audio input pin so they always intended for that kind of feature expansion.
The SNES has a high speed channel for moving data from external memory into video RAM which was what made things like the SuperFX and SA-1 possible. I don't think they envisioned those exact uses but understood that having a way to shuttle in data quickly would be beneficial which it turned out to be.
It's rather unfortunate their CD-ROM peripheral never took off because slow access to video memory is what hampered streaming video on the Genesis and TurboGrafx CD systems.
answered 18 hours ago
raisin-wrangler
78525
add a comment |Â
up vote
13
down vote
accepted
You're correct about it being a consequence of cartridges being able to observe the PPU memory bus. The advanced video features of the MMC5 and other mappers might have been trivial to add if Nintendo provided more signals to expose the internal state of the PPU to the cartridge, but they didn't, so these chips function by carefully monitoring PPU memory accesses to infer what it is doing as there isn't a more direct line of communication.
It takes a lot of logic to do that which is why the advanced features didn't show up in earlier cartridges made with discrete TTL parts (outside of bankswitching which is trivial) until they could justify the cost of adding semi-custom parts (gate arrays) to implement the PPU bus monitoring.
Nintendo did have foresight to push the cost of graphics memory into the cartridges knowing memory gets cheaper over time, which allowed for interesting design choices like using RAM and large ROMs. But the special functions of the MMC2, MMC5, and scanline counting across various mappers were a consequence of the design rather than something intentional.
For audio it's a different matter, the Famicom had a dedicated audio input pin so they always intended for that kind of feature expansion.
The SNES has a high speed channel for moving data from external memory into video RAM which was what made things like the SuperFX and SA-1 possible. I don't think they envisioned those exact uses but understood that having a way to shuttle in data quickly would be beneficial which it turned out to be.
It's rather unfortunate their CD-ROM peripheral never took off because slow access to video memory is what hampered streaming video on the Genesis and TurboGrafx CD systems.
answered 18 hours ago
raisin-wrangler
78525
add a comment |Â
up vote
13
down vote
accepted
up vote
13
down vote
accepted
You're correct about it being a consequence of cartridges being able to observe the PPU memory bus. The advanced video features of the MMC5 and other mappers might have been trivial to add if Nintendo provided more signals to expose the internal state of the PPU to the cartridge, but they didn't, so these chips function by carefully monitoring PPU memory accesses to infer what it is doing as there isn't a more direct line of communication.
It takes a lot of logic to do that which is why the advanced features didn't show up in earlier cartridges made with discrete TTL parts (outside of bankswitching which is trivial) until they could justify the cost of adding semi-custom parts (gate arrays) to implement the PPU bus monitoring.
Nintendo did have foresight to push the cost of graphics memory into the cartridges knowing memory gets cheaper over time, which allowed for interesting design choices like using RAM and large ROMs. But the special functions of the MMC2, MMC5, and scanline counting across various mappers were a consequence of the design rather than something intentional.
For audio it's a different matter, the Famicom had a dedicated audio input pin so they always intended for that kind of feature expansion.
The SNES has a high speed channel for moving data from external memory into video RAM which was what made things like the SuperFX and SA-1 possible. I don't think they envisioned those exact uses but understood that having a way to shuttle in data quickly would be beneficial which it turned out to be.
It's rather unfortunate their CD-ROM peripheral never took off because slow access to video memory is what hampered streaming video on the Genesis and TurboGrafx CD systems.
answered 18 hours ago
raisin-wrangler
78525
You're correct about it being a consequence of cartridges being able to observe the PPU memory bus. The advanced video features of the MMC5 and other mappers might have been trivial to add if Nintendo provided more signals to expose the internal state of the PPU to the cartridge, but they didn't, so these chips function by carefully monitoring PPU memory accesses to infer what it is doing as there isn't a more direct line of communication.
It takes a lot of logic to do that which is why the advanced features didn't show up in earlier cartridges made with discrete TTL parts (outside of bankswitching which is trivial) until they could justify the cost of adding semi-custom parts (gate arrays) to implement the PPU bus monitoring.
Nintendo did have foresight to push the cost of graphics memory into the cartridges knowing memory gets cheaper over time, which allowed for interesting design choices like using RAM and large ROMs. But the special functions of the MMC2, MMC5, and scanline counting across various mappers were a consequence of the design rather than something intentional.
For audio it's a different matter, the Famicom had a dedicated audio input pin so they always intended for that kind of feature expansion.
The SNES has a high speed channel for moving data from external memory into video RAM which was what made things like the SuperFX and SA-1 possible. I don't think they envisioned those exact uses but understood that having a way to shuttle in data quickly would be beneficial which it turned out to be.
It's rather unfortunate their CD-ROM peripheral never took off because slow access to video memory is what hampered streaming video on the Genesis and TurboGrafx CD systems.
answered 18 hours ago
raisin-wrangler
78525
answered 18 hours ago
raisin-wrangler
78525
answered 18 hours ago
raisin-wrangler
78525
answered 18 hours ago
raisin-wrangler
78525
78525
add a comment |Â
add a comment |Â
up vote
13
down vote
Yes and no. Since the cartridge slot contained a complete basic CPU bus (Address + Data + Clock + R/W), any memory mappable coprocessor can be implemented. No specific coprocessor handling lines are present - and the CPU wouldn't support such anyway.
(And the SNES was only specific in having designated lines to handle a game specific security chip - besides that it was again rather plain CPU/Memory design).
edited 18 hours ago
Community♦
1
answered 20 hours ago
Raffzahn
33.1k474132
1
What about IRQ? What is that for, if not a specific coprocessor handling line?
– rwallace
20 hours ago
4
IRQ is a general way to handle interrupts - and they are general purpose. Handling a coprocessor may involve interupts - much the same way as a parallel interface or a push button. Having one (or more) interrupts is a definite plus for an interface, but neither special for coprocessors nor required.
– Raffzahn
20 hours ago
add a comment |Â
up vote
13
down vote
Yes and no. Since the cartridge slot contained a complete basic CPU bus (Address + Data + Clock + R/W), any memory mappable coprocessor can be implemented. No specific coprocessor handling lines are present - and the CPU wouldn't support such anyway.
(And the SNES was only specific in having designated lines to handle a game specific security chip - besides that it was again rather plain CPU/Memory design).
edited 18 hours ago
Community♦
1
answered 20 hours ago
Raffzahn
33.1k474132
1
What about IRQ? What is that for, if not a specific coprocessor handling line?
– rwallace
20 hours ago
4
IRQ is a general way to handle interrupts - and they are general purpose. Handling a coprocessor may involve interupts - much the same way as a parallel interface or a push button. Having one (or more) interrupts is a definite plus for an interface, but neither special for coprocessors nor required.
– Raffzahn
20 hours ago
add a comment |Â
up vote
13
down vote
up vote
13
down vote
Yes and no. Since the cartridge slot contained a complete basic CPU bus (Address + Data + Clock + R/W), any memory mappable coprocessor can be implemented. No specific coprocessor handling lines are present - and the CPU wouldn't support such anyway.
(And the SNES was only specific in having designated lines to handle a game specific security chip - besides that it was again rather plain CPU/Memory design).
edited 18 hours ago
Community♦
1
answered 20 hours ago
Raffzahn
33.1k474132
Yes and no. Since the cartridge slot contained a complete basic CPU bus (Address + Data + Clock + R/W), any memory mappable coprocessor can be implemented. No specific coprocessor handling lines are present - and the CPU wouldn't support such anyway.
(And the SNES was only specific in having designated lines to handle a game specific security chip - besides that it was again rather plain CPU/Memory design).
edited 18 hours ago
Community♦
1
answered 20 hours ago
Raffzahn
33.1k474132
edited 18 hours ago
Community♦
1
edited 18 hours ago
Community♦
1
edited 18 hours ago
Community♦
1
1
answered 20 hours ago
Raffzahn
33.1k474132
answered 20 hours ago
Raffzahn
33.1k474132
answered 20 hours ago
Raffzahn
33.1k474132
33.1k474132
1
What about IRQ? What is that for, if not a specific coprocessor handling line?
– rwallace
20 hours ago
4
IRQ is a general way to handle interrupts - and they are general purpose. Handling a coprocessor may involve interupts - much the same way as a parallel interface or a push button. Having one (or more) interrupts is a definite plus for an interface, but neither special for coprocessors nor required.
– Raffzahn
20 hours ago
add a comment |Â
1
What about IRQ? What is that for, if not a specific coprocessor handling line?
– rwallace
20 hours ago
4
IRQ is a general way to handle interrupts - and they are general purpose. Handling a coprocessor may involve interupts - much the same way as a parallel interface or a push button. Having one (or more) interrupts is a definite plus for an interface, but neither special for coprocessors nor required.
– Raffzahn
20 hours ago
1
1
What about IRQ? What is that for, if not a specific coprocessor handling line?
– rwallace
20 hours ago
What about IRQ? What is that for, if not a specific coprocessor handling line?
– rwallace
20 hours ago
4
4
IRQ is a general way to handle interrupts - and they are general purpose. Handling a coprocessor may involve interupts - much the same way as a parallel interface or a push button. Having one (or more) interrupts is a definite plus for an interface, but neither special for coprocessors nor required.
– Raffzahn
20 hours ago
IRQ is a general way to handle interrupts - and they are general purpose. Handling a coprocessor may involve interupts - much the same way as a parallel interface or a push button. Having one (or more) interrupts is a definite plus for an interface, but neither special for coprocessors nor required.
– Raffzahn
20 hours ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f7551%2fdid-the-nes-do-anything-special-to-support-coprocessors%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
6
In my terminology, a "real" coprocessor can take over the bus and stop the main CPU - This does not seem to be possible, as the CPU RDY signal doesn't seem to be exposed on the cartridge slot - Apparently, the coprocessors can only work as intelligent I/O processors
– tofro
17 hours ago
Re: the SNES, didn't they move the DSP-1 off the main board only at a relatively late stage, after Pilotwings was already mostly finished? I don't have a concrete source for that. But it would more than support the idea that coprocessor support was being explicitly factored into the SNES design.
– Tommy
13 hours ago
You might be interested in watching youtube.com/watch?v=ar9WRwCiSr0 where a guy basically does that by observing the bus and really in the end uses the NES just as an i/o system and everything runs on the cartridge.
– PlasmaHH
5 hours ago