SNES Splatoon (How do I shot HiROM?)

[tepples]

You generally shouldn't rely on open bus, but some games on the NES do.

There's good relying on open bus, and then there's bad relying on open bus. The bug in the music engine of Low G Man is the bad kind. But I had planned to use open bus at $4016 to help identify the connected controllers and whether it's an NES or a Famicom. I won't explain here because it's an advanced technique; those who are interested can see Riding the open bus.

[Mindscape games' reliance on unused bits of controller ports] ended up breaking these games on the PowerPak, which for some electric reason I'm not capable of explaining, changes the open bus behavior.

Pull-up resistors on D0-D7 was a hack added early on to fix OAM DMA problems in early revisions of the PowerPak.

[lidnariq]

Even mapper 185 is really just testing for "Contains correct data / does not contain same data", not exactly relying on open bus...

[tokumaru]

Seems like I was wrong about the copy protection thing, sorry about that!

[93143]

Wait, so "sta $2100" is the same in banks $00-$3F as it is in banks $80-$BF?

Yes. In all cases it's a write to INIDISP.

One thing I've noticed though is it looks like in the memory map I found, there's extra random junk near $8000 in banks $00-$0F, $30-$3F, and $80-$8F.

Yeah, some games undoubtedly put DSP registers or RAM in there, and there's no reason that has to be identical across all banks with system areas. But the internal stuff is, unless I'm sorely misled.

[Drew Sebastino]

DSP? You mean like the DSP-1 enhancement chip? (That's probably not even close... )

[93143]

Yes, actually. In a Mode 21 cartridge with a DSP-1, the I/O registers for the DSP-1 are mapped to $6000-$7FFF in banks $00-$0F and $80-$8F. There also appears to be an area of extra RAM in the same address range in banks $30-$3F, but I imagine that's optional...

Just be aware that if you start getting fancy, you can end up with extra stuff mapped in. If you aren't using the extra stuff, you don't need to worry about it yet. I know a fair bit about the Super FX memory map, even features no game ever used, because I think I'll need that stuff. The SA-1? Forget it - if I ever start seriously working on F-Zero SX or something like that, I'll have to learn it, but right now there are better places to focus my energy...

[Drew Sebastino]

if I ever start seriously working on F-Zero SX or something like that

Will you be able to go 3000+km/h with snaking, shift boosting, and MTS? You have to at least add Fat Shark.

[93143]

Naw, I was thinking I'd back off a little on the unphysical exploit-type maneuvers. The part that makes you go fast is your engines, and the physics model would reflect this. Drifters would work like in the GBA games, where you can pre-steer by compensating with the opposite drifter, but everything would be carefully tuned and tested to make sure there's no way to move any faster than by just driving in a straight damn line.

And I'm not sure the Fat Shark fits in with the rest of the palettes; there are only five or six free and every machine on the screen has to fit into those. In any case I wasn't going to have more than about 12-16 machines total - ROM limits, you see. I came up with a cool idea, and it eats ROM for breakfast... I may have to trash it... (I'd say "we'll see", but quite frankly we almost certainly won't...)

This would be a prequel of sorts to F-Zero X, set before the big accident; accordingly the speeds would be roughly X level at best, Blood Falcon definitely wouldn't be in it, and the driver of the Red Gazelle would be Clinton Gazelle (yes. And if you're curious, also yes)...

None of this is set in stone, obviously. It's basically daydreaming at this point, and likely to remain so.

[Drew Sebastino]

Naw, I was thinking I'd back off a little on the unphysical exploit-type maneuvers. The part that makes you go fast is your engines, and the physics model would reflect this. Drifters would work like in the GBA games, where you can pre-steer by compensating with the opposite drifter, but everything would be carefully tuned and tested to make sure there's no way to move any faster than by just driving in a straight damn line.

Yeah, I think F-Zero GX has become more about executing all these maneuvers without crashing than just driving, if that even makes sense. They're practically required for story mode though. The funny thing though, is that I started to do them all during the Grand Prix races, and even on Master, there was virtually no competition, as I'd finish a whole 30 seconds above anyone else on some courses. That's why it's more fun to play on max speed.

Anyway though, yeah, I have no clue how all those sort of "bugs" exist. I've heard that some of the staff ghosts use them though, like shift boosting in Lateral Shift, which would explain how they go so fast even in some of the worse vehicles.

there are only five or six free and every machine on the screen has to fit into those.

Yeah, I've always thought that even the SNES's color count was sorry. It's in a weird spot where it's big enough to where you don't want to have everything share palettes like a Genesis game, but not big enough to where you can safely have everything have its own palette. I still really want to try mid-screen palette swaps for sprites. Really, the number of typical sized sprites per line is about equal to 8 anyway. The biggest problem with this is actually programming it.

ROM limits, you see. I came up with a cool idea, and it eats ROM for breakfast... I may have to trash it...

I don't understand why people let ROM restrict them in this day and age, even after hearing people's reasons for it. They talk about trying to make the games authentic, but frankly, I find looking at the "true power" of the system is more interesting. I'm assuming you're not using mode 25?

This would be a prequel of sorts to F-Zero X, set before the big accident; accordingly the speeds would be roughly X level at best, Blood Falcon definitely wouldn't be in it, and the driver of the Red Gazelle would be Clinton Gazelle (yes. And if you're curious, also yes)...

Looks like someone knows their F-Zero.

I just thought of something... Are you no longer working on your other game?

[tepples]

I don't understand why people let ROM restrict them in this day and age, even after hearing people's reasons for it.

Because they lack the finances to pay artists enough money to create enough graphics and maps to fill 8 MB, the limit for mode $25 on Super NES and for oversized BNROM on NES. Or because they lack the finances to create a game that's a compelling purchase by itself, and instead seek to be included on a collaborative multicart. It's like writing a short story instead of a 1000 page door-stopper. How is each of these reasons invalid?

[Drew Sebastino]

they lack the finances to pay artists enough money to create enough graphics and maps to fill 8 MB, the limit for mode $25 on Super NES

I mean, they don't have to fill up the whole thing. It's more like telling the artists to stop because they've ran out of rom space.

Or because they lack the finances to create a game that's a compelling purchase by itself, and instead seek to be included on a collaborative multicart.

They shouldn't even have to worry about space then.

[tepples]

they lack the finances to pay artists enough money to create enough graphics and maps to fill 8 MB, the limit for mode $25 on Super NES

I mean, they don't have to fill up the whole thing. It's more like telling the artists to stop because they've ran out of rom space.

On the NES, adding more memory often means adding more bank bits to the mapper, which means the mapper must ship on a larger CPLD ($). Larger CPLDs and larger flash chips also tend to have voltage incompatibility with the 5.0 V signal environment of an NES or Super NES, requiring level shifters ($), and many lack an 8-bit mode, requiring multiplexers ($).

Has "telling artists to stop" been a problem with your past projects?

Or because they lack the finances to create a game that's a compelling purchase by itself, and instead seek to be included on a collaborative multicart.

They shouldn't even have to worry about space then.

They do if the multicart's inclusion policy rejects the entries with the lowest fun-to-space ratio so as to maximize the fun in a given amount of ROM space. Otherwise, the multicart would have to go to a bigger ROM. To take an extreme example, a 1 Mbit 5 V 8-bit DIP flash chip is cheaper than a 64 Mbit 3.3 V 16-bit TSOP flash chip ($) and the additional circuitry to make it work in a 5.0 V 8-bit environment ($) and make it flashable in circuit so as not to need a $4,000 programmer.

[Drew Sebastino]

Has "telling artists to stop" been a problem with your past projects?

You know very well that I have no past projects. I'd probably try and be my own artist anyway. (Well, the problem is that I'm slower than dirt though.)

[thefox]

[Mindscape games' reliance on unused bits of controller ports] ended up breaking these games on the PowerPak, which for some electric reason I'm not capable of explaining, changes the open bus behavior.

Pull-up resistors on D0-D7 was a hack added early on to fix OAM DMA problems in early revisions of the PowerPak.

Pull-up resistors were there from the start for voltage level conversion. The later hack was series resistors on the data lines.

[93143]

ROM limits, you see. I came up with a cool idea, and it eats ROM for breakfast... I may have to trash it...

I don't understand why people let ROM restrict them in this day and age, even after hearing people's reasons for it. They talk about trying to make the games authentic, but frankly, I find looking at the "true power" of the system is more interesting. I'm assuming you're not using mode 25?

I'm talking about machine graphics using up nearly all of the 8 MB addressable by the Super MMC (unless someone knows better; it sure looks like 8 MB is the limit), even when tepples' sprite scaling scheme is taken into account. This cool trick of mine roughly triples the amount of space taken by the graphics. Compression is an option, I suppose; unpacking something like LZ4 on the SA-1 might end up a fairly small fraction of the overall time required to get a sprite ready for VRAM...

One cool thing about prerendered graphics is that once you have the 3D model, it's not all that time-consuming to make more frames of animation from it.

Are you no longer working on your other game?

It's a bit stalled right now, but my plans haven't changed. I've pretty much satisfied myself that the SNES-side display engine will work, and I've continued planning how best to use the Super FX to plug the holes in the console's feature set. The next major step is a bullet test on the GSU, but it's on hold while I try out a BRR looping trick (which is likely to be useful for the shmup) and then test the cool sprite trick I mentioned above (which isn't). I suppose I could rearrange my priorities...

The big thing holding me back in SNES development is my day job, basically. It's unfortunately not the kind of thing where you can just go there for 8 hours and then come home and be free. I'm trying to finish a Ph.D., and it's sucking up all my mental energy. Worse, it's cognitively similar to SNES development, so any "free time" in which I have enough mental energy to work on this hobby could in principle be better spent on my research...