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

[bazz]

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

[Drew Sebastino]

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. )

[bazz]

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.

[Drew Sebastino]

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.

[bazz]

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

[Drew Sebastino]

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...

There really isn't much here at the moment.

You may be looking for this:
SNES Hardware + Peripherals Wiki

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.

[koitsu]

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.

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.

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.

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).

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

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. :-)

Lastly, what the heck is this? I'm guessing C?
printf("$%04X", address)

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.

[Kannagi]

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.

[tepples]

The other thing that I think gets my frustrated is how the SNES was made. [...] I do always hear people complain about the CPU speed

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.

and that leads to one question... Why didn't Nintendo overclock it?

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.

I'm no hardware expert, but I always thought you could keep increasing CPU speed until the CPU melted

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).

Heck, isn't the SA-1 just a 65c816 running at 10 megahertz? If it is, that just shows it can be done.

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.

most of the tutorials [at superfamicom.org] 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.

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.

[Drew Sebastino]

Espozo wrote:The other thing that I think gets my frustrated is how the SNES was made. [...] I do always hear people complain about the CPU speedIf 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.

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.)

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.

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

Video game consoles introduced at 599 US Dollars tend not to sell 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?

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.

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.)

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

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.

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.

[tepples]

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.

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.

(After all, It's a video game console, not a calculator. )

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

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?

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.

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.)

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.

I honestly thought you were referring to the Neo Geo (Didn't that actually go for $700 though?)

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.

Personally, I think I would have liked the GBA more if it were a home console

Buy a GameCube and a Game Boy Player.

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.

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.

I'd love to see how fast computers would run if everything were still written in ASM.

Go try MenuetOS.

[psycopathicteen]

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.

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.

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.

[Shonumi]

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.

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.

[Drew Sebastino]

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.

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.

I honestly thought you were referring to the Neo Geo (Didn't that actually go for $700 though?)

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.

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)

Personally, I think I would have liked the GBA more if it were a home console

Buy a GameCube and a Game Boy Player.

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. )

[bazz]

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..