A bit of clarification: When you say "HDMA allows Mode 7 to do cool tricks that it couldn't do on its own", technically, the only thing that Mode 7 *can* do on its own is an affine transformation: Translation, rotation, scaling, and skew. It can't actually do perspective transformation without HDMA changing the matrix registers on each line. HDMA is actually what most games use to change the mode itself since the mode register is one that it can access. Super Mario Kart is one example of a game that does manipulate the registers in the middle of the game using the CPU: In split-screen mode, it turns on forced blanking in the middle of the frame, then loads new sprites for the bottom half. This takes a few scanlines to complete, which is why there's a thick black bar separating the views. All of the other effects, including mode switching and perspective are done using HDMA.
An interesting point about sprite flicker (at least on the Sega Master System, though I assume on most 8-bit onsole at least) : Sprite flicker is not an automatic process. On the SMS, sprites have different priorities, based on their location in the Sprite Attribute Table (SAT). Those with a lower address on the table, ie. $3F00 will be given draw priority over those with a higher address on the table, ie. $3FFF. So if there are 9 sprites on a single scanline on the Master System, only the first 8 sprites with the lowest SAT address will be drawn. The rest will actually be completely invisible. Sprite Flicker as we know it is actually something that has to be coded in by the programmer. This is usually done by shuffling around the addresses of each sprite in the SAT so that their priority is constantly shifting. This is viewed as flicker by the player. You can see this happening if you open up an SMS game in an emulator like Emulicious. I believe this is also how the Game Boy Color works, but the original black and white Game Boy determines the draw priority by which sprites have the lowest X coordinate, so I'm not sure how flicker would work on an old-school DMG Game Boy, or if it was possible. I'm not very familiar with the DMG library unfortunately. Interestingly, slowdown is ALSO something that doesn't happen automatically, and must be manually coded in by the programmer.
For the Mega Drive, there's actually a specific benefit to performing DMAs during VBLANK. The VDP performs DMA significantly faster while the screen is disabled, which is most commonly the case during VBLANK.
Is it really faster? Is it not just that because the DMA is not used to display the screen you have 10x more free DMA then. The end result just want to check as I can’t understand how DMA works
@@litjellyfish The 10x value may be off, since I see conflicting numbers from different sources. But performing a DMA transfer from the 68k's memory to the VRAM is significantly faster during VBLANK/when the display is disabled. There are various wiki pages that cover it. You should be able to find some by searching for "mega drive vdp dma"
Also worth noting how V-blank came in different sizes per platform for hardware performance sake, why DOS gaming was 320x200 and Genesis was 320x224, or how few platforms actually were 320x240 or 240p in the 90s till much later in the decade. Same for the 4:3 anamorphic stretch varying too, which was a pain in the ass with cross platform development lol. I tend to only refer to "background tiles" and instead say "sprite blocks" just to make sure there is no confusion between both units rather than say "tiles" for everything in statements.😉
I also remember reading that Blast Processing can be a faster method of "blasting" data from the Sega CD over to the Genesis. I have no idea if this is real and given your description of how the Sega CD works in previous videos, it sounds like no.
There's a demo out there where someone actually shows the SNES displaying seven out of the eight available backgrounds modes all running on-screen at once just by switching them down the screen. It's a fugly programmer art demo, but it's pretty technically impressive and shows some of the potential there.
Why did you say that blast processing can only display 256 colours? I believe it can display any colour from the full palette, so all 512 colours on screen. However, the screen can only be 2/3rds full.
1:06 Technically one movement from the top left to the bottom right (plus VBLANK) is a field, and TVs usually draw 2 fields with their lines interlaced between each other, hence interlaced mode. Games usually cut the second field off prematurely so the next field is drawn over the first field; in that case a field is equal to a frame. 1:15 For normal TV broadcasts it's exactly 60/1.001 fields per second, Wikipedia has a nice section in the "NTSC" article on why/how they used that. For the progressive mode of the consoles it depends on how many lines they have in a field, and the exact duration of a line which depends on the dot clock frequency, usually a fraction of the system clock. The duration of a line may also not always be exactly the same, to slightly vary the NTSC color artifacts over two frames. Usually it's a bit faster than 60/1.001 fps because it draws half a line less per field. 2:29 Afaik the TV always moves the beam slightly downward at all times, both during active display and horizontal retrace. But that could very well be an implementation detail that could have varied over the years and between manufacturers. 3:47 Well, it doesn't involve the CPU executing program code for every byte transfer. The CPU could very well contain the circuitry ("DMA engine") that stops the program code, enables the source's "read mode" control line and the target's "write mode" control line, and then on every clock cycle just advances the respective address bus values. Afaik on the Amiga it's a dedicated "Copper" chip, while on the NES and SNES this is integrated into the CPU chip. 4:29 For games on ancient consoles like the Atari 2600 the game was basically drawing each scanline 'manually', so parallax effects would be very easy there too. Just CPU intensive, of course. 4:57 The NES had a feature that sets a bit in the PPU status register when an opaque pixel of sprite 0 overlaps an opaque pixel of the background. Games could use that to detect when a certain scanline was reached. 9:34 That's when the systems were released... Of course their development started a few years earlier. The WDC 65c816 CPU was released in 1985 while the SNES which used it as its CPU's core was released 5 years later. The NES is even more extreme: the MOS 6502 was released in 1975 and the NES in 1983. 10:55 Some games actually intentionally use that sprite hiding behavior. Afaik it's how the Mario games hide the portion of him that is already in a pipe, and in Zelda 1 how Link walks under the wall tiles when passing vertical doors in a dungeon.
Caveats: 1:06 Number of scanlines and field alternance were dictated by TV raster standards and fixed. Consoles always output them all, only how they built it varied. Very common was to issue the same content on both fields, effectively spreading each pixel over 2 CRT scanlines. 2:29 The beam was horizontal when active, even on cheap TVs. This is verifiable on slo-mo footage of CRTs. 3:47 DMA is conceptually a co-processor dedicated to memory transfers. Being separate or integrated is a manufacturing detail. 10:55 Some games did hide sprites this way, emulators have to take care. But Mario3-in-pipe is hidden by another sprite, itself hidden behind the pipe.
7:47 I always disliked how childish and toxic sega's marketing was back then. It did not do them any favour on the long run... At the end of the day, so called blast processing was some kind of palette swap, but on a per scanline level? Not sure if that is truly unique to the MD, swapping palette for specific areas of the screen is pretty common. But if doing it per scanline cannot be used easily in games, it becomes a pretty weak argument.
A bit of clarification: When you say "HDMA allows Mode 7 to do cool tricks that it couldn't do on its own", technically, the only thing that Mode 7 *can* do on its own is an affine transformation: Translation, rotation, scaling, and skew. It can't actually do perspective transformation without HDMA changing the matrix registers on each line. HDMA is actually what most games use to change the mode itself since the mode register is one that it can access.
Super Mario Kart is one example of a game that does manipulate the registers in the middle of the game using the CPU: In split-screen mode, it turns on forced blanking in the middle of the frame, then loads new sprites for the bottom half. This takes a few scanlines to complete, which is why there's a thick black bar separating the views. All of the other effects, including mode switching and perspective are done using HDMA.
An interesting point about sprite flicker (at least on the Sega Master System, though I assume on most 8-bit onsole at least) :
Sprite flicker is not an automatic process. On the SMS, sprites have different priorities, based on their location in the Sprite Attribute Table (SAT). Those with a lower address on the table, ie. $3F00 will be given draw priority over those with a higher address on the table, ie. $3FFF.
So if there are 9 sprites on a single scanline on the Master System, only the first 8 sprites with the lowest SAT address will be drawn. The rest will actually be completely invisible. Sprite Flicker as we know it is actually something that has to be coded in by the programmer. This is usually done by shuffling around the addresses of each sprite in the SAT so that their priority is constantly shifting. This is viewed as flicker by the player. You can see this happening if you open up an SMS game in an emulator like Emulicious.
I believe this is also how the Game Boy Color works, but the original black and white Game Boy determines the draw priority by which sprites have the lowest X coordinate, so I'm not sure how flicker would work on an old-school DMG Game Boy, or if it was possible. I'm not very familiar with the DMG library unfortunately.
Interestingly, slowdown is ALSO something that doesn't happen automatically, and must be manually coded in by the programmer.
For the Mega Drive, there's actually a specific benefit to performing DMAs during VBLANK. The VDP performs DMA significantly faster while the screen is disabled, which is most commonly the case during VBLANK.
Is it really faster? Is it not just that because the DMA is not used to display the screen you have 10x more free DMA then.
The end result just want to check as I can’t understand how DMA works
@@litjellyfish The 10x value may be off, since I see conflicting numbers from different sources. But performing a DMA transfer from the 68k's memory to the VRAM is significantly faster during VBLANK/when the display is disabled. There are various wiki pages that cover it. You should be able to find some by searching for "mega drive vdp dma"
Always wondered what all these terms referred to. Great video.
Also worth noting how V-blank came in different sizes per platform for hardware performance sake, why DOS gaming was 320x200 and Genesis was 320x224, or how few platforms actually were 320x240 or 240p in the 90s till much later in the decade. Same for the 4:3 anamorphic stretch varying too, which was a pain in the ass with cross platform development lol.
I tend to only refer to "background tiles" and instead say "sprite blocks" just to make sure there is no confusion between both units rather than say "tiles" for everything in statements.😉
such a clear presentation)) thanks))
love this channel. also the lost vikings always needs more love!
that was an awesome guide, thanks man
That was super informative and interesting! I can't wait to see more tricks and techniques of the retro gaming console development.
amazing content
I also remember reading that Blast Processing can be a faster method of "blasting" data from the Sega CD over to the Genesis. I have no idea if this is real and given your description of how the Sega CD works in previous videos, it sounds like no.
Splitting the screen into different modes? Never even occured to me lol.
It was done quite a lot!
There's a demo out there where someone actually shows the SNES displaying seven out of the eight available backgrounds modes all running on-screen at once just by switching them down the screen. It's a fugly programmer art demo, but it's pretty technically impressive and shows some of the potential there.
@@inceptionali think ive seen this before, but I can't remember what the name was
@@whamer100 Yeah, I can't remember the name either.
Each horizontal row of pixels on SNES/Genesis is drawn with 2 scanlines, 1/60th of a second apart… unless using an interlaced resolution mode output.
Why did you say that blast processing can only display 256 colours? I believe it can display any colour from the full palette, so all 512 colours on screen. However, the screen can only be 2/3rds full.
How did the Sega CD work?
It's explained in my newest video! :) th-cam.com/video/gIVZZcY9vBA/w-d-xo.html
1:06 Technically one movement from the top left to the bottom right (plus VBLANK) is a field, and TVs usually draw 2 fields with their lines interlaced between each other, hence interlaced mode. Games usually cut the second field off prematurely so the next field is drawn over the first field; in that case a field is equal to a frame.
1:15 For normal TV broadcasts it's exactly 60/1.001 fields per second, Wikipedia has a nice section in the "NTSC" article on why/how they used that. For the progressive mode of the consoles it depends on how many lines they have in a field, and the exact duration of a line which depends on the dot clock frequency, usually a fraction of the system clock. The duration of a line may also not always be exactly the same, to slightly vary the NTSC color artifacts over two frames. Usually it's a bit faster than 60/1.001 fps because it draws half a line less per field.
2:29 Afaik the TV always moves the beam slightly downward at all times, both during active display and horizontal retrace. But that could very well be an implementation detail that could have varied over the years and between manufacturers.
3:47 Well, it doesn't involve the CPU executing program code for every byte transfer. The CPU could very well contain the circuitry ("DMA engine") that stops the program code, enables the source's "read mode" control line and the target's "write mode" control line, and then on every clock cycle just advances the respective address bus values.
Afaik on the Amiga it's a dedicated "Copper" chip, while on the NES and SNES this is integrated into the CPU chip.
4:29 For games on ancient consoles like the Atari 2600 the game was basically drawing each scanline 'manually', so parallax effects would be very easy there too. Just CPU intensive, of course.
4:57 The NES had a feature that sets a bit in the PPU status register when an opaque pixel of sprite 0 overlaps an opaque pixel of the background. Games could use that to detect when a certain scanline was reached.
9:34 That's when the systems were released... Of course their development started a few years earlier. The WDC 65c816 CPU was released in 1985 while the SNES which used it as its CPU's core was released 5 years later. The NES is even more extreme: the MOS 6502 was released in 1975 and the NES in 1983.
10:55 Some games actually intentionally use that sprite hiding behavior. Afaik it's how the Mario games hide the portion of him that is already in a pipe, and in Zelda 1 how Link walks under the wall tiles when passing vertical doors in a dungeon.
Caveats:
1:06 Number of scanlines and field alternance were dictated by TV raster standards and fixed.
Consoles always output them all, only how they built it varied.
Very common was to issue the same content on both fields, effectively spreading each pixel over 2 CRT scanlines.
2:29 The beam was horizontal when active, even on cheap TVs. This is verifiable on slo-mo footage of CRTs.
3:47 DMA is conceptually a co-processor dedicated to memory transfers. Being separate or integrated is a manufacturing detail.
10:55 Some games did hide sprites this way, emulators have to take care.
But Mario3-in-pipe is hidden by another sprite, itself hidden behind the pipe.
7:47 I always disliked how childish and toxic sega's marketing was back then. It did not do them any favour on the long run...
At the end of the day, so called blast processing was some kind of palette swap, but on a per scanline level? Not sure if that is truly unique to the MD, swapping palette for specific areas of the screen is pretty common. But if doing it per scanline cannot be used easily in games, it becomes a pretty weak argument.