Hello everyone. I have been looking for a while now and have not been able to find much info on nes dev hardware / software. I came across a video somewhere that had some "behind the scenes" footage of someone working on mario bros 3. They were at some sort of computer and moving mario's sprite around and changing some level features in real time. For the life of me I can not find this video again, or anything like it. I was trying to figure out what kind of computer they were using. Not only that but what kind of dev software. I would love to know about some of the features. My other question is this...in the SNES days were pretty much all commercial games done in ASM or did nintendo provide some kind of C style language that could be used? Was there some sort of environment with custom header files to speed up development. So if anyone can entertain my query, that would be super. I would love to see some pics of old NES dev hardware or behind the scenes pics of developers at work. Same for the SNES. We have all seen some SNES Dev hardware floating around, but I would like to know about the software that was used to make the games. Thanks in advance. I hope I don't sound like a total retard, but I have searched quite a bit and have come up with very little.
Development stuff provided by Nintendo was just documents on the hardware, Assemblers for the CPUs, and maybe Cartridge Emulators. There was no magic C programming with libraries to take care of things for you. Developers could get a C compiler for their games if they wanted to and used that but atleast at the time C was very poor performing on the NES and SNES CPUs. Some games were developed in C I've heard, like strategy games by Koei are usually cited as such. But probably 99% of NES and SNES commercial games were developed in ASM. There really isn't much to either system and today you have access to the tools and information as good as if not better than developers back then had.
I was just curious. I was blown away when it seemed they were doing some sort of real time editing in the video I came across. I guess maybe they were just using some sort of level editor they wrote for super Mario bros 3 to speed up development time. If I had to guess they were using some kind of 8bit computer with a 6502. Maybe they had some custom apple hardware with a custom NES PPU add on. I had to ask, because my mind was racing. I was reading an older special issue of retro gamer before I went into to surgery yesterday, there was a great read about the development of Golden Eye for the N64. They actually started to work on it before they had a Dev unit or even full specs of the N64. So they just used a SGI computer and guessed at it. I guess they made whatever changes were needed later. I thought that was really cool. A few years back I got a copy of the manual and toolchain stuff for the NDS. I guess development on the newer systems is a bit more modern and streamlined. Thanks for not scoffing at my stupid question. I am new to all this stuff. I love this site. There are some really smart people here and a lot of cool Dev hardware pr0n. Thanks again everyone....
Nintendo would have used PC-98s throughout the FC's lifecycle, and the majority of SFC's. With ROM emulators you can edit and update character tiles in real-time on the console. With in-circuit emulators or debug monitors linked to the game (and some scripting) it's possible to update the tile map on the console as well.
I think Super Metroid actually contains some sort of editors which attempt to write to ROM. There was something about it on TCRF, http://tcrf.net/Super_Metroid
As far as I understand 2500A.D. was the 6502 assembler of choice at the time, whereas SNASM or SASML or whatever was the 65816 one. I have both but I haven't messed with them as they're most likely DOS apps and I don't really care to set up a DOS environment at this time
Perhaps for some Western third-party developers (same with TASM and DASM), but certainly neither assembler would have been very attractive to Nintendo. For one, 2500 AD seems to have came along after the FC, and SNASM came along after the SFC. Two, Japanese companies tend to like Japanese language software, and Nintendo is competent enough to write a few assemblers in house.
You don't really need libraries or a SDK for the SNES. Everything you can ever hope to do is hardwired and defined by hardware IO registers. The CPU itself is too slow to do anything in software, so all SNES programming really amounts to is enabling/disabling hardware flags, using DMA to shuffle data between ROM and sound/display RAM, checking inputs, and some basic AI and collision detection. C and libraries would only get in the way.
Too slow to do anything? Many games utilize software graphics compression, not in real time ofcourse. But you are right that there is no real point for any libraries or SDK. The most helpful things would be a solid Sound Engine with music and sound effects tools. Other than that anything else should be able to be programmed by any game programmer that can figure out assembly programming.
SNES use SFBOX II to development in japan they use PC98 to host computer SFBOX II have 2 ver, one is debugger w/16MB EMU, another one is for mastering , some people say it support burn EMU data to ROM , but SFBOX II not support all DSP , so final they make more 1 SA-1 with rom emu. btw, early SFC CD_ROM the design also target install on SFBOXII
That's beautiful I've never seen that top part of the unit. Anyway, the SNES would benefit from "libraries" in the sense of pre-compiled utility subroutines pointed to by an assembly file and included on final assembly or just an assembly file with helper routines and what-not. The same could be said about sound drivers too. GEMS and SMPS (which I have never seen official code released of btw ) are both (in the case of SMPS I am assuming) pre-compiled code that is inserted with certain defines somewhere in code and, with the help of a header, used like any other library you would find in any coding language. The SNES probably couldn't handle C in it's ideal form, but one probably could build an interpreting compiler that converts C into it's analogues assembly using pre-coded subroutines inserted once in the code.
