Why did Super Mario RPG and Kirby Super Star use an SA-1?

From the information I can find, it looks like it's just there to speed up compression time between levels, and to cover up sloppy programming. Both of which sound like lame reasons to add a 10 Mhz CPU to the cartridge. These games are probably not using more than 30% of the SA-1's speed, and the S-CPU is probably doing nothing but sPPU updates, and HDMA effects.

*shrug* Copy protection, better compression with faster decompression, because it'd make their lives easier (no one cares if your code is sloppy if it runs fast enough, and sloppy code is often faster to write). Who outside of 1996 Nintendo/HAL/Square can say?

Whatever the reason, it paid off: KSS is easily the most fluid and dynamic platformer on the system, so it's hard for me to feel as though it's really going to waste there.

Ever played DKC 1-3?


It's easy for me to say it's going to waste; I see no reason as to why this game needs the SA-1. The DKC games do compression in real time and don't have any less action onscreen. I think the SNES only needs something like the SA-1(outside of 3D) for heavily action oriented games with real time compression, which (as far as I know) has never been proven to be possible.

Sure have. Ever played Kirby Super Star?

They may have already had a stock of them produced and needed to put them to use. And copy protection is not something to overlook. SNES was affected by piracy and titles like Super Mario RPG and Kirby would be games pirates wanted.

I have heard conversations before saying that the SA-1's potential wasn't really realized in any of the games released. But that doesn't mean it didn't have any benefit. Faster decompression, "covering up sloppy programming", copy protection, etc. All sound like good things to me. I don't understand why you say sloppy programming like they should have just "got good" instead. In the real world of making these games the consumer and the developer doesn't care if a game has sloppy code. The consumer cares that the game works and the developer cares that the product is finished on time.

Projects risk failure or cancellation if they do not meet milestones or reach completion on time. Projects you make on your own time you can spend as long as you want perfecting every little detail. This luxury doesn't exist in the professional industry.

Did Mario RPG have no effects requiring it? It's been years since I played it.

To be exactly how it is, it might require the SA-1. But I think the idea is that the same general game could have existed without the SA-1. It's harder to tell versus something like the Super FX games that clearly required the added hardware.

I think the SA-1 is a nice idea, maybe even worthy of being something like a 32X where you could sell the SA-1 chip to the consumer once in some form and then have game carts that plug into it. It's the same 65816 CPU but significantly faster with some extra goodies. Isn't that what most people complain about with the SNES? The lack of processing power.

Nintendo still should've optimized their SDK code library from time to time so that developers weren't limited by the same old routines.

*decompression


Why would they be limited? They could easily write their own routines.

Because writing a new routine would take 2 seconds longer than copying and pasting code.

BTW, does anybody know if the decompression in KSS and SMRPG is done in real time, during a load time, or done dynamically?

I also think it wasn't fully used, as some other chips that are used in only a couple of games.
Nice to know my impressions based on random compararisons are somewhat real

KSS uses exactly the same (de)compression routine that HAL had been using since circa 1989 (Adventures of Lolo, etc.) As far as I know it's only used during screen/area transitions and so on, in a pretty standard way.

There are zero games that show off the power of the SA-1, sadly.

The best examples are the two golf games that render entire scenes to a giant bitmap. But it's ruined by the fact that it takes 5+ seconds to draw one scene this way.

The chip also has over a dozen features that not a single game ever used. It's ... quite mind-boggling.

Yes, and I even own Kirby Super Star Ultra. I still don't know what you mean; it's always felt like an early SNES game to me in terms of graphics (aside from the partially prerendered backgrounds) and mechanics. I suppose there is a lot of versatility though (being able to bring the second character that can look like any of the enemies anywhere), but it's still no better than DKC where everything is dynamically loaded in, which makes it possible to put any enemy anywhere (not counting running out of space in the object table) as long as the palette (objects using the same palette won't add to the limit) and vram limit aren't met. (Bosses don't work properly outside of their stages, though, as they break the vram system.) There is more total animation going on in the DKC games.


Well, wasn't this game more expensive than other SNES games at the time? It's not like there were no drawbacks to using the SA-1 (otherwise, every game from the time period would have it.)


Most people see how Super R-Type and Gradius III run like shit, and then look just at 3.58 and compare it to 7.68 without taking into account memory accesses per cycle, or bus width, or ISA, or whatever.


What psychopathicteen said. The decision to use the SA-1 was more than likely driven by laziness time.


Well, that settles the discussion!

If Super Mario RPG or Kirby Super Star could be rewritten to not use the SA-1 and still be the same game(s) without any performance penalties, that would be amazing for all SD2SNES users. The SD2SNES compatibility page says that SA-1 support is "to be determined". On top of that, I have a GamerzTek clone SNES which I've heard is incapable of handling SA-1 (and S-DD1) games, and if that rewrite ever gets made, I would absolutely put these games on my SD2SNES. Super Mario RPG is easily the game I have the fondest memories of from my childhood.

However, Super Mario RPG stores some data that isn't just scratchpad into the IRAM, including the current party formation at $3033-3037, so that raises a potential issue for both it and Kirby Super Star: obviously, the BW-RAM would become SRAM, but will the internal WRAM and cartridge SRAM combined have enough space for whatever these games stored into IRAM?

I've heard about a StarOcean hack that used no SDD1 chip.
Instead, it used a larger ROM.
That would be a nice thing to do on SFA2 too.
SA1 is a different history...


Comparing with other SNES games the end result is kind of disappointing.
I wasn't aware that this specific Kirby's game used a special chip back in the day, and I found quite annoying it just worked in the "not unlocked" SNESes.

I just imagine how different the DK games would be if they used and explored that chip capacities...
Well... anybody can imagine lots of things. And this sure would make a _very_ long topic.

Exactly; making KSS run on the SNES only would be a near rewrite.


I'm not quite sure what they would have done; everything that could be considered a technical limitation (not much stuff onscreen, no complex AI) could also be considered part of the game's design. The game could have looked much better if background tiles were loaded in with the level moving, (backgrounds are pretty repetitive and obviously part of a tileset, which doesn't work way to well with the otherwise varied graphics) but I think this has much more to do with cartridge space and extra effort on developing more of the environment. I will admit, I've never had a clue how they prerendered the backgrounds; with the objects, you can just take a picture of the whole thing from whatever camera angle, but there's no way to do that way with the whole background, and even if there were, you'd have some really weird sheering issues. There are loads of perspective issues in the game, (particularly prevalent with hard edged platforms) but that's unavoidable.

That wasn't my point. My point was primarily that spending significantly more time developing a game isn't always an option. Adding the SA-1 certainly did raise the cost of games which is probably why I believe of the fairly small number of games that used the SA-1 only a fraction of those were released outside Japan. You'd want to be very confident in your game selling well enough if you were going to raise the cost. More games could have benefited from the SA-1 if it had been offered in a 32X-like or Game Genie sort of form factor. But then you risk confusing consumers.



There are other examples too but I think those are infamous for slow down. I think you are saying how people compare the SNES CPU clock against the Genesis without understanding they are different designs. But what about comparing the SNES to the TurboGrafx 16/PCE which does share CPU design? And its CPU really does run at over 7mhz. And it came out prior to the SFC.

That just proves the game was smartly designed around the technical limitations. Perhaps they'd have gone in a slightly different direction given quadruple the processing power plus a bunch of potentially useful bells and whistles. Like how Yoshi's Island made clever use of the Super FX, without being obviously a Super FX game.


The SD2SNES incompatibility list has 26 SA-1 games on it. That's the same size as the DSP-n library, which isn't too bad considering the first one came out in 1995...


But it doesn't share the same CPU design. The HuC6280 is 8-bit. It's a slightly souped-up NES CPU.

All that demonstrates is that Nintendo wasn't absolutely locked to low clock speeds once they picked the architecture - they could have customized the CPU to get rid of the phi1/phi2 nonsense and doubled the clock, but they didn't. It does not mean the PC Engine CPU was twice as powerful.

...

The sad fact that no existing game really exercises the SA-1 is unlikely to change in the near future, given how tough it is for a hobbyist to make a game that takes proper advantage of just the base console. Also, if I understand correctly, emulation of the SA-1 is not currently accurate enough to serve as a development environment for a game that pushes its limits; apparently a memory controller capable of giving two CPUs simultaneous access to multiple single-ported writable memories is hard to emulate for some reason...

The 65816 doesn't limit their clock to 3.5 in any way, even with the requirement for Phi0/1, it is stable when over-clocked to 20mhz using the WDC fabrication, maybe Nintendo dropped the fab tech to make it cheaper? A NMOS 6502 will do 4Mhz fine according to Mencsh, the HMOS-II 8500/2 will do it as well.

I would think the main reason they used an SA-1 was for copy protection and region locking, at the end of the SNES life piracy would have been a bigger issue than before and the Grey/Red imports markets would have been well established and oiled.

You shouldn't however use every chips feature for the the sake of it, you should use what you need for the gameplay at hand. Maybe the bitmaps gave better compression so using the built in hardware bitmap->planes was the main use, especially since it was something a stock SNES couldn't do. Or the Huffman bit stream assistant, or the Extra ROM it allows, or the Extra RAM. Maybe running a 65816 at 10mhz allowed them to just use C and hang the cost, but dev faster. Using a 10mhz chip would have allowed them to do more in a scripting system which on a games of the larger size, helped a lot, as you could get the cheaper designers to do more logic work.

What is the Nintendo SNES SDK? I've not heard or seen anything about it, got a link?

What cart size does the Star Ocean no SDD-1 patch use? But again it might have been cheaper for them to use the SDD-1 than the larger ROM size when you factor in the money saved on piracy.

The Star Ocean no S-DD1 hack expands the ROM size from 6 MiB to 12 MiB (48 Mbit to 96 Mbit), which is more than any ExHiROM or ExLoROM. I believe the SD2SNES supports this hack already. Street Fighter Alpha 2 does not have a 12 MiB hack.

Specifically, the memory map goes like:

It's just a theory of mine that I've pieced together through bits of information I could find. It sounds like developers were so strict with time they couldn't even write original code, and had to rely on reusing the same code from 1990 without improving or altering it in any way.

I mean, of course developers saved time by reusing old code and building off their existing engines. That doesn't mean that it came from Nintendo as part of a formal SDK.

TBH, I suspect that if Nintendo provided devs with a library of sample code, it would've been leaked at this point.

We know they provided a set of sample routines ("library"?) for using the mouse, super scope, and multitap: Fullsnes § detecting controller support by searching for magic strings inside ROM images

It does if you need to operate reliably in a 120 ns memory without wait states.

Which suggests another obvious way to improve matters, that Nintendo actually used for slower memory areas... but it wouldn't get you to 7.16 MHz; maybe making the process reliable to 10.74 in order to go from 3.58/2.68 to 5.37/3.58 didn't seem worth it...?

There's also the trick the SA-1 used, which was to use 16-bit memory with a smart interface. A 65816 can sustain 10.74 MHz in ordinary FastROM this way, even without eliminating the address half-cycle, unless it encounters a branch or a random data access...

Okay, I think I figured out what you're talking about. Having the memory accessing "half" cycle longer than the other.

I was under the impression that SMRPG needed the speed for some attack animations that used a layer, but I'm not very in-the-loop on that.

I just found something that would be a limitation for SA-1 games, and that is sPPU write speed. The SA-1 only works with if the SNES is in slow ROM mode. There's a work around of doing self modifying code, and being able to buffer the DMA data with the SA-1. Are writes to sPPU and DMA still fast in slow ROM mode? If not would the SA-1 not work if the S-CPU is put in fast mode when doing vblank stuff, just as long as it's not touching ROM?

But other than that, I really want to make an SA-1 game. If I make an Alisha's Adventure 2, I'm definitely going to use the SA-1. It looks like Nintendo got their shit together when they designed it. I like how both the S-CPU and SA-1 can share the same memory space, and even the same ASM code, and how the S-CPU can even make use of the SA-1 registers.

DMA is always on its own weird timebase (4&4)
Otherwise, memory accesses to $xx2000-$xx3FFF and $xx4200-$xx5FFF are "fastrom" timing (3&3).
"slowrom" timing is 3&5.

Wait wait wait; weren't you a big advocate for saying the plain old SNES CPU is strong enough?

Yes, but I would be able to have multijointed bosses that take up the entire screen, and I wouldn't have to reuse the same sprites for arms and legs.

There is the How to read a Joypad, mouse, scope etc and How to Init the Snes code in the 2 books. Which where the rolls-royce of information about the machine and didn't come out for a while. Most devs I know were the "they gave us a couple of pieces of paper and didn't even mention Mode-7, then they released Mario-Kart and we were HOW HOW HOW", The programmers mostly would just poke random address to see what it did, to work the machine out That being said the PS2 came with about the same, although it at least had 6 books to tell you how things worked

Not if you hit the sprite tile per line limit first though. How much ram is used with the different rotations anyway?

NEC was one of the pioneers promoting the CD format in Japan in the eighties, so they thought it would make sense to make their own home console also support it. For this reason they used very fast RAM and other design choices that was necessary for a CD unit to work well with it. This lead to it being very good for arcade ports, and the CD games was able to compete in the 16-bit era for a while. The PC Engine is probably even faster than the Megadrive, but it was also very expensive when it was released, and was sold for below the manufacturing cost.

I guess one reason the SNES is so slow is because they initially designed it with Famicom compatibility in mind, and used an 8-bit data bus. I guess the 65816 was expensive to make run on a faster clock at the time.



Heh it was even harder during the NES era when western developers where given only partly translated dev docs. Japanese third-party developers also had a hard time from what I've heard from David Siller, Nintendo didn't want any third-party support at all first. I guess they finally designed the proper dev doc and even translated it into English in the end though. It explains all hardware features including Mode 7.

The Plasma Grinch takes 72kB:
Head: 32 kB for 64 32x32 frames
Body: 16 kB for 32 32x32 frames
Limbs: 16kB for 32 32x32 frames
Joints: 8kB for 64 16x16 frames

I didn't say the "same CPU design". I said they share CPU design. They are both related to the 6502. So you can compare them better than you can to the Genesis and its 68000. I also didn't say the PCE's CPU was twice as powerful. Although I'd imagine it has an advantage over the SNES. But you're right that what NEC did does illustrate that Nintendo could have had a faster CPU if they'd wanted. We can only speculate but I imagine it is the way it is due to cost savings.

Did SNES carts typically have more data in them than PCE carts?

Off topic, but does writing slow code really save time? What if code becomes so sloppy that it slows down development, and the only way to clean it up is by optimizing it?

It seems HuCards (the cartridge format for the PC Engine) generally ranged from 256 KB to 1 MB. Apparently there was only a single PC Engine game on HuCard larger than 1 MB, namely Street Fighter II' clocking in at 2.5 MB.

As for writing slow code, it depends. Of course there are things that, for instance, happen every frame, and those generally need to be well-optimized. However, sometimes you'll have code that you know won't need to be that fast. For instance, level decompression/loading doesn't have to be that fast, because there's ways to hide it, like screen transition effects you can hide the loading time behind. If you're smart about optimizing the stuff that really has to be, it can certainly save development time.

Yeah, but what Espozo was talking about was people blindly comparing clock speeds. Going from 8-bit to 16-bit is way too big a difference for that sort of comparison to be anywhere near right. Not to mention that the instruction sets went in different directions from the 6502 baseline.


Probably.

It's also possible that some of this extra stuff would have fit, but they didn't think of it, or have time to implement it, or something like that. If the current technical information re: the Switch is accurate, my understanding is that Nintendo could have literally doubled CPU power, RAM bandwidth and maybe even GPU power without appreciably harming battery life, simply by going to 16 nm FinFET (less power consumption at a given clock speed) and customizing the chip more (A72/73 with 128-bit bus and 3 or 4 SMs). Then again, that could be cost savings too; 20 nm is supposedly more expensive than 16 nm FinFET, but that may not apply when the vendor is trying to dump an unwanted wafer contract... and of course adding SMs to the GPU would eat die space, even if the impact on battery life were minor at such low clocks... naturally the design process itself wouldn't have been free...

(That's the impression I got by lurking on NeoGAF, anyway. Anyone here know better? Or am I too far off topic?)

Pretty much, in most cases LOADS of time. Lets take a really simple example.
Given I have 7 sprites and I want to set their x,y and image ptr. Let imaging that it makes a square box, like a dialog or something. The dumb way of doing this would be something like

Which is code you can write straight off the top of your head, you don't really need to think about it. However it is really bad code. To which I now have to sit and think about a couple of options. 1 all of the addresses are in a line, so I could just use ,x but that eats more CPU time, do I need this code to be clock fast, am I in a VBlank for example... Maybe since there are shared values it would be not to much room to just unroll the loop with the values... well lets have a stab at the ,x method. looking at the code there is a two groups, the D0XX and the 204X so let make a couple of loops, first lets make sure that X doesn't hold an important value I want to preserve, or find a better place where I don't care about X before I trash it
Much nicer, less to type, but I had to scroll through the code to find a place to park the data, but still, two loop is a bit odd right, I mean it could be 3x4 so lets fix the code
well if I don't need Y, I can get rid of the SpriteData, nah for 4 its not worth it, maybe if I was setting all 8 it would be..

This is all well and good but we are in a production house and we use macros because they are awesome and setting a sprite is something we do a lot so we have a
so the first code becomes

which was a lot faster to type than anything above. And it also doesn't have a giant wall of code for you to scroll past and go hmmm that is a lot of code, I should fix it...

Now lets imagine for a second that the artists decided to put a small flourish in the bottom right corner of the dialogue box, but the flourish goes above the sprites top pixel, but as there was room left below the normal line they put the flourish all one sprite as it was easier for them to visualise it, so now the bottom right sprite needs to be moved up 4 pixels so everything lines back up again. Go through the examples above and make the modification you need to make in your head and then tell me which one was the fastest for you to understand, see and modify what needed to be done?

Now imagine you moved the DB address on the 65816 and then when something else fired it didn't handle having the DB pointer moved on it, and it randomly crashed, and the lead programmer had to spend 2 days and $1000 in wages trying to hunt down the bug and fix it, for 20 clocks but if you used the slower long absolute it wouldn't have happened.

Usually smaller processes are far more expensive, often by 1.5-2x. Customizing a chip is also expensive, up to several million per shot, and there will be multiple since mistakes happen.

Disclaimer: I lurk semiaccurate, which I consider a higher quality source than a gaming forum, but I'm no factory pro.

Yes, though most PC Engine games used the CD format so they naturally had lots more data. Especially later games in the PC Engine's life was for CD.

I had acquired the impression that in this specific case, all else being equal, the newer process would be cheaper, either because 20 nm was just that bad or because nobody is using it any more.

But there were also rumours that Nintendo had gotten a ridiculously good deal from NVidia, and rumours on top of that suggesting that this may have been because NVidia was trying to dump their 20 nm commitments without paying contract termination penalties.

Of course, it may well be that none of this is true, and that there simply wasn't a lot of low-hanging fruit to be had...

That's what I've always figured, it just bugs me when people think you can't write code that is both optimized and maintainable under time constraints. I've seen programmers who thought this:



was more maintainable than this:



simply because optimizations are "risky".

Because the SNES only used cartridges and outlasted the PC-Engine it has many more large ROMs. The PC-Engine also being out in 1987 meant early games were limited by what ROM sizes were practical during that time. If the SNES was out earlier then you would have seen more early games with smaller ROM sizes. And if PC-Engine's HuCard format had been popular until 1996 or 97' like the SNES then you would have seen more large games and larger than were released.

Street Fighter II' was mid-1993 at 20 Megabits. Parodius Da! at Feb 1992 was 8 Megabits. Ghouls n Ghosts and 1941 for the SuperGrafx (which used the same HuCard format) are 8 megabits and released in 90' and 91'. So the PC-Engine seems it could have kept up if needed. But as Pokun pointed out there was a big shift toward the CD-ROM, Super CD-ROM, and later Arcade CD-ROM formats. The Arcade CD format allowed for 16 megabits of RAM in addition to the Super CD-ROM's 2 megabit. That's a whole lot of memory both for storage and random access considering it was available in March 1994. Plenty of SNES and Genesis games released at the same time period were smaller than that. I think Ninja Gaiden Trilogy released on SNES in 1995 was only 12 megabits.

I feel your pain. That is not an optimisation, that is just how you do it.

Another thing that annoys me is when someone dismisses an optimization because "it will only cost 2% of a frame" but they do the same thing 50 times a frame, resulting in slowdown.

This is a big fat straw-man. I can believe you found the former example in your disassembly of some shipped code. I don't believe you have any insight as to why the programmer wrote it that way.

There's certainly reasons to write slower code in service to maintainability, but this example isn't it. You need context to make such a justification. Five lines of assembly code is not a context; a hundred thousand line program that needs to ship by Tuesday might be.

You can't just act like someone deliberately considered those two alternative pieces of code and chose the former. There'a a million ways code gets edited mangled, etc. during production where everything is constantly changing. I think it's preposterous that you propose this was the result of an argument for maintainability.


Except the example you gave is 0.02% of a frame, not 2%, and you'd have to do the same thing 5000 times, not 50, and that's a real difference.

You're not representing the argument fairly here. I don't dismiss something because "it will only cost 2% of a frame", I was suggesting that optimization should be approached by profiling and working from the top down (example prior discussion), and that finding and fixing a thousand tiny pin pricks might not make the change you've hoped for.

What I really object to is you calling programmers or other labourers stupid or lazy or bad at their job for having written some inefficient code in one place or another. They succeeded at making a game that you liked so much that you're disassembling it 25 years later with tools that are like a microscope compared to their magnifying glass.

There is such a thing as doing a bad job, but making examples of extreme minutiae out of context isn't a good argument for it.

It's not like I'm saying "why don't they unroll every loop in the game?". If I was trying to fix a thousand nitpicks I would never have gotten this far with my homebrew.

But you're making assumptions about how the code came to be the way it is. You can't say that the cause for a specific instance of weird/slow code is ignorance, laziness or whatever, because you weren't there. We're seeing this code from a completely different point of view than the people who wrote it.

I for example am not proud of every single line of code I've written when coding professionally, because getting things done on time was more important than writing the best possible code for every little aspect of a program. The exact same happens with commercial games, there's always someone on your back expecting results, so there's hardly any time to look back on stuff that's already working to make improvements.

Now, you appear to be dead set on creating the most optimal SNES game ever, and from the forum topics I remember reading, you've rewritten your sprite system a few hundred times already. Has that gotten you any closer to actually finishing a game? Things are different when coding is a hobby. One could even argue that your hobby is actually optimizing code, not making games. The same thing happens to me, I've rewritten the same systems so many times in search of the best possible solutions it isn't even funny, and while that has been a good exercise in its own right, because it's a hobby of mine, it hasn't gotten me any closer to shipping a finished product. This is a completely different context from that in which the games you're debugging were created, and it's unfair of you to do some of the comparisons you make.

By all means, debug the hell out of them and point out all the weirdness and slowness you can find, that actually helps other coders make better choices in their own projects, but try not to make assumptions about why other programmers did what they did, it just makes you sound pretentious.

Unrelated, but I rejoice a little every time I see posts by rainwarrior.
Not only because of his avatar picture, but also because they contain
so much truth, sharp analysis and wisdom without ever being
insulting, arrogant or condescending.
My hat's off to you!

My code example didn't really drive my point across, but if I waste 60 cycles doing something, and that routine gets called 100 times, then it takes up 10% of the CPU time, and the 60 cycles wasted in the routine might include the above code.




Well, actually it did because I have less limitations to work with than I did back in 2010. I no longer have to manually squeeze sprites into VRAM.

Wow. That's even more than I have! (I'm actually in the process of rebuilding it again; I had broken routines into a million specialized subroutines that were faster, but I just couldn't keep up with it all and then I started to have to have to chain beq/bne to bra a bunch, which often mitigated whatever speed increase there was. I've also redone my metasprite routine to accept metasprite data outside of bank 0. I had direct page acting as an index register, as at that point I didn't know it was a cycle slower if it wasn't set to multiples of 256.)


It's because of me, right?

So is this what's going on:



Then you're going to do this?

Well, what I was referring to specifically was the problem I was having with the vram engine. In order to create the linked list, it would need to know what slot was used previously. To do that, it would look at the entry in the tile request table right before it. I had it find all the 32x32's for a metasprite, then all the 16x16's, as you wouldn't need to do anything to the number you were indexing by. The thing is, I had a 32x32 tile request table, and a 16x16 tile request table, which makes it to where you have to have a different subroutine for every situation; I had one for starting 32x32, one for starting 16x16 (if the metasprite had no 32x32 sprites), one for 32x32 to 16x16, one for continuing 32x32, and one for continuing 16x16. That's 5 different "groups" of code. The alternative is to also store the results for the previous slot as regular variables in ram as well as in the appropriate table. I started feeling like an idiot when I thought about how the speed of the code really wouldn't change much, as one absolute x indexed load is 4 cycles, while a direct page store and load is 6 cycles combined. However, with all the extra branches I had to do, the speed probably evened out, while the code was probably over twice as large. I really wasn't thinking...

How I did it was something like this:

Does something as short as "find_vram_slot" really need to be it's own routine?

My routine also sets up DMA.

What do you mean by "sets up DMA"?

This is my sprite tile uploading routine. I don't know how you could do any less of this in VBLANK and still be able to do the DMA transfer; all this is really doing is writing to the different DMA registers.

By setting up DMA, I mean building the DMA table.

You know I must say, the reason I dislike liscensed developers is not because they write inefficient code, but because a lot of them acted like know-it-alls in interviews. Treasure's lead programmers didn't say they couldn't get SNES to run Gunstar Heroes because of time constraints, they said because "the SNES's CPU can't handle the action, period" which I know is complete bullshit. Plus the fact that Konami jumped on the bandwagon, and made "Contra Hard Corps" on the Genesis which they've designed to be as CPU efficient as possible (even under time constraints) from the get go, unlike their SNES counterparts where they just threw together any code from NES games or 68000-based arcade games where they converted ASM code line by line, and just did a couple nitpick optimizations at the end.

Why would I spend my time fixing "a thousand tiny pinpricks" if I always attempt to write efficient code in the first place? Yes, I do make mistakes once in a while, but it's not like I make it a thing to always use memory as registers, literally, which a lot of people do.

I don't really understand how that thing I said a month and a half ago is relevant, so I'm not equipped to argue unless you explain what you're getting at.


OK? O_o?

Why are you mad at someone for honestly believing they couldn't port Gunstar Heroes to SNES 25 years ago? Or even if you must insist it was dishonest, they were beholden to Sega who was paying for everything they did; what exactly do you expect someone to be able to say in a PR situation like that?

Because I got banned from websites just for disagreeing with what Konami and Treasure said, and I needed help from people on the websites to explain stuff like how to use assemblers, how to set up NMIs and joypads etc.

There is no particular need to state any opinions and rub people the wrong way, or participate in discussions that rustle your own jimmies. Less stress for everyone ~

This kind of response sounds a little tone-deaf. Don't you think maybe these kinds of bands are handed out because of conduct and manners? In other words, the way disagreement is expressed?

I at least tried to explain stuff with math and logic.

Plus pretty much all of the stuff I wrote on those websites were edited by moderators, because they thought it was hilarious.

Why are you again bringing drama here, necroing a month-old topic at the same time? We don't care about forum drama.

Rainwarrior asked me why I don't like Konami.

I wouldn't call this drama, just slight radicalism causing conflict.

I don't really think it's fair to be mad at commercial SNES devs for poor code. Mine would look similar if I had to work on old hardware with a deadline.

If I was in a rush, I would just use crappier animation, which would actually save cycles.

Are you saying if you were in a rush you would do this?



Instead of this?

Okay, NOW the thing I said a month and a half ago is relevant again. ...but only because you're repeating yourself.

Do you have an actual source for these ridiculous "examples", or are they entirely made up on the spot? It's trivial to rewrite a piece of code to do the same work in more steps. Why would you waste your time doing that?

As I said a month ago, it's believable to me that you'd find such a piece of code somewhere, but since you've provided no source/context it's again pretty damn meaningless. If you want to actually cite something as it exists in a game, maybe there'd be something even worth talking about. We could ask questions like:

• "is this startup/loading code, or is this happening many times per frame?"
• "is this typical throughout the code or an isolated example?"
• "do some parts of the code appear to be written by an inefficient compiler rather than hand-assembly? did they have a scripting language of some sort?"

These might actually be interesting to discuss. Your constant assertions of "I write perfect efficient code and old commercial games are full of bad inefficient code" are quite frankly VERY DULL.

If you want to know the real reason Treasure didn't make a game for the SNES it's because NINTENDO NEVER HIRED THEM TO MAKE ONE. It had literally nothing to do with code quality, or whether the SNES could "handle" it.

If you wanna prove that you could port Gunstar Heroes to the SNES, please, by all means go and do that. I'd love to see more good homebrew for it. If you wanna patch some optimizations into Super R-Type to reduce slowdown, great! Please do it. You don't have to take constant vague piss shots at old games and developers to accomplish these things.

Many times per frame.

Typical throughout code.

Could be, I don't know.

As of where in these games do we find what code, that will take me a while to find, because I don't take notes of where exactly every code is.

Those weren't questions that can be answered without context. As such, those aren't answers, they're meaningless and pointless assertions. (Just like the "example" itself.)

+1 to everything rainwarrior's said.

And FWIW, if that code is real and not just a made up example, it's almost certainly the result of a compiler or a macro.

It's super-easy to imagine that some well-meaning dev at Konami or wherever wrote a macro that translates "ASL $00" -> "LDA $00; ASL; STA $00" to compensate for the missing addressing mode and save him some typing, and that this was part of their standard library of macros or whatever.

It's also super easy to imagine that their assembler had a code repetition pseudo-op.

So, I dunno, I also find it pretty easy to imagine that some burnt-out salaryman cranking out 1000s of lines of code a 14-hour workday to meet a deadline and who just wanted to get out to karaoke for the night and was working on non-core code just used a one-liner like "REP 4 { ASL SomeVar }" to shift a a variable in memory left n-times instead of writing 6x the code to do it manually.

Who knows, it might have even been mandated by project managers to use macros like that outside of performance-sensitive sections to make code denser, easier for other devs to read, easier to go back and edit, and less likely to have bugs in it.



Edit: oh, oops, ASL $00 isn't a missing addressing mode (I don't 6502 often right now). So I'm a little skeptical that this code is 100% real? ASL $00 x 4 is still easy enough to imagine, though.

…but we prefer thread "necromancy" here to its alternatives.

He seems to talk briefly and vaguely about these things. Example here: viewtopic.php?f=12&t=15794

He seemed to have an example that could actually be tested but then never seemed to revisit it. The idea of optimizing games that suffer bad slowdowns is a nice idea but I haven't really seen anyone do that.

I think it would be really great if psycopathicteen managed to optimize an old game and make it run better. That'd be pretty neat, and something I'd like to see the process of.

I even wouldn't mind a post that was like "why is this code in (insert game name) so stupid?" with a concrete example in its real context that we could look at and discuss. That stuff's totally cool.

This post, however, is none of that. It's some kind of challenge based on a false premise. Of course someone who knows 65XX would be very stupid to consider both those choices, and choose the former. Nobody would make that choice directly; it can happen naturally from process and iteration though, which I and others have been saying all along but you keep insisting that it's purely intentional. IT IS NOT. You're not even asking a question, you're just making some statement that you think you could have done their job better. Big deal. There are things that could be improved in any game that's ever shipped.

Since you're talking about optimising old games to remove slowdown, can I suggest this one as a candidate for this experience?
If someone can remove the slowdown in this game only changing its PRG ROM I would be VERY happy!!

I made a ROM patch for Super Ghouls and Ghosts a while ago.

This is great. IPS plz.

Hey now that's pretty neat, worth having its own thread too BTW.

The good thing is if you patch one Konami game you could probably patch them all

psycopathicteen should team up with OmegaMax and make a website together. First step in patching is doing the archaeology to work out what needs to be patched