How games were written on Dendy
With this article, I would like to shed some light on how games were created on Dendy. And it will not be about how this can be done now, but how it happened then - in the 80s and 90s, and about what problems the developers faced at that time. If you are bored with reading the latest recollections of managers, designers, or programmers who have retrained as managers who reveal the technical side of things a little less than nothing, then welcome to cat.
Then and now
Nowadays, the development for game consoles is increasingly reminiscent of writing programs for conventional computers, the difference between what was happening then and what today's developer has is enormous. On the one hand, today, technology and the development culture have stepped far forward, allowing development in high-level languages, and on the other hand, in the 80s, companies producing consoles did not fully understand what should be given to third-party developers to create games. And therefore, if now for the next playstation you can get documentation, five demo disks, as well as a powerful development station, in fact a hybrid of the console itself and a general-purpose computer suitable for direct development, for example, in the 80s, many developers were content with a booklet with the specification of the console .
A bit of history
It is believed that the Nintendo Entertainment System (NES) was originally created, with which our Dendy and dozens of other clones around the world were already spiraling.
After looking at the picture, it is clear that this may not be entirely true. Initially, in 1983, the Famicom console was released in Japan. In any case, there were 2 slightly different consoles - NES and Famicom. And the development for them was also carried out by different tools, although the program code for the games in the cartridges was the same for both. The cartridges themselves were somewhat different. In the case of NES, there were several additional contacts on the cartridge, which led to the chip, which in theory should have been only on licensed cartridges ...
Back in 1983, Nintendo could only dream of third-party developers for the newly made console. So the first few games were created by the authors of the console themselves. Some of them were ports of games that already existed on arcade machines. These games were primitive even by the standards of NES, not using all the capabilities of its hardware filling. All games of that starting period fit on one screen and did not occupy more than 32 kilobytes of data on the cartridge. The most famous games of that period: Donkey Kong, Balloon Fighter, Mario Bros. The irony was that NES had special hardware support for scrolling levels, but the very first games were not side scrollers, although they were released by a company that God himself commanded, knowing all the features of their console, to release games,
The limitation on the size of 32 Kb NES games was only the first couple of years. Then third-party developers more or less adapted to the console and realized that 32 kb is not enough for everyone. Seeing this situation, Nintendo decided to make a mapper for all new cartridges, which allowed creating games an order of magnitude larger. Here it should be noted that the NES architecture itself did not change, but cartridges changed, expanding the capabilities of NES itself.
You could put anything on the cartridge - any chips that your heart desires: RAM, video memory, coprocessor, non-volatile memory for saving. Theoretically, you can add things like a modem or raspberry pi to a cartridge. Another thing is that to implement this it will require titanic efforts, as well as several free days off.
The specifications of the NES cartridge can still be found on the Internet, and, in general, are pretty detailed by the community. But the cartridge production process itself is a mystery covered in darkness. More or less reliably, it is known that in Europe and the USA, Nintendo exclusively engaged in cartridge production. I mean, the boxes themselves with the chips.
The chipset has increased over the years, so we can say that from the point of view of the developer, the specification of the console itself has changed, although the cartridges actually changed. This feature has allowed NES to be popular for so long, competing with other game consoles.
Each developer should explicitly indicate in the header of the compiled game (ROM) the list of NES functions that will be used by the game. Some functions were supported by “ordinary” cartridges - for example, a memory mapper, but Nintendo had to pay extra for saving or extra RAM to include the coveted chips in your future cartridge.
In Japan, there were companies that themselves were engaged in the manufacture of cartridges, simultaneously adding to them their own unique chips, created for one specific game. Subsequently, such things in themselves ate a lot of nerve cells in those who created NES emulators, trying to get such games to work in their brainchild.
The architecture of the cartridges implied that the program itself and graphic sprites are in different chips. Here's an example photo of a Super Mario Bros cartridge.
In those cartridges that were sold with us, such chips were usually used only in those that came with the console, and that is not always the case. The pirate cartridges used black blots instead of chips, most likely they were the same circuits, but made using a different technology. For what? I think in the comments you will find the answer to this question.
Information about the official Nintendo SDK is very scarce, so much so that I am already inclined to believe that it simply did not exist. Those. there are a couple of photographs of such units on the network, but nowhere is it said that they were released by Nintendo, moreover, their appearance suggests that they were most likely crafts of the final developers. So all that was available was specifications, and then each developer spun as best he could. Home-made development equipment was divided into 2 classes: modified cartridges with rewritable data banks and debugging stations.
In the first case, everything is relatively simple - in a conventional cartridge, data banks and graphics were replaced with similar chips with the possibility of rewriting overwritten. This is not to say that development with such a tool pleased - after each recompilation, the cartridge had to be re-flashed. And yes, despite the small volume of programs, the firmware speed was low, given the equipment and power of computers of that time. Nevertheless, this device in several copies was the same and often the only tool of the programmer.
In the case of RAM cartridges, development was much faster. It was possible to edit the memory directly during the game, using for this a computer, on which, in fact, the development was carried out. The EEPROM chip was replaced with memory banks, which on the one hand were seen by the console as a regular cartridge, and on the other hand, they were connected to the developer's computer and were for it normal RAM ... or a disk ... or a device - it all depended on which driver the programmer wrote for his brainchild.
The most stubborn or successful developers could boast of debugging stations - modified NES, which, in addition to all the advantages of RAM cartridges, also made it possible to conduct deep debugging by looking at the contents of video memory, processor registers, etc. For example, one such station.
On which computers the development took place is unknown, but given the level of fuss with the radio components that was required to run the debug version of the game on the console, the computer model did not have much significance. It is well known that Japanese developers used MSX computers . With a high degree of probability, we can say that Apple 2 computers were used in the USA, due to the fact that they were quite common, and also had a processor similar to that used in NES.
The main and almost the only programming language used to develop games is assembler, some lucky ones wrote in C if they could get the compiler. But even in this case, some companies did not buy assembler from Nintendo but wrote their own. It was hard to say why it was called, but many sources say that in the first years of its existence, NES Nintendo did not share its tools with third-party developers.
The processor that was used in NES also existed in computers like Apple 2 or Commodore 64, for which there were assemblers and even C compilers. But the NES architecture still had some differences, and wild system limitations and banking (the need to unload old and loading new pieces of program code into the area accessible to the processor) did not allow writing C games that would use the maximum capabilities of the console.
Assembler is far from the only thing that had to be written manually: graphics editors, programmers, debuggers: all this was written several times by the caring hands of programmers. Map editors can be considered a separate article - it should be remembered that computers were weak and hardly remembered, so, for example, the entire map for Metroid was drawn manually on paper, and then it was encoded into pieces in pieces by the game.
The developers often recruited yesterday's students who did not see NES in the eye. For the lion's share of small companies creating games the term “sharashkina office” was the best suited. A typical game took 3-6 months of development time. Teams were most often small - 3-10 people. There were many offices that released 1 game and then disappeared without a trace.
The development process usually began with the creation of development tools. Although the concept of the game by that time was already ready. In general, in the early years, many games for NES were ports from arcade machines. Even if the game itself had not yet been programmed, the composer and artist took up the matter. Almost all the music and all the graphics for the Dendiv games were not made on a computer.
At first, the designer drew sketches of backgrounds and characters, then, after selecting suitable pictures, the so-called pixelation began - the NES palette supported only 14 colors on the screen at a time, so I had to redraw the pictures in view of this limitation. Then the drawing was drawn on the grid, and if necessary it was stretched or compressed - NES hardware supported 8x8 pixel sprites. The character of Mario was drawn in 4 passes, after eating the mushroom - in 8 passes. A trifle, but sometimes due to its ignoring, we saw disappearing sprites in some games, when a lot of enemies became on the screen, so programmers had to save on matches. By the way, there were 2 types of video memory - one in which character sprites and other small things were usually stored, the second, in which more level cards were stored.
The work of the composer flowed smoothly into the work of a programmer - writing music is only part of the story, encoding it into a game is also a matter of gain, but then the fun began. As mentioned above, sometimes the game slowed down, so if in the pre-release such brakes reached unprecedented levels, the composer was given the task of “optimizing” the music - removing unnecessary opcodes to speed up the game as a whole. It was then that revealed the true skill of the composer. An extra coin was added to the composer's bank of shame by the fact that far from always a movie game developer was licensed to ... use music from a film. Thus, composers had to write something original, and not always good.
Among the games for NES, the so-called repackage was common - this is when on the basis of one game they do the other by changing sprites and levels, sometimes slightly changing the gameplay itself. For example, Castlevania and Ninja Gaiden are made on the same engine, as well as Darkwing Duck was made on the basis of the engine for the Megaman (Rockman) series of games. We can only guess what the true extent of the repack was, especially considering the fact that a huge percentage of dandy games are the same type of side scrollers.
As already mentioned, many of them were yesterday’s students. There were many architectures at that time, so knowledge of at least some assembler was often enough to be hired. A large stream of frames migrated from the cohort of programmers of arcade game machines. The latter are very easy to distinguish from the interview - they always try to justify the systemic limitations of NES that they encountered after changing the platform. And the truth is - NES was not created at the cutting edge of the technology of its time, it was inferior to the hardware that was put in slot machines. But it cost less money to customers and more frustration to programmers. A good explanation of the limitations of NES from the point of view of the end programmer can be seen in this video: http://www.youtube.com/watch?v=Hvx4xXhZMrU .
Of course, I was interested in what exactly the developers did in those days, but alas, this very question remained unanswered. Programmers do not remember a damn thing about that period. Those. they remember some organizational moments, difficulties that arose in the team, how they ate pizza on weekends, how they hastily looked for a programmer for NES to pay off their debts, but they could not name the brand of computer they spent sleepless nights at. And in general, we can say that their work was perceived as a routine, they did not have the feeling that they create great things that will remain in the memory of a multimillion generation for life.
Only then, years later, they began to understand the significance of what they wrote. And then they became really ashamed. They could be understood - the zoo of consoles of that time, the slurredness of their future, micromanagement in development - all this created the impression that you were writing something incomprehensible, incomprehensible for what, and it was not clear with what prospects.
Among the companies, as already mentioned above, there were many one-day trips - like the ones that now write games for iPhones that have tried themselves in this market, went bankrupt, and went into oblivion. A huge number of Dendiv roms do not contain any information about the developers, which indicates a very low assessment of the results of their work by programmers.
Surprisingly, there were those who still continue to develop games, even after 30 years. They can be found in social networks, but after the second dozen attempts to reach at least one of them failed, I quit this useless activity. However, a list of the names of developers that I managed to tear out from the most extensive collection of roms is here .
Nowadays, a lot of people write games for NES, but that's not the case at all - 99% program their examples exclusively for the emulator, without thinking about creating cartridges. Even not, it’s better this way: today, programmers have emulators with a built-in debugger, ready-made macro assemblers and C compilers, a number of sprite and music editors created by the community. The nesdev.com website contains everything to do this painstaking work yourself. Or at least it’s worth looking at the Wiki section of this site to find out how much you did not know about Dandy.
So today any student can write a game for Dandy who has written, but not bought, the code for his laboratory in the subject devoted to microcontroller programming.
Judging by the fragmentary information that it was possible to obtain about the development of that era, nothing has changed in almost 30 years. And the process of creating games on the Dandy in 1985 differs little from the creation of casual toys for smartphones today. If someone has more detailed information, then I will be happy to add it to the article. You can also google and ask programmers from the list, maybe luck will smile more for you. And if God forbid, you are riveting toys for an iPhone, PSP, or a variety of tablets now - keep a diary, after 20 years someone will definitely need it.