nesdev.com's "not" longest thread ever.

Again, the only reason I am posting this under SNESdev is because it is pretty much my "comfort zone". I remember looking at a discussion where tepples was showing an example of how to optimize code for the 6502 and the 65c816 and psychopathicteen said that those were the kind of "hardcore optimizations" that Space Megaforce uses and I was wondering how he would even know that. The only two ways I can think of (which are about as hard as mapping DNA) are to either open up a game file with a hex editor and look at the machine code and try to turn it into ASM (I'm sure some of file just codes for thing like the name of the file and other stuff though,) or you could possibly open up the game in a debugging emulator and change different values in ram and see what happens. The first method seems like it would take forever and the second would be way to confusing. (too bad the source code for these games haven't been given out. )

You just need experience. I'm not really sure what you're looking for, and I don't think you are either.. What does it mean to hack a game??? Um, whatever you want it to.

Some ppl like myself have gone into a game merely to change its color palette and we might call that a hack.. For instance changing a game characters look.. Other people get fancier, and they discover the formats/protocols to parts of the game -- like when someone discovered how the levels to Super Mario World worked, and then they created their own custom level editors and made new "hacks" of Super Mario World with all new levels. That's mega elite. Don't worry about being elite if you're having fun!!

Other hacks include figuring out what the game is doing logically and "re-routing" it to do something else.. The smarter you get, the bigger the modifications you can make.. I hope I'm helping you

There are automatic disassembly tools; some expensive (IDA Pro); some free (nescom, nesrevplus); some not fully automated (e.g. FCEUX+disasm6)

Based on the titles of these (I haven't looked them up) it looks like they are for the NES, unless the work for both. I have heard that coding for both systems is similar, but I'm not sure because I've never done anything for the NES. (I've always wanted to make a shooter and knew that the NES didn't quite have the "oomph" for what I was trying to do, so the SNES is the first thing I've ever tried programing for.)


Changing graphics is easy, (Unless they are compressed... ) as you only need a graphics editor. I am actually more interested as to how a lot of these games run instead of actually modifying them, so I can have a better idea as to how to make a game myself.

There's source code to a lot of Anthrox demos.
I have a ported BSNES with debugger for OS X here: https://github.com/bazzinotti/BSNES-0.64-OSX
IT's really useful. If you don't use OSX Get BSNES 0.64 for your OS. compile with DEBUGGER symbol active and whatever other features you need/want.. That debugger is Gold

Me and Tepples were poking fun at how bad programmers were with the 65816 because they were so used to 68000, and how optimizations are often seen as some kind of rocket science.

Yes, you and tepples sure do have a taste for technicals.

There's one major difference that's relevant to disassembly - the 65816's status flags can modify the length of instruction operands (e.g. LDA #$xx vs. LDA #$xxxx). If I understand correctly, this means that the disassembler has to be execution-based (ie: it has to step through the code and see what it does) in order to not get out of sync with the opcode/operand sequence.

I've actually had this problem with the no$sns debugger; it seems to disassemble code based on the current state of the status register, which can cause it to output nonsense if you're looking at a section of code that's supposed to happen with different settings.

^ ^ ^ precisely.

You won't have that problem with Byuu's BSNES Debugger

Focusing on just one part:



The term you're looking for is reverse-engineering. And yes, for commercial games that don't provide source code (such is the case of 98% of SNES/SFC games out there), the options you've listed are all that's available. There isn't any kind of "smart forensics" software that can use heuristics to analyse something and create source code for you, or tell you the hows/whys of a game's design. I'll go out on a limb here and say: the idea in itself (of such analysis software) is preposterous/ridiculous. Computers are only as clever as the human using them, but it becomes a recursive mess when a human tries to write something for a computer that analyses compiled/assembled results for a computer that was written by a human (lost yet?). TL;DR -- humans are clever, computers are not.

Disassembly of a game/program, followed by going through it line by line, is pretty much the only way you'll ever truly know what the game is doing. There are people out there who actually love doing this (psychopathicteen might be one of them); a colleague of mine also loves doing it (for any platform).

Furthermore, even if the source code to said commercial games was released, what makes you think it'd be more easily understood than a disassembly? Sure, now you've got multiple files laying around, probably thousands of labels and variables all with names you yourself have no familiarity with -- you still have to reverse-engineer the code more or less. You know what I'm saying? Just because source code is available to something doesn't mean the person looking at it can easily understand it.

But there is something that's kind of in-between these two things though: romhacking. It's hard to explain tersely, because the methodology varies per skill set of the person doing the romhacking. A lot of folks do Japanese-to-English translations of games this way, despite not knowing any 6502/65816 (really!). It greatly depends on the game though, as I'm sure you know. And a lot of the time, the romhacker (who has no assembly knowledge) gets stuck in their effort, and has to find someone who DOES know assembly to reverse-engineer part of the text drawing routine, or graphics routine, etc. and modify the code there so that it'll work with the desired goal. I've done romhacking stuff for a while now (usually helping out other romhackers), but I've never actually completed a project fully on my own. (I have two in progress -- one is massively insanely complex (god damn you Chun Soft!), and the other is less complex and doable but requires a lot of uninterrupted attention and is still complex in its own right (god damn you Konami!))

If you want to get into romhacking, there is an entire site and forum filled with people doing just that: http://www.romhacking.net/ (we used to host them at Parodius). Gideon Zhi also occasionally does Twitch streaming of his romhacking + debugging sessions, so you can watch/listen to him and what he's doing plus chat with him in real-time.

Anyway, all that leads to ask something..

You seem to do a lot of complaining about the state of programming (particularly in assembly) in these parts, and I get the impression you are very frustrated with the nature of the beast. Is that the case? Before responding -- I politely ask that you to read what I've said and sleep on it (trust me!). I need you to be introspective on this one. Know that I'm not attacking you (honest!), it's just that many of your posts have a strenuous/stress-induced nature to them, like you're frustrated about development on classic consoles. If you aren't? Cool/great! And if you are? Then that's okay too, but you should decide how you want to deal with that frustration. Starting out is difficult; none of this stuff is easy. But then again, think back to a subject in school (say, mathematics) that you had trouble understanding and got frustrated with (for me that would be advanced algebra, calculus, chemistry, and biology). As an adult nobody is forcing you to learn anything, so you can go at your own pace, or even simply say "Nah, I don't wanna do this any more". There's no shame in any of that! Don't let anyone tell you otherwise.

There is nothing easy about video game development on any system. Programming in itself is not easy, and game development adds a whole new layer of "omfg" to the picture. And don't even get me started on 3D stuff (I'll NEVER understand it, I find it all ridiculously complex and insane compared to 2D platforms). I've been doing what I do (with 65xxx and consoles both) since the mid-to-late 80s, and despite all that time I've never written a game. And there's a reason for that: I've spent so much time working "on" consoles (but not as low-level as guys like, say, lidnariq or kevtris) that my gut says "don't attempt a game, dude. You will get very very irritated and angry", so I don't. I've done a small little demo on the SNES included with my SNES docs (includes source), and also did the FF2e (NES) intro for Neo Demiforce in their translation project (and that had wonderful bugs due to us not knowing how the PPU fully worked at the time). Yet, on the flip side, guys like tepples are able to churn out a game in a few months (depends on how simple/complex) -- we're just different people.

I'll note that I did work for a few months on an Apple IIGS game, inspired by Gradius 3 and Space Megaforce (first time I've heard that game mentioned in years is in this thread, how funny!) but gave up because the IIGS's graphical capabilities were simply too limited -- mainly full-screen panning/scrolling wasn't possible (and not enough CPU time to do it all via software in one frame). My SNES sat next to me the entire time, taunting me. "Psst... you have 4 overlayed backgrounds here... you can set background X/Y positions for panning in only a few cycles... psst..." I guess the only "claim to fame" I have is doing an Apple IIGS demo along with a friend of mine.

I share these stories as a way to say it's okay to be frustrated (if you are), but that you may want to dig deeper to figure out how to leverage that frustration.

Random tidbit point, but for the 6502/NES, specifically FCEUX: its real-time debugger does stupid shit like this:


Look very closely at the instructions here -- these are opcodes which use ZP addressing, yet the addresses shown in the disassembly are full 16-bit absolute addresses (which use a completely different opcode). Ignore the = #$xxx stuff (that's just showing you, at that moment in time, what the contents of the effective address contained). Those instructions should read STA $DD, LDX $DE, INC $DE, LDA $DF, but don't.

I can't tell you how many times this has confused me / caused me issues / pissed me off. It's almost like someone is just doing printf("$%04X", address) for all addresses, no matter the opcode used. It drives me insane.

Man... Koitsu ninjaing me. Still posting.


The first step is usually finding RAM, which is pretty easy with a debugging emulator. The process is not changing values randomly, there's a method. You have a goal in mind.

A very common feature in debuggers allows you to narrow down RAM locations based on conditions. Say I'm playing a platformer, I want to find out which RAM value represents the player's X speed. If I stand still, it's probably gonna be zero.

So I eliminate every single piece of RAM that's not zero.
Then, I press right for a few frames to accelerate.
I now eliminate every single piece of RAM that either hasn't changed, or decreased.

Maybe there's only about three to four bytes of RAM it could be at this point. So I play in real time and watch to see which one corresponds to my movements.

Or... if there's still like sixty bytes of RAM, you let the player come to a stop completely. Then eliminate all RAM that isn't zero from your list.

Then press left and eliminate all RAM that either hasn't changed or increased.

(Just to note, the debugger keeps track of this RAM, and narrows it down. It's not like you've got a notepad file of what RAM it could be, and then have to verify each. You say, "Get rid of RAM that's not zero." And all RAM that's not zero is instantly gone from that list. You keep doing this until you've found what you're looking for.)

By now you've probably found X speed. Now, the above makes a few assumptions. It's not necessarily guaranteed that the RAM representing X speed is 0 when the player is standing still. And it's not necessarily true that the speed increases when you hold right. It could decrease (or do something weirder). But... you think what you'd do as a programmer and look for that.

After finding RAM, it's really easy to start to look into code. You can break on read and writes of the X speed variable, which will let you see how the game's acceleration works. Because the very code that is changing the variable is right there once the break happens! A good debugger will break the moment a write or read is detected, and show you the code around it. From there you could figure out what other RAM might represent in the context of code, again just thinking how you'd do it as a programmer.

As far as modifying the program, it's a lot like writing a regular program. The thing to understand is that every assembly instruction is represented by an "opcode". Which is a byte (or some bytes) that tells the CPU what to do. When an NES (or SNES) encounters $18, it clears the carry flag. If you were writing a program and typed CLC, it would become $18 once assembled. If you programmed for either console, you know what CLC does.

If you know how to program in the assembly language you're reading, you could look at the code the debugger broke on for X speed. (Which again, a good debugger would display as code and not hex. See what Koitsu posted from FCEUX's debugger.) You'd then figure out what changes you wanted to make, just like if it was your own program. And then you'd look up the opcodes for what you want to do and change what's there. (Or ignore opcodes entirely, and assemble a code snippet and paste the block there.)

The caveat with hacking (without a disassembly) is that you cannot simply add instructions in the middle of a routine that's already there, because it would break a bunch of branches and things. So you find some free space in the rom (depending on the rom, this can be tough) to add your new routine. And then you replace a few instructions in the area you want to add something to with a jump to that free space. You put your routine in the free space(with the instructions you just replaced with the jmp before the new routine so the program still executes them). At the end, you jump back. (Or just return.)

If you truly understand how to program with a given assembly language for a given system, hacking is not a lot of new knowledge. It can certainly be challenging... but probably not like mapping DNA. If I wanted to find out how other games optimized say... their graphics, I'd break on writes to the system in question's graphics registers.

Find how what's put there. Trace how THAT got there. Trace how THAT got there. Until I found it. Whee, crash course on executable hacking. You have the start with a goal, rather than, "I'm gonna read through this entire game line by line." Even if your goal is eventually making a disassembly, you break it up into smaller parts. First identifying what the RAM is used for, maybe.

tl;dr: Learning to program first is highly recommended. If hacking still seems difficult, keep practicing straight programming. I never learned to hack. One day, my friend asked me to make a small hack and I realized I totally could. I've never read anything on the subject.

A named edit (though I anticipate doing a few more to fix lots of typos: Knowing if something is hardcore optimized is again, just knowing the language. Sometimes you look at code in a game and just say, "Damn. This is REALLY clever."

This "cheat finder" is good for some use cases. But if you're aiming to completely understand a game engine, you can start by putting breakpoints on its input and output (I/O). On the NES and Super NES, I/O is done by writing to memory-mapped ports in $2xxx and $4xxx. This lets you find the code that performs I/O, and then you can discover data structures related to what the I/O does.


Or come at it from the other direction. Look for the part that reads the controller, which should be easy with a write breakpoint on $4016 and (in the Super NES's case) read breakpoints on $4218-$421F. This will show you where the game reads the controllers, and watching it read the controllers will show you the RAM address where the game stashes button states. Then you can put a read breakpoint on that address and see where the game makes decisions based on these button states. You'll eventually end up discovering the code that causes movement and jumping.


Heck, you can find the character's position in RAM (and thus the movement code) by looking at the sprite display lists sent to the PPU. Put a write breakpoint on DMA registers ($4014 on NES, $43xx on Super NES) and find copies to OAM. This will give you the address of the buffer that the game uses for the display list. With a write breakpoint on the display list, you can find the sprite drawing routines. Look at what those read from, and you'll know where the position is. Look for what modifies that, and you have movement code.


Toady artwork from Yoshi's Island

Just keep in mind what Tim Toady says: There is more than one way to do it.

koitsu you are so well spoken, today (hhahaa!)

Now to reply to koitsu monster post... Don't worry I'm not angry at you. (Why would I be anyway?)


To be honest with you, I've never done any programing with anything but assembly. The thought of writing code that you know isn't going to be very optimized kind of disgusts me and I like to know exactly what I am doing.


Yes, mostly because I almost don't see why I have so much difficulty programing and it seems like everyone else doesn't. (I know I really sounded like a looser there.) It would be like If you took Spanish class and you made terrible grades and everyone else made hundreds all the time even if you did your best. Incase you haven't noticed, I'm a bit of a perfectionist. (I'm sure my OCD doesn't help.) What I think is one of my main flaws is that I like to get ahead of myself. I was originally thought about programing for the NES, but I didn't even do anything for it before I decided that I wanted to work with the SNES, which was the first system I ever programmed for. Heck, I just got into programing a little over four months ago. It seems like most of the people on this website are either in college or are college graduates while I just graduated middle school about a year a go. I should probably slow down a bit... The other thing that I think gets my frustrated is how the SNES was made. Don't get me wrong, It's a great system (my favorite, actually) but I feel like some of the design choices were a bit strange. (Not saying I could have done better, of course.) I do always hear people complain about the CPU speed and that leads to one question... Why didn't Nintendo overclock it? I'm no hardware expert, but I always thought you could keep increasing CPU speed until the CPU melted, which the SNES CPU is far from doing as the console doesn't even generate a half a degree of heat. Heck, isn't the SA-1 just a 65c816 running at 10 megahertz? If it is, that just shows it can be done.

Now for the less-personal stuff...


I know what you mean. I just figured that it would still be easier to figure out how game works this way than trying to make a code from looking at the machine code and still having to figure out what it means without having any notes written on the side (If the people write any) or having any of the registers given names that say what they are being used for. (Even if the names are not that clear.)

And now for the random stuff...

I tried the snes demo you made but it didn't work. I looked at vram, cgram, oam, and work ram and they were all blank. I looked at the source code, (not to hard) but from the looks of it, it doesn't look like something I wouldn't be able to make.


Really? people seem to act like it's the holly grail or something with many people calling it the "best shooter ever". I'm not saying it's a bad game by any means, but it's just not my cup of tea. I think you can probably guess what my favorite shooter franchise is. (Hint: by the same company that made my profile picture!)


And then your GBA said, "Psst... you have 4 actually useful backgrounds here".

Lastly, what the heck is this? I'm guessing C?

printf("$%04X", address)

Eh, I don't see what's holding you back. Why not try out my tutorials? They take you step by step.. They'll hold your hand more than I will .. lol

Are you talking out the ones at superfamicom.org? most of the tutorials there only show you how do things like load data to vram and scale a bg in mode 7 but don't even tell you how to do something like make a character jump. I read what was labeled as ASM tutorial and sure enough, that's exactly what it was. It mostly said how to do things like load and store values but never really said how you could use your newly acquired knowledge to make anything with it. (The power-up timers or whatever really were a pretty lousy example. )

why can't YOU use your newly acquired knowledge of the language to apply the general concepts you learned? Can you think for yourself? I'm not being rude.. but seriously... if you're sick of the basics, but if you actually know the basics, what's so hard about thinking about implementing it for yourself!!! You want a character to jump?? Have you already learned to draw a sprite to screen and DMA and do vblank??? you make it sound like you already know it. if thats true, shouldn't it be trivial for you to take it upon yourself to learn some basics applications of gravity on a y coordinate and update periodically for your character to jump?? OK rant over...

but there's a really good tutorial on this stuff in C and SDL that u can take to the ASM field.. they used to be called 'jnrdev'.. taught u about running and jumping (jnr) and collision detection. good luck.

I was about to ask you as to why you seem so angry until I actually noticed that you were the one who made the tutorials. I really am an idiot... The tutorials I were bashing the most weren't the ones you wrote. I'm honestly not making this up (I swear!) when I say that the tutorials you wrote were actually the first one I read and I still look at them occasionally. (everything I have made has been based on the walker source code from the SNES starterkit that I got from your tutorials) Also, I wouldn't know how to do things I said like displaying sprites or using DMA. The one thing I have to say though is that if you are sick of my incompetence, you don't have to help me you know.

I'm not really angry I just want you to think for yourself.
Also shoutz to Neviksti the original author of Walker source code.

Since your still hear, I am just going to ask who or what is Neviksti? I've heard the name several times and I just searched the name on Google and I found a website called neviksti.com and this is what it contained...



By the way, who actually created superfamicom.org? from the sound of the first paragraph, I makes it seems like there is one author. E.g. So why do I, I’ve been collecting, I am truly interested in this, it is my hobby, it will be my own little book, I will be adding important documents, and lastly, feel free to help me.

So random tidbits here about me, since I think you see other people's success (maybe just here on the forum?) as a frustration point for you (i.e. "they can do this so easily, why am I having such difficulty?):

I've had this same feeling myself, though about all sorts of things in life, not just console stuff. I started writing out several examples (ex. my successes and failures with learning foreign languages, esp. Asian languages, how I've never gone to university and didn't finish high school, and the difficulties of being an introvert), but realised I'd just make an even bigger monster post. So here are some random tidbits that might give you inspiration just knowing:

- Despite my history and age (I'll be 38 next month), I started with an Apple II+ (6502) doing machine language and later assembly. My first home computer was an Apple IIGS (65816), which is where I did the bulk of my assembly programming. The first video game console I worked on was the SNES; I did NES stuff 4-5 years later. For what it's worth, I think the SNES is a significantly better console and much easier to program/work on than the NES (especially with regards to graphics -- NES PPU is still the #1 struggle point around here, with audio being #2). I've avoided audio on both platforms because audio is something I just cannot wrap my brain around.

- I never finished high school, and I never went to university/college. Almost everything I know is self-taught. The only PLs I learned in school were Applesoft BASIC and Pascal. Assembly, C, Perl, shell scripting (not really a PL but still), and some super simple JavaScript I've learned on my own. I have to deal with Ruby and it's crap (and let me tell you, it IS crap) as part of my day job, and there isn't a day that goes by that I don't curse because of how ridiculous of a PL it is. Anyway, point is, I am one of the people who does not have a full education.

- Right now (in the world), you're surrounded by people doing programming in high-level languages. Being someone who is interested in assembly makes you the odd man out -- trust me, I know. It doesn't help that a lot of these present-day languages are utter garbage (ex. Ruby, Go, Python, etc.) and have too much going on under the hood and too much "middleware" design (especially the OO ones) that waste cycles. (It upsets me that we have 3GHz+ CPUs -- something I could have never dreamt of -- yet simple programs run like molasses because a lot of programmers today don't understand how their high-level PL code maps to assembly/behaves on the actual CPU). The advantage you have over these people is that you will understand how the processor works. I always bow to other assembly coders, because assembly is essentially KISS principle, and I support that (and live by it, in a lot of ways).

- Yeah, I've noticed you question the hows and whys of the design of the SNES and consoles. My general suggestion is: stop doing that (you aren't the only one whose done this BTW). You can't change how they are. You can still write code on them and make stuff (simple or complex) on them without knowing why, for example, the last 32 bytes of OAM are unused. :-)

- As for 65816 CPU speed and why the CPU ran at what it did: plain and simple: cost. This is where (humbly) it's hard to explain to people who weren't of age or around during the 80s and 90s. The system I learned 65816 on, the Apple IIGS, ran at 2.8MHz with a 1MHz bus speed (which was needed to retain 100% compatibility with the earlier Apple II models). There were cards made several years later which had faster crystals on them, allowing the CPU to run at up to 16MHz (but still with a 1MHz bus). They were expensive -- US$400+ or so. The SNES would have cost a crapload of money if Nintendo had chosen to use, say, a 12MHz crystal instead of 2.68MHz or 3.58MHz (FastROM). The only systems that used that kind of thing that were game-related at the time were arcades, not home systems. So that said, this is my opinion of people who complain about CPU speed on the SNES (or any classic console or system): stop whinging. It's part of history and just how it is, you can't change console (okay sure you could, but you can't guarantee everyone is going to mod their SNES just to meet your needs). The reason things were done that way then were often economically-driven. You can't compare technology of today to things from 20-30 years ago; things today are mindblowingly advanced and fast. My point here is this: it's best to just accept how things are and then sit back and say "hmm, okay, so either I can't do the thing I want, or I have to come up with a way to do it differently, or make sacrifices". That's how we thought back then too.

Random other tidbit: I should note that after I stopped doing NES docs and made them public-domain, I stopped doing NES development (for the most part) altogether. I had spent... god, I don't know... 12 years? 13 years? Focusing on nothing but technical aspects of the consoles, how the games worked, etc.. One day I had an epiphany: I couldn't play a NES or SNES game without my brain starting to think about how it worked and why it worked that way. It completely overwhelmed my ability to enjoy what it was I was playing. I had become so fixated on the technological that it was taking away my enjoyment. This might not apply to everyone, but it was what happened to me.


The reason it probably doesn't work is because the ROM wasn't padded to 512KBytes (4mbits), which is the minimum allowed ROM size for the SNES. The development systems I (and most of us) had back in the early 90s were copiers like the Super Wild Card (usually costing US$450 and up), and we wrote our code on a PC or Amiga, assembled it using a 65816 assembler, then copied the ROM to a floppy, then stuck that in the copier and loaded it. 32KBytes takes a lot less time to copy than 512KB, especially when you know 480KB consists of nothing but filler ($00 or $FF). The copier took care of the padding for you. Yes, some copiers had parallel ports, but the software and LPT methodology was finicky (especially with ECP and EPP), but it still took several seconds to load the data that way (it was faster than using a floppy disk though).

And yeah, the demo is very simple -- it's intended to show people how some basic registers work, and tinker with some "fun" things. It isn't complex, and that's intentional. For example, I've never spent any time with OBJ/OAM on the SNES (or the NES for that matter). I "get" them, but I've never spent the time to actually do anything with them. There's a lot of things on both the SNES and the NES I haven't tinkered with simply because I have trouble understanding some things (a great example is, I STILL do not fully understand/remember the nature of how the NES PPU behaves with $2000/$2005/$2006). It's a matter of what personally interests me (then and now both). For more complex examples, see the source for a lot of the Anthrox SNES demos -- those are crazy (some are so timing-sensitive every CPU cycle matters).


GBA wasn't a system that interested me. It's CPU is intimidating (to me), and while I enjoyed a lot of games on my GBA, but handhelds haven't really ever interested me. The NES and SNES are the two I like most, with a secret love of the PC Engine/TG16. :-)


Yes, it's C, but printf is available in a lot of languages (e.g. PHP, Ruby, etc.). You can read about printf here (ignore the Lisp example). The code in question would output to the screen the literal string/text $XXXX where XXXX is a zero-padded capitalised hexadecimal number (whatever the variable "address" contains). I.e. if address = 0xea then printf("$%04X", address) would output $00EA.

If you want to see some C code I've written (I comment fairly heavily), just today I migrated one of my public open-source projects to github.

Finally, a footnote: I want you to know it makes me EXTREMELY happy to see folks like you, psychopathicteen, tepples, and many others doing stuff on the SNES in this day and age. It really honestly does. It induces a deep sense of nostalgia in me and reminds me of the feelings I first had when doing SNES development. I still remember the night I finally figured out the mode 0 graphics data/format -- after literally 5 or 6 hours of trial and error I finally got it. I was at a friend's house, and it was something like 0300 in the morning. I leapt out of my chair and started yelling "IT WORKS!!! IT FUCKING WORKS!" and was so proud of myself. My friend woke up and looked at the text I had on the screen (white text on a black background) and said "...now make it multiple colours" and went back to bed (and within about an hour I did, then combined that with smooth background scrolling).

I feel the same way about NES development too, it makes me so happy to see so many people doing games on the console, and I try very hard to contribute a couple hundred USD to every single Kickstarter project there is relating to the NES. I'm still tremendously excited about LizardNES.

So if I can give my opinion, assembly programming is hard, make a video game that is hard if you start with these two diffculties it can not be that you are disgusted with programming and making games.

My job programmer games on Android / IOS, I have already done a lot of games and I know a lot of technique / algorithm of video games.
And I would find it difficult to start on the SNES, what to acquire the first is the algorithm, the rest can be learned easily.
To make a game just know 3 things handled, sprites / background, the joypad and sound, the rest is algo and personal experience.

If you're referring to "Blast Processing" and "Genesis does what Nintendon't", consider that the 68000 can access memory only on one of every four CPU cycles. This makes a 7.67 MHz CPU in practice closer to 1.92 MHz memory-wise. The 65816 in the Super NES can access memory on every cycle, but there are fewer of them (3.58 MHz) and the data bus is narrower (8-bit instead of 16-bit), so it's kind of a wash. See gencycle and nearby posts.

Tip: Don't call the S-CPU "slow" around psycopathicteen unless you're interested in a sermon as to why this is not the case.


I can't say with certainty why Nintendo didn't do something, but I can say why a reasonable company wouldn't under similar circumstances. And I see three reasons not to overclock the NES CPU.

1. First, 1.8 MHz was already faster than the 1.0 MHz of the Apple II and Commodore 64 and the 1.2 MHz of the Atari 2600. And it was competitive with the 3.6 MHz Z80 in the ColecoVision and SG-1000, as a Z80 typically gets as much work in 4 cycles as a 6502 gets in two.
2. Cost, as koitsu mentioned. A product with a faster specified frequency tends to be more expensive. Video game consoles introduced at 599 US Dollars tend not to sell well, especially when the video game industry is pulling out of the 1983-1984 recession. Look at the first year of the 3DO and PlayStation 3.
3. Nintendo was trying to build a reputation for building video game hardware that is Tonka Tough, a reputation that would last throughout its cartridge years. (N64 Control Stick and DS shoulder buttons are exceptions.) Actual overclocking, or running a part at a frequency over its spec, would cause unreliability that threatens this reputation.

All of these apply just as much to the Super NES CPU.


CPUs start giving wrong results before they start melting. Even if a particular clock speed works in the lab, it might not work in people's homes where the air is dirtier and the ambient temperature varies more. It's better to stick with the spec provided by Western Design Center (the designer of the 65816 core in the S-CPU) and Ricoh (the S-CPU manufacturer).


The SA-1 came out later, once it had become cheaper to make a fast 65816. Notice how no SA-1 games were released in 1990 when the Super Famicom shipped.


Hardware tutorials are for hardware-specific issues, and jumping is not one of them. You need Euler integration and fixed-point arithmetic for that: add gravity and other accelerations to velocity each frame and then add velocity to position each frame. And they don't put jumping in every tutorial because not all games need jumping.

I personally think that hardware wise, the Genesis is overrated. It boggles my mind as to how people think that a console released in 1988 would be better than a console released in 1990 for the exact same launch price. I mean, a 6 megahertz CPU isn't exactly "screaming fast" (compare it to most arcade machines that ran at about 12 megahertz and usually had a z80 or something thrown in). What everyone fails to mention is that the SNES has two large PPUs that are about as powerful as the main CPU so while the SNES's main CPU may be a little behind the Genesis's (the Genesis's CPU is definitely not "almost twice as fast" as I heard that the 68000 isn't the most efficient.) Sega fanboys always fail to mention that in order to "truly" know the SNES's power (don't quote me on this) you would need to multiply 3.5x3 and that would get you 10.5 vs. 6.

I know I'm going to sound crazy for this but If I were to pick a main problem with the SNES, It wouldn't be the main CPU speed, but rather the two PPU's speed. I almost don't see why people complain so much about the CPU speed when you can 1. Optimize your code as much as possible. And If you still have slowdown than proceed to step 2. Add an expansion chip. You can always add more processing power for moving everything around, but It's not like you can add more BG layers or increase sprite overdraw. (After all, It's a video game console, not a calculator. ) Basically, what I am saying is that you can add on to the CPU, but not the PPU's. Just thinking, how can the SNES do transparency? If you were to average two colors across the screen, wouldn't you have to load a value from the main screen, add a value from the subscreen to it, do a bit shift operation on it two divide it by two and then store the result somewhere 57,344 (256x224) times? While cool, I imagine that if they would have cut out the transparency effects, there would have been more room for other things. (Like 3 4bpp bg layers.)


Ha! I wonder, do you two know each other well?


I honestly thought you were referring to the Neo Geo (Didn't that actually go for $700 though?)
Speaking of money, watch this. (I'm sure you've already seen it.) https://www.youtube.com/watch?v=MTzyz2TgGls (This video is easily some of the stupidest sh*t I've ever seen.) Also, B E S T F Z E R O P L A Y E R E V E R ! And look at 1:29. No duh... Lastly, 1:39. Blind People?



Why I gave jumping as an example is beyond me. (It's something so simple that even I figured it out by myself. )

About increasing the CPU speed, At the time I wrote about making it faster, I was not aware of this "crystal" thing. I don't know why, but I always just assumed that you could just feed a CPU more power and it would run faster. (which really wouldn't cost any money.)


Personally, I think I would have liked the GBA more if it were a home console, but at the day and age it was released, It never would have been. Also about the CPU, I don't possibly know how you wouldn't think it's fast. (That is, If you weren't born yesterday and have never heard CPU speed measured in anything but Gigahertz before.) Although It was made ten years after, the GBA makes just about all the arcade machines from back in the day look like scared puppies. The one problem I see with the GBA though is that although they made the processor blazing fast, they really didn't really do way too much with vram.

Also, how many high level programing languages are there? 3,000? About 3Ghz CPU's and programs running very slow, although there really isn't any need for it and it would take just about an eternity to make, I'd love to see how fast computers would run if everything were still written in ASM.

About leaning mode 0 at your friend's house at three hundred in the morning, how old were you? I assume there weren't any tutorials online? (Or online, for that mater.) Since you've kind of given me a background history of yourself, I am going to ask when and why did you drop out of highschool? What is your current Job? You don't have to tell me anything if you don't want to.

Super FX adds sprite overdraw. Look at the title screen of Yoshi's Island. Each of those buildings revolving around the center of the island is a quadrilateral drawn by the Super FX coprocessor, and those are sent to the PPU.


You appear not to played Donkey Kong Jr. Math or my FizzBuzz prototype.


Shifting and adding happens to be a very fast operation in hardware, about as fast as deciding which pixel to display out of BG0, BG1, BG2, and whatever the sprite line buffer is currently showing.


That would have needed much faster video memory. For every 8 pixels, the PPU makes eight memory fetches. In mode 1, these are BG0 nametable, BG0 planes 0-1, BG0 planes 2-3, BG1 nametable, BG1 planes 0-1, BG1 planes 2-3, BG2 nametable, and BG2 planes 0-1. At 5.37 MHz, this works with 150 ns SRAM. (Sprite pattern reads happen at the end of the scanline, as on the NES.) Reading VRAM twice per dot would have needed much more expensive 70 ns SRAM.


As I understand it, SNK originally intended to sell the Neo Geo AES to Blockbuster and other rental stores, and sale was opened to the public later.


Buy a GameCube and a Game Boy Player.


That's because you can reload most of VRAM every vblank and still have time to spare. You only need enough VRAM for those animation cels being displayed.


Go try MenuetOS.

That effect is still limited by DMA though. The buildings fit within a 128x128 square, and each of them has the same color palette. It would've been nicer if the PPU's had their own cartridge bus.

It was a 6x increase from the GBC (12x from the DMG). Coming from one generation to the next, a developer would have been absolutely spoiled Add that to the improved DMA handling and CPU speed and you start feeling like you could do anything (at least I do when I'm working on stuff). I'm sure someone's mind was blown with the increased sprite capacity alone.

What you are calling added sprite overdraw is really just a buffer they set up. The sprites aren't moving, the tilemap is just changing. (If you notice, all the hills and buildings are using the same color palette.)

Frame 1: (lower half of vram)



Frame 2: (lower half of vram)



Edit: Dang it psychopathicteen! You beat me again while I was writing.


You're right. I still never understood as to why it costed as much as it did, considering it doesn't even look 1.5x as powerfull as the SNES, let alone 3.5x... (It's probably the crazy large ram capacity)



Oh come on. You knew what I meant. If you use the Gameboy player, you still can't do split screen with a friend. Also, the GBA's low resolution really stands out on a large TV. (I'm sure they would have increased it if it were a home console.)

Also, do you think you could go over the whole BG thing again? I kind of got lost while reading it... I always kind of wondered why say in mode 0 if you add up the "bits per pixelage" between all the layers, you would get 8bpp and in mode 1, you would get 10bpp and in mode 3, you would get 12bpp. I'm sure there is more than to just dividing bpp among layers. Based on this, It seems like you could say that with every new BG layer, you loose 2bpp. If I were to make a game, I would probably make it in mode 3, as I always felt that you get the most bang for your buck. (Of course, vram starts to be an issue then, so you really can't win. )

yes maybe u understand the basic grasp now of how to implement jumping, but you should NAIL IT DOWN with a demo. The fixed point math reference tepples made is extremely important on these systems without floating support. It's a useful way to use the bytes/words as a cheap decimal fractional notation. Very important to learn I think.. Depending how good you are with the SNES u might want to postpone this and learn more satisfying things first, that's up to you. Plus if you make a demo that interacts with the player by jumping you will have gained real experience in making your ideas come to life..

I actually did make a working demo of a character jumping, (using the walker code) but it wasn't very useful because I basically just did bcc on the sprite y variable so that if it went far enough down the screen, it would "pop" it above the line. I don't remember exactly how I did it (I'm sure I could rewrite it, but I kind of want to make a horizontal shooter) but I remember using a register that I would check to see if the character was in "ground mode" (checking if you are going to press the jump button) or "air mode" (decreasing the y velocity which was a register every frame so that it would eventually become negative and would make the character fall. It also checked if you were below the line I made.)

I certainly disagree. You can only optimize your code so much, and you may still run out of time to process each game frame in time. You say "add an expansion chip" like this is something anyone can do or do so simply. That's certainly not the case. It adds complexity to your design and definitely cost. If you look at the SNES library, a very small percentage of games used expansion chips. You mention not being able to do anything with the PPU running out of BG layers or dropping sprites. The average game player probably can't name any game where this seemed like a big problem. I do recall some games where you can see sprite drop but it is not a problem or distracting like it was on NES with the flicker to compensate. And not enough BG layers, I'm not sure what any example of that would be.

An healthy improvement would have been if the SNES could have accessed all RAM and ROM at "Fast" speed. But it would have increased the cost of the DRAM in the console and the ROM in every cartridge. Or maybe just changing RAM access to "Fast" and leaving it up to each game whether or not to have 'FastROM' would have been another improvement. If we move on from the CPU, I'm sure we could complain about the SPC before the PPU. Maybe the SPC could have used additional memory or some kind of faster transfer mechanism.

But like koitsu said, it's history now. There's no changing it and we can debate it all day but still it changes nothing.

Yeah, but you can still optimize your code to run 10x faster than what you usually saw in SNES games, before optimization becomes difficult.

Exactly. The Super FX is compositing the extra sprites to a buffer, and from the viewer's point of view, the buffer creates the illusion of more sprite overdraw. It's like PC games and Lynx games, which draw all sprites to a frame buffer and then display that.


A modern PC is orders of magnitude more powerful than a GBA, with support for displays that substantially exceed 1080p. Yet PC games likewise tend not to offer split screen.


GBA: 240x160.
Super NES, zoomed in to fit the entire width of an HDTV: 256x168, with 28 lines hidden off the top and bottom.


Each 8x1 pixel sliver (or 16x1 if half-width pixels are enabled) of the background is based on 16 bytes of data.

• Mode 0: 8 bytes nametable, 8 bytes tiles
• Mode 1: 6 bytes nametable, 10 bytes tiles
• Mode 2: 4 bytes nametable, 8 bytes tiles, 4 bytes offset
• Mode 3: 4 bytes nametable, 12 bytes tiles
• Mode 4: 4 bytes nametable, 10 bytes tiles, 2 bytes offset
• Mode 5: 4 bytes nametable, 12 bytes tiles (half-width pixels)
• Mode 6: 2 bytes nametable, 8 bytes tiles (half-width pixels) , 4 bytes offset
• Mode 7: 8 bytes nametable, 8 bytes tiles

EDIT: Incorporates typo corrections by psycopathicteen


Correct. You lose 2 bits to nametable fetches.

Mode 2 is 4 bytes name, 8 bytes tile, 4 bytes offset
Mode 3 is 4 bytes name, 12 bytes tile

Neviksti is legendary. I only know so much about him/her (I think he's a guy). here are some things I remember:
. Created the Star Ocean uncompressed Gfx hack (I think it was him, others could have been involved I dunno much about it)
. Created pcx2snes graphics conversion tool
. investigated using the XBand for internet communications on SNES
. I think he managed to alter the Tototek Superflash CPLD to support multiple save-games.
. Created the popular snes-starterkit package, including its useful source library routines.

He's probably done a lot more cool things on SNES and other consoles. He seems to pop up being involved on just about anything!! I remember he had valuable input on the development of the WLA-DX assembler(s).

Alright, Here's a quick demo I made just recently. (The physics are so terrible that I would never put them in an actual game though.)




Sadly, I don't doubt it. I think that we all know what the rea$on is. (Getting the game out faster.)

Also, I never said that it was easy (although admitting it did sound like I said it was) to add an expansion chip. I just that at least you can upgrade the CPU.

The average game player can't see this?



And about asking for more backgrounds, you could always ask for more. For example, Say if in a game, you had a foreground, background, and a large boss character. One of them would have to use a 2bpp layer. A lot of people who designed games for the SNES really didn't even use BG layer 3, I guess because they felt that it was useless. I've literally seen games that use BG layer 3 for creating a status bar that consists of about 12 8x8 tiles. If there were games for the SNES that properly utilized BG layer 3, they would have to be the Donkey Kong Country Games.

About the SPC needing to be upgraded more that the PPU's, I wouldn't know, as I've never even touched the SNES's sound system.

I guess there's no sense in complaining, though, as the past is the past...

I honestly think that the programmers just didn't know how to optimize their code. If you know how to write efficient code, why not write efficient code to begin with. You can argue that efficient code takes longer to write, but I just haven't seen an example of this happening. Every example of code optimization I've seen was always about taking bloated code, and reducing it. I never seen anybody make a routine faster by making it longer and more complicated.

Taking a bunch of branches out of the inner loop often makes the routine longer but faster. Or compare early versions of my VWF tile drawing routine, which looped to shift the tile, to the one that Blargg wrote, which uses a branch tree.

Well, the examples of optimization you have seen are quite limited, then, perhaps mostly limited to replacing badly written code with the same algorithm but done with more skill or care? This is the kind of optimization a C compiler can be pretty good at, but optimization isn't just about trimming fat, it's about understanding both the process and the goal and making it faster. You know more about the goal than a compiler does, and you can make much higher level decisions than it can.

There are lots of opportunities for optimization that add complexity to an algorithm. Tepples already hit upon a simple example. Unrolling loops is a trivial example that adds more code but can increase speed. (Again, this is simple enough for a compiler to do in many cases.)

It's hard to come up with easy examples of complexity-increasing optimizations, but that's because the good examples of it are complicated solutions to complicated problems. There are cases where there are generic problems like sorting a list where you can choose between a simple implementation like insertion sort, or a more complex but faster heap sort, etc, but most real world examples are very specific. Even the choice of algorithm I just mentioned is not generic; there are even situations where the insertion sort would be a faster choice.


Here's an example. I took a challenge to write sudoku solvers with some friends of mine, to see who could write the fastest one.

1. I start with the simplest solution. Systematically try the numbers 1-9 in each empty space, check for validity, and recursively continue until the board is filled. (~50 lines of code, ~450 seconds)

2. Do a bunch of simple optimizations to solution 1 that the compiler was unable to do (aggressively unroll loops, rearrange data structures, etc.). (~250 lines of code, ~250 seconds)

3. Maintain a sorted list of spaces to check by how many solutions remain in each, check the one with the least number of solutions first. (~500 lines of code, ~16 seconds)

In this case I drastically increased performance by increasing the complexity of my code. I could have tried to do more reductive optimizations on #1 but I doubt I could have squeezed much more performance out of it. I needed to add more information about the problem/goal into the algorithm, and this required more code.


In my professional life, I usually want to see someone write the simplest and most maintainable version of an algorithm first, after which optimizations become a necessary distortion of that clear version in the name of speed, only to be done when that speed is needed. In my experience most optimization attempts at the professional level reduce readability and increase complexity (and of course, take longer to write). There are many cases where someone sees a better algorithm to use that is both faster and smaller and easier to maintain, but these are very rare gems, and finding them is a joyous occasion.


There is, of course, occasionally someone just writes bad code because they're incompetent or tired or for whatever reason, but this isn't the norm, because if this is your consistent level of operation you'll probably be fired. Fixing bad code is not what I think of when I think "optimization", this is more like... "taking out the garbage".

You say "occasionally"; I say "daily".

I still can't wrap my head around SNES games that lag with 4 or 5 characters onscreen. Collision takes like 30 or 40 cycles, and you have 45000-60000 cycles per frame. I did manage to find bad oam handling techniques through disassembling some games, but I am pretty sure it's not even the worst example of inefficient code in said games.

Although I'm not adding anything to the subject, have you ever seen Super R-Type? It's quite possibly the most inefficiently programed game I've ever seen. So much so that when the game actually goes to normal speed, (when there are absolutely no enemies on screen and you are not pressing the fire button) It actually gives off the illusion that the game just miraculously sped up. Also, to top off what a technical disaster it is, the game uses 8x8 and 16x16 sprites. (it seemed like most early SNES games started off this way and then moved to 16x16 and 32x32 sprites, with the notable exception being the Donkey Kong Country games. Although this sounds ridiculous, were people not aware of $2021?) The reason why this would be a problem is that most of the sprites in the game aren't even 8x8 (heck, the r-type 2 arcade board, the Irem m72, didn't even support sprites smaller than 16x16...) and many things are 32x32 meaning that they have to be made of 4 sprites. Because of this, there are many points in the game where it literally runs out of sprites, and things start to miraculously disappear.

I've not played Super R-Type. Perhaps it's just an example of a developer's first SNES title. Or one of the first for them.

Capcom's early title Final Fight is known to suffer slowdown and have sub-par sound quality. And Konami's Gradius III ofcourse is known for intense slow down. What you said though about running out of sprites is certainly interesting. With 128 sprites you have quite a situation when you still run out of them.

IMO it's a pretty good game despite the slowdown. But R-Type III was a later effort and is much better. It seems Irem more or less got the hang of the system in the meantime.

When they made Final Fight I think they didn't trust the CPU at all, in fact if I recall correctly every graphic is uncompressed (yep, this is why Guy and a whole level are missing, they wasted all the space they had). I guess they probably didn't think the CPU would be fast enough to decompress graphics without a loading screen.

I assume you meant $2101

Is that both sprite-to-sprite and sprite-to-background collision? Besides, it's not just collision; it's also each object deciding where to move in the next frame. How long does it take a unit to A* its way to its destination?


Interesting. About how long does it take you to find blatant inefficiency in a randomly chosen game? I'd be willing to help you with a "SNES WTF" blog.


How much overdraw did the m72 support? On the Super NES, you get only 34 slivers of 8x1 pixels each on each line, and putting an 8x8 bullet in a 16x16 sprite cel costs you an extra sliver across its entire height plus two slivers on the additional height.


Super Mario All-Stars also uses uncompressed tiles, apparently because it needs to stream a bunch in during vblank to simulate MMC3 bank switching.


War was beginning.

It wasn't starved for ROM space though =P

But yeah good question, do all the graphics for a level (well, a section) fit in VRAM?

SMB2 and SMB3 use animated tiles (moving grass, spinning ? blocks, etc.). Even if they did all fit in VRAM, the game would need to rewrite the nametable to animate them, and that's probably more complex code-wise than just uploading new CHR.

Finding oam manipulating code is easy, but I don't know how to find physics and AI. Is there anything better than BSNES debugger? I have the feeling that I'm not using the right kind of program.

As I wrote in this post: Find the RAM that the OAM manipulating code reads when determining positions of sprites. Then find what writes to that RAM, and you should end up in physics. This requires a debugger that can break on RAM reads.

Super Ghouls and Ghosts makes that difficult, because it has an intermediate sprite table between the game logic and OAM buffer, that keeps changing address in RAM.

If a game is trying to use runtime ASLR techniques to stop Game Genie/Action Replay from working, similar to those adopted by later Pokémon games, then perhaps you can try proceeding forward from player input.

Like I said, this could have easily been avoided if they had used the 16x16 and 32x32 combination. There is a part in level 3 of that game where there are these flying enemies that use 4 16x16's and when you shoot them, they leave 3 4 16x16 explosions behind them, and this lasts until they hit the ground. With 8 of these enemies on screen (It does happen) you effectively run out of any room for anything else (including you're ship, which is always onscreen) If the game had used 32x32 sprites, everything would have taken the exact same size and you would have only used 32 sprites instead of the full 128. Like what 93143 said, when Irem made R-type 3, they saw the error of their ways and used 16x16 and 32x32 sprites among other things.

About the missing level in Final Fight, I thought I might chime in and say that there is a very overwritten version of it still in the game. (There's a Youtube video of it online.)


Opps... Yeah, you're right. I tried to remember what it was without looking it up. (Which obviously didn't go too well. )


I don't know. There really isn't much documentation on the Irem m72. (Nothing really outside of these websites: http://www.system16.com/hardware.php?id=738 and http://patpend.net/technical/arcade/m72.html)

What I do know, though, is that the system runs at the resolution of 384x256. Pretty Big! Interestingly, when it's successor came out, the Irem m92, the resolution was actually reduced to 320x240 (perfect 4:3 aspect ratio!) Based on the resolution and this: (I couldn't get the picture to be 384x256. )


I would say that the overdraw is just barely 384 pixels long. (The game doesn't try anything more daring then that.)


What?

About the BSNES Debugger, there is certainly room for improvement. A lot of features that are missing are found in other emulators for different consoles like visual boy advance. The two things that (In my opinion) need the most improvement are: the vram viewer, (you can't even look at it using different palettes) and the oam viewer. It would be really nice if they showed you the graphics the sprites are using and if they told you the 9th x bit and fixed the character selection for each sprite (When the 9th character selection bit is enabled, it still says it is using tile 256 instead of 512.) I'm sure the memory editor probably needs help, but I haven't even figured out how to change any values using it. I click the numbers, but it doesn't let me edit them. I see that there is a box on the side that lets you type stuff into it, but nothing happens if you type in 1-F, but if you type in nonsense like T, the program crashes.

Either I'm insane, or I just saw a post that said "Someone almost set up us the bomb." What is "the bomb" anyway? And I'm pretty sure it was supposed to be "Someone almost set us up the bomb."

"What is "the bomb" anyway?"

Apparently you didn't get signal a decade ago. First read Wikipedia's article about "the bomb", then watch these videos:
Zero Wing intro
Invasion of the Gabber Robots, a remix of the Zero Wing intro (also as video)
Mmm WHAT YOU SAY !!

Final Fight and U.N. Squadron were their first titles. Maybe they didn't yet have time to develop tools for the SNES for compressing graphics. Why do you assume they thought it would "require a loading screen"? It seems more likely to me that they didn't have the tools already available since they were the first titles and they did not have the time/money/experience to develop them for the first titles. And then when the Final Fight Guy special edition was released they were not going to invest the time into doing what they should have, put all 3 characters and the missing level back in.

I don't think it had anything to do with trusting the cpu or not. Just the usual time is money combined with no pre-existing company tools and routines for dealing with compressing graphics.

I've been trying to reverse engineer R-Type today, and it looks like the slowdown might be easy to fix. Almost half a frame is spent doing what appears to be a metasprite drawing routine, and it just barely misses the end of the frame.

I hope you try to fix it and succeed. It would be quite an interesting patch to actually optimize a game to reduce or eliminate slowdown. I wished someone could do that for Mega Man The Wily Wars on the Genesis as it suffers some pathetic slow down in many places.

Strange how a number of SNES games suffer from this... I wonder if they all used some sort of badly unoptimized library.


Is it possible that they blindly/automatically translated the 6502 code into 68000 ASM instead of properly reimplementing the logic?

This would have been in 1993, so that would have made 16 at the time (I was born in 1977). I skipped 2nd grade so I was a year younger than everyone else in school.

At the time there were no tutorials of any kind. The Internet (as we know it today) did not exist then. I was online at that point, and working at Oregon State University, but websites and HTTP were just barely being introduced and were very bare-bones. The web became more commonplace in the mid-to-late 90s (I still remember the first time I saw a URL shown during a TV ad -- it was from Sony).

SNES development during that era consisted mainly of discussions on Usenet (NNTP-based), a.k.a. "newsgroups", or what today is known as "Google Groups", and on private mailing lists. There was a snesdev mailing list maintained by Charles Doty (I think?) back then, and many of us contributed. Here's some proof I put on Twitter last year (be sure to look closely at the Date: header in the pictures).

There was only one document at the time (ca. 1992) on how the SNES worked, what its registers were, and how they behaved. It was a document written by Dax & Corsair (two Amiga guys). There were typos galore, with lots of bits defined wrong, and was really quite awful by today's standards (if you Google something like "corsair dax snes" you'll find some of the docs, but not all of them). That and my own hacking is what prompted me to write my SNES documentation, which is what a lot of people used for probably the next 10 years or so (people tell me they STILL use it though, just because of how I write/phrase things, with my intention being ease-of-understanding). People have found lots of mistakes in my stuff as well, and now a lot of people (most?) have access to the official developers docs anyway. The reason I got into SNES hacking was because the SNES used the same CPU as my Apple IIGS -- the day I found that out I became completely enthralled with trying to write code on the SNES. Games like Actraiser blew my mind (we had nothing like this on the IIGS).

School is somewhat of a weird subject for me (I absolutely HATE school even to this day. But strongly advocate people stay in school). I did "okay" in grammar school and junior high/middle school, getting usually Bs. I was never an A-grade student. When high school came around, especially my junior year, I really stopped caring about a lot of the subjects I was required to take. The subjects just didn't interest me. You could see it on my report cards: Ds in English, mathematics, social studies, maybe a C in sociology, while getting B+s in subjects like computer science and Chinese (both subjects I enjoyed). I failed biology twice (it was a semester course, and I failed both times -- it didn't help that they changed teachers after the first semester), and I failed "college-level" trigonometry as well as calculus.

By the time I was a senior, I was skipping pretty much all my classes except the ones that interested me (only 2 or 3 at that point). My lack of attendance eventually got me into trouble, where after 3 months (don't ask me why it took them so long to find me -- I was at school the entire time, I never left campus) the in-school suspension fellow was given a photograph of me and went looking for me + found me, and I had in-school suspension for (I think?) 3 days. You aren't allowed to leave barring restroom usage, and you have to use the time to do school work (and any new school work they go and fetch for you). Friends of mine kept coming to the in-school door and sliding notes under it that read things like "FREE YOSHI" and all this stuff, which embarassed the hell out of me and made the in-school guy go "WTF?"

The in-school programme gives you this "questionnaire" where you're asked a bunch of self-reflective questions about why you're in in-school, what you could do better, etc.. During those 3 days I wrote a 10-page (double-sided) response to that questionnaire, and at the end of the 3 days dropped the tome on the guys' desk, left, and went right back to doing what I had been (skipping most of my classes + going to the ones I found interesting). About 2 weeks later, the same guy came to the CS lab -- with the vice principal in tow -- and they asked if I'd come to the VPs office for a chat. I figured I was going to be expelled (my mother would have killed me). Instead, the in-school guy slides my 10-page work across the table to me and says "This is the most eloquent, well-thought-out, wonderfully introspective thing I have ever read from someone during all my years doing in-school suspension. The VP thought so too. We don't understand why someone of your calibre would skip class." I explained why, and they seemed to understand, but I don't think they *truly* understood. My opinion was that the in-school guy had probably, in all his years, just gotten people writing "SUCK A DICK" or "I FUCKED YOUR MOM" over and over rather than actually getting something coherent and intelligent. After the 30-minute chat, the let me leave, and I went back to what I was already doing. I saw both of them throughout the rest of the year (in the hall, usually when I was skipping class) and neither said or did anything.

At the same time I was going to school, I was working (voluntarily) at Oregon State University as a UNIX systems administrator (for about 4 years), which is eventually what lead to my career (although these days I do a lot more than just that, as I have a pretty strong background in networking as well; here's my CV/resume). That was where I got my feet wet. And during my senior year, I also lived with a Chinese family (locally) for 6 months where I wasn't permitted to speak English. Also, my high school computer science department used Novell Netware 3.1; and one year (I think my senior year?) Novell offered free CNE training (and certification, assuming we passed) to those of us in the lab who were interested (at the time I was writing DOS applications in a mix of Pascal and x86 assembly to do certain Netware transactions over IPX), so 4 of us did that and we all passed. (I have no idea where my certificate is now -- I really couldn't care less, and you couldn't pay me a billion dollars to work on Novell now, haha)

So -- when graduation came around, I had excess credits in electives (computer science, photography/art, Chinese, you name it), and had barely managed to get all of my pre-requisite course credits (I think they gave me the credit for biology, barely, because I took it twice). The only problem was: I wasn't going to be allowed to graduate. You see, my junior year, the 509J school district introduced two mandatory courses into the curriculum: "Living On Your Own" and "Personal Finance". I went to both of these classes maybe 4 or 5 times at most, and they were year-long. I thought they were absolutely ridiculous -- I was already living on my own (i.e. I wasn't living with my parents during those 6 months), and I knew how to balance my chequebook (my mother ran an engraving company and was the company's bookkeeper). In Oregon at the time you could "challenge" a course -- they'd give you the final test and if you passed it you didn't have to take the class. However, 509J deemed both of these classes MANDATORY, so you couldn't challenge them. My mother and I both contested the matter with the school district and we lost. Thus, I said fuck it, and didn't attend them.

So when my senior year ended, my school informed me that because I was 2 credits short, I would be allowed to go through the graduation ceremony (and go to prom), but what they'd hand me up at the podium would be an empty piece of paper. To me that's pointless effort, and I never cared about prom or graduation, so I did neither of them. When the next school year started (which would be my second senior year per se), I went back to high school for about 4 months before dropping out entirely (and was spending most of my time at OSU working). PSU (Portland State University) was also doing a take-university-courses-by-mail thing at the time (this would have been mid-1995), so I tried doing that for a few months but I was horrible at it -- the books and curriculum had no context, so it was just like throwing random pieces of test paperwork at me without any background. I quit.

After that, still in 1995 (I can tell because the stuff I uploaded to Twitter has my Email being @mediacity.com), I ended up moving to California to live with my girlfriend, and worked at an ISP (MediaCity) doing technical support -- until the systems administrator got wind of the fact that I had 4 years of UNIX experience and so I became a kind of combination tech support + junior UNIX SA. Since then all I've done is industry work, with a brief stint in 1997 where I worked for my mother's engraving company doing vinyl application + graphic design + sign installation.

You couldn't pay me to go back to school. I absolutely hate it. But as I said, I tell kids to stay in school -- my lack of education has never hindered me (every job I've applied for, except one, I've gotten), but the early-to-mid-90s were a very unique time to be alive when it came to computing and the introduction of the Internet, so I just got lucky in that regard.

About the only thing today I'd want educationally would be to take some mathematics courses, specifically to refresh my memory of algebra. For example, until sometime in 2011, I had completely forgotten how to do long-hand division (computers spoil us, and I don't think that's a positive thing).

P.S. -- There's a hilarious twist to my lack of graduation: my sister (younger by 7 or 8 years) went to the same high school I did, and during (I think?) her freshman year, the 509J district made both of the aforementioned mandatory courses optional. I've always wanted to go back there and be like "I see you changed your mind... so can I have my diploma now? 21 years later?" ;-)

I still remember how to do long division, but only in binary, and only because of NESdev. See getSlope1 in the source code of Thwaite and RHDE.

That's what I've thought for a long time, but SGnG's sprite drawing routines are different from R-Type. Maybe I'll look through some more games, and see if any use the same code library.

And while you're at it, see why Ikari Warriors and other arcade ports by Micronics are so damn slow.

I'm just curious, psychopathicteen, but how are you finding all this stuff? Do you just look at ram like previously suggested? And what are people calling "long division?" just something like 3681/86529? Also, It seemed like sprite drawing seemed to be a very common problem with a lot of SNES games. Is it really that hard to write to hioam? I always thought that you would have a word that would be used for the X position for metasprites. In your metasprite creating routine, I imagine you would just see if the 9th bit of the X position word was filled with 1, and if so, just write 1 to hioam. I don't know specifically how you write it, but it really doesn't seem like it should take that much CPU time.

While we are talking about Super R-Type, I will say that, while mainly fixed, R-Type III actually does have some slowdown, but only really on the mode 7 parts in the first stage. Because it really isn't hard to do mode 7, (just write to 2 different registers for rotating and scalling) I'm guessing it slows down because of some sort of fancy collision detection going on while it's rotating.

Also, about Micronics, they seem very bad at programming. (An NES game running at 12 frames per second? What are they doing, realtime 3D?)

koitsu, I read what you wrote, and I am not lying when I say I found it genuinely interesting. I love how when you were in in school suspention, they didn't let you use the restroom. (What did they expect you to do, take a dump all over the floor?) Why did you have to stay with a Chinese family for 6 months? And the last question. How did you get to be on this website? Did you create it? Did you know all the other moderators before this website was created?

The procedure described in this article. Or as Capt. James T. Kirk might put it: KHAAAN!


Bit packing is sort of tedious. And unless you use the technique I call "soft OBC1", you have to maintain two different index registers: one for normal OAM and one for high OAM. This means you don't have one left for the metasprite table.


Walk animations in my own games Thwaite and RHDE run as slow as 5 frames per second, but I'm under the impression that the player doesn't really notice because the characters are so small. Besides, games for 8-bit home computers such as Rocky's Boots and Knight Lore and The Trap Door were running at 12 fps or slower, though a lot of this was because of software 2D compositing.


"You aren't allowed to leave except for restroom usage".


NESdev.com was created by Memblers and originally hosted on Parodius Networking, a hosting service for retro-gaming sites operated by koitsu. Parodius closed in mid-2012.

Oh, I was talking about Final Fight when I made that question （　・・） (but what you describe doesn't sound like every tile in those games...)

Ops... (Some of the Nazis at my school don't let you go to the bathroom without having points off your next test.)


What is bit packing? Is it just operations like AND? If so, what's bad about it? Also, what is the "soft OBC1" technique?


That's just walk animation though, right? I imagine the games still run at 60fps?

Y'all seem to really know what it takes to create an optimized SNES game.. (not sarcastic) Have you thought of collecting this knowledge into a basin / wiki to organize it. It can include guide lines and tips, no? It would beat the bits and pieces of gold being randomly scattered across these forum posts.

For instance, what is this Soft-OBC1 routine .. Maybe we can start a thing on http://wiki.superfamicom.org

OK, I'll take some liberty in my own hands right now.. and add a SNES Optimizations page..

I've added an Optimizations section at the end of http://wiki.superfamicom.org
Someone please populate the "Soft OBC-1" cause I have no idea what the frick yer talking about.
O! and if you have any other 1337 optimization knowledge stuffz, feel free to add your goods.
I'm talking about bit-stuffing, byte squeezing, frame-saving- miniscule-sized smallest-cycle efficient greatness theheheh

Or even advices page feel free to share your wisdom how to efficiently perform a certain crucial function of your game. I think a lot of people would love to hear about it.

It's not just the hioam routine that is slow, it's the normal oam routine that is slow too. R-Type has this nonsensical code:



Why didn't they just do this:



Even then you can ask, after adding the metasprite displacement, camera adjustments and bounds checking, why did they store it back to a register just to pick it back up again, and move it to shadow oam?

The answer to this is usually because it worked well enough and they were under time and budget constraints to finish the game. In any shipped game there are a million little things that could have gone better. You simply can't make a game without making some mistakes or poor decisions along the way. There was probably a huge game-breaking bug that was more important to solve than saving a few cycles in a sprite routine that is already at least doing its job. Stuff like this persists in the shipping game because it never became a priority to fix.

I should have put "barring restroom usage" in parenthesis or used a comma. Barring means to exclude, i.e. "we weren't allowed to leave the room, except for bathroom breaks". There are places, however, that don't allow people to use the restroom outside of specifically assigned windows/breaks (they're almost all in industry, not academia), and I find that whole concept offensive and just downright inhumane. My opinion is amplified by the fact that I have moderate-to-severe mixed-type IBS, so having access to a toilet is something I classify as a necessity, not a nicety.

I didn't "have" to stay with a Chinese family -- it was something I opted (chose) to do. It was an immersion experience, basically. My Mandarin had gotten to the point where I was quite fluent but wanted further practise, and I felt a good way to do that would be to live in an environment where by default nobody spoke English. I knew the family personally for 6 or 7 years prior to living with them. The other (minor) reason was location: I grew up in a rural area ~2 miles outside the city, while the family lived in the city and only a couple blocks from the high school (can't link to that now because they moved the high school back in early 2000). By the time I did the immersion, I was biking to school and then to OSU (to work) and then back home every day (vs. riding the bus to school, walking to OSU after school, then walking home every night), so it also doubled a more optimal place to be given where the high school and university were.

How I got to be on this website... well, I suppose running Parodius Networking for nearly 18 years or so has something to do with it. :-) The guy who originally created all of this (the nesdev website concept) is Memblers, and it all used to be hosted by me as http://nesdev.parodius.com/ until I closed down Parodius in August 2012. There is a #nesdev IRC channel on EFnet that (at the time) was used for a lot of collaboration and communication, so I hung out there. When Memblers wanted to do a website, I was happy to host the content (since we mainly focused on hosting things relating to emulation, video game development, or electronica). I stopped joining the IRC channel at some point (maybe 2007? I forget) and just hung out here.

Sort of along those same lines (and earlier parts of my posts here), there's an old thread talking about why I stopped doing nesdev, in case you wanted to read that. The very last bullet-point is the one that sticks, the rest are just things I experienced which greatly diminished my interest in doing nesdev. But like I said earlier, I still do some development through the form of romhacks (specifically hacking existing games so they could have their text translated from Japanese into English), so I guess I haven't completely left. I haven't done SNES stuff since the mid-to-late 90s, but most of it is still in my brain. I really do think the SNES is the easier/better console to develop for (from a programmer's perspective); once you deal with the NES and its nuances, almost all the things on the SNES are like a dream. I think the one that stands out the most (to me) is how on the SNES you can get the state of all the joypad buttons + directions in a single 16-bit read statement (lda $4218) while on the NES you can only read 1 bit (button/direction) at a time, thus have to do stuff like this. We're talking 5 or 6 cycles vs. 132+ on the NES.

It's shifts and ANDs and ORs and a separate index, which can get expensive with only two index registers.


The index of a particular sprite in high OAM differs from the same sprite's index in low OAM. Specifically, they differ by a factor of sixteen. The 65816 has two index registers: X and Y. If X is used for the metasprite table and Y for the index into low OAM, you need to swap Y back and forth between pointing to low OAM and pointing to high OAM.


It's my term for storing sprites' high OAM bits (X bit 8 and size bit) in a separate 512-byte table that uses the same indices (4 bytes per sprite) as the 512-byte low OAM table. Then a separate optimized post-processing loop uses two index registers to combine the high bits of appropriate sprites into high OAM. See ppu_pack_oamhi in src/main.s in my Super NES project template.


It's a mix of 50-60 Hz (every frame), 25-30 Hz (every other frame), 10 Hz (every 5 or 6 frames), and 5 Hz (every 10 or 12 frames). The things that the player has the most direct control (mostly cursor movement) run every frame, but other tasks run on a "time-sharing" system where one is run each frame. For example, in Thwaite, only half the explosions are collision-tested and drawn each frame (hence 30 fps), and only half the smoke particles are drawn each frame. This alternation between even and odd also gives the explosions and smoke a constant semitransparent flicker. And in RHDE, only one unit moves each frame, and it takes 0.2 seconds to cycle through all units owned by both players (hence 5 fps). A player can give a movement command to his current unit at any time, with a visible effect (movement of the destination cursor) reflected immediately before the unit actually starts moving.

tepples, when you were talking about the "soft OBC1" did you say you make a separate 512 byte table just to fill out 32 bytes? I downloaded the SNES project template and opened up the file, (Why is it a .c file? I've never even heard of that before. I usually use a text or ASM file.) but I couldn't find ppu_pack_oamhi for the life of me. I think what bazz suggested is a great idea and It would really help people like me. Maybe somebody could explain the soft OBC1 technique in great detail and even post some code for it in on superfamicom.org. (I'd say I would after I figured it out, but I am really not good at making tutorials and don't have nearly as much information about the SNES as 99% of the people here.)

About how developers don't go though there entire game to look for minor problems, I still fail to see how they would make a more complicated 6 line code easier than an extremely straightforward 4 line code.

Also koitsu, It seems a lot of people treated you like an asshole. (I don't even want to know how they would treat someone like me.) The only question I still have is (this isn't meant to be an insult of any kind) where did tepples come into play? I saw that he was on that website where you said you quit NES development.

Yes, because I'm under the impression that it's faster.


I didn't see any .c files in there. Could you take a screenshot of the part of the zipfile that contains a .c file? A .s file is functionally the same as .asm.


How big is the src/main.s file? And are you using Notepad on Windows?


Someone did.

I guess ram isn't nearly as big of a problem as CPU time.


You're right. I'm just crazy. (I mean't .s instead of .c)


I am using Notepad++ (as previously suggested) and the file is 545 lines long.


Ohh... I thought it would have been under the newly formed Soft OBC1 link. (I guess that can be taken down now?)

You're looking at that code after the fact. You have the luxury of knowing what it needs to do, and what it doesn't. This isn't really true for a developer until the game ships. Probably at one time they were trying to do things a different way (e.g. more sprite features that were planned but never actually implemented, or removed), and some editing eventually reduced it to what you see there. Maybe it was just a quick change to make a demo to show to the boss, planning to get back to it to clean it up but never did. There's a million different ways a person might write strange looking code like this. If all you have to go by is a disassembly you have very little to speculate with (especially a tiny and out of context example like this).

I'm not saying it's good code (it clearly isn't). I'm just saying that weird garbled code that still just barely works happens pretty naturally in the development process. Once it's there, someone actually has to notice it before it gets fixed, so if it doesn't break the game, it's not terribly likely to get noticed. Every game ships with bugs, and this isn't even a bug. It's a funny example, sure, but not one that I'm surprised to see.

Someone did.[/quote]

The way how this method is listed in the "How to display a sprite" section makes it non-obvious to an advanced user that he can learn an optimization technique here.. I think an optimization section on this and other techniques is essential in contrast to just residing in the "how to display sprites" section. I dunno, what do you think? I think I have a point here.. Something a little more standardized..

Little inefficiencies add up if there are a lot of them.

When it comes to assemblers, any file extension is fine. You can have the source code written in a file with the .exe extension and it will work the same, so you can use whatever you like. I do prefer .asm though.

In my experience, in technological fields, there tend to be a lot of "crotchety old men". Some don't give a crap and just want to be jerks, others are brash/crass/rude while still having good intentions (i.e. they don't convey their information in a friendly or nice manner). Console "hacking" (reverse-engineering, homebrew development, etc.) is a technical field.

But on the flip side, if you were to dig up some of the old #nesdev guys (some are still here) and ask them about me, they'd be able to tell you stories of me being a complete dick to people (especially on IRC). That's a whole other topic in itself though, and to try and keep it short, there are parts of that I'm a bit ashamed of. Something in me snapped at about age 25 where I just realised that I didn't want to argue/fight/battle with people any longer. I'm now more tolerable as a person; disagreements or conflicts I tend to avoid (including those on the forum here). But I'm sure if you read my posts you'll find a few where I'm fairly direct/bordering on brash; old habits die hard sometimes.

Tepples is just some random dude who found something I said on PocketHaven (since he hangs out there) and made a thread here about it. There isn't a connection between him and me ceasing to do development/docs any longer. :-)

And some people like me just appear rude because they're still learning the finer points of social skills, even in their thirties. At age 15, I was diagnosed with a mild form of autism that sometimes make me forget the tact when I bring out the honesty. This diagnosis tends to be more common among people in technical fields.

Uh...huh.
The jargon file has a few options.

However, I'd say it would be both modding a game that may not readily provide resources to easily do so (e.g. nigh-all Nintendo games), and the preparatory work and investigation that this requires.

Cracking a game, contrariwise, is disabling the DRM/copy protection, often adding a "trainer" to allow options not-normally-accessible or cheats to be enabled.

(Some others may put it that hacking is fiddling with the intricate bits of a computer benignly, and cracking, maliciously.)

I remember reading an interesting article explaining why SNES was released late, stating that in Japan, the Sega Genesis wasn't very popular and they thought it was going to be obsolete in a couple years, so they took their time with the SNES. Then in 1990, they realized that Sega Genesis was a big hit in the US and Europe so they had to change plans and release the SNES ASAP.

Maybe this affected 3rd party games. Maybe they were planning on fixing the slowdown for a 1992 release, but the deadline was cut short, and they didn't get around to it. Was the SNES's hardware even finalized by the time the games got started? If not, it could explain games organizing sprites in unusual ways that bare little resemblance to how the system operates.

I do recall reading that Nintendo at one point was not in a rush to release the SFC since the FC was still doing well. I don't think anyone knows if the Sega Genesis' western success had anything to do with when the SFC was released. But you shouldn't forget about the PC-Engine in Japan. It was quite popular there, more so than the MegaDrive I believe. Pressure from one or both of these competitors had something to do with when the SFC was planned to be released.

About developing on non-final hardware, we'll probably never know that either. Not unless someone finds and interviews someone at one of these companies at the time. Both Final Fight and Gradius III were released to arcades at the end of 1989. That gives both games about a year between arcade release and their SFC release. Perhaps they were on a tight development schedule. As it has already been said, a working product is more important than an efficient one.

If the games are so poorly optimized and the slowdown could be eliminated by some reprogramming then it would make a very nice ROM patch.

If only I had the original source code for these games, I can probably fix them in less than an hour. Making sure the optimized code fits into the exact same size as the original is a pain in the butt to do.

You could always make like doppelganger and disassemble yourself some source code. SMBDis is what ShaneM worked from when making a huge bug fix of SMB1 and SMB2 (J).

Don't forget that games usually have padding at the end, you can probably insert the new routines there and then just add a jump into them at the beginning of the original ones - this is how I injected the Super Sonic code into Sonic 3D (which has the ROM size maxed out). New graphics and such take up a lot of space, but replacement sprite routines would probably be small enough to fit =P

Also honestly it may be just better to expand the ROM size.

EDIT: before I forget

Wasn't the DSP in Pilotwings added because that part was originally in the SNES and was removed at last moment, and they didn't have time to reprogram the game to not use the hardware? (which would also imply that the 65816 was perfectly capable of doing those computations on its own, just that they didn't get around doing it)

The SFC was "announced" in September, 1987, and reportedly software was already being designed for it. Hardware design might have even begun in 1986.

http://www.chrismcovell.com/secret/SFC_1988Q4.html (1st showcase)

http://www.chrismcovell.com/secret/sp_sfcpromo1988.html (design & specs)

In November, 1988, the SFC was displayed and its hardware specs were exactly the same as the final 1990 version, barring the size of its work RAM.

So, yeah, 1986/87 design, 1988 hardware. Sat on for 2 years.

In July 1989 when Nintendo pushed back the SFC release until Nov. 1990, game companies had *even* more time to prepare their games right, in theory.

Does that seriously say 8K? I blew past that just doing a title screen mockup. Granted, I wasn't especially careful with WRAM (or CPU cycles), preferring to save ROM...

Glad someone decided it was a bit slim, especially considering the Mega Drive was already out with 64K... I guess the size of the RAM mirror available in LoROM might be an artifact of this...?

Also, from that second article translation:


You said it, pal...

Initially 8192 bytes of RAM; tiles are bits 0 and 1 line interleaved, then bits 2 and 3 line interleaved; work started in 1986, when the PC Engine was presumably finished and headed to manufacturing for a release next year. Now I'm suspicious: Was Nintendo trying to remake the PC Engine?

(Corrections to the timeline have been incorporated.)

I thought the PCE came out in 1987?

From what It sounds, it seems like Nintendo decided to add more ram later on. Although there is no solid reason as to why I thought this, I always though that the SNES was originally supposed to have more ram than it did, but it got cut later on. I am really referring to vram, as I always thought 128KB of work ram was more than enough. From what I've seen, quite a bit of arcade machines didn't even have as much work ram. In fact, I don't think I've ever seen an arcade board from back then that had more wram than vram. One of the main reasons that I thought the SNES was originally supposed to have more vram is because not only is it half the size of work ram, (unlike the Genesis, where they are the same) but several registers for selecting a starting position for tiles for BGs have an extra bit that, if containing a one, will double the value of the position making it wrap around to zero. This is why I originally asked if you could add more vram, as I don't know why they would have just left an empty bit when they could have just made it to where the distance between each starting position you could select would be cut in half.


According to Wikipedia, you are correct. Tepples could have just made a mistake. About the PCE, do you know how much CG ram it had than the SNES? I know it has twice as many colors on screen, but the color depth is only 9bits instead of 15bits (still takes up 16 bits, though) so I would imagine it has four more bytes.

Nope, but it's a well-used strategy of Nintendo's to announce (or give tantalizing updates about) their own hardware, with precision timing that takes the wind out of the competition's sails. And relieves media & consumer pressure on Nintendo.
eg:
Competition........................Nintendo
PCE Release, Oct. 1987........SFC "announcement", Sept. 1987
PCE CD-ROM, Dec. 1988
MD Release, Oct. 1988.........SFC showcase, Nov. 1988
..
Mega CD Release, Dec. 1991... SFC CD "announcement" Q3&4, 1991
...
it goes on...

The irony of you mentioning the Genesis is that Sega planned to give it 128KB of video RAM as well =P (there are still traces of it in the video hardware and indeed if you add the missing memory it works just as intended, double bandwidth and everything - I wonder what Nintendo would have done with the SNES if Sega had taken that route)


Could have been already announced by then though, specs included (since it was just one year before release). I know that the PCE CD was already announced when the PCE was released (the heck?).

I'm not very familiar with the Genesis hardware so I'm wondering what exactly do you mean by this? You say double the bandwidth? I'm not clear what the advantages are to be gained by another 64kb of VRAM. I do know that it could have used more color palette ram. That would I think have been more useful than more VRAM.

I'm not sure what exactly the SNES would gain by having 128kb of VRAM either. I guess you could put it to use if you made an effort.

The practical limiting factor for expanding VRAM on the Super NES S-PPU is that only one-fourth of VRAM can actually be used as OAM. Background tile numbers in mode 0-6 are 10-bit (32K range with 4bpp tiles) with format vhpcccnn nnnnnnnn, while sprite tile numbers are 9-bit (16K range) with format vhppcccn nnnnnnnn. So as I understand it, S-PPU video memory should be laid out thus:

Mode 0-6

• $0000-$3FFF: Background tiles
• $4000-$5FFF: Sprite tiles
• $6000-$7FFF: Nametables and HUD layer tiles

Mode 7

• $0000-$3FFF: Background tiles and nametable (byte interleaved)
• $4000-$5FFF: Sprite tiles
• $6000-$7FFF: Nametables and tiles for HUD and horizon layers

Compared to the S-PPU, the Genesis VDP sacrificed one bit of color and one bit of sprite priority for 11-bit tile numbers, which let it pull sprites and background tiles from the entire 64K range. The format for both is pccvhnnnnnnnnnnn. So I imagine that if VRAM were doubled, the sprite system would get a dedicated half.

I think the Genesis gets access to another buss, enabling it to DMA a word at a time with the extra 64kB of VRAM

Depends what you're trying to do. In my porting project, I'm pushing the limits on VRAM in pretty much every section of the game, from the title screen to the end credits, and in fact I'm making minor compromises left and right due to insufficient space. It's a bit of an edge case, I grant you; the game was never conceived as a SNES game in the first place and it's kinda surprising that it fits as well as it does...

Generally the SNES doesn't seem to have been gravely limited by its VRAM, but I'm given to understand that stuff like 8bpp and the hires modes didn't get much exposure, possibly because they consumed too much memory to be worth it. And people have complained about the unwieldy sprite system and slow DMA; more headroom for table switching might have helped with that...

Yeah, the video bus in the Mega Drive becomes 16-bit when it's in 128KB mode (normally it's just 8-bit). Given how the VDP behaves like it's always accessing words, it sounds like 64KB mode was tacked in really at last moment. Apparently Sega backed down on that because they thought that it was only useful to have more tiles (like that'd be something minor... but yeah, reducing the price of the system I suppose).


In 128KB mode, you can choose to use either the lower or upper half of the video memory for tiles. This can be selected separately for each of the layers (one bug aside, but it can be worked around without losing anything). This basically means that how the memory is used is entirely up to the programmer.

EDIT: oh, and yeah, the tables can be assigned anywhere within the 128KB range, no limitations on that.

Added more vram.


Might I ask what your project is? I'm just curious. I always thought it would be really cool if somebody tried to make a Metal Slug port for the SNES. You could use BG mode 3 and have the first layer be 8bpp and the second be 4bpp, but you would run into vram issues very quickly. For example, I ran this picture through pcx2snes and found out it used 638 tiles out of the total 1024, and this is only for one screen, meaning you would have to load new tiles every time the screen budged.



Although unrelated to vram, you would also find yourself running out of palettes for sprites very quickly. An example would be if you were playing 2 player and you both fired your gun, threw a grenade and had a grenade explode, you would have already used up six palettes right there. (Almost everything in that game uses different palettes.) I guess you could try to make an area in ram that takes up 8 bytes and every object in the game has a special palette defined by a certain number and check to see any of the numbers match the one of the new object onscreen. You would either use an existing palette or use an unused one. The problem is, with 8 palettes, you're practically guaranteed to reach the end of the list without finding the right palette and in that case, you would just display the sprite with the wrong palette, which would look terrible, but its the best you can do. I think it was really wise for Nintendo to double cgram when they made the GBA, but that system came out about 10 years later. I think I actually remember there being a port of the original Metal Slug being released for the GBA, (I'm not talking about Metal Slug Advance, as that game is awful) but that SNK was running into "memory issues". What the heck is that supposed to mean? Were they running out of rom? wram? cgram? vram?

EDIT: Does anyone know what factors affect DMA speed? is it the speed at witch the processor starts DMA that makes it slow, or how long it takes the electric current to go across the circuit board? (I would image the ladder being almost instantaneous.)

About Metal Slug on the GBA:



Source. Looks like it was ROM space that killed the project. Perhaps 32 MiB wasn't enough, or they didn't want to pay that much memory. Not that I'm exactly well versed in Metal Slug games, but I found Metal Slug Advance to be pretty enjoyable I just like to shoot stuff...

Oh, so it was the romsize? I had never actually looked at the website, but I heard it from people online, who didn't describe why in too great detail. (Kind of like a game of telephone.)


Didn't GBA games also come in 64Mbit sizes? And does anyone know how expensive memory was in the early to mid 2000's? (I was only about 5 then, so I have no clue.) I would image it would be far less cheap than the SNES days.

I wonder if SNK could fit Metal Slug on a 64Mbit cartridge if they tried hard enough. I know most Neo Geo games (Metal Slug included) don't make good use of memory and use about 3x as much as they should, having large gaps of no data and having none of the graphics compressed. (Why bother when you can just throw more money at it?)

The most ROM data you could load in is 32MB. The GBA is hardwired to only see that much in memory (though this is mirrored across several sections with different access timings).

But 64Mb (Megabits) is different from 64MB (Megabytes). B vs. b; it makes a difference. I'm pretty sure there were 64Mb carts out there (8MB).

So the largest GBA games are 8 times as big as the largest SNES games? Then in that case, how did SNK possibly run out of space? Aren't the largest Neo Geo games that don't use bank switching (Metal Slug is one of them) 330 megabits so the largest GBA games only 74 megabits smaller? I know they could have fit 330 megabits into a 256 megabit cartridge if they compressed the graphics and tried a little harder to condense everything.

Well I wasn't intending on hacking a game last night, but I did :]

https://www.youtube.com/watch?v=vCqLewz ... e=youtu.be

In this video I walk thru how I hacked Kirby's Dream Course to have every enemy in the game offer the U.F.O powerup.

Metal Slug the NeoGeo MVS/AES version is a little over 26 megabytes of data. That does fit into the maximum amount, but depending on the year we are talking about it may have been prohibitively expensive. Metal Slug was already old by the time the GBA was released. It probably wasn't worth it.

Maybe tried to boost the DMA transfer speed too? It might have required a bit of a system redesign, though; the 8-bit bus combined with the 200 ns memory doesn't seem to leave much room for just overclocking the DMA unit...


I'm keeping the specifics on the down low. Without getting into my life story, I've become wary of making promises I can't keep, and this is an extremely ambitious project (especially for someone who knew almost nothing about SNES programming nine months ago).

Basically, it's a vertical-scrolling bullet hell shooter, with enough bullets that I need a Super FX chip in high speed mode to have a hope of displaying them all even at 30 fps. It was originally developed for a much more sophisticated platform, so it's not just VRAM that's getting a workout here - in fact, due to a special technique I plan to use, I doubt it will work on a SNES Jr....

...

That Metal Slug picture looks like it might be doable in 4bpp without too much pain. Neo Geo graphics were 4bpp in 16x16 tiles, and this image only has 52 colours total. Then again, the Neo Geo had a lot of palettes available, so this doesn't necessarily imply that four or even eight SNES palettes would cover it. Still, it looks pretty good in 31 colours and decent in 15, and it looks like some of the colours only occur near the top while some only occur near the bottom; those you could just replace with HDMA. I bet you could pull off a reasonable facsimile with two or three 4bpp palettes if you had to (though if the scenery changes much, doing the whole level would probably take more). Of course, this doesn't invalidate your point regarding the addressable tile count...

Addressable tile count isn't too much of a problem if you have VRAM and aren't trying to scroll as fast as Sonic the Hedgehog 2 in Chemical Plant 2. Just replace the tiles themselves along the seam. This might require a 248-pixel-wide window to cut off the wrap tile at left and right, but nobody complained when Kirby Super Star used a 248.

But 4-bit works when you can divide the pic into areas that use different sets of 15 colors.

Than in that case...




What do you need the Super FX chip for? Collision detection? To my knowledge, you can't actually add sprites via an expansion chip, but you can simulate there being more if you set up a frame buffer.

I always thought that Metal Slug used a two "BG layers" (the background is really made of 16x512 sprites) for the foreground and one "BG layer" for the background (I've seen sprite clipping in the game, which led me to believe it was using 3 BGs). The picture actually does work using 4bpp, but it uses 6 palettes...





Still, overall, the hardest part of the game would be the sprite palettes, but unless you were trying to make them run out by pilling a bunch of different enemies on screen and playing 2 player and both shooting and throwing grenades (almost actually never happens, but would make the game look terrible if both players did).

I know this sounds kind of bizarre and contradicts me talking about how difficult it would be to port a Neo Geo game like Metal Slug to the SNES, but I always thought it was a little strange how glorified the Neo Geo's hardware is. The only thing about it that really blows the SNES out of the water is the color palette and vram. Despite these improvements, I still fail to see how the Neo Geo could cost 3.5 x as much as the SNES, unless they were just drastically overpricing it to make it seem more powerful than it is because someone would buy it. (The kind of people who buy the newest phone that's only 5% stronger but costs 3x as much.) Even for an arcade machine, it isn't exactly the most powerful. I can think of several stronger arcade boards that were released at the same time, most notably being this beast. http://www.system16.com/hardware.php?id=709

Exactly. The Super FX chip is very good at blitting directly to bitplane format, so instead of having the PPU handle each bullet, I can simply draw them to the GSU's frame buffer and DMA the results into VRAM over the course of two frames. Any bullets too fast for 30 fps can be handled as individual sprites; there shouldn't be many.

There are also other tasks that I'm not sure the S-CPU is fast enough to handle, and collision checking is one of them - not only can there be hundreds of enemy bullets, but the player shoots a lot of bullets too, and there can be a significant number of enemies on screen...


There's got to be a way to reduce the number of palettes that takes without it looking too bad (shots packed in with explosions, grenades packed in with characters or enemies - something like that). It kinda seems like since Neo Geo games pretty much couldn't run out of palettes, the developers didn't bother optimizing their graphics...

A little off topic, but here is an update of my Super Ghouls and Ghosts slowdown removing patch. It uses a combination of both fast ROM and code optimizations. This is for bass assembler.

I'm under the impression that in the early days, "fast" ROM rated at 120 ns was more expensive than "slow" ROM rated at 200 ns. Nowadays costs are different, but I'm still curious how much optimization could have been done without just saying "screw it; let's just OC the ROM."

Once I get it perfect, I'll start on an all slowROM version, just for the sake of challenge. If your making a repro, it doesn't matter because there wouldn't be a difference to the player, since he/she would be happy to finally play the game full speed.

Well the NeoGeo's 68000 cpu ran at 12mhz so that probably added a good amount of cost. Also the SNES uses DRAM for the 128KB of WorkRAM which the NeoGeo I believe uses Static RAM which is more expensive. The speed of that RAM may also have added to the cost. Though the comparison there depends on the prices each company was getting from their supplier at the time and the exact combination of RAM chips. The NeoGeo boards in general are larger PCBs, probably with more components. That adds cost in components and I assume for assembly too. These are just some ideas.

I doubt they purposely "overpriced it". They probably, like Nintendo, sold it to break even or even profit. But I'm sure it was expensive to produce, more so than the SNES.

The NeoGeo doesn't blow the SNES out of the water with "vram", it's Character ROM (like CHR-ROM on NES) that does that. The NeoGeo just can address huge amounts of Memory for graphics which was far too expensive for consumer hardware like the SNES. If the SNES could map in 64 Megabytes worth of Character ROM at will and memory was cheap, the SNES could have had animation as good as the NeoGeo.

I think the NeoGeo was a pretty good system that was well supported and lasted quite a long time. Opposite of your statement, the only thing I see where the SNES "blows out of the water" the NeoGeo is the PPU. The SNES has some fancy PPU features that the NeoGeo as far as I know does not. The NeoGeo is more about raw power. Lots of sprites on screen with lots of C-ROM. A fairly beefy CPU that you could develop games for in C rather than ASM if desired. The sound hardware could produce some very nice music and sound effects too. But the SNES can do things like Windowing and Color Math. I know NeoGeo can do Raster Effects though I don't know how it compares to HDMA.

It just seems silly though comparing the systems. They may be from the same era but they are not in the same category. Both are great systems with great libraries of games.

NeoGeo hardware is expensive because it is filled with various chips, there's a nice handful of SRAM there for example. The ginormous cartslot with multitude of buses doesn't help with cost either.

Here's couple photos I that show some bits of my MV-1 and MV1-FZ :
http://www.tmeeco.eu/BitShit/NeoGeoPentagram.jpg
http://www.tmeeco.eu/BitShit/NeoGeo2.jpg

If it's anything like the work RAM in the Mega Drive, the speed penalty is around 1%, and that's assuming the CPU is doing all its fetches from RAM which is not the case since usually code is run from ROM... not really worth taking into account.


Don't forget that the NeoGeo as a console was initially rental-only, and the fact that the hardware was originally made for arcades instead of being consumer grade. Heck, the whole point of the console was to pay a premium in exchage of having proper arcade quality =P

In a Super NES, the DRAM refresh alone robs ~3% of the potential speed from the system, since the CPU is outright paused for 40 master cycles per scanline. If you assume SRAM would have allowed high-speed operation, fetching from RAM every third cycle or so is another ~10% on top of that, because it takes 8 master cycles instead of 6. Running completely in WRAM with nothing but load and store instructions takes about a 27% penalty when considering both factors. If the WRAM had used the same type of memory as the VRAM (like the Neo Geo did), it might have been possible to run the CPU at 5.37 MHz, resulting in a speed penalty of more than 50% in the historical worst case (though I'm not sure what that would have added to the cost of the CPU).

I have only a passing familiarity with the internal details of the MD. What do you mean by "the speed penalty is around 1%"?

Does that mean that vram is stored inside the cartridge? I've never heard of that expression before. I've only worked on the SNES, but I don't remember the Sega Genesis or the Turbo Grafix 16 having that either.


Is this saying that sprite data is also stored inside the cartridge? (I think I'm beginning to realize why the cartridges are so large) I don't think I've ever seen a Neo Geo game put 381 sprites on screen, much less 150. I know backgrounds are made of sprites, but It's rare to find a Neo Geo game that even puts out more than 2 backgrounds (42 sprites when scrolling). I think the reason most Neo Geo games don't put many sprites on screen is because of the 96 sprite per scan line limit. While on the subject of sprites, I think It probably would have been wiser of SNK to have made the sprites 256 pixels tall and used the unused character bits to be able to have each 16x16 tile use a different palette. (They take the same amount of space, but I have no idea if it would actually work like this.)

I wonder if the Neo Geo were to start off as a home console that maybe they could have gotten it to cost a lot less while still keeping or almost keeping the same graphical power by getting chips from different suppliers or just reworking the system to have about the same power while getting rid of some of the less useful stuff. I actually seem to remember that originally, the Neo Geo MVS was originally supposed to go for $600 dollars but it was changed to $700, meaning they profited at least $100.

About the Neo Geo's sound vs. the SNES, I've heard that the Neo Geo has fourteen sound channels, but that 7 are FM. I know that the music in Metal Slug is a mixture of FM and PCM. I always thought that maybe if Nintendo had gone for cheaper, but not much worse (meaning they didn't ask Sony) sound hardware how much money could have been used to upgrade some parts of the system that needed a little more help.

Yes, all sprites or graphics in general are stored in Character ROM (C-ROM) on the NeoGeo. VRAM would only be for defining tile positions and attributes, not the actual appearance. The NES can have either RAM or ROM for the Character (graphics) data. Besides the NES and NeoGeo, nearly all other systems use internal RAM for video memory so all graphics are transferred from ROM to RAM first. The NES and NeoGeo have to have a separate Bus for the graphics because of this which raises costs. The SNES and Genesis do not have a video related data bus going to the cartridge connector like the NES or NeoGeo.

So vram on the Neo Geo is essentially oam? What even determines what you call each area of memory then? I know that the SNES was supposedly "built for expandability", but It seems increasingly like the NES was more so. Also, if "vram" is in the cartridge though, doesn't that mean you can expand it infinitely? I guess you're still limited to the character selecting bits though.

The speed of the 68000 has been benchmarked before, the difference when the benchmark runs from ROM and when it runs from RAM is about 1%. (granted, some cycles are also stolen when running from ROM, but is that the case with the SNES as well?)

In any case the 65816's instruction set is probably a much bigger issue when it comes to performance, not to mention that Metal Slug already slows down on the NeoGeo in the first place. (that said, we don't know if the game was programmed sloppily though, which seemed to be rather common with arcade games, so maybe it's still feasible as-is)


Huh, pretty sure each tile within a sprite has its own palette (as well as its own flip settings), this is why faking full blown tilemaps with a few sprites works. Also probably why there's a feature to let the video hardware animate the sprite automatically without the CPU's intervention, animating huge sprites would be hell since you need to specify every tile.


As I said, originally the system was rent-only and was geared specifically towards a niche of the market. Higher prices make sense in those cases.

Yes. The Neo Geo CD uses bog-standard CHR RAM like the TG16, Genesis, or Super NES. But on the AES cartridges, I don't even know if the write enable is brought out to the cart edge. If it isn't, then it isn't even possible to make a cart game that uses software rendering. Is it?


Yes. All sprites and all tiles that the HUD layer uses are in the CHR ROM.


That's roughly comparable to the Super NES, with three background layers (60 sprites) plus just under 2x overdraw. However, if a background layer doesn't cover the full screen all the time, then it doesn't consume 20 slivers throughout the whole screen.


In other words, it's like a Genesis's Yamaha synth and a Super NES's DSP at once.


Yes, except for the HUD layer.


That's why the "Giga Power" cartridges have a mapper to address more CHR ROM.

Except for the complete lack of special effects. As far as I know it's just some ADPCM channels. Don't expect to be able to do stuff like reverb with those channels, unless you fake it somehow.

6 of the channels are also fixed pitch, and 7th is the only variable pitch one. Sound quality is massively higher though, especially since you have pretty much no limits on how much sound data you have.

With 1536 pixel scanline limit and clipping mode set to 304, you could do 4 layers (320 pixels) and still have 256 pixels left for sprites on that scanline.

The difference is that 256 pixels isn't enough for 100% coverage of a 304-pixel scanline. So if you tried doing four full background planes, you'd get sprite dropout sooner than you would, say, on the Super NES with four 2bpp backgrounds.

Is that because the Mega Drive is an asynchronous system? Aside from the audio module, the entire Super NES runs off one master crystal, so I'm not sure where any stolen cycles would come from.

I'm pretty certain the S-CPU and its DMA unit pause completely for DRAM refresh, regardless of where the next access is. So it's not a difference between ROM and RAM as such; rather a penalty to the whole system due to the use of DRAM.


I wasn't aware we were comparing the 5A22 directly with the 68K. That seems to be a bit of a can of worms, but I am given to understand that the 65816's lean, headlong quasi-RISC architecture makes up for a lot, and the difficulty of programming it is only an issue if you have a deadline. I would have said the vast clock speed difference was more of a problem - the S-CPU in FastROM mode may be in roughly the same class as a 68K at 7.67 MHz, but a 68K at 12 MHz is a different story.

If it turns out the SNES can't handle Metal Slug by itself, there's always the SA-1...

I really don't think that you would need the SA-1, or any expansion chip for that matter. In terms of pushing sprites around, doing collision detection and other CPU related stuff, I'd say Metal Slug really doesn't put much more strain on the CPU than a game like Contra III. (At least what I can see.) I think the bigger issue would be (ironically) the things you can't fix using an expansion chip, like cgram size.

EDIT: Apparently, according to http://superfamicom.org/info/contra-spirits the U.S. version of Contra III is a fast rom cartridge, but the Japanese and European versions are slow rom. (I've never heard of the same game using different cartridge types in different regions.) Does anyone know I the two slow rom games run as smoothly as their fast rom counterpart?


The game was definitely programmed sloppily. Metal Slug X is testimony to that. (It seemed like Irem/Nazca knew how to bring any system to its knees. ) If you were to write Metal Slug in ASM and not C, I really don't think you would have a problem.


wasn't that the overdraw size on the Genesis? I've read that that the overdraw on the Genesis is 320 pixels, but I see sprites getting clipped way to often for that to be true. The website I read it off of said that the SNES's overdraw was 256 pixels instead of 272 and that the SNES didn't have 8x8 sized sprites, so that just shows you their credibility. (It seems like they accidentally used some specs from the Turbo Grafixs 16.)

Genesis has 320 pixel overdraw in 320px mode and 256 pixel overdraw in 256px mode. Super NES has 272 pixel overdraw in 256px mode.

But the usable fraction of the visible screen depends on how wide the pixels are. Super NES pixels and Genesis pixels in 256px mode are "wide"; Genesis pixels are "narrow"; Neo Geo pixels are closer to square. For now let's assume that the SNES/MD picture, which is 47.68 ns wide, is the same width as the visible picture (the "action safe area" in TV production parlance). At 6 MHz, that equals 286 Neo Geo pixels. So an apples-to-apples comparison should use 19 sprites per background layer with two frontmost solid black border sprites framing a 288-pixel-wide action safe area. This gives 5x total overdraw, just a hair less than Super NES in mode 0 and substantially more than Super NES in mode 1.

This increases if the sprites serving as a background plane only partially cover the screen, which could easily be the case if the characters are interacting with background objects like terrain and ? blocks. But it decreases once you shrink the sprites any, and needing to account for shrink might explain why Neo Geo games use less coverage than you might otherwise expect.

Here are my calculations in case you want to look into it some more:

• TMS9918 pixel clock (NES, Genesis 256px, Super NES): 3/2*315/88 = 5.369 MHz
• Neo Geo: 6 MHz
• Genesis 320px: 15/8*315/88 = 6.712 MHz
• Exact square pixels (for reference): 320/704*13.5 = 12/7*315/88 = 6.136 MHz
• NTSC picture width as defined in Rec. 601, including overscan but excluding nominal analog blanking: 704/13.5 = 52.15 ns
• SNES/MD picture width as fraction of Rec. 601 picture width: 256/280 = 91.43%
• Neo Geo picture width as fraction of Rec. 601 picture width: 320/6/(704/13.5) = 102.27%

Was there any reason for the Genesis in 256 pixel mode using 256 pixel overdraw instead of 320? I guess they were trying to urge developers to use 320 pixel mode?

The 320-pixel mode increases the clock rate of the VDP. This opens more cycles to fetch all the sprite pattern slivers.

The entire system runs off a single around 53MHz crystal (I think the SNES has a crystal that's about half the speed, somebody correct me here please).


I was talking about when the 68000 was running (during DMA the refresh timings change completely since the VDP takes over).


Yeah, pretty much. The clock rate is directly tied to the pixel size, they make the clock faster to make pixels smaller (i.e. take up less time). Incidentally, DMA speed in 256 pixel wide mode is exactly the same as on the SNES.

EDIT: I swear tildes (~) look like hyphens (-).

MD master clock is 53.203424MHz in PAL units and 53.693175MHz in NTSC ones. Stuff in some areas of south america have a different value.

I don't recall the DMA being exactly same in 256pixel mode between SNES and MD, but it has been a while since I did any caluclations on that part... SNES has one DMA cycle happen every 8 master clocks, minus the region in the middle of line where DRAM refresh happens.

For both SNES and Sega Genesis, DMA speed is exactly 1 byte every 2 pixels.

Do you mean the ability to "chain" sprites together or something else?



Where did you get that the SNES was "built for expandability"? Most systems have certain ways the manufacturer might expand them.

And yes, the NES and NeoGeo potentially can have as much video memory as someone cares to put into a cartridge and make addressable. With enough memory I suppose you could play some sort of FMV on NeoGeo. You could do the same thing on NES but you're more limited.

SNES NTSC master clock is 21.477 MHz.

What do you mean by "stolen" cycles then? I was under the impression that SNES timing is what it is, and that you could in principle write a loop that reliably took exactly n scanlines if you paid attention to what each cycle of each instruction does.

No, every sprite is specified as a list of 16×16 tiles (you don't specify only the first one), and each of those tiles can have its own palette and flip settings.


I recall somebody arguing that the reason custom hardware in cartridges was so common was that the SNES was built for expandability, which honestly sounds like a bullshit rumor to me =P (it's not any more expandable than other consoles at the time)


Sometimes the 68000 ends up having to wait for a memory access because the hardware wants to hog the bus for whatever reason. Supposedly this may be for refresh - since development cartridges used DRAM and there's a register that is meant to enable the refresh signal through the cartslot (but apparently doesn't affect the timing?). Given that it's likely that the SNES also had development cartridges like that I wonder if such delays exist there as well, but I'd need somebody who knows the hardware better to tell if that's the case.

(or maybe the 65816 is so slow clockwise that it isn't needed?)

Its the Sega a**holes who always say stupid things like that. Some of the remarks they make are so unintelligent that it makes me want to throw up blood. I always look online at videos of people playing games like Gunstar Heroes or Alien Soldier and saying stupid things like "the SNES couldn't handle a game like this because it would've melted" and the worst part is, I don't even think they're kidding. I don't think Gunstar Heroes is a bad game or anything and it's pretty good technically for a Genesis title, but nothing ever really screamed wow at me. Hell, I honestly think Rendering Ranger r2 looks better, (even if it was only one player, but Alien Soldier was too) and there isn't even the slightest hint of slowdown, despite running on a console with a "SLOW" cpu.

(Sorry about my little rant, I just couldn't help myself )

EDIT: One thing I forgot to mention that cracks me up is when people say that the "SNES faked better graphics by having more colors", as if it didn't take more powerful hardware and that more colors was simply a design choice.

Wait, what? No, in this case it's actually SNES fanboys doing it - implying that being able to use all those coprocessors is actually an ability for which the SNES was especially designed for and that other consoles were inferior for not allowing it (despite that, um, they did actually, just that nobody else really bothered with it). It also goes to show how stupid those claims are. (also consider: why would Sega fanboys say that the SNES was built for expandability but not the Mega Drive which has two full fledged add-ons?)

Also personally I think Rendering Ranger looks like crap, but that's not really the hardware's fault (the effects themselves are fine, too), it's just that the graphics remind me of badly prerendered crap in DOS games from the VGA era (and as far as I heard, the original intention was to use proper pixelart, but the publisher insisted on more realistic graphics).

Oh... I guess I got everything backwards. I have heard some uninformed people complain about how if you took out the expansion chips from SNES games, then that the SNES wouldn't even compare to the Genesis, even if only 5% of the SNES library used expansion chips. I never saw way too much need for expansion chips because all the things I felt needed to be expanded can't be anyway (anything that doesn't have to do directly with the CPU.) About the Genesis's add-ons, didn't the Genesis only really act as a pass-through for the 32x? I always only thought you could only do CPU related stuff through the cartridge slot. I seem to remember you having to plug the Genesis's TV cable (I have no clue what you'd call it) into the back of the 32x.

About Rendering Ranger, I'm not particularly fond of the art style either, (I much prefer Irem/Nazca style graphics) but I do think that the game from a technical standpoint isn't so bad. I'm really not way too fond of the artwork found in Gunstar Heroes either, as I always thought everything looks like it were made of plastic. (I think they did a better job with Alien Soldier in that respect.)

The 32X frame buffer is drawn on top of the Genesis graphics through a genlocked overlay. The Genesis graphics are still visible in pixels marked transparent in the 32X frame buffer. All four or five CPUs (dual SH-2, 68000, and Z80, plus the 68000 in the Sega CD if attached) are available.

Yeah, the entire Mega Drive is still fully functional while the 32X is running (in fact, the 32X is kind of a letdown when compared to the Mega CD, since it's just the two SH2s, a framebuffer and two raw PWM channels).

As for the chips: it really depends on the situation. Pilotwings had the chip because some part of the SNES that it relied heavily on was removed at last moment so they didn't have enough time to rewrite the code to not use it (i.e. the 65816 was perfectly capable of doing everything on its own if the deadline wasn't there), the DSP is literally simulating that part. SuperFX stuff obviously would be a severe strain without it (the planar format actually slows it down a lot), although it seems to be implied that it was created because Miyamoto by that point was set on adding extra hardware by the time he approached Argonaut (there's a fun story behind this...). The rest of the chips were either used to do stuff like real-time scaling/rotation or decompression (something both consoles would struggle with... sorta) or as DRM (in which case the processing gain doesn't matter at all), or in the case of math-processing chips (the DSP ones), to reduce development time (since the 65816 is ultimately harder to program than the 68000 because of its more restricted instruction set).

Also worth noting that the SNES stayed for two more years later than the Mega Drive despite the CPU being on par, so of couse its processing power would be lagging behind severely by the end of its lifetime (if Sega had bothered to make the Mega Drive last longer it's likely the SVP or the 32X would have seen more use).

Yeah, I don't think that happens on the SNES; I've never heard of such a thing. DRAM refresh is a contiguous 40-cycle block in the middle of every scanline, and that's it as far as I know.


I've actually done bitplane rendering at 8bpp, and I had to cheat like crazy to get about 5k pixels rendered in two frames (eight different source data blocks to avoid bitshifting, top bitplane used as a pixel mask because all the overlay colours were in the top half of CGRAM). Maybe I'm just not very good at this yet, but there's a reason at least four different expansion chips featured various flavours of automatic bitmap-to-bitplane conversion...

Well, with the SuperFX the problem was that it had the PLOT instruction which at first seems like great... except for the part that it only plots an individual pixel, and that requires eight accesses to RAM (assuming 4bpp: four reads and four writes), and that goes through a cache as well (there's a reason why the PLOT instruction can take so many cycles). I presume this slowed down the SuperFX a lot. Code that's designed around writing multiple pixels at once (which makes sense when you're drawing line spans) would do eight pixels at once in the same amount of RAM accesses. On top of that in the middle of large opaque polygons you can skip the reads altogether (since all pixels in the group get replaced), reducing those to just four RAM accesses. I'm not sure how well the 65816 would fare with this, but maybe the SuperFX could have a better chance if you go with that instead of using PLOT. (the SVP was much faster at the same speed because it only needed two RAM accesses to plot a pixel, and that's assuming it isn't doing multiple pixels at once either)

For the record, if your bitmap width is a multiple of two (e.g. 256 pixels), you can probably just get away mirroring the RAM elsewhere but rearranging the address lines, now your bitmap has been converted into tiles just by reading from a different address, you don't even have to wait for it.

I think you're misunderstanding the Super FX chip. The PLOT opcode didn't plot directly to the RAM buffer; it plotted to an 8-byte pixel cache representing one 8x1 sliver (a stack of bitplanes that could be 2, 4, or 8 bits deep). When running from the instruction cache, this operation took one internal cycle, corresponding to either one or two master cycles depending on the chip's speed setting. When the primary pixel cache was full, or when a pixel outside the currently-mapped sliver was plotted, it would dump to a secondary pixel cache that handled RAM I/O, freeing the primary cache to receive more data. If the sliver in the secondary cache had unset bit-pend flags (ie: transparent or unplotted data), it would read the sliver from RAM before writing it so as to properly superimpose the flagged data; otherwise it would simply dump the contents of the secondary cache into RAM. (If one actually wanted to plot transparent data, potentially overwriting opaque pixels, there was a CMODE flag one could set to enable it - I believe this simply made PLOT set the bit-pend flag when plotting colour #0.)

So for 4bpp, plotting an 8-pixel sliver either in whole or in part would use either 4 or 8 I/O cycles, where an I/O cycle was either 5 or 6 master cycles depending on whether the chip was in high-speed mode or not. I'm pretty sure the worst-case scenario in the manual (48 cycles) corresponds to an attempt to write a pixel in a different sliver twice in a row after a non-full sliver, resulting in the primary cache trying to dump to the secondary cache just as the secondary cache starts reading from RAM, which at 8bpp would lead to a wait state roughly 16 I/O cycles long (96 master cycles, or 48 internal cycles in low-speed mode - I suspect the maximum is actually 80 internal (= master) cycles in high-speed mode, though the manual doesn't say this).

I very much doubt the SVP chip was actually a whole lot faster than the Super FX. Has anyone benchmarked them, or are you just going on the contrast between Virtua Racing and Starfox?

Oh, OK. (doesn't explain the slowness then though... sloppy programming then, maybe?)


Nobody knows for sure yet (good luck testing the SVP on real hardware!), but when the SVP is emulated at around 11-12MHz the game doesn't slow down anymore, while the original SuperFX ran at 10MHz. (the SVP processor is emulated like its stock DSP counterpart, some features like the stack go unused by Virtua Racing though) So yeah, that's where the comparison arises. Virtua Racing runs at 15FPS, if you wonder.

Of course there's also the fact that ROM and RAM are separate in the cartridge and you don't need to keep the 68000 off the ROM for the SVP to be able to run (just make sure both don't try to use the cartridge RAM at the same time), although no idea how much of an impact that has on performance in practice (since what would take a hit is gameplay logic).

Well, this topic has gone places. Lots of places.


Why's that? Looking at prices, it doesn't look like Virtua Racing for Genesis is even expensive.

It's less that (and I even have a Japanese Virtua Racing cartridge) and more getting your own program to use a SVP. In theory I suppose a passthrough cartridge could work (yeah, that'd be a custom flashcart), but in practice I'm not sure how feasible would that be. The program is not a problem since the SVP doesn't contain a ROM (the game loads the SVP program into RAM and then boots the processor).

In any case by general rule its timings and such should match the SSP1601 (and a quick look at the datasheet does seem to imply that it's one cycle per instruction for the most part, albeit it doesn't need prefixes like the SuperFX does), what we don't know is if any of the opcodes not used by Virtua Racing were removed.

...also huh what? Reading some doc I have here (svpdoc.txt) and according to this, it has the address line rearrangement thing I mentioned before, but it's only used during test mode and not in-game. The hell, Sega?

I agree. As usual, if you can find clean split points, PM them to me.

It can just be renamed "nesdev.com's longest thread ever."

The more talk about Neo Geo's CHR-ROM and enhancement chips not helping graphical limitations, the more I'm convinced that the SNES should've been designed with a PPU bus on it's cart slot. They could've had SNES pinouts the same as the NES, but use the 10 EXT pins to extend the PPU data bus to 16-bit, and 2 extra bits for the PPU address bus. Maybe extend the pinouts by another 16 pins to extend the CPU and PPU address buses.

Except it isn't... just looking through 3 pages of threads brings up the PowerPak thread, currently at 38 pages long. I think the INL board thread is pretty long too, just off the top of my head.

That could be significant. By some accounts, the Super FX was not especially well suited to general computing. You were supposed to put the CPU into a WRAM loop while the Super FX was running, and in principle the WRAM code could have been game logic, but I don't think Starfox did much with it.

According to the manual, with later boards it was possible to include up to 6 MB of extra ROM in the cartridge parallel to the GSU, so that the GSU couldn't see it but the S-CPU could access it at any time. And all of it was in the FastROM region. AFAIK no one did this, though, possibly due to cost...


That is a powerful chip. What was the clock speed in Virtua Racing - the usually-quoted 23 MHz, or lower?

Also, maybe it's just my lack of experience with chips other than the 65816, but that setup looks awfully familiar somehow...

Yeah, the SuperFX was pretty much designed to do software rendering of graphics (heck, it was the outcome of Miyamoto not being happy with having to draw sprites from every angle in mode 7), although I imagine it would still do better than the 65816 for stuff like heavy math.

Anyway, the point was that gameplay code isn't exactly intensive compared to 3D rendering (especially not for something like Star Fox which didn't have physics much more complex than, say, Space Harrier), so not running it in parallel with the graphics rendering really isn't much of a loss compared to the massive gain from speeding up graphics rendering. This also means that the SVP allowing it is not that important of an advantage (unless you are really tight in CPU usage for some reason).


As I said, at around 11-12MHz the game doesn't slow down anymore. Nobody checked the true speed, but in any case it doesn't need to be any higher than that for Virtua Racing to work as intended - hence the comparison to the SuperFX 1, which is 10MHz (contrast to the SuperFX 2, which is 21MHz - and yes I'm aware it's just the same processor at different clock speeds =P).

Also beware with quotes about the SVP speed. A common one is that it uses a 13.2MHz clock directly from the console... which is actually a video signal /o\ (the same rumor had been made about having the 68000 run at that speed)

Is it a video signal? Or is it just the pixel clock? Because if it's video, then why does the 32X need loopback cables?

I'd argue that the pixel clock is still a video signal =P (though if you wonder, the 32X only takes color from the cable, the H and V signals are taken from the cartslot)

The 13MHz signal is pixel clock like signal. In 320 mode it switches between 10 and 13MHz depending on position in line (it goes to 10MHz briefly in HBL) and it is always 10MHz in 256 mode.

SVP most probably uses VCLK * 2 intenally, (53203424 / 7) * 2 for PAL machines.

Like this:
http://www.sega-16.com/forum/showthread ... ead/page29

They didn't even bother to actually download it. There isn't even a version of the demo that had slowdown issues in the first place, or a version that had "only 2 guys, 3 bullets and 1 cloud."

Sega 16.......... home to the biggest assholes in existence. What really sickens me is how they act like they're hardware "experts" or something when, from what I've heard of everyone on there, they know jack shit except how to spread hate. (that website has definitely gotten itself a reputation.) It astonishes me how one person says something like that and everyone goes along with it. If you notice in there thread, they make fun of the fact that the SNES would "run Gunstar Heroes at half the frame rate." but totally disregard the fact that the "mode 7" demo in pier solar or whatever only runs at 12 frames per second, which at that point, you might as well be drawing polygons onscreen. I already know that the demo only uses 16 colors to draw the texture, so its not even as useful. (It appears to use a second background for the cloud reflection though). My theory about the Genesis extremists on that site is that when they were young, they wanted a SNES, but got a Genesis though and tried to convince themselves that they got the more powerful system, despite there being nothing that supports this. Lastly, I love how they say the SNES couldn't handle black apple because it wouldn't run at the same frame rate (my ass, half of the background is repetitive tiles and you have window layers) but again, could care less that the mode 7 demo runs a 12 fps. (I guess framerate only matters on the SNES. ) It's also kind of funny that there so called "movie" runs in straight black and white because it would take to much time to transfer the tiles and that it would end up looking like utter garbage using 64 colors (It probably wouldn't even be doing that because of the fact the BG is 4bpp) out of a 512 master palette.

Sorry about my rant there. It's just that people like them actually make me hate playing my Genesis.

Edit: Oh yeah, there is no way they tried you're Gunstar Heroes demo. (There too much of stubborn jackasses.) I actually think it would be cool if somebody did port Gunstar Heroes to the SNES and actually improve it graphically by giving sprites their own color palette, (E.g. 16 color explosions) adding BG 3 and even some transparency effects where they can be added just to make them shut up. (They wouldn't even download it though, because they want to live in their fantasy land.)

Edit 2: The best part is, I just noticed I'm wearing a Sonic shirt. Excuse me for my horrible picture taking.

I sense a whole lot of pain in the lower end...

lower end?

That doesn't follow. Yes, the Super FX is a monster at blitting, and decent at multiplication. But that's because it was specifically designed to be really good at 3D rendering. For other tasks, the advantage isn't nearly as great, and relies much more on the simple fact that the Super FX is clocked higher than the S-CPU.


Yeah, see, I was under the impression that it was 23 MHz, so I was comparing it to the full-fledged 21 MHz GSU.

But I still think that comparison makes some sense.

In the first place, it compares the most powerful extant form of both chips (and the Super FX is still cheaper). If you tell me the SVP chip is way more powerful than the Super FX, without specifying versions, that doesn't just tell me the chip in Virtua Racing could significantly improve on Starfox; that's already reasonably evident (though subject to lingering questions re: programming efficiency). It tells me it could significantly improve on Doom or Comanche, which is less clear.

Second, while it's true that the DSP the SVP is based on was supposed to be good to 25 MHz (at least by 1996 when that datasheet was put out), the existing version resulted in a $100+ cartridge with a heat sink, so I'm not sure how much headroom there actually was for clocking up...


Speaking of which, how's that Bad Apple demo going?

Also, where's that "55% speed" thing from? Did Vector (who seems to be the bulk of the problem on that thread) make that up out of thin air? I don't see any significant speed difference between your demo and the real thing...


[*cough*]

Correct! I am! I honestly don't have anything against the Genesis (like I said, I own one) but those people make me crazy. Also, about that vector guy, it seems like quite a bit of people there actually agreed with him though, like Kamahl.

I had difficulty programming the compression encoder, since I am not used to high level languages.

I did notice that it can be compressed a lot, just by doing RLE on 8x1 slivers in a vertical direction. Using per pixel LZSS looks a bit overkill to me.

I hate the Bad Apple demo from Stef, it's the most publicized one despite the fact it isn't the best =/ Let's start with the fact that it requires a special memory arrangement that doesn't work with the Mega CD attached at all due to bus conflicts and that isn't guaranteed to work on every system. Then there's the fact that everybody forgets MtChocolate's demo (that video is from the first revision, there were six) which is the one that sparked the whole thing about everybody trying to get Bad Apple on the Mega Drive and which fits in 4MB just fine, and then there's also this one which has better quality (full resolution) and framerate (30FPS!) than both of those, and also fits in 4MB (in fact only 3MB are used for video), yet everybody seems to forget that it exists.

So yeaaaaah...

Also if you think Sega-16 is bad just for that, don't forget how they seem to think that Project MD is the best thing since sliced bread despite the fact I told them that pretty much nearly every platformer on the NES (not even the same generation) is much better.


The heatsink isn't there in the Japanese version (in fact the SVP barely becomes warm as far as I know), it's there just to make the FCC happy because they wanted RF shielding (and somebody probably figured it'd make a good heatsink as well). Also from what I recall Star Fox wasn't exactly that cheap either, and originally the idea was to add the SVP to other games (Zaxxon Motherbase started as a SVP game, for instance). The problem is that later Sega decided that the 32X would be a better idea (yeah, in the long term you'd just pay once for the extra hardware... but it came out the same year as the 5th generation consoles).

I see. Are you still working on it, or have you given up?

I'd offer to help, but (a) I'm already swamped, and (b) I'm probably the wrong guy for the job...


Huh. I vaguely recall hearing about that, but I wasn't sure. Then I happened across an article that explained how to replace the old thermal paste so the thing would still work, and I assumed I must have misremembered...


It wasn't noticeably more expensive than a normal game from what I recall, maybe $10 extra or something like that. Big titles like Final Fantasy III and Earthbound cost more.

Is this by any chance? It seems to assume that it's bad just because it's old without even realizing that the Japanese cartridges don't even have the heatsink (and of course this is all before even trying the cartridge for starters).

I have a Japanese cartridge (which I bought for $9 by pure luck XD) but I have absolutely no idea how to open it (nor where to get the relevant screwdriver) so I can't take a pic right now =/

Didn't the 68000 in the Genesis also have a heat sink? I'm not sure why, because the thing doesn't even generate half a degree of heat. (I think Sega might just be addicted to heat sinks. )

Edit: Is this project MD?If the gameplay is as lackluster as the title and the artwork I've seen, then I think I might stay away.

Edit 2: Wait a minute, did you make the game Sik? Didn't you just criticize it a while back?

It's a very good homebrew game with cool ideas and very nice music. The art style and game fairness are *slight* letdowns, however.

The only heatsink in MD is for the voltage regulator(s). 68K does get warm, but VDP gets much warmer. The later CMOS based units stay nearly cold and also suck much less power.

What would that be? I own a model 2 Genesis and it doesn't get warm at all. (I am feeling the vents on it.)

MD1 VA7 is full CMOS, and so are all MD2s. Some MD1 VA5/6 boards have a CMOS CPU but the rest is still NMOS based.

That's the one. I assumed he had a good reason for what he was doing, but apparently not...

I can understand you prefer the 4 MB version and honestly i would have preferred to make it fit in 4 MB but it wasn't possible to maintain 30 FPS decompression in this case so i had to simplify the codec (and make the rom bigger). I think also you're forgetting a very important point of the 8 MB version of the demo i made: the video codec is lossless. With a lossy codec as the one used in the 4 MB version it's much more easier to get things done. Honestly i was not interested in lossy compression if you can see it and that is very the case here :p

Ho and yeah, i am referring the MtChocolate version right at the beginning of the video description

Yeah, but nearly everybody forgets that one exists =/

I spoke about it many time when i developed my version, i also like how he used speech synthesis in version 6 for the music, awesome !
But anyway, i think that if the 8 MB is that popular it's just because the video is real full resolution without any loss in quality, also sound is pretty descent so you really have the feeling to watch the original video. The 4MB version which uses full resolution has (imo) heavy compression artifacts, maybe with a better encoder it could be less noticeable.

I was bored yesterday night so started the "ASM optimizations" page on wiki.superfamicom.org, and went nuts ranting about programmers who write 65816 code, like they're writing 68000 microcode.

You mean this page? I just edited it to incorporate the example we gave here of how a particular 68000-oid code fragment might be optimized.

Excuse me? Is a homebrew game and you are talking about the work of other people , a bit more of respect will be apreciated.
Also , in my opinion , It looks really good , a lovely well made homebrew platformer

I don't think Espozo meant any disrespected here, just stated his opinion. I also think sik got tierd
of working on it since people said stuff like "really good", "lovely" e.t.c. too much.

I wouldn't say 68k so much, as just a processor that's not Accumulator based. But stuff like that wreaks of macros. Yeah, they might be slow, but lets be honest here - 65x source code gets a bit too expanded and affects the readability. Macros clean this up and make things easily readable/understandable/compact/etc, as well as some other benefits. They waste a little space and waste some cycles, but if the code is in a non critical area - then no harm no foul. I mean, if the example you posted only represents about 0.1% cycle usage per frame - then does it really matter? I would be more concerned with how they optimize high level stuff to function faster on the processor's design (the organization/layout of data, how it can be accessed, etc); how it can be tailored or tweaked to function faster on this specific ISA. As a developer, I'd probably only start cycle counting on code/loops/etc that have a real impact.

I used to think similar; why did developers write crappy or unoptimized code - when they could have easily done this or that. But I came to realize, developers had different priorities and constraints. As a homebrewer or hacker, I have the time and dedication to highly optimize my code. I'm not so much worrying about deadlines, or that the game design more take a drastic internal design change that negates my previous optimizations. And even if those designs did change, I have the time to easily re-optimize.

In my opinion, this is where the real difference lays between the 68k and the 65x ISA. While you can theoretically highly optimize both, the median performance of average code will almost always perform better on the 68k; you get really nice performance for no optimization .

On a side note to this, it seems developers were way more opt to optimize for graphics than optimizing cycle counts/code. Visuals just have more of an impact; more bang for the buck. Well, at least with Japanese developers. Euro developers at the time, seemed to be concerned with both - they just lacked in game design (IMO).

Well, not all homebrew games are good.


While I agree that there are more constructive ways to give feedback, sometimes we do dislike things in a more intense way, and feel the need to express that more harshly. Everything is someone's work, does that mean we can never pull an "Angry Video Game Nerd"?


My personal opinion is that it's a very well programmed game, it's very solid at the technical level, but the gameplay isn't particularly exciting, and the art... well, it looks like "programmer art" most of the time (very simplistic and lacking a consistent style).

Portal had N64-caliber graphics before it got picked up by Valve. Sometimes you have to prove the concept before you can hire artists.

Off course I am. Even shitty LJN video games were made by people. (As in not by something like aliens or chimpanzees. ) The thing is, you shouldn't always be all lovey-dovey with people if you see flaws in their work because frankly, you're lying by telling them that their work doesn't need improvement. I think any sensible/respectable person can understand that their work is necessarily going to be 100% perfect, especially without any insight as to what is wrong.


I agree 100%. I feel like one of the main problems with homebrew games is the artwork. (You certainty won't see anything Metal Slug quality.) I feel like that maybe with homebrew projects, people should work together more often in order to bounce ideas off each other and help each other to make a more commercial-quality games.

LJN games may in fact have been made by chimpanzees. We're still not sure. AVGN definitely isn't sure.

Ha!

...and by "no optimizations", you mean "no intentional optimizations" because programmers were so used to programming the 68000, they make tons of optimizations without actually thinking about it. Kind've like how I'm so used to programming the 65816, I don't even have to think about optimization when I'm writing code.

Like using registers to hold constants being used more than 2 times. 68000 coders just get into the habit of storing repeatedly use constants in registers, so they don't even need to think about it.