Enjoying your froyo?

[Drew Sebastino]

BG2 in EXTBG is literally the same data as BG1. No extra reading required.

Oh, I get it now. Wouldn't that mean that you can only use 128 colors, or is it like BG 1 takes colors 0-127, and BG2 takes colors 128-255? Anyway though, couldn't they have implemented this just as easily on any other mode? The Irem M92 (and I think even the M72) has something almost exactly like this where the backgrounds can have half of the colors be higher priority. In the Hunt showcases this a lot, like where there is water that covers the submarine and the rest of the BG layer. Also, the underwater buildings on stage 2.

Long story short: you may not want to mess with it.

It seems like there are a lot of weird tricks I don't yet know about. I'm guessing this would be way too slow for trying to change the color of every pixel to create a 16bpp bitmap?

禁則事項です。

Google Translate? (Nothing ever translates that well unless it was written in it, and even then, it can have trouble translating its own translated message. )

...okay, no, that's not true. I'm Canadian.

Enjoying your "froyo"?



(Seriously though, this website is home to the largest number of Canadians I've seen yet.)

Does that make me a hipster for saying Mega Drive instead of Genesis?

I'm assuming it was called the Genesis there also? Wasn't there some sort of copyright or something that prevented Sega from using the name Megadrive? Kind of reminds me how StarFox had been named StarWing in PAL regions due to some crappy Atari 2600 game.

[AWJ]

The nice part about the VRAM gate is that it's got one 8-bit register for each VRAM chip (at least, I'm pretty sure that's how the split works), and you can set it to increment the word address (by 1, 32, or 128) with a write to either one. This means that for Mode 7, you can use a single DMA transfer to update either the graphics data or the tilemap without touching the other one, meaning you don't have to store them interleaved in ROM, and you can render to Mode 7 (like Wolfenstein 3D) without worrying about skipping the tilemap bytes.

Cool. So is one entry in mode 7 tilemap really just 8 character bits?

Yes, in Mode 7 each "even" byte of VRAM is one 8-bit tilemap entry without any attribute bits, and each "odd" byte is one 8-bit pixel. Mode 3/4 also has 8bpp tiles but they're regular planar SNES tiles, and not interleaved with the tilemap.

adds a second BG layer to Mode 7, and this BG2 is exactly the same as the BG1 (scroll, matrix, etc.) except that the top byte in the colour index for each pixel is considered a priority bit instead of a colour bit.

Would it have been any more difficult for them to have just made the second BG layer be a normal BG layer? Also, isn't the second BG in EXTBG just like a regular 8bpp BG in how the graphics and the tilemap are? I would have thought all of this would be too much for how fast the ppus can read from vram.

The EXTBG layer is completely "parasitic": it's a different interpretation of the same Mode 7 pixel data that the PPU is already fetching for BG1. Each of the VRAM data lines is literally connected to two different pins on PPU2.

The originally intended purpose of the EXTBG pins was almost certainly to mix in output from a third PPU of some sort (e.g. from a NES-compatible PPU, if backward compatibility was planned for the SNES at some point) When whatever that "PPU3" would have been was dropped from the design, some engineer evidently realized those pins could still be used to add a bit of extra functionality to Mode 7 at no hardware cost.

The video hardware in just about any other 2D system I can think is way more straightforward.

Arcade hardware tends to be simpler (meaning more fixed-function, not less powerful) than console hardware because for arcade games with different needs the manufacturer would use completely different hardware. Until the late 1990s (when hardware directly derived from consoles and PCs started taking over) no arcade manufacturer would use the same video chipset for a 2D shoot-em-up as for a behind-the-car driving game.

The Genesis video hardware does have "modes" if you count the Master System backward-compatibility ones. I won't dispute that the SNES is more complicated than the Genesis or the PC Engine (TurboGrafx) but if you want to see a crazy-complicated "2D" video system take a look at the Saturn. It makes the SNES look very simple indeed.

The GBA video hardware is actually quite a bit simpler than the SNES. Just to name two basic things, there are only two tile formats (8x8 4bpp and 8bpp) and the VRAM layout is much more hardwired than on the SNES. Most of the complexity of the SNES (and the Saturn) comes from the desire to squeeze every drop of use out of very limited RAM capacity and bandwidth. You have so many different tile formats because there's enough bandwidth to fetch and draw two 4bpp layers and a 2bpp layer, but not quite enough for three 4bpp layers. You can put anything (except Mode 7) anywhere in VRAM so that you never leave any VRAM unused, no matter what the balance of sprite to background graphics in your game is. You support 16x16 tiles because it reduces the amount of tilemap data the CPU has to create in WRAM and upload to VRAM by three quarters, but you also support 8x8 tiles because most games do need a score/HUD display (run Dogyuun or Knuckle Bash or Batsugun in MAME and take a look at how they displayed their HUDs using hardware that only supported 16x16 tiles; it's hilariously wasteful)

The PSX video hardware is also pretty damn simple, though it's fundamentally different from everything else discussed here (a blitter/rasterizer rather than sprites'n'tilemaps). The primary reason its emulation is such a black art is that nobody wants to play those first-generation 3D games in their original resolutions. Imagine that that HDNES abomination was the bare minimum that end-users would accept and you have the PSX emulation scene

[AWJ]

BG2 in EXTBG is literally the same data as BG1. No extra reading required.

Oh, I get it now. Wouldn't that mean that you can only use 128 colors, or is it like BG 1 takes colors 0-127, and BG2 takes colors 128-255? Anyway though, couldn't they have implemented this just as easily on any other mode? The Irem M92 (and I think even the M72) has something almost exactly like this where the backgrounds can have half of the colors be higher priority. In the Hunt showcases this a lot, like where there is water that covers the submarine and the rest of the BG layer. Also, the underwater buildings on stage 2.

BG1 uses colors 0-255, BG2 uses colors 0-127, sprites use colors 128-255 (like they always do). Nothing is ever wasted on the SNES (except that one VRAM cycle in Mode 6)

For the regular BG modes Nintendo went with priority-per-tile rather than priority-per-pixel. The former is probably easier to implement in hardware than the latter when you have variable bitdepths like the SNES does, and probably also easier for artists to use. But both of them are luxury features; a lot of arcade hardware can't do either, and I can't think of any hardware that does both at once (though I'm sure it exists...)

[Drew Sebastino]

The EXTBG layer is completely "parasitic": it's a different interpretation of the same Mode 7 pixel data that the PPU is already fetching for BG1. Each of the VRAM data lines is literally connected to two different pins on PPU2.

I'm almost not really sure why it's called an extra BG when it doesn't really seem like it's enough to be considered one. If we're counting that as an extra BG, we could say the Irem M92 has 6BGs.

Arcade hardware tends to be simpler (meaning more fixed-function, not less powerful) than console hardware because for arcade games with different needs the manufacturer would use completely different hardware.

Well, maybe with Sega at least. I swear, it looks like they where developing for 8 different arcade machines at any given moment. If you look at a company that didn't feel like having 100 different arcade boards like Capcom, SNK, or Irem, they have many different games running on the same hardware. Then there's people like Konami, who I heard pretty much made a new arcade board for every game.

run Dogyuun or Knuckle Bash or Batsugun in MAME and take a look at how they displayed their HUDs using hardware that only supported 16x16 tiles; it's hilariously wasteful

How do they do it? I've seen games use 16x16 sprites for one letter or number, even on the SNES. (Rendering Ranger R2, which I would have thought they could have gotten away with just updating the tiles instead)

The PSX video hardware is also pretty damn simple, though it's fundamentally different from everything else discussed here (a blitter/rasterizer rather than sprites'n'tilemaps). The primary reason its emulation is such a black art is that nobody wants to play those first-generation 3D games in their original resolutions. Imagine that that HDNES abomination was the bare minimum that end-users would accept and you have the PSX emulation scene

I actually today felt like being a pirate and downloading Goldeneye because I was playing it at my father's house in Virginia during the summer on the N64 there, and it looked really weird, like how smooth everything looked contrasted with the rest of everything. This is kind of random, but let me tell you, the control stick options in Project 64 are terrible, or at least they were with my wired Xbox 360 controller. It's weird, because once you moved the control stick past halfway in either direction, it wouldn't increase the speed. I wish more shooters where like Doom to where you can hold down a run button for turning really quickly, and you can not hold it down for accurate aiming, because in every other game I've played with adjustable sensitivity, I've had to try and balance between it because the control stick sensitivity is god awful. (I got a Wii u for Splatoon a couple of days ago and as fun as I find the game to be, the controls are some of the worst I've ever experienced. I literally turned the sensitivity as low as it goes.) People need to look at Super Monkey Ball or something for a good reference on how to properly implement analog controls.

Edit: New post incoming to stop my rant.

Nothing is ever wasted on the SNES (except that one VRAM cycle in Mode 6)

I think Mode 6 wins the award for most useless SNES graphical mode. I mean, I can't even think of one thing that uses it. I would have rather seen a 512x448 8bpp mode, even if that could only fill a 1/4 of the screen with unique tiles. It could look incredibly awesome for a title screen if it's fine to have repeating tiles.

But both of them are luxury features; a lot of arcade hardware can't do either, and I can't think of any hardware that does both at once (though I'm sure it exists...)

Irem M92.

Edit: Is it me, or is Wikipedia (unsurprisingly) off on this?

RAM is accessed at 3.072 MHz

Isn't ram always accessed at slowrom speed (2.56MHz?) while rom can either be accesed at slowrom or fastrom (3.58MHz?) speeds depending on the cartridge?

Also, I'm assuming the Wikipedia article was written by someone over at Sega 16?

higher bit-rate competition such as the Sega Genesis.

As part of the overall plan for the SNES, rather than include an expensive CPU that would still become obsolete in a few years, the hardware designers made it easy to interface special coprocessor chips to the console

[93143]

It seems like there are a lot of weird tricks I don't yet know about.

This one is rare. As far as I know, mid-scanline BGMODE switching has been done only three times in the history of the SNES - once in a cracktro for Bubsy 2 done by Anthrox in 1994, once in a menu test screen for the RPG Ramsis is working on, and once (well, a few times) in my preliminary work on that shmup port I've been poking at.

I'm guessing this would be way too slow for trying to change the color of every pixel to create a 16bpp bitmap?

You can write one 16-bit word (corresponding to a 15-bit RGB triplet plus one dummy bit) every four dots with DMA to CGRAM, except during DRAM refresh right in the middle of every scanline where the CPU pauses for 10 dots. To my knowledge this has not been tested and may not work, and even if it does the DRAM refresh will ensure it doesn't work well. Though I suppose you could rewrite the colours for that area during HBlank...

You can do it on the Mega Drive, though - since DMA to CRAM is 16-bit, you can write one colour every two pixels, which looks half-decent. And there's no DRAM refresh region, so the whole screen is accessible. This technique is called "FantomBitmap" and was developed fairly recently.

Isn't ram always accessed at slowrom speed (2.56MHz?)

That's 2.68 MHz. 21.477 MHz master clock divided by 8. (Or 21.281 MHz for PAL, resulting in 2.66 MHz slow access.) Mind you, nothing happens during DRAM refresh, so globally FastROM and SlowROM are more like 3.47 and 2.61 MHz (3.44 and 2.58 for PAL).

If you happened to have some SRAM in the cartridge mapped/mirrored in the FastROM region, you could access it at high speed...

禁則事項です。

Google Translate?

Anime reference.

Enjoying your "froyo"?

I have honestly never seen that word before. Checking their website, it seems the nearest location is about 3 hours away by car...

I'm assuming it was called the Genesis there also?

Yeah, Canada tends to get lumped in with the U.S. in these matters, because it's culturally similar and has comparable income levels, a huge open border, and 1/9 of the population (mostly living within a few hours of said border), so it isn't worth it to treat it as a whole separate region. (Regarding video games specifically, it doesn't hurt that Canada is an NTSC territory with the same power outlet standards as the U.S., so hardware that works there works here.)

But there are still weird little differences. Ever seen these?

[Drew Sebastino]

This one is rare. As far as I know, mid-scanline BGMODE switching has been done only three times in the history of the SNES - once in a cracktro for Bubsy 2 done by Anthrox in 1994, once in a menu test screen for the RPG Ramsis is working on, and once (well, a few times) in my preliminary work on that shmup port I've been poking at.

Wow, of all things, Bubsy 2... You know, this technique seems really pretty useful. Couldn't you use it for column scrolling in non supported modes by changing BG layer Y coordinates during the scanline? Heck, you know, if this is something that has to be changed every scanline, couldn't you actually have it to where there's a diagonal window of Mode 1 to 3 or something?

If you happened to have some SRAM in the cartridge mapped/mirrored in the FastROM region, you could access it at high speed...

Anime reference.

Yeah, I wouldn't have gotten that...

I have honestly never seen that word before. Checking their website, it seems the nearest location is about 3 hours away by car...

Apparently, it's a Canadian only frozen yogurt chain. "Froyo" is the "cool" way of saying frozen yogurt. Dang though, talk about product placement. I wouldn't be surprised if Nintendo owned Yogurt's (which has only recently been known because of them): https://twitter.com/yogurtys

But the fun doesn't stop there... https://www.facebook.com/yogenfruz (yes, this is an entirely different frozen yogurt chain.)

But there are still weird little differences. Ever seen these?

mnm's in a smarties container?

[93143]

Wow, of all things, Bubsy 2...

Not the game itself. A cracktro (or so it appears) inserted by a team called Anthrox. Behold! This technique will be possible in higan v095.

You know, this technique seems really pretty useful. Couldn't you use it for column scrolling in non supported modes by changing BG layer Y coordinates during the scanline?

Maybe, but you'd have to line up the writes pretty precisely so they'd happen where you wanted them, and you'd sacrifice a lot of compute time doing it. There's a reason only one game (if I'm not mistaken) ever did that...

Heck, you know, if this is something that has to be changed every scanline, couldn't you actually have it to where there's a diagonal window of Mode 1 to 3 or something?

Like I said, it eats a lot of real estate, as well as glitching the screen. (Not sure if Mode 1 -> Mode 3 causes glitching, but Mode 5 -> Mode 1 does, and Mode 7 -> anything causes a lot of it.) My game has a 32-pixel-wide column of sprites dedicated to masking the garbage that results from the mode change, and it only looks okay because all the writes fall in a dark area of the sprite mask so you can't see the remaining glitch pixels very well.

And the only reason that's true is that I used timed code in the interrupt to check the H-position and stagger-step in order to line up the writes tightly enough within a single 8-dot column to avoid visible glitching when the main code is using instructions as long as 7 cycles (I was aiming for 8, but there was some slight glitching outside the target column). After this, the interrupt zeroes BG1's scroll values, changes BGMODE (+ MOSAIC, since I'm using 16-bit writes) and CGADSUB + COLDATA, and does a decrement+branch on a line counter in WRAM so I can do a couple of things I ran out of HDMA channels for (one of which probably shouldn't be done with HDMA anyway).

This interrupt alone eats nearly half of the available compute time during the playfield display. Adding in my heavily loaded HDMA schedule bumps it to around two-thirds. Fortunately this happens to be a Super FX game, so if I find I'm running out of CPU time, the GSU can pick up the slack...

You might not need the full functionality of my IRQ, but keep in mind that the IRQ timer registers are internal to the CPU, so you can't write them with HDMA. This means you'd have to add that functionality to the interrupt if you wanted to move the trigger point every scanline.

Alternately, you could use timed code over the whole frame instead of an IRQ. Again, it's harder than it sounds even without trying to get any useful work done during the frame - or maybe that's just because I was running HDMA at the same time; I never did figure out what the problem was...

https://www.facebook.com/yogenfruz (yes, this is an entirely different frozen yogurt chain.)

Now that name I know - our local Cineplex has one.

mnm's in a smarties container?

Those are Smarties. And no, they taste nothing at all like M&M's, or as little like them as they possibly can while being basically the same thing...

[Drew Sebastino]

Behold! This technique will be possible in higan v095.

Wow...

Maybe, but you'd have to line up the writes pretty precisely so they'd happen where you wanted them, and you'd sacrifice a lot of compute time doing it. There's a reason only one game (if I'm not mistaken) ever did that...

By wasting computing time, I assume you mean like checking how much processing has been done to know when to send the information, because it needs to be timed perfectly? Wait, didn't you say you could create an interrupt for this? What would be some bad processing wise than?

There are honestly dozens of possibilities for this, even if you do need an extra chip.

Now that name I know - our local Cineplex has one.

Did you ever try the nasty-looking product placement yogurt? (Or should I say "froyo"?)

[AWJ]

This one is rare. As far as I know, mid-scanline BGMODE switching has been done only three times in the history of the SNES - once in a cracktro for Bubsy 2 done by Anthrox in 1994, once in a menu test screen for the RPG Ramsis is working on, and once (well, a few times) in my preliminary work on that shmup port I've been poking at.

Wow, of all things, Bubsy 2... You know, this technique seems really pretty useful. Couldn't you use it for column scrolling in non supported modes by changing BG layer Y coordinates during the scanline? Heck, you know, if this is something that has to be changed every scanline, couldn't you actually have it to where there's a diagonal window of Mode 1 to 3 or something?

No, mid-scanline raster effects really aren't very practical at all on the SNES which is why they're so rare. If you want an angled split screen like the DBZ fighting games, or a side-HUD like every console port of a shmup that originally ran on a vertical monitor, then using the clip windows or one of the offset-per-tile modes is much easier.

The problem with doing mid-scanline effects on the SNES is that a single CPU cycle takes from 1.5 to 2 pixels worth of time to execute, and the shortest instruction on the 65816 takes two CPU cycles, so the most precise positioning possible is about 1 tile, and even that requires tricky cycle counting which prevents you from doing much of anything else with the CPU at the same time (like, say, gameplay calculations). Furthermore, mode changes in particular produce a very large and visible stripe of garbage on the screen that you have to cover up with sprites.

Air Strike Patrol does exactly what you're suggesting, changing a Y scroll register in mid-scanline to make the word "READY" rotate as if the letters were on the faces of a row of cubes. They work around the precision issue by doing the effect on a BG layer that's mostly blank/transparent (it contains the HUD at the left edge of the screen, the "READY" in the middle, and nothing in between) and the CPU usage is irrelevant because the effect is displayed at the start of a stage before you actually start playing (also, the effect only spans a few scanlines, not the entire height of the screen)

[Drew Sebastino]

a single CPU cycle takes from 1.5 to 2 pixels worth of time to execute

How is it "1.5 to 2"? Don't all cycles take the exact same amount of time? Or is it really like all cycles take 1.75 pixels or something? Also though, if you're using a fast expansion chip, you shouldn't have to worry about this problem, should you?

[AWJ]

a single CPU cycle takes from 1.5 to 2 pixels worth of time to execute

How is it "1.5 to 2"? Don't all cycles take the exact same amount of time? Or is it really like all cycles take 1.75 pixels or something? Also though, if you're using a fast expansion chip, you shouldn't have to worry about this problem, should you?

No, all cycles don't take the same amount of time on the SNES. A fast cycle (accessing FastROM or MMIO) is 1.5 pixels (6 master clocks), a slow cycle (accessing SlowROM or WRAM) is 2 pixels (8 master clocks).

Expansion chips in a cartridge can't directly write to the PPU (or to anything else on the console motherboard). Only the S-CPU can.

[Drew Sebastino]

No, all cycles don't take the same amount of time on the SNES. A fast cycle (accessing FastROM or MMIO) is 1.5 pixels (6 master clocks), a slow cycle (accessing SlowROM or WRAM) is 2 pixels (8 master clocks).

You know, what happens if you try to send this data on a "half pixel"? (will it count as 0 or 1 or something else?) I imagine that if you are using FastROM along with WRAM and you're wanting to just have a precise split down the screen or something, you could do a mixture of both 1.5 pixel and 2 pixel cycles to perfectly make any number over 1 (which I'm not sure why you'd do it then anyway).

Expansion chips in a cartridge can't directly write to the PPU (or to anything else on the console motherboard). Only the S-CPU can.

I know, unfortunately. I'm still not sure why they didn't add a way, considering they didn't seem to have a problem with adding an expansion port on the bottom of the system that pretty much went unused.

[tepples]

Is it me, or is Wikipedia (unsurprisingly) off on this?

RAM is accessed at 3.072 MHz

Isn't ram always accessed at slowrom speed (2.56MHz?) while rom can either be accesed at slowrom or fastrom (3.58MHz?) speeds depending on the cartridge?

Also, I'm assuming the Wikipedia article was written by someone over at Sega 16?

3.072 is right on for the speed of RAM access on the APU side. The S-SMP gets one cycle out of three and the S-DSP gets the other two. It's also coincidentally an average between 3.6 MHz (fast ROM and PPU ports) and 2.7 MHz (slow RAM). Does any reasonable Super NES emulator output the fraction of cycles that are slow or fast?

As part of the overall plan for the SNES, rather than include an expensive CPU that would still become obsolete in a few years, the hardware designers made it easy to interface special coprocessor chips to the console

Extensibility was intentionally engineered into the NES, according to two articles published during the third year of Nintendo Power (issues 13-24; I lack exact issue numbers). The second was titled "Why Game Paks Never Forget" or the like. I remember it using an analogy that one could upgrade a car by replacing its engine.

[Near]

> Does any reasonable Super NES emulator output the fraction of cycles that are slow or fast?

No, but that's an easy mod to make if you wanted to track that. Hardest part would be hooking it up to display in a window.

> Also, I'm assuming the Wikipedia article was written by someone over at Sega 16?

Speaking of that, are there any mods left there? Been waiting over a week for an account activation.

[DoNotWant]

>

Speaking of that, are there any mods left there? Been waiting over a week for an account activation.

The first time I tried I had to wait about a month before being denied.
The second time I tried I had to wait about a week. Slow as hell, and some of those guys seem REALLY hostile towards the SNES.