nesdev.org

I realized I'm heading toward disaster. I have everything in bank $00, and that includes everything in ram in that nothing leaves the first 2KB. If I want my object table to be a good size, let's say 32 bytes x 64 objects = 2048 bytes, that'd be exactly the first 2KB. I was wondering, I know $00-$3F and $80-$BF have 2KB of ram at the beginning, but is it the same 2KB, because if so, that's not helpful to me. The main problem is that if I have my object table in banks $7E or $7F, I don't have access to any rom data. Actually, wait, I have still have direct page. But wait, it can't move out of bank $00... So if I do that, I'm stuck with only the first 32KB of rom data. Because you're pretty much always going to have to use the object table, you're basically stuck with only using that much data for anything that isn't being DMA or HDMA transferred, so any tables for metasprite or animation information have to fit in there. I suppose one thing I could do is have some of the object tables in the first 2KB of ram. It'll be nice, because I'll have an overlap of object data that can access rom and the rest of ram, depending on what I have the data bank register set to. Can you only change the bank register via PHB and PLB? (I've never done it before, so I wouldn't know) Yeah though, I guess this won't be as hopeless as I originally thought. I can even DMA some data over to ram on startup that I'll use as rom. Too bad it'll only be at 2.65MHz though...

Don't you mean 8kb?

Wait, really? Wow, I'm an idiot... False alarm.

Espozo wrote:If I want my object table to be a good size, let's say 32 bytes x 64 objects = 2048 bytes

That doesn't sound like a lot, considering this is the SNES we're talking about... The Genesis has half the RAM and Sonic still has 96 64-byte object slots. Even the 8-bit Sonic games dedicate 64 bytes to each object, but they obviously have fewer slots (32 maybe?).

I don't know what kind of game you're making, but I can tell you I'm having a hard time making everything fit in just 32 bytes per slot in my NES game. It's true that I do need more physics stuff than most NES games, but from the stuff I read here it looks like you have a lot of complexity related to sprites and patterns. Are you sure you don't want to use 64 bytes per slot? Even if you don't need all that most of the time, doing this will at least save you the trouble of figuring out which offsets can be reused for different purposes on different object types by analysing the requirements of each one to avoid conflicts.

It's funny how Sonic has more objects than the Genesis has sprites. It sounds like they were making sure that Sonic never runs out of objects.

As for Sonic the Hedgehog series on the Genesis

Among the 96 sprites in the sprite table, only those sprites that overlap the 320x224 pixel camera window need to be included in the list of 80 sprites sent to the VDP. The rest can be clipped out. But now that I think about it, the 2-player mode of Sonic 2 has two camera positions. Does it send a second sprite table during forced blanking in the middle?

As for Super NES RAM capacity

The Super NES has 128 KiB of RAM, but many addressing modes apply only to data in the current data bank. And if you want to access both RAM and ROM using these addressing modes at the same time, you'll need to put RAM and ROM in the same bank. This means you're stuck with the 8 KiB at $7E0000-$7E1FFF, which are mirrored into banks $00-$3F and $80-$BF.

tepples wrote:But now that I think about it, the 2-player mode of Sonic 2 has two camera positions. Does it send a second sprite table during forced blanking in the middle?

I have no idea, I also wonder about that.

The Super NES has 128 KiB of RAM, but many addressing modes apply only to data in the current data bank. And if you want to access both RAM and ROM using these addressing modes at the same time, you'll need to put RAM and ROM in the same bank. This means you're stuck with the 8 KiB at $7E0000-$7E1FFF, which are mirrored into banks $00-$3F and $80-$BF.

Are you saying that a typical SNES game has less RAM that it can directly access than an NES game with 8KB of WRAM on the cartridge? SNES memory mapping is really confusing... Why would they use such a convoluted design in a 16-bit console? Are these absurd limitations imposed by the CPU or did Nintendo really screw this up by trying to keep things somewhat similar to how they were on the NES?

tokumaru wrote:Are you saying that a typical SNES game has less RAM that it can directly access than an NES game with 8KB of WRAM on the cartridge?

A SNES game can directly access all 128kb (or more) of RAM at all times. The 8kb of RAM that is mirrored to multiple locations only affects the possible size/speed of some read/write instructions.

Are these absurd limitations imposed by the CPU

Yes, sort of.

One reason RAM and ROM are mapped the way they are on the SNES is because the stack has to be in RAM, while the interrupt vector table has to be in ROM, but both the stack and the vector table are always in the 000000-00FFFF range (bank 0).

did Nintendo really screw this up by trying to keep things somewhat similar to how they were on the NES?

Also yes. (Because arguably, if they weren't aiming for similarity with the NES then they could have used a different processor entirely.)

The only 2 limitations for accessing memory are:

1) The direct page and stack can only be located within bank 0.
2) You can't do long indexing with Y, unless it's indirect.

tokumaru wrote:

tepples wrote:But now that I think about it, the 2-player mode of Sonic 2 has two camera positions. Does it send a second sprite table during forced blanking in the middle?

I have no idea, I also wonder about that.

Indeed it completely rewrite the sprite table during forced blanking in middle of screen

It is possible to access all of WRAM through the WRAM registers as well ($2180-2183), though that's not really "direct access".

Nicole wrote:It is possible to access all of WRAM through the WRAM registers as well ($2180-2183), though that's not really "direct access".

Yeah, that's damn near useless.

Stef wrote:Indeed it completely rewrite the sprite table during forced blanking in middle of screen

That's pretty impressive... 96 objects really does seem excessive for any of the Sonic games though, it's not like it's Contra.

psycopathicteen wrote:1) The direct page and stack can only be located within bank 0.

I don't care about the stack, but the deal with direct page is a pretty big one. If you're loading from the other 120KB of ram, you're stuck with only using the data in bank $00. I'll probably just DMA some data to ram on startup. Object palettes are an example, because my routine needs access to them and it's not like the palettes are going to take an unrealistic amount of space. Plus, the data is rewritable. Donkey Kong Country has about 64 (Edit: I remembered that wrong, it's more like 128) sprite palettes total. Metal Slug probably has no more than twice that. (It's insane though, it appears Metal Slug does some sort of dynamic palette updating. Why? It never goes past 64 onscreen palettes, ever )

Revenant wrote:if they weren't aiming for similarity with the NES then they could have used a different processor entirely.

It seemed that this is the only reason the 65816 was ever used. I don't know anything else that used it except the Apple IIGS, and it used it there for Apple II compatibility.

I don't think the SNES's problem is the processor itself, but rather, the ram that's not even as fast as the CPU that's not exactly known for its horsepower (although I think it's lack of power is exaggerated, but that's another story). The memory mapping is silly (like I said, you can't load from any ram past the first 8KB and rom at the same time, it's like, why did they even put the other 120KB of ram in there to begin with?) and the communication with the SPC700 is really poor in that it takes too much CPU time to upload a reasonable amount of data. I know I'm going far overboard (my animation scheme and my palette changing stuff) but I find that most of the CPU time is spent making up for the PPU's shortcomings. I know that's ridiculous to say, but I can honestly see just about any arcade game from the time period running at the speed they do with the 65816, but there's so many background layers and animation and palettes and sprites that unless you're doing all this crap to compensate with the CPU (like sprite multiplexing, dynamic animation, etc.) which would potentially slow down the CPU too much, the PPU won't cut it.

tokumaru wrote:but from the stuff I read here it looks like you have a lot of complexity related to sprites and patterns.

Basically the only thing I've been doing in terms of programming has been object or dma to vram related. 32 bytes was kind of preposterous though. I'm at something like 26 bytes from all my routines, but I haven't even implemented any AI or physics stuff yet. I'll probably need at least 48 bytes, which with 96 objects (probably what I'd settle with. Maybe higher later, but 128 seems a little ridiculous) would be 4.5KB. However, say I want 64 bytes and 128 objects, I'm using the entire 8KB.

I think I found out my battle plan though. Like I said earlier, have whatever variables that have routines that don't need any information outside of the first bank will be past the first 8KB of ram. Whatever else will be in the first 8KB. Luckily for me, a lot of variables are (or are expected to) not touched by the actual object code. For example, I have X and Y position variables, but they are just for the total level. Then, I have onscreen X and Y position variables that a routine generates, and then these are used by the metasprite routine and other stuff. Non-onscreen X and Y are really only for object code, while onscreen is for everything else. What's nice (I want to make my engine as all-purpose as possible, just swap out a few routines for different types of games) is that I can have a simple "subtract x and y by camera x and y" or I can do something more complicated that uses multiplication and whatnot for a mode 7 racer.

Edit: (It's not worth to double post for this) Is "bmi" not the same thing as "and #$8000, bne" because it's not giving me the same result. I've been trying to speed up my metasprite routine, and I found that this was something minor I could do to help.

Also, what is the difference between "and" and "bit"? They both do the exact same thing, accept it affects an additional "V" flag, which is the "overflow" flag. I didn't know what that meant, so I looked it up, and I still don't get it.

(I felt that this was actually worth another post, obviously because I'm did just that:)

Damn it, you know what? I realized that when using direct page, the address can be no more than 1 byte. The reason this is a problem is that I recently slit all my tables apart into multiple because I was led to believe there was no advantage to doing it the other way. Turns out, I was wrong. So, great, upon formatting a table, I need to keep in mind all of the routines that are using it, and with an object table, that's a hell of a lot. I'm considering reverting my object table back to how it was in that everything is together like how it was. I'll just have to suck it up and fit the object table into the first 8KB while still having room to spare. I'll probably do some sort of weird number like 56 bytes x 112 objects for 6272 bytes, a little over 6KB. What's nice though, is I realized that direct page is always faster than x or y indexed, so in terms of processing power, I have about nothing to lose unless I'm trying to load a random variable in the first 8KB of ram, because I'll have to use absolute addressing instead of direct page, but in a routine that deals with the object table, I'm more likely going to load from it than the random variables.

You know what's funny? My old routines were actually closer to where I want to go than I am right now, in that I had the object table being indexed by direct page...

Yeah, somebody should have written a warning about this. It'd go like...

If using direct page, have a struct of arrays.

If using x and y, have an array of structs.

Triple post!

I found out that if I have 64, 2 sprite objects, the metasprite routine uses about 7/8's of the CPU time. (well, not quite that, the routine that makes the top 32 bytes of oam takes a decent size too.) Although there are some random optimizations I can make here and there, the real only way around it is to have a separate metasprite for if an object is flipped or not. As I've said before, I'm not to worried about space. If I do this though, I think I'll be able to get the CPU time down to 3/4's! It's not too hopeless though, as I'm not even using FastROM yet, which might get it down to 5/8's. I don't see me doing that palette thing though, unfortunately.

Well, I could also just make everything an unrolled loop...

Can you post some code?