SNES hardware APU support?

Electric Rain · Post by **Electric Rain** » Tue Dec 11, 2007 7:51 am

Hi, I'm new... <.< >.> Okay, I don't really know how to introduce myself, so I'll just jump right in to my proposal.

I'm sure many of you are aware of the SNES APU parallel port interface that a few people have built around the 'net. It allows you to load and play SPCs directly into the actual APU (that can be taken out of the early model SNESes) via parallel port. Obviously, it gives 100% accurate sound, which is friggin' A.

I was wondering if it would be possible to integrate support for the hardware APU in ZSNES. How amazing would it be if you could emulate SNES games with perfect sound? Actually, you wouldn't even be emulating the sound. ^-^

One of the more advanced members on the BenHeck forums (my "native" forum, you could say) that has actually built one of these and has a good deal or programming experience told me it would probably be pretty hard, and that there may be syncing problems because of the parallel port interface (too slow... possibly). I wanted to see what you guys thought, since this is the ZSNES forum, after all.

I want to build a media center PC, but I also want to emulate SNES games with it... and this would be some SWEET icing on the cake (pun intended).

If someone thinks they can write a plugin or something to do this, then I would be willing to build them a module for the cost of parts... or maybe for free. I dunno, I'm hardly rich. >.>

So how about it? Feasible?

whicker · Post by **whicker** » Wed Dec 12, 2007 3:01 am

Nice idea.

Not going to happen perfectly without a "realtime" emulator. In ZSNES and probably every other SNES emulator, clock ticks of the emulated CPU and APU do not coincide with what a real device would do at that same instant. It's more like "bursts" of activity, where the end result matches up with the 60Hz or whatever redraw of the screen. Sound itself is put into an audio buffer in bursts as well, and nobody is the wiser as long as the signal gets streamed out at a constant rate.

It isn't impossible to do half-assed, though. Most games are just going to use the reference code to load up the APU, with a blanked screen or whatever, which can be handshaked, with the hardware interface taking as long as it needs. Other commands to play sound effects ingame would be okay with a granularity of +/- 33ms or so.

Electric Rain · Post by **Electric Rain** » Wed Dec 12, 2007 11:57 am

...Huh... alright then. Now I know.

Thanks for filling me in.

It'd still be sweet, though.

Edit: Yeah, I know it looks like I'm an idiot here, but I really just don't know what to say to that. I understood everything you said though, honest.

byuu · Post by **byuu** » Wed Dec 12, 2007 10:04 pm

whicker, it sounds like he wants this interface to get more accurate sound, and delays of up to ~33ms to wait on parallel port accesses certainly isn't going to help any.

Instead, it would be better to get a really good PC sound card that doesn't resample, and use an emulator with blargg's S-DSP emulator, such as ZSNES v2.0 when it's ready. blargg's emulator is bit-perfect in virtually all test cases, which will produce much better sound that trying to pretend you could strobe the I/O ports at two constant frequencies (~10.5MHz to, ~1.024MHz from)

I can't even find any information on how fast the port is, but I'm sure you won't be able to get better than ~5ms granularity, even with a real-time OS. That's way, way more than enough to completely destroy many games like Earthworm Jim 2.

Lastly, such an interface would bind you to running only at full speed anyway (no fast forward, no save states, no emu-based pause, etc). And if you're using real hardware already ... why not just go all the way? Hook up a copier + SNES to a video + audio capture card, and play your games inside the capture card playback software.

And if you know how to program, maybe get one of the parallel port SNES units, and write a frontend that automatically transfers a ROM over to the copier for you via File->Load, and embeds the capture card output into its own window. If not, get one of the CD-based copiers and put all your games on there.

neo_bahamut1985 · Post by **neo_bahamut1985** » Thu Dec 13, 2007 12:20 am

Yes, I've heard that Blarg's S-DSP emulator (for Zsnes 2.0) is really good. Just how good is "good"? Just a random question.

franpa · Post by **franpa** » Thu Dec 13, 2007 12:27 am

bit perfect in most cases as byuu pointed out.

I.S.T. · Post by **I.S.T.** » Thu Dec 13, 2007 7:46 am

byuu wrote:Instead, it would be better to get a really good PC sound card that doesn't resample,

I thought all but the highest end(I.E. Professional level shit.) SCs resample...

byuu · Post by **byuu** » Thu Dec 13, 2007 9:10 am

I.S.T. wrote:
byuu wrote:Instead, it would be better to get a really good PC sound card that doesn't resample,
I thought all but the highest end(I.E. Professional level shit.) SCs resample...

Yeah, but if this guy is building his own custom SNES APU hardware, he either has a lot of money, or has the intelligence to make a lot of money if he wants to, so it shouldn't be a problem.

... or perhaps he can rig up his own sound card just for this project :)

Electric Rain · Post by **Electric Rain** » Thu Dec 13, 2007 12:41 pm

byuu wrote:Lastly, such an interface would bind you to running only at full speed anyway (no fast forward, no save states, no emu-based pause, etc). And if you're using real hardware already ... why not just go all the way? Hook up a copier + SNES to a video + audio capture card, and play your games inside the capture card playback software.

And if you know how to program, maybe get one of the parallel port SNES units, and write a frontend that automatically transfers a ROM over to the copier for you via File->Load, and embeds the capture card output into its own window. If not, get one of the CD-based copiers and put all your games on there.

I would, but those units are hardly perfected. I won't be able to play any games that used Super FX chips, DSP chips, or any other special coprocessors, would I? If I were to do something like that, I'd probably end up going WAY over the top with it... heh. I.E. I would hack up an FC Twin and re-build it on a PCI card with a build-in parallel interface. Then I would just use a jumper cable to go straight from the A/V out on that to the internal A/V in port on my PVR-150 capture card.

Completely contained.

It's really too bad that Nintendo had to be so difficult and start putting coprocessors in their games... who DOES that?!

BFeely · Post by **BFeely** » Mon Dec 17, 2007 2:33 am

It's really too bad that Nintendo had to be so difficult and start putting coprocessors in their games... who DOES that?!

Those who realize their video game system has inferior processing power.

blackmyst · Post by **blackmyst** » Mon Dec 17, 2007 4:14 pm

BFeely wrote:
It's really too bad that Nintendo had to be so difficult and start putting coprocessors in their games... who DOES that?!
Those who realize their video game system has inferior processing power.

Yeah, that's why such games as ToP, CT or DKC1-3 all looked worse than Genesis games did.

Panzer88 · Post by **Panzer88** » Mon Dec 17, 2007 11:09 pm

or Sekien Densetsu 3, Treasure of the Rudras, or Treasure Hunter G, I guess Bahamut Lagoon too.

(they have some spiffy effects)

byuu · Post by **byuu** » Tue Dec 18, 2007 12:37 am

You're comparing two totally different things.

The Genesis has a vastly superior processor. 32-bit, ~10MHz Motorola 680x0.
The SNES had an inferior 16-bit, ~2.68MHz WDC 65c816. Not even the SA-1 was an equal to the Genesis 68k, and the SuperFX2 was too specialized for general purpose computing to be practical.

The advantages the SNES had were its amazing video processor, and practically cutting-edge sound processor and DSP.

The SNES PPU could reach 15-bit (32,768) color, whereas the Genesis VDP was limited to a mere 9-bit (512) color. No matter what add-on chips or hardware the Genesis introduced, they could never make their games look much more vibrant than NES-era games.

The SNES APU ... well, you can tell by games like ToP how powerful that was. Full voice acting in that day and age ... versus the Genesis' FM synthesis. No competition at all there.

But while enhanced video and audio are nice, you're still bottlenecked by that CPU. You'll note that most of the SNES special chips, especially the DSPs, contain lots of circuit-logic for AI. Such as with the DSP-3, DSP-4, ST-010, ST-011 and ST-018. Games that bypassed special chips and kept decent AI ended up with some serious lag issues, such as Der Langrisser. Compare that to Langrisser II and see which moves faster. Lots of fan translators now struggle with producing fast variable-width font rendering code. It takes roughly 1/3rd of a frame to render a single 8x8 item name with a VWF. Now try filling an entire item list screen like that, and you end up with DeJap's Bahamut Lagoon copier patch. ~3-4 second lag per item page scroll.
Also compare CPU-intensive tasks like software scaling and rotation, missing from both systems. The Genesis had no problems simulating that (Castlevania: Bloodlines, Sonic special stage, etc), but the SNES could never really do that with more than a few small sprites at a time. Of course, the SNES PPU saved the day here with its Mode 7 effects. But unfortunately that only applied to the entire BG screen (limited to 128x128), and never to sprites.

The SNES' only real weakness was easily corrected by cartridge add-on chips. Although Nintendo really would have been wiser to stick a much more powerful CPU in there, absorb some of the costs in the base system, and greatly reduce the cost of producing all of those special chip carts out there. Oh well ...

It's very telling why the Genesis only ever had one special chip, which existed solely for generating 3D video; and why the SNES had roughly a dozen for numerous specialized purposes.

In the end though, there's no disputing which system design approach proved more commercially successful. One need only look at which company is still producing gaming hardware to this day.

(EDIT: fixed duplicated text)

denzilla · Post by **denzilla** » Tue Dec 18, 2007 3:30 am

You're comparing two totally different things.

The Genesis has a vastly superior processor. 32-bit, ~10MHz Motorola 680x0.
The SNES had an inferior 16-bit, ~2.68MHz WDC 65c816. Not even the SA-1 was an equal to the Genesis 68k, and the SuperFX2 was too specialized for general purpose computing to be practical.

The advantages the SNES had were its amazing video processor, and practically cutting-edge sound processor and DSP.

The SNES PPU could reach 15-bit (32,768) color, whereas the Genesis VDP was limited to a mere 9-bit (512) color. No matter what add-on chips or hardware the Genesis introduced, they could never make their games look much more vibrant than NES-era games.

Just some small corrections to your post

1. The Genesis Motorola 68000 CPU was 16-bit running at approx 7.16MHz not 32-bit. the SegaCD addon also utilized the same CPU, only it had a higher clock frequency of about 12Mhz. The 32X did in fact use a 32-bit CPU however. Perhaps you got confused :p

2. The Genesis was capable of displaying 64 colors out of a maximum of 512. They were able to beat this limitation with software tricks as I remember (Ranger-X used the trick), but 64 out of 512 was its official limit.

3. SNES was capable of displaying 256 colors out of 32,768.

Sega lost in the end because they saturated the market with to much hardware and little to no support for any of it. All they did was confuse and dilute their own marketshare. They should've stuck with the Genesis while putting all their R/D into the Saturn. Had they done that, things might've been different today. Hindsight is always 20/20 isn't it

franpa · Post by **franpa** » Tue Dec 18, 2007 4:06 am

you have 2 copies of your text in your post byuu.

neo_bahamut1985 · Post by **neo_bahamut1985** » Tue Dec 18, 2007 4:26 am

that definitely explains why SNES games, on average, look cleaner than Genesis. And yes, this may be off-topic, so, I apologize.

denzilla · Post by **denzilla** » Tue Dec 18, 2007 4:38 am

Genesis resolution was 320x224 vs. SNES resolution of 512x448. The higher res plus the higher maximum colors on screen made SNES games look a whole lot better. The Genesis was so much better at pushing sprites though. Thunderforce III for the Genesis just wowed me throughout the whole game while I was disgusted when I first played Gradius III on the SNES. It was a beautiful sight paused but man did it suck in motion. Kick ass music though!

byuu · Post by **byuu** » Tue Dec 18, 2007 5:02 am

1. The Genesis Motorola 68000 CPU was 16-bit running at approx 7.16MHz not 32-bit.

Ah, that's true about the clock speed, my mistake. As for the processor itself -- I definitely remember using 32-bit instructions when programming for it, such as move.l #$c00000,d0. This was the same for the data bus and data registers (d0-d7), and for the address bus and address registers (a0-a7) (though perhaps the upper 8-bits were ignored / mirrored). If there was some sort of black magic and it really was only 16-bit, then the processor did a wonderful job of faking being 32-bit.

2. The Genesis was capable of displaying 64 colors out of a maximum of 512. They were able to beat this limitation with software tricks as I remember (Ranger-X used the trick), but 64 out of 512 was its official limit.

3. SNES was capable of displaying 256 colors out of 32,768.

The point was the ability to display the colors, and how many bits you had per palette entry (15-bit 0bbbbbgg gggrrrrr SNES vs 9-bit 0000000r rrgggbbb Genesis). Of course, 64/Genesis and 256/SNES were the practical limits ... there was also a tech demo for the SNES to display all 32,768 colors onscreen at one time. Typically, color add/sub effects greatly enhanced the number of onscreen colors in most games (eg Dracula X level 1 fire background), but usually it didn't reach more than ~256 - 2,048 colors at any one time.

But yeah, the point was the depth of colors possible. It made for much more vibrant games.

Sega lost in the end because they saturated the market with to much hardware and little to no support for any of it.

I don't know, really. The Master System had horrible advertising, I've only ever even seen two in my lifetime. The Genesis had the aforementioned problems with video and sound. The Sega CD was way too early to market, and thus way too expensive (funny, and the PS3 started at $600.) The 32X -- I don't even want to know what they were thinking there.

The Saturn suffered from being way too complex. A real shame, Sega of America had a great system design, but the Japanese had too much pride and pushed ahead with their design, ignoring that developers would never be able to utilize it all. They even had their chance to beat Nintendo -- the N64 was one of the biggest duds in history, again mostly for pride issues. It's really telling that it's the only example I have where the system made after it (Dreamcast) is both easier and faster to emulate.

The Dreamcast, that really was a rock solid system. I loved mine. Despite getting in bed with The Devil, who continues to haunt gaming to this day, the system was surprisingly stable and well designed. It's just a shame nobody at Sega ever bothered to try running a standard CD-R on the system :/

And with all of their other failed projects beforehand ... yeah, they were in really bad shape.

It's really funny now watching Sony repeat all of Sega's mistakes this generation. You really have to love the pride these Japanese companies have. And Microsoft's laughable attempts to enter the Japanese market. Silly gaijins.

you have 2 copies of your text in your post byuu.

... how the hell did that happen? o.O
Fixed, thanks.

Genesis resolution was 320x224 vs. SNES resolution of 512x448.

Well, RPM Racing was the only game I've seen actually use full 512x448. Those modes had serious color / BG restrictions. It was a more practical limit in most games to use 256x224. The difference was infinitesimal, and if anything it helped out the slower SNES CPU.

The Genesis was so much better at pushing sprites though.

... because it controlled each sprite with the CPU. The SNES video circuitry was more powerful, but the CPU didn't have the processing power to calculate the AI for so many sprites and still run quickly.

SNES @ 256x224: 128 max/screen, 32 max/scanline
Genesis @ 256x224: 80 max/screen, 20 max/scanline
Genesis @ 320x224: 64 max/screen, 16 max/scanline

Really, the SNES with the Genesis CPU would've been a force to be reckoned with.

I.S.T. · Post by **I.S.T.** » Tue Dec 18, 2007 8:57 am

The 68000 is an odd chip. It has 32 bit registers, and an address bus that can be 8, 16 or 24 bits. The one found in the Genesis has a 16 bit bus.

Electric Rain · Post by **Electric Rain** » Tue Dec 18, 2007 10:30 am

You know, somehow, the fact that this has gone TOTALLY off topic doesn't really bother me at all.

The current discussion is quite entertaining... and educational. You crazy b@st@rds are smart.

DancemasterGlenn · Post by **DancemasterGlenn** » Tue Dec 18, 2007 10:50 am

I agree, I'm reading this mostly for pleasure now. Very interesting points.

byuu · Post by **byuu** » Tue Dec 18, 2007 12:13 pm

I.S.T. wrote:The 68000 is an odd chip. It has 32 bit registers, and an address bus that can be 8, 16 or 24 bits. The one found in the Genesis has a 16 bit bus.

Please elaborate. The address bus is 100% certainly greater than or equal to 24-bits (there was no MMC, the entire ROM was mapped, starting right from 0x0 onward -- the VDP was mapped to 0xc00000+ IIRC), and the data bus would clearly have to be 32-bits (or sport some serious voodoo black magic) to work with 32-bit instructions and registers. Which bus is 16-bits, and how is that possible? Please point to technical information.

Thristian · Post by **Thristian** » Tue Dec 18, 2007 12:47 pm

DancemasterGlenn wrote:I agree, I'm reading this mostly for pleasure now. Very interesting points.

This kind of thing is the whole reason I lurk in the ZSNES/SNES9x/BSNES dev forums at all. And then I go to parties and correct people's wild assertions about old game consoles and people look at me funny. But hey, it's fun!

denzilla · Post by **denzilla** » Tue Dec 18, 2007 1:01 pm

I don't program byuu so I can't speak to the internal workings of the 68000, but my Genesis had 16-bit wrote on the top of the system and I read several different magazine articles referring to the Genesis CPU as 16-bit back in the day. If it was a 32-bit system, I would think that Sega would've jumped at the chance to use that in its marketing.

What was SOA's proposal in terms of specs/design for the Saturn?

Nightcrawler · Post by **Nightcrawler** » Tue Dec 18, 2007 3:03 pm

Ok, let's put this to bed. I have the definitive information taken directly from Motorola/Freescale documentation.

http://www.freescale.com/webapp/sps/sit ... H3YTLC6165

The MC68000 is the first implementation of the M68000 16/-32 bit microprocessor architecture. The MC68000 has a 16-bit data bus and 24-bit address bus while the full architecture provides for 32-bit address and data buses. It is completely code-compatible with the MC68008 8-bit data bus implementation of the M68000 and is upward code compatible with the MC68010 virtual extensions and the MC68020 32-bit implementation of the architecture. Any user-mode programs using the MC68000 instruction set will run unchanged on the MC68008, MC68010, MC68020, MC68030, and MC68040. This is possible because the user programming model is identical for all processors and the instruction sets are proper subsets of the complete architecture.

What does this mean for the Genesis? Let's review:

1. It is a 32 bit microprocessor sitting on a 16-bit-wide *DATA* bus.

2. The 68000 implements a 24-bit *ADDRESS* bus, allowing it to address up to 16 MB of physical memory.

3. Address storage and computation used 32 bits, however, with the high byte ignored due to the physical lack of pins.

4. The internal data registers are indeed 32-bits.

This was a great CPU architecture design with forward thinking and compatibility in mind. There's good reason it was widely used and is still being used today. The SNES would have been a beast with this processor. You can blame that design decision on the fact that the SNES was supposed to be backwards compatible with the NES. Otherwise, there's just no good reason to have selected the 65816.

Hope I could clear up this debate for everyone. No applause necessary.