Correction 1: At 3:47, the registers to hold the number of bytes to transfer was corrected from $43-7 & $43-6 to $43-6 & $43-5. This was also corrected in the code at the left at 4:50. Correction 2: At 4:14, the binary number for transfer mode 1 "2 bytes to 2 registers" was corrected from 010 to 001. This was also correct at 6:50 and 9:50.
@@5nefarious I always assumed the took a section in front of the player, then skipped X numbers of pixels to distort it into the frustram for psuedo 3d - running the whole track / background, from a top down perspective, through the mode 7s ASIC is pretty mind blowing.
@@bryanl1984 A lot of racing games work roughly like that. But, I've known what mode 7 does for a long time. And yeah, mode 7 racing games work by altering the scaling/rotation parameters during H-blank for each and every line. You can do this manually with the CPU, but HDMA simplifies your job a LOT.
@@KuraIthys I knew in principle how it worked but, seeing it drawn line by line is pretty impressive and helped me understand it intuitively. For some time, I assumed there was more going on than the affine transforms and DMA - more like a super scaler. This video series shows you just how much blitters, DMA and memory manipulation can be used to create _GREAT_ effects. The irony of mode 7 is that the matrix ASIC that does the transforms was put in because the SNES was clocked at a dismally slow rate - in order to be backwards compatible with the NES, which obviously never happened. The NES was clocked at 1/2 the colour burst frequency (1/2 F) and the SNES was only 2/3 F. To put that in perspective, the _MASTER SYSTEM,_ a NES contemporary, ran at F and the Genesis ran at 15/7 F. In retrospect, it's probably a good thing considering how backwards compatibility has often encouraged developers to design for the lowest common denominator and then mildy spice it up for the better, more expensive and thus rarer systems. Just look at how much this sabotaged the Sega CD; probably for the best that Nintendo didn't pursue NES compatibility or we'd see NES quality games, only with larger color palettes. It makes sense form a business perspective but, it's a shame we never really got to see many examples of what a Miyamoto could have done with a true game on something like the SCD, instead of gimmicks. If you're into the SCD, there are some tantalizingly great games, just not enough of them. What's funny is that Nintendo is single handedly attributed with saving the gaming market after the crash of the 80's, which is dubious but, they invented the concept of a Graphics Accelerator to make up for the SNES' low clock; we have them to indirectly thank for the awesome modern graphics. They essentially had to put in mode 7 to get around the fact that the SNES was so much slower than the Genesis,PC-engine and Master System which were from the 80's. It's a shame they limited the ASIC to a background layer too. The Sega CD was more or less a contemporary of the SNES and the SEGA "mode 7" ASIC could be used on any data in the system, not just a BG layer. When people reminisce over what could have been if Nintendo and Sony had made a CD SNES, they overlook the Sega CD. On a hardware level, when the SCD is used the way it's intended, the SCD is by far the most impressive console of the 16 bit era. Too bad developers were so enamored w/ FMV trash instead of using it to add pre rendered elements and cut scenes as intended by SEGA. That and all the repurposed corelco games that were sitting around unused when their VHS game system got (rightly) canceled.
Even with two years of computer science classes, this stuff is still pretty dense. It really makes me appreciate how smart all the hardware developers were to design all of these features into a simple gaming console.
I've been coding for 8 years, and this is still super dense. Thankfully, stuff like this is really only for hobbyists, you never have to dabble in stuff like this unless you want to for fun.
@@davidmenlo9305 Not really only for hobbyists. Stuff like this is still awfully common in embedded system engineering and microcontroller based electrical engineering. You'd be surprised how many microcontrollers you still need to program in assembler because they don't have proper C support. It has come to the point where there is a real split in competences between high level and low level programmers. Low level programmers can't program high level and high level programmers can't program low level.
@@joey199412 I'd never considered that this wasn't always the case that there this significant division between low- and high-level programmers. However, it is logical that programmers who are used to working in less-developed languages would be better at low-level languages. To your point, as a C# programmer, if it weren't for general hobbyist stuff and assembly-based Zachtronics games (like TIS-100 or Shenzhen IO), I'd have no knowledge of it.
A game console we all know and love but that programming sound sooo complicated,time consuming and boring, i can hardly imagine that game devs had to work that way and doing all that within a scadual time, you had to think like a mad scientist in order to understand this,phew.
The crazy thing about all these scrolling visualizations at the end is that's *exactly* how all these effects looked on early ZSNES versions (like pre-2000s) when you used the simpler tile-based rendering instead of scanline based. Makes a bit more sense now.
This was stunning. My childhood dream of understanding the SNES is becoming a reality. I always thought the scanline modification stuff like the eye or the power bomb in Super Metroid was some kind of mode 7 + transparency, but they did it much more efficiently. I can't imagine the magnitude of the genius that created this system. In retrospect it makes sense, but the leap between the NES and the SNES was astounding. I never realized how so much of the SNES magic had to do with modifying parameters for each scanline. That one idea unlocked so many doors.
Remember the episode about max number of objects per line ? That reveals that on each line the console automatically assigns the objects to draw to a limited number of actual object-drawing circuits.
What I would love to know, since the SNES can use what seems to be a pretty unique feature in this HDMA stuff (most other systems including the Genesis talk about only DMA, which the SNES can also do, but not HDMA), is if this allowed the SNES to actually overcome its much slower CPU [and a few other areas where it fell short] compared to the Genesis and actually surpass what the Genesis could do when used to its full capability. I mean, if the SNES can literally update all of this kind of stuff every single scanline, and apparently it comes at very little cost, including switching between all of its different background modes, effectively nullifying many of their individual limitations as I interpret it, then why wasn't this used far more often to get around the SNES many slowdown issues and the inherent limitations of Mode 7 (only able to show a single background layer) and the like?
@@inceptional uh... you got it in reverse genesis can do it as well. the difference is that the genesis cpu and DMA is so much faster that it doesn't actually need anything special to do so. the snes was very memory bottle-necked and has a slow cpu, that's why it needed it that feature. on a genesis you just set the "gpu" to throw a interrupt on H blank(the time between each scanline) and you can do your thing there. the whole family of effects that could be done with this were called "raster effects" since they were changing things during rasterization. most genesis game did something with that, Treasure and latter konami games for genesis were famous for all the effects stuff. but i think the best example of raster effect abuse on genesis is a game called ranger-x
@@khhnator the genesis is faster, mostly due to the wider memory bus and more and larger registers, but it's not THAT much faster. HDMA on genesis would be amazing. You can do a lot of similar tricks with h-interrupts, but it takes a lot of cpu time, as the 68k isn't very fast at interrupt handling. Even if it was fast at interrupts, DMA is much faster than a cpu h-int to update some vdp registers.
@@Ehal256 wait wait... you missing a massive thing there... the VDP has a dedicated DMA controller on it that can be activated in V or H blanks(for different amounts of transfer obviously). yeah sure the cpu will be stalled during it... but who cares? the thing is obscenely fast and can access all vram and ram(which includes the cartridge). when you are v-interrupting, you are essentially just setting up a dma transfer to overwrite the previous settings, or replace tiles if you need. heck all those 3d games on genesis are literally rendering lines during active h + v blank in main ram and while interrupted to dma it to vram during h-blank, line by line. i think the biggest showing of graphics setting tweaking abuse during h-blank are racing games, not the ones that use mode 7 but the ones like outrun where a road bitmap is tweaked to make curves and slopes. and just compare road rash 2 on mega drive to... i don't know? top gear 2 on snes? i think that's the best one on the system. (mind you that top gear 3000 uses extra processors, even thought doesn't look that different even if it is a lot faster, while road rash fps is... weird? it uses fps as a way to throttle the speed, usually when you are at higher speeds with best bikes it is smooth, even though when you start the game with crappy bikes it feels like you at 15 fps... its just weird)
One of my day jobs is graphical effects programming in UE4 and I had zero idea what was going on in this video. We're so fat and spoiled these days in our modern engines.
I've tried coding shaders for Unity's ShaderLab, and it's exactly the same thing as this, except not on a scanline basis. All you get to determine the diffuse of an object is a single RGBA color struct made out of 4 floats. But you know that the GPU will call your color function in a way resembling a bidimensional for-loop for every single pixel on the screen, and this variable will be different each time because Unity will work out the UV math for the texture and load up that color structure with whatever the color of the texture is supposed to be at exactly that position on the screen. So the output of your function will change accordingly. Of course, a lot of work here is still done by the engine, so even we are still pretty spoiled.
@@3lH4ck3rC0mf0r7 That's pretty much how fragment shaders work in OpenGL and DX as well, it's just how the pipeline works on modern GPUs, afaik Unity's shaders allow you to get about as close to the hardware as you're gonna get without a low-level API like DX12 or Vulkan. UV Texture mapping can also be handled independently by the GPU, as UV coordinates are automatically transformed for the current fragment based on the vertex UVs that make up the triangle being rendered with a world space offset of the current fragment.
Amazing HDMA visualisations. And your note on not being able to read the DMA registers actually solved an emulator-dependent bug that I had. Thanks a lot! And keep up the good work
I feel like these videos help me be a better developer. I love learning how limitations were used to their advantage back in the day, and every video I watch, I feel like I can approach things a lot better knowing there's very clever yet refined ways to do things.
Surprised you didn’t mention the scanner in Super Metroid - it’s an effect that you can activate anytime once you get the item, and it really lets you see how they combined background layers and sprites in the environment. Fantastic video as always.
Since the x-ray scope's windowing effect covers the same amount of space as the windowing effect created by the eye's light beam, showing them both wouldn't be much new information on how non-rectangular windows work. It would have been interesting to see how the X-ray scope can show one background block inside a window and a different one outside the window, though.
@TurboGhast: Each layer (including all sprites and the background colour) can have a different masking logic. That means, you can set layer 1 (the visible layer on the X-ray) to be only drawn outside the window and layer 2 (the hidden layer) inside the window. Something similar happens in SMW with the keyhole effect: The foreground layers and background colour (yes, that too) are set to be masked out (i.e. not drawn) inside the keyhole but sprites still can. But when the keyhole closes, SMW sets the sprite rendering in a such way that they're only drawn inside the keyhole but not outside.
@@TurboGhast. The background layer gets replaced by an almost exact copy of the foreground, but where the holes are visible (that's why the background disappears when scanning!), using masking the "xray" background is then shown where appropriate.
@@jimmyhirr5773 I think the effect in itself isn't what's impressive - there's plenty of true 3D work from arcades prior to this - it's more that they found a way to achieve that effect that specifically utilises the sprite scaling abilities of the SNES. Pole Position's technique (like that of Outrun or Road Rash) is a little bit different - definitely a clever technique too, but different in its implementation, and less hardware dependent.
It took me a minute to understand what the visual representations were trying to show (around 14 min mark, mode 7). If I understand it correctly, the image on the right side is being used to render the image on the left. The scanline draws what is on the right image at the moment it is writing and only for that line. Neat stuff. I'm a geologic engineer and know very little about the hardware stuff, but my mathematics background gives me a deeper appreciation for what is happening in the console for my entertainment.
Wow, that's a lot to take in. Thanks for including the examples toward the end of the video - the F-Zero and Super Metroid examples in particular are fascinating!
2:56 : You mentioned that DMA is independent of the CPU, but later you (correctly) contradict yourself, stating that the CPU stalls while DMA is in progress. It's one of the more annoying design decisions in the SNES in my opinion. I wonder why Nintendo did it this way. Even around the time the SNES was released, it was common for DMA to be asynchronous with either a per-channel finish flag you could check for completion, or interrupt-based. 1:40 Even with this great video series to explain things, the various memory spaces on the SNES can be extremely confusing. If it is unclear to anyone, VRAM, OAM and CGRAM have completely separated memory spaces; these areas are not memory-mapped in the 24-bit CPU memory space. Rather, hardware registers are memory-mapped instead and used to access these memory spaces, not very unlike how you would operate an UART/USART. The same thing (kind of) applies to the memory space of the SPC700 (the audio processor), with the small twist of talking to the APU bootloader until the SPC700 has a valid image to run. Once the SPC700 runs with an image, both processors communicate via UART-like HW registers. Excellent work as always.
They probably did that to make the DMA faster and simpler. This way, the DMA has the whole bus for itself, and can copy data as fast as possible without caring about the CPU. On the PC, both the old ISA DMA and the newer PCI Busmastering DMA have to steal bus cycles from the CPU, so the transfer becomes slower if the CPU accesses memory. And the CPU is always accessing memory, because it has to read the program it's executing. This uncertainty is something you really can't use if you need to finish the transfer during the H-Blank period.
nullplan01 AFAIK 6502 CPU family (to which 65816 belongs) accesses memory way too much to have any cycles to steal. And it is on 8-bit bus despite being called 16-bit CPU! 8086/8088 in PCs have prefetch queue (and, later models, caches, on motherboard and on the chip), making it easer to coexist with DMA. Modified Z80 in GB is supposedly also able to coexist well with other ram accesses.
I guess that, because the DMA and the CPU both have to access ROM/RAM (unless you are DMAing ROM and the CPU is running a routine in RAM), they have to share the bus. Since the DMA is meant for fast (burst) transmission, it would be better/faster to let the DMA take over the bus and halt the CPU while the DMA hardware is operating. It is just a guess though, I'd love to know more about it.
@noop9k Yeah, I should have made explicit that I was talking about WRAM, not VRAM. Anyway, there is not a lot of things the game can do while DMAing the computed frame on V-Blank routine, since it can be very problematic to interleave game routine with drawing routine.
João Baptista actually I can list at least 3 somewhat distinct reasons for DMA. 1) make up for the extreme inefficiency of these early cpus at moving data around. They spend vast majority of the time reading their own code and rather small % of these cycles is actual work. Especially 65xx. 2) feed data to time-sensitive hardware at the rate controlled by that hardware. 3) simply offload work that cpu could be doing just as well, on the systems where cpu is not hogging up all the bus cycles when executing its code.
Your videos are so fantastic - I love how thorough and detailed you get (I feel like I come away from every video with a true understanding of the topic beyond just a vague idea of how it works in theory) and your visualizations are absolutely top-notch. This series especially has made me really come to appreciate the work done to create games for consoles like the SNES and NES - as someone who grew up with more advanced hardware and software it's easy to take for granted things like rotation and scaling, perspective transforms, distorted backgrounds, having tons of sprites onscreen, etc. but watching your videos has really made me understand and appreciate how much specialized work had to be put into these effects both on the hardware and software ends. So thank you so much for the time and effort you put into understanding these consoles and creating your videos.
Your videos are so awesome. I love how you use visualization and animation to explain concepts that can be hard to understand if someone was say just giving a lecture.
It would have been interesting to describe the limitations of the windowing tricks: you can only create shapes that are horizontally convex, because ultimately, all you're able to do is change the start pixel and end pixel of the window. You can draw windows shaped like < or >, but not ^ or v.
It is a bit more complicated than that, since there are two windows, and the final result can be the intersection, union, and or complement of the two. A V-shaped window is possible by having one for the left half and one for the right half, then combining the two together.
HDMA is a fascinating feature. Most of my favourite retro computers have variations on this kind of idea. The atari 8 bit computers have a 'display list', which is a list, that broadly speaking specifies for each line on the screen what display mode it's in and where to pull the data from in memory for that line. (also whether to cause an interrupt on that line, to automate more complex effects - for an 8 bit machine this is exceptionally powerful) The Atari has 14 graphics modes which vary in colour depth, resolution, whether they're text or graphics modes and a bunch of other features. And thanks to the display list, you can slam ALL of the graphics modes onto the display at once, with basically no CPU intervention at all. Then you get the Amiga - (incidentally the same people designed the Amiga as did the Atari 8 bit computers, so the similarity is no coincidence.) On the surface this seems like a much simpler feature, but it's actually a more powerful refinement of the display list concept. Instead of specific graphics modes, you have what's called a Copper list. Unlike a display list, it doesn't specify graphics modes directly. Instead there are a bunch of graphics registers, and a copper list basically consists of a command to write a value to a specified register, and a command to wait 'x' pixels. - meaning copper can mess with anything that has a register within it's allowed access range (which as it happens also includes the audio registers.), as you might have noticed, since it's timing is based on pixels, it can automatically perform effects in the middle of a scanline, all without CPU intervention! There's a limit to this of course; Copper isn't fast enough to change something literally every pixel. There's a minimum period between commands, but it's still extremely capable nonetheless... Now, take a close look at these features, then look at how HDMA works on the SNES... The SNES has 8 HDMA channels, and essentially reads a list of commands from memory to write values to specific registers during H-blank. How many values you can write in a line is tied to how many HDMA channels there are, but all changes are done in H-blank. This, effectively sits right in the middle in terms of flexibility between the Amiga and the Atari... It really can do a LOT though. - you can, depending on circumstance and what precisely you're trying to do, modify up to 16 registers per scanline drawn. and these can be ANY graphics registers. Meaning you can fully automate any static scanline effect that requires the modification of 16 registers if the memory map is in your favour, or at least 8 even if it isn't. These lists can be recalculated dynamically, but depending on the effect you can also simply pre-compute it, and play that static list every time to pull off a given effect... Yeah...
Nowadays the same concept applies to GPUs today and modern shaders, using textures and ramps to drive any aspect of rendering at the pixel level, instead of scanlines. Notable examples of interesting hardware setups are the GameCube and Wii, which have the CPU and GPU share all their memory. This allows you to use GPU rendertextures on the CPU with no overhead.
If game developers really had to think that complicated back then, then i will never understand how they could have make sooo many games per year. Just mind blowing.
Most of the complicated stuff was done by Nintendo because they knew exactly how the hardware was designed. A lot of 3rd party games just didn't have these more complicated effects.
To properly answer your question: what is considered Computer Science today is a joke compared to what people studied back in the 70s and 80s. Today they learn stuff like relational databases, Agile, software development, etc. Back then it was Turing machine shit, memory, CPU, it was closer to how hardware is made up to compute. There was a closer grasp to the hardware architecture, and the course was much more difficult. You needed BRAINS back then, to work on that level. So basically people who had this background were the ones who worked on games. Also, videogames were specialized computers who had an overall similar architecture and concepts, such as background, video memory, sprites, etc. For a computer developer to go to videogames it was a certain degree of a learning curve but it was doable. From someone working on NES to SNES there was a lot of additional elements involved, but you're seeing here a condensed version in a 10 min video, while they had extensive documentation and training. For those people, it would make sense. Additionally, while early games were efforts of one or two people at a single game, the NES and particularly the SNES required a much larger team. So someone could specialize in mode 7 + HDMA algorithms, someone would program the actual physics and game structure, and people would be dedicated to work on art, music, etc. So you didn't need to know ALL of it. Also, there was a lot of reusable assets and workarounds. Once you knew how to do it, you just changed the art and there you go. And also, some of these features were ignored by developers and they stick with plain, regular platform games.
My dream is to develop a game for my favorite retro console, the SNES. Every time I rewatch one of these videos my respect only grows for the geniuses who understood this arcane system and coaxed a masterpiece out of that bucket of bolts. I have to keep reminding myself to persevere. I’ve seen what developers can do. If I go forward, I want to build around the SA-1 chip as little of its true potential was ever tapped.
I understood far more in the previous parts on the SNES hardware, this is now beyond my comprehension... AND YET... I was still entertained. Nicely done. I hope after you finish everything about the SNES that you'll do a series on the SEGA Genesis.
14:45 Note: If you are flying a plane and what you see looks like what's on the right, you are having a bad problem and you will not go to the sky today.
How can I see the games I play rendered like the visual examples shown in this video and the Mode 7 video? How do you make those visual representations?
Each game is done differently; I had to look into the memory and run some trace logs to find where the HDMA tables are stored. Then with that I can write a script to modify the table to be uniform for each scanline, then I can sew all the images together one after the other.
I develop for the Genesis. I know that the DMA chip on the Genesis can move about 91 bytes per Vertical blank which amounts to 22 screen tiles.So does this mean that the super nintendo can move more screen tiles. according to my math its moving 44.3 kilobytes per vertical blank NTSC. I don't think that's right... I'm doing the math wrong I think. EDIT: Did a bit of research it seems like the Genesis DMA was faster by virtue of it's 16 bit bus, BUT it is not significantly faster. Also the SNES uses 2 8 bit buses for DMA which reduces the size per transfer but it was asynchronously clocked so it could achieve much higher speeds. It also appears that SNES DMA was severely hampered by SLOW ROM access. Does any of this matter.... no not really. If you want to read more take a look at this: www.quora.com/Was-the-Sega-Genesis-faster-than-the-Super-NES I would really like to do some game development on the SNES later but it will require a major adjustment to my workflow. THE SNES 65C816 is a very alien thing to me. Lots of specific commands that I've never seen before. Thank you for the videos.
The registers refer to any of the hardware registers located at $21xx via the B Bus. For example, if $4301 was set to #$26, and transfer format %100 was used (4 bytes to 4 registers), one byte each would get written to $2126, $2127, $2128, and $2129.
Wow, the last portion with practical applications explained a lot of mysterious, of how these effects were actually realised. No wonder some games look so much superior than others. It's really tricky to use these features and needs a huge amount of technical creativity as well.
Would you be willing to make an episode on how devices like Action Replay or Game Sharks worked as far as the computer engineering behind them? I haven’t found a good one that explains exactly what they do or how they work as far as intercepting instructions or modifying them. Love the vids!
I really love the 65 series CPUs for their simple design. However, their simple design can also be a real curse, particularly for the 65816. In the 65816 you have a 16-bit CPU with a 24-bit address bus... sitting on a limited 8-bit data bus that's also forced to give up a significant portion of its accessible time to the address bus because the highest-order byte of the memory address can only be issued through the 65816's data pins via multiplexing. This, combined with the fact that outside of forced blanking you can't access a lot of hardware, is why the SNES CPU has such dreadful data transfer speeds on its own. When your word size is 16 bits but you can only transfer 8 bits at a time and only within certain windows of each clock cycle because you have to multiplex an address out your data pins, it's a wonder the 65816 could get data around any faster than the 6502 could. The SNES had some great hardware, but I do think the Mega Drive definitely had a better CPU with the m68k. Full 16-bit data bus, full non-multiplexed 24-bit address bus, and an ISA that, while it maintains some backwards compatibility, seemed to be aware of the times it was in and thus offered way more power to the programmer and the hardware. The 65816 didn't really take off on the microcomputer market outside the Apple IIgs probably because it was competing against other 16-bit CPUs like the 8086 and the m68k that could run circles around it at the same clockspeeds. That said, I still love the 65 series CPUs for their simple design, but if I were to homebrew a computer and I had a choice between a 65816 and an m68k, I'd probably just take the m68k.
I'm a bit upset that Mode 7 is the huge special feature of the SNES, when HDMA (while less flashy in concept) really allows for a lot of the awesome visual effects the SNES could do.
Per scan line modifications is nothing special lot of platforms had that, those pseudo 3D effects would not be possible with matrix transformations of Mode 7 which was revolutionary at the time
Does this mean that it would be impossible to the SNES to render a vertical gradient, or is there another trick that could be used? For example, could I get the SNES to display the Super Metroid title screen rotated 90°? Thanks so much for the videos! They’re a bit advanced for me, so I watch them multiple times until I understand. 😊
If you wanted a vertical gradient, you would have to use a different method. The easiest way would be to just bake the gradient into the graphics themselves, but this would use up more graphics and palette memory than a horizontal gradient using HDMA.
Wouldnt it be easier for Nintendo to just allow mode 7 to also scale the screen differently on the too and make a plane view such as the one used in f zero?
In Mode 7, the tilemap and the character table are bytewise interleaved in VRAM. Can I use DMA to modify the tilemap between frames, while leaving the character table alone?
There are so many similarities to the NES in the SNES architecture that there isn't a shadow of a doubt in my mind that they were meant to be backwards compatible at one point.
I'm currently enjoying "I AM ERROR", a platform study of the NES. Goes into how the hardware design choices and limitations affected the games made for the system and contributed to their success.
It's kind of amazing how similar the SNES was to the NES, but having a few extra 16-bit features when so much is still byte-based throws the memory addressing into chaos. I'm tinkering with a SNES-like virtual machine design, and I ran into this on my own almost immediately. I'm thinking, "I kind of understand the NES, I'll try to recreate those emulators but just add in some wider registers, a few more math functions, and a screen buffer," but having to suddenly manage instructions and processor logic for both bytes and shorts makes everything not just twice as complicated, but three times as complicated because each short is also a low byte and a high byte. That means I have 3 versions of every operation (at least the way I'm currently trying to implement it) and it just turns into madness really fast. 8-bit is limiting, but knowing all reading and writing is happening in that same data size makes quite a few low-level things much cleaner (in spite of some obvious drawbacks). Imagine if for the NES there were op-codes/mnemonics for accessing and manipulating each bit of any given byte in memory: instead of about a dozen instructions governing everything, you'd have more like 100 of them. It's no wonder modern 64-bit processors still can have so much based on the old 8-bit machines, but the range of data sizes makes acting on any specific block of data increasingly complicated either for the programmer having to remember a bunch of suffixes, or complicated for the hardware trying to determine what's being done based on some other context clues. I feel like that whole "AL and AH make AX, which is half of EAX" kind of register organization is why most people take one look at Intel x86 ASM and think, "Oh, fuck no. I'll just go back to 6502 or z80 instead."
Please excuse me if I'm getting a little ahead of you, but you mention at 5:24 that CPU execution is suspended while a DMA transfer is occurring. In certain SNES games, such as Mickey Mania (th-cam.com/video/iL6xnm5pJIM/w-d-xo.htmlm49s) and Pink Goes to Hollywood (th-cam.com/video/pPLaiQJMj9o/w-d-xo.htmlm25s), the game freezes for a brief moment when the Background Music is changed; is this freeze due to a DMA transfer that freezes the processor? I'd go into further detail on what I think is going on, but i don't want to spoil anything for your viewers incase I'm right.
It's not quite DMA, as you'll find out in the future video regarding the audio system. But you have the right idea: when the SNES CPU and SPC700 CPU are communicating, they can't do anything else. Especially when large amounts of (music) data are being transferred, both the music and gameplay pause in the mean time.
Djeez this was difficult. I might start creating my own code in an emulator just to do stuff with this, because a video just isn't enough to understand this. Still love these videos though!
Same way as F-Zero. Just that black bar in the middle is doing far more processing than can be done using HDMA alone. After that is finished then it can resume doing Mode 7 magic. Basically Super Mario Kart has 2 V-Blanks.
@@davidmcgill1000 Right - I was just rewatching this video and figured it out. The little indicator arrow he added to show what scanline the game is on never actually moves outside of the black bar. The perspective is done with HDMA while the sprite doubling is done with regular DMA. The visualization on the right side just doesn't show what Mode 7 is actually doing for these scan lines.
@frognik79 It was necessary. Can you imagine the ungodly mess if the CPU tried to access RAM at the same time an HDMA was occurring? It's called "bus contention". At best, the CPU has to enter a wait state anyway until the bus arbiter allows the CPU to use the bus (for example, to fetch the next program instruction). At worst, you end up with garbled data that can cause graphics or audio corruption, or even crash the system.
@@SpearM3064 I know, but the whole point of a dma controller is to free up the cpu. Usually dma controllers have their own dedicated bus and allows the cpu to also access memory if it's a different address but I guess things were different back then.
2.68MB/s DMA? That means 44KB/frame. Does that mean almost the entire VRAM (64KB) could be replaced with sprites from the cartridge every frame? Because I don't think I've seen a game which streams more than 10% of it's sprites per frame.
This is a reupload due to a few mistakes in the video that warranted more than just a mention in the description.
specfically, what changes did you make?
Correction 1: At 3:47, the registers to hold the number of bytes to transfer was corrected from $43-7 & $43-6 to $43-6 & $43-5. This was also corrected in the code at the left at 4:50.
Correction 2: At 4:14, the binary number for transfer mode 1 "2 bytes to 2 registers" was corrected from 010 to 001. This was also correct at 6:50 and 9:50.
Thank you sir.
Well done on the corrections
Your dilligence is appreciated.
The visualisation of F-Zero 14:24 just blew my mind.
It makes sense when you see it, but I never would have guessed that's how they did it.
@@5nefarious I always assumed the took a section in front of the player, then skipped X numbers of pixels to distort it into the frustram for psuedo 3d - running the whole track / background, from a top down perspective, through the mode 7s ASIC is pretty mind blowing.
@@bryanl1984 A lot of racing games work roughly like that.
But, I've known what mode 7 does for a long time.
And yeah, mode 7 racing games work by altering the scaling/rotation parameters during H-blank for each and every line.
You can do this manually with the CPU, but HDMA simplifies your job a LOT.
@@KuraIthys I knew in principle how it worked but, seeing it drawn line by line is pretty impressive and helped me understand it intuitively. For some time, I assumed there was more going on than the affine transforms and DMA - more like a super scaler. This video series shows you just how much blitters, DMA and memory manipulation can be used to create _GREAT_ effects. The irony of mode 7 is that the matrix ASIC that does the transforms was put in because the SNES was clocked at a dismally slow rate - in order to be backwards compatible with the NES, which obviously never happened. The NES was clocked at 1/2 the colour burst frequency (1/2 F) and the SNES was only 2/3 F. To put that in perspective, the _MASTER SYSTEM,_ a NES contemporary, ran at F and the Genesis ran at 15/7 F. In retrospect, it's probably a good thing considering how backwards compatibility has often encouraged developers to design for the lowest common denominator and then mildy spice it up for the better, more expensive and thus rarer systems. Just look at how much this sabotaged the Sega CD; probably for the best that Nintendo didn't pursue NES compatibility or we'd see NES quality games, only with larger color palettes. It makes sense form a business perspective but, it's a shame we never really got to see many examples of what a Miyamoto could have done with a true game on something like the SCD, instead of gimmicks. If you're into the SCD, there are some tantalizingly great games, just not enough of them.
What's funny is that Nintendo is single handedly attributed with saving the gaming market after the crash of the 80's, which is dubious but, they invented the concept of a Graphics Accelerator to make up for the SNES' low clock; we have them to indirectly thank for the awesome modern graphics. They essentially had to put in mode 7 to get around the fact that the SNES was so much slower than the Genesis,PC-engine and Master System which were from the 80's. It's a shame they limited the ASIC to a background layer too. The Sega CD was more or less a contemporary of the SNES and the SEGA "mode 7" ASIC could be used on any data in the system, not just a BG layer. When people reminisce over what could have been if Nintendo and Sony had made a CD SNES, they overlook the Sega CD. On a hardware level, when the SCD is used the way it's intended, the SCD is by far the most impressive console of the 16 bit era. Too bad developers were so enamored w/ FMV trash instead of using it to add pre rendered elements and cut scenes as intended by SEGA. That and all the repurposed corelco games that were sitting around unused when their VHS game system got (rightly) canceled.
@@bryanl1984 THAT is the longest reply i've ever seen on yt!
That mode 7 bit completely blew my mind.
Even with two years of computer science classes, this stuff is still pretty dense. It really makes me appreciate how smart all the hardware developers were to design all of these features into a simple gaming console.
I've been coding for 8 years, and this is still super dense. Thankfully, stuff like this is really only for hobbyists, you never have to dabble in stuff like this unless you want to for fun.
@@davidmenlo9305 Or you are making a game yourself :p
@@davidmenlo9305 Not really only for hobbyists. Stuff like this is still awfully common in embedded system engineering and microcontroller based electrical engineering.
You'd be surprised how many microcontrollers you still need to program in assembler because they don't have proper C support.
It has come to the point where there is a real split in competences between high level and low level programmers. Low level programmers can't program high level and high level programmers can't program low level.
@@joey199412 I'd never considered that this wasn't always the case that there this significant division between low- and high-level programmers. However, it is logical that programmers who are used to working in less-developed languages would be better at low-level languages. To your point, as a C# programmer, if it weren't for general hobbyist stuff and assembly-based Zachtronics games (like TIS-100 or Shenzhen IO), I'd have no knowledge of it.
A game console we all know and love but that programming sound sooo complicated,time consuming and boring, i can hardly imagine that game devs had to work that way and doing all that within a scadual time, you had to think like a mad scientist in order to understand this,phew.
And I thought the mode 7 video was complicated
demoknight tf2
"Now, what would the HDMA table look like?"
Absolutely no fricken clue, but please go on.
The crazy thing about all these scrolling visualizations at the end is that's *exactly* how all these effects looked on early ZSNES versions (like pre-2000s) when you used the simpler tile-based rendering instead of scanline based. Makes a bit more sense now.
This was stunning. My childhood dream of understanding the SNES is becoming a reality. I always thought the scanline modification stuff like the eye or the power bomb in Super Metroid was some kind of mode 7 + transparency, but they did it much more efficiently. I can't imagine the magnitude of the genius that created this system. In retrospect it makes sense, but the leap between the NES and the SNES was astounding. I never realized how so much of the SNES magic had to do with modifying parameters for each scanline. That one idea unlocked so many doors.
Remember the episode about max number of objects per line ?
That reveals that on each line the console automatically assigns the objects to draw to a limited number of actual object-drawing circuits.
What I would love to know, since the SNES can use what seems to be a pretty unique feature in this HDMA stuff (most other systems including the Genesis talk about only DMA, which the SNES can also do, but not HDMA), is if this allowed the SNES to actually overcome its much slower CPU [and a few other areas where it fell short] compared to the Genesis and actually surpass what the Genesis could do when used to its full capability. I mean, if the SNES can literally update all of this kind of stuff every single scanline, and apparently it comes at very little cost, including switching between all of its different background modes, effectively nullifying many of their individual limitations as I interpret it, then why wasn't this used far more often to get around the SNES many slowdown issues and the inherent limitations of Mode 7 (only able to show a single background layer) and the like?
@@inceptional uh... you got it in reverse
genesis can do it as well. the difference is that the genesis cpu and DMA is so much faster that it doesn't actually need anything special to do so.
the snes was very memory bottle-necked and has a slow cpu, that's why it needed it that feature.
on a genesis you just set the "gpu" to throw a interrupt on H blank(the time between each scanline) and you can do your thing there.
the whole family of effects that could be done with this were called "raster effects" since they were changing things during rasterization.
most genesis game did something with that, Treasure and latter konami games for genesis were famous for all the effects stuff. but i think the best example of raster effect abuse on genesis is a game called ranger-x
@@khhnator the genesis is faster, mostly due to the wider memory bus and more and larger registers, but it's not THAT much faster. HDMA on genesis would be amazing. You can do a lot of similar tricks with h-interrupts, but it takes a lot of cpu time, as the 68k isn't very fast at interrupt handling. Even if it was fast at interrupts, DMA is much faster than a cpu h-int to update some vdp registers.
@@Ehal256 wait wait... you missing a massive thing there... the VDP has a dedicated DMA controller on it that can be activated in V or H blanks(for different amounts of transfer obviously). yeah sure the cpu will be stalled during it... but who cares? the thing is obscenely fast and can access all vram and ram(which includes the cartridge).
when you are v-interrupting, you are essentially just setting up a dma transfer to overwrite the previous settings, or replace tiles if you need.
heck all those 3d games on genesis are literally rendering lines during active h + v blank in main ram and while interrupted to dma it to vram during h-blank, line by line.
i think the biggest showing of graphics setting tweaking abuse during h-blank are racing games, not the ones that use mode 7 but the ones like outrun where a road bitmap is tweaked to make curves and slopes. and just compare road rash 2 on mega drive to... i don't know? top gear 2 on snes? i think that's the best one on the system.
(mind you that top gear 3000 uses extra processors, even thought doesn't look that different even if it is a lot faster, while road rash fps is... weird? it uses fps as a way to throttle the speed, usually when you are at higher speeds with best bikes it is smooth, even though when you start the game with crappy bikes it feels like you at 15 fps... its just weird)
One of my day jobs is graphical effects programming in UE4 and I had zero idea what was going on in this video.
We're so fat and spoiled these days in our modern engines.
I've tried coding shaders for Unity's ShaderLab, and it's exactly the same thing as this, except not on a scanline basis. All you get to determine the diffuse of an object is a single RGBA color struct made out of 4 floats. But you know that the GPU will call your color function in a way resembling a bidimensional for-loop for every single pixel on the screen, and this variable will be different each time because Unity will work out the UV math for the texture and load up that color structure with whatever the color of the texture is supposed to be at exactly that position on the screen. So the output of your function will change accordingly.
Of course, a lot of work here is still done by the engine, so even we are still pretty spoiled.
I remember when the first version of the Unreal Engine came out. The game was amazing, and UnrealEd blew my mind in what I could create...
Well. I think, all he says is the base of the currrent graphical programming.
That's because you are dragging a mouse around in a GUI. Nothing more than I do when I work in CAD
@@3lH4ck3rC0mf0r7 That's pretty much how fragment shaders work in OpenGL and DX as well, it's just how the pipeline works on modern GPUs, afaik Unity's shaders allow you to get about as close to the hardware as you're gonna get without a low-level API like DX12 or Vulkan. UV Texture mapping can also be handled independently by the GPU, as UV coordinates are automatically transformed for the current fragment based on the vertex UVs that make up the triangle being rendered with a world space offset of the current fragment.
Amazing HDMA visualisations. And your note on not being able to read the DMA registers actually solved an emulator-dependent bug that I had. Thanks a lot! And keep up the good work
Hey its PJ :)
I feel like these videos help me be a better developer. I love learning how limitations were used to their advantage back in the day, and every video I watch, I feel like I can approach things a lot better knowing there's very clever yet refined ways to do things.
god bless i live for this
3:20 Reading data at the speed of sound. Got places to go, gotta finish before screen writes.
Surprised you didn’t mention the scanner in Super Metroid - it’s an effect that you can activate anytime once you get the item, and it really lets you see how they combined background layers and sprites in the environment. Fantastic video as always.
Since the x-ray scope's windowing effect covers the same amount of space as the windowing effect created by the eye's light beam, showing them both wouldn't be much new information on how non-rectangular windows work. It would have been interesting to see how the X-ray scope can show one background block inside a window and a different one outside the window, though.
@TurboGhast: Each layer (including all sprites and the background colour) can have a different masking logic. That means, you can set layer 1 (the visible layer on the X-ray) to be only drawn outside the window and layer 2 (the hidden layer) inside the window.
Something similar happens in SMW with the keyhole effect: The foreground layers and background colour (yes, that too) are set to be masked out (i.e. not drawn) inside the keyhole but sprites still can. But when the keyhole closes, SMW sets the sprite rendering in a such way that they're only drawn inside the keyhole but not outside.
@@TurboGhast. The background layer gets replaced by an almost exact copy of the foreground, but where the holes are visible (that's why the background disappears when scanning!), using masking the "xray" background is then shown where appropriate.
Good sir, you do not upload often, but when you do you do an amazing job! Keep doing what you're doing.
Now I can show some respect for the programmers of those crappy Dragon Ball Z games.
As always, some of the most professionally done and visually coherent presentations I've ever seen. Bravo :)
Imagine the geniuses that developed these games with what they were given. Holy moly. Great visualization in this video. Thanks.
14:25 THIS VISUALIZATION PERFECTLY EXPLAINS MODE 7 PERSPECTIVE YESSSSSS!
The visualisations of pilotwings and f-zero took my breath away. I find it so fascinating that teams were doing such clever stuff right off the bat!
I don't think it was a new technique. Games like Pole Position were doing similar effects in the arcade a decade before Pilotwings.
@@jimmyhirr5773 I think the effect in itself isn't what's impressive - there's plenty of true 3D work from arcades prior to this - it's more that they found a way to achieve that effect that specifically utilises the sprite scaling abilities of the SNES. Pole Position's technique (like that of Outrun or Road Rash) is a little bit different - definitely a clever technique too, but different in its implementation, and less hardware dependent.
@@Soundole SNES does not do sprite scaling. It can scale a single background layer, that's it.
14:22 it FINALLY makes sense. Nobody else talks about this!!
It took me a minute to understand what the visual representations were trying to show (around 14 min mark, mode 7). If I understand it correctly, the image on the right side is being used to render the image on the left. The scanline draws what is on the right image at the moment it is writing and only for that line.
Neat stuff. I'm a geologic engineer and know very little about the hardware stuff, but my mathematics background gives me a deeper appreciation for what is happening in the console for my entertainment.
Wow, that's a lot to take in. Thanks for including the examples toward the end of the video - the F-Zero and Super Metroid examples in particular are fascinating!
2:56 : You mentioned that DMA is independent of the CPU, but later you (correctly) contradict yourself, stating that the CPU stalls while DMA is in progress. It's one of the more annoying design decisions in the SNES in my opinion. I wonder why Nintendo did it this way. Even around the time the SNES was released, it was common for DMA to be asynchronous with either a per-channel finish flag you could check for completion, or interrupt-based.
1:40 Even with this great video series to explain things, the various memory spaces on the SNES can be extremely confusing. If it is unclear to anyone, VRAM, OAM and CGRAM have completely separated memory spaces; these areas are not memory-mapped in the 24-bit CPU memory space. Rather, hardware registers are memory-mapped instead and used to access these memory spaces, not very unlike how you would operate an UART/USART. The same thing (kind of) applies to the memory space of the SPC700 (the audio processor), with the small twist of talking to the APU bootloader until the SPC700 has a valid image to run. Once the SPC700 runs with an image, both processors communicate via UART-like HW registers.
Excellent work as always.
They probably did that to make the DMA faster and simpler. This way, the DMA has the whole bus for itself, and can copy data as fast as possible without caring about the CPU. On the PC, both the old ISA DMA and the newer PCI Busmastering DMA have to steal bus cycles from the CPU, so the transfer becomes slower if the CPU accesses memory. And the CPU is always accessing memory, because it has to read the program it's executing. This uncertainty is something you really can't use if you need to finish the transfer during the H-Blank period.
nullplan01 AFAIK 6502 CPU family (to which 65816 belongs) accesses memory way too much to have any cycles to steal. And it is on 8-bit bus despite being called 16-bit CPU! 8086/8088 in PCs have prefetch queue (and, later models, caches, on motherboard and on the chip), making it easer to coexist with DMA. Modified Z80 in GB is supposedly also able to coexist well with other ram accesses.
I guess that, because the DMA and the CPU both have to access ROM/RAM (unless you are DMAing ROM and the CPU is running a routine in RAM), they have to share the bus. Since the DMA is meant for fast (burst) transmission, it would be better/faster to let the DMA take over the bus and halt the CPU while the DMA hardware is operating. It is just a guess though, I'd love to know more about it.
@noop9k Yeah, I should have made explicit that I was talking about WRAM, not VRAM. Anyway, there is not a lot of things the game can do while DMAing the computed frame on V-Blank routine, since it can be very problematic to interleave game routine with drawing routine.
João Baptista actually I can list at least 3 somewhat distinct reasons for DMA. 1) make up for the extreme inefficiency of these early cpus at moving data around. They spend vast majority of the time reading their own code and rather small % of these cycles is actual work. Especially 65xx. 2) feed data to time-sensitive hardware at the rate controlled by that hardware. 3) simply offload work that cpu could be doing just as well, on the systems where cpu is not hogging up all the bus cycles when executing its code.
Extremely informative and fascinating! I absolutely love the visualizations of various hdma effects. It really cleared up a lot of confusion I had!
15:09 correction: FINAL FANTASY 6
I appreciate the time you put into these videos. They're worth the wait.
Your videos are so fantastic - I love how thorough and detailed you get (I feel like I come away from every video with a true understanding of the topic beyond just a vague idea of how it works in theory) and your visualizations are absolutely top-notch. This series especially has made me really come to appreciate the work done to create games for consoles like the SNES and NES - as someone who grew up with more advanced hardware and software it's easy to take for granted things like rotation and scaling, perspective transforms, distorted backgrounds, having tons of sprites onscreen, etc. but watching your videos has really made me understand and appreciate how much specialized work had to be put into these effects both on the hardware and software ends. So thank you so much for the time and effort you put into understanding these consoles and creating your videos.
Just discovered your channel, excellent stuff man! Congrats!
strafefox I’ve found Strafefox!
Just discovered your channel, lol
Your videos are so awesome. I love how you use visualization and animation to explain concepts that can be hard to understand if someone was say just giving a lecture.
It would have been interesting to describe the limitations of the windowing tricks: you can only create shapes that are horizontally convex, because ultimately, all you're able to do is change the start pixel and end pixel of the window. You can draw windows shaped like < or >, but not ^ or v.
It is a bit more complicated than that, since there are two windows, and the final result can be the intersection, union, and or complement of the two. A V-shaped window is possible by having one for the left half and one for the right half, then combining the two together.
HDMA is a fascinating feature.
Most of my favourite retro computers have variations on this kind of idea.
The atari 8 bit computers have a 'display list', which is a list, that broadly speaking specifies for each line on the screen what display mode it's in and where to pull the data from in memory for that line. (also whether to cause an interrupt on that line, to automate more complex effects - for an 8 bit machine this is exceptionally powerful)
The Atari has 14 graphics modes which vary in colour depth, resolution, whether they're text or graphics modes and a bunch of other features.
And thanks to the display list, you can slam ALL of the graphics modes onto the display at once, with basically no CPU intervention at all.
Then you get the Amiga - (incidentally the same people designed the Amiga as did the Atari 8 bit computers, so the similarity is no coincidence.)
On the surface this seems like a much simpler feature, but it's actually a more powerful refinement of the display list concept.
Instead of specific graphics modes, you have what's called a Copper list. Unlike a display list, it doesn't specify graphics modes directly.
Instead there are a bunch of graphics registers, and a copper list basically consists of a command to write a value to a specified register, and a command to wait 'x' pixels. - meaning copper can mess with anything that has a register within it's allowed access range (which as it happens also includes the audio registers.), as you might have noticed, since it's timing is based on pixels, it can automatically perform effects in the middle of a scanline, all without CPU intervention!
There's a limit to this of course; Copper isn't fast enough to change something literally every pixel. There's a minimum period between commands, but it's still extremely capable nonetheless...
Now, take a close look at these features, then look at how HDMA works on the SNES...
The SNES has 8 HDMA channels, and essentially reads a list of commands from memory to write values to specific registers during H-blank. How many values you can write in a line is tied to how many HDMA channels there are, but all changes are done in H-blank.
This, effectively sits right in the middle in terms of flexibility between the Amiga and the Atari...
It really can do a LOT though. - you can, depending on circumstance and what precisely you're trying to do, modify up to 16 registers per scanline drawn. and these can be ANY graphics registers.
Meaning you can fully automate any static scanline effect that requires the modification of 16 registers if the memory map is in your favour, or at least 8 even if it isn't.
These lists can be recalculated dynamically, but depending on the effect you can also simply pre-compute it, and play that static list every time to pull off a given effect...
Yeah...
Nowadays the same concept applies to GPUs today and modern shaders, using textures and ramps to drive any aspect of rendering at the pixel level, instead of scanlines. Notable examples of interesting hardware setups are the GameCube and Wii, which have the CPU and GPU share all their memory. This allows you to use GPU rendertextures on the CPU with no overhead.
Yo notch being your first patron is legendary!!!!
If game developers really had to think that complicated back then, then i will never understand how they could have make sooo many games per year.
Just mind blowing.
Devkits, communication with first party, documentation, and crunch time.
The majority of SNES games had more than one developer making them. Also, some code could be reused between games.
How did programmers understand this mess back in the days
Most of the complicated stuff was done by Nintendo because they knew exactly how the hardware was designed. A lot of 3rd party games just didn't have these more complicated effects.
There is something called documentation. Also Programmers doesn't need to know all of this.
Shots fired.
Constantly referencing the SNES documentation.
To properly answer your question: what is considered Computer Science today is a joke compared to what people studied back in the 70s and 80s. Today they learn stuff like relational databases, Agile, software development, etc. Back then it was Turing machine shit, memory, CPU, it was closer to how hardware is made up to compute. There was a closer grasp to the hardware architecture, and the course was much more difficult. You needed BRAINS back then, to work on that level.
So basically people who had this background were the ones who worked on games. Also, videogames were specialized computers who had an overall similar architecture and concepts, such as background, video memory, sprites, etc. For a computer developer to go to videogames it was a certain degree of a learning curve but it was doable. From someone working on NES to SNES there was a lot of additional elements involved, but you're seeing here a condensed version in a 10 min video, while they had extensive documentation and training. For those people, it would make sense.
Additionally, while early games were efforts of one or two people at a single game, the NES and particularly the SNES required a much larger team. So someone could specialize in mode 7 + HDMA algorithms, someone would program the actual physics and game structure, and people would be dedicated to work on art, music, etc. So you didn't need to know ALL of it. Also, there was a lot of reusable assets and workarounds. Once you knew how to do it, you just changed the art and there you go.
And also, some of these features were ignored by developers and they stick with plain, regular platform games.
My dream is to develop a game for my favorite retro console, the SNES. Every time I rewatch one of these videos my respect only grows for the geniuses who understood this arcane system and coaxed a masterpiece out of that bucket of bolts.
I have to keep reminding myself to persevere. I’ve seen what developers can do. If I go forward, I want to build around the SA-1 chip as little of its true potential was ever tapped.
its always such a joy when u upload
Its been 2 years, and we are only on part 7, shows how much effort goes into making these
So HDMA is pretty much like an Amiga copper list. I never drew that connection before. Great video!
Man, imagine if Amiga had had a mode 7 hardware transformer to go with the copper...
Thank you for everything.
You give me such a great knowledge. If I study these by myself, I think it takes a year or more.
That DKC parallax effect is really freaking cool. Wow.
I understood far more in the previous parts on the SNES hardware, this is now beyond my comprehension... AND YET... I was still entertained. Nicely done. I hope after you finish everything about the SNES that you'll do a series on the SEGA Genesis.
14:45 Note: If you are flying a plane and what you see looks like what's on the right, you are having a bad problem and you will not go to the sky today.
This is great information for starting out with home brew.. Thankyou!
memories, like the corners of my map. 16 bit depth colored memories, of HDMA
The game at 8:56 is (I think) Tetris Attack. Not totally sure though
How can I see the games I play rendered like the visual examples shown in this video and the Mode 7 video? How do you make those visual representations?
Each game is done differently; I had to look into the memory and run some trace logs to find where the HDMA tables are stored. Then with that I can write a script to modify the table to be uniform for each scanline, then I can sew all the images together one after the other.
@@RGMechEx Is it theoretically possible to write a LUA script that could do these things automatically and render them out in a separate view?
Yes, I'm sure that's possible.
OMFG YOUR VIDEOS ARE AMAZING. GJ PLS DO MORE!!
It's awesome how the engineers were thinking about all the uses while designing the console's hardware
I'm looking forward to your next video; I hope it comes out soon.
This was an amazing video! Very informative
Yeah, a new video:)
I develop for the Genesis. I know that the DMA chip on the Genesis can move about 91 bytes per Vertical blank which amounts to 22 screen tiles.So does this mean that the super nintendo can move more screen tiles. according to my math its moving 44.3 kilobytes per vertical blank NTSC. I don't think that's right... I'm doing the math wrong I think.
EDIT: Did a bit of research it seems like the Genesis DMA was faster by virtue of it's 16 bit bus, BUT it is not significantly faster. Also the SNES uses 2 8 bit buses for DMA which reduces the size per transfer but it was asynchronously clocked so it could achieve much higher speeds. It also appears that SNES DMA was severely hampered by SLOW ROM access. Does any of this matter.... no not really. If you want to read more take a look at this: www.quora.com/Was-the-Sega-Genesis-faster-than-the-Super-NES
I would really like to do some game development on the SNES later but it will require a major adjustment to my workflow. THE SNES 65C816 is a very alien thing to me. Lots of specific commands that I've never seen before. Thank you for the videos.
The 65C816 is basically an expanded 6502, and the be 6502 is pretty easy to pick up, so you might want to start by learning the 6502 first.
Excellent explanation. Good work.
14:22 - mind blown
in 2:17 I found it a bit confusing when you wrote the *memory addresses* into the boxes
God, I've been waiting for this video! 😁
Your videos are so much more awesome now that I'm learning assembly to hack Super Metroid. Thank you!
Such a niche interest but such brilliant videos
@RGMechEX, at 4:20, what are the "registers" for the "Transfer Format"?
The registers refer to any of the hardware registers located at $21xx via the B Bus. For example, if $4301 was set to #$26, and transfer format %100 was used (4 bytes to 4 registers), one byte each would get written to $2126, $2127, $2128, and $2129.
@@RGMechEx OK, but what then are the "write two bytes two times to one register" used for?
Wow, the last portion with practical applications explained a lot of mysterious, of how these effects were actually realised. No wonder some games look so much superior than others. It's really tricky to use these features and needs a huge amount of technical creativity as well.
Man i wish there was a playlist like this but with the NES
Would you be willing to make an episode on how devices like Action Replay or Game Sharks worked as far as the computer engineering behind them? I haven’t found a good one that explains exactly what they do or how they work as far as intercepting instructions or modifying them. Love the vids!
th-cam.com/video/C86OsYRACTM/w-d-xo.html
Not exactly what you were looking for, but...
Awsome! Keep up the good work!
I really love the 65 series CPUs for their simple design.
However, their simple design can also be a real curse, particularly for the 65816. In the 65816 you have a 16-bit CPU with a 24-bit address bus... sitting on a limited 8-bit data bus that's also forced to give up a significant portion of its accessible time to the address bus because the highest-order byte of the memory address can only be issued through the 65816's data pins via multiplexing.
This, combined with the fact that outside of forced blanking you can't access a lot of hardware, is why the SNES CPU has such dreadful data transfer speeds on its own. When your word size is 16 bits but you can only transfer 8 bits at a time and only within certain windows of each clock cycle because you have to multiplex an address out your data pins, it's a wonder the 65816 could get data around any faster than the 6502 could.
The SNES had some great hardware, but I do think the Mega Drive definitely had a better CPU with the m68k. Full 16-bit data bus, full non-multiplexed 24-bit address bus, and an ISA that, while it maintains some backwards compatibility, seemed to be aware of the times it was in and thus offered way more power to the programmer and the hardware. The 65816 didn't really take off on the microcomputer market outside the Apple IIgs probably because it was competing against other 16-bit CPUs like the 8086 and the m68k that could run circles around it at the same clockspeeds.
That said, I still love the 65 series CPUs for their simple design, but if I were to homebrew a computer and I had a choice between a 65816 and an m68k, I'd probably just take the m68k.
Yeah I'm just gonna keep learning C, assembly for the snes/6502 sounds convoluted XD
Boy, they sure did have to be creative back then.
Oh man so much information! Great 👌
I'm a bit upset that Mode 7 is the huge special feature of the SNES, when HDMA (while less flashy in concept) really allows for a lot of the awesome visual effects the SNES could do.
Per scan line modifications is nothing special lot of platforms had that, those pseudo 3D effects would not be possible with matrix transformations of Mode 7 which was revolutionary at the time
Does this mean that it would be impossible to the SNES to render a vertical gradient, or is there another trick that could be used? For example, could I get the SNES to display the Super Metroid title screen rotated 90°?
Thanks so much for the videos! They’re a bit advanced for me, so I watch them multiple times until I understand. 😊
If you wanted a vertical gradient, you would have to use a different method. The easiest way would be to just bake the gradient into the graphics themselves, but this would use up more graphics and palette memory than a horizontal gradient using HDMA.
Wouldnt it be easier for Nintendo to just allow mode 7 to also scale the screen differently on the too and make a plane view such as the one used in f zero?
In Mode 7, the tilemap and the character table are bytewise interleaved in VRAM. Can I use DMA to modify the tilemap between frames, while leaving the character table alone?
There are so many similarities to the NES in the SNES architecture that there isn't a shadow of a doubt in my mind that they were meant to be backwards compatible at one point.
Seeing the effects used for F-Zero made me wonder, is this also how they made those wacky battle backgrounds in Earthbound?
This is a good video
Can you recommend any books?
I'm currently enjoying "I AM ERROR", a platform study of the NES. Goes into how the hardware design choices and limitations affected the games made for the system and contributed to their success.
I recommend the official Nintendo development manual
I suppose it should be possible to dma audio and dma video at the sound time by using 4 channels for each right?
Check that bad apple demo .
It's kind of amazing how similar the SNES was to the NES, but having a few extra 16-bit features when so much is still byte-based throws the memory addressing into chaos.
I'm tinkering with a SNES-like virtual machine design, and I ran into this on my own almost immediately. I'm thinking, "I kind of understand the NES, I'll try to recreate those emulators but just add in some wider registers, a few more math functions, and a screen buffer," but having to suddenly manage instructions and processor logic for both bytes and shorts makes everything not just twice as complicated, but three times as complicated because each short is also a low byte and a high byte. That means I have 3 versions of every operation (at least the way I'm currently trying to implement it) and it just turns into madness really fast. 8-bit is limiting, but knowing all reading and writing is happening in that same data size makes quite a few low-level things much cleaner (in spite of some obvious drawbacks).
Imagine if for the NES there were op-codes/mnemonics for accessing and manipulating each bit of any given byte in memory: instead of about a dozen instructions governing everything, you'd have more like 100 of them. It's no wonder modern 64-bit processors still can have so much based on the old 8-bit machines, but the range of data sizes makes acting on any specific block of data increasingly complicated either for the programmer having to remember a bunch of suffixes, or complicated for the hardware trying to determine what's being done based on some other context clues. I feel like that whole "AL and AH make AX, which is half of EAX" kind of register organization is why most people take one look at Intel x86 ASM and think, "Oh, fuck no. I'll just go back to 6502 or z80 instead."
Could this HDMA modes be used to redrawing the colors of pixes using an external 32bpp LUT?
Oh, I thought that said DMT & MDMA.
Great video!! Retro Game Mechanics Explained, which emulator do you suggest for debugging SNES games?
When are you going to get to the next part of this?
Please excuse me if I'm getting a little ahead of you, but you mention at 5:24 that CPU execution is suspended while a DMA transfer is occurring. In certain SNES games, such as Mickey Mania (th-cam.com/video/iL6xnm5pJIM/w-d-xo.htmlm49s) and Pink Goes to Hollywood (th-cam.com/video/pPLaiQJMj9o/w-d-xo.htmlm25s), the game freezes for a brief moment when the Background Music is changed; is this freeze due to a DMA transfer that freezes the processor? I'd go into further detail on what I think is going on, but i don't want to spoil anything for your viewers incase I'm right.
It's not quite DMA, as you'll find out in the future video regarding the audio system. But you have the right idea: when the SNES CPU and SPC700 CPU are communicating, they can't do anything else. Especially when large amounts of (music) data are being transferred, both the music and gameplay pause in the mean time.
I just love vidsos like this!
Awesome video.
I feel like a total genius right now.
0:23 MMIO
2:23 DMA
6:29 HDMA
I'd like to get more into romhacking, but I know its more than just what you explained in your videos.
ThatEarthBounder Loads of tutorial docs on RHDN.
I don't know which one I should start looking at but I know there's even apparently an Official document used by Snes developers in that website.
@@@jumponearth1673
Try looking for the ROM maps for whatever game you want to hack, too.
Wow, that was awesome!
What font do you use in this video? It looks good.
Djeez this was difficult. I might start creating my own code in an emulator just to do stuff with this, because a video just isn't enough to understand this. Still love these videos though!
@RGMechEx, what software do you use to build these visualizations? They are very well made. I am guessing you have a custom fork of a SNES emulator.
Fun part starts at 11:46 😀
If you can't do non-linear stuff without HDMA, how does the background on Super Mario Kart work then? I don't see how it's different from F-Zero.
Same way as F-Zero. Just that black bar in the middle is doing far more processing than can be done using HDMA alone. After that is finished then it can resume doing Mode 7 magic. Basically Super Mario Kart has 2 V-Blanks.
@@davidmcgill1000 Right - I was just rewatching this video and figured it out. The little indicator arrow he added to show what scanline the game is on never actually moves outside of the black bar. The perspective is done with HDMA while the sprite doubling is done with regular DMA. The visualization on the right side just doesn't show what Mode 7 is actually doing for these scan lines.
4:50 marking where i left off
deleted and reuploaded?
If hdma & dma cannot be used at the same time, i was thinking that since it contain 8 channels,why not use 4 channels for hdma and 4 channels for dma?
I have an idea:
Let's build a console that has dma to free up the cpu but we'll also pause the cpu during the dma to piss people off.
@frognik79 It was necessary. Can you imagine the ungodly mess if the CPU tried to access RAM at the same time an HDMA was occurring? It's called "bus contention". At best, the CPU has to enter a wait state anyway until the bus arbiter allows the CPU to use the bus (for example, to fetch the next program instruction). At worst, you end up with garbled data that can cause graphics or audio corruption, or even crash the system.
@@SpearM3064 I know, but the whole point of a dma controller is to free up the cpu.
Usually dma controllers have their own dedicated bus and allows the cpu to also access memory if it's a different address but I guess things were different back then.
Another example of the use of HDMA is in the title screen for Mega Man X.
2.68MB/s DMA? That means 44KB/frame. Does that mean almost the entire VRAM (64KB) could be replaced with sprites from the cartridge every frame? Because I don't think I've seen a game which streams more than 10% of it's sprites per frame.