- For making cartridges of your Super NES games, see Reproduction.
Here you have a nice tutorial about compiler design :
https://www.tutorialspoint.com/compiler ... /index.htm
You can see how far is the intermediate code generation in the process, it's why it's interesting to only consider that last step of intermediate code to target code translation if possible.
Code: Select all
Step 5: Allocate variables to A, X and Y a = b | c d = a & e gets rewritten as A = b | c // A = a a = A // A = a A = A & e // A = d d = A // A = d a = b | c b = b + d d = a & e gets rewritten as X = b // X = b A = X | c // A = a, X = b Y = A // A = a, X = b, Y = a A = X + d // A = b, Y = a b = A // A = b, Y = a A = Y & e // A = d, Y = a d = A // A = d, Y = a a = Y // A = d, Y = a
Most people on the internet do.What!? Who says this? Like many Japanese companies; great game design, mediocre code efficiency (speed) at best.Everybody says Konami has well-optimized assembly
Some time ago I decided I wanted to learn Super Nintendo development. I managed to write 12 small programs, for example one for changing the background color, and another one for moving a sprite. I learned a lot from repeatedly reading documentation found on the web. I tested my programs on an emulator ('higan' if I remember correctly). I wanted to test them on real hardware, so I obtained a back-up device outfitted with a floppy drive emulator. Unfortunately about half of my programs did not work on real hardware. I obtained an official development kit hoping it would help me debug, but its power supply is broken and I've been too lazy to get that fixed. And even then, I'd have to get an ancient computer with Japanse software to interface with the unit, so I have all but given up on the dream of debugging my code on real hardware.
Anyway, here's the code, the documentation I wrote as I was developing and learning how the Super Nintendo works, and the slides for a presentation I once gave on the topic.
The code is for the WLA assembler, and I've added some library code for init, registers and some constants, just to make the example code more readable. I was about to write a sprite tool but then I lost interest ¯\_(ツ)_/¯
I still think the Super Nintendo is an awesome console, but not because of its system design; the games I played on it when I was young were my main inspiration.
Good luck with any endeavours in this space, I think you guys are amazing!
Maybe these products didn't exist when you were doing your dev work, but it's a little surprising you didn't consider the SD2SNES, SNES PowerPak, Super EverDrive -- especially considering how much pain you must have gone through to try and get an official devkit + hardware.michielvoo wrote:I wanted to test them on real hardware, so I obtained a back-up device outfitted with a floppy drive emulator. Unfortunately about half of my programs did not work on real hardware. I obtained an official development kit hoping it would help me debug, but its power supply is broken and I've been too lazy to get that fixed. And even then, I'd have to get an ancient computer with Japanse software to interface with the unit, so I have all but given up on the dream of debugging my code on real hardware.
Thanks for putting your stuff online!
With regards to NES and my nominal C64/128 development the SNES is relatively as so
NES : stuck is a desert with a small canteen and a walking stick
C64 : travelling through the dessert with a well stocked camel caravan and a compass.
C128 : travelling through the dessert with a well stocked camel caravan, a compass, a large water reserve and a motorbike to scout with.
SNES : living it up in *****s at the Hanging Gardens of Babylon eating grapes and drinking wine with a fan-boy to keep you cool.
we are all suffers of the 6502, the 65816 is a lovely CPU that fixes most of the issues, makes coding less painful, 2.5~3.5 mhz and 16 bits easy... Hardware Mul and Div to make up for the CPUs lack of operations, happy sigh. It has stack relative commands which helps with C. The ability to move the ZP and Stack allow for making micro threaded entity systems.
Then large number of sprites, 4 moveable planes, windows, colour, palettes, dedicated VRAM, dedicated Sound chip with its own RAM. DMA channels out of our ears... HDMA... 8 button joypad... and then we can drown in ROM...
So why do we waste our time with the NES and C64/128 when we can just live it up on the SNES and make the same game we make now but in half the time?
That leads to the other half of the tale...
Because if we did launch the straight C64/NES game on the SNES we would be laughed at. The SNES has all the toys and the disconcerting customer will demand them all. Just in the way a C64 game these days has to do all the tricks or go home, a SNES game will have to be top of the line... a top of the line SNES game is 5 people and 2 years of work.To which if I'm going to put in that work I might as well use game maker, get it done in 1 year and sell if somewhere I have a hope of making money ( a hope, not a reality ) like Steam. Because there aren't really any publishers for the SNES, you even still call the NES "homebrew", ( do you have NES publishers? )
Lets make a SNES game, is it a platformer, is it as good a SMW? DKC? ok no lets make a shooter, R-type3 Daruis good? JRPGs the SNES was king of those, is Chrono Trigger good, Terranigma, FF6 good? the bar is very high.
However this is 2017 and we have lots of new toys to get the development time down... only the SNES doesn't seem to... I first go into SNES dev on my P133 when Y0shi's doc was the only doc, and it seems if I wanted to do dev now my best bet would be to fire up the P133 and use the tools I had back then, as they won't run on my modern machine and there doesn't seem to be much to replace them...
I don't think fixing the lack of C compiler is going to really move the needle. Sure they modern people can say... oh man asm... but I want C.... but then if you give them C it will be... wait palettes you mean I can't just draw a png in photoshop, I have to work out tiles, I can only play 8 notes and not an mp3... the game maker crowd will never really push through the hard work of doing SNES dev, C or not. For me, C would be good enough on the SNES for doing presentation and general flow, but I would imagine I would need to kill the C runtime and drop into a pure ASM game core. It would save some time but not a lot of time. For me the rest of the tools,docs,turn key solutions would help a lot more. Porting the MACROSS assembler to 65816 might make a gentle halfway house though.
I don't think having C is the only push for getting more MD games, the fact it shares its core with the Amiga and ST means all their tools can be ported and the MD was more popular in the Euro zone where the demo coders are. They will just bash out a MD game for the fun it and to do something different for a change. Nintendo dominates in the US which doesn't really have a demo scene or programming mindset when it comes to computers. Also the MD has a lower standards.
For me the first step would be getting the tools and getting c# libs up to snuff, so people can make content, and build custom game tools quickly.
Then get some off the shelf solutions for things. The Audio tracker + playback code, standard joypad reading code, basic sprite bolting animation and movement system, something like http://codebase64.org/doku.php?id=base:start maybe port exominizer and make custom versions for it to depack to VRAM etc
Can those debug though?koitsu wrote:Maybe these products didn't exist when you were doing your dev work, but it's a little surprising you didn't consider the SD2SNES, SNES PowerPak, Super EverDrive -- especially considering how much pain you must have gone through to try and get an official devkit + hardware.michielvoo wrote:I wanted to test them on real hardware, so I obtained a back-up device outfitted with a floppy drive emulator. Unfortunately about half of my programs did not work on real hardware. I obtained an official development kit hoping it would help me debug, but its power supply is broken and I've been too lazy to get that fixed. And even then, I'd have to get an ancient computer with Japanse software to interface with the unit, so I have all but given up on the dream of debugging my code on real hardware.
Thanks for putting your stuff online!
A 1- or 2-man hobbyist team can complete an NES game as visually impressive as a commercial game from the pre-MMC era (NROM, CNROM, FDS, early UNROM, thinking 1983-1986) in a reasonable time. Not all NES games are as visually impressive as, say, Battletoads or Bucky O'Hare. There's still plenty of room for a 512 kbit production, such as the NESdev Compo, and an option to upgrade to a cartridge release once you hit 1987-1989 levels of complexity.
But even the Super NES's launch titles, such as Super Mario World, are more visually impressive than Battletoads and Bucky. Matching those production values needs a bigger team. With more people on your team comes more pressure to pay them, and once they want money up front, a retraux production on a modern platform is the path of least resistance.
So anyway, about tools that you would have run on a Pentium 133 in MS-DOS or Windows 95: Which tools would you have used to assemble 65816 code, assemble SPC700 code, make tile graphics, make art, make BRR samples, make music sequences, and debug your program? Are there specific deficiencies in the debugging-oriented Super NES emulator bsnes-plus?
X816 was the assembler I settled on. There is a RAW2SNES,GIF2SNES I think there was a PCX version as well, I eventually got hold of a leaked IFF2SNES which was used by some game devs.
Audio was very very primitive, I think a tool called SNESSOR was a tool for ripping bbr samples from games, and then you would use MIDI2MSS with the wavs of those samples and the actual brr samples. So you make the Midi on the PC using the wavs, then it packed it into some format and there was player code for it. Very very primitive from memory.
There was also a WAV2BRR but my music skills were never good enough so I just made things silent.
There was TileLayerP and a couple of others. I eventually made a Charset editor and Map editor as a SNES program. Then I would save the data to the SRAM, switch to windows and rename the srm file, then save the other. I then had a tool to strip and remove the excess from them. It was easier to use the SNES emulator to draw GUIS and the like than try and write windows code again to emulate all the drawing modes and pallets.65816 its faster to write than MFC Again coming from the C64 were all the char editors, screen editors, music makers, map makers etc were programs on it, it was just how I was use to things. There was another one that let you view ZSNES savestates, so you could run your code, then savestate it, the look at it in the tool to see all the other stuff you can't see on the screen to work out where you went wrong etc.
For debuggers there was the ZSNES one, which makes GDB look good. However as I came from C64 dev where the are no debuggers on the actual hardware ( although the fancy expensive assemblers had 6502 emulators so you could step your code, I didn't have a fancy one ), I just black box debugged as before.
I'm not saying the tools of yore are awesome, just seems to be more off them. Back then there was a small demoscene, since then most SNES work has been ROM translations, with some hacks. So the tools have grown up and around that purpose, so debuggers, translation tools, table editors, patch formats etc are well covered in the tool department, but the "to make something new" department is somewhat barren.
Now the Assemblers and Debuggers are miles better. I wouldn't use X816 any more, we have 64tass Then you have geigers and the new bsnes debuggers. There was a dev who told a tale of a game they worked on, and for months they just could not find what was corrupting a single pallet entry, so before they shipped they just made some code to patch it back at the end of vblank. With the modern tools I found it in 20mins for them. These debuggers, like FCEUX, take a more lets work out how this code works rather than, lets debug the code I just wrote work flow, well at least to me.
libSFX looks like an awesome start, nice work Optiroc.
However when it comes to more complex games, code is not really the battle, layout, balance, design start to take over.
- Assembler: I use ca65. x816 is hardcoded to LoROM (mode $20) anyway.
- Graphics conversion: I made a tool that can convert an indexed PNG, GIF, or BMP to 2-, 4-, or 8-bit planar or 8-bit packed formats, which I included with my Super NES project template. It currently doesn't do anything related to palettes or maps though. Though I made a tool to convert a PNG title screen to tile and map data, converting an arbitrary PNG is a bit of a harder problem with 1+8x15 colors than with 1+4x3 because it's harder to handmake the palette and specify it on the command line.
- Audio: We have an audio engine called SNESGSS. I also write my own WAV to BRR tool, which I included with my Super NES project template.
Is this in any way similar to a background graphics editor I made for NES?Oziphantom wrote:I eventually made a Charset editor and Map editor as a SNES program. Then I would save the data to the SRAM, switch to windows and rename the srm file