SPC700 & ARAM - Super Nintendo Entertainment System Features Pt. 10

[@mikukumiku]

I find it oddly amusing the way the APU and SNES (CPU) communications were animated. That is perhaps some of the most incessant yet polite exchanges I've ever seen.

[@kyliewolfe]

I’m guessing this separate processor then is why the music keeps playing even when the game crashes. Fascinating stuff, thanks for the awesome (as usual) vid!

[@RonWolfHowl]

Same thing for the Nintendo DS when the cart is removed.

[@msklywenn]

@@KieferSkunk If I recall correctly, the behaviour is manually implemented by the developers. The game could totally run from RAM without the cart. Except if it was streaming from it, of course.

[@canebro1]

Also why that happens sometimes with PCs, sound will keep playing even if the GPU crashes, and sound will loop for a bit if the CPU crashes.

[@paulstelian97]

​@@canebro1 I'm actually porting a sound driver to various platforms belonging to the company I'm employed to. Basically, it's a 64kB buffer in the DSP memory which the DSP keeps playing and it's waiting for that memory range to be updated by the CPU (but a crashed CPU won't actually update it) so it will just find the same PCM data and play the same thing repeatedly. Nobody will announce that there was an underrun either so the DSP doesn't know the sound data is invalid. I have heard that effect quite a few times during development until I fixed some performance issues with the on-DSP code.

[@RonWolfHowl]

@@paulstelian97 That's interesting. Couldn't it just use a counter / parity bit of some sort to check whether the buffer was actually updated, and stop playing if it hasn't been updated in a while?

[@TheCasualSubculturist]

Nintendo and SONY in one chip. Dogs and cats living together, MASS HYSTERIA!

[@iProgramInCpp]

Is that a Ben Heck reference? Because I got it as one.

[@burritoman2k]

Might be an AVGN reference, could've swore he said something similar

[@Darxide23]

"Dogs and cats living together, MASS HYSTERIA!" is a Ghostbusters reference, you uncultured swine.

[@Sheevlord]

I guess I have to be that guy who brings up that Nintendo and Sony had a partnership once. Nintendo hired Sony to develop a CD addon for SNES - but eventually the deal fell through, and Sony decided to develop their own CD based console - the Playstation. And since Ben Heck was mentioned here I should note that a while back he repaired and showcased the only prototype of the CD-enabled SNES in existence.

[@iProgramInCpp]

@@Darxide23 okay

[@GeneralBolas]

The relationship between the SPC700 and the CPU/PPU in the SNES somewhat mirrors the relationship between Sony and Nintendo in the videogame industry. They're both part of it, they're both important, but they don't much like each other and try to communicate as little as possible. When they do talk, it's in a very strained way.

[@johneygd]

GeneralBolas Aha No wonder those send & recieving signals between the cpu & spc700 chip could collide with eachother once they share the same 4bit halfduplex port,hahaha BTw you made a great statement, those chipsets inside the snes really tells alot about the weird relation with sony & nintendo and with eachother, but also the estaetic graphics & sounds will do give you a puberty feeling, something in between being a child and being an addult,, it’s like having a balance between good & evil,

[@mrmimeisfunny]

Also they don't interrupt each other.

[@paulstelian97]

@@johneygd CPU with SPC have 4 full-duplex byte-wide channels. Not half-duplex.

[@zerobyte802]

It may mirror the SONY/Nintendo relationship, but this was a pretty typical configuration for a dedicated Audio CPU, such as was common in arcade boards. In fact, those were even more isolated than the SNES CPU/APU. I've been messing with Capcom CPS-1 (Street Fighter II in particular) and it's much more isolated. There are two 8-bit latches used for the CPU to send messages to the APU. The APU cannot talk back to the CPU as far as I know. The APU just buffers the commands in its own dedicated RAM and gets to them when it has time. The "protocol" is dead simple. CPU sends a number (0-255) to the APU on the first latch. Each number corresponds to a particular song or sound effect, whch the APU just starts playing until it gets a "stop music" command ($F0). If the number is a different song than the APU is currently playing, it just stops playing the previous song and starts playing the new one. If it's a sound effect, it just plays that sound. The SNES needs the bootstrapping protocol because the cartridges can be changed, so the game has to send the audio data and music player software to the APU. Arcade machines just had one game's ROMs plugged directly into the board, so there was no need for this. The APU had its own RAM and ROM, and it just booted up ready to rock. It just sat there silent until the CPU put, e.g. $01 on the latch so the APU would start playing Ryu's stage music.

[@_notch]

This is my favorite youtube series. Easily.

[@Aunarky]

Holy shit, you watch him aswell?! good taste

[@NatetheAceOfficial]

RGME's smooth tonal voice is my zen.

[@reddragoncats1732]

I REALLY hope you discuss how SNES music is made very soon. People have been trying to figure it out for a long time, and there have been videos regarding this subject, but most don’t do a very good job. You provide a much better explanation of SNES features compared to anybody else.

[@Plasmariel]

It is made using a program that uses samples as notes, it has only 8 channels max to work with, but the most brilliant minded composers find incredible things like sound illusions to make it sound better. There are three audio modifications possible: The Echo=Used in nearly any SNES game, does some kind of reverb without taking the space of another channel, the FIR Filter can do many audio compression method that changes the sound for a more complete and polished final product. The Noise=This one is used to distord sound and reduce the bit quality of the sample, like transforming a high analogic pitch bend into wind. The Pitch Modulation=The most rare and unused of the three, most game composers didn't even knew it existed, it can be used to reverse the waveform to create a sort of dual note and other effects. You had only 64kb of Audio RAM, so the samples needed to be incredibly tiny and re-used to not take too many space aviable, most of the samples are used in the game.

[@reddragoncats1732]

Plasmariel Huh, interesting. How do I copy your comment on a mobile phone?

[@Plasmariel]

hmm

[@Plasmariel]

I don't know i actually never tried

[@Plasmariel]

Other things, the DSP of the S-SMP is the real 16-Bit sound, the more famous SPC700 only produces 8-Bit sounds. There is exactly 256 values of Stereo from left to right (-64 to 63).

[@mrmimeisfunny]

Can someone explain what the INC $01 does? Why does it increment that address when the counter is 0? Edit: Figured it out. It is the high byte of the pointer. And because it knows it overflowed it adds 0x100 to the address so it won't clobber any data.

[@Madsy9]

I'm currently working on a SNES SDK I hope to release when it's feature complete and beginner friendly. What's currently done: * GNU binutils toolchains for the 65816 and SPC700 CPUs. This means we have gas and ld for both of them, as well as all the other nice binutils utilities such as objdump and objcopy. * Our own build of the Tiled Editor for laying out tilemaps * Custom tools for converting image formats to the SNES' indexed-color interleaved bitplane formats, and correctly adjusting the tileset size. * Linker scripts, include files for common hardware registers and constants, startup code, macros for common operations such as initializing graphics modes. * A simple mode 4 scrolling example The next step is to make a simple music tracker which exposes the SNES APU capabilities, and I have been looking for audio and GUI developers in this regard. If anyone think this sounds interesting and you have experience from somewhat similar projects, give a shout my way. Otherwise I'll end up coding my hacked together tracker in ncurses, and no one really wants that ;-)

[@surrodox]

GST大好き is appreciating your effort to touch the sound chip.

[@MrBizznessMan]

I almost had a heart attack when I read SPC as SCP

[@littlesinners1944]

Tbh same

[@RandomPerson964]

Hmm, yes. Computer go bip boop make pretty sounds.

[@genericrandom64]

RandomPerson964 no no no it goes beep bip not bip boop

[@tchitchouan]

Boop boop beep

[@genericrandom64]

Tchitchouan Inouane bip beep

[@kimgkomg]

Beep boop boop bop

[@renw9876]

...yeah, this is pretty much how i feel right now. my brain hurts. lmao

[@rtyuik7]

i gotta admit, i cant keep up with all of the jargon used in these videos (for the record, i have Absolutely Zero experience with programming or coding, which is probly WHY i cant understand much of these videos)...but the little diagram of the SPC and the SNES 'talking' to each other makes a lot more sense to me..."Is this byte #$00? Okay, receiving byte #$00; Received byte #$00"...that kinda stuff helps a lot, so id definitely suggest using more lol...you gotta break it down a little smaller for simpletons like me xD

[@KuraIthys]

So... Time to build a frankenstein of a system... Pull the audio chips out of a playstation... Wire up the graphics system of a Neo Geo to a series of 4 SNES PPU chips... Then combine with a 65816 and an ARM chip just to create something truly absurd... And then marvel at your monster that serves no purpose whatsoever since no software exists for it. XD Though this is mostly a joke, I do wonder sometimes about how far you can abuse the SNES chipset to do things the SNES itself does not - for instance, the PPU's external video input, which is currently fed into itself for mode 7 tile priority, seems like it should allow you to combine multiple graphics chips together into a single output. Even if that isn't the case of course, it's possible to take the output of multiple chips and build a circuit to combine them - similar to how the PPU 'sub/main' screen system combines things... Throwing in Neo Geo hardware was even more of a joke, although the Neo Geo is basically a monster of a sprite engine, while the SNES does backgrounds pretty well (And sprites are it's weakest point...) The Neo Geo is just plain weird, honestly. EVERYTHING is a sprite. Even the backgrounds. But meanwhile the way sprites are set up sits somewhere between a typical sprite in other systems, and a small strip of a tilemap image... Since the Neo Geo sprites are 16 pixels wide, but you can draw 96 of them on a single line, while the screen is 320 pixels wide, this works out to be the equivalent of having 4.8 layers to work with. Even more interesting is how it manages sprites given it only has a 12 mhz CPU if it needs to manipulate them even to draw background layers... Seems there's one very basic trick that makes this work - aside from the fact that sprites can be anything from 16 to 512 pixels tall of course. That's the fact that each sprite can be set to be 'sticky'. Which means if the next lowest numbered sprite in the sprite table is on it's left, it will move if you move the sprite. Thus if you have say, 30 sprites all aligned, with all but the first being set to 'sticky' You can move the entire block of 30 sprites as if it's a single object just by altering the coordinates of the first sprite in the group... Thus explaining how the system copes - you can essentially create truly HUGE sprites that can be manipulated as if they're all one object... Retro hardware is pretty weird... But in a good way...

[@intron9]

Check out arcade machine hardware, like when you boot a name game . Chip after chip with dedicated roms and then you add an mp3 player chip there.. and etc..

[@KuraIthys]

@@intron9 lol. Yeah, arcade boards are often whatever they happened to feel like at the time. Though several companies did make 'standardised' boards over time. The Neo Geo of course being a really obvious one because they pretty much advertised it to players. But Capcom also had 'standardised' boards, and Sega of course had many... But yes. Custom designs were equally likely... XD

[@gizaha]

What's PPU's external video input? I didn't knew this.

[@gizaha]

@@KieferSkunk Are you refering to the ext port, or transfer data from the cartridge slot? Can it overcome the dma speed bottleneck to vram?

[@SuperSmashDolls]

@@gizaha The SNES PPU has an 8-bit input that was intended to be used to stream video into during Mode 7. They wired it up to mirror half of the RAM word on retail consoles, so it's not particularly useful outside of getting an "extra" background layer in Mode 7 (hence why it's called Mode 7). It's a damned shame as there's no way to access these pins from the cartridge and thus DMA is the biggest bottleneck to getting things on the screen. Interestingly enough there's a similar function on the NES PPU as well. There's a 4-bit I/O port that can be used as either a background output or input, and this can be used to chain two PPUs together. This is also unused... though on the NES, you have the PPU data bus right on the cartridge port anyway, so you can stream video to it that way. See suckerpinch's "Reverse emulating the NES to give it SUPER POWERS!" video if you wanna know more.

[@Ghomaghity]

What timing... I was just researching how the APU worked yesterday, and watched a video where someone wished you made a video about it lul

[@raafmaat]

just out of curiousity, what do you need this info for? are you planning to do any reverse engineering or something? ^^

[@Ghomaghity]

@@raafmaat I'm planning to making my own .spc player, which requires decent knowledge of how the SPC700 works.

[@raafmaat]

@@Ghomaghity sorry, what is a .spc file?

[@Ghomaghity]

@@raafmaat Basically, it's a capture of the APU's memory that can then, with the right software, be played back like a music file.

[@Sheevlord]

@@Ghomaghity Sounds like a fun project. Good luck!

[@TheotherdaysNet]

Excellent presentation of the SPC700 inner mechanics! 0.5x playback speed helps to realize the extent of the efforts you put in crafting such accurate, in-depth and content-focused videos. Thanks a lot for your insightful and highly qualitative work!

[@vuurniacsquarewave5091]

As someone who got into programming these old systems mostly due to the audio, the SNES has always been that boogeyman I would never want to really mess with, and it's explained exactly why in this video. It's just such an overcomplicated protocol compared to what you need to do on either competitor's system. The actual audio capabilities are fine, it sounds like an interesting challenge to use them but I have always found this communication part too dauting. On the Genesis the secondary CPU (Zilog Z80) can access 48k of cartridge ROM directly at any time (can be mapped to ROM in 16k banks), and for communication the main CPU (Motorola 68000) can turn off the Z80 at any time and directly write to its RAM. The Genesis only has 8k of "sound RAM" in that sense but that is far more than enough for most sound applications because it only needs to hold sound code variables, the rest of it, which are samples (if there are any, the synth can do just fine on its own), the sound code itself and the music data come from ROM directly. The PC-Engine is even more straightforward than that because it's just a wavetable PSG integrated into the CPU directly, with memory mapped registers, there is no secondary CPU. But the CPU itself runs at twice the rate that the SNES CPU does, and also doesn't take as many clock cycle per instruction as the Genesis CPU. The sound itself is "older tech" though, it's just 6 channels of configurable short waveforms, so it's more versatile than the NES but definitely not as powerful as the SNES.

[@andre_601]

I don't know why I still watch those videos. I don't understand a single thing explained here and even if I understand it somehow do I forget it real quick... I probably watch the videos because of the smooth animations and visualizations.

[@lumps17]

It always brightens my day when Retro Game Mechanics uploads.

[@nintentyr2355]

I don't fully understand everything you're saying, but I greatly enjoy the breakdown and all the technical information. Keep up the fantastic work

[@Tiranice]

I had to design a circuit a bit like this in software in college. It made a saw and sine wave hums.

[@koopa1018]

Maaan. It's a good thing I'm a fan of technical stuff, because this flies right over my head.

[@jonathanfaber3291]

Question for the ASM nerds: what's the difference between the labels starting with a period (like ".retry") versus the ones that don't (like "Start")?

[@sakuyaizayoi4672]

The difference is a kind of scoping mechanism used to reduce the number of different names required. Labels without dots cut the source into "sections". Inside each section, the labels with a dot are local to the section. So for example you could write Start .loop Main .loop but not Start Loop Main Loop

[@jonathanfaber3291]

@@sakuyaizayoi4672 Ah! Thank you

[@Madsy9]

What Sakuya Izayoi wrote, but it depends on the assembler. GNU as has no scoping for labels, but you define sections with the ".section" keyword.

[@glenndoiron9317]

A bunch of replies here already, but to the assemblers of the day, it indicated that the label had "local" scope. The scope of a local label was defined as any instructions between the previous and next "global" scope labels (labels were global if they did NOT start with a period). Those instructions were the only ones in your program which could "see" the local label and use it. All global labels had to be uniquely named within your ENTIRE program. All local labels had to be uniquely named *within their scope*. Local labels in a different scope could have the same name. In this case, a reference to the label would return the address of the label within the instruction's scope. Attempting to reference a local label which was not defined within the current instruction's scope (see first statement) would produce a compiler error. For instance, this allowed you to use labels like ".loop" every time you performed a copy operation (assuming that you only cared about entering your subroutine from the beginning). You would use a global label at the start of your subroutine (so that you could JSR into it from anywhere in your program), set up your registers, then use a local label ".loop" to define your loop entry point, copy a byte, increment your register(s), check to see if you needed to run the loop again, and if so, branch back to ".loop". You could do this in every subroutine that needed to loop using the ".loop" local label as long as you started the subroutine with a global label, which would break scope with any local labels that were previously defined, so you didn't have to run back through your source code and make each loop label different across your entire program.

[@luisgonzalez5482]

These videos might take forever to wait for in between. But GODDAMN is it ALWAYS worth it.

[@fdwr]

Wish informative videos like this existed 20 years ago when I first wrote my SPC700 emulator >__

[@WishMakers]

I will admit that with my interest in things like FamiTracker that I was more interested in the audio processing itself, but it astounds me just how slow the data transfer is as opposed to DMA and other data transfers for game assets. (Even though the SPC most likely couldn't handle something like that in the first place.) Speaking of FamiTracker though, I would be really interested in a video on Famicom expansion chips if you felt confident in covering them at some point. Looking forward to the next episode!

[@KuraIthys]

Keep in mind the process described is only what the bootloader ROM does. It's only used to do the initial transfer of your custom audio program. music playback routines are free to use the APU ports any way they like. It's possible to do DMA (and even HDMA) to the APU ports, given they are present on bus B. The problem of course being that if you use DMA to write to the APU port then the SPC-700 somehow has to keep up, and you can't really check if the transfer has any problems... Certainly you can do a lot if you try. - Tales of phantasia clearly streams audio data from cartridge to APU in realtime... Also worth noting that you can write to the APU during periods that you cannot use to do DMA to the display; The APU ports can be written to at any time without disrupting anything. While you have to ensure any manipulation of PPU data happens during H-blank or V-Blank to avoid screen corruption. While of course it does consume CPU time you could use for general purpose calculations, audio transfers can happen alongside graphics data updates since they can happen during different parts of a frame. I'd say the hardest thing about advanced audio routines is deciding on a protocol for communicating between the two processors. As to streaming audio... You can either use ADPCM compressed samples - in which case a block of 16 samples takes up 9 bytes. Or you can abuse the echo buffer to write uncompressed 16 bit audio. Since the audio rate is 32 khz, there should be 64,000 samples a second either way. (obviously uncompressed streaming audio is impractical on a cartridge that may only be a few megabytes in size; a CD only holds about an hour of music on 600 megabytes after all) This puts the required data transfer rate for streaming (mono) audio at about 128 kilobytes/second for the uncompressed stream. And about 7 kilobytes a second for a compressed stream, which is easily achievable, though the uncompressed stream means you run out of APU memory pretty quickly. (max buffer size less than 0.5 seconds) - but you can easily buffer multiple frames worth of audio... A compressed stream meanwhile can buffer something like 8 seconds of audio. If you can't update 7 kilobytes of data a second when you have an 8 second buffer to smooth things over, you're doing something badly wrong. XD Someone should look into Tales of Phantasia's audio driver, honestly... It does some stuff pretty much no other SNES game seems to with audio... So anyway, this data transfer method, fascinating though it is, is NOT what games use while playing audio. It's the bootloader. And honestly even without DMA and with the need for sync code, 64 kilobytes of data shouldn't take forever to transfer. Even if it's as slow as 100 cycles per byte written (from the 65816's perspective - which... I doubt optimised transfer code would be that slow) you would be able to write 40 kilobytes/second to the APU... Which is a fair bit if you're clever about what you do with it...

[@KuraIthys]

@@KieferSkunk True enough. But there's plenty of examples of interlacing code in exactly that kind of way on older systems. The easiest would be relating it to vblank timing. The PPU line counter interrupt could also ensure you switch to doing an audio transfer at a consistent point each frame. As long as you're not also doing several other timing critical tasks... I mean if you work with 8 bit systems you have much worse audio timing problems. Try doing audio sample playback on an atari 800XL. The hardware provides rudimentary support for it... But you somehow have to time CPU writes to audio registers to happen thousands of times a second. (again, easiest approach is using display interrupts to time it.) Interrupts in general are your main tool here. And the graphics chip usually your main source of timing info, since it repeats the same pattern over and over and in almost all computers there are some measurable timing sync points in the graphics system...

[@KuraIthys]

@@KieferSkunk Kinda surprised though that devs would use that bootloader code or an equivalent so often though. Guess there weren't many experienced audio programmers from the 8 bit era working with it. (or they couldn't be bothered with anything complex. Understandable I guess if the results of doing it the 'easy' way are good enough)

[@BubblegumCrash332]

I'm not a programmer but I could watch these videos all day. 👍👍👍

[@CanoTheVolcano]

I have a repro cartridge of EarthBound on the SNES, but never played it because it was always more convenient to do it on 3DS or Super Nintendo Classic Edition. But this series got me to pull out my SNES again play EarthBound on it's original hardware because I had a new appreciation for how all these different parts come together to make one game

[@kailastnam9793]

I didn’t even know daughterboards were a thing until this video.

[@andrewjustice003]

Visualization is Very Good!

[@jennasloan396]

Gosh, this audio subsystem seems overly complicated. It's crazy to think that the SNES had dual processors. Are there any video games that use the audio processor for things other than just audio, like maybe as another CPU?

[@Budch]

Yes, probably DOOM use A-subsystem for driving 3D

[@Sheevlord]

It's not that uncommon in the game consoles of that era. For example, Sega Genesis (AKA Megadrive) also has 2 CPUs: Motorola 68000 and Zilog Z80. The former was the main CPU that ran game code, while the latter had two purposes: normally it would control the sound, but it was also used for backwards compatibility with Sega Master System games.

[@GeneralBolas]

Sound processing is a concept that is very amenable to being handled by a separate computational element. There are several factors at play: 1: Timing. In order to play a sound correctly, you *must* get the signal data to the DSP at exact, regular intervals. Human hearing is *really* good at spotting pitch, and we're talking about upwards of 20,000+ cycles per second. If you can't compute the right sample value(s) at exact, regular intervals, the player will hear it. 2: Complex, overlapping sound is pretty processor intensive, but overall simple to do. You're just figuring out which sample to fetch for the sound data, possibly interpolating between multiple samples, multiplying that sample by the volume, adding multiple sources of samples together, and that's your sound for this period of time. It's time consuming, but overall it's just simple math. 3: Sound is very input-to-output. That is, you get some data to send, do some processing on it, and you send it. There is no need to communicate back to the system that told you what sound to make; you just make the sound. This means the process can be asynchronous. 4: Sound is one-and-done from the CPU's perspective. All the CPU needs to do is say "play this sound" or "play this series of 'notes'" or whatever. It doesn't need to think too much about it after that. Music itself can be seen as a sequence of operations on digital instruments. All of these factors add up to a scenario where having a separate processing element makes sense. As to why it should be a full-blown CPU rather than something more restrictive, well, that's the nature of the beast. 3D graphics chips used to be highly restrictive, with no actual programming elements. Now, they're largely programming elements, with a few bits of fixed hardware. As we get more transistors, we tend towards general processing solutions, not specific ones.

[@AiOinc1]

ayy I had the same thought

[@AiOinc1]

@@Sheevlord The Z80 in the Genesis also read the controllers as well

[@Scoobdashoob]

I cant quit watching your videos but they make my brain hurt.

[@renw9876]

man, is this a mood. i've been watching all day. my brain is pretty well mush at this point.

[@aldolopez9564]

Beautiful, just beautiful.

[@colinstu]

I wonder if the example being shown is an actual song from a game or something... or if it's just random.

[@Lovuschka]

Not to be confused with SCP-700. That'd be a pretty old building.

[@mashmachine4087]

So excited for more stuff on the sound chip!

[@noravanguard]

2:51 so you're saying that Nintendo shoved darkside phil into the SNES

[@LQ_LQ_LQ]

Thanks again for this great video (and your helpful mail)! I'm about to implement the SPC700 into my emulator right now, and might even think about running it on its own thread after seeing the communication :)

[@domeshtan1677]

I'm still struggling trying to add sound in my SNES homebrew game (trying to understand the code generated by SNSEGSS and getting it to work properly with wla_dx) Nothing working yet, but your videos are total magic for understanding how snes hardware works. The descriptions and animations are top notch when it comes to explaining things. Had to rewind a few times but the concept of how the SPC700 works is sinking in. Great work. Hope to see more.

[@ThisuraDodangoda]

Amazing visualizations!! I greatly appreciate the work you have put into this video!

[@xylexrayne8576]

I absolutely Love the SNES APU. You have helped me discover a way of driving one with an Arduino. :D

[@proxy1035]

yes, another great video to watch! man i'm really hoping you do this for the NES as well (though there obviously is less to cover)

[@scottpelak1856]

Can you add a video about SNES software? I love seeing the hardware explained, and I'm curious how to approach writing an SNES game from a developer's prospective, e.g. is there an SDK that helps take care of some of the magic numbers? How low level do devs need to code? I love your videos!

[@RGMechEx]

It's a work in progress 😉

[@KuraIthys]

How low level? XD The official SNES documentation is basically just a list of the hardware registers that exist, what they do, and some notes on any quirks they have. SNES programming is generally done entirely in assembly with direct addressing of the hardware registers by code. There's no libraries to speak of. No OS. No api, no SDK... Just direct manipulation of the hardware at a low level. This isn't surprising because it's how development worked on most 8 and 16 bit systems. Even where higher level tools were available, game developers tended not to use them since it was just too slow...

[@billmoran5957]

65c816 Assembly. Here ya go. wiki.superfamicom.org/

[@lustechsource5197]

Another informative video! Looking forward the the full video on the SNES's sound subsystem.

[@Elayzee]

Wow, game development was just so much more interesting back then than today. What they were able to accomplish with such primitive and limited resource amazes me, especially in the audio department. Now days all I ever seem to hear a developer say is "we're using Unreal Engine 5" and....it just doesn't impress me the same way.

[@TrebleWing]

You have a deep understanding of so many of these console's aspects. Are you currently working on any assembly projects? I would be interested in following if you are. I code assembly for NES but love all this stuff, even with the SPC syntax

[@RGMechEx]

I've been wanting to make a game from scratch for a while now, but haven't got around to it. I do have one assembly project I work on semi-regularly, which you can find on my Github: github.com/Dotsarecool/SMWPracticeCart

[@recklesflam1ngo968]

These iare quite helpful, as I'm currently learning 6502/65816 assembly!

[@rollmeister]

Apparently DKC music was so hard to do, they got some genius who figured it out and spent months porting each song to the SNES sound system.

[@explodoboyv2]

I click on this video expecting another fabulous reading on the Shark Punching Centre's 700th SPC, but I'm not disappointed on what I clicked on, either.

[@AnarchoTak]

Amazing series I love your Channel

[@root42]

The SPC assembler looks a lot like x86 assembler.

[@urbaniuscee3657]

brilliant video as always! thx

[@alynnzz0491]

"Although the APU comes bundled with this boot-" *I pause to do something*

[@xanbeth]

I've been waiting for this :)

[@SLZeroArrow]

And all we need is one more part and there we have it, unless part 11 also gets split like some of the parts here.

[@EuclidPlaceRecords]

my man i hope youre getting college credit for all these vids

[@paulstelian97]

For the one who threw the first dislike... May your job be writing games for the original NES until retirement!

[@paulstelian97]

@@slightlyevolved That one I don't know but okay :))

[@johneygd]

Ahahaha. But apart from that, if software is soooo hard ,slooow & complicated to write then how could it be that there’s sooooooooo msny games released on soo many systems withing 5 years?? How could it be assambly code sounds as intercalaptic as it can, pfff.,

[@paulstelian97]

@@johneygd Lack of alternatives and thus enough man power invested into it

[@canebro1]

For a video like this I usually assume it was a miss-click and those 9 people are blissfully thinking they actually left a like

[@billmoran5957]

That's my dream job.... 6502 ASM is elegant and beautiful =) ....shoutouts to NESdev!

[@romajimamulo]

I wonder how many games just used this to load their own data loader, vs how many games decided to use it after boot

[@minermemecoffee8256]

I like your funny words, magic man.

[@palmenros]

Really loved the video. Any time estimates about when the new series about the SPC700 will be released? ;)

[@guspolly]

This is nothing you could have forseen, but KZbin's image processing just does not seem to like the color you chose for the background. I assume it was supposed to be a solid color, but it's been turned into a checkerboard pattern, sometimes flashing noticeably.

[@kaioocarvalho]

It looks solid dark grey to me.

[@RGMechEx]

Yeah, that has been an issue for the past few videos now. It takes like a week or more for it to process correctly for some reason.

[@mrmimeisfunny]

@@RGMechEx What color is it supposed to be? (in hex)

[@guspolly]

​@@RGMechEx It looks like that second pass went through now. I can see the very subtle camo-looking pattern. I bet the colors were too similar for the first pass and it just went ‾\_(ツ)_/‾

[@amazingagent1404]

oooo new video

[@artherius535]

Are you ready yet? Are you ready yet? Are you ready yet?

[@RonWolfHowl]

*_WE'RE GETTING THERE BOIS_*

[@Aikisbest]

Now that this edutainment series is coming to a close, I feel kinda sad in the same way you might be when reaching the end of a good book where you really like the characters.

[@LeviathanRX]

I'm ready to receive the first byte

[@jefflinahan5853]

At 3:00, all ARAM access from the SPC700 actually goes through the DSP.

[@uncoherentramblings2826]

Very good video!

[@johneygd]

Now that’s really really mind blowing how the cpu & spc communicate with eachother using 4 4 bit ports switching per 1byte per turn, it’s mind blowing that so far no signal collision happened and no game crash, the atari lynx comlynx port works in a similar way in that both the send & recieve signal shares the same wire in a alternate way to get around the half duplex limitation of it.

[@samfortunato]

You are an absolute legend. Any plans to do videos on the N64?

[@ToriningenGames]

Merely a "what-if": Wouldn't it be neat if the SNES did up its sound processor design like the NES's PPU? That is, each cart had dedicated pins (and probably a ROM chip(s)) that fed directly to the APU system and ran independently from there. Then, the cart could contain RAM and arbitration hardware (well, the expensive ones, anyway) and kick up both the CPU and the APU in power. Does anybody know of a system that exposed its sound subsystem to the cart directly, beyond the "Audio In" line style like in the Famicom & Game Boy?

[@YaveYu]

SNES SPC is a fantastic thing... On emulator we have four interpolations, gaussian is close to real hardware but eats high-freq, cubic and sinc aren't eat high-freq.

[@wChris_]

The bootrom you explained was a bit unclear to me, maybe you could have added the SPCs registers to know a bit more wat was happening and maybe in parallel a simple CPU program that could talk to the spc. But i don't know if the cpu program would be too much to understand all of it.

[@Dr_Mel]

Have you received the header yet?

[@samuelthecamel]

Are you ready yet?

[@FlameRat_YehLon]

So the question is... Will it be faster if hardware interrupts are used to sync the communication, rather than using the routinely checking method? It would mean one interrupt channel each taken from both chips, though...

[@mrmimeisfunny]

The SPC must not support interrupts.

[@RGMechEx]

This is the case unfortunately. The SPC700 instruction set has instructions related to interrupts (DI, EI, RETI), but the S-SMP and S-APU chips either don't connect the interrupt pins or just don't implement them in the first place.

[@mrmimeisfunny]

The audio code is very precisely timed and an interrupt might cause an audible glitch.

[@spicylemonz1333]

Lol i started watching ur channel since the video explain the split screen on pac man

Finally! :D

[@ozzie_goat]

I've been waiting.

[@AmyraCarter]

Imagine playing a large game like Final Fantasy VI without a separate SPU...oof...

[@ferociousfeind8538]

Is... is this what all CPUs are like? "Am I reading this right? Am I reading this right? Is this the second byte?" "Did you get it? I just sent it, be prepared to get it. This is the second byte." "Ok. I have the second byte. Is this the third byte? Is it? Is it the third byte?" "Ok... I have sent the third byte. Did you get it? Are you reading the third byte?"

[@MatthijsvanDuin]

The fact that the control flow is conditional on whether or not the address is >= $8000 after the "INC $01" seems really wonky to me. As far as I can tell, the overal effect is that whenever the "INC $01" happens (i.e. after Y wraps to 0), if the address is >= $8000 and the subsequent "CMP Y, $F4" reads a corrupted value from the io port (while it's transitioning from $FF to $00) that happens to be in range $01-$80 then it will break out of the transfer loop (i.e. fall through to Start) without having double-checked the io port value like it does normally (when "retry: BPL .data" is reached from the "BNE .retry" above).

[@MatthijsvanDuin]

@@KieferSkunk Doing it correctly wouldn't require anything other than making sure it jumps unconditionally to .data after the "INC $01" ... but I do now realize that space limitation is probably the reason: this code already takes up all 64 bytes of ROM. Still, I'm pretty sure this minor rearrangement of the .data loop would fix the problem without any penalty in code size or performance: E4 F5 .data: MOV A, $F5 CB F4 MOV $F4, Y D7 00 MOV ($00)+Y, A FC INC Y D0 02 BNE .wait AB 01 INC $01 7E F4 .wait: CMP Y, $F4 F0 F1 BEQ .data 10 FA BPL .wait 7E F4 CMP Y, $F4 10 F6 BPL .wait (unless I'm overlooking something, which is entirely possible since I had zero experience writing assembly for this cpu before today)

[@MatthijsvanDuin]

@@KieferSkunk Sure, I was just puzzled at why the control flow was like this because I was assuming the test being done (addr < 0x8000) was intentional rather than just incidental. I wonder if perhaps this bootloader was originally written under the assumption that the audio subsystem would only have 32K of ram, since then the code is perfectly fine.

[@EngineerDJ_Julius]

The SPC700 Player is amazing but I can't say the same thing about the company that made it

[@MetroidChild]

Any idea what the max average data transfer rate from the main board to the audio processor is? Like if we transfer using the default bootloader, or a custom loader that also transfers data through the other ports.

[@rlbond]

I'm a bit confused - you said that the I/O buffers needed to be denounced, but the SPC boot ROM doesn't seem to perform that. Couldn't that result in a transfer error?

[@Nikku4211]

Aw man, guess I'll have to wait until 2030 for you to start the SPC700 series.

[@TheMr77469]

Iam surprised that the ARAM chip had free space at all. I thought it would have been all utilized, or be co-opted by the Main CPU to share workload.

[@RGMechEx]

Most of the time it is utilized, especially when a song with echo enabled is being played. "Free" in this case meant more of "general purpose" than "unused."

[@Sheevlord]

To me it seems that without DMA it would be a huge hassle to utilize ARAM for anything not sound related.

[@KuraIthys]

The interesting thing about the modular nature of the early hardware is you can technically swap it out for anything else so long as the comm port design is the same. Makes me wonder if the audio hardware was a last second addition to the design. On the original SNES revisions they could literally have put any audio hardware they liked into the system even after the main system had already been designed and manufactured. It's literally an independent module. Can be swapped for something completely different even in finalised hardware. I mean you could do that even now with an early SNES... Swap out the Audio module. Build your own... Anything... Really makes it look like they built a generic interface, not knowing what their audio chip would be, built the rest of the system... Then added the audio chip at the last second.

[@KuraIthys]

@@KieferSkunk Considering the supposed story of how the SPC700 was designed by Ken Kutaragi in his spare time without informing his bosses at Sony, it doesn't seem so strange to think they didn't have much to work with until quite late... It's a pretty weird set of stories in general, honestly, when you look at the interactions between Sony and Nintendo and how that led into the creation of Playstation. Lots of things that could be true but sound strange enough to also be fabrications...

[@jotarandom]

When was Part 11 being released originally?

[@mrflamewars]

Great video. Still doesn't explain Plok - but then that can't be explained on a technical level at all, it's pure witchcraft and devilry!

[@pulsar6375]

Plok was just good musician(s?) + good quality samples + a good sound engine all in one.

[@pulsar6375]

@Kit Duguay yeah, some games did that I think waterworld did it too

[@KuraIthys]

makes sense. Once you truly wrap your head around the fact that your 'instruments' are all audio samples at heart, it shouldn't take much to realise the base sample can be multiple notes, or even multiple instruments. I mean, if you had the resources you could get an entire orchestra to record a chord and play that as a note... Now the true technical witchcraft has got to be the intro to Tales of Phantasia. That has full spoken lyrics somehow...

[@pulsar6375]

@@KuraIthys you can stream audio into sample data. Also yeah, big samples are possible but they're not the most resource efficient.

[@tchitchouan]

The SPC700 is the holy grail chip that made SNES music that much better than the Yamaha based genisus chip

[@mrflamewars]

I could never tolerate the Genesis/Megadrives' "Robot fart philharmonic orchestra" sound. It still grates on me to this very day. Absolutely hate it.

[@tchitchouan]

John yes it had a very gritty Grundy metallic sound which was good for hard rock and metal music not so much for orchestra and ensembles.

[@paulstelian97]

I find it funny that the actual code that runs after boot on certain games was never actually presented. Emulators must emulate this CPU as well, plus the DSP too. Whoever is making games for the SNES does need to know how the DSP itself works in order to write that code for the SPC...

[@aaendi6661]

Even though it's 100 times more frustrating to program. They should've allowed the main CPU to write to audio RAM and the DSP chip directly.

[@intron9]

@@aaendi6661 Aaendi hmm I'd say no, it takes like 2 seconds to fill entire apuram at it's worst case. Spc and dsp share apuram with a special clock divider, if they had mixed it with the rest of the snes which is more complex, it wouldn't have been worth the cost of hw design. Later with the n64 you have an unified memory. I wasn't there when they designed the apu tho , but that sounds like a bad idea.

[@fernandossmm]

Nice

When all processing units are "central," none of them actually are.

[@retroboyo4238]

Could you explain Gameboy Audio Samples? like the entire soundtrack of Project S-11 for GBC?

[@ssg-eggunner]

That's probaly just wavetable switch by tick Not sure if s11 uses overclock to get high sample rate I hope not

[@No-Me3]

This is all so far over my head. Why do I watch these?

[@mojoplayer8915]

Would be cool if you could cover other systems

[@sllvksacgsakjc9357]

Finally Ess pee see seven hundred

[@Sparkette]

SCP-700 is in the SNES?

[@renakunisaki]

This seems like such a poor design. Having to transfer audio data through such a low-bandwidth link that also has to be debounced... (Could you even avoid that with clever timing? I suspect not since the CPU and APU have their own clocks.) Why not allow to DMA directly to ARAM? Or do like the NES PPU and have ARAM/ROM on cartridge? Or even give us an IRQ so we don't have to poll? Heck, let me bypass the SPC and access the DSP/ARAM directly, which also frees up the SPC to do math, which is much better suited to such a slow connection. The cartridge bus does have audio inputs (the Super Game Boy and MSU-1 use them); I wonder if any game ever did just pipe all its sound through those instead? Maybe not practical back then, but an interesting idea now...

[@GeneralBolas]

Given that Nintendo didn't develop the chip themselves, I don't think the design was a choice so much as "that's what the chip requires." Direct DMA would have required it to be integrated into the SNES's DMA-driven busses, which would undoubtedly require a chip designed for such integration. Tighter integration would likely have required the chip to be developed in-house by Nintendo, or at least it would have made the SPC700 less able to be used for things that aren't the SNES.

[@Sheevlord]

Probably this design was chosen to keep the cost and complexity down. It's not an elegant solution, but in the real world inelegant solutions are used quite often. For example, if you have a USB mouse then your computer is constantly polling it for data because a USB device cannot generate an interrupt. The only way for the USB host to tell if the device has new data for it is to constantly ask.

[@renakunisaki]

@@GeneralBolas I imagine you could "pause" the SPC while the CPU accesses ARAM (via DMA or not), without having to change its design. I'm not sure, but it seems like it should be possible.

[@Madsy9]

Overly complex and limited design, sure. But very cost effective. The shared interface is extremely simple hardware-wise. All you need is two pins (RX, TX) and common ground.

[@KuraIthys]

@@KieferSkunk That's misleading. clock speed is not the be all and end all of performance. the SNES cpu isn't as slow as you think it is. While not a factual statement, steve Wozniak, who of course designed both the Apple IIGS that uses a 65816 and the Mac built around a 68000, claimed that the 65816 was as fast as a 68000 running at twice the speed. (certainly clock for clock the 65816 has twice the memory bandwidth, in spite of using an 8 bit bus instead of 16 bits like the 68000) obviously take such remarks with a grain of salt. But the 65816 isn't as slow as you might think. Also worth noting the APU ports are in the memory range that the SNES DMA and HDMA engines can write data to. This means you can DMA to the audio system, but since this isn't direct access to the APU memory, nor a dedicated memory port like the PPU, and there's no DMA on the APU side, this would be very difficult to use effectively.

[@novameowww]

How many times during recording this did you accidentally say SCP-700 instead

[@PhyChris]

Love your videos! how much ARAM can the SNES address? can the sound ram be upgraded?

[@GeneralBolas]

Upgrading the ARAM is highly unlikely, since it undoubtedly lives in the SPC700, and the SPC700 is largely isolated from the main memory busses of the SNES.

[@PhyChris]

@@GeneralBolas Cool, when i look inside the sound module in my old SNES there looks like a few unused pins on both chips. thought one might be an extra address line.

[@Madsy9]

The SPC700 has 64 KiB memory total for its bootloader, UART/serial-like interface, samples, DSP instruction data (notes, volume, panning, effects), echo/reverb buffer and overall music code. Its memory is totally separate from the 65816 CPU's memory, and neither processor has direct access to the other CPU's memory bus. The two CPUs must communicate over a serial-like interface by using hardware registers which they read and write. And the SPC700 memory can not be extended by additional memory on the cart. So what games typically do is to first upload the first program to the SPC700 using the SPC700's bootloader. Once that is done you can start the SPC700's program entrypoint and you don't need the bootloader anymore. From there on, the ARAM contains a full music player, and the SNES CPU uploads samples and pattern data to the music interface every time the game wants to switch songs. One or two channels and some samples are usually always left untouched and reserved for game sound effects. The music player SPC700 side and SNES 65816 side work together in a master-slave fashion by implementing a kind of RPC command interface. Other games (some Final Fantasy games I think) go even further and stream new patterns and samples to the SPC700 while the SPC700 is already playing, in order to make more complex music scores with the limited memory. Those kind of players are impossible to capture/rip out of the game because they depend on the 65816 CPU. The infamous SPC SNES file format for music simply contains a snapshot of the SPC700 and DSP state (ARAM and registers) and plays it back by emulating the SPC700 processor and DSP chip.

[@PhyChris]

@@Madsy9 after some quick googling, people have 'hooked up' the SNES sound module/daughter board to an Arduino LOL

[@KuraIthys]

Given it's modular nature you'd probably have more luck just outright replacing the entire APU with something else if you wanted upgraded audio capabilities. The PPU is the only obvious component you can reasonably 'upgrade' directly in the SNES design. - it supports 128k of VRAM but only has 64k installed. This has no bearing on existing games but homebrew would be able to exploit this. 128k of VRAM would make the high resolution and high colour modes function better. It would also let you use more sprite data, and generally ease a few coding complications. Finally it would greatly benefit external processors that do graphics, such as the SA-1 and SuperFX. This is because a 256x224 fullscreen image at 4 bit colour depth about 28kb (but you are forced to use at least 2k on a tilemap) while the 256 colour modes would take up 57kb It thus follows that 128k of VRAM would let you double-buffer a fullscreen 256 colour image, greatly simplifying the rendering pipeline for any external device that is trying to draw graphics. Similarly, 256 colour mode can still use a tileset of 1024 tiles. However the standard 16 colour tiles take up 32 bytes per tile meaning a full set of 1024 takes up 32kb. While a 256 colour tileset takes 64 kilobytes, leaving you with no spare space for sprites, tilemaps and so on. (which 128k would solve) Basically 128k makes 256 colour and 512x224 resolution modes far less awkward to use. It's about the only real upgrade to core SNES hardware that makes any sense. For everything else there's less intrusive solutions. (both the cartridge and expansion buses have audio input pins that outright bypass the APU for instance. Want upgraded SNES audio? stick a chip in a cartridge and be done with it. No point messing with the APU...)