Must all NES and SMS games be programmed in assembly language?

[5233]

I'm wondering because it would be cool to see new releases built from the ground up for either system. I just want to know how hard it would be to do that, and if you can only program for it in ASM.

[tomaitheous]

In my experience, the 65x 8bit family of processors (NES) don't work great in C. Such processors get their speed from hand optimized Assembly. Not sure how well the z80 handles C, but imagine it's the same situation (I've only used Assembly with z80 variants).

As far are dev, NES has an active scene -> http://nesdev.parodius.com/bbs/

[TmEE]

You want to use ASM when you're going to do something serious... you can get away with C if you'll just be doing some stuff requiring no real performance (like a board game).

Z80 has very pleasant ASM, beats the crap out of pre-386 ASM easily, cannot really comment on 6502 and alikes, but all my friends except Tomaitheous hate it :P

[sasuke]

I've tried both Z80 and 6502. I could say that the 6502 could be more C friendly than the Z80, since its index registers can act as an entry in an array.
I'd say I prefer the Z80 mostly for its multiple registers (6502 only has 3 general purpose ones, Z80 has around 7, 11 if you count the index registers) and syntax. I like the 6502's "zero page" addressing and the index registers, though.
I you want a really difficult processor to program for, try the 65816. :?

[dragonboy]

I you want a really difficult processor to program for, try the 65816.

It's funny how MOS-technology created the 6502 to be the simplest easiest cleanest chip design ever, but the WDC who later got the rights to the 6502, created the 65816 to be the 16-bit successor to the 6502, but ironically made it the most complicated, confusing, and dirtiest cpu archetecture ever. Somebody obviously did not get the point.

The 6809 is a perfect example of what the the 65816 should have been.


A little bit off topic. So I've been reading other programming threads on other forums and it made me wonder, am I the only programmer who doesn't push and pull every register on and off the stack in all the subroutines I use? It just looks like a total waste of time to me.

[tomaitheous]

A little bit off topic. So I've been reading other programming threads on other forums and it made me wonder, am I the only programmer who doesn't push and pull every register on and off the stack in all the subroutines I use? It just looks like a total waste of time to me.

On 65x series, I almost never use the stack. There's no real reason too. Especially speed wise. Well, with the exception of interrupt handlers. On the 68k, I use the stack more often. Still not a lot though. Depends on the subroutine and what code is calling it.

[dragonboy]

I'm wondering is it possible to create high-level languages specifically optimized around individual cpus so that the cpu can run something higher than assembly yet wouldn't be as slow as C or BASIC.

[GriskaGyoran]

I'm wondering is it possible to create high-level languages specifically optimized around individual cpus so that the cpu can run something higher than assembly yet wouldn't be as slow as C or BASIC.

FORTRAN? Then again mostly used for large computing like for genome and whatnot.

[Chilly Willy]

http://www.cc65.org/

C compiler for the 6502, with library support for the NES among other systems. :cool:

It's not a FULL C compiler... more like Small C with extensions, but it's not assembly.

I love both the 6502 and the Z80. They're completely different, but both have their pros and cons. And I've never pushed all registers just for the hell of it. Look at my 68000 code in Wolf32X and you'll see I push as few registers as possible. The idea is to write your subroutines to use registers you KNOW are free at the time so that you don't have to push the registers. That makes your code much faster, but more prone to bugs if you don't keep track of your register usage.

[tomaitheous]

I worked on HuC for a few years on and off. Digging through the library code, compiler source, etc.

It's a Small C compiler for PCE, but was built from an open source Small C compiler floating around on the net (the date of the original source was 1984, IIRC). I suspect that its origins are the same as CC65. Which, IIRC, CC65 is an upgrade from the original Atari Small C compiter.

Anyway, working with HuC is/was frustrating. Not that I use the language personally, but I was trying to get some speed out of it so more down to earth/less serious hobbyist programmers would use it. The nice thing is that the library is in ASM, and with a pragma fastcall setup - was able to write my own extensions to the lib. The other nice thing about pragma function setup was that I had full control about how the arguments were passed (registers,zp,etc) - and that I could do argument overloading. I.e. same function name but with different number of arguments. I was able to add support for additional hardware and/or more effective hardware interfacing. The biggest downside to HuC (besides the lack of a real optimizer) is that it's crippled for any type of array (const pointer) access. It treats it as far data and that macro for fardata read/writing is insanely slow. Even static mapped near data. That's the insane part. That's pretty much makes HuC almost worthless for anything approaching a moderately serious project.

I'm not sure how CC65 is in comparison, but I no doubt assume that it's better. Considering it has a much larger user base, support group, crosses multiple platforms. Anyway, that's my experience with a high level language for 65x. I like C quite a bit. I use it for PC all the time. But ASM is where my heart is. And I dread using C for consoles with such CPUs. I can see using C for 68000 consoles, but why when assembly is just soo much more fun ;)

[Chilly Willy]

Yeah, I can't see using anything but assembly on an 8 bit CPU. Even old BASIC games on 8 bit systems like the Atari used lots of assembly user subroutines for speed. Also, hand-made assembly can't be beat for size.

I had Deep Blue C for the Atari years back when I was still programming on it, but I can count the number of times I actually used it on one hand. :)

[dragonboy]

What I'm wondering is how did programmers keep up with their own scheduel. This week I've been working on the jump/fall/tilecollision part of my game, and everytime I do it, it malfunctions in some new way.

Take a look at this:

[tomaitheous]

Funny thing, just saw this posted over at SMSpower -> http://www.z88dk.org/forum/ . C compiler for Z80.


What I'm wondering is how did programmers keep up with their own scheduel. This week I've been working on the jump/fall/tilecollision part of my game, and everytime I do it, it malfunctions in some new way.

Hehe. The joys of annoying bugs squashing. Once you've got it working though, building completely new engines/routines that still have similar/related requirements, becomes much easier. I.e improving/expanding upon it or modifying the requirements, etc.

[Chilly Willy]

Funny thing, just saw this posted over at SMSpower -> http://www.z88dk.org/forum/ . C compiler for Z80.

Nifty, but not much use on the Genesis with only 8K of RAM for the Z80. I suppose you COULD make 32K of code in the ROM and set the bank to it, but the Z80 would have to contend with the 68000 for bus cycles while executing the code.

Still, if all you wanted was a Z80 program in C, you could use the MD as a test bed that way.

[tomaitheous]

Nifty, but not much use on the Genesis with only 8K of RAM for the Z80. I suppose you COULD make 32K of code in the ROM and set the bank to it, but the Z80 would have to contend with the 68000 for bus cycles while executing the code.

Still, if all you wanted was a Z80 program in C, you could use the MD as a test bed that way.

Yeah, definitely wouldn't use it for MD. Would be fun to mess around with for a SMS project. Actually, if this compiler is efficient enough - I'm hoping this brings some attention to the SMS coding scene. SMS graphics are pretty easy to work with and easier (than say NES), and pairing that with this compiler would be a great asset for the SMS dev scene. Here's hoping ;)

On a side note, I keep forgetting that I can do SMS dev with my Genesis consoles. I'd want to do an SMS dev project sometime in the near future.

[Chilly Willy]

Yeah, definitely wouldn't use it for MD. Would be fun to mess around with for a SMS project. Actually, if this compiler is efficient enough - I'm hoping this brings some attention to the SMS coding scene. SMS graphics are pretty easy to work with and easier (than say NES), and pairing that with this compiler would be a great asset for the SMS dev scene. Here's hoping ;)

On a side note, I keep forgetting that I can do SMS dev with my Genesis consoles. I'd want to do an SMS dev project sometime in the near future.

Actually, with the NeoMyth, you really CAN use your MD for SMS development now. :D

Maybe we can put together a devkit with zasm for the assembler, z88dk for the compiler, and some library functions like Stef's, but geared toward the SMS.

I need a good tech file for the SMS - beyond having the Z80, a VDP similar to the MD, and the PSG (and a different FM chip on the Jap model), I really don't have much of an idea how the SMS operates.

EDIT: Found lots of good docs over at SMSPower. I noticed TmEE is over there as well. :D

[dragonboy]

Funny thing, just saw this posted over at SMSpower -> http://www.z88dk.org/forum/ . C compiler for Z80.



Hehe. The joys of annoying bugs squashing. Once you've got it working though, building completely new engines/routines that still have similar/related requirements, becomes much easier. I.e improving/expanding upon it or modifying the requirements, etc.

I found my glitch. I threw the direct page into a place that overlaps the middle of the collision map. I changed the direct page location and now it works properly.

Only issue now is that it uses 8-bit x/y coordinates, and if I want side scrolling in my game I need to reprogram it with 16-bit x/y coordinates, and it doesn't help that Nintendo interweved the 9th x coordinate bits with the size bits, instead of using flat out 16-bit x/y coordinate registers like the Genesis has.

[dragonboy]

To be completely honest, I don't really like programming. In fact I hate it. The only reason why I keep doing it, is so people will respect and beleive me.

The current status of homebrewing websites like smwcentral.net is horrible. The majority of people on that website think they are the "uber" programmers and they don't share their code library with anyone, and they'll call you an idiot if you ask them.

Then there is smkdan, who everyone keeps beleiving is the god of all snes programming knowledge, when all of the assembly code I've seen him post is disgustingly redundant and slow.

For example smkdan says if you want to move 32-bit data from $0000,x to $0000,y, you do this

lda $0000,x
sta $0000,y
inx
inx
iny
iny
lda $0000,x
sta $0000,y
when I know that you can just do

lda $0000,x
sta $0000,y
lda $0002,x
sta $0002,y
and save 8 cycles, but when I correct his mistakes, everybody asks me to "prove" myself, but they blindly accepts smkdan's code as the truth eventhough I never see him making some kind of stupid demo for everything he says.

[Knuckle Duster]

To be completely honest, I don't really like programming. In fact I hate it. The only reason why I keep doing it, is so people will respect and beleive me.

The current status of homebrewing websites like smwcentral.net is horrible. The majority of people on that website think they are the "uber" programmers and they don't share their code library with anyone, and they'll call you an idiot if you ask them.

Then there is smkdan, who everyone keeps beleiving is the god of all snes programming knowledge, when all of the assembly code I've seen him post is disgustingly redundant and slow.

For example smkdan says if you want to move 32-bit data from $0000,x to $0000,y, you do this

when I know that you can just do

and save 8 cycles, but when I correct his mistakes, everybody asks me to "prove" myself, but they blindly accepts smkdan's code as the truth eventhough I never see him making some kind of stupid demo for everything he says.

Easier way to earn respect:
Don't default to 'bitching' about other people or their work when frustrated. ;)

[dragonboy]

When you mean "nice" do you mean sucking up with the common consensus?

[Chilly Willy]

When you mean "nice" do you mean sucking up with the common consensus?

No, but by the same token, when someone does retarded coding, don't say "That's retarded! Here's how someone who ISN'T a retard would do it!"

Until you get a better rep than the people currently posting code, you have to use tact. Say something like "This might be better... can someone else try it and post their findings?"

[tomaitheous]

To be completely honest, I don't really like programming. In fact I hate it. The only reason why I keep doing it, is so people will respect and believe me.

Hehe, you have weird motivations for coding then :) There's a lot of code I do that only a few people see. It's not really for the public. It's not a big deal. Actually, I don't really like to post much of it - because it can be misinterpreted as bragging. It's different when coders get together and look/talk about such things, it doesn't feel like that. It's more of a general excitement and sharing of code/techniques. The possibilities.


The current status of homebrewing websites like smwcentral.net is horrible. The majority of people on that website think they are the "uber" programmers and they don't share their code library with anyone, and they'll call you an idiot if you ask them.

Then there is smkdan, who everyone keeps beleiving is the god of all snes programming knowledge, when all of the assembly code I've seen him post is disgustingly redundant and slow.

Never heard of the guy. There two types of (console) programmers that I tend to see. Those who live on low level (and high level too) optimization (I'm in that category) and those who care more about the game/logic/etc aspect of programming. They might be an expert on interfacing and handling sound/video/etc parts of the hardware, but are not specifically interested in optimizing every little thing. They are more for flexibility than speed. Be it the higher and lower level of the design stages. Maybe he's in the latter bracket.



For example smkdan says if you want to move 32-bit data from $0000,x to $0000,y, you do this

Or use a block transfer instruction/opcode of the '816? To be honest, moving around large chucks of data is so rare in the stuff I do. Moving data to vram is where it's at, but even then.


When you mean "nice" do you mean sucking up with the common consensus?

What Chilly Willy said. Even if you have the rep and know how, you don't want to come off as an asshole like the guys you're complaining about now. One thing to remember; arrogance is rarely, if ever, justifiable. And sadly much too often, seemly tolerated in the world. Is it just me or is it more so in the academic community.

[dragonboy]

Don't blockmoves use 7 cycles per byte? Wouldn't that be 14 cycles per 16-bit word?

[tomaitheous]

Don't blockmoves use 7 cycles per byte? Wouldn't that be 14 cycles per 16-bit word?

Ohh.. Are you talking about a single 32bit move, or moving a block of data that is 32bit elements in size?

Also, got a link to the thread?

[dragonboy]

Another reason why I feel forced to program is the way the Snes is portrayed on the internet.

I was a little kid back then. I use to go to the video store, there were always hundreds of Super Nintendo games lying on the shelves, from all different companies. Naturally I liked Nintendo 1st party games the best, but there were a wide variety of obscure games that I played that I liked.

Nowadays you go lookup Super Nintendo online and what shows up? Overrated "classics" that are now popular just because they were from popular companies such as Capcom and Konami.

What I've been noticing for a long time is, only the popular companies such as Capcom had serious issues with slowdowns in their games. There were tons of overlooked companies that never even had problems with slowdown right from the getgo, but never get any media coverage. However when I was little, I couldn't read the company logo on the cover, so I played tons of obscure games that had not even the slightest bit of slowdown.

For instance, I've rediscovered a long forgotten company called Natsume, that has some extremely underrated games. Pocky and Rocky is a perfect example of the kind of games I used to play as a little kid, and in that game sometimes there are tons of little guys running around and yet it barely ever has slowdown (the very few times it does, it's about 90% the normal speed), unlike similar games from Capcom and Konami. I think Natsume could've did Gunstar Heroes on the Snes if they tried to.