There's always been an extreme dearth in homebrew on the SNES. For being arguably the most popular retro gaming system ever, it sure doesn't get much programming love. And of course I know all too well many of the reasons why.
Markfrizb wondered why. I think some of the reasons are
- Needing to learn two assembly language syntaxes, one for audio and one for everything else. Toward fixing this, byuu developed bass with 6502 syntax for the SPC700, but bass is really more for ROM hacks than for original homebrew. I developed a proof-of-concept reimplementation of 6502 mnemonics in ca65 macro language, which led to blargg's macro packs for SPC700 (both syntaxes) and GBZ80.
- Needing to find a good set of WAVs to turn into BRRs.
- It can be harder for your artists to make use of all 15 colors you get in a sprite or tile.
- It can be harder for your artists to make use of 3 layers.
- It can be harder for your whole team to make use of 2 Mbit, the smallest size of a well-formed SFC image.
- It took a lot longer for emulators to get to the point where testing something on an emulator produces some level of confidence that it'll work on a console; Snes9x and ZSNES were even more deceptively permissive than NESticle at times. I'm guessing this is what byuu was referring to.
- Less known working demo source code, even to the level of hello world. It takes more code to get something visible because of CHR RAM; the program has to DMA in some CHR data.
- No widely accepted freeware 65816 C compiler; even the Apple IIGS-era compilers are hard to get. This rules out rapidly developed minigames like Alter Ego, Zooming Secretary, and MineShaft.
See also
Super NES games slower than NES versions of the same gameEDIT: See also
status of solutions as of December 2015.
Interestingly, I usually consume a good chunk of memory with music and SFX alone.
- Uwol: Quest for Money (the SNES port) is 2 Mbits, and almost a third of that is the music and SFX.
- MazezaM Challenge is 4 Mbits. Two fifths of that memory is used by the music and SFX. Interestingly, the game is more like a 3 Mbit game, as the last megabit is left unused.
- Tchou, for some odd reason, is a 7 Mbit game, although there is at least one megabit that can be shaved off since it's unused (and if the conditions are right, more than a megabit with some pointer shuffling). My music takes up one and three quarters of a megabit (or almost two megabits)... and a bunch of the music actually ends up unused!
I have a couple of game ideas myself, and I am already developing the soundtrack for both of them (one of them is so large, even larger than Earthbound's soundtrack, that the music alone is already 8 megabits! And the game I have in mind isn't even an RPG!). I've made a couple of test programs (including a graphic test), and I compile on the Mac with WLA DX (compiled using the shell script provided), and test them with SNES9X 1.53. I transfer the data over to another computer to debug if I absolutely have to, because there is no debugger on my end.
I do have a graphic converter that was produced by alekmaul (which I compiled with XCode and then, if I recall correctly, I adjusted the program for endianness issues), and SNESMod by mukunda for the music and SFX (also compiled through XCode).
I've also learned how the music can be banked over time thanks to inventing all sorts of music modifiers over the years, and I'm taking that method for some of these games. The in-game music in Uwol is all in SPC700 RAM at once (exceptions are the Title Screen, Ending and Game Over themes).
For a., I know both SPC700 assembly and 65C816 assembly, although I use 65C816 assembly much more often (I usually don't look up SPC700 opcodes, although I have looked up raw data inside SPC700 files before, especially these days when I do track counts when checking the ranges for the music modifier I produced).
For b, heh... this is where Schism Tracker comes into play, especially given the sound driver I use. I let SNESMod do the conversion, and I simply edit the samples, including loop points, with the tracker. It's basically dynamically changing the size of the sample in the process.
On a related note, I actually have endianness issues with the newest version of BRRTools, while I did not suffer from this problem with the Java version (I don't have the latest Java version..).
For c., I actually have an idea in one of my games to let the main sprites take up four or five colors, with one of those colors being different, and spread them out over the eight patlettes. The best use for this is so that I don't have to make duplicate versions each time. Then the other ten colors for each sprite patlette can be used for other objects. (or, if the right patlette is used, I can recycle some of the colors in one patlette).
For d... I think I have at least one idea that might use 3 layers. However, it might not always apply.
For e... I'm not sure about the graphics, but usually the music I make takes up a good deal of memory.
f. is a major reason why I have multiple debuggers... I have laevatinn (until there's another debugger) just in case I need to really examine what went wrong if the debugger I use, nosns, can't quite pick out the problem due to differences in emulators (I had this problem at least once).
For g... heh, I see what you mean. Especially with custom music. Plus, I think of mid-scanline effects, which I'm tempted to experiment with.
For h... oh yeah, tough call there... I actually can't even think of one that would work on a PowerPC Mac (I'm running an iMac G5 on Mac OS X 10.4.11). Even if I had the source, I'd have to check it and account for endianness issues if they pop up, and that's if the programming language (C or C++ is best for me) and libraries are compatible.
I plan to move to SNES homebrew and even Playstation 1 homebrew once I'll have successfully released several good NES games.
However, that won't be before a good while.
As for tepple's list of problems :
a) isn't a problem when you already know like 6 different assembly languages. Just print the instruction chart in doubt
b) Finding WAVs is not a problem, but making them fit the restricted SPC memory might be a problem. Anyways a low quality/small soundfont should do the work. Or just rip samples out of SNES games
c) Is definitely true ! However you can always come up with cheaper graphics that don't push the system to it's limit. It's the main problem for me, who is a very mediocre artist.
d) Not really. Layer 0 = playfield, Layer 1 = parallax or transparency or large bosses, Layer 2 = status bar and textboxes. Or if that's too much layers, use 2 layers, and use the tile-per-offset in mode 2, an amazing feature that was way too much underused
e) I don't see how it is "hard" to use 2 Megabit. You can always start with an almost blank 2 Megabit ROM. Uncompressed 4BP graphics will take up space quickly, and 64kb of SPC samples will already take 25% of that space.
f) Well the Super Power Pak and other similar devices exists for a reason.
g) I don't know much about SNES hardware but I doubt you have to use DMA, you could always manually copy the CHR assets in forced blanking mode.
h) You can code in assembly, although it's not quite as convenient.
@KungFuKirby : How did you end up having edianness problems with BRRTools ? Did you recompile it under a big endian system ?
I want to program for the snes so bad but I don't know where to start. Which tools should I use , I have windows 7, I have higan emulator, and also snes9x debugger. But as far as the tools to write the code and compile, I don't know where to start. I know a lot about electronic engineering and some various programming language skills.
Bregalad wrote:
Or just rip samples out of SNES games
And open yourself to a lawsuit just as much as if you had ripped the Mario sprites out of
Super Mario World.
Quote:
c) Is definitely true ! However you can always come up with cheaper graphics that don't push the system to it's limit.
And open yourself to "Why didn't you just make it for the NES?"
Quote:
Layer 1 = parallax or transparency or large bosses
I was referring to effort in drawing a beautiful parallax background.
Quote:
You can always start with an almost blank 2 Megabit ROM. Uncompressed 4BP graphics will take up space quickly, and 64kb of SPC samples will already take 25% of that space.
If you come up with cheaper graphics, they won't take as much space because they'll be stored in Game Boy or 3BPP format and expanded to 4BPP at runtime.
Quote:
f) Well the Super Power Pak and other similar devices exists for a reason.
For one thing, the PowerPak, EverDrive, and similar solutions tend to start the program in a state other than the actual power-up state. For another, it takes 30 seconds to get a build to the card, including copying the file, unmounting the CF card, inserting it into the PowerPak, and navigating the menus.
Quote:
g) I don't know much about SNES hardware but I doubt you have to use DMA, you could always manually copy the CHR assets in forced blanking mode.
It's still harder than the assets already being there, which is true with either NES CHR ROM or a Super NES "hello world" project template.
I've been thinking about the items in tepples' initial post the past couple days. No I am not ready to respond to any of them in full yet; I'm kind of nodding (in agreement) and laughing (in disagreement) with a bunch of them. I really wonder how many of those were around during the snesdev days in the 90s. Am I the only one left? :/
Anyway, the one item I did want to ask tepples about was this, item (g):
Quote:
It takes more code to get something visible because of CHR RAM; the program has to DMA in some CHR data.
You do not have to use DMA, you can do it the "old way" through memory-mapped registers if you wish (in fact that's actually how DMA does it -- yes really!), and in some cases the "old way" is a better choice. But trust me, for large updates, the DMA method is superb in every way and makes a lot more sense when you look at it. Have you actually tried using it? It's simple and logical to use for filling PPU memory.
The way you phrase the item implies that the DMA methodology is a negative -- it really isn't. In fact, overall I find dealing with PPU-related things on the SNES a hell of a lot easier (from a programmer's standpoint) than the NES. Remember: I started with the SNES/SFC and later learned NES/FC, so you could say I'm "spoiled", but it doesn't change the fact that DMA really isn't a negative in any way.
Basically the SNES/SFC is where Nintendo said "let's do this sanely, even if it costs a little more". The joypad registers on the NES, for example, are the one thing that still blow my mind compared to the SNES. NES = have fun screwing around in loops and shifting bits and using spare memory locations; SNES = all button values are stored in a 16-bit memory-mapped register for you to read at any time, where each bit represents a button or direction. wow very speed such smart so design.
Quote:
But as far as the tools to write the code and compile, I don't know where to start.
Some tools:
Some example code:
Quote:
It's still harder than the assets already being there
Sure, but it's simple enough to perform a DMA transfer:
Code:
load_cgram:
php
rep #$20
lda 11,s ; numBytes
sta.l $4305
lda 5,s ; src (lower 16 bits)
sta.l $4302
sep #$20
lda 7,s ; src bank
sta.l $4304
lda 9,s ; cgramOffs
sta.l $2121
lda #0
sta.l $4300
lda #$22
sta.l $4301
lda #1
sta.l $420b
plp
rtl
load_vram:
php
rep #$20
lda 9,s ; vramOffs
sta.l $2116
lda 11,s ; numBytes
sta.l $4305
lda 5,s ; src (lower 16 bits)
sta.l $4302
sep #$20
lda 7,s ; src bank
sta.l $4304
lda #1
sta.l $4300
lda #$80
sta.l $2115
lda #$18
sta.l $4301
lda #1
sta.l $420b
plp
rtl
------------
extern void load_cgram(char *src, unsigned short cgramOffs, unsigned short numBytes);
extern void load_vram(char *src, unsigned short vramOffs, unsigned short numBytes);
------------
load_vram(&bg_map, 0x3000, (&bg_map_end - &bg_map));
Quote:
And open yourself to a lawsuit just as much as if you had ripped the Mario sprites out of Super Mario World.
As far I know, fonts are not copyrightable, so logically sound fonts would follow the same rule.
However, if you're smart enough you'll rip each sample from a different game from a different company so nobody will even notice. That'll work better than having every letter from a different font (which will likely be very ugly).
I've seen so many games using Roland SC-55 samples for some of their instruments. Did Roland ever lawsuit game companies ? Or did they pay a licence ? Or is buying Roland hardware considered good enough ?
Quote:
And open yourself to "Why didn't you just make it for the NES?"
True, but if you make a nice use of SPC music that'd be the answer ^^ (or would a NES cartridge using an expansion sound like N106 or VRC6/7 considered "more authentic" ?)
Quote:
WLA-DX for Windows hosts (includes assemblers for the 65816 and SPC700)
Don't use WLA for SPC700 coding. This particular port of WLA is extremely buggy and unstable. It's already hard enough to debug code on a platform with virtually no good debugger, if the assembler doesn't produce the code you had at input it's even much worse. I recommend
spcas.
Quote:
This particular port of WLA is extremely buggy and unstable. It's already hard enough to debug code on a platform with virtually no good debugger, if the assembler doesn't produce the code you had at input it's even much worse.
IIRC, bsnes has an S-SMP debugger.
As far as generating correct output is concerned, do you have an example? I've used wla-spc700 in multiple projects and have not seen that kind of behavior.
koitsu wrote:
The way you phrase the item implies that the DMA methodology is a negative -- it really isn't.
I wasn't trying to claim it was harder than a CPU-driven copy. But it is harder than the data already being there, which is what you get with NROM on NES. You have to somehow get the data into what is essentially CHR RAM yourself. And unlike on NES, where $2005+$2001+$2000 = display, there are a lot more registers that you have to poke before the PPU will start displaying anything. This is why a hello world template project for your particular toolchain is so important.
koitsu wrote:
NES = have fun screwing around in loops and shifting bits and using spare memory locations; SNES = all button values are stored in a 16-bit memory-mapped register for you to read at any time
Except at the start of vblank, which bites you if your NMI handler didn't have much to copy this frame and you immediately start to run your next frame's game logic. Then you're back to loops to wait for the automatic reading to finish. And if you want to use a mouse or a multitap, you're still back to loops.
Bregalad wrote:
As far I know, fonts are not copyrightable, so logically sound fonts would follow the same rule.
The case law for pictorial, graphic, and sculptural works and the case law for sound recordings went in different directions.
Bregalad wrote:
I've seen so many games using Roland SC-55 samples for some of their instruments. Did Roland ever lawsuit game companies ? Or did they pay a licence ?
It's likely that Nintendo signed a deal with Roland to provide a sample set to licensed developers.
mic_ wrote:
IIRC, bsnes has an S-SMP debugger.
Has, or had? I seem to remember higan gaining and losing the debugger as it goes through different front ends. And is it present for all platforms supported by higan, or do I have to run Wine for debugging the way I have to with FCEUX?
Quote:
Has, or had? I seem to remember higan gaining and losing the debugger as it goes through different front ends.
Had, in the version I'm using (which isn't the latest one). Windows is the only OS I run at home, so I don't know whether any of the debugger-enabled versions of bsnes are available for other OSs (though IIRC the source code is/was available, allowing you to build it yourself).
There are a lot of homebrew games for classic gameboy, gameboy advance, and nintendo ds. As well as for most 8bit consoles & computers. Many of tepple's possible issues are applying to that systems too, but they didn't stop people. Initializing VRAM with or without DMA isn't that difficult, filling the available ROM space with (useful or wasteful) data is all too easy. Creating a square wave or finding WAVs shouldn't be more difficult as on other systems, finding a WAV to BRR converter may be some small obstacle, the syntax for main cpu and sound cpu are mostly having cosmetic differences, which should be no big deal, except that one may need separate assemblers for each one (finding assemblers & brr-converters shouldn't be impossible, but one needs to get more tools together for getting started).
During their lifetime, SNES and PSX were lacking any kind of good hardware documentation, and there don't seem to have been any good tools for testing things on real hardware. Well, at least from nowadays, floppy disc-based copiers and cdr-based modchips are looking like pre-historic relicts. The snes copiers & psx cheat devices also had parallel ports, which are also a bit pre-historic, but they (should) have reached up to 750kbyte/s transfer rates. I have never tried them, but I doubt that they've been implemented properly (the psx cheat firmwares are doing a lot of handshaking after each byte, so they have more probably reached only poor rates like 100kbyte/s). Though, even if homebrew wasn't that easy during the SNES/PSX lifetime, that doesn't really explain why there's still no homebrew scene yet.
For SNES, my main issue would be the 65C816 cpu. The overall 65xx syntax can be looking quite cryptic (to people who didn't grew up with 6502 computers), myself I don't know (and don't want to know) if TXA transfer from X to A, or from A to X. The 8bit/16bit/24bit memory addressing with lorom/hirom maps is also a bit more scary as on other systems - I could deal with that stuff - but the 8bit/16bit mode switching is just insane. I am still surprised that there are so many companies that have developed SNES games, I've absolutely no clue how they have found programmers that were able to (and willing to) write code on that CPU. The thing might have been quite comfortable when doing everything in 16bit mode, and leaving the 8bit modes unused, but unfortunately many of the I/O ports are only 8bit wide (that's really stupid, looks as if the hardware designers haven't been aware that Nintendo was going to use the PPU/DMA stuff with a 16bit CPU, else they could have at least padded the 8bit ports to 16bit size). Maybe it'd be recommended to stick in 16bit mode, and use 8bit mode(s) only in a few low level functions. Aside from being difficult to program, it's also difficult to disassemble that mode-switching code (which may also be a reason for smaller homebrew/hacking scene).
Bregalad wrote:
It's already hard enough to debug code on a platform with virtually no good debugger, if the assembler doesn't produce the code you had at input it's even much worse.
Anything wrong with no$sns? The debugger for main cpu isn't as powerful as in no$gba/no$gmb/no$psx, but I was hoping that it's at least good enough to be of some use (but yeah, debugging for the sound cpu and for the numerous coprococessors is still lacking some features).
What is an "assembler that doesn't produce the code you had at input"? One that is mis-translating the source code to wrong binary code instead of firing error messages?
nocash wrote:
The overall 65xx syntax can be looking quite cryptic (to people who didn't grew up with 6502 computers), myself I don't know (and don't want to know) if TXA transfer from X to A, or from A to X.
The T family instructions all use "from, to" order, just as the 68000 does.
Quote:
I've absolutely no clue how they have found programmers that were able to (and willing to) write code on that CPU.
Probably from the 6502 scene. There were plenty of programmers with C64, Atari computer, or Apple computer experience. The Apple IIGS had been out for a few years with the same CPU, and early dev systems were reportedly IIGS-based.
Quote:
Anything wrong with no$sns?
FCEUX's debugger works only in the Windows front end, but at least its bug tracker has been receptive to my Wine bug reports. Do you test in Wine? Or should I be your Linux guinea pig?
Quote:
As far as generating correct output is concerned, do you have an example?
Unfortunately not, I lost the source code, I only have the binary SPC file left on my PC. But it was something totally random (but deterministic), like it would throw a dozen of 0x00 bytes in the middle of my code for no reason. I don't remember very clearly, but it was extremely annoying. I had to add dummy instructions so that WLA wouldn't trigger its bug. If you didn't encounter it then I'm glad for you. Also pehaps you have a newer version of WLA than the one I had back then ? Although it doesn't seem WLA gets updated much...
Quote:
IIRC, bsnes has an S-SMP debugger.
Quote:
Anything wrong with no$sns?
The experiment I mentionned was made in 2008. no$snes weren't released at that time, and BSNES had zero debugging features. I was using SNES9x Debug for debugging, it was working, but it was just a bit annoying to make it work, compared to FCEU for example (the absolute reference of debugging, if only Super FCEU was existing it'd be awesome, even at medium accuracy level).
Quote:
The overall 65xx syntax can be looking quite cryptic (to people who didn't grew up with 6502 computers), myself I don't know (and don't want to know) if TXA transfer from X to A, or from A to X.
The same could be said of any assembly language, really.
Quote:
Although it doesn't seem WLA gets updated much
Ville has (de facto) abandoned the project long ago. The version I use is 9.5, and whichever version is included with SNESC.
Anyway, it's good that there are other assemblers for people to choose from. The reason I use WLA-DX is mainly because it supports a lot of target CPUs, so I can develop for several different systems with one assembler suite and only learn one set of directives, one macro syntax, etc. But to each his own.
Bregalad wrote:
@KungFuKirby : How did you end up having edianness problems with BRRTools ? Did you recompile it under a big endian system ?
That's exactly what I tried to do. My main computer is an iMac G5, and it uses a PowerPC processor, so it is a big endian system. Right off the bat, I determined endianness was responsible for the wrong sample address being loaded, as I was getting glitched results. I didn't have this problem with the Java version (however, I don't have the latest Java version)... after recompiling because I was running an earlier version of Java.
Part of the reason I'm interested in the SNES is that I can pull off some features the NES can't. Especially Mode 7. And if I wanted to add some modifications (or just make a brand new one), I can use pitch modulation (this one is rarely used, although I know of a few examples, and I've been using it myself recently via a modifed version of SNESMod) and noise generation.
I like it how there's always someone bashing wla with hearsay in every thread on this sub.
Bregalad wrote:
Quote:
And open yourself to a lawsuit just as much as if you had ripped the Mario sprites out of Super Mario World.
As far I know, fonts are not copyrightable, so logically sound fonts would follow the same rule.
However, if you're smart enough you'll rip each sample from a different game from a different company so nobody will even notice. That'll work better than having every letter from a different font (which will likely be very ugly).
I've seen so many games using Roland SC-55 samples for some of their instruments. Did Roland ever lawsuit game companies ? Or did they pay a licence ? Or is buying Roland hardware considered good enough ?
I don't know if you're joking but that's some pretty poor reasoning, a soundfont is not a text font.
The majority of samples used in SNES games were not made by game companies, it's all ripped from various samplers/sample packs. Every hard-/software sampler I've ever encountered is perfectly legal to use for whatever (except ripping and selling the samples as a new sample pack), so long as you paid for the unit/didn't pirate the software. What tepples said about licensing samples sounds plausible too.
I don't think you can use samples ripped straight from Nintendo games even if you do own the unit those samples originated from since Nintendo must've converted the samples to brr and likely processed them too.
Making your own samples for the snes isn't hard anyway, I'll try to make a tutorial at some point.
tepples wrote:
Except at the start of vblank, which bites you if your NMI handler didn't have much to copy this frame and you immediately start to run your next frame's game logic. Then you're back to loops to wait for the automatic reading to finish.
Auto-joy takes about 3 scanlines iirc, if you've got no DMA or calculations to perform during that time I don't think your game logic would be particularly stressed. Doesn't hurt to have a loop in place as a precaution.
nocash wrote:
but the 8bit/16bit mode switching is just insane.
It is a pretty annoying feature, I agree. Something that all of the open assemblers are missing that I saw in the psygnosis 65816 assembler is being able to assert accumulator/index size. This would eliminate many bugs caused by forgetting to change the size before calling a subroutine or using a macro with the wrong acc/idx size. That's about the only big inconvenience in my opinion, and you can sort of solve it with macros in ca65 (or by writing safer but slower code, ew).
nocash wrote:
Anything wrong with no$sns?
Breakpoints for main cpu bug out sometimes, it's impossible to remove one without clearing all breakpoints. It rarely happens and I haven't been able to observe a pattern yet.
My wishlist for no$sns features:
- Being able to set breakpoints on ROM/VRAM/WRAM/etc reads/writes (basically the entire memorymap + isolated stuff like vram and aram) would also be useful.
- A way to view the contents of VRAM/CGRAM/OAM in hex.
- A better organized I/O map window, or perhaps even just a simple list view like the debug window interface with the data next to each register, this way you could also map in additional registers easily like GSU and SA-1 mmio.
- Being able to set breakpoints on coprocessor execution would be nice.
- Support for .sym files. WLA can generate them but no$sns always complains about corruption (I tried all sorts of modifications but no dice). It'd be really convenient to have symbolic debugging.
Of course no$sns is already great as it is, I use it all the time for debugging and testing. I really appreciate the effort you've put into it so far
Also while I'm at it did anyone ever figure out how to get the WLA macro ARGS to work? Macros start looking unnecessarily cryptic once you get to \5 or so. Been thinking about giving it another shot, even if it's abandoned at this point.
Wow, I never thought someone still used those old machines ! Unfortunately I don't have a big endian machine to test on it, but I'll have to find a way to fix it somehow, so you can use the new BRRTools on your machine. I imagine I'd need a wrapper routine for every fread/fwrite call so that the byte order is reversed on big endian machines.
As for Java, I don't think the version of Java has any impact on the functionality of the program. The Java version is no longer supported, because, well, Java was starting to really annoy me. Compiling and running program is so complicated and it's so inefficient at runtime, it's a huge price to pay for the cross-platform compatibility.
Quote:
I like it how there's always someone bashing wla in every thread on this sub.
I'm not bashing it, I just said that i had problems with the SPC700 version. I had no problems with the 6502 version (or the 65816 version, but I used it very barely, and only used 6502 instructions, as I don't know 65816 assembly).
Quote:
I can use pitch modulation (this one is rarely used)
As far I know, Squaresoft was the only company to ever give Pitch Modulation some love, and that on both the SNES and PS1 machines.
Quote:
I don't know if you're joking but that's some pretty poor reasoning, a soundfont is not a text font.
I'm not that dumb you know ? But there's definitely some kind of analogy behind this (despite the word "sound font"). I have several sound fonts lying on my PC (most of them were available for free, some came with an old sound card) and 2 synthesizers, so I'd have a very large source of samples not ripped from games anways.
Bregalad wrote:
As far I know, fonts are not copyrightable, so logically sound fonts would follow the same rule.
Fonts are not copyrightable
in the US. In the UK, and Ireland they are. In much of the EU they're covered by design patents.
In any case, it's not clear that soundfonts necessarily follow the same rule. In the manual for my old synthesizer, I think I remember finding an explicit licensing clause allowing the use of the samples for commercial products without separate royalties, and AIUI something equivalent is very common in the EULA of most commercial softsynths (You're buying a royalty-free license, not just the software). Conversely, this is part of why CreativeCommons-Sampling license was formed, because this surface wasn't explicitly clear in legal code nor in case law.
Quote:
Has, or had? I seem to remember higan gaining and losing the debugger as it goes through different front ends. And is it present for all platforms supported by higan, or do I have to run Wine for debugging the way I have to with FCEUX?
When replacing the entire toolkit, it mostly eliminates all the work done on any GUI. Went through a few revisions: raw Win32 [bsnes v013] -> Windows/GTK+ wrapper (hiro) [bsnes v040] -> Qt [laevateinn] -> Windows/GTK+/Qt/Cocoa wrapper (phoenix).
Current debugger for phoenix is called loki:
http://byuu.org/images/loki/loki-20140130.pngAs nice as GUIs are, they're just too much of a hassle. So this one is terminal-based. Haven't posted a downloadable version yet, still adding features.
Quote:
Anything wrong with no$sns?
It doesn't run on my operating system (Debian Wheezy), and it's closed source so I can't extend it as needed.
I've had some experience with text-based debuggers for other consoles/computers, so that's acceptable as long as the command list is available.
Pitch modulation is rarely used in music, if at all (There is one song in Jurassic Park 2 where this pops up). The most unusual implementation of pitch modulation by far for music is Packy and Marlon.
I myself use soundfonts (at least in part) for the music, although I edit them manually so that they can be transformed into SNES samples. It's less painful for me to edit those than fooling around with samples already made for the SNES (especially when ripped from .spc files... those loop points are already perfected, and sometimes they have no room for further adjustments) However, I have caught on to what sample packs are used by what companies, and some of them are really unique (Rap Jam: Volume One comes to mind... or even Universal Soldier!). So be careful what you pick... I can recognize a bunch of them, especially the ones that sound much more unique. It helps that I've invented music modifiers for at least a hundred SNES games.
The text-based debugger reminded me of the iconic debugger from the Apple II Monitor.
I will try and allow for nice things like an IPC layer for talking to the debugger (so you could have your own GUI-based tools on top of it), a user-made command alias so you can short-hand anything you want (the defaults are going to be verbose instead of single-letter commands), command history, execute-last-command quickly, a codebase that makes it easy to add your own monitoring windows to it, etc.
Appreciative that some of you won't mind the text-based interface, but I do fully expect it to be much less popular than the traditional GUI style, and that's fine. Like with higan, I make my stuff for me now, and I understand that it's niche. It is, however, sadly the only choice for a Linux SNES debugger. ZSNES' is DOS only (and discontinued), Geiger and no$sns are both Windows only. (DOSbox and Wine are hard enough, let alone on a 64-bit system with no ia32libs.)
I've always personally felt that the absolute most powerful debugger is the one where you are writing code right into the emulator itself. No debugger, GUI or text-based, is going to allow you the power to eg set a breakpoint when pixel 216,37 is set to BG3 when the screen is in mode 0. Or a breakpoint that breaks after the 37th hit while A=0x0153 after reset. But that's a five-second breakpoint to setup when you're working with the C++ code directly.
byuu wrote:
I will try and allow for nice things like an IPC layer for talking to the debugger (so you could have your own GUI-based tools on top of it)
If you use gdb protocol, these GUI front ends will already exist.
Quote:
a codebase that makes it easy to add your own monitoring windows to it
With a scripting language like FCEUX has?
Quote:
No debugger, GUI or text-based, is going to allow you the power to eg set a breakpoint when pixel 216,37 is set to BG3 when the screen is in mode 0.
Let me express it in a pseudo code similar to that of WarioWare DIY, which uses a "when" clause as an action trigger followed by several "while" clauses to narrow it:
When hcount becomes 216
While vcount = 37
While screen mode = 0
While frontmost layer at raster is BG3
Pause machine
Quote:
Or a breakpoint that breaks after the 37th hit while A=0x0153 after reset.
When (other condition)
While A = $0153
Add 1 to event_count1
When event_count1 becomes 37
Pause machine
See also
what I wrote about breakpoints in NESICIDE.
ARM9 wrote:
nocash wrote:
but the 8bit/16bit mode switching is just insane.
It is a pretty annoying feature, I agree. Something that all of the open assemblers are missing that I saw in the psygnosis 65816 assembler is being able to assert accumulator/index size. This would eliminate many bugs caused by forgetting to change the size before calling a subroutine or using a macro with the wrong acc/idx size. That's about the only big inconvenience in my opinion, and you can sort of solve it with macros in ca65 (or by writing safer but slower code, ew).
This is being discussed
here, and I maintain my stance that this is just crying/whining. Referenced thread mentions assemblers that follow
rep/sep bit changes (there are multiples and for different platforms -- I have used all of the ones I mentioned), ditto with having pseudo-ops to tell the assembler what's going on. Use of a macro to do both (ex.
.force16a would both tell the assembler "we're using 16-bit accum"
and issue
rep #$20 inline) is fine too, but isn't always desirable (it depends all on what you're doing in your code).
For all the years I did 65816, I ran into register size vs. assembler register size problems maybe once or twice, and it was easy to diagnose once generating a listing (one of the many reasons why that feature exists). Simple
rep/sep following takes care of 90% usage cases; other scenarios are exactly why assemblers have pseudo-ops to tell the assembler how it should be treating register sizes within that piece of code, making it the programmers' responsibility to know what is going on (and I fully agree with this belief). Nothing pisses me off more than computers (e.g. assemblers/compilers) thinking they can make decisions on my behalf. My mistakes = my fault, my program = my responsibility.
I'll end with a verbatim quote from the ORCA/M manual, with relevant part bolded:
Quote:
The 65816 CPU is capable of doing sixteen-bit operations involving the accumulator and memory; it is also capable of performing eight-bit operations the same way the 6502 and 65C02 do. The size of the accumulator and the amount of memory affected by instructions like LDA, STA and INC are controlled by a bit in the processor status register. At assembly time, the assembler has no idea how that bit will be set at run time – it is the responsibility of the programmer to tell the assembler using this directive.
Use 16-bit X/Y and 8-bit A as the standard size for routines. 16-bit X and Y let you loop over more than 256 bytes of memory easily, or use them as general pointers, and I don't believe that 16-bit indicies are any slower than 8-bit ones (obviously initializing them is). 8-bit A lets you manipulate registers and bytes easily, and you can do 16-bit operations as two 8-bit operations. They are also useful for 16-bit increment/decrement. This covers most needs. You pretty much have to keep an 8-bit register around to deal with hardware registers. Use 16-bit A/8-bit X and Y where it makes a significant speed difference, and be wary of any routine calls while in this mode.
I've never done "real" 65816 code, but wouldn't letting A, X and Y 16-bit in most situations be the more sane choice ? It's supposed to be a 16-bit processor after all. You can temporary turn A to 8-bit when dealing with memory mapped I/O, and then revert to 16-bit.
You'd have to switch to 8-bit A every time you wanted to deal with any 8-bit piece of data. That means basically all I/O registers, most of your variables (since 8-bit is enough for almost everything), most tables in memory. It's a pretty obvious choice if you're coding for the SNES.
Some of the memory-mapped registers are 8-bit, others are 16-bit. The reality of programming on the SNES/SFC specifically is that you do end up using sep/rep a lot, which really isn't that big of a deal since they only take 3 cycles. When it comes to memory-mapped registers, depending on what was desired by the programmer, folks tended to do things in "sections", i.e. rep #$30 then do necessary 16-bit stuff, then sep #$20 (8-bit a, 16-bit x/y) and do necessary 8-bit stuff there. I'm going to bow out of this subject from here on out, as it's starting to get into sperglordland. :-)
It just pisses me off when I see people crying/whining over this shit. The 65816 was designed to be backwards-compatible with the 65c02, which means 256 opcodes, and having dynamically-sized registers (thus applies to some operands, which is what the is complaint is about) means you only need 2 opcodes to control that (unless you wanted to rely entirely on plp, ha) while giving you the benefits of 16-bit registers. The crying is often done by people who did 68K or were spoiled by processors which had 16 bits worth of opcode space (i.e. 2-byte opcodes) -- sure, that might make things "easier for you" (and anyone disassembling), but that would mandate a new CPU that wasn't backwards-compatible with the 65c02. Reality check!
I always prefer 8-bit A, 16-bit X/Y. Switch to 16-bit A only when it helps performance (eg inner shift loop of a VWF routine, block transfer that has a catch which prevents simple DMA/MV[NP], etc)
I have tried in the past implementing assembler directives to catch A/X/Y sizes. I find that all it does is trade one set of problems for another, and makes the code uglier.
Catching rep and sep is easy, sure. But what do you do after plp, or rti, or even just a regular rts/rtl? The next function may have different expected sizes when invoked. What happens when you blur the line between functions and jump around with relative offsets? (jump tables and the like.) You're just as capable of getting lazy and missing a force size marker that results in non-working code.
Like koitsu said, it's not really hard. I've written several megabytes worth of 65816 source, and mixing up sizes has only happened to me a few times at the beginning.
But if I really wanted protection against this, here's the way I'd do it: create a usage file format. For each ROM address output by the assembler, store a byte in a usage.bin file that has the following bit-fields for each address: <read, write, execute, M flag, X flag, ...>. M/X flag only matters here for #const opcodes, where it can be detected by the assembler. Now have the emulator generate the same information as the program runs. If it detects a mismatch between the assembler-output and emulator-input M/X flags on a #const opcode, it should alert in the terminal. Even better if you store more usage information (source code line#, previous function name, etc.) Yes, it's one of those annoying run-time instead of compile-time detections, but it's a transparent behavior catch without you having to try and label M/X flag settings all throughout your source.
koitsu wrote:
It just pisses me off when I see people crying/whining over this shit.
There there, calm your tits. It's quite amusing how many times you've called me a whiner when you don't even understand what I'm talking about.
I never said that it's hard to keep track of the processor status, I said that it's an inconvenience (admittedly mostly for beginners) that could be further diminished ever so slightly with some fairly basic features. If you don't like it then don't use it, no harm done.
Byuu's approach is probably the most foolproof, but using plp without php sounds questionable.
ARM9 wrote:
koitsu wrote:
It just pisses me off when I see people crying/whining over this shit.
There there, calm your tits. It's quite amusing how many times you've called me a whiner when you don't even understand what I'm talking about.
I never said that it's hard to keep track of the processor status, I said that it's an inconvenience (admittedly mostly for beginners) that could be further diminished ever so slightly with some fairly basic features. If you don't like it then don't use it, no harm done.
Byuu's approach is probably the most foolproof, but using plp without php sounds questionable.
Use of
php with
plp is probably implied.
So let me try to wrap up the answers to my original post:
- Assembler reliability and assembly syntax: Use ca65 with blargg's SPC700 macro pack to avoid problems with the discontinued WLA and to regain familiar (to NES/C64/Atari/Apple II coders) 6502 syntax.
- WAVs: Find some CC-BY or otherwise permissively licensed sound font, or find or write a few quick synth programs. Convert the waves to the sampling rate that is a multiple of 16 times the note frequency, such as a multiple of 4186 for a middle C, and the loop points will line up. Making the sample rate a power of 2 times the note frequency will also make your note frequency tables sane.
- Color use: Start by making normal, highlight, and shadow shades of skin, clothing 1, and clothing 2 colors. This allows more freedom than the NES, where you typically get one shadow, one color, and one highlight/skin without having to use overlap.
- Layers: The common practice is to use mode 1 with three layers for playfield, parallax, and status, or use OPT mode 2 with two layers for playfield and parallax and sprites for the status bar. But your artists still need to determine what to put in the parallax layer.
- A full SPC700 image will eat up 1/4 of 2 Mbit right away, and graphics may compress twice as big as they did on the NES.
- Save up for a PowerPak. Accept the misfortune of having to wait years until you're old enough to work, accept the misfortune of having to check retrousb.com daily until the PowerPak is no longer Temporarily Unavailable, and accept the misfortune of having to move a CF card back and forth between your PC and your Super NES. But this still leaves open the difference between the power-up state of the Super NES and the state that the PowerPak menu leaves it in. Are there tests for the power-up state of the Super NES, and does higan pass them?
- It's not just copying the CHR assets into VRAM. With all the registers that must be set to a sane value to get a display going, it's best to start from an example that exercises the feature you are looking for. I made a minimal working example for the NES. mic_ lists a few for the Super NES.
- Use 816-tcc in the SNES SDK. Or just learn assembly and accept the misfortune. The rep/sep problem can be worked around by establishing calling conventions such as 8-bit A and 16-bit XY set for the parts of your program that interact with I/O registers.
Besides a PowerPAK you could use one of INL's SNES boards, or a Super EverDrive, or one of many Backup Units. So there are other and cheaper options to test on real hardware.
> Are there tests for the power-up state of the Super NES, and does higan pass them?
higan is extremely conservative. If I don't know the power-on state of a register (many are write-only, and very challenging to determine initial values for), I default it to a random value that changes with each power cycle / run of the emulator.
I most likely randomize things that shouldn't be. I'd rather have your game break only on higan than only on real hardware.
While byuu and I don't usually see eye-to-eye, his approach with higan is completely understandable.
I don't ever remember seeing "documented" power-on values (in any document, official or unofficial), all I remember is Nintendo very specifically outlining in their documentation the values values you need to assign to all memory-mapped registers in your RESET routine, ditto with standard sei/clc/xce and the necessary jml/jmp long (where long is bank $80 or higher) for games using high-speed mode (and also in NMI) to properly set the K register.
The manual says something to the effect of "{memory-mapped} register values are unknown when power is applied; initialisation must be done ASAP". It's easier to just do the initialisation per Nintendo and not get OCD about the power-on state. If you're worried about what the actual CPU registers are on power-on, those are actually documented in the official WDC 65816 manual (but I've given hints above :-) ).
Amusingly, you could reduce "sei/clc/xce" to just "xce", as P is always #$34 after both power cycle and soft reset. But yeah, you're saving two whole bytes. Not worth the brain space to remember that detail.
One of the more evil things I've found ... the stack pointer decrements with each reset, and the Super UFO in particular defaults the stack to #$0100 (it probably set it to zero and then switched to emulation mode.) So if your first instruction is a jsr/jsl, then you switch to native mode and return, your game will crash always on the UFO, and after every ~256/3 resets otherwise. Overwriting the entry point with a JSL is a pretty common ROM hacking way to add an intro splash screen or a trainer.
So as I understand your post, there's no one-frame delay before the regs become writable like
there is on NES. I'll have to study the worked examples more. Can I get a pre-release copy of the source code for higan with this new text-based debugger so that I can compile it in Xubuntu (a Debian derivative) and play with it for a while?
> So as I understand your post, there's no one-frame delay before the regs become writable like there is on NES.
Not that I've observed, hard to capture the very first video frame output from a running system with the tools I have.
One fun side effect I've seen is that VIRQs trigger one scanline late during only the first frame.
> Can I get a pre-release copy of the source code for higan with this new text-based debugger so that I can compile it in Xubuntu (a Debian derivative) and play with it for a while?
It's currently too unstable to use (only started on it this week), but I'll point you at a pre-release WIP once things are a bit more stable.
I've never noticed anything like a one-frame power up delay on SNES either. The initial I/O port settings are documented here
http://nocash.emubase.de/fullsnes.htm#snesiomap and here
http://nocash.emubase.de/fullsnes.htm#s ... ryandiomap (in the rightmost columns) (values in brackets tend to be so on initial power-up, but are left unchanged on /reset, it. they depend on if/how the game has changed, or when doing things like hotswapping cartridges, they might even contain values from the previously played game, so they could be actually total random).
The write-only PPU register are mostly unknown. Only way to test them would be writing a dozen of test programs, and then examining the TV picture (eg. initialize all PPU registers, but leave one register uninitialized, and then look how that uninitialized register affects the picture). I am assuming that the uninitialized PPU registers are all FFh on power-up (at least some are known to be so: the ppu multiplier input, the vram increment mode, and I think Anomie mentioned that the BG scroll offsets are also like so).
Anyways, it would be best to initialize or zerofill all I/O ports when the game starts (best do that twice, for the 'write-twice' registers). And of course, initialize RAM, VRAM, and Sound RAM too. If that's done right, then it should be quite safe to assume that the game works on both directly booting retail cartridges, as well on flash cartidges with bootstrap loaders.
tepples wrote:
Funny what one finds when trolling threads not otherwise of interest. I still owe you on this, tepples.
ARM9 wrote:
My wishlist for no$sns features:
- Being able to set breakpoints on ROM/VRAM/WRAM/etc reads/writes (basically the entire memorymap + isolated stuff like vram and aram) would also be useful.
- A way to view the contents of VRAM/CGRAM/OAM in hex.
- A better organized I/O map window, or perhaps even just a simple list view like the debug window interface with the data next to each register, this way you could also map in additional registers easily like GSU and SA-1 mmio.
- Being able to set breakpoints on coprocessor execution would be nice.
- Support for .sym files. WLA can generate them but no$sns always complains about corruption (I tried all sorts of modifications but no dice). It'd be really convenient to have symbolic debugging.
Breakpoints for main cpu bug out sometimes, it's impossible to remove one without clearing all breakpoints. It rarely happens and I haven't been able to observe a pattern yet.
Memory access breaks would be nice. I am afraid it'd be some work (more as for RISC cpus) since the SNES has so many different opcodes with different addressing modes (not to mention all the coprocessors). For performance reasons, I'd need to implement each opcode twice (for normal fast execution, and slower debugging checks).
Vram/Palette/oam hex viewing for BG Maps, Palette, and OAM you can view HEX values (when moving the mouse across the VRAM viewer windows). Downside is that it doesn't cover non-BG-Map portions of VRAM, and of course there are cases where it'd be nicer to see all values at once, without needing to move the mouse on certain entries.
better organized I/O map window - alltogether I like the I/O map windows as is. They are currently resolving the meaning of the separate bits, which I wouldn't know how to do that in a list view. And they somehow sorted by categories. All sound registers in one tab, the DMA (and misc) registers in another tab. And the PPU registers in two tabs - that's the point where I am occassionally getting lost myself. Maybe I should rearrange those two tabs: One tab that contains solely BG related registers, one for basic control/status, and maybe a third tab for special effects like window & color math.
NB. The coprocessor I/O ports can be viewed in the "Cart Profile" window, but it's really uncomfortable to use (need to reopen the window and scroll down each time when viewing them), but then, coprocessors are probably rarely used in homebrew projects, so it doesn't matter too much.
breakpoints on coprocessor - yup, would be great, especially for the APU, currently only the one-shot breaks (F4-key) are working on APU side. The issue with normal (F2-key) breaks is that I'd need to store some "which break is for which cpu" info in the breakpoint list (and of course, needing to implement them on the different cpus).
Breakpoints for main cpu bug out sometimes - whoops. Might have something to do with the new dynamically allocated lists that I had implemented in January 2013. I remember that there has been some problem... but I can't find any release notes about when I have fixed it. Maybe the bug does still exist in current no$sns version - you are using v1.5, don't you?
Support for .sym files that's supported. Allthough I don't seem have to documented how :-) best pick the magicsns source code
http://nocash.emubase.de/magicflr.htm store it in no$sns's "STUFF" folder, then use no$sns Utility -> Assemble File to build the binary and .sym file. As for the breakpoints, it's lacking the "for-which-cpu" info, I'll need to change the format someday to something like "APU:NNNN apu_label" and "CX4:NNNN capcom_label".
tepples wrote:
Do you test in Wine? Or should I be your Linux guinea pig?
Yes, why not? Would be nice. I haven't tested in Wine. Judging from the latest posts, I am having the impression it does work under wine. Though I got some bug reports about debug font issues some years ago (unsupported GetGlyphOutline function, which is hopefully implemented meanwhile, and, some glitch where wine was using a proportional font, instead of the desired fixed width font). I know that lidnariq has tested the hardware accellerated video zooming under wine, so it seems that no$sns is somehow working, hopefully without font glitches.
PS. The no$sns debugger can be found here:
http://nocash.emubase.de/sns.htm
tepples wrote:
So let me try to wrap up the answers to my original post:
- Assembler reliability and assembly syntax: Use ca65 with blargg's SPC700 macro pack to avoid problems with the discontinued WLA and to regain familiar (to NES/C64/Atari/Apple II coders) 6502 syntax.
- WAVs: Find some CC-BY or otherwise permissively licensed sound font, or find or write a few quick synth programs. Convert the waves to the sampling rate that is a multiple of 16 times the note frequency, such as a multiple of 4186 for a middle C, and the loop points will line up. Making the sample rate a power of 2 times the note frequency will also make your note frequency tables sane.
- Color use: Start by making normal, highlight, and shadow shades of skin, clothing 1, and clothing 2 colors. This allows more freedom than the NES, where you typically get one shadow, one color, and one highlight/skin without having to use overlap.
- Layers: The common practice is to use mode 1 with three layers for playfield, parallax, and status, or use OPT mode 2 with two layers for playfield and parallax and sprites for the status bar. But your artists still need to determine what to put in the parallax layer.
- A full SPC700 image will eat up 1/4 of 2 Mbit right away, and graphics may compress twice as big as they did on the NES.
- Save up for a PowerPak. Accept the misfortune of having to wait years until you're old enough to work, accept the misfortune of having to check retrousb.com daily until the PowerPak is no longer Temporarily Unavailable, and accept the misfortune of having to move a CF card back and forth between your PC and your Super NES. But this still leaves open the difference between the power-up state of the Super NES and the state that the PowerPak menu leaves it in. Are there tests for the power-up state of the Super NES, and does higan pass them?
- It's not just copying the CHR assets into VRAM. With all the registers that must be set to a sane value to get a display going, it's best to start from an example that exercises the feature you are looking for. I made a minimal working example for the NES. mic_ lists a few for the Super NES.
- Use 816-tcc in the SNES SDK. Or just learn assembly and accept the misfortune. The rep/sep problem can be worked around by establishing calling conventions such as 8-bit A and 16-bit XY set for the parts of your program that interact with I/O registers.
Not sure if this is mentioned other places in the thread, but don't underestimate the power of dithering:
http://upload.wikimedia.org/wikipedia/e ... dither.pngDepends on your taste, but you can reduce the amount of colors significantly depending on how much you are willing to put up with. I do it by hand sometimes, but you can also get interesting results out of Photoshop with the save for web option. If you save it as a .gif you can reduce the amount of colors and play with how the dithering works (pattern, noise, etc)
benjaminsantiago wrote:
Not sure if this is mentioned other places in the thread, but don't underestimate the power of dithering
Trust me;
I've played with dithering before as a way to compensate for another platform's lack of HDMA. That's why I've suggested breaking each 15-color palette into five 3-color subpalettes, to allow each color to be dithered light and dark.
Quote:
If you save it as a .gif you can reduce the amount of colors and play with how the dithering works (pattern, noise, etc)
I had to alternate strips of pattern and noise to get things to look good.
Quote:
Needing to learn two assembly language syntaxes, one for audio and one for everything else. Toward fixing this, byuu developed bass with 6502 syntax for the SPC700, but bass is really more for ROM hacks than for original homebrew. I developed a proof-of-concept reimplementation of 6502 mnemonics in ca65 macro language, which led to blargg's macro packs for SPC700 (both syntaxes) and GBZ80.
Quote:
Assembler reliability and assembly syntax: Use ca65 with blargg's SPC700 macro pack to avoid problems with the discontinued WLA and to regain familiar (to NES/C64/Atari/Apple II coders) 6502 syntax.
Quote:
The overall 65xx syntax can be looking quite cryptic (to people who didn't grew up with 6502 computers), myself I don't know (and don't want to know) if TXA transfer from X to A, or from A to X.
I understand the point of Koitsu being annoyed by people whining about the 8/16 bit register swapping, but I am even more annoyed by people whining about mnemonic syntax. I mean, if you can program in assembly for a platform you should able to be flexible and adopt for different architectures.
If you can't code in assembly because some processor uses MOV instead of LDA or whatever, you should seriously question your mental health / sanity.
I want to share code between music sequence interpretation in an NES game and music sequence interpretation in a Super NES port of the same game. If both assemblers support the same mnemonics, I can write music sequence interpretation once and test twice, and any new features or fixed bugs propagate to the other version. But if they don't, I have to either write my own assembler that takes 6502 mnemonics and spits out something an SPC700 assembler can handle (like blargg's macro pack) or write the music sequence interpreter twice and somehow remember to fix bugs twice and add features twice. I know I have to write the instrument code twice, once for the 2A03 PSG and once for the S-DSP, but reducing what I have to write twice makes the job that much easier.
Quote:
you should seriously question your mental health / sanity.
If you want to believe that only mentally ill people
don't repeat themselves, I'll have to agree to disagree. Wanting to write code with multiple layers of safety doesn't make someone
terrible, and wanting to reuse effort doesn't make someone insane.
Besides, it doesn't matter anymore now that blargg's macro pack exists. Line "a." is one of the things that I marked as solved in my follow-up post.
What is all that 'whining' about other people's preferences about? I don't see a problem if some prefers a specific syntax. And I can't see how people can feel offended if somebody says the mode switching is uncomfortable to him. In case somebody felt offended because I was saying that mode switching is "insane": Okay, I am sorry, I do admit that it wasn't nice saying that. I just meant it's a unique (and rather uncomfortable) feature of the 65816.
I've never seen a processor - no matter if it's new or old, 4bit, 8bit, 16bit, or 32bit architecture - that requires permanent mode switching. To people being new to that processor (=ongoing homebrew programmers) that means:
1) one must understand what mode switching is about
2) one may need to select some default setting, like 16bit X/Y and 8bit A, whatever appears best to them
3) after soon one may notice that the CPU supports 16bit ADC (cool), but it doesn't work in above 8bit mode (damn)
4) one may need to change the default mode here and where (some games are changing it dozens of times within a single function)
5) as some people mentioned, one must careful not to mess up different modes (like mode changes in subfunctions, etc.)
The whole subject requires a bunch of design decisions: The default mode, whether to push/pop/change the mode inside of functions (slow on every function call), or to expect the function always being called in proper mode, whether to use 16bit maths, or to use several 8bit opcodes for the same purpose. Once you are familar with it, it may be easier to do that decisions (either you might intuitevely know the best solution, or you might simply decide that you don't care if your code isn't optimal).
About the syntax: I am using a rather uncommon 80x86-style syntax. For example, it's using "MOV dst,src" opcodes (instead of the official LDA, STA, LDX, STX, LDY, STY, TAY, TAX, TSX, TYA, TXA, TXS, TXY, TXY, TDC, TCD, TSC, TCS opcodes with implied operands). The "MOV" variant can be easier to read, and one doesn't need to memorize all the official mnemonics. On the other hand, the official syntax is shorter (less typing time when writing source code), and may be also useful for discussing specific opcodes (like saying that "TXS and TCS don't affect any flags").
Of course any inofficial syntax may look like a sacrilege to some people. That's good. I do
like sacrileges. Anyways, in no$sns, I've spent days and weeks on implementing both official & inofficial syntaxes (both in the disassembler as well as in the built-in assembler) for the 65816, for the APU, and also for several coprocessors. Hope that it'll satisfy almost everybody (only, it doesn't include 6502-like APU syntax, sorry).
For homebrew code, I'd be glad is somebody would feel like using or adopting my syntax. The 'clearer' syntax might be making things easier for beginners. The downside is that it doesn't match up with any existing tutorials.
Z80 has "prefixes" that set a mode, but the next instruction clears the mode. Intel x86 has real, virtual, protected, and now (with AMD64) long mode. I guess that puts 65816's rep/sep somewhere in the middle.
Anyway, for the avoidance of doubt, unsolved problems have been cut down for the moment to d. what to put in the parallax layer, and f. waiting for byuu's new debugger.
nocash wrote:
I've never seen a processor - no matter if it's new or old, 4bit, 8bit, 16bit, or 32bit architecture - that requires permanent mode switching.
I'm not that familiar but I think the earlier x86 processors had various addressing modes for 16/32-bit addressing or some such. PowerPC has a little-endian mode. The ARM series has a thumb mode, and the 64-bit ARM (A64?) has a 32-bit mode that might be used a lot for current software.
tepples wrote:
Z80 has "prefixes" that set a mode, but the next instruction clears the mode. Intel x86 has real, virtual, protected, and now (with AMD64) long mode. I guess that puts 65816's rep/sep somewhere in the middle.
The x86 real/virtual/protected mode and it's 16bit/32bit modes are needed to configured only once (usually done by the operating system), and thereafter one won't need to care about them (and with prefixes, one can still use 16bit values in 32bit mode, and vice versa).
Eventually the REP/SEP opcodes could be compared to that prefixes, except that one must place them manually, and if needed, also restore the old mode manually. That's making the 65816 a bit more challenging than any other processors.
blargg wrote:
I'm not that familiar but I think the earlier x86 processors had various addressing modes for 16/32-bit addressing or some such. PowerPC has a little-endian mode. The ARM series has a thumb mode, and the 64-bit ARM (A64?) has a 32-bit mode that might be used a lot for current software.
Disassembling mixed ARM/THUMB can be actually as hard as 65816 code. On the other hand, programming ARM/THUMB is quite easy: one could easly write a complete function (or a whole program) using only one mode.
I didn't knew that PowerPC supports little-endian, but one would probably need it only rarely; like when dealing with little-endian file formats. I've never used 64-bit ARM. But there's one general rule for ARM devrs: 99% of them are using HLL code. I suspect that they won't even know if their compiler should actually happen to do any mode switches.
On the SNES, about 99% of all games are looking like asm code. Only exception that comes to my mind is the X-Band modem bios (it's binary code doesn't look too beautiful, it reminds me a lot of the HLL code that Nintendo is now using on GBA and DS).
Anyways, the SNES hardware includes support for OAMs and scrolling BG layers, so it might be quite possible to write reasonably fast games in HLL code. I wonder if anybody already did so?
My point was simply that there are other processors with modes that you set based on your design and rarely/never change, in response to this:
nocash wrote:
I've never seen a processor - no matter if it's new or old, 4bit, 8bit, 16bit, or 32bit architecture - that requires permanent mode switching.
I didn't see it as a question of how justified their modes are, just that they exist in many other architectures.
nocash wrote:
The x86 real/virtual/protected mode and it's 16bit/32bit modes are needed to configured only once (usually done by the operating system), and thereafter one won't need to care about them
Didn't your pre-Win9x emulators have a DOS port that used some sort of DPMI to run the app in protected mode and switch in and out of virtual mode to run DOS?
Quote:
But there's one general rule for ARM devrs: 99% of them are using HLL code.
And the other 1%, at least on the GBA, were writing the inner loops of sound mixers or 3D software renderers. This goes back to the "same syntax" issue: I used to have a game compiling out of one tree with PC, GBA, and DS ports differing only on input, video, and audio, and most of the video code was shared between GBA and DS versions.
Quote:
I suspect that they won't even know if their compiler should actually happen to do any mode switches.
On ARM with Thumb interworking, mode switches happen at the start or end of a subroutine. The majority of a GBA program would be in Thumb mode in ROM (or slow RAM in the case of multiboot clients), with certain inner loops or math functions (the kind of things one would do on a Super FX) in fast RAM.
Quote:
Anyways, the SNES hardware includes support for OAMs and scrolling BG layers, so it might be quite possible to write reasonably fast games in HLL code. I wonder if anybody already did so?
It's been done on the NES: Alter Ego, Zooming Secretary, and MineShaft are in C.
Perhaps once this debate dies down I can take a look at some examples in no$sns in Wine.
Couple random tidbits:
- Certain models of PIC chips, if my memory serves me right, also offer similar features that are adjustable at runtime (register sizes or some kind of memory model, I forget which).
- There are SNES/SFC games which were written in combinations of both assembly and C. Some of the later RPGs were done that way, based on (again if my memory serves me correct) interviews with some developers and/or reverse engineering efforts. If other examples are needed, I could ask Toshi Morita (I'm not sure he'd remember me though, as I met him back in 1993); look him up if you don't know who he is -- not exactly a "unknown" fellow. I wouldn't be surprised if he did a bit of C in
Zombies Ate My Neighbors, given his background with compilers.
Quote:
Of course any inofficial syntax may look like a sacrilege to some people.
This is exactly what I was thinking. It's a sacrilege.
Quote:
On the other hand, programming ARM/THUMB is quite easy: one could easly write a complete function (or a whole program) using only one mode.
Yeah, usually there is no reason to switch constantly between both : If you want speed you use ARM, if you want to save ROM/RAM space you use THUMB (GBA is a bit of a weird beast here, because THUMB will ALSO be faster when executing from ROM because the CPU lacks an I-Cache and ROM fetches are 16-bit). However, a 100% Thumb program isn't possible as the processors resets in ARM mode, and automatically switch to ARM when an interrupt is executed.
Quote:
could ask Toshi Morita (I'm not sure he'd remember me though, as I met him back in 1993)
You mean the guy from 6502.org ? I didn't know he wrote SNES games !
"Probably" the guy from 6502.org, since Apple IIGS stuff is how I originally met him. Toshi does a lot of things and is extremely well-versed in, well... everything. Especially 65xxx. Yep, he did some commercial games (for Genesis/Megadrive and SNES/SFC), has worked on gcc (including porting it to some Sega console, I forget which one) and also has some patents. He's very friendly, very professional, and mindblowingly smart.
The guy I'm referring to (sorry, have to use a Google cached copy due to LinkedIn privacy stuff):
http://webcache.googleusercontent.com/s ... =firefox-a
nocash wrote:
On the SNES, about 99% of all games are looking like asm code.
Try disassembling Romancing Sa-Ga's bank 02 (i.e. 02/8000 in SNES address space; ROM offset 0x010000) If that shit isn't compiled C code (complete with hilariously cycle-wasting malloc() and memcpy() library functions) I'll eat my hat.
> Memory access breaks would be nice. I am afraid it'd be some work (more as for RISC cpus) since the SNES has so many different opcodes with different addressing modes (not to mention all the coprocessors). For performance reasons, I'd need to implement each opcode twice (for normal fast execution, and slower debugging checks).
I have all of my opcodes call out to generic opcode read/write functions, so I only need a breakpoint hook in one place.
I really think one should have a debugger build and a regular build without the debug checks. With a bit of clever coding, you don't even need unsightly #ifdef DEBUGGER blocks around all your debugging hooks. So I'll have:
Code:
alwaysinline void CPU::op_read(unsigned addr) {
mdr = bus.read(addr);
add_clocks(speed(addr));
debugger.op_read(addr, mdr);
return mdr;
}
And the debugger.op_read(), when DEBUGGER is not defined, is reduced to a no-operation, and thus zero overhead. The forced inlining makes sure that we don't pay for the abstraction, and we get to adhere better to
DRY.
Similarly, I have read/write/execute breakpoints for CPU, SMP, APU, VRAM, OAM, CGRAM with the read/write breakpoints accepting an optional "only if read/write value == N" condition. They are indeed immensely useful for ROM hacking / fan translations.
> breakpoints on coprocessor - yup, would be great, especially for the APU, currently only the one-shot breaks (F4-key) are working on APU side. The issue with normal (F2-key) breaks is that I'd need to store some "which break is for which cpu" info in the breakpoint list (and of course, needing to implement them on the different cpus).
Yeah, interleaving operations between the multiple processors is a real bitch. Gets even nastier when your emulator runs at cycle granularity and one processor may be in the middle of an opcode at an instruction breakpoint boundary on another CPU.
Cooperative threading also adds fun limitations to debugging in my own case.
There's a definite struggle between accuracy and debugging power. But in our case all of the less accurate SNES emulators have either no debuggers or shit debuggers, so the bar is pretty low.
> There are SNES/SFC games which were written in combinations of both assembly and C. Some of the later RPGs were done that way, based on (again if my memory serves me correct)
Yeah, it's a big library, probably all variations of anything you can imagine.
Square seems to have made their own bytecode language for their games, which I assume they had large script files and a compiler for. Masaya built games entirely from portable macro code (it was a nightmare to hack, the unrolling was legendary.)
The main issue is that the 65816 is just an absolute shit architecture for compiling C code on. You have exactly one register that you can add and subtract on. You can't even multiply or divide with the base processor.
Any code produced by a compiler is going to be inherently slow. You can definitely write your non-critical code sections with this slow code and probably be okay, but given the processor is effectively ~2.68MHz, with a throughput of less than half of one MIPS, you're going to end up degrading your game the more you use C. It's not like a desktop app where you can just code a few hot functions in ASM and have great performance. Some of the best games choke down the CPU despite being in pure assembler. Absolutely anything called at least once per frame would have hurt those games.
> This is exactly what I was thinking. It's a sacrilege.
It makes it vastly more difficult to share code, that's for sure.
The SMP mnemonics just drove me absolutely nuts. It was the most blatant 6502++ ripoff imaginable, yet they came up with this insane syntax. I would really be shocked if they didn't internally have a 6502-like mnemonic set for their CPU. I'd bet money that their public syntax was strictly a legal decision.
Of course the real fun in deviating from official syntax is that you'll never, ever get two people to agree to the same unofficial instruction set, so you end up with 15 variations.
byuu wrote:
Of course the real fun in deviating from official syntax is that you'll never, ever get two people to agree to the same unofficial instruction set, so you end up with 15 variations.
I think it'd be worthwhile for the community to come to a consensus on a 6502-style syntax for the SPC700, starting from your work on bass. Is there a well-known SNESdev forum, or is this it?
Well right off the bat, I offered to work on a consensus, but blargg already went his own way with his project. Given it had slightly different goals, but not a good omen. If you look to the Cx4, you see the same thing. segher came up with a temporary syntax for his reverse engineered instruction set. I tried to make it all consistent and nice in my implementation. Then Overload came up with his own mnemonics for it. And then finally nocash came up with his own. So we have four Cx4 mnemonic sets, and in this case, no official one to go by (HG51B169 is undocumented publicly.)
SNES emu dev is mostly on my own board, but even there it's died down substantially since we've fixed all known bugs.
There's some SNES programming forums like RHDN, but ROM hackers don't have the same depth of system knowledge as emulator authors. That and I really don't think the place is run very well.
For what it's worth, I am open to changing my SPC700-6502 syntax if anyone wants to discuss it. There's some really hairy issues, like two-operand opcodes that the 65816 lacks (which is a problem as 65816 already uses , for + for some mindfucked reason), and some interesting problems like "ora" not really applying to the non-A or modes (eg or carry and or bit), which is inconsistent with "and" that is the same for carry and bit.
byuu wrote:
For what it's worth, I am open to changing my SPC700-6502 syntax if anyone wants to discuss it.
I'll start a new topic about it.
Quote:
65816 already uses , for + for some mindfucked reason
Probably because + is already taken by expressions:
lda label+5,xQuote:
and some interesting problems like "ora" not really applying to the non-A or modes
Which is why ARM went to
orr.
tepples wrote:
byuu wrote:
65816 already uses , for + for some mindfucked reason
Probably because + is already taken by expressions:
lda label+5,xAccepting + leads to the the odd restriction that you can only add the index register as the last item in an expression. Comma is the standard argument separator for assembly, and indexed modes have a separate argument: what register to index via.
byuu wrote:
and some interesting problems like "ora" not really applying to the non-A or modes
I read that companies sued others or some legal bullshit over mnemonics back then, so everyone tried to make their own. That's what I've always explained to myself as to why they didn't just use or. That and their appreciated goal of making all mnemonics three characters.
> Which is why ARM went to orr.
That's what I ended up using for the non-A based ones. I left ora for consistency with 65816's ora.
> Probably because + is already taken by expressions: lda label+5,x
lda label+5+x would have been fine. You could also technically allow lda label+x+5 if you wanted to write a more complex parser. Both would require reserving a/x/y/s, and not allowing their use in user-made labels.
At any rate, even if we accept the justification, what do we do about opcodes that legitimately need commas for operand separators on the SPC700? And technically, MVN/MVP on the 65816.
My idea was to use =. Maybe a good one, maybe not.
bbs dp:bit=target
bne dp,x=target
orr dp=#imm
Added benefit of making the "dest,src or src,dest" ordering more clear.
> I read that companies sued others or some legal bullshit over mnemonics back then, so everyone tried to make their own. That's what I've always explained to myself as to why they didn't just use or. That and their appreciated goal of making all mnemonics three characters.
I figured they went with ora because or would have been the only mnemonic that wasn't exactly three letters.
Say what you will on mnemonics, but I've always really appreciated the visual operand alignment without needing to pad opcode names with spaces or tabs. When you get into Intel-era 20-letter-long AVX instructions, it's downright infuriating.
But yeah exactly. This is why the SPC700 has that half-assed, hideous mnemonic set. They knew they'd be sued for ripping off the 6502.
If I were designing it, I would have used ior (inclusive or.)
byuu wrote:
At any rate, even if we accept the justification, what do we do about opcodes that legitimately need commas for operand separators on the SPC700? And technically, MVN/MVP on the 65816.
Do these opcodes also happen to use indexed addressing?
Quote:
If I were designing it, I would have used ior (inclusive or.)
That looks like "immediate or" to me ever since I saw MIPS in college.
byuu wrote:
I figured they went with ora because or would have been the only mnemonic that wasn't exactly three letters.
IOR = inclusive or
EOR/XOR = exclusive or
Quote:
Say what you will on mnemonics, but I've always really appreciated the visual operand alignment without needing to pad opcode names with spaces or tabs. When you get into Intel-era 20-letter-long AVX instructions, it's downright infuriating.
No disagreement there. Coding on variable-length mnemonic assemblies is never pleasant, unless you want to depend on your editor to have custom tab widths or custom tab stops and tab between the mnemonic and operands.
Quote:
If I were designing it, I would have used ior (inclusive or.)
Haha.
It shouldn't be that difficult to develop an SNES game that looks like an NES game. You can use 128 8x8 sprites without the need of dealing with the extra 32 bytes, and you don't need to use 16-bit mode or use more than a single bank.
Also, is HLL a standard language that Nintendo uses, or does it refer to any high level language in general assuming that is what HLL stands for.
I think "HLL" refers to any high-level language. And as I understand how nocash's worldview connects to the ARM-powered platforms supported by his emulators, "HLL" in
this post probably means C or the less RAM-heavy parts of C++.
The state of development tools coupled with the expertise needed to create games for the SNES pretty much guarantees it's a niche within a niche for homebrew development.
We need both assembly gurus and amateur 3rd generation language capable homeworkers to create a thriving scene.
Sadly, the last effort to lower the bar on SNES game development has been abandoned twice:
http://www.snesgamemaker.comeze.com/Anyone with knowledge of the 65816 flavor of
wla could pick up the pieces and add functionality to it. Rejuvenate the project and grow the homebrew community.
tepples wrote:
Bregalad wrote:
Or just rip samples out of SNES games
And open yourself to a lawsuit just as much as if you had ripped the Mario sprites out of
Super Mario World.
This is blown out of proportion. If the use of the dinky samples from Super Mario World are comparable to Mario's direct likeness, then something is wrong here. I've come across dozens of POS systems in small stores and gas stations that use the ring, drowning, and goalpost sound effects ripped straight out of Sonic the Hedgehog. Surprise surprise, nobody's upset! Those are
actual recognizable sounds. Using an instrument sample from a SNES game will get nobody in trouble, especially since the game likely is not being sold. If someone uses a Mario sprite to teach themselves how to manipulate sprites for a demo, that's absolutely fine. A single sample of an instrument used in a part of one particular game is not going to tangle anyone's undergarments.
If needed, take the sample, mar it up a bit until it's a little different, and use it.
I don't see why the issue of "THERE COULD BE A LAWSUIT" is so often an issue that gets
excitedly brought up.
I remember trying to explain to the maker of snesgamemaker that in order to display a sprite onscreen, you had to upload a sprite pattern table during initialization, upload the oam during vblank, clear unused oam entries AND calculate hi-oam at the end of active display, as well as having the "display sprite" subroutine, to display sprites. He was seriously confused by all these steps.
EDIT: I have an idea. Why don't we take the famous snes initiation code, and add the addition of a default color palette, default sprite and bg pattern table and default vram memory arrangement settings.
How's this as a default setting:
Code:
sprites: 8x8 and 16x16
bg mode: 1, with high priority bg3
vram layout:
$0000 sprite patterns
$2000 bg1 map (64x64)
$3000 bg2 map (64x64)
$4000 bg1 & bg2 patterns
$6c00 bg3 map (32x32)
$7000 bg3 patterns
No idea why the maps have to be 64x64 instead of 64x32, which is enough for scrolling without artifacts. But if you could port
my NES project template to the Super NES, that'd be great.
Okay, that's a good point. It lets all 4 BG layers fit from $2000-$3fff.
EDIT:
Okay, here is a modified version of the initialization routine. It also puts it in fast mode, all layers on main screen, and in active display, full brightness.
I don't know anything about assembly. Is there any way to modify the InitSNES.asm to take advantage of your improved init routine psycopathicteen?
Here is the init used in SNESGameMaker (Located in C:\SNESGameMaker\Temp\Include)
I'll look into the code.
I want to know how you are assembling the code. Is it just a bunch of .asm files being assembled to a ROM individually, or are they using "includes."
Here's a question for others on this website. Is there a "correct" way to use NMI interrupts? In the last couple of projects I've been using an IRQ interrupt in the place of an NMI, because NMI interrupts could trigger late when the CPU is busy, causing a black bar to appear at the top of the screen, instead of the usual slowdown. If you keep the NMI interrupt flag set, it can interrupt the CPU while it's not finished with a frame, causing glitches, unless you reserve a byte of memory to signal if the frame is finished or not.
EDIT: Your code RTL after it clears wram. That would cause crashing, due to the stack being swiped out.
Okay, I'm finished with the snes initiation code. I even made text files ready to use as main and nmi code. Graphics should be stored in the $81xxxx and $82xxxx ROM banks, since each ROM bank is 32kB, it takes 2 banks to fill up 64kB of vram. I use xkas, if anyone has issues with wla or another assembler. If anyone finds a mistake, please tell me, and I'll fix it.
EDIT: No wonder nobody responded. I made two mistakes. The first is setting $2100 to $1f instead of $8f, the second is dma-ing both banks to address $0000 in VRAM. I'll post a correct version when I get home.
EDIT 2: Uploaded the corrected version. Hope people find this useful.
psycopathicteen wrote:
Okay, I'm finished with the snes initiation code.
Thanks for your effort. I have just taken a look at it and I would have initialized $2100 with zero brightness, since you probably will show your first image on screen coming from a fade-out (black to the image).
Somebody know if there have ever been a commercial game's source code leaked to the internet? I've read about how programmers did the game in those times, such as Secret of Evermore and its customized scripting system; I would like to know the inner of SNES games: how they manage events, the command scripts, drawing into VRAM, sprite creation, movement and collision, and so on.
So far, I reverse-ingeneered some games (Final Fantasy 6, Romancing Saga 3 and Treasure Hunter G) and all of them are different:
* FF6 uses different NMI routines for different kind of scenes (intro, worldmap and menus, at least, but I suppose they are different from NMI used in battles and cities), and the intro is built through a event queue (a RAM array) filled with routines that draw the Magitek armors, print the credits, set the HDMAs and manage the timing. The command script for the game is separated from the text script.
* RS3 uses different NMI routines for maps, battles, military battles and menus, pretty much like FF6. I didn't make through the event system, although I disassembled all the text scripting engine. The command script is not fully separated from the text script: the text script engine checks and writes some flags and variables to trigger some events or print different texts, so the text is mixed with those commands.
* THG is pretty tough, since it uses a mix between the previous: in each scene, the command script dictates which graphic chunk is to be decompressed, which VRAM address it has to be sent to, the CGRAM palette and some (so far) undefined things; there are 48 different commands. One of the commands points to a bunch of events that may occur in the current scene, and they are stored in a RAM array; there are 14 commands that defines each event. Finally, each scene has a bunch of dialogue pointers which are treated different from the events and which have their own 208 commands: variable and flag checking, text printing... pretty much like RS3. And my personal opinion is that the game was programmed in C, considering some data which looks like structs, the routine calling system, and so on...
magno wrote:
Somebody know if there have ever been a commercial game's source code leaked to the internet?
Someone disassembled
Super Mario Bros. for NES, and I'm told the code changes from NES to
Super Mario All-Stars weren't huge. There are also
some M.C. Kids post-mortem documents; they're not source code but they still have implementation details. It also depends on how you define "commercial": some open-source homebrew games have been
sold on the Action 53 multicart.
I think B.O.B. for SNES's source code was leaked. I seem to recall seeing it at some point. It should be out there somewhere.
byuu wrote:
Current debugger for phoenix is called loki:
http://byuu.org/images/loki/loki-20140130.pngAs nice as GUIs are, they're just too much of a hassle. So this one is terminal-based. Haven't posted a downloadable version yet, still adding features.
Has the "loki" debugger stabilized over the past few months? I'm getting feature requests for more colors in one of my NES games, and I figured a port to the Super NES would be easier than putting MMC5 ExGrafix on a CPLD.
With a port of one of my games to Super NES tying for second in a
recent poll, I felt the need to summarize the status of solutions to these problems, nearly two years on:
- Separate SPC700 syntax and buggy WLA: Solved with blargg's macro pack.
- Finding samples: Permissively licensed sound fonts are believed to exist.
EDIT: Fekinox recommended some, as did Quack Man - Making use of all 15 colors: Start with three lightnesses (normal, highlight, and shadow) of up to five of your character's colors, and stop fudging with similar colors (like SMB3 does with black overalls) or overlapping sprites (hi Mega Man). Draw surfaces pointing toward light lighter and surfaces pointing away from light darker.
- Finding something to put into BG2 and BG3: (?)
- Minimum size: A 1 Mbit UNROM or SxROM game will likely nearly double to almost 2 Mbit due to increased graphics color depth, SPC700 samples, and additional graphics for BG2 and BG3. That and you can improve the main character's animation or turn palette swapped enemies into distinct designs. For an NROM-scale game, there's no shame in padding the binary with $FF.
- Testing: Use bsnes-plus or no$sns (which works in Wine) for debugging and a Super EverDrive or SNES PowerPak for hardware verification. But with the DMA glitch, we may need to compile a list of people willing to test on 1/1/1 consoles. (?)
- Hello world: I've since made a Super NES version of my ca65 project template, and mic_ has listed others.
- C compiler: Answer is similar to NES. Try tcc-65816 for mostly turn-based games, assembly for real-time games.
What remains are links to sample packs, something to put in the parallax backgrounds, and DMA glitch testing. Are there any other excuses for plenty of NES homebrew releases and so few Super NES ones?
Re: samples
Bregalad made a Wav to Brr conversion tool. You can make your own samples by recording live instruments or virtual instruments.
http://www.romhacking.net/utilities/681/
I'm aware of tools like that. I was more concerned about the source of WAV files to put into that tool. Or rephrasing, where do ModPlug users get their samples?
Here's my two cents (I'm not a Modplug user, though):
I take samples from soundfonts, but I resample them and manually assign loop points to them utilizing Schism Tracker.
tepples wrote:
Are there any other excuses for plenty of NES homebrew releases and so few Super NES ones?
I always thought one thing that could be potentially holding it back is the somewhat unjustified reputation of the SNES's CPU, and how it's
SLOOOOOOOOOOW. What doesn't make sense though is as to why they'd go to the NES instead though. Most people (if any even do) would probably go to the Genesis, and there is plenty of Genesis homebrew. I guess it's like this: there are people who want to make something fairly small, so they go to the NES, and if people are then trying to make something with greater production value, they go to the SNES or the Genesis and choose the Genesis because they believe it is a better platform to work with (possibly because of the above reason) or they are just nostalgic for it or whatever.
The reasons I wanted to work on the SNES over other systems is because:
1. It's my favorite system and I wanted to contribute to it in some way
2. I'm "nostalgic" for it (which contributes to reason #1) in that although I'm not 25 years old or whatever, I got it as a hand-me-down when I was about 4, and it was the first video game I ever played and owned as I first played it when I was 3, almost 4 (It's on an old vhs tape that has the date in the corner).
3. I liked the technical specs video hardware, as I thought they would be capable of nice looking games while being somewhat conveniently made for 2D graphics (although I was kind of wrong about that...)
4. I feel like many developers could have done better, and I want to "prove" that the SNES is capable of more than has been done on it. (Kind of ties in to #1)
Now, as I've worked on the SNES, I can say I'm not nearly as enthusiastic as when I started because of frustration with things that I would have thought would be obvious mistakes when designing a video game console. Easily the main problem are the sprites, as there is almost nothing intuitive about them on the SNES, most notably the vram situation. I just personally found the easily accessible technical specs for the SNES (Wikipedia basically) to be somewhat misleading, and I know many people like random limitations to work on stuff like this, but I don't want to feel like I'm being crushed by it. The NES is (obviously) worse in this regard, but everything is at least straightforward. If I had known about the Irem M92 when deciding to work on the SNES, I probably wouldn't have even started on the SNES, although I probably wouldn't have gone far with that because I never would have had the technical knowledge on how to program for old systems, so I owe the SNES that. I still plan to work on the SNES, but it's killing me. I write bunches and bunches of crap, but I don't see any improvement because in me trying to "show off" old video game developers and program something amazing, I've gotten myself stuck, with it being hard to go back and start over, and equally hard to push through, but I figure one side would be more productive. The problem is that if I start to write a giant, complex animation engine and vram finder and tile uploader that all work in harmony, I need all of them done at once to even test anything, so it almost feels like I'm not even doing anything because I never see improvement, unlike when I first was working on the system and learned how to make characters change colors and stuff like that. Even then, I should have been done with this long ago, even with all my dumb school work, but I can't help myself from trying to improve things as I go along making it, almost causing me to restart the same thing multiple times over and still not seeing any result. What I really should do is I should stick to finishing something, see some sort of result onscreen, and then trying to improve it instead of trying to do it all in one shot. I'm sorry for my little "rant", but this has just gotten to me, and I'm kind of afraid I'll quit someday.
Espozo wrote:
I just personally found the easily accessible technical specs for the SNES (Wikipedia basically) to be somewhat misleading
How is wiki.superfamicom.org not accessible?
Quote:
The problem is that if I start to write a giant, complex animation engine and vram finder and tile uploader that all work in harmony, I need all of them done at once to even test anything
First load all of one character's animations statically into the 16K of CHR RAM dedicated to sprites, build your "giant, complex animation engine" around those 128 16x16 tiles, and get it
working. From there you can refactor it to load the tiles dynamically, and possibly load frames into statically allocated slots per character,
DKC style. What I just described, doing the simplest thing and then refactoring it for generality, is how I made the CHR RAM update engine of
Haunted: Halloween '85.
So anyway, I get the idea: the Genesis is drawing people away. Might it be wise for me to revise one of my older projects to build NES and Super NES versions from the same tree, with identical game logic and just different graphics and sound code, to show how easy it is to step up?
tepples wrote:
I just personally found the easily accessible technical specs for the SNES (Wikipedia basically) to be somewhat misleadingHow is wiki.superfamicom.org not accessible?
Just look up "snes technical specs" and tell me where wiki.superfamicom.org is, because I didn't find it till much latter. Look at it through the eyes of a beginner. I probably shouldn't have said "accessible" though...
tepples wrote:
First load all of one character's animations statically into the 16K of CHR RAM dedicated to sprites, build your "giant, complex animation engine" around those 128 16x16 tiles, and get it working. From there you can refactor it to load the tiles dynamically, and possibly load frames into statically allocated slots per character, DKC style. What I just described, doing the simplest thing and then refactoring it for generality, is how I made the CHR RAM update engine of Haunted: Halloween '85.So anyway, I get the idea: the Genesis is drawing people away. Might it be wise for me to revise one of my older projects to build NES and Super NES versions from the same tree, with identical game logic and just different graphics and sound code, to show how easy it is to step up?
I wasn't trying to attack you... But yeah, I guess you could do what you just described. I really don't think the SNES would give you a hard time if you just tried to do something simple for it, like Super Mario World simple vs. DKC.
Let's see if I can break this down into steps.
1) Create a basic animation engine.
2) Implement the ability to DMA to a fixed slot.
3) Use a frame number queue (a seperate register for previous and next frame number) to limit DMA usage.
4) Do all the fancy tile searching stuff.
Espozo wrote:
choose the Genesis because they believe it is a better platform to work with
By all accounts it is
easier to work with. But I've never been bothered much by whether or not what I'm trying to do is easy (which may be why I have trouble finishing projects)...
Quote:
I feel like many developers could have done better, and I want to "prove" that the SNES is capable of more than has been done on it.
Maybe that's part of the problem.
If you want to knock something out quickly, the Mega Drive is often a better choice. And the NES attracts most of the Nintendo fans who just want to do something simple or "retro". This leaves projects that either
need to be on SNES (and there's a pretty narrow window between "just do it on NES/MD" and "just do it on PC") or are done
by fanboys who want to prove something at least in part to explore untapped potential in the hardware.
You, me, psycopathicteen, and a number of other SNES developers on this board are all apparently trying to push the system past what the commercial-era games did with it. This isn't a guaranteed recipe for failure, as d4s has shown, and there are of course people who don't mind working on modest projects that don't push the envelope, but this 'drive to exceed' could be a contributing factor in the relative scarcity of finished games.
Quote:
I'm kind of afraid I'll quit someday.
I felt similarly for a while after I got the idea to do this port I'm working on (I had done zero game design or assembly programming before that; they were both voodoo as far as I was concerned). I felt like my enthusiasm would fade after a few months. It hasn't. This could be partly because I haven't had much time to work on the project, so instead of getting tired of it, I have to keep tearing myself away...
It could also be because I've seen tangible (if slow) progress. I'm learning the system, I'm pushing the limits of what can be done with the PPU, and it doesn't really feel like I'm just spinning my wheels. If I'd tried to start actual development on day 1, I'd likely have gotten lost and given up - but I've been doing system tests and functional mockups, trying one thing at a time, and so far it's working. I'll probably do a simple game or two as practice before starting development for real, so I don't get bogged down by my own incompetent code design...
Espozo wrote:
tepples wrote:
Are there any other excuses for plenty of NES homebrew releases and so few Super NES ones?
I always thought one thing that could be potentially holding it back is the somewhat unjustified reputation of the SNES's CPU, and how it's
SLOOOOOOOOOOW. What doesn't make sense though is as to why they'd go to the NES instead though. Most people (if any even do) would probably go to the Genesis, and there is plenty of Genesis homebrew. I guess it's like this: there are people who want to make something fairly small, so they go to the NES, and if people are then trying to make something with greater production value, they go to the SNES or the Genesis and choose the Genesis because they believe it is a better platform to work with (possibly because of the above reason) or they are just nostalgic for it or whatever.
It seems like if it weren't for its reputation of being slow, it wouldn't have ever been slow in the first place.
On this weekend of the release of Lucasfilm's The Force Awakens, remember that Nintendo's attempt to reverse this perception of slowness was thwarted by Pixar, which now shares a corporate parent with Lucasfilm.
Pixar produced a short film titled Red's Dream.
Lucasfilm produced a feature film titled Star Wars.
Nintendo produced a video game titled Uniracers to prove the Super NES wasn't slow.
Pixar successfully sued Nintendo on grounds that Uniracers was too similar to Red's Dream.
Disney owns Pixar.
Disney owns Lucasfilm.
tepples wrote:
Pixar produced a short film titled Red's Dream.
That was made in 1987? Dang... I'd have thought Toy Story would look like Toy Story 3 then, given the time gap. Did Pixar keep the same equipment?
tepples wrote:
Nintendo produced a video game titled Uniracers to prove the Super NES wasn't slow.
Was that really the point behind the game?
Actually, never mind...
tepples wrote:
Pixar successfully sued Nintendo on grounds that Uniracers was too similar to Red's Dream.
What was the point in suing them? I don't think Uniracers was taking any money away from Pixar...
Anyway, here's a little thing I found:
http://www.hardcoregaming101.net/unirally/unirally.htmQuote:
As explained on Nintendo Life, in an interview with Unirally developer Mike Dailly: "We modelled the unicycle exactly, based on a real life unicycle. The problem with Pixar was that they seemed to think that any computer generated unicycle was owned by them. They took footage from Red's Dream and compared it to Unirally and the unicycles were virtually the same; this isn't a big surprise as there's not a lot of ways you can bring life to a unicycle without looking like the one Pixar did. The judge - being the moron that he was - agreed. While it was a unicycle, and did look similar, I think he should have looked at the game as a whole. If he had, then he would have noticed that the game was a completely different environment, and the ‘character' of the unicycle just wasn't the same."
Was this Mike Dailly person even aware of Red's Dream's existence? I've never even heard of it until now...
I'm still convinced you're a lawyer tepples.
Nintendo should've gave developers the page of "peephole" optimizations.
That is, if Nintendo even knew them.
Something that never made sense to me is how much developers (such as Treasure) talked about how much they had to rely on optimizations to make use of the Sega Genesis's "blastprocessing" CPU. If it's so powerful, why do you need so many tricks in order to get it to run fast, and why didn't you use any of those tricks on the SNES?
psycopathicteen wrote:
developers (such as Treasure) talked about how much they had to rely on optimizations to make use of the Sega Genesis's "blastprocessing" CPU.
I was never aware of them doing this. All I heard was them saying that there games (how they are) wouldn't be possible on the SNES. Developers working on a particular system are known to talk about it favorably compared to others, justified or not. Konami wasn't exactly known for being good at programing for the SNES, and I think I heard most of their arcade machines from the time used the Motorola 68000, so it would make sense that they'd have an easier time there, as people from Treasure came from Konami. I always found it funny how they sort of trashed talked the SNES but then went to make games for the N64 (and the Saturn). Did they just not like working on more popular systems (like the PlayStation)?
I thought "blast processing" was a term invented in Sega of America's marketing? I wouldn't imagine any Japanese developer ever using that term.
I'm sure there were programmers that preferred the 68000 and others that didn't like it.
MottZilla wrote:
I'm sure there were programmers that preferred the 68000 and others that didn't like it.
Honestly i think that a very few percent of programmer which know the 68000 don't like it...
I started on 6502 assembly (only the basics, i was just getting the power of assembly compared to basic language then :p). Later i developed for the
Saturn cpu (which is quite exotic), then x86 for many years, then ARM and SHx cpu... I discovered 68000 quite late (i did know it but wasn't programming for it) and honestly even on the late i think it's still one of the best designed CPU with a very efficient and straightforward instruction set, it's my favorite when it comes to do assembly programming, definitely... The Z80 for instance is a CPU which i don't like, many registers (for a 8 bits CPU) but the instruction set do no take full benefit of it, i far prefer the customized / economic GB version which remove useless parts and add very useful instructions to it
To make a simple reply to the subject, i think the architecture of the SNES is the main reason why we don't see much homebrew for it... The SNES is probably one of the most popular retro gaming system, i'm certain a lot of people tried "to play" with (as i did actually) but got quickly discouraged or frustrated by the complex / convoluted architecture of the system. And by complex i don't mean it in the good way, here the complexity is only a pain and affect what we can do with the system, definitely.
We often read the CPU is slow but indeed the CPU is not *that slow*, even working at ~3 Mhz (mixed fast rom / ram speed) the synchronous RAM access (compared to 1/4 68000 access) make it definitely not that slow in term of "instruction" rate (probably higher then what we have with the 7.7Mhz 68000) BUT what hurt a lot if the CPU technology itself... Based on 6502 (which is already very basic as a 8 bit CPU), the 65816 is too archaic and definitely more in the range of the 8 bits CPU generation than 16 bits (even with the 16 bits internal ALU), aside the PPU weirdness i was so disappointed when i started programming the 65816, almost each new discovery about this CPU was a disappointment for me... I quickly dropped the idea to develop on SNES just because of that, the CPU would definitely limit me in what i could do on this system (at this time i was interested in doing basic 3D rendering) and i would never use extra hardware as Super-FX which denature entirely the system for me.
Stef wrote:
Later i developed for the
Saturn cpu (which is quite exotic), then x86 for many years, then ARM and SHx cpu...
And SH2 ended up also being a
Saturn cpu Quote:
To make a simple reply to the subject, i think the architecture of the SNES is the main reason why we don't see much homebrew for it
[...]
BUT what hurt a lot if the CPU technology itself... Based on 6502 (which is already very basic as a 8 bit CPU), the 65816 is too archaic and definitely more in the range of the 8 bits CPU generation than 16 bits (even with the 16 bits internal ALU), aside the PPU weirdness i was so disappointed when i started programming the 65816, almost each new discovery about this CPU was a disappointment for me
Yet the 6502 itself draws plenty of Atari 2600, Commodore 64, and NES homebrew development, even with all the weirdness of the TIA, VIC-II, and PPU.
I did a bit of SH-X coding but that is definitely very different from the Saturn CPU itself (hopefully :-p)
The 6502 systems you are talking about all come from the 80 years era so the 6502 is not that hurting for these architectures (by miles simpler than the snes) and somehow expected from olds systems like these. But a 65816 cpu in a 90's year system, really *that hurts*...
NES and SNES had the same types of games though.
Something to take into account is that there isn't anything like SGDK but for the SNES. I think nearly all the Genesis homebrewers are just using SGDK (I prefer programming to the bare metal instead). So consider looking into that first.
As for Treasure: something to take into account is that they were making commercial games and that meant tight deadlines. The 68000 instruction set makes it much easier to get things done (both make the code and debug it) and this means they had more room to do crazy things and still manage to stay within the deadlines. The SNES has fast multiplication hardware which should help for stuff like what they did, but the problem is everything else in that sense.
And I wouldn't be surprised if Treasure didn't work with Sony due to how they treated developers (at least small ones).
See what Kenji Eno (RIP) did for the same reason:Quote:
His next big game, Enemy Zero, was meant to be for the PlayStation. His team had already started developing for Sony's platform, but he was upset with how Sony had short-changed his shipment of D, shipping less than a third of what they said they would. So he took his revenge at a Sony press conference. As he walked out on stage to announce his new title, the screen behind him showed a PlayStation logo... that quietly warped into a Sega Saturn logo, and he went on to announce his game for Sony's rival platform, at their own event, simply because they'd backed out of a promise.
Stef wrote:
I did a bit of SH-X coding but that is definitely very different from the Saturn CPU itself (hopefully :-p)
And the "Tom" RISC CPU in the Atari Jaguar is very different from the AMD Jaguar APU in the PlayStation 4 and Xbox One. But I just see "SH" and think "32X, Saturn, and Dreamcast".
Another problem, as I realized when my (now former*) artist visited yesterday, is that there's a set of game designs that cannot be trimmed down to work on the NES but don't quite need a 3D GPU. The Super NES fills that gap, but it turns out not to be very wide, as 93143 mentioned in
this post. This is demonstrated by graphically competent Chinese Famicom demakes of Super NES games such as
Aladdin.
* The reason I say "former" is that my sister told me she's done with 2D games. She wants to work on at least N64, after which point I told her there's not really that much qualitative difference between that and a low-poly PC game.
Sik wrote:
The SNES has fast multiplication hardware which should help for stuff like what they did, but the problem is everything else in that sense.
But it takes a good amount of time to set up the multiplication and division because it's not internal to the 65816. I actually thought that that's where the 65816 was mostly beaten at compared to the 68000, and the lack of any 32 bit instructions doesn't help. In a 2D console though, it isn't as important as it would be otherwise, but still.
Sik wrote:
And I wouldn't be surprised if Treasure didn't work with Sony due to how they treated developers (at least small ones).
I actually just noticed that I've never owned a Sony console, and I own every Nintendo console, (and handheld), a Genesis, and an Xbox 360, and my sister owns an Xbox One but never plays it so it might as well be mine (but I never play it, so...). I like the original PlayStation, but I've never seen the draw to the other ones. The PlayStation 2 doesn't have Super Smash Bros Melee, Super Monkey Ball, or Halo 2, the PS3 doesn't have Halo 3, and the PS4 might as well be the exact same thing as the Xbone. I think a large draw to the PlayStation 2 came from RPGs, and everyone already knows my opinion on them. It's not that it's bad, but I'll just see the PS2 near the top on an "all time" video game console list, while the GameCube and the Xbox are resting at about 10th place. I don't get it. (I have a GameCube and my cousin had an Xbox, so I never had the PlayStation 2 experience or whatever.) I don't know why I felt like sharing that.
tepples wrote:
She wants to work on at least N64, after which point I told her there's not really that much qualitative difference between that and a low-poly PC game.
Hopefully she's not coding in assembly, unless she likes MIPS. I wish her good luck though, as I don't think I've ever really seen any N64 homebrew. In fact, I don't think I've ever seen any GameCube homebrew either, although I've seen a good bit of Wii homebrew like "Ironing Maiden".
Espozo wrote:
The PlayStation 2 doesn't have Super Smash Bros Melee, Super Monkey Ball
Nor does any Nintendo console have
Descent,
Wipeout (not the adaptation of the game show),
Parappa, main series
Katamari,
FantaVision,
Amplitude, or
PlayStation All-Stars Battle Royale. The GameCube doesn't have
Dance Dance Revolution with actual music that people associate with the series. None of the above are RPGs. And I could rattle off plenty of PC exclusives that
none of the consoles has.
Quote:
or Halo 2
I've played
halo two on my PlayStation.
Quote:
tepples wrote:
She wants to work on at least N64, after which point I told her there's not really that much qualitative difference between that and a low-poly PC game.
Hopefully she's not coding in assembly, unless she likes MIPS.
N64 games were typically programmed in C, and GCC targets MIPS. But I think I made my point to her that once we go 3D, we ought to go PC Master Race.
Quote:
I don't think I've ever seen any GameCube homebrew either
The
GameCube version of 240p test suite is available as a GameCube disc image, a GameCube DOL, and a Wii DOL.
tepples wrote:
Nor does any Nintendo console have Descent, Wipeout (not the adaptation of the game show), Parappa, Katamari, FantaVision, Amplitude, or PlayStation All-Stars Battle Royale.
Oh come on, I can list more examples if you want to. I should probably mention I'm not a fan of rhythm games either, so I don't really care about Parappa, Amplitude or Dance Dance Revolution.
There are always the Donkey Konga games on GameCube, but I don't know how good they are because I don't own them. I've never heard of Descent, but it appears to be a PlayStation 1 game. F Zero GX runs circles around any Wipeout game, (actually made by the same team that made Super Monkey Ball at Sega, gotta go fast you know). I've never played Katamari, but it looks... Interesting... FantaVision looks decent, and I'm pretty sure PlayStation All-Stars Battle Royale is a PS3 game.
I think it really comes down to a matter of preference, but I wouldn't think this matter of preference is so one sided that one console is rated substantially better than the other. Well, I know a lot of people do like RPGs, so I guess that's mainly the reason?
tepples wrote:
I've played halo two on my PlayStation.
You've made that joke to me before.
tepples wrote:
I think I made my point to her that once we go 3D, we ought to go PC Master Race.
Uhh... On that note, can't we just say make everything on the PC? Didn't you even list some of the advantages to making a game on a console? I just feel like if we're going to say work on PC for 3D games, then why don't we do 2D games while we're at it? Don't say simplicity, because I'll tell you from working on the SNES that that's a lie.
Stef wrote:
To make a simple reply to the subject, i think the architecture of the SNES is the main reason why we don't see much homebrew for it... The SNES is probably one of the most popular retro gaming system, i'm certain a lot of people tried "to play" with (as i did actually) but got quickly discouraged or frustrated by the complex / convoluted architecture of the system. And by complex i don't mean it in the good way, here the complexity is only a pain and affect what we can do with the system, definitely.
I think this is part of the reason. When you compare the 65816 and 68000, the 68000 is probably more simple/straight forward/easy to understand. The 65816 due to its backwards compatible design has various aspects that can confuse those new to it, and still cause problems for those somewhat familiar with it. However I am not extremely familiar with the 68000 but I do have a lot of experience with the 6502 and that helped a lot with learning the 65816. The Genesis is also probably better suited to C programming than the SNES, though I believe some people have made some SNES homebrew with it. The graphics hardware on the Genesis may also be more straight forward to deal with than the SNES. It does make it harder to produce something on the SNES in theory but I don't see either CPU or PPU as big barriers.
I really think the biggest barrier is just thinking of something worthwhile to do and following through to complete it. The separate things you need to do to make a game aren't really that hard, but you have to have everything to put together into something interesting. The first step is being able to handle all those pieces but eventually you'll need to make something with them.
MottZilla wrote:
I really think the biggest barrier is just thinking of something worthwhile to do and following through to complete it.
That seems like a blanket statement, like saying the difficult part is everything difficult about it. Do you mean to say that what makes it difficult are:
1. Thinking of a concept for a game of SNES magnitude and overall design
2. Creating the assets for the game, like graphics and sound effects / instruments
3. Coding the game to be able to run 1 and 2
I haven't even concerned myself with 1 and 2, and I'm not even halfway done... I don't even really plan on releasing a game anymore, just a flexible but efficient game engine to make it easier for other people to make games. I'm not sure I'll ever finish though or if this idea of mine is realistic, but most platformers and run and guns and shmups and even fighting games can run on slightly modified versions the same code. Irrelevant, but I found out that F Zero GX runs off a modified Super Monkey Ball game engine, although I don't know how changed it is. It does go to show how you don't need to start from scratch though when designing a different style of game, as with sprite based systems, it's not like you need the metasprite code to differ much, if at all. Because I like run and guns and shmups, I have it check to see if the object is only one sprite in the metasprite code for bullets and explosions that take up one sprite to save on processing, but just checking to see how many sprites the object is takes time, so I'd get rid of that bit of code if I were using it in a beat em up were everything is just about guaranteed to be multi sprite.
If it helps to clarify, I mean that programming the actual game in my opinion is the easier part. The harder part is getting all of the artwork, sound, music, etc designed. But that may be because I'm not an artist. If you have the overall idea and all the artwork assets then you'll get a lot further than if you have a general idea with no artwork but decent programming skills. I mean I suppose if you lack the artistic talent you could make a game with primitive or lifted graphics and such.
tepples wrote:
Yet the 6502 itself draws plenty of Atari 2600, Commodore 64, and NES homebrew development, even with all the weirdness of the TIA, VIC-II, and PPU.
In general, the scope of game design for those systems is not in the same league as the SNES or systems of that generation. There's also this community that has grown up around these systems (mainly the small home computer scene) with the mentality of pushing these systems as far as they will go. There's also more merit and recognition in that achievement than say the "16bit generation" - in which everything
pretty much as been explored and done on a commercial level, already.
I see the complex convoluted design and interface of sPPU, coupled with the mirroring attributes of the cpu, to be the primary reason why high level stuff isn't really suited for the SNES. And in that respect, especially now for some reason, that makes it a very active deterrent for people wanting to delve into snes dev. People are afraid to write their own libraries. They want this ready made, flexible, fast lib with high level support - with maybe a dash of ASM here and there. And that's not really applicable on the snes, unless you significantly reduce the scope of your game design - limiting yourself to an overall reduction capable power/resource (getting things done). Speed/power in relation to capability, comes with customized routines specifically for said games. The more flexible and generalized a routine is, the less efficient is becomes in relation to speed.
As far as the asm coders go, the sPPU and cpu shouldn't be a problem though. Yes, it might have an initial steeper learning curve - but once that learning curve is out of the way (as with all systems), you're able to move forward with your project design. The 65x cpu design isn't holding you back. The convoluted sPPU interface/design isn't hold you back. What's holding you back, is the lack of will to learn the system's in and outs. Stef's post is a testament to that.
The Genesis requires little investment to start producing an acceptable product, but in all reality if you want a highly polished product - you're still going to have to invest roughly the same amount of time as you would on the SNES. That initial investment of becoming familiar with the SNES hardware and structure, the time involved and set aside for that, becomes a relatively small portion of what's required to put out a decent product. And I think the biggest problem is that people don't see this. Most people really don't have an accurate idea of how much time and effort goes into making a game to the standards of the commercial soft for era of that system. And it's this inaccurate perception that's, in my opinion, the reason for the lack homebrew on the snes.
Sik wrote:
As for Treasure: something to take into account is that they were making commercial games and that meant tight deadlines. The 68000 instruction set makes it much easier to get things done (both make the code and debug it) and this means they had more room to do crazy things and still manage to stay within the deadlines. The SNES has fast multiplication hardware which should help for stuff like what they did, but the problem is everything else in that sense.
That makes a lot of sense.
Espozo wrote:
But it takes a good amount of time to set up the multiplication and division because it's not internal to the 65816. I actually thought that that's where the 65816 was mostly beaten at compared to the 68000, and the lack of any 32 bit instructions doesn't help.
Multiplication on the 68000 is quite slow (38 to 70 cycles, depending on the second operand), and division is
way too slow (around 140 cycles). You can usually replace division with multiplication (in some form) so that's not much of an issue. As far as multiplication goes though, the SNES should be better, at least for small numbers.
Espozo wrote:
In a 2D console though, it isn't as important as it would be otherwise, but still.
It can be extremely useful for rotations, actually (even if it's just calculating positions).
Espozo wrote:
as I don't think I've ever really seen any N64 homebrew.
Check this out, the guy eventually figured out how to get the N64 hardware draw stuff (using his own microcode) instead of having the CPU do it.
Sik wrote:
Espozo wrote:
But it takes a good amount of time to set up the multiplication and division because it's not internal to the 65816. I actually thought that that's where the 65816 was mostly beaten at compared to the 68000, and the lack of any 32 bit instructions doesn't help.
Multiplication on the 68000 is quite slow (38 to 70 cycles, depending on the second operand), and division is
way too slow (around 140 cycles).
Is that 8*8 or 16*16? The memory-mapped multiplier on the Super NES finishes in about 8 cycles (equivalent of roughly 20 cycles on 68K), but it's only 8*8. There's another 15*8 multiplier that finishes faster (within the 4 cycles it takes to read the value back) but can't be used while mode 7 is active.
I need to figure out a way to work around signed 16x8 while in Mode 7.
Several games that use Mode 7 have a BG status bar at the top/bottom of the screen in a different Gfx mode. Does that mean the 15x8 multiplication regs could be accessible at that time?
Yes. Also don't forget that nearly every mode-7 game has a horizon showing the sky and that definitely is not mode 7 either, so that gives some more room too (i.e. you can go some more beyond vblank safely).
tepples wrote:
Is that 8*8 or 16*16?
16×16 → 32, but usually one of your operands will be a rather small number anyway (unless you're doing something like multiplying by 0x5555 to divide by 3). Also you'd be naive to think that somebody like Treasure wouldn't know how to write code in such a way as to avoid getting locked out of the fast multiplier when needed.
If it's mode 7 math, then yes you can do it during a HUD. If I'm using it for gameplay physics reasons, it could end up being used anywhere in the middle of the frame.
Sik wrote:
Multiplication on the 68000 is quite slow (38 to 70 cycles, depending on the second operand), and division is way too slow (around 140 cycles). You can usually replace division with multiplication (in some form) so that's not much of an issue. As far as multiplication goes though, the SNES should be better, at least for small numbers.
Actually i think that having that "slow" multiplication is still a big advantage definitely.
The SNES only has 8x8 multiplication (the other unit being used by the mode 7, that is not safe for a regular alternative) and I guess that using a 8x8 lookup table is almost as fast than using the multiplier unit (you have to count at least 15/16 cycles for load / read result time) so i don't see the real advantage of having it :-/
And when it comes to 16x16 multiplication (which is for me the minimum if you do real math calculations) the 68000 will be miles faster... even if it is not that fast.
Another thing that is annoying is having to switch between 8-bit and 16-bit modes while doing multiplication, or have a 16-bit accumulator with 8-bit indexes.
Stef wrote:
The SNES only has 8x8 multiplication (the other unit being used by the mode 7, that is not safe for a regular alternative)
Wait, are you saying that you can do 16x8 or 16x16 multiplication with mode 7's multiplication and division registers? Is there any realistic way to "chain" two 8 bit multiplications together like you can do with addition or subtraction? Probably not...
Stef wrote:
(you have to count at least 15/16 cycles for load / read result time)
That's why I was thinking it wouldn't be that fast. 70 to 140 cycles sounds astronomically high to me, but on the SNES, it's more like half which is still ridiculously large, but it's at least somewhat reasonable.
Espozo wrote:
Stef wrote:
The SNES only has 8x8 multiplication (the other unit being used by the mode 7, that is not safe for a regular alternative)
Wait, are you saying that you can do 16x8 or 16x16 multiplication with mode 7's multiplication and division registers? Is there any realistic way to "chain" two 8 bit multiplications together like you can do with addition or subtraction? Probably not...
Not sure if this was what you were asking, but off the top of my head: (a and b are 16-bit numbers)
Code:
a*b = (a_hi*256 + a_lo) * (b_hi*256 + b_lo)
= a_hi*b_hi*256*256 + a_hi*256*b_lo + a_lo*b_hi*256 + a_lo*b_lo
= ((a_hi*b_hi)<<16) + ((a_hi*b_lo + a_lo*b_hi)<<8) + a_lo*b_lo
This could be repurposed for '816. The routine has a large overhead of T1 loading because it's setup for sequential calls were T1 doesn't change, but you could easily switch that to indirect, removing the self-modifying code, and seriously cut that loading over head down by a lot. Also, the tables are split 8bit as well as the math, so that could be optimized into single tables with single sbc's; word wide tables and 16bit operations. A re-write/re-structure for '816 could probably get it close to 70 cycle range.
http://codebase64.org/doku.php?id=base: ... iplication 16x16->32bit mul
Code:
; Description: Unsigned 16-bit multiplication with unsigned 32-bit result.
;
; Input: 16-bit unsigned value in T1
; 16-bit unsigned value in T2
; Carry=0: Re-use T1 from previous multiplication (faster)
; Carry=1: Set T1 (slower)
;
; Output: 32-bit unsigned value in PRODUCT
;
; Clobbered: PRODUCT, X, A, C
;
; Allocation setup: T1,T2 and PRODUCT preferably on Zero-page.
; square1_lo, square1_hi, square2_lo, square2_hi must be
; page aligned. Each table are 512 bytes. Total 2kb.
;
; Table generation: I:0..511
; square1_lo = <((I*I)/4)
; square1_hi = >((I*I)/4)
; square2_lo = <(((I-255)*(I-255))/4)
; square2_hi = >(((I-255)*(I-255))/4)
.proc multiply_16bit_unsigned
; <T1 * <T2 = AAaa
; <T1 * >T2 = BBbb
; >T1 * <T2 = CCcc
; >T1 * >T2 = DDdd
;
; AAaa
; BBbb
; CCcc
; + DDdd
; ----------
; PRODUCT!
; Setup T1 if changed
bcc :+
lda T1+0
sta sm1a+1
sta sm3a+1
sta sm5a+1
sta sm7a+1
eor #$ff
sta sm2a+1
sta sm4a+1
sta sm6a+1
sta sm8a+1
lda T1+1
sta sm1b+1
sta sm3b+1
sta sm5b+1
sta sm7b+1
eor #$ff
sta sm2b+1
sta sm4b+1
sta sm6b+1
sta sm8b+1
:
; Perform <T1 * <T2 = AAaa
ldx T2+0
sec
sm1a: lda square1_lo,x
sm2a: sbc square2_lo,x
sta PRODUCT+0
sm3a: lda square1_hi,x
sm4a: sbc square2_hi,x
sta _AA+1
; Perform >T1_hi * <T2 = CCcc
sec
sm1b: lda square1_lo,x
sm2b: sbc square2_lo,x
sta _cc+1
sm3b: lda square1_hi,x
sm4b: sbc square2_hi,x
sta _CC+1
; Perform <T1 * >T2 = BBbb
ldx T2+1
sec
sm5a: lda square1_lo,x
sm6a: sbc square2_lo,x
sta _bb+1
sm7a: lda square1_hi,x
sm8a: sbc square2_hi,x
sta _BB+1
; Perform >T1 * >T2 = DDdd
sec
sm5b: lda square1_lo,x
sm6b: sbc square2_lo,x
sta _dd+1
sm7b: lda square1_hi,x
sm8b: sbc square2_hi,x
sta PRODUCT+3
; Add the separate multiplications together
clc
_AA: lda #0
_bb: adc #0
sta PRODUCT+1
_BB: lda #0
_CC: adc #0
sta PRODUCT+2
bcc :+
inc PRODUCT+3
clc
:
_cc: lda #0
adc PRODUCT+1
sta PRODUCT+1
_dd: lda #0
adc PRODUCT+2
sta PRODUCT+2
bcc :+
inc PRODUCT+3
:
rts
.endproc
Espozo wrote:
Wait, are you saying that you can do 16x8 or 16x16 multiplication with mode 7's multiplication and division registers? Is there any realistic way to "chain" two 8 bit multiplications together like you can do with addition or subtraction? Probably not...
You can do 8x16 --> 24 multiplication with mode 7 registers but no division as far i know.
And of course you can chain them to obtain a 16x16 --> 32 multiplication :
(8 low) x16 = x
(8 high) x16 = y
then just do a 32 bits addition : x + (y << 8) to get the final 32 bits results.
Still even using the mode 7 registers i bet you spent a large amount of cycle just to do 16x16=32
Quote:
That's why I was thinking it wouldn't be that fast. 70 to 140 cycles sounds astronomically high to me, but on the SNES, it's more like half which is still ridiculously large, but it's at least somewhat reasonable.
Actually on 68000 the multiplication takes up to 72 cycles (for signed version) and up to 140 cycles for the signed division but given some benchmarks i did, you can assume a mean of 50 cycles for multiplication and about 90/100 cycles for division which is not that bad.
With the genesis 68000 cpu (7.67 Mhz) i can transform (3D transformation + 2D projection) about 10000 vertices per second which is not that bad (i expected 6000 max).
A single 3D transformation consist of :
- 9 16x16=32 multiplication
- 6 32bit additions
- 3 16bit additions
A single 2D projection consist of :
- 3 16bit additions
- 1 32:16=16 division
- 2 16x16=32 multiplication
The projection could be different but i handled it that way for convenience.
Still that is a big amount of complexes operations and i don't count the load / store / shift operations here.
If we just count maximum cycles of mul and div, we already obtain (11*70) + 140 which is close to 1000 cycles per vertex ! So we shouldn't be able to transform more than 8000 vertices per second just because of these operations... but hopefully that is not the case. I wonder how much we could transform with the SNES hardware using smart interlacing of operations with the different available multiplier / diviser units
tomaitheous wrote:
This could be repurposed for '816. The routine has a large overhead of T1 loading because it's setup for sequential calls were T1 doesn't change, but you could easily switch that to indirect, removing the self-modifying code, and seriously cut that loading over head down by a lot. Also, the tables are split 8bit as well as the math, so that could be optimized into single tables with single sbc's; word wide tables and 16bit operations. A re-write/re-structure for '816 could probably get it close to 70 cycle range.
http://codebase64.org/doku.php?id=base: ... iplication 16x16->32bit mul
Interesting
is there the same for signed multiplication (which is more useful) ? I guess it only requires different lut.
Edit: I found the signed version which add some cycles at the end of the multiplication operation, signed operands process a bit slower because of that, still that is a fast implentation for the 6502 CPU
Stef wrote:
Interesting
is there the same for signed multiplication (which is more useful) ? I guess it only requires different lut.
Edit: I found the signed version which add some cycles at the end of the multiplication operation, signed operands process a bit slower because of that, still that is a fast implentation for the 6502 CPU
Code:
; Description: Signed 16-bit multiplication with signed 32-bit result.
;
; Input: 16-bit signed value in T1
; 16-bit signed value in T2
; Carry=0: Re-use T1 from previous multiplication (faster)
; Carry=1: Set T1 (slower)
;
; Output: 32-bit signed value in PRODUCT
;
; Clobbered: PRODUCT, X, A, C
.proc multiply_16bit_signed
jsr multiply_16bit_unsigned
; Apply sign (See C=Hacking16 for details).
lda T1+1
bpl :+
sec
lda PRODUCT+2
sbc T2+0
sta PRODUCT+2
lda PRODUCT+3
sbc T2+1
sta PRODUCT+3
:
lda T2+1
bpl :+
sec
lda PRODUCT+2
sbc T1+0
sta PRODUCT+2
lda PRODUCT+3
sbc T1+1
sta PRODUCT+3
:
rts
.endproc
Yeah, those two groups of 8bit SBCs could be optimized down to one each for '816. So worse case is two 16bit subtractions for signed overhead. Though I think a slightly more optimal routine could be written for signed input/output.
Indeed, someone should rewrite an optimized version for the 65816, would be pretty useful
I think I figured out how Tomaitheous's code works. This is basically the math equation:
LUT1(a+b) - LUT2(255-a+b)
LUT1(x) = (x^2)/4
LUT2(x) = ((x-255)^2)/4
((a+b)^2)/4 - ((255-a+b-255)^2)/4=
((a+b)^2)/4 - ((-a+b)^2)/4 =
((a+b)^2 - (-a+b)^2)/4 =
(a^2 + 2ab + b^2 - (a^2 - 2ab + b^2))/4 =
(a^2 + 2ab + b^2 - a^2 + 2ab - b^2)/4 =
4ab/4 = ab
I don't know how the rounding error somehow gets cancelled out.
I use multiplication for calculating the rotation of the bosses' joints. The sines and cosines are 16-bit signed values from -256 to 256, and the radius is a signed 8-bit values. The result is a signed 16-bit value.
I thought of a fast routine that uses non-mode-7 multiplication registers.
Code:
sine_multiplication:
lda #$0000
sep #$20
cpy #$80
bcc +
sbc sine_lo,x //clears carry for upcomming adc
+;
sty $4202
ldy sine_hi,x
sty $4203
ldy sine_lo,x
adc $004216 //wastes one cycle
sty $4203
xba
rep #$21
adc $4216
rts
What really boggles my mind about slowdown is when games lag with 4 sprites, while other games can have more than 40. You mean to tell me they programmed every routine 10 times slower than necessary?
What's even more odd is that the games with heavy slowdown seem to have a higher threshold on the second lag frame as if running the game itself takes a lot of overhead. Like, it takes 4 sprites to make it run at 30fps, but with 10 sprites onscreen, it STILL runs at 30fps? WTF?
The dataGame A
1-3 objects: 60 fps
4-10 objects: 30 fps
Game B
40 objects: 60 fps
Speculation as to causeFor purpose of argument, I'll
assume good faith, imputing no malice where incompetence is sufficient (
Hanlon's razor), nor incompetence when bona fide intractability is sufficient.
As for the difference between the games: Some games have more complicated collision detection and path finding algorithms and may thus slow down with fewer active objects. I doubt that individual spread-gun bullet sprites in
Contra or even ships in
Recca have very complicated movement.
As for why 10 is no slower than 4: Perhaps there is a constant overhead equivalent to seven objects, such as decoding the map into background update packets. Or perhaps the player character is as complex as two or three objects. I know the walking characters in
Haunted: Halloween '85 (the player and the zombies) are the most algorithmically complex because they have to read the collision map four times (bottom center, left, and right, and head-height at leading edge), compared to everything else that reads it once (bottom center) or not at all. Incidentally, I had to do a shload of optimization to the code that parses collision slabs to get it to work well with six walkers (the player and five zombies) on the most platform-filled levels (such as the barn) without slowing down.
What's funny is that I just got 1943 from a local video game store, Game X Change, (don't know why I felt like sharing that) and I played it and it's a ton better about not slowing down than Gradius III which I also got, except that this one is on the SNES... That's what really boggles my mind.
Isn't the SNES's CPU supposed to be something like 4x faster than the one in the NES?
Now that I think about it, I think most people mistakenly identify object collision as speed-critical code, when it could actually be the BG collision that bogs the cpu down. I wonder if slopes have anything to do with it, because a lot of NES games didn't use slopes.
Edit: I changed the wording, because I'm not exactly sure if this is totally accurate.
psycopathicteen wrote:
BG collision that bogs the cpu down.
Oh yeah... There's no BG to bump into in that game.
I think I should try to investigate the BG collision routines in other games and compare it with my own game to find out if this is where the "horror code" lives.
I've already investigated how the BG collision in Super Castlevania 4 works, but I didn't measure exactly how much time is spent.
Edit: Looked at the traced code again. SCV4 spends 20 scanlines just to do BG collision with the player character. Now I need to check other games to see if the have anything similar.
Espozo wrote:
Isn't the SNES's CPU supposed to be something like 4x faster than the one in the NES?
It's not quite twice as fast. The NES CPU runs at 1.78mhz where as the SNES CPU runs between 2.68mhz and 3.58mhz. If it were to run always at the top frequency of 3.58mhz and didn't have DRAM refresh periods frequently then it would run twice as fast.
However the PC-Engine/TurboGrafx 16 CPU runs 4x faster than the NES CPU running over 7mhz, and thus basically a bit more than twice as fast as the SNES CPU.
tepples wrote:
I know the walking characters in Haunted: Halloween '85 (the player and the zombies) are the most algorithmically complex because they have to read the collision map four times (bottom center, left, and right, and head-height at leading edge), compared to everything else that reads it once (bottom center) or not at all.
Normally you can get away with just checking once per axis (usually the problems from that tend to be minor and self-correcting).
Players are notoriously more complex in general though. For starters, unless you're using the same routine for everything, they're the only ones to have full blown physics (collision all ways, acceleration, slopes, checks against background
and platforms, etc.), while most objects usually just have the bare minimum for what they do. Also, players are the only ones to have many actions (idle, running, jumping, swimming, crouching, hurt animation, etc.)
and potentially could switch between them at any moment, while most objects just have a couple of simple actions and maybe a collision check and not much else to worry about.
psycopathicteen wrote:
I wonder if slopes have anything to do with it, because a lot of NES games didn't use slopes.
The problem with slopes is not so much that they're slower (it's not that bad) but the fact that they're notoriously hard to get right, and by "right" I mean "things don't suddenly jump when going downhill or suddenly stop when going uphill" (especially the jump part). That usually requires a lot of hacks to get working within your limited physics engine. No wonder they were usually avoided (and even into the 16-bit era, usually only players would handle slopes, since it was easier to have everything else just treating tiles as "solid or empty")
MottZilla wrote:
Espozo wrote:
Isn't the SNES's CPU supposed to be something like 4x faster than the one in the NES?
It's not quite twice as fast. The NES CPU runs at 1.78mhz where as the SNES CPU runs between 2.68mhz and 3.58mhz. If it were to run always at the top frequency of 3.58mhz and didn't have DRAM refresh periods frequently then it would run twice as fast.
That's without factoring in the gain from 16-bit operations, which is substantial but can be a bit slippery as it is application-dependent. Movement code is an example - adding a 16-bit number to a 24-bit number is far quicker on the SNES than on the NES.
MottZilla wrote:
Espozo wrote:
Isn't the SNES's CPU supposed to be something like 4x faster than the one in the NES?
It's not quite twice as fast. The NES CPU runs at 1.78mhz where as the SNES CPU runs between 2.68mhz and 3.58mhz. If it were to run always at the top frequency of 3.58mhz and didn't have DRAM refresh periods frequently then it would run twice as fast.
However the PC-Engine/TurboGrafx 16 CPU runs 4x faster than the NES CPU running over 7mhz, and thus basically a bit more than twice as fast as the SNES CPU.
The 65816 is more cycle efficient than the 6502 as long as the programmer knows what their doing.
Sik wrote:
psycopathicteen wrote:
I wonder if slopes have anything to do with it, because a lot of NES games didn't use slopes.
The problem with slopes is not so much that they're slower (it's not that bad) but the fact that they're notoriously hard to get right, and by "right" I mean "things don't suddenly jump when going downhill or suddenly stop when going uphill" (especially the jump part). That usually requires a lot of hacks to get working within your limited physics engine. No wonder they were usually avoided (and even into the 16-bit era, usually only players would handle slopes, since it was easier to have everything else just treating tiles as "solid or empty")
I don't remember seeing any game that doesn't allow enemies to walk on sloped platforms. Maybe I just never noticed it before because nobody ever pointed it out to me.
psycopathicteen wrote:
I don't remember seeing any game that doesn't allow enemies to walk on sloped platforms.
I wouldn't be surprised if they at least used a simplified form of slope handling for objects other than the player. I know that the Sonic games did this... Enemies are placed at the correct height on slopes, but the angle doesn't affect them at all, it's like they're always walking on straight ground. You can easily notice this if you use the debug mode to place enemies near loops or quarter pipes. They ascend insanely fast, because their horizontal movement isn't attenuated by the angle, and their Y coordinate is adjusted to match the height of the slope.
Quote:
Maybe I just never noticed it before because nobody ever pointed it out to me.
There are a lot of limitations games managed to hide from us pretty well. I'm pretty sure there are many cases where level design and object placement are carefully planned to avoid tricky situations.
Other ways SNES is more efficient...
-Separate processor to handle music, don't have to waste CPU cycles running a music engine
-tons more RAM, don't have to do things twice if you can store it in RAM for later
-much more efficient moving large chunks of data around
(DMA)
-larger sprites, don't have to waste cycles contructing metasprites.
Downside of SNES dev...the expectations are much higher, it's assumed that an SNES game should look as nice as SMW.
dougeff wrote:
Downside of SNES dev...the expectations are much higher, it's assumed that an SNES game should look as nice as SMW.
This is the essence of what I was trying to say in points c (color use) and d (parallax layer use) of my
first post. But most of this topic has been about the 65816 CPU, with only a few posts addressing the expectation of production values:
Bregalad wrote:
However you can always come up with cheaper graphics that don't push the system to it's limit.
tepples wrote:
And open yourself to "Why didn't you just make it for the NES?"
psycopathicteen wrote:
It shouldn't be that difficult to develop an SNES game that looks like an NES game.
MottZilla wrote:
The harder part is getting all of the artwork, sound, music, etc designed.
MottZilla wrote:
However the PC-Engine/TurboGrafx 16 CPU runs 4x faster than the NES CPU running over 7mhz, and thus basically a bit more than twice as fast as the SNES CPU.
And thus almost twice as fast as the 68000?
(I mean, the way you just calculated it there anyway.)
It seems the TurboGrafx is a bit unbalanced in design, like having a 7+mhz 6502 variant but with only 8KB of ram. I'm not sure how anyone was able to manage with that given the general complexity of games on the system.
tokumaru wrote:
There are a lot of limitations games managed to hide from us pretty well. I'm pretty sure there are many cases where level design and object placement are carefully planned to avoid tricky situations.
The DKC games are carefully designed around the 8 sprite palette limit. There are situations like climbing a rope that stop you from doing things like carrying barrels too far, or ditches that stop enemies from traveling to far if you follow them. The tiles often get messed up because there's not enough vram for how they're managing it.
Actually, you know what I just thought of? If you're using 8x8 and 16x16 sized sprites, you don't even need to search every 8x8 block for a vram engine, because all 128 16x16 sized sprites just fit it. I mean, that's if you're using that much. You could even assign sprite a spot in vram.
Yeah, if each sprite is using individual tiles, then 32x32 sprites are actually kind of pointless.
dougeff wrote:
it's assumed that an SNES game should look as nice as SMW.
So not very?
Espozo wrote:
dougeff wrote:
it's assumed that an SNES game should look as nice as SMW.
So not very?
My thoughts exactly. As I see it, SMW is to the SNES what SMB is to the NES. The graphical potential of the console is severely underused.
Maybe dougeff meant "at least as nice as SMW", which is like, a little bit better than some late NES titles?
I'd actually argue that it's even worse in terms of effort put in. There isn't that much shading, and the shading that exists isn't too spectacular, and the sprites aren't any larger than what you'd find on the NES (and the animation isn't any smoother because of the limited vram system), so the amount of effort it takes to do all this is less than trying to fit everything within the NES's constraints. I think SMB 3 actually looks better overall. The sprites are cleaner and the artwork is more consistent. Then again, I like SMB3 a whole lot better anyway.
I never understood, did Nintendo forget to outline this or something? It sticks out from the rest of the sprites like a sore thumb:
Attachment:
Lava Monster.png [ 735 Bytes | Viewed 2528 times ]
You want to know another thing that always looked weird to me in SMW? A lot of the color gradients are kind of poorly done. You'll see something like the green on the pipe have some red, then not have red, then have red again even if the green is increasing. Just an observation.
SMW uses lots and lots of 4-color and 8-color graphics, which is the reason it looks so simple compared to a lot of other contemporary/later SNES titles. Given the amount of time it was in development (supposedly ~3 years, probably close to the release of SMB3), I think a lot of the graphics were made before the technical details of the SNES had even come close to being finalized, so they just played it safe.
I was under the impression that the SNES was originally supposed to be more powerful, not the other way around. I really have no clue how that game took 3 years to make. I'm pretty sure DKC was made in about a year.
Not just technical though, a lot of the artwork, simple or not, just doesn't look that good. Maybe Irem just has me spoiled.
Aren't the BG tiles actually only 3bpp in order to save space on the cartridge? I mean, this doesn't justify the sprites though, which are the main problem.
Quote:
It seems the TurboGrafx is a bit unbalanced in design, like having a 7+mhz 6502 variant but with only 8KB of ram.
This is because the PCE has no restricted acces to VRAM, you can decompress or modify SAT/BAT directly in vram, without any RAM buffer .
In fact is less problematic than it seems,but it is if you are coding like a system with allowed VRAM acces only in vblank .
Quote:
Other ways SNES is more efficient...
-Separate processor to handle music, don't have to waste CPU cycles running a music engine
-tons more RAM, don't have to do things twice if you can store it in RAM for later
-much more efficient moving large chunks of data around
(DMA)
-larger sprites, don't have to waste cycles contructing metasprites.
Fast shortcuts here ..
Quote:
-Separate processor to handle music, don't have to waste CPU cycles running a music engine
Yes but without any mechanism for accessing ROM/WRAM to refresh his limited amount of RAM for a sample based sound processor, it's not really an advantage.
PCE can do better samples without any dedicated sound processor .
Quote:
tons more RAM, don't have to do things twice if you can store it in RAM for later
Yes but too slow for 65xxx, better to have 32ko of fast ram than this shity DRAM imo ..
Quote:
-larger sprites, don't have to waste cycles contructing metasprites.
Yes but it's relevant with a descent SAT/OAM organisation and not with only two size allowed at the same time. In the snes's case,it'is a little bit useless .
tokumaru wrote:
Maybe dougeff meant "at least as nice as SMW", which is like, a little bit better than some late NES titles?
That's what I guessed too. SMW has 7-color shading (even if not 15-color) and parallax.
Espozo wrote:
I never understood, did Nintendo forget to outline this or something? It sticks out from the rest of the sprites like a sore thumb:
Attachment:
Lava Monster.png
Blargg appears only in skull-raft levels, and all these levels are on black backgrounds. It isn't outlined for the same reason sprites in
Donkey Kong and
Metroid aren't outlined.
tepples wrote:
SMW has 7-color shading (even if not 15-color)
And they wasted it on dumb gradients and unbalanced contrast...
A good NES artist could do wonders with that.
Mario's dull pink hat always bugged me. They used pure red for everything else in the game, why didn't they just use pure red for Mario's hat as well?
Espozo wrote:
MottZilla wrote:
However the PC-Engine/TurboGrafx 16 CPU runs 4x faster than the NES CPU running over 7mhz, and thus basically a bit more than twice as fast as the SNES CPU.
And thus almost twice as fast as the 68000?
(I mean, the way you just calculated it there anyway.)
It seems the TurboGrafx is a bit unbalanced in design, like having a 7+mhz 6502 variant but with only 8KB of ram. I'm not sure how anyone was able to manage with that given the general complexity of games on the system.
I'm not sure what you mean. The 68000 I assume you mean in the Genesis is clocked slightly faster than the PC-Engine's CPU but they are completely different designs and a simple clock speed comparison isn't as valid as it is when comparing NES, SNES, and PCE which all share the same basic cpu design.
The TurboGrafx 16 having only 8KB of RAM clearly wasn't unmanageable. Most of the types of games that were being made at the time didn't need a whole lot of RAM. And when the CD-ROM system came along, you had more RAM than either SNES or Genesis if you wanted it for game variables or buffers. I don't think many SNES games or Genesis games are really going to need a large percentage of the RAM available. That's not to say they don't use it, because if it's there a programmer will probably use it. But you could certainly optimize or do things in a different way to get by with less. SNES and Genesis games are probably more likely to have large buffers or arrays of data to be readily accessed.
I know that one or more of the SNES Mega Man titles uses a large chunk of WRAM to store and restore the background map when you pause the game. That certainly isn't necessary but they had the memory to do it, so they did it. Probably made the programmer's job a lot less complicated.
And once you get into "why did they do this" or "they should have done this" you can say that about every console and talk about it forever. For example I've thought that Sega should have outfitted the Genesis VDP with enough Color RAM for 128 Colors instead of 64 and made the Background and Sprites use different section like the NES or SNES does. In my mind it would have been a bit improvement for what I can only suspect would have been a manageable cost. Or we could go on to why Nintendo didn't do something to clock the SNES CPU faster. Or why Sony never came out with a RAM cartridge for the Playstation 1 as Sega did for the Saturn.
Quote:
Or we could go on to why Nintendo didn't do something to clock the SNES CPU faster.
Nintendo didn't expect anybody to write such inefficient code.
TOUKO wrote:
Yes but it's relevant with a descent SAT/OAM organisation and not with only two size allowed at the same time. In the snes's case,it'is a little bit useless .
I'd say the organization of it cancels out its usefulness. I never quite understood the hate on the sprite system though. The only real legitimate complain I have is that there's only a fourth of vram available for it. They should have made tiles for sprites 16x16 like the Turbografx so sprites could occupy all of vram. You could even keep 8x8 sprites, but the only advantage you'd get is sprite pixels per scanline, but I guess you could actually also store BG tile data. Just saying, 16x16 and 32x32 is easily the best sprite size configuration. 64x64 with anything is completely useless. I would actually prefer a color math enable bit over an extra size bit.
SNES and Turbografx sprite capabilities really are about the same aside for vram. I think you can make every sprite configuration on the Turbografx with 64 sprites that you can on the SNES with 128 16x16 and 32x32 sprites, aside from one where there are 64x16 sized sprites on the Turbografx? One thing that people are forgetting is that the SNES has more sprites, so it's actually more flexible in that regard, although it's also more to process if you're pushing a bunch of sprites. (I've never seen a game use past 80...)
psycopathicteen wrote:
Mario's dull pink hat always bugged me. They used pure red for everything else in the game, why didn't they just use pure red for Mario's hat as well?
I never liked the color of the overalls either. It's like the brightness was turned up.
psycopathicteen wrote:
Quote:
Or we could go on to why Nintendo didn't do something to clock the SNES CPU faster.
Nintendo didn't expect anybody to write such inefficient code.
I actually kind of feel the same way. I mean, if developers (excluding Micronics among others) didn't have a problem making games on the 1.78mhz 6502, then they shouldn't have a problem making slightly more advanced games on a 16 bit processor clocked 2x as fast, right? The one thing were this breaks down though is that Nintendo wasn't necessarily the best themselves, but still better than many others.
Quote:
They should have made tiles for sprites 16x16 like the Turbografx so sprites could occupy all of vram.
The PCE have more size than 16x16, you can have 16x32,16x64,32x16,32x32,32x64 and you can have all that sprites size in your frame at same time,but unfortunately no tiles under 16 pixels .
Quote:
SNES and Turbografx sprite capabilities really are about the same aside for vram.
Not really, PCe can use all his VRAM space for sprites .
Quote:
One thing that people are forgetting is that the SNES has more sprites, so it's actually more flexible in that regard, although it's also more to process if you're pushing a bunch of sprites. (I've never seen a game use past 80...)
yes but don't forget more sprites to manage, more CPU to spend for .
tokumaru wrote:
I wouldn't be surprised if they at least used a simplified form of slope handling for objects other than the player. I know that the Sonic games did this...
That's because
everything in that engine is a slope (walls are just very steep slopes), so it's actually kind of required for enemies to handle slopes in that game. But yeah, even then it's limited: they can handle a height difference of 1 pixel (without any momentum adjustment), but that's it. Becomes obvious with motobugs, where they'll stop immediately the moment they try to go through a 45º slope (i.e. the bottom of a loop). The enemies launching drills in Hydrocity maybe are a better example, since there a few actually placed next to a loop.
Espozo wrote:
I was under the impression that the SNES was originally supposed to be more powerful, not the other way around. I really have no clue how that game took 3 years to make.
The SNES was also being publicly promoted quite early too. It's likely SMW took that long as the hardware was being developed (and also why it looks to take so little advantage of it, it was a constantly moving target).
MottZilla wrote:
For example I've thought that Sega should have outfitted the Genesis VDP with enough Color RAM for 128 Colors instead of 64 and made the Background and Sprites use different section like the NES or SNES does.
That was their original intention, but they ran out of die space ¯\(º_o)/¯ (instead we got less-used features like S/H that took up less room) There's a good reason why the VDP can use an external color DAC, but again that'd have made the console more expensive (ugh).
Espozo wrote:
I never quite understood the hate on the sprite system though. The only real legitimate complain I have is that there's only a fourth of vram available for it.
The hate comes from the fact the MSB of the X coordinate and sprite size are stored separately. Alright, but the real problem is that this area decides to pack four entries into a single byte, making things way more complex than needed
and resulting in slower code. Ugh!
For the record, since OAM is in on-die memory, they could have easily just made it look like 768 bytes (i.e. one address per entry) but not store the redundant bits (resulting in about the same amount of die space). Would have made things much easier for developers, even if that most likely took a hit in DMA bandwidth.
TOUKO wrote:
The PCE have more size than 16x16, you can have 16x32,16x64,32x16,32x32,32x64 and you can have all that sprites size in your frame at same time,but unfortunately no tiles under 16 pixels .
Yeah, I meant, like how the minimum sprite size is 16x16, so I said 16x16 tiles. I'm pretty sure the Turbografx 16 has 9 bits for selecting tiles, it's just that it's going by 16x16 instead of 8x8? I mean, I don't think not having 8x8 sprites is that big of a loss. (referring to not having them on the Turbografx 16 or the SNES with 16x16 and 32x32 sprites selected.) Most arcade machines that I've seen didn't even support tiles that small, although they had plenty more sprite pixels per scanline.
TOUKO wrote:
Not really, PCe can use all his VRAM space for sprites .
I said aside for vram, although that is a big factor. I didn't know the PCE was a male.
TOUKO wrote:
yes but don't forget more sprites to manage, more CPU to spend for.
True. The one advantage you have to the SNES sprite system has though is that although the total sprite area is the same as the Turbografx 16, it's more flexible in that it can be divided up (instead of a 16x32, you can have two 16x16s) which is nice for shoot em ups, but with how many developers were programing, they couldn't take advantage of that because of limited CPU power.
Sik wrote:
The hate comes from the fact the MSB of the X coordinate and sprite size are stored separately. Alright, but the real problem is that this area decides to pack four entries into a single byte, making things way more complex than needed and resulting in slower code. Ugh!
I mean, you deal with it once when you make your metasprite code and you don't have to deal with it again, although the processing part is still a problem. Like I said though, if you have limited vram for sprites, you'll try to do fancy things to try to make the most out of the space, and if you're doing that, you're taking up more CPU time then you are for the 9th x bit and size bit.
Espozo wrote:
I mean, you deal with it once when you make your metasprite code and you don't have to deal with it again
I could say that about most stuff, the problem is getting it to work at all (
and performing well) in the first place. For many people that must be a headache. Just because you do it once doesn't mean it won't make you hate it =P
Sik wrote:
Espozo wrote:
I mean, you deal with it once when you make your metasprite code and you don't have to deal with it again
I could say that about most stuff, the problem is getting it to work at all (
and performing well) in the first place. For many people that must be a headache. Just because you do it once doesn't mean it won't make you hate it =P
Well, I just hijacked psychopathicteen's code.
Really though, making a good vram engine is much, much worse. I really feel like Nintendo should have released code to people for handling hioam, like how they did with initialization.
This is how it was like back in the day for a developer.
Programmer 1: We need a hi-oam code fast!
Programmer 2: Why don't you just hijack psycopathicteen's code?
Programmer 1: Psycopathicteen isn't even potty trained yet!
Programmer 2: Oh NOOOOOOOOO!!!!
Espozo wrote:
Really though, making a good vram engine is much, much worse.
Because you all insist on it. Nearly every game out there just hardcoded the VRAM addresses.
Espozo wrote:
I really feel like Nintendo should have released code to people for handling hioam, like how they did with initialization.
To be fair, do we know if they really didn't? E.g. I know Sega did release some sample code (mainly to show that their devkits worked), but I don't think many developers used it... at least on the Japanese side of things.
Sik wrote:
Espozo wrote:
Really though, making a good vram engine is much, much worse.
Because you all insist on it. Nearly every game out there just hardcoded the VRAM addresses.
It isn't nearly as efficient with saving tile space though, which is important on the SNES. The problem with this kind of approach though is that you're not 100 percent sure everything will fit in vram at a given time, but this isn't any different then sprite dropout, and just about every NES game after 1987 has that. Just thinking, 3D systems are kind of the same way. If you were planning everything for the worst, but unrealistic, scenario, then you couldn't get away with as much.
Quote:
Yeah, I meant, like how the minimum sprite size is 16x16, so I said 16x16 tiles.
Ah ok sorry espozo
Quote:
I'm pretty sure the Turbografx 16 has 9 bits for selecting tiles
No, it has 11 bits
Quote:
it's just that it's going by 16x16 instead of 8x8
Yes
,and you lose some sprite bandwidth when only 8x8 sprites are needed .
Quote:
I didn't know the PCE was a male.
Of course, and with big balls
i'am curious to know how many cycles take to write an entire sprite attributes on MD .
@espozo: Bad coding exist on all systems, doing a good one (in any department) needs a big amount of time.Now we are coding for pleasure, with no deadlines, we have time, and it's easy to optimise our stuffs like hell,redoing code if it's not good enough,etc ..
You absolutely can not comparing nowadays stuff with 90's ones .
TOUKO wrote:
No, it has 11 bits
You mean it goes by 8x8, although the minimum sprite size is 16x16?
TOUKO wrote:
Yes ,and you lose some sprite bandwidth when only 8x8 sprites are needed .
Well, most things aren't even that small to begin with, aside from bullets which can be a problem. I still think 16x16 and 32x32 is the best sprite size on the SNES, because if you're using 8x8 and 16x16, instead of having to worry about sprites being clipped, you'll have to worry about sprites actually disappearing.
TOUKO wrote:
You absolutely can not comparing nowadays stuff with 90's ones .
That's exactly why I don't get why people are trying to be so stingy with things that don't matter anymore, like cartridge size. What you do is you just don't judge games with a lot of memory graphically to ones that do, just like I wouldn't compare an SNES game that tries to do 3D by the CPU to one that's using the Super FX.
TOUKO wrote:
Of course, and with big balls
Are all of them male? I mean, you got to have a female to reproduce...
Espozo wrote:
TOUKO wrote:
Yes ,and you lose some sprite bandwidth when only 8x8 sprites are needed .
Well, most things aren't even that small to begin with, aside from bullets which can be a problem.
With a username that close to TOUHOU, bullets were probably at top of mind.
Espozo wrote:
I still think 16x16 and 32x32 is the best sprite size on the SNES, because if you're using 8x8 and 16x16, instead of having to worry about sprites being clipped, you'll have to worry about sprites actually disappearing.
Why? Because of the 128 sprite limit of OAM or the 32 sprite limit? The 32 sprite limit isn't really that much lower than the 34 sliver limit.
Quote:
I don't get why people are trying to be so stingy with things that don't matter anymore, like cartridge size.
It's also expensive to use a 16-bit memory like 29F322 with an 8-bit data bus. Memories with an 8-bit mode, which can directly interface with the thing, are limited to 16 Mbit. The other option is to build a "poor man's PowerPak": a 4 Mbit PSRAM, an eMMC, and an interface chip that reads the eMMC and holds the CPU in reset until the boot sector is copied to RAM.
tepples wrote:
It's also expensive to use a 16-bit memory like 29F322 with an 8-bit data bus. Memories with an 8-bit mode, which can directly interface with the thing, are limited to 16 Mbit. The other option is to include a RAM on the cartridge, an eMMC, and an interface chip that reads the eMMC and holds the CPU in reset until the boot sector is copied to RAM.
Only (edit:
new) 5V parallel NOR ROMs are limited to 2 MiB/16Mibit. It's for now still cheaper to just add the voltage translation circuitry with a 3V NOR ROM (up to 128 MiB) than the complexity of adding a bootloader.
tepples wrote:
Why? Because of the 128 sprite limit of OAM or the 32 sprite limit? The 32 sprite limit isn't really that much lower than the 34 sliver limit.
Oh, I should have been more clear. I mean games running out of sprites because they're using so much and then there's sprite flicker. When I said no game uses more than 80, I was thinking of 16x16 and 32x32, not 8x8 and 16x16.
The game that comes to mind is Super R-Type. On the 3rd level at the part with the ships that fly forward upon being hit, the game will somethimes go crazy and things will appear and disappear out of existence. The diffusion wave beam is also a lot lamer than it is in R-Type II because they were more cautious of how many sprites were being used.
lidnariq wrote:
It's for now still cheaper to just add the voltage translation circuitry with a 3V NOR ROM (up to 128 MiB) than the complexity of adding a bootloader.
To allow saved games, is it cheaper to make the voltage translation bidirectional to allow writing back to flash or to include a battery-backed RAM?
Quote:
Bad coding exist on all systems, doing a good one (in any department) needs a big amount of time.Now we are coding for pleasure, with no deadlines, we have time, and it's easy to optimise our stuffs like hell,redoing code if it's not good enough,etc ..
You absolutely can not comparing nowadays stuff with 90's ones .
I always find it weird when people say this. Do people think I spend all my time optimizing code?
Good chunk of your posts are about making some bit faster/better, so it kinda gives people that impression
TmEE wrote:
Good chunk of your posts are about making some bit faster/better, so it kinda gives people that impression
Well it makes no sense to get my game to run at 70fps if neither the TV or the system can output 70fps.
EDIT: When I was younger I think I wasted a lot of time optimizing code when I didn't really need to. A lot of my old code had a lot of ugly unrolled loops.
tepples wrote:
lidnariq wrote:
It's for now still cheaper to just add the voltage translation circuitry with a 3V NOR ROM (up to 128 MiB) than the complexity of adding a bootloader.
To allow saved games, is it cheaper to make the voltage translation bidirectional to allow writing back to flash or to include a battery-backed RAM?
Bidirectional translation can be as simple as using the CPU R/W pin on the 'direction' input of something like a 74LVC245. That's my plan anyways, I expect it'll work (I think the Everdrive does something similar as well). That's about a 10 cent part, 3 of those is most of what you'd need (if your mapper is 3V). For a battery you'd have a 30 cent battery clip, 25 cent battery, 25 cent voltage supervisor, some extra diodes, caps, resistors, and possibly a larger PCB to hold that big ol' battery. The price difference isn't huge if you already have the RAM onboard, but it is more parts and the battery will fail sooner or later (much later if you select the right SRAM and diodes). Yeah, I've been pricing all this stuff in the past few days.. guess why.
Anyways, writing to flash on-cart is almost necessary, as the alternative is programming them before soldering, which is a terrible idea.
psycopathicteen wrote:
Well it makes no sense to get my game to run at 70fps if neither the TV or the system can output 70fps.
I see "70fps" and immediately think of VGA mode 13h. But "70fps" in the sense of ensuring that 16 percent of CPU time is almost always free might help avoid dropping from 60 to 30 fps in worst cases.
Memblers wrote:
Anyways, writing to flash on-cart is almost necessary, as the alternative is programming them before soldering, which is a terrible idea.
How "terrible"? Mask ROMs were "programmed" (that is, fabricated) before soldering, and EPROMs during the Super NES's commercial era were programmed before socketing. But you're right that writable flash is useful. It is probably more practical on Super NES than on NES because a Super NES game probably doesn't also need the work RAM onboard for other things, as it has the absurdly spacious (by NES or TG16 standards) area at $7E2000-$7FFFFF.
tepples wrote:
How "terrible"? Mask ROMs were "programmed" (that is, fabricated) before soldering, and EPROMs during the Super NES's commercial era were programmed before socketing.
TSOP/SSOP ZIF adapters for putting in a programmer are expensive and fiddly. It's far easier to get a PCB assembly place to just put the not-pre-programmed memories on, because they will have access to much better soldering tools than you (probably), and using a card edge connector to program is much easier.
Quote:
You mean it goes by 8x8, although the minimum sprite size is 16x16?
11 bits for sprite patterns, a complete sprite attributes is 4 words, 1st word for Y position,2nd for X position, 3rd for pattern, and 4th for size,flip, palette .
On the 3rd, 11 bits is used .
I am also confused by this? Why does it have 11 bits if the PCE can't use 8x8 sprites?
According to
pcetech.txt, the TG16's nametable format is oversize, with an intended range of 128K, presumably for future expansion:
Code:
FEDC BA98 7654 3210 Nametable entry
|||| ++++-++++-++++- 8x8 tile number (0-2047 valid; 2048-4095 unspecified)
++++---------------- Palette
The tile number register for sprites also addresses 128K:
Code:
FEDC BA98 7654 3210 Sprite attribute 2
||| |||| |||+- CG mode bit (used in 2-bit sprite mode)
+++-++++-+++-- 16x16 tile number (0-511 valid; 512-1023 unspecified)
The VDC was designed to use either fast or slow VRAM. The TG16 shipped with fast VRAM, but the VDC retains the bits in register 9 specifying memory speed alongside the bits that specify nametable size. One of the slow modes apparently produces 4-color tiles instead of 16-color ones, and the CG mode bit specifies which half-tile to use.
tepples wrote:
with an intended range of 128K
Wouldn't this make it an intended range of 256K? Anyway, it seems that the TG16, Genesis, and SNES could have originally intended to have 128KB of VRAM.
tepples wrote:
The VDC was designed to use either fast or slow VRAM.
What, were they unsure?
tepples wrote:
the VDC retains the bits in register 9 specifying memory speed alongside the bits that specify nametable size. One of the slow modes apparently produces 4-color tiles instead of 16-color ones, and the CG mode bit specifies which half-tile to use.
I was about to say how this could be useful to conserve VRAM space, but I'm guessing 4-color tiles apply to everything, not just a certain sprite or something like that...
Espozo wrote:
tepples wrote:
with an intended range of 128K
Wouldn't this make it an intended range of 256K? Anyway, it seems that the TG16, Genesis, and SNES could have originally intended to have 128KB of VRAM.
At 128 bytes per 16x16 tile, 10 bits cover 128K. The remaining bit is intended for the 2-bit mode and is zero otherwise.
Quote:
tepples wrote:
The VDC was designed to use either fast or slow VRAM.
What, were they unsure?
Yes. Hudson was probably unsure of whether RAM makers would be able to provide fast enough RAM, so it designed in both fast and slow modes. Had RAM makers not hit their target by 1986, the PC Engine would have been specced with slow memory, all games would use slow mode, and then years later, there would be hacks to solder in faster RAM and patch games to alleviate slowdown.
Quote:
I was about to say how this could be useful to conserve VRAM space, but I'm guessing 4-color tiles apply to everything, not just a certain sprite or something like that...
I'm guessing it'd be like 8x8 or 8x16 pixel sprites on the NES.
Espozo wrote:
Well, I just hijacked psychopathicteen's code.
psycopathicteen wrote:
This is how it was like back in the day for a developer.
Programmer 1: We need a hi-oam code fast!
Programmer 2: Why don't you just hijack psycopathicteen's code?
Programmer 1: Psycopathicteen isn't even potty trained yet!
Programmer 2: Oh NOOOOOOOOO!!!!
Add me to the list of people who use psycopathicteen's hi-oam algorithm.
Espozo wrote:
Really though, making a good vram engine is much, much worse.
I just finished writing, optimising and unit testing my vram engine. It took 3 months of on-again, off-again development but it's finally complete.
Now that the boring part is done my productivity should increase.
Quote:
I am also confused by this? Why does it have 11 bits if the PCE can't use 8x8 sprites?
Like tepples said, it intended to use 128ko of VRAM ..
And those 11bits are not the same for sprite cells size, those are in another word (the fourth),it's 11 bits for sprite patterns addresses in VRAM only.
@espozo: if this can help you:
Code:
Here's what a SATB entry looks like:
+---------------------------------------------------------------+
|15 |14 |13 |12 |11 |10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-----------------------+---------------------------------------+
| | y coordinate |
+-----------------------+---------------------------------------+
| | x coordinate |
+-------------------+---+---------------------------------------+
| | pattern address |
+---+---+-------+---+-------+---+---+-----------+---------------+
| Y | | CGY | X | |CGX|PRI| | palette index |
+---+---+-------+---+-------+---+---+-----------+---------------+
Y -> vertical flip bit (0 = normal, 1 = reversed)
X -> horizontal flip bit (0 = normal, 1 = reversed)
CGY -> sprite height: 00 = 16
01 = 32
10 = invalid
11 = 64
CGX -> width: 0 = 16
1 = 32
PRI -> priority flag: 0 = in background
1 = in foreground
Quote:
What, were they unsure?
Yes it's sure, you can use slow/fast VRAM with VDC(it's designed for), and you can also use a 8/16 bits CPU, you can switch all VDC's registers in 16 bits mode instead of 2 8 bits with a connected pin to +VCC .
I think the VDC was not designed specificaly for PCE, but for general uses in multiple systems .
Slow VRAM can not be used for PCE's med/hi res,even with his 100ns VRAM, still works under speed specifications for hires (93ns is required),but works .
Sik wrote:
MottZilla wrote:
For example I've thought that Sega should have outfitted the Genesis VDP with enough Color RAM for 128 Colors instead of 64 and made the Background and Sprites use different section like the NES or SNES does.
That was their original intention, but they ran out of die space ¯\(º_o)/¯ (instead we got less-used features like S/H that took up less room) There's a good reason why the VDP can use an external color DAC, but again that'd have made the console more expensive (ugh).
If they ran out of die space then I think they should have scrapped the Master System video modes if that would have allowed for 128 colors. It would have been far more useful in the long run.
Fekinox in the FamiTracker Discord server recommended a few sources for waves to convert to BRR:
This leaves filling BG2 and BG3 and testing on all three major variants (1/1/1, 2/1/3, 1CHIP) of each region as the remaining blockers of stepping up from NES to Super NES.
Filling BG2 and/or BG3 seems more like an issue for artists (and depending on the game, might not even need to be very detailed). And then you have the fact that for a lot of cases, you don't need a particularly large BG2 or BG3 either. I imagine you could just make a static tilemap and tileset, send them to VRAM once, then just adjust the BG2/3 scroll registers on VBlank, and it would be good enough. If you wanted something larger you'd need to use tile reloading like BG1, yes, but then, that's what code reuse is for.
HihiDanni wrote:
Filling BG2 and/or BG3 seems more like an issue for artists
Which is my point: more graphics means paying your artist for more hours of work than on 8-bit, or inflating a 1-man hobby project to one where the producer-programmer has to hire an artist in the first place.
UnDisbeliever wrote:
Espozo wrote:
Really though, making a good vram engine is much, much worse.
I just finished writing, optimising and unit testing my vram engine. It took 3 months of on-again, off-again development but it's finally complete.
Now that the boring part is done my productivity should increase.
I just added vertical and horizontal sprite runs to my animation engine, so I can have shorter metasprite data.
tepples wrote:
HihiDanni wrote:
Filling BG2 and/or BG3 seems more like an issue for artists
Which is my point: more graphics means paying your artist for more hours of work than on 8-bit, or inflating a 1-man hobby project to one where the producer-programmer has to hire an artist in the first place.
Am I an outlier by not so much being interested in making a game, but programming instead? I think a powerful, all purpose engine could get people into making SNES games who don't have a whole lot of programming knowledge to begin with. As they get more experience, they can actually modify the game engine too. I'm envisioning something like SMW hacking except much less shitty.
Unfortunately, I haven't done any programming this whole summer.
Now with Splatoon 2 out, I don't see that changing.
psycopathicteen wrote:
I just added vertical and horizontal sprite runs to my animation engine, so I can have shorter metasprite data.
What does this mean?
Espozo wrote:
I think a powerful, all purpose engine could get people into making SNES games who don't have a whole lot of programming knowledge to begin with.
I agree, but you still need competent graphic design to make the
engine's tech demo attractive to modders.
Espozo wrote:
As they get more experience, they can actually modify the game engine too. I'm envisioning something like SMW hacking except much less shitty.
Essentially all
Super Mario World hacks that I'm aware of leave the graphics for at least one block or character untouched. You'd need a total conversion of
SMW, wiping all Nintendo graphics from existence, to form the set of graphics that will be used to demonstrate an original engine.
Espozo wrote:
psycopathicteen wrote:
I just added vertical and horizontal sprite runs to my animation engine, so I can have shorter metasprite data.
What does this mean?
If it's anything like the metasprite format in
The Curse of Possum Hollow, it means that if a cel is 48 pixels wide, you used to get this for each row of 16x16 pixel sprites in the cel:
Code:
x, y, tile, attributes, x+16, y, tile, attributes, x+32, y, tile, attributes
And now you get this:
Code:
x, y, attributes, 3, tile, tile, tile
Quote:
Am I an outlier by not so much being interested in making a game, but programming instead?
I enjoy programming much more than other aspects of game design (testing, graphics design).
But, without a goal, a specific finish line, your motivation will go to crap...and you get distracted (Splatoon) and nothing gets done. Make small goals. Not, I will make a game this year. But...I will spend 2 hours programming today. I will draw some pixel art this weekend. Etc.
Quote:
Essentially all Super Mario World hacks that I'm aware of leave the graphics for at least one block or character untouched. You'd need a total conversion of SMW, wiping all Nintendo graphics from existence, to form the set of graphics that will be used to demonstrate an original engine.
I doubt I'd use SMW assets.
Quote:
If it's anything like the metasprite format in The Curse of Possum Hollow, it means that if a cel is 48 pixels wide, you used to get this for each row of 16x6 pixel sprites in the cel:
I don't see any advantage to doing this over letting sprites be anywhere in the metasprite, other than space, unless that is the advantage.
Quote:
(Splatoon)
God, I hate myself...
Espozo wrote:
tepples wrote:
You'd need a total conversion of SMW, wiping all Nintendo graphics from existence, to form the set of graphics that will be used to demonstrate an original engine.
I doubt I'd use SMW assets.
I agree. But first we'd need to see the assets you
would use. And my point is that a game comparable to those from the Super NES launch window requires a lot more such assets than a game comparable to those from the NES launch window.
Espozo wrote:
tepples wrote:
HihiDanni wrote:
Filling BG2 and/or BG3 seems more like an issue for artists
Which is my point: more graphics means paying your artist for more hours of work than on 8-bit, or inflating a 1-man hobby project to one where the producer-programmer has to hire an artist in the first place.
Am I an outlier by not so much being interested in making a game, but programming instead? I think a powerful, all purpose engine could get people into making SNES games who don't have a whole lot of programming knowledge to begin with.
The problem is people always look at the source code of these engines (which does all the dirty work for them) and give up when they can't understand 100% of the instructions.
The people who know how to program in some assembly language, and the people who know how to or want to spend time programming a game engine from scratch are not necessarily one and the same group. We spend a lot of time discussing how to make DMA queues, do metasprites, etc. but not really going the extra mile and providing already working implementations of these concepts in a readily usable package. That's the whole point of making an engine.
And if all you do is just dump a bunch of source code somewhere, of course it probably wouldn't generate a ton of interest, especially if it's largely unexplained. Even experienced programmers want documentation. The best way to get people to use something is to show them how, to invite them to do so by explaining how you go about creating screens, adding objects and assets to the game, and tying everything together into a playable game. And example games are good but you also need to provide a clean template for people to use, so that they don't have to pick apart the game-specific stuff to get to the engine itself.
I think proper tools and (documented!) frameworks will go a long way towards generating homebrew interest. The less time spent banging rocks together to make fire, the better.
Even if I put comments on my code, it would still be confusing because my dynamic animate engine uses a ton of register juggling.
Ideally, whoever is programming their game won't have to touch that code unless they want to modify the engine. You should provide either a function interface or a data format or maybe even macros so that new animations can be plugged into the game relatively easily.
But the problem remains of producing original assets with which to test an engine. The
complexity just doubles or more on the Super NES because of two layers, four times the tile space, and five times the colors per tile.
Adding more BG layers can be done at the end of development though.
tepples wrote:
But the problem remains of producing original assets with which to test an engine. The
complexity just doubles or more on the Super NES because of two layers, four times the tile space, and five times the colors per tile.
This seems largely nonsensical to me - the world certainly has no shortage of pixel artists. Might it require more effort to make graphics for the SNES compared to the NES? Maybe. But having to make pixel art hasn't stopped the vast amount of pixel-art-themed indie games that have shown up on virtually every modern platform.
Art isn't the issue here, programming and tooling is.
HihiDanni wrote:
the world certainly has no shortage of pixel artists. Might it require more effort to make graphics for the SNES compared to the NES? Maybe. But having to make pixel art hasn't stopped the vast amount of pixel-art-themed indie games that have shown up on virtually every modern platform.
As far as I know, "the vast amount of pixel-art-themed indie games that have shown up on virtually every modern platform" are made on an existing engine. A tech demo would need all new pixel art.
HihiDanni wrote:
Art isn't the issue here, programming and tooling is.
So how would I go about finding people willing to create pixel art suitable for testing the "programming and tooling" that I am creating?
I'll just let you use the graphics that I'm using for my game.
I'm pretty certain that finding libre-compatible assets is the exact point of opengameart.org ?
tepples wrote:
As far as I know, "the vast amount of pixel-art-themed indie games that have shown up on virtually every modern platform" are made on an existing engine.
That is what I'm getting at, yes. People want to be able to sketch out ideas quickly. Lack of developer convenience is a deterrent.
Quote:
A tech demo would need all new pixel art.
I can do art, though I tend to keep to my own projects mostly out of personal preference - I'm somewhat of a lone visionary. But I would very much like to contribute one or two demos of my own.
HihiDanni gets it. The problem I see, there are people who are:
1. interested in programming
2. interested in game design
3. interested in creating pixel art
Outside of this website, I've seen people who are 2 and/or 3 by far. If there weren't (I assume) several 2D game engines already made for PC, I'd bet the number of "retro" indie games would be near-zero.
tepples wrote:
A tech demo would need all new pixel art.
Wtf tepples?
https://www.spriters-resource.com/
Espozo wrote:
tepples wrote:
A tech demo would need all new pixel art.
Wtf tepples?
https://www.spriters-resource.com/ Those appear to be rips from copyrighted games. They could get the developer of a tech demo in trouble. That's why I specifically mentioned "the problem remains of producing
original assets".
tepples wrote:
This leaves filling BG2 and BG3 and testing on all three major variants (1/1/1, 2/1/3, 1CHIP) of each region as the remaining blockers of stepping up from NES to Super NES.
I'm sure this is already debated thoroughly in this old thread, but are you sure the major blocker in "stepping up" from NES to SNES isn't simply a lack of thorough and properly organized documentation (such as the Nesdev Wiki) and good beginner tutorials?
I tried looking into SNES development at one point, but I really had no idea where to start out, apart from creating newbie threads on this forum.
2 cents on artists:
There are many who are interested in doing pixel art, that's true. But there seems to be relatively few who are interested in making assets that would actually work without conditioning for a target platform. I've for example seen pixel artists do pictures with the NES master palette, not minding attributes, character space, subpalette restrictions...
Music side, there's plenty of people doing chiptunes - and some of that could be used with varying results in a game, but comparatively few who does actual vgm (taking game design and technicalities into consideration. Mixing a" hit single" or even an album is different from mixing a soundtrack, even for nes/snes/other machines).
But then again, SNES graphics limitations could be said to be more 'tolerant', so more graphics with no specific target platform will fit at least technically.
Still, if you want a template, you might aswell draw one that's consistent and that's made with intention to support and demonstrate an engine, rather than stitching together various free for all assets with varying styles and design goals to something that's approximately consistent.
FrankenGraphics wrote:
2 cents on artists:
Music side, there's plenty of people doing chiptunes - and some of that could be used with varying results in a game, but comparatively few who does actual vgm (taking game design and technicalities into consideration. Mixing a" hit single" or even an album is different from mixing a soundtrack, even for nes/snes/other machines).
Not to mention - something that would actually work on a common NES cartridge without sound expansion channels, and doesn't require so much CPU that you couldn't run it alongside a game (obviously that's a limitation set by the coding of the engine, but I think Famitone works as a decent benchmark for a very flexible engine with sensible CPU usage)
I'd wager it's probably a lot easier to find a "pixel artist" that's able to do stuff that's viable on the SNES than the NES.
While "8bit graphics" is a pretty abstract term that says nothing about the limitation of your palette (though a maximum of 256 colors is a good guess, obviously
), the term is pretty much just a buzzword, and usually never represents anything that's even remotely doable on an NES or even Master System. PC Engine might, but that's rarely what people think of when they're talking "8bit games".
Sumez wrote:
are you sure the major blocker in "stepping up" from NES to SNES isn't simply a lack of thorough and properly organized documentation (such as the Nesdev Wiki)
I mostly rely on
Fullsnes nowadays. There's also
SNES Development Wiki.
Sumez wrote:
and good beginner tutorials?
How much of a job would it be to rewrite Nerdy Nights for Super NES?
FrankenGraphics wrote:
There are many who are interested in doing pixel art, that's true. But there seems to be relatively few who are interested in making assets that would actually work without conditioning for a target platform.
Would it be hard for artists to understand a
description of mode 1 limits?
tepples wrote:
Sumez wrote:
are you sure the major blocker in "stepping up" from NES to SNES isn't simply a lack of thorough and properly organized documentation (such as the Nesdev Wiki)
I mostly rely on
Fullsnes nowadays. There's also
SNES Development Wiki.
The former is thorough but not properly organized. The latter is properly organized but not thorough.
Quote:
FrankenGraphics wrote:
There are many who are interested in doing pixel art, that's true. But there seems to be relatively few who are interested in making assets that would actually work without conditioning for a target platform.
Would it be hard for artists to understand a
description of mode 1 limits?
I think this is really a tool problem. My understanding is that pixel artists enjoy working with limitations. The problem is that existing tools like Aseprite don't really enforce palette-per-tile and maximum tile limitations. In essence, there's the act of making art, and then there's getting that art into the engine, but nothing to really connect those two together.
The
Sega Digitizer System comes to mind. I wonder if it handled this sort of stuff transparently?
Just take some generic pixel art, reduce the image to 121 colors in GIMP, posterize to 32 shades of RGB, then manually arrange the colors as 8 palettes of 15 colors, and modify the graphics if they don't fit.
Hand-optimizing pixel art that was designed without tile limitations in mind is probably easier said than done, especially if you're trying to squeeze as much as possible out of available VRAM.
tepples wrote:
Sumez wrote:
and good beginner tutorials?
How much of a job would it be to rewrite Nerdy Nights for Super NES?
Quite a demanding job, for sure. No one is denying that. But I'm sure you'd agree that the lack of such is a big barrier of entry to SNES development for most people, correct? I would love for one to exist, but wouldn't dare asking anyone to make it.
That said, personally I am more into "segmented" tutorials, describing examples of various individual things to do on the system. Ie. one tutorial to learn the CPU/assembly language, another one for best vblank practice, one for controller reading, etc. Makes it easier for me to focus at the task at hand. If I follow a "make a full game" tutorial, I usually end up just skipping through most of the text, copy/pasting the code that I need, and then immediately alter it to experiment or better suit my own future needs. I'm super impatient like that.
In fact, what I need, personally, might be more of a "template project" than a tutorial. I always found those immensely helpful.
HihiDanni wrote:
tepples wrote:
I mostly rely on
Fullsnes nowadays. There's also
SNES Development Wiki.
The former is thorough but not properly organized. The latter is properly organized but not thorough.
This echoes my own impressions from digging into those.
FWIW, I find fullsnes is just fine. After all I managed with the same author's similar style GBA document without any issues.
So from my POV, the docs are adequate. If there was an acceptable C compiler, I could be doing SNES games right now.
edit: I know I'm probably in the minority with this opinion, but nerdy nights was useless to me. I had a decent compiler, and that tutorial wanted to teach 6502 asm in tiny steps, when all I needed was the system-specifc specs, which I found on the nesdev wiki.
I agree that a tutorial definitely shouldn't try to teach you 6502 (or 65C02) along with the system in question, those should be kept separate. Sure, it's good practice to explain what each asm instruction does, but no need to start talking about what registers are, etc.
I have to admit I've never even looked at Nerdy Nights. Count me in with the "nesdev wiki" route.
fullsnes is neat, but it's definitely not "newbie" friendly. I look at it now and my immediate reaction is "but where do I start".
Sumez wrote:
In fact, what I need, personally, might be more of a "template project" than a tutorial. I always found those immensely helpful.
I'm not sure what you what in a template, but I made
lorom-template.
The answer to the wiki not being thorough is for those who already have Super NES programming experience to sign up and edit it.
As for narrowing a tutorial's scope, I guess one approach is to teach the Super NES hardware assuming knowledge of 65816 assembly. But then which are the two best 65816 tutorials?
A few years back I made a SNES romhack (that wasn't released) using a mish-mash of sneswiki and a demo program for the hdma feature as guidance. The fact I had working knowledge of NES and GBA already made SNES only a slight learning curve. But I wouldn't recommend it to beginning programmers (probably not any console over a PC with a library like Pygame or Allegro).
While some of the best games we'll ever play are on the 16-bit consoles (including MD/Gen and PCE/TG-16), I think they're the worst targets for homebrew dev because for all the complexity they're quite middling in what can be accomplished. This SNES homebrew release with choppy animation only bears that out.
https://www.youtube.com/watch?v=DtHbnYCccyU (4:30 to watch gameplay)
Still, if anyone insists, I can't see a SNES tutorial being effective without demanding prior knowledge of NES (likewise 65816 from 6502).
strat wrote:
While some of the best games we'll ever play are on the 16-bit consoles (including MD/Gen and PCE/TG-16), I think they're the worst targets for homebrew dev because for all the complexity they're quite middling in what can be accomplished.
This sounds rather defeationist to me, and Unholy Night as an example is rather disingenuous. I don't think that game's issues are strictly tied to the SNES. The quality of the art and music pales in comparison to releases from the 16-bit era. And heck, pretty much every other piece of SNES homebrew I've played was better programmed than this. It's almost like you picked this game specifically to discourage people from making homebrew.
I guess I'm just getting increasingly tired of the endless pessimism I'm seeing out of a thing that I actually think is Pretty Freaking Cool and deserves more attention than it's got.
Quote:
Still, if anyone insists, I can't see a SNES tutorial being effective without demanding prior knowledge of NES (likewise 65816 from 6502).
I have basically zero working knowledge of the NES and I'm doing fine. I also don't understand why 6502 knowledge would be a prerequisite to learning the 65816. In fact, I'm having a hard time imagining even programming an 8-bit processor. It just seems like something that would constantly get in your way.
Out of curiosity I've been browsing the NES section of these forums as well as some other NES resources. I know this isn't first-hand experience with NES development but it's still to me an eye-opener. Here is what I discovered:
- No native 16-bit arithmetic (obviously). There's so much game-related infrastructure I can think of that's, say, just barely outside the 8-bit range but is easily represented via 16-bit values. Timers, score, object positions, pointers, etc. etc. Yes, you can use the carry flag for addition and subtraction, but for comparisons it becomes more complex.
- You can't just follow a function pointer on the 6502. You have to do a song and dance with the stack to get it to work, and this costs significant CPU time compared to the 65816 which can do this natively. And function pointers are (IMHO) rather important to making code that's flexible and reusable.
- No hardware multiply/divide.
- To initialize RAM you have to use a tight loop in software. You can't just tell DMA to fill a region with zeroes.
- You can't use DMA to do nametable transfers.
- You have to resort to positional interrupt tricks just to get two large objects moving independently, and even then you're severely limited.
I'm sure there's more that I've forgotten. I've had a NES programmer pop in once while I was streaming SNES homebrew programming. They were in awe that I had 8kB of readily accessible RAM to play with. We take a lot for granted in SNES land.
As for past experience and working knowledge, I remember when I was looking into C/C++ programming and came upon the following advice: Essentially, don't learn all of C if you intend to be working mainly in C++, because you're going to be spending a lot of time unlearning old C habits that are counter-productive in C++, because C++ does some things differently. I suspect the same applies here. Yes, there is some transferable knowledge, but it'd be advisable that folks only train themselves in what is transferable, as anything else may just be an unproductive use of time.
You forgot that the 6502 can't use it's index registers as 16-bit pointers, AND there is no normal indirect mode, just indexed indirect and indirect indexed.
I've been looking for some SNES homebrew. The most interesting thing I came across (and it's not out yet):
https://www.youtube.com/watch?v=8bgBxtN0AGUThere's also N-Warp Daisakusen (originally freeware but also published on cart) and Super Boss Gaiden (SNES CD, yeesh). Of course one of the posters here (Shiru) did Classic Kong.
There are lots of great looking newer SNES games that actually date back to the 90's but were unreleased and picked up all these years later. Like Nightmare Busters and what's been published by Piko Interactive. Not exactly homebrew but at least someone is releasing new SNES carts.
Quote:
This sounds rather defeationist to me
I'm not trying to discourage anyone from SNES homebrew, per se. Since I've only made a rom hack, this is an imperfect judgment: On NES, the limitations are very clear and strict, so you can design the game around what can't be done. It seems to me on SNES you could go to a lot of trouble with getting part of a game done, then find, "ah gee, that doesn't work after all." And that's really apparent with Unholy Night. Possibly it was ineptly programmed but it just looks like assets were cut out to make it run with the animators begging for a more powerful platform. It could be the implementation was poorly planned all around, but it comes off like biting more than the system could handle.
Another reason for my attitude is the proliferation of co-processor chips in the commercial era. The Super FX (GSU) chip is its own discussion (we know exactly why it was needed in those games), but I couldn't look at Kirby Superstar or Super Mario RPG and tell you why they needed the SA-1*, while DKC and Tales of Phantasia didn't. Almost as if the cpu speed introduces a hidden limitation that could become a minefield despite the system's sprite capability.
* Though without debugging I'd guess off-hand they use the co-processor to load animation frames on the fly, since enemies in KSS are very detailed.
That said, I basically decided any game of mine for an older system will be backported from PC.
strat wrote:
Possibly it was ineptly programmed but it just looks like assets were cut out to make it run with the animators begging for a more powerful platform. It could be the implementation was poorly planned all around, but it comes off like biting more than the system could handle.
I've just been staring at the game's intro wondering how on earth it can choke on displaying fixed width text. That just isn't something that happens. Only thing I can think of is that they were programming in a (very!) high-level language. Even the launch titles run (and look) better than this.
Quote:
Another reason for my attitude is the proliferation of co-processor chips in the commercial era. The Super FX (GSU) chip is its own discussion (we know exactly why it was needed in those games), but I couldn't look at Kirby Superstar or Super Mario RPG and tell you why they needed the SA-1*, while DKC and Tales of Phantasia didn't.
Probably a combination of developer convenience, hardware decompression, and anti-piracy features. The fact that DKC doesn't need an expansion chip is a testament to, rather than a strike against, the base SNES system.
I feel like I have a _pretty good_ idea of how powerful the base CPU is from doing homebrew programming in assembly. I am currently doing some refactoring to allow support for streaming metasprites in my engine but before that's finished I plan to cook up a simple demo called 128 Birds. As the name would suggest, the demo is meant to be a more accurate indicator of the CPU's ability to handle large object and sprite counts at 60 FPS. And since it will be within the context of a game framework instead of an isolated tight loop, it should also be fairly indicative of real-world performance. I think you may be pleasantly surprised at just how much the CPU can do.
It looks like Unholy Night might use the "Let's update as little as possible during vblank, and just make the game wait for the next vblank when it exceeds the arbitrary limit we set for it" approach.
tepples wrote:
Sumez wrote:
In fact, what I need, personally, might be more of a "template project" than a tutorial. I always found those immensely helpful.
I'm not sure what you what in a template, but I made
lorom-template.
Thanks, that actually looks genuinely helpful! I'm not gonna move up to SNES development any time soon, but I might try playing around with it a bit.
HihiDanni wrote:
There's so much game-related infrastructure I can think of that's, say, just barely outside the 8-bit range but is easily represented via 16-bit values. (...), object positions, (...)
This... so much this
Quote:
- No hardware multiply/divide.
I didn't even realise the SNES CPU had that! Now I'm even more intrigued.
Hw multiply/divide isn't that useful. Genesis has that, and IIRC it's faster than SNES's. Yet it's only useful for things done rarely, like score updates once per frame; for anything done more often, you have to use a table, just like on NES. And even on NES you have enough time to multiply or divide for rarely done things, it takes just a few scanlines.
So after perusing the entire thread, I thought I'd bring up one thing that is surprisingly not discussed a whole lot, depite being pretty much the basis for the entire thread. Most of the talk has been quite technical (and extremely interesting, too!) in regards to the SNES hardware, and of course the bullet points tepples brought up, but I don't believe that is
really the cause of the "lack of" a SNES homebrew scene.
HihiDanni wrote:
This sounds rather defeationist to me
This! This might be more obvious for me, having only picked up NES development last year, and thus seeing most of this from an outside perspective, but there's a very general pessimism surrounding potential SNES development, to the point where getting anything done is perceived to be near-impossible.
Throughout the years, whenever I've pondered the possibility of creating games for older consoles, SNES would always have been my first thought (after all, it's pretty much the most popular classic console to ever exist), but the ideas have always been shot down by people that I talked to about it. Usually it goes something like "SNES is way too difficult to develop for, that's why no one is doing it". Or "There's a C compiler for the MegaDrive, so I would recommend going with that". Hell, I know it makes no sense to point out in an NES development community, but I'll admit that even the prospect of having to code something in assembly was pretty daunting, especially when there's another, supposedly much more approachable, 16-bit alternative. And even now, looking at just the assembly code, 68K ASM just looks so much more simple and beautiful than 65816 or 6502. And let's not forget those myths still going around that the SNES CPU is "too slow", or supposedly the cause of slowdown in many SNES titles (lol, I know).
However, the reasons for this general attitude towards how "difficult" SNES development is, don't *really* matter. What matters is that it exists. There's a lot of prejudice going around, and the aforementioned "defeatist" stance is a pretty good example of what you see everywhere. If a bigger SNES development community needs to happen, that's the first obstacle that needs to be torn down and obliterated.
I guess actually just seeing some more finished homebrew projects would probably help it a lot. As to say "hey, a scene does exist!".
HihiDanni wrote:
[...] And since it will be within the context of a game framework instead of an isolated tight loop, it should also be fairly indicative of real-world performance. I think you may be pleasantly surprised at just how much the CPU can do.
Indeed.
calima wrote:
Hw multiply/divide isn't that useful. Genesis has that, and IIRC it's faster than SNES's. Yet it's only useful for things done rarely, like score updates once per frame; for anything done more often, you have to use a table, just like on NES. And even on NES you have enough time to multiply or divide for rarely done things, it takes just a few scanlines.
Huh? I wouldn't say it's as slow as you're making it out to be.
In particular, the mode 7 multiplier (s16 * s8 = s24) is as fast as it possibly could be for an MMIO multiplier; the result can be read immediately as soon as you write the operands. The downside is that it can only be used freely in mode 0-6; in mode 7 it can only be used during vblank and forced blank.
There's also the unsigned multiplier (u8 * u8 = u16) which takes 8 CPU cycles before the result is ready, and the unsigned divider (u16 / u8 = u16 R u16) which takes 16 CPU cycles. Note, however, that even this isn't as bad as it seems, because other stuff can be done while waiting for the result. In addition, something like
lda $4216 takes three cycles to read the instruction before it actually reads from $4216, so in practice you only have to wait 5 CPU cycles for the unsigned multiplier, for instance.
strat wrote:
Since I've only made a rom hack, this is an imperfect judgment: On NES, the limitations are very clear and strict, so you can design the game around what can't be done. It seems to me on SNES you could go to a lot of trouble with getting part of a game done, then find, "ah gee, that doesn't work after all." And that's really apparent with Unholy Night. Possibly it was ineptly programmed but it just looks like assets were cut out to make it run with the animators begging for a more powerful platform. It could be the implementation was poorly planned all around, but it comes off like biting more than the system could handle.
Imperfect judgement for me too, but I think the difference between the NES and the SNES is that with the SNES, there's what can be done, and there's what can reasonably be done (what was done during the commercial era). Unholy Night definitely falls under the later, but as some have said, on the lower end of the spectrum, like Street Combat versus SNES Killer Instinct. I could think of many ways to improve Unholy Night; use HDMA to change BG3 colors (like my Metal Slug status bar mockup) and possibly move color windows (F-Zero health bar) to make the status bar more colorful, use BG3 as part of the background past the status bar, (possibly still using HDMA to change color) upload different background tiles depending on where the camera is, make characters larger and have more animation frames, and shrink the dumbass giant black bars. The last 3 would require a better vram engine, but it would definitely be possible with the perfect vram engine I've been trying to make forever. Going from the Neo Geo to the SNES just is not a good idea; it takes much more work and a lot of trickery to get near equivalent graphics on the SNES.
Espozo wrote:
upload different background tiles depending on where the camera is, make characters larger and have more animation frames, and shrink the dumbass giant black bars.
If you ask me, the elephant in the room is the game's framerate. This is precisely the sort of thing I mean when I say that even the launch titles were better than this.
Espozo wrote:
Going from the Neo Geo to the SNES just is not a good idea; it takes much more work and a lot of trickery to get near equivalent graphics on the SNES.
I think you are giving too much credit to "ex-SNK devs". The Neo-Geo era ended over a decade ago. People change, teams come and go. Rust builds. Projects can be mismanaged. By that same logic, Mighty No. 9 would have been a masterpiece.
@Espozo. When you program, do you start from scratch each time, or do you continue where you left off?
I start from my accumulated libraries. But I often have to start from near scratch if there's a change in platform, a change in employer, or a change in genre. And libraries are one thing we need.
HihiDanni wrote:
This seems largely nonsensical to me - the world certainly has no shortage of pixel artists.
This completely miss the goal/purpose of making your game in solo, through. On the NES it's easier to make your game in solo, because the level of skill required to compose music for only 4 channels and do graphics for only 3 colours per tile is accessible to an all-round talented programmer. Sure, we might not put the system to its limit but still get a level of detail comparable to commercial games of that era. On the SNES you'd either use a fraction of the system's possibilities, or mount a team with people dedicated for specific art. This is not specific to SNES, though. Any more advanced platform has the same issue.
Also the lack of C is a pretty bad excuse, considering how controvertial it is how good this language is in the first place.
It's a really bad excuse, but it definitely does have some effect on the general prejudice around development for the two major 16-bit consoles.
Quote:
considering this language is a rather bad language in the first place.
*avoids flame*
@Sumez
How so? I am not exaggarating when I say asm is in general over 10 times slower to write. It is simply not worth my time to write an entire game in asm, nor worth anyone's money to pay somebody to do so. That alone is the reason some recent Kickstarters were quoted above 10k for a SNES port, it's that laborious.
Having a game cost 10 times more, without being 10 times more fun, is simply a non-starter.
I get what you're saying, but assembly also has a way worse reputation that it deserves, and I definitely don't see why it should keep people away from creating SNES games.
You need to write assembly to make games for the NES, and that doesn't keep people away. (sure there are some nice examples of NES games created in C, but I'm sure we can all agree on the massive overhead it creates - there's a reason this entire forum is extremely focused on the 6502)
calima wrote:
Having a game cost 10 times more, without being 10 times more fun, is simply a non-starter.
But the game might be 10 times faster.
I'm pretty sure both Classic Kong and Christmas Craze were written in C and they seem to run fine. I wouldn't use C for stuff with large object counts but I think the option is there for quite a few different kinds of games.
Whether the existance of a usable C library is a valid argument or not is a moot point anyway. I mean, if someone were to build an actually useful library for the SNES, it would obviously help push a lot more people into SNES development, but even when it doesn't, my original point was that that really shouldn't keep people away from it. Or at least not to the point where a homebrew scene for the platform is almost non existant.
Sumez wrote:
sure there are some nice examples of NES games created in C, but I'm sure we can all agree on the massive overhead it creates
And any fan of Koei war sims would consider the overhead worth it.
Now as I find time, I could help solve "g. Less known working demo source code." Now that I've started on my own music engine S-Pently, I plan to do more on this system.
But I'm still drawing a blank for "c-d. Filling 15 colors and 3 layers". Bregalad makes a good point about solo projects. With
SMW art quality being the low bar on Super NES, solo developers scale their plans back to the NES, where solo art is more acceptable. Progressing past a solo project requires interpersonal skills to interest pixel artists in your project, which can prove difficult with the autism endemic among hobbyist programmers.
So I guess I have to demonstrate these issues myself by porting several of my old NES projects to Super NES. It'll add some working source code for other programmers to look at. But it'll also show how out-of-place NES-grade solo artwork looks on Super NES outside
Williams Arcade's Greatest Hits.
I would agree that artwork and music/dealing with the SPC are the biggest challenges for doing something on the SNES. The standards for audio and visual quality on the SNES can be pretty high among players when compared to the top licensed games.
But if you can get the right people involved that are serious about a project and can devote the time to it, I don't think the SNES is significantly less accessible than similar platforms. Homebrew and licensed games can both suffer from poor quality due to lack of knowledge or time. Of course other platforms can make things easier like the PC since anyone that can make artwork or music in whatever format you can probably convert and use.
To the original topic, I wouldn't say there is "no homebrew scene" for the SNES. There's plenty of homebrew and hacks out there for the SNES.
There's plenty of hacks (which really isn't homebrew, even if a few more creative ones are borderline), and maybe a couple of actual homebrews.
But is there any "scene" apart from what's present here?
It would be really great if someone made a easy to use snes game engine and tools for SNES development. And while I know that there are tools and programs that exists it just seems like there really isn't any community of people doing it.
However if you look at some of the SNES hacking scenes, some of them are actually pretty advanced. For example the Super Metroid hacking scene has produced some good hacks. And the one scene which seems to dominate over all is the smw hacking scene. There are literally hundreds of custom sprites, hundreds of custom blocks and hundreds of custom level codes and patches. Combined with a top quality editor and lots of tools, you can literally make all sorts of new games using the smw game engine.
But the SMW hacks also contain substantially all the artwork from SMW. An all-new engine designed to make SMW hacking less necessary would need all-new artwork.
I've been busy today squeezing my animation engine down to as little lines of code as possible. I want it so short that noobies would think I wrote it in just a few minutes.
psycopathicteen wrote:
@Espozo. When you program, do you start from scratch each time, or do you continue where you left off?
I start where I left off. I don't comment anything, but I give everything super-long, descriptive names. I just haven't been programming for a good long while now.
Erockbrox wrote:
you can literally make all sorts of new games using the smw game engine.
It's just unfortunate, because SMW is a really shitty base.
Oh yeah, about audio, I've still never gotten around to touching it. I don't even know what responsibilities people generally give the SPC 700; I'd probably let the 65816 actually mix the songs and just send commands to the SPC700.
Espozo wrote:
Erockbrox wrote:
you can literally make all sorts of new games using the smw game engine.
It's just unfortunate, because SMW is a really shitty base.
I have to agree. Just looking at a RAM map of SMW is enough to make me want to shake my head. You're going to get more mileage out of a homebrew engine or even writing your own thing from scratch.
Espozo wrote:
Oh yeah, about audio, I've still never gotten around to touching it. I don't even know what responsibilities people generally give the SPC 700; I'd probably let the 65816 actually mix the songs and just send commands to the SPC700.
This is inadvisable. There's a reason the SPC700 has high resolution timers and is mostly isolated from the rest of the system. It's basically an early example of threaded audio. You don't want to get stuck notes while the main CPU is busy doing other things. That's the sort of stuff you get on the NES and Genesis but is virtually non-existent on the SNES. IMHO, just figure out how the SPC upload protocol works, then toy around with SNESGSS or another existing homebrew sound driver. You're going to get results much faster that way.
If I'm trying to make a code library for others to use, how much shorter do I need to make this code to not look intimidating?
Code:
animation:
ldy {metasprite_request}
bne + //no animation, if "metasprite_request" is blank
jsr clear_vram_slot
stz {frame_id}
rts
+;
lda {animation_update} //sprite is animated if "metapsprite" is different from
bne + //"metasprite_request" or "animation_update" is set
cpy {metasprite}
bne +
rts
+;
lda $000c,y
tax
clc
adc {total_dma_legnth} //check if there is enough DMA time for sprite
cmp #$0081
bcc ++
lda {first_object_to_dma}
bne +
tdc
sta {first_object_to_dma}
+;
rts
+;
stx {vram_size}
jsr clear_vram_slot //clear previous animation frame
stz {180_degrees_flip}
lda {animation_update}
cmp #$0002 //if "animation_update" is 2, then frame is rotated 180 degrees
bne +
lda #$c000
sta {180_degrees_flip}
+;
stz {animation_update}
ldy {metasprite_request}
sty {metasprite}
lda $000e,y
clc
adc {animation_index}
inc #2
sta {frame_id}
tax
lda {animation_copies},x
beq + //if animation_copies is not 0, then no further processing
inc //is needed
sta {animation_copies},x
rts
+;
inc
sta {animation_copies},x
lda $000a,y //find the ROM address of sprite graphics
asl #5 //ROM address = metasprite ROM address + (animation frame)*(metasprite ROM size)
sta {vram_width}
sep #$20
lda {animation_index}
lsr
sta $4202
lda $000c,y
sta $4203
nop
rep #$20
lda $4216
asl #5
clc
adc $0006,y
sta {temp3} //"temp3" is ROM address
lda $0008,y
sta {temp2} //"temp2" is ROM bank
lda $0010,y
bpl + //if $0010,y is $7fff or less, it is the metasprite data itself
tya //if $0010,y is $8000 or more, it is the address pointing to metasprite data
clc
adc {animation_index}
tax
ldy $0010,x
+;
phd
lda #$0000
tcd
ldx #$ffff
-;
lda $0010,y
bne +
txa
invalid_chr:
pld
ldx {frame_id}
sta {animation_chr},x
lda {vram_size}
clc
adc {total_dma_legnth}
sta {total_dma_legnth}
rts //this is where the game exits the routine
+;
xba
and #$000f
sta.b {temp7} //"temp7" counts down the vertical sprite run
lda $0011,y
and #$0070
lsr #4
sta.b {temp8} //"temp8" counts down the horizontal sprite run
lda $0018,y
adc.b {temp3}
sta.b {temp} //"temp" is the ROM address of the sprite being added
sta.b {temp9} //"temp9" is the ROM address of the top sprite in a vertical run
lda $0012,y
sta.b {temp_x}
lda $0014,y
sta.b {temp_y}
sty.b {temp5}
-;
jmp find_vram_slot
find_vram_slot_done:
ldy.b {temp5} //this puts all the "OAM" information
lda.b {temp6} //onto the linked list
ora $0016,y
sta {sprite_attributes},x
lda.b {temp4}
sta {sprite_size},x
asl
tay
lda.b {temp_x}
sta {sprite_x},x
lda.b {temp_y}
sta {sprite_y},x
dec.b {temp7} //decreases "temp 7" until all sprites
bmi + //in the vertical run are put on linked list
clc
adc sprite_size_LUT,y
sta.b {temp_y}
ldy.b {temp5}
bra -
+;
dec.b {temp8} //decreases "temp 8" until all sprites
bmi + //in the horizontal run are put on linked list
lda.b {temp_x}
clc
adc sprite_size_LUT,y
sta.b {temp_x}
lda.b {temp9}
clc
adc sprite_size_LUT2,y
sta.b {temp9} //this moves the ROM address of the sprites
sta.b {temp} //to the next sprite in a horizontal run
ldy.b {temp5}
lda $0014,y
sta.b {temp_y}
lda $0011,y
and #$000f
sta.b {temp7}
jmp -
+;
lda.b {temp5}
clc
adc #$000a
tay
jmp --
sprite_size_LUT:
dw $0010,$0020,$0010,$0020
sprite_size_LUT2:
dw $0040,$0080,$0040,$0080
find_vram_slot:
lda $0010,y
txy
and #$0003
dec
beq small_slot
cmp #$0001
beq large_slot
repeat_slot: //this finds repeat slots
tsb.b {temp4}
ldx {repeat_slot_stack_index}
dex
dex
bpl +
tya
jmp invalid_chr
+;
lda {repeat_slot_stack},x
stx {repeat_slot_stack_index}
tax
tya
sta {sprite_name},x //puts it on linked list
jmp find_vram_slot_done
small_slot: //this finds 16x16 VRAM slot
sta.b {temp4}
ldx {small_slot_stack_index}
dex
dex
bpl +
tya
jmp invalid_chr
+;
lda {small_slot_stack},x
stx {small_slot_stack_index}
tax
tya
sta {sprite_name},x //adds slot to linked list
lda x16_lut,x
ldy.b {dma_updates}
sta {dma_destination},y //sets up dma queue
clc
adc #$0100
sta {dma_destination}+8,y
lda.b {temp}
sta {dma_address},y
adc {vram_width}
sta {dma_address}+8,y
adc {vram_width}
sta.b {temp}
lda.b {temp2}
ora #$4000
sta {dma_bank},y
sta {dma_bank}+8,y
tya
clc
adc #$0010
sta.b {dma_updates}
stx.b {temp6}
jmp find_vram_slot_done
large_slot: //finds open 32x32 VRAM slot
sta.b {temp4}
ldx {large_slot_stack_index}
dex
dex
bpl +
tya
jmp invalid_chr
+;
lda {large_slot_stack},x
stx {large_slot_stack_index}
tax
tya
sta {sprite_name},x //adds slot to linked list
lda x16_lut,x
ldy.b {dma_updates}
sta {dma_destination},y //sets up DMA queue
clc
adc #$0100
sta {dma_destination}+8,y
adc #$0100
sta {dma_destination}+16,y
adc #$0100
sta {dma_destination}+24,y
lda.b {temp}
sta {dma_address},y
adc {vram_width}
sta {dma_address}+8,y
adc {vram_width}
sta {dma_address}+16,y
adc {vram_width}
sta {dma_address}+24,y
adc {vram_width}
sta.b {temp}
lda.b {temp2}
ora #$8000
sta {dma_bank},y
sta {dma_bank}+8,y
sta {dma_bank}+16,y
sta {dma_bank}+24,y
tya
clc
adc #$0020
sta.b {dma_updates}
stx.b {temp6}
jmp find_vram_slot_done
x16_lut:
dw $0000,$0020,$0040,$0060,$0080,$00a0,$00c0,$00e0,$0110,$0120,$0140,$0160,$0180,$01a0,$01c0,$01e0
dw $0200,$0220,$0240,$0260,$0280,$02a0,$02c0,$02e0,$0310,$0320,$0340,$0360,$0380,$03a0,$03c0,$03e0
dw $0400,$0420,$0440,$0460,$0480,$04a0,$04c0,$04e0,$0510,$0520,$0540,$0560,$0580,$05a0,$05c0,$05e0
dw $0600,$0620,$0640,$0660,$0680,$06a0,$06c0,$06e0,$0710,$0720,$0740,$0760,$0780,$07a0,$07c0,$07e0
dw $0800,$0820,$0840,$0860,$0880,$08a0,$08c0,$08e0,$0910,$0920,$0940,$0960,$0980,$09a0,$09c0,$09e0
dw $0a00,$0a20,$0a40,$0a60,$0a80,$0aa0,$0ac0,$0ae0,$0b10,$0b20,$0b40,$0b60,$0b80,$0ba0,$0bc0,$0be0
dw $0c00,$0c20,$0c40,$0c60,$0c80,$0ca0,$0cc0,$0ce0,$0d10,$0d20,$0d40,$0d60,$0d80,$0da0,$0dc0,$0de0
dw $0e00,$0e20,$0e40,$0e60,$0e80,$0ea0,$0ec0,$0ee0,$0f10,$0f20,$0f40,$0f60,$0f80,$0fa0,$0fc0,$0fe0
dw $1000,$1020,$1040,$1060,$1080,$10a0,$10c0,$10e0,$1110,$1120,$1140,$1160,$1180,$11a0,$11c0,$11e0
dw $1200,$1220,$1240,$1260,$1280,$12a0,$12c0,$12e0,$1310,$1320,$1340,$1360,$1380,$13a0,$13c0,$13e0
dw $1400,$1420,$1440,$1460,$1480,$14a0,$14c0,$14e0,$1510,$1520,$1540,$1560,$1580,$15a0,$15c0,$15e0
dw $1600,$1620,$1640,$1660,$1680,$16a0,$16c0,$16e0,$1710,$1720,$1740,$1760,$1780,$17a0,$17c0,$17e0
dw $1800,$1820,$1840,$1860,$1880,$18a0,$18c0,$18e0,$1910,$1920,$1940,$1960,$1980,$19a0,$19c0,$19e0
dw $1a00,$1a20,$1a40,$1a60,$1a80,$1aa0,$1ac0,$1ae0,$1b10,$1b20,$1b40,$1b60,$1b80,$1ba0,$1bc0,$1be0
dw $1c00,$1c20,$1c40,$1c60,$1c80,$1ca0,$1cc0,$1ce0,$1d10,$1d20,$1d40,$1d60,$1d80,$1da0,$1dc0,$1de0
dw $1e00,$1e20,$1e40,$1e60,$1e80,$1ea0,$1ec0,$1ee0,$1f10,$1f20,$1f40,$1f60,$1f80,$1fa0,$1fc0,$1fe0
no_slot_to_clear:
rts
clear_vram_slot: //this routine clears the VRAM slots of the previous animation frame
ldx {frame_id}
beq no_slot_to_clear
lda {animation_copies},x
beq +
dec
sta {animation_copies},x
bne no_slot_to_clear
+;
lda {animation_chr},x
-;
cmp #$ffff
beq no_slot_to_clear
tax
lda {sprite_size},x
beq clear_small_slot
cmp #$0001
beq clear_large_slot
txa
ldx {repeat_slot_stack_index}
sta {repeat_slot_stack},x
inx
inx
stx {repeat_slot_stack_index}
bra +
clear_small_slot:
txa
ldx {small_slot_stack_index}
sta {small_slot_stack},x
inx
inx
stx {small_slot_stack_index}
bra +
clear_large_slot:
txa
ldx {large_slot_stack_index}
sta {large_slot_stack},x
inx
inx
stx {large_slot_stack_index}
+;
tax
lda {sprite_name},x
jmp -
psycopathicteen wrote:
If I'm trying to make a code library for others to use, how much shorter do I need to make this code to not look intimidating?
Comment as much as possible. There is no such thing as "too obvious" when it comes to beginners.
If you have almost 350 lines of assembly code with literally zero comments, the length isn't what people are going to find intimidating about it.
I began trying to put comments on my code, but then realized that I should really make diagrams to visualize it too.
Let's see if I can sum this up. It uses linked VRAM slots. Each onscreen metasprite has a chain of VRAM slots with a beginning and end. Each VRAM slot has a metasprite-relative x/y coordinate and attribute tied to it. Several objects can share the same chain at once with a different origin and flip settings. There are special slot numbers that aren't real VRAM locations, but signify if a CHR number is a repeat of the last one, but with a different relative x/y or attributes, which can be useful for making tiled moving platforms.
Is that explanation good?
psycopathicteen wrote:
I began trying to put comments on my code, but then realized that I should really make diagrams to visualize it too.
Let's see if I can sum this up. It uses linked VRAM slots. Each onscreen metasprite has a chain of VRAM slots with a beginning and end. Each VRAM slot has a metasprite-relative x/y coordinate and attribute tied to it. Several objects can share the same chain at once with a different origin and flip settings. There are special slot numbers that aren't real VRAM locations, but signify if a CHR number is a repeat of the last one, but with a different relative x/y or attributes, which can be useful for making tiled moving platforms.
Is that explanation good?
Mention
anything that you'd want to see if you were a user of this code.
- author (name, email, website, accounts on the websites you frequent), version, date, license
- does it require specific assembler(s), hardware (e.g.
no SNES MINI) or emulators?
- operating principle
- detailed reference
- example(s)
- links
A few issues I am noticing with the posted code:
- This looks like one large function that is doing a lot. Separation of concerns is a key principle here. Of course for performance reasons it may be good to bundle many actions together, but if this is only getting called for maybe 16 objects a frame, you can afford to split it up.
- I can't tell which labels are intended to be called from user code, and which ones are internal branch/jump destinations. It doesn't help that the first label is simply titled "animation". Generally you'll want to name your functions after verbs, and also include the scope or target of your action in the name. Is the function processing animation for all objects? Or the current object? You may also want to include notes on when/where it is appropriate to call this function, along with input parameters and side-effects.
- Use of magic numbers ("if "animation_update" is 2, then frame is rotated 180 degrees") You should replace 2 with a constant.
- Maybe personal preference, but it could use more blank lines between groups of instructions so each "step" of the routine is more apparent. Maybe also comment overall what each step (group of instructions) is doing on a high level. Learning code is easier when you understand the general purpose of each segment of code. And personally I would find this more helpful than commenting individual lines (though if an individual line is doing something weird, might want to comment that too).
I feel like this code is trying to do a lot in general, and perhaps I'm paranoid, but it could use some optimization and redesign. That's not necessarily a bad thing - I've reworked my code several times in the past. It's rare to come up with the perfect design on the first try, and this is just the reality of software development. But splitting things up as I mentioned above, and documenting how the different systems work together (what each function expects, the format of the underlying data, etc.) will make that much easier.
Of course, you can still provide the code like it is, and then improve on it later with a new version. User testing may be some of the most valuable testing you can find. Just remember to attach a license to your code so that people can use it.
The thing is that it has to decode the meta sprite format in order to find the ROM address of the needed sprite graphics.
Another example I discovered today. This KS for a simple SNES game was estimated to take 6 months; now it's taken two years and three months, and it's still not complete.
https://www.kickstarter.com/projects/43 ... ns-of-dea/
So, like most Kickstarter projects then? You also neglected to mention that they said they were building the engine from scratch. Which, yeah, is going to take longer. This really just highlights the importance of having engines available for people to use.
calima wrote:
Another example I discovered today. This KS for a simple SNES game was estimated to take 6 months; now it's taken two years and three months, and it's still not complete.
https://www.kickstarter.com/projects/43 ... ns-of-dea/The NES game I'm working on started development in early 2005, and it's still not complete.
The thing about "engines" is that the Super NES probably isn't powerful enough for something as generic as, say, Unity or Unreal. Feel free to prove me wrong, but though an RPG, a platformer, and a vertical shmup could share a large set of hardware libraries, their engines would probably be structured very differently.
Writing a platformer engine that doesn't even scroll would be a matter of weeks, not years.
calima wrote:
Another example I discovered today. This KS for a simple SNES game was estimated to take 6 months; now it's taken two years and three months, and it's still not complete.
https://www.kickstarter.com/projects/43 ... ns-of-dea/I laughed when I saw that guy in the video. How many unfinished SNES games has that guy advertised?
Quote:
now it's taken two years and three months
But, that's how long I would expect a game like this to take to develop. '6 months' was just foolishly optimistic.
tepples wrote:
The thing about "engines" is that the Super NES probably isn't powerful enough for something as generic as, say, Unity or Unreal. Feel free to prove me wrong, but though an RPG, a platformer, and a vertical shmup could share a large set of hardware libraries, their engines would probably be structured very differently.
Engines can be different sizes. Unreal and Unity are designed around modern systems with a lot more complexity to manage under the hood because they're designed to scale to environments that take 8,000x as much RAM as the SNES actually has. They're also designed around a lot of micro optimizations that are only found in newer hardware and simply doesn't apply to the SNES. Word alignment? Haha, no need for that here.
The entire reason I'm making an argument for engines is that I only ever see people talking about how to implement DMA queues instead of actually making games. A lot of this is infrastructure that applies to a wide variety of genres and can easily be made reusable, just like the existence of code libraries, only an engine is more tightly integrated.
When it comes to genres, much of my initial inspiration for my SNES engine comes from Alien Soldier, which fits both "platformer" and "shmup". Action games share a surprising amount of infrastructure and are easily generalizable. If it's overhead from unused stuff that concerns you, then one of my design goals has been to allow objects to only do as much processing as they need to. If an object needs to move, it calls MoveObject. Same idea for drawing sprites and animation. An object that doesn't need to draw a moving sprite simply doesn't call the movement or animation functions. I have recently introduced an optimization so that an empty scene capable of having 128 objects only uses 7% CPU (excluding time spent in Vblank). That's pretty good if you ask me.
(I realize that there are some smaller details that users might want to tweak, and I'd like to help them do so via proper documentation and allowing user adjustment of object list sizes, etc. Still, I want to keep options open which is why I always do performance testing with high object counts, but also try to design my systems around flexibility.)
I'm also trying to do an Alien Soldier type game, but I'm also doing a hell of a lot of sprite animation, which is why that animation code is so long. It has to figure out how a constantly changing combination of sprites onscreen are going to fit into VRAM.
I'm still trying to crunch the code down. I hope this is a noticeable improvement.
Code:
animation:
ldy {metasprite_request}
bne + //no animation, if "metasprite_request" is blank
jsr clear_vram_slot
stz {frame_id}
rts
+;
lda {animation_update} //sprite is animated if "metapsprite" is different from
bne + //"metasprite_request" or "animation_update" is set
cpy {metasprite}
bne +
rts
+;
lda $000c,y
tax
clc
adc {total_dma_legnth} //check if there is enough DMA time for sprite
cmp #$0081
bcc ++
lda {first_object_to_dma}
bne +
tdc
sta {first_object_to_dma}
+;
rts
+;
stx {vram_size}
jsr clear_vram_slot //clear previous animation frame
stz {180_degrees_flip}
lda {animation_update}
cmp #$0002 //if "animation_update" is 2, then frame is rotated 180 degrees
bne +
lda #$c000
sta {180_degrees_flip}
+;
stz {animation_update}
ldy {metasprite_request}
sty {metasprite}
lda $000e,y
clc
adc {animation_index}
inc #2
sta {frame_id}
tax
lda {animation_copies},x
inc
sta {animation_copies},x
dec
beq + //if animation_copies is not 0, then no further processing is needed
rts
+;
lda $000a,y //find the ROM address of sprite graphics
asl #5 //ROM address = metasprite ROM address + (animation frame)*(metasprite ROM size)
sta {vram_width}
sep #$20
lda {animation_index}
lsr
sta $4202
lda $000c,y
sta $4203
nop
rep #$20
lda $4216
asl #5
clc
adc $0006,y
sta {temp3} //"temp3" is ROM address
lda $0008,y
sta {temp2} //"temp2" is ROM bank
lda $0010,y
bpl + //if $0010,y is $7fff or less, it is the metasprite data itself
tya //if $0010,y is $8000 or more, it is the address pointing to metasprite data
clc
adc {animation_index}
tax
ldy $0010,x
+;
phd
lda #$0000
tcd
ldx #$ffff
-;
lda $0010,y
bne +
txa
invalid_chr:
pld
ldx {frame_id}
sta {animation_chr},x
lda {vram_size}
clc
adc {total_dma_legnth}
sta {total_dma_legnth}
rts //this is where the game exits the routine
+;
sty.b {temp5}
lda $0012,y
sta.b {temp_x}
lda $0011,y
and #$0070
lsr #4
sta.b {temp8} //"temp8" counts down the horizontal sprite run
lda $0018,y
adc.b {temp3}
-;
sta.b {temp} //"temp" is the ROM address of the sprite being added
sta.b {temp9} //"temp9" is the ROM address of the top sprite in a vertical run
lda $0014,y
sta.b {temp_y}
lda $0011,y
and #$000f
sta.b {temp7} //"temp7" counts down the vertical sprite run
jmp find_vram_slot
find_vram_slot_done:
ldy.b {temp5} //this puts all the "OAM" information
lda.b {temp6} //onto the linked list
ora $0016,y
sta {sprite_attributes},x
lda.b {temp4}
sta {sprite_size},x
lda.b {temp_y}
sta {sprite_y},x
clc
adc.b {temp10}
sta.b {temp_y}
lda.b {temp_x}
sta {sprite_x},x
dec.b {temp7} //decreases "temp 7" until all sprites
bpl find_vram_slot //in the vertical run are put on linked list
dec.b {temp8} //decreases "temp 8" until all sprites
bmi + //in the horizontal run are put on linked list
clc
adc.b {temp10}
sta.b {temp_x}
lda.b {temp10}
asl #2
adc.b {temp9}
jmp -
+;
tya
clc
adc #$000a
tay
jmp --
find_vram_slot:
lda $0010,y
txy
and #$0003
dec
beq small_slot
cmp #$0001
beq large_slot
repeat_slot: //this finds repeat slots
tsb.b {temp4}
ldx {repeat_slot_stack_index}
dex
dex
bpl +
tya
jmp invalid_chr
+;
lda {repeat_slot_stack},x
stx {repeat_slot_stack_index}
tax
tya
sta {sprite_name},x //puts it on linked list
jmp find_vram_slot_done
macro add_and_store(a,b) {
adc {a}
sta {b},y
}
macro find_slot(stack_index,stack) {
sta.b {temp4}
ldx {stack_index}
dex
dex
bpl +
tya
jmp invalid_chr
+;
lda {stack},x
stx {stack_index}
tax
tya
sta {sprite_name},x //adds slot to linked list
lda x16_lut,x
ldy.b {dma_updates}
sta {dma_destination},y //sets up dma queue
clc
add_and_store(#$0100,{dma_destination}+8)
}
small_slot: //this finds 16x16 VRAM slot
find_slot({small_slot_stack_index},{small_slot_stack})
lda.b {temp}
sta {dma_address},y
add_and_store({vram_width},{dma_address}+8)
adc {vram_width}
sta.b {temp}
lda.b {temp2}
ora #$4000
sta {dma_bank},y
sta {dma_bank}+8,y
lda #$0010
jmp ++
large_slot: //finds open 32x32 VRAM slot
find_slot({large_slot_stack_index},{large_slot_stack})
add_and_store(#$0100,{dma_destination}+16)
add_and_store(#$0100,{dma_destination}+24)
lda.b {temp}
sta {dma_address},y
add_and_store({vram_width},{dma_address}+8)
add_and_store({vram_width},{dma_address}+16)
add_and_store({vram_width},{dma_address}+24)
adc {vram_width}
sta.b {temp}
lda.b {temp2}
ora #$8000
sta {dma_bank},y
sta {dma_bank}+8,y
sta {dma_bank}+16,y
sta {dma_bank}+24,y
lda #$0020
+;
sta.b {temp10}
clc
adc.b {dma_updates}
sta.b {dma_updates}
stx.b {temp6}
jmp find_vram_slot_done
x16_lut:
dw $0000,$0020,$0040,$0060,$0080,$00a0,$00c0,$00e0,$0110,$0120,$0140,$0160,$0180,$01a0,$01c0,$01e0
dw $0200,$0220,$0240,$0260,$0280,$02a0,$02c0,$02e0,$0310,$0320,$0340,$0360,$0380,$03a0,$03c0,$03e0
dw $0400,$0420,$0440,$0460,$0480,$04a0,$04c0,$04e0,$0510,$0520,$0540,$0560,$0580,$05a0,$05c0,$05e0
dw $0600,$0620,$0640,$0660,$0680,$06a0,$06c0,$06e0,$0710,$0720,$0740,$0760,$0780,$07a0,$07c0,$07e0
dw $0800,$0820,$0840,$0860,$0880,$08a0,$08c0,$08e0,$0910,$0920,$0940,$0960,$0980,$09a0,$09c0,$09e0
dw $0a00,$0a20,$0a40,$0a60,$0a80,$0aa0,$0ac0,$0ae0,$0b10,$0b20,$0b40,$0b60,$0b80,$0ba0,$0bc0,$0be0
dw $0c00,$0c20,$0c40,$0c60,$0c80,$0ca0,$0cc0,$0ce0,$0d10,$0d20,$0d40,$0d60,$0d80,$0da0,$0dc0,$0de0
dw $0e00,$0e20,$0e40,$0e60,$0e80,$0ea0,$0ec0,$0ee0,$0f10,$0f20,$0f40,$0f60,$0f80,$0fa0,$0fc0,$0fe0
dw $1000,$1020,$1040,$1060,$1080,$10a0,$10c0,$10e0,$1110,$1120,$1140,$1160,$1180,$11a0,$11c0,$11e0
dw $1200,$1220,$1240,$1260,$1280,$12a0,$12c0,$12e0,$1310,$1320,$1340,$1360,$1380,$13a0,$13c0,$13e0
dw $1400,$1420,$1440,$1460,$1480,$14a0,$14c0,$14e0,$1510,$1520,$1540,$1560,$1580,$15a0,$15c0,$15e0
dw $1600,$1620,$1640,$1660,$1680,$16a0,$16c0,$16e0,$1710,$1720,$1740,$1760,$1780,$17a0,$17c0,$17e0
dw $1800,$1820,$1840,$1860,$1880,$18a0,$18c0,$18e0,$1910,$1920,$1940,$1960,$1980,$19a0,$19c0,$19e0
dw $1a00,$1a20,$1a40,$1a60,$1a80,$1aa0,$1ac0,$1ae0,$1b10,$1b20,$1b40,$1b60,$1b80,$1ba0,$1bc0,$1be0
dw $1c00,$1c20,$1c40,$1c60,$1c80,$1ca0,$1cc0,$1ce0,$1d10,$1d20,$1d40,$1d60,$1d80,$1da0,$1dc0,$1de0
dw $1e00,$1e20,$1e40,$1e60,$1e80,$1ea0,$1ec0,$1ee0,$1f10,$1f20,$1f40,$1f60,$1f80,$1fa0,$1fc0,$1fe0
no_slot_to_clear:
plb
rts
macro clear_slot(stack_index,stack) {
ldx {stack_index}
sta {stack},x
inx
inx
stx {stack_index}
}
clear_vram_slot: //this routine clears the VRAM slots of the previous animation frame
pea $807e
plb
ldy {frame_id}
beq no_slot_to_clear
lda {animation_copies}-$7e0000,y
beq +
dec
sta {animation_copies}-$7e0000,y
bne no_slot_to_clear
+;
lda {animation_chr}-$7e0000,y
-;
cmp #$ffff
beq no_slot_to_clear
tay
ldx {sprite_size}-$7e0000,y
beq clear_small_slot
cpx #$0001
beq clear_large_slot
clear_slot({repeat_slot_stack_index},{repeat_slot_stack})
bra +
clear_small_slot:
clear_slot({small_slot_stack_index},{small_slot_stack})
bra +
clear_large_slot:
clear_slot({large_slot_stack_index},{large_slot_stack})
+;
lda {sprite_name}-$7e0000,y
jmp -
I've considered moving to SNES at some point in the future, but I'm reluctant just due to the implicit, rather large jump in scope. We're a 2 person operation and each NES game we've made clocks in right around 3.5 to 4 years at the pace we work (this is with me doing everything but the art, so music for instance is of manageable scope). I think that's about the limit of my patience for a large project which has extra difficulty (working with old hardware) imposed on it. If I made a SNES game I'd probably take 6, maybe 7 years on the type of game we might make. I think it's more realistic I may jump to gameboy, potentially. The graphics format was so similar I was able to make small modifications to my NES tools to output data for gameboy just tinkering one weekend. That plus the growing number of people in the gameboy scene makes it an attractive second option (more resources, tools, game jams, etc.). I think the reality boils down to SNES projects need larger teams (or just a lot more time), and as hobbyists keeping together large teams is obscenely difficult. It's difficult for all indie devs, probably, but with modern dev it's much easier to change out members of a team who can easily ramp up on some modern language codebase versus obscure old hardware.
Just about all of the projects I want to do on the SNES are either primitive practice games, one-shot tech demos, or ports. The only exception is a full-scale SA-1/MSU1 F-Zero game, which is so far down the list that I don't expect to ever start. Maybe I'm subconsciously trying to push back against the scope overload that seems to plague everything I do... or maybe I'm simply protected by my lack of artistic initiative. Either way, I've been laying the groundwork for my first SNES project for over three years now. Hopefully once I'm out of grad school things will loosen up a bit...
I was also looking at getting on the Gameboy, when Krikzz announced the GB-X everdrive some time ago. It has lower power consumption, and a RTC, so you can finally play 2nd gen pokemon as intended
Of course there are plenty of z80 C compilers.
That'd work for the ColecoVision, Master System, or Game Gear. But I'll open another topic in GBDev about C on the LR35902.
GradualGames wrote:
I've considered moving to SNES at some point in the future
Same here, I planned to move to SNES once I released some 3-4 games on NES. Exept I'm still at 0 games for the NES.
I've been wanting to get into SNES development for a while now, but really don't know where to start. I know x86 assembly fairly well (enough to write some functions in ASM for use in C code and to have an understanding of how to structure and write ASM code) and have learned most of the commonly used 65816 opcodes. I've been following bazz's tutorial on superfamicom.org and got to the point where I put a 1x1 tile image on the screen while understanding about half of what I was doing. Haven't really gotten much further than that.
I love coding in assembly, and making a SNES game has been a lifelong dream of mine. Some pointers would be much appreciated.
What do you want to know about first?
First, get the hell away from WLA.
93143 wrote:
Hopefully once I'm out of grad school things will loosen up a bit...
I'll be a high school senior this year, so I should have more free time. The next year, however...
psycopathicteen wrote:
What do you want to know about first?
That's my exact problem. I don't know what I need to know and what order to learn about it in. I need some sort of starting place that I could work myself up from there.
Espozo wrote:
First, get the hell away from WLA.
I've heard many negative things about WLA. Is it just bad syntax or what? I already have ca65 on my system, and was messing around with sneskit earlier. What's your personal preference?
I suppose PPU access comes first, then you can configure the registers to a state that allows things to become visible. You'll have to load in a palette so you can see anything at all, then load some tiles to VRAM and then write to tilemap area in VRAM to show some of the GFX on the screen. You can use an emulator with debugging functions to see that you're doing things right, no$sns seems to be pretty easy to get going with on that regard. you'll see register states, what's in the palettes, VRAM and sprite list.
My personal recommendation is to first start out by learning 65816 assembly. Play around with basic operations and store results of arithmetic in RAM, then look to see if it's the value you expected. Use a debugging emulator like bsnes-plus. Having a memory viewer is going to be very useful because you'll be able to learn the language, experiment, and fix bugs without having to display stuff on-screen. Breakpoints and debugger step-thru are also great to have because you can see step by step what your code is doing. Just remember to turn on auto-refresh in the memory viewer so you can see any changes in RAM.
Quote:
I don't know what I need to know and what order to learn about it in. I need some sort of starting place that I could work myself up from there.
tepples has an example code on his website.
https://pineight.com/snes/And baz's tutorials on the superfamicom wiki.
I also recommend ca65. The .SMART feature alone is worth it. It keeps track of REP and SEP instructions and sets the assembler accordingly.
Both WLA and ca65 have a smart feature. But ca65 has generally been a lot more reliable for me, with less surprises in the form of detecting the wrong register size without warning about it. Only thing I had to do for ca65 was put rep #$30 at the top of source files so it knows that 16-bit is intended as the default.
dougeff wrote:
Quote:
I don't know what I need to know and what order to learn about it in. I need some sort of starting place that I could work myself up from there.
tepples has an example code on his website.
https://pineight.com/snes/And baz's tutorials on the superfamicom wiki.
I also recommend ca65. The .SMART feature alone is worth it. It keeps track of REP and SEP instructions and sets the assembler accordingly.
I'll definitely check out tepples's template. Seems like just the snes.inc alone is amazingly helpful.
Also is there any difficulty difference between coding for HiROM or LoROM?
TmEE wrote:
I suppose PPU access comes first, then you can configure the registers to a state that allows things to become visible. You'll have to load in a palette so you can see anything at all, then load some tiles to VRAM and then write to tilemap area in VRAM to show some of the GFX on the screen. You can use an emulator with debugging functions to see that you're doing things right, no$sns seems to be pretty easy to get going with on that regard. you'll see register states, what's in the palettes, VRAM and sprite list.
I've taken a liking to bsnes-plus, so I'm probably going to use that (in addition to real hardware with an SD2SNES). If it gives me trouble, I'll keep nocash's emulator in mind.
HihiDanni wrote:
My personal recommendation is to first start out by learning 65816 assembly. Play around with basic operations and store results of arithmetic in RAM, then look to see if it's the value you expected. Use a debugging emulator like bsnes-plus. Having a memory viewer is going to be very useful because you'll be able to learn the language, experiment, and fix bugs without having to display stuff on-screen. Breakpoints and debugger step-thru are also great to have because you can see step by step what your code is doing. Just remember to turn on auto-refresh in the memory viewer so you can see any changes in RAM.
I'll try writing some functions using tepples's template as a base and see what the results are. Experimenting with existing things tends to be the way I learn best, although I will eventually want to learn how to do everything from scratch, but baby steps I suppose..
syboxez wrote:
Also is there any difficulty difference between coding for HiROM or LoROM?
Not particularly.
With Mode $20 ("LoROM"), it's easier to decide to keep the bank registers "B" and "K" the same; with mode $21 ("HiROM") you'll more often have to let them be them different. There's no particular advantage to keeping them same, and both the direct page, stack, and vectors always have to be in bank 0 regardless.
Mode $21 is a little more convenient for just shoving giant chunks of uncompressed data around, since then your memory map doesn't have gaps and it makes pointer math simpler. But the DMA unit can't cross banks anyway, so you may have to split things into multiple transfers regardless.
syboxez wrote:
Also is there any difficulty difference between coding for HiROM or LoROM?
LoROM and HiROM don't actually exist. You can create custom manifests with higan, and as long as they follow
the requirements of the base unit you can put your data anywhere you want. You don't even have to fill all the fields in the internal header, except for the vectors. (Of course other emulators might then have difficulties detecting the layout.)
"PRG ROM skips CPU A15" and "PRG ROM uses CPU A15" certainly exist. Yes, I know more mappings are possible, but those are the basic classes of mapping that your PowerPak, EverDrive, or SD2SNES is likely to support.
The latest version of the template is at
https://github.com/pinobatch/lorom-template
syboxez wrote:
Also is there any difficulty difference between coding for HiROM or LoROM?
HiROM is more complex, but it lets you store a consecutive run of 64kB of data (which, to my knowledge, can't really be done in LoROM).
Note however that even if you're using HiROM, you can still do LoROM style accesses by using the LoROM banks, which I do in my own engine for performance reasons - I'm putting most of my code in bank 80 rather than c0, but data goes in c2, c3, etc.
I suggest sticking with LoROM for now.
If someone is making an engine, I think there should be a folder labelled "complicated black magic stuff" so that beginners don't have to read it.
I can't believe I didn't think of this before, but I think it would be a good idea to emulate an arcade style sprite system with 16384 CHRs, and use a routine that allocates them to SNES's VRAM. Of course it might exceed vblank DMA limit, but you can come up with a separate routine for animation scheduling.
Haunted: Halloween '85 for NES does something similar with its sprite CHR. It emulates a sprite system with 256 16x16 CHRs, uploading two per frame to one of two buffers allocated to each entity and switching to the next animation frame only once all needed 16x16s are in place. On Super NES, it should be easier, as you don't need two buffers if no single cel needs more than 5K.
But you still need someone to draw plausible sprite cels with which to test a sprite system including this sort of OBJ-ExGrafix simulator, so that you don't end up over-relying on peculiarities of your synthetic test tiles.
Or you can just make the code not peculiar.
You might not know your architecture is peculiar until you plug in real data and discover that it's not as flexible or efficient as you thought it'd be. It doesn't have to be final data, just representative data.
Well, I guess I would have to come up with a separate version for 8x8 & 16x16 sprites, and 16x16 & 32x32 sprites.
EDIT:
I'm guessing that using 16384 16x16 would be limiting to games larger than 16-megabits. So you can fix that problem with extra SRAM, because you need a table to store the VRAM location of every sprite.
If you want to use a lot of SRAM, then lorom is better.
Okay, I just wrote an example code for a simple "
convert arcade-style sprite attributes to SNES-style sprite attributes" system. I wonder where Espozo is, he might be interested in this.
Code:
// "CHR" is the name for the table of 14-bit (or 15-bit) ROM CHR numbers for 128 sprites.
// The routine converts the 14/15-bit CHR values to the SNES's native 9-bit CHR values.
// "CHR_allocation" is a table of where each 14/15-bit CHR is mapped to what VRAM slot.
// Each slot has a hardcoded 9-bit CHR value
// "slot_CHR" says what 14/15-bit CHR value each slot cooresponds to.
// "active_slot" flags if the slot is being used or not. If $ffff, then the slot needs to be DMA'd.
// "sprite size" table declares if a sprite is 16x16 or 32x32
manage_VRAM:
ldx #$007e
-; //clear active slot list
stz {active_slot},x
dex #2
bmi -
ldy #$00fe
-; //check all active slots
ldx {CHR},y
lda {CHR_allocation},x
and #$00ff
tax
inc {active_slot},x
dey #2
bmi -
ldy #$00fe
-; //this loop allocates missing sprites and converts CHR values
ldx {CHR},y
lda {CHR_allocation},x
and #$00ff
bne +
jsr allocate_CHR //allocate missing sprites
+;
tax
lda VRAM_slots,x
sta {CHR},y //replace 14-bit (or 15-bit?) ROM CHR value with
dey #2 //SNES's native 9-bit CHR value
bmi -
rts
allocate_CHR:
phy
lda {sprite_size},y
bne allocate_large_sprite
ldy #$0040 //small sprites are allocated in slots 32-63
-;
lda {active_slot},y
beq + //open slots have "active_slot" as #0
iny #2
cpy #$0080
bne -
ldy #$0000 //VRAM full error gets NULL slot number
bra +
allocate_large_sprite:
ldy #$0010 //large sprites are allocated in slots 8-31
-;
lda {active_slot},y
beq + //open slots have "active_slot" as #0
iny #2
cpy #$0040
bne -
ldy #$0000 //VRAM full error gets NULL slot number
+;
lda #$ffff
sta {active_slot},y //#$ffff marks slots to DMA
tya
ora {CHR_allocation},x
sta {CHR_allocation},x //table entry is expected to have a low byte of #0
txa
ldx {slot_CHR},y
sta {slot_CHR},y
sep #$20
stz {CHR_allocation},x
rep #$20
tya
ply
rts
VRAM_slots:
dw $ffff,$ffff,$ffff,$ffff,$ffff,$ffff,$ffff,$ffff //NULL slots (only 0 is used)
dw $0000,$0004,$0008,$000c,$0040,$0044,$0048,$004c //32x32 slots
dw $0080,$0084,$0088,$008c,$00c0,$00c4,$00c8,$00cc
dw $0100,$0104,$0108,$010c,$0140,$0144,$0148,$014c
dw $0180,$0182,$0184,$0186,$0188,$018a,$018c,$018e //16x16 slots
dw $01a0,$01a2,$01a4,$01a6,$01a8,$01aa,$01ac,$01ae
dw $01c0,$01c2,$01c4,$01c6,$01c8,$01ca,$01cc,$01ce
dw $01e0,$01e2,$01e4,$01e6,$01e8,$01ea,$01ec,$01ee
Don't worry, I'm still alive.
Could you give a summary of what this code does? I read the description at the top, and glanced at the code, but I don't understand what is going on. It sounds like you want to somehow increase the CHR size of OAM to 15 bits instead of 9, but this is a hardcoded limitation. The end of your comment says something about 16x16 and 32x32 sized slots; is this related to the system we're doing of dynamically looking for space in VRAM for sprite graphics?
I thought more about this idea, and I thought that it might be easier to do 16x16 sprites in groups of 2, for a lot of reasons:
-half of the SNES's memory space can be used for sprites.
-32x32 and 16x16 sprites would have the same alignment.
-All sprite pairs have a page aligned address.
-DMA routine can be made more efficient. Possibly around 5kB at once without bars.
The downsides are slightly less flexible 16x16 sprites, and doing 48x48 rotating sprites would have a much more confusing mapping.
In
this post, GradualGames pointed out that the asset complexity even on the NES is greater than that on the Atari 2600, and backers of an RPG Maker-style tool that targets NES are clamoring for a counterpart to the Unity engine's Asset Store. This would be even greater for the Super NES.
If they can make an NES game maker program, maybe they can make an SNES game maker too, even if doesn't take 100% of the system's resource.
Anything can happen if there's enough funding
MiniMacro (who goes by Quack Man in FamiTracker community Discord) recommended more samples:
groboclown.net's XM instrument archive
I talked to John (gamester81) and told him to release or sell his Justice Beaver SNES creation tools when they are done with that project. He said that he would have to talk with the SNES programmer to see if he was interested in doing it.
If people are willing to sell their own SNES homebrew tools or do kickstarters to improve or develop SNES tools it would really help the SNES homebrew community and scene.
I'll be looking forward to that.
tepples wrote:
In
this post, GradualGames pointed out that the asset complexity even on the NES is greater than that on the Atari 2600, and backers of an RPG Maker-style tool that targets NES are clamoring for a counterpart to the Unity engine's Asset Store. This would be even greater for the Super NES.
Oh gawd, the Unity Asset store. How to make a game not survive a game-engine-you-didn't-write update.
We really do need some kind of "Simple"/"Retro" assembly-code game engine that can run on a NES/SNES/MD by outputting the necessary 6502/65c816/68K assembly game code/assets, that works on Higan or a real SNES/Super NT. If it can validate on the real hardware, then having a IL output (for LLVM) would let it be compiled with other machine-native engines that have the capability to display graphics and play midi/tracker style music.
At any rate, the amount of games that I see being made in Unity or GameMaker that are 2D pixel sprite games, but lack the color range, or even input responsiveness of an actual retro game kinda makes me disappointed over and over again. This isn't a call to stop making 2D sprite games in Unity, but rather these games simply don't have the retro aesthetic other than being "pixelated"
Erockbrox wrote:
I talked to John (gamester81) and told him to release or sell his Justice Beaver SNES creation tools when they are done with that project. He said that he would have to talk with the SNES programmer to see if he was interested in doing it.
If people are willing to sell their own SNES homebrew tools or do kickstarters to improve or develop SNES tools it would really help the SNES homebrew community and scene.
That's very interesting!
Do you know what is the base of their toolset? (ASM or C?).
Did they also create some time saving tools (level editor, sprite animation manager, etc.), like the ones HihiDanni has planned for SuperFeather?
Please note that I only suggested it to John when I met him at an event. He said that it would have to up to the SNES programmer to see if he was interested in releasing/selling his tools.
Since NESmaker was so successful. It seems as if it would only make sense if they also did a kickstarter and did some sort of SNES maker tool.
Part of my hypothesis for this, if you'll recall, is the asset complexity gap between NES and Super NES. It appears to be confirmed by
this review of Sydney Hunter, which took marks off for underusing the S-PPU. Apparently you
have to have parallax, not just TG16-class graphics, if you want to sell a Super NES game.
I think the key lesson is...if you want a COMMERCIALLY successful SNES game, it should have multiple layers (parallax), or Mario Kart style perspective, or professional quality artwork.
But, freeware homebrews, should be free to look like Space Invaders to be "good" (see Classic Kong).
Thing is, if I see a homebrew severely underutilizing the platform it was coded for, I'll hardly be interested. When someone targets a specific console, I expect them to use most of the features it has to offer, and I expect the game to look AT LEAST like the typical games made for that system back in the day (If they go the extra mile and try to surpass what the typical games had to offer, even better!), otherwise I'll feel underwhelmed.
Which means you see a lot more projects that should have been TG16-scale either get scaled back to the NES or just released as a PC game instead.
I don't know about the TG16 thing, because one of the first rules pseudo-8-bit games break is the single scrolling background layer, and the TG16 could only fake a second layer using sprites. I've seen many games that could slmost pass for NES games, if it weren't for the background parallax layer. Aspect ratio is disregarded very frequently too, since all displays are wide-screen nowadays. Pixels artists also appear to feel tempted to sneak in 1 or 2 extra sprite colors. The sprites-per-scanline limit goes out the window fairly frequently too.
I bet you could do a decent rendition of Shovel Knight on the Super NES using Mode 0, with perhaps some cleverness required for certain cases. I'm not sure the MMC5 quite covers it...
tokumaru wrote:
I don't know about the TG16 thing, because one of the first rules pseudo-8-bit games break is the single scrolling background layer, and the TG16 could only fake a second layer using sprites.
Or shifting around a repeating pattern in CHR memory, analogous to what NES games started to do in
Battletoads and
MetalStorm and what I think
Donkey Kong Country does with its snowstorm effect. Or have the parallax and playfield on separate scanlines, as seen in a bunch of NES games including
Vice: Project Doom and
The Curse of Possum Hollow. But the games I've seen blasted for "not looking 16-bit enough" have no parallax at all: the aforementioned
Sydney Hunter,
Flicky,
The New Zealand Story,
Insector X ("I wonder if it would have killed Hot-B to add a layer or two of scrolling to the backgrounds. [...] I would have really felt like I was playing a 16-bit system instead of a late NES title."), and especially
Ninja Gaiden Trilogy which removed line scrolling parallax that had been in the NES game.
tokumaru wrote:
I've seen many games that could slmost pass for NES games, if it weren't for the background parallax layer. Aspect ratio is disregarded very frequently too, since all displays are wide-screen nowadays.
The TG16 has an anamorphic display mode, which
I've mentioned earlier. It increases the dot clock rate from 5.37 MHz (like most TMS9918-inspired VDPs) to 7.16 MHz. This squeezes about 336 pixels across the width of the screen, and both 5.37 MHz at 4:3 and 7.16 MHz at 16:9 have the same pixel aspect ratio. I'm just a bit disappointed that the Super NES has nothing between 5.37 and 10.74 MHz.
tokumaru wrote:
Pixels artists also appear to feel tempted to sneak in 1 or 2 extra sprite colors. The sprites-per-scanline limit goes out the window fairly frequently too.
As far as I know, the TG16 VDC has 16 16x16-pixel sprites per line, roughly comparable to the Genesis and Super NES limits.
93143 wrote:
I bet you could do a decent rendition of Shovel Knight on the Super NES using Mode 0, with perhaps some cleverness required for certain cases. I'm not sure the MMC5 quite covers it...
There is a C64 port coming, so I mean SNES would have to be a shoe in right?
tepples wrote:
tokumaru wrote:
I don't know about the TG16 thing, because one of the first rules pseudo-8-bit games break is the single scrolling background layer, and the TG16 could only fake a second layer using sprites.
Or shifting around a repeating pattern in CHR memory, analogous to what NES games started to do in
Battletoads and
MetalStorm and what I think
Donkey Kong Country does with its snowstorm effect. Or have the parallax and playfield on separate scanlines, as seen in a bunch of NES games including
Vice: Project Doom and
The Curse of Possum Hollow. But the games I've seen blasted for "not looking 16-bit enough" have no parallax at all: the aforementioned
Sydney Hunter,
Flicky,
The New Zealand Story,
Insector X ("I wonder if it would have killed Hot-B to add a layer or two of scrolling to the backgrounds. [...] I would have really felt like I was playing a 16-bit system instead of a late NES title."), and especially
Ninja Gaiden Trilogy which removed line scrolling parallax that had been in the NES game.
tokumaru wrote:
I've seen many games that could slmost pass for NES games, if it weren't for the background parallax layer. Aspect ratio is disregarded very frequently too, since all displays are wide-screen nowadays.
The TG16 has an anamorphic display mode, which
I've mentioned earlier. It increases the dot clock rate from 5.37 MHz (like most TMS9918-inspired VDPs) to 7.16 MHz. This squeezes about 336 pixels across the width of the screen, and both 5.37 MHz at 4:3 and 7.16 MHz at 16:9 have the same pixel aspect ratio. I'm just a bit disappointed that the Super NES has nothing between 5.37 and 10.74 MHz.
tokumaru wrote:
Pixels artists also appear to feel tempted to sneak in 1 or 2 extra sprite colors. The sprites-per-scanline limit goes out the window fairly frequently too.
As far as I know, the TG16 VDC has 16 16x16-pixel sprites per line, roughly comparable to the Genesis and Super NES limits.
Parallax is the "lens flare" of 16bit right? I mean when a game showed off on the NES it did parallax which meant "it pushed the machine to the limits".
Oziphantom wrote:
There is a C64 port coming, so I mean SNES would have to be a shoe in right?
Okay, but that's not exactly a 1:1 port.
The screen resolution means you couldn't do a 1:1 port on the SNES either, but you could get a lot closer. Maybe 1:1 with a cropped playfield. I'm not familiar enough with Shovel Knight to be able to say whether cropping the playfield would substantially damage gameplay.
(Unless you could manage the whole game accurately in Mode 5 or pseudo-hires, using a 432x240i frame which gives you not quite enough DMA bandwidth to refresh 4 bits per pixel per field. Since sprites are locked at lowres, you'd need software rendering for all moving objects, which combined with the necessary parallax tricks probably implies a fairly beefy cartridge coprocessor - a GSU or SA might do the trick. But even if you managed all that, it would still leave you with an interlaced picture and very little ability to mitigate the ensuing flicker... plus I'm not at all certain that scaling up each axis separately so the image fits perfectly on a 16:9 screen is even possible on all, or any, such displays.)
The SNES retaining the Super Famicom's external audio pins (and the S-SMP's ability to credibly mimic the 2A03) means the music shouldn't be a problem. You might even be able to manage the whole thing internally on the S-SMP, but then you'd get channel dropouts for sound effects...
...
I was mostly just commenting on the fact that the original game uses multiple parallax layers (at least 6 by my count, so even in Mode 0 you'd need to use tricks) and busts the NES palette slightly. The developers justified the former with handwaving about mappers, and the latter by pointing out that the colours they added look good. And then there's the fact that it's widescreen 240p (and the devs don't even seem to realize that using all of a 240p display is itself an accuracy issue). Basically, the game is a good example of what tokumaru was talking about.
Then again, by all accounts it's an excellent game...
tepples wrote:
Part of my hypothesis for this, if you'll recall, is the asset complexity gap between NES and Super NES. It appears to be confirmed by
this review of Sydney Hunter, which took marks off for underusing the S-PPU. Apparently you
have to have parallax, not just TG16-class graphics, if you want to sell a Super NES game.
I agree that assets are more complicated... If you're going to make an SNES game, people will wonder why bother unless it uses some of the SNES capabilities? (Similarly, if you made a NES game that looks like an Atari game, people will wonder why you made such a bad looking game)
That said, I think you're over-obsessing over the details of this one review. That one guy wanted parallax on this game. That doesn't mean every game has to have parallax.
And like DougEff said: there's a difference between "we're making these homebrew games because we want to" and "I'm trying to make a commercial success"
gauauu wrote:
If you're going to make an SNES game, people will wonder why bother unless it uses some of the SNES capabilities?
Because there is no retro platform with visual capability greater than that of the NES and GBC and less than that of the Genesis and Super NES that is well known in the Americas or Europe. Thus any game on the low end of this gap ends up having to be scaled down to the NES and GBC, and any game on the high end of this gap needs additional budget to make its graphics at least comparable to the Genesis and Super NES launch lineup.
gauauu wrote:
And like DougEff said: there's a difference between "we're making these homebrew games because we want to" and "I'm trying to make a commercial success"
A "because we want to" project with no chance of recovering the cost to house and feed the developers for the duration is practically limited to projects of less than about 1000 man-hours. Anything greater than that whose visual style lies in the gap between NES and Super NES then has to go to the PC market, which I assume is more tolerant of TG16-class visuals.
The man-hours needed to jump this gap are a big part of why no SNES homebrew scene.
tepples wrote:
The man-hours needed to jump this gap are a big part of why no SNES homebrew scene.
I respect your opinion, so please realize I'm not trying to be difficult here, but I'm not sure I buy what you're arguing. Many homebrewers (including me) don't consider the market in thinking about making a game. We just do it for whatever weird reason personally motivates us. (So why haven't I made an SNES game yet? Because I haven't finished my big NES project yet. )
The GBA (as you know) had a good homebrew scene, and the visual expectations were similar to the SNES. That scene thrived because it was an easy platform to program for. There weren't as many for-profit releases as on the NES, but the community and scene were big. I think the SNES scene would be the same way if the biggest factor was just the high expectations of visuals.
tokumaru wrote:
I don't know about the TG16 thing, because one of the first rules pseudo-8-bit games break is the single scrolling background layer, and the TG16 could only fake a second layer using sprites. I've seen many games that could slmost pass for NES games, if it weren't for the background parallax layer. Aspect ratio is disregarded very frequently too, since all displays are wide-screen nowadays. Pixels artists also appear to feel tempted to sneak in 1 or 2 extra sprite colors. The sprites-per-scanline limit goes out the window fairly frequently too.
I think a TG16 games like this is above than a nes can do
:
https://youtu.be/OHyvX5dzwEI?t=10m17sIn this game many techniques are used to fake more layers .
Quote:
It increases the dot clock rate from 5.37 MHz (like most TMS9918-inspired VDPs) to 7.16 MHz
No it's 5.37 up to 10.76,but the 10.76 mhz it's a true hi-res mode,it's not like the snes one.
Quote:
As far as I know, the TG16 VDC has 16 16x16-pixel sprites per line, roughly comparable to the Genesis and Super NES limits.
Exact, but the sprites bandwith is not increased when you switch to an higher dotclock,it's still the same in 5.37,7.16 and 10.76
Quote:
That said, I think you're over-obsessing over the details of this one review. That one guy wanted parallax on this game. That doesn't mean every game has to have parallax.
I agree, tetris is here to remind us of this.
And don't forget, sydney was coded in C and even the switch version has no parallax .
TOUKO wrote:
it's a true hi-res mode,it's not like the snes one.
What's this supposed to mean? The BG modes are true high-resolution on SNES; they're not blended except by the fact that period CRTs tended to not be super sharp. It's only the sprites that aren't hi-res, and I think that's understandable because the PPU doesn't actually upclock, so there isn't any more time to load sprite graphics during HBlank and hence using high resolution would cut the line coverage in half. (Though it'd be nice to have had the option...)
There's also a real interlace mode, and it can be applied to double the vertical resolution of sprites as well as BGs. (As in, there's a bit that causes the PPU to read even/odd lines of the sprite graphics on alternate fields, just like the BGs in Modes 5/6 with interlace on.)
"Pseudo-hires" is actual hi-res too. It's just that it requires the user to manually position graphics on main and sub screens to get the desired result, instead of reading 16x16 tiles natively.
Quote:
What's this supposed to mean? The BG modes are true high-resolution on SNES; they're not blended except by the fact that period CRTs tended to not be super sharp
This means that unlike the snes, PCE sprites are also affected by the dotclock ,not only the background tiles ,plus it seems that you can't have more than 1 bckgnd layer in this mode, true ??
Mode 5 has two layers, one 4bpp, the other 2bpp. Mode 6 has only one 4bpp layer, with offset-per-tile.
I think it's colour math that doesn't work normally. Since the main and sub screens are used for alternating half-dots, the only thing you can do is blend with the constant backdrop colour. In pseudo-hires mode with Modes 0-4 (and 7, with caveats), you can put different layers on the main and sub screens instead of even and odd pixels of the same graphic, and the TV will blur them so they look averaged; using backdrop colour math with this effect results in an apparent three-layer blend.
I agree that the sprites not being usable at H-512 resolution is annoying and limits the usefulness of the mode. However, it is a bit of a consolation that sprites can be natively displayed interlaced with no manual field toggling, and in any BG mode too. In fact, it is notable that technically both H-512 and interlace can be used to full effect in any BG mode; it's just that the special BG modes do the half-dot interleave and field toggling automatically and allow the graphics to be used as is instead of splitting them up (plus Mode 5 is more bandwidth-efficient, with effectively two normal-res 4bpp layers and two normal-res 2bpp layers, though Mode 6 can be faked in Mode 2).
How well does the manual interlace mode on the PC Engine work? Is it usable for games, or is the compatibility too dicey?
Quote:
How well does the manual interlace mode on the PC Engine work?
There is no interlaced mode on PCE,you can fake him (if is that you mean by manual) but IMO is unusable out of a demo .
Chris covell did it in his fractal demo, but i think is a simple screen switch technique (each frame you change the screen between even/odd lines), like some computers demo do for displaying more colors than the graphic chip can do .
The screen has a annoying flickering, and the frame rate drop to 30 fps,not really convenient for a game
.
Quote:
it's a true hi-res mode,it's not like the snes one.
I can't wait for @koitsu 's response to this comment.
dougeff wrote:
Quote:
it's a true hi-res mode,it's not like the snes one.
I can't wait for @koitsu 's response to this comment.
I don't know how to call it with sprites which still in low-res .
Quote:
^Used for superimposing "sfx" graphics, whatever that means. Usually 0. Not much is known about this bit. Interestingly, the SPPU1 chip has a pin named "EXTSYNC" (or not-EXTSYNC, since it has a bar over it) which is tied to Vcc.
^^When this bit is set, you may enable BG2 on Mode 7. BG2 uses the same tile and character data as BG1, but interprets the high bit of the color data as a priority for the pixel. Various sources report additional effects for this bit, possibly related to bit 7. For example, "Enable the Data Supplied From the External Lsi.", whatever that means. Of course, maybe that's a typo and it's supposed to apply to bit 7 instead.
^^^This creates a 512-pixel horizontal resolution by taking pixels from the subscreen for the even-numbered pixels (zero based) and from the main screen for the odd-numbered pixels. Color math behaves just as with Mode 5/6 hires. The interlace bit still has no effect. Mosaic operates as normal (not like Mode 5/6). The 'subscreen' pixel is clipped (by windows) when the main-screen pixel to the LEFT is clipped, not when the one to the RIGHT is clipped as you'd expect. What happens with pixel column 0 is unknown. Enabling this bit in Modes 5 or 6 has no effect.
Quote:
SETINI - Screen Mode/Video Select
2133 wb+++-
se--poIi
s = "External Sync".^
e = Mode 7 EXTBG ("Extra BG").^^
p = Enable pseudo-hires mode.^^^
o = Overscan mode.^^^^
I = OBJ Interlace.^^^^^
i = Screen interlace.^^^^^^
https://wiki.superfamicom.org/#toc-inid ... en-displayEnable pseudo-hires mode : eh,not a true hi-res mode .
gauauu wrote:
tepples wrote:
The man-hours needed to jump this [asset complexity] gap
I'm not sure I buy what you're arguing. Many homebrewers (including me) don't consider the market in thinking about making a game.
My point is that games developed without considering the market are practically limited in how many man-hours of work they can represent. At some point, a developer not considering the market still needs three hots and a cot just to survive. It's also why there are virtually no AAA games whose engine is day one free software.
gauauu wrote:
The GBA (as you know) had a good homebrew scene, and the visual expectations were similar to the SNES.
The homebrew scene for GBA produced exactly one commercial release, to my knowledge:
gbadev 2004Mbit Competition. (Disclosure: This game credits me as a composer.)
TOUKO wrote:
tepples wrote:
It increases the dot clock rate from 5.37 MHz (like most TMS9918-inspired VDPs) to 7.16 MHz
No it's 5.37 up to 10.76,but the 10.76 mhz it's a true hi-res mode,it's not like the snes one.
Based on
this post by tomaitheous, I was under the impression it had all three of 5.37, 7.16, and 10.74 MHz modes. But consider the context to which I was replying:
tokumaru wrote:
Aspect ratio is disregarded very frequently too, since all displays are wide-screen nowadays.
In the context of widescreen, 7.16 is probably the most useful because of how it preserves the pixel aspect ratio that 5.37 has on a 4:3 display. You still get 16 16x16-pixel sprites per line, and though 256/336 = 76% coverage is less than you get at 5.37, it's still a heck of a lot more than the 25% you get on an NES or even the 50% on a Game Boy or Game Boy Color.
TOUKO wrote:
gauauu wrote:
That doesn't mean every game has to have parallax.
I agree, tetris is here to remind us of this.
Then I'll qualify: Every 16-bit game that is side-view and not flip-screen has to have parallax, and even many that are flip-screen could benefit from animations behind the playfield like a cloud layer. Single-screen block games would be considered flip-screen by this definition.
Quote:
Based on this post by tomaitheous, I was under the impression it had all three of 5.37, 7.16, and 10.74 MHz modes. But consider the context to which I was replying:
No problem, the 10.76 mhz is often forgoten
Quote:
Then I'll qualify: Every 16-bit game that is side-view and not flip-screen has to have parallax, and even many that are flip-screen could benefit from animations behind the playfield like a cloud layer. Single-screen block games would be considered flip-screen by this definition.
Yes, but i wanted to say it's not necessary to have parallax or even a scrolling to make a good game(as opposed to some sydney hunter comments),even if i agree that parallaxes are a 16 bit signature .
TOUKO wrote:
Quote:
Based on this post by tomaitheous, I was under the impression it had all three of 5.37, 7.16, and 10.74 MHz modes. But consider the context to which I was replying:
No problem, the 10.76 mhz is often forgoten
Quote:
Then I'll qualify: Every 16-bit game that is side-view and not flip-screen has to have parallax, and even many that are flip-screen could benefit from animations behind the playfield like a cloud layer. Single-screen block games would be considered flip-screen by this definition.
Yes, but i wanted to say it's not necessary to have parallax or even a scrolling to make a good game,even if i agree that parallaxes are a 16 bit signature .
I think the point they're making is that parallax is so easy on the SNES (just divide your scroll x value a bunch of times and put it in RAM, then make an HDMA table with pointers to those addresses) that not putting in that effort to make your game look way nicer is a bit of a waste.
Of course ,the snes is obviously designed for that purpose, and this is why i develop only for SGX now,because of that(not only, but in part) .
But when you do an adaptation, you sometimes do not need parallaxes because the original game has no parallax, art of fighting neogeo is an example which come in mind,no parallaxes and no floor effects,and i don't think it looks less 16 bit than other games .
tepples wrote:
gauauu wrote:
The GBA (as you know) had a good homebrew scene, and the visual expectations were similar to the SNES.
The homebrew scene for GBA produced exactly one commercial release, to my knowledge:
gbadev 2004Mbit Competition. (Disclosure: This game credits me as a composer.)
That's my point. The GBA had a great homebrew scene, even if there weren't a lot of commercial releases. The SNES could have the same.
(and there were other releases than the 2004 competition cart, even if you weren't aware of them)
tepples wrote:
gauauu wrote:
If you're going to make an SNES game, people will wonder why bother unless it uses some of the SNES capabilities?
Because there is no retro platform with visual capability greater than that of the NES and GBC and less than that of the Genesis and Super NES that is well known in the Americas or Europe. Thus any game on the low end of this gap ends up having to be scaled down to the NES and GBC, and any game on the high end of this gap needs additional budget to make its graphics at least comparable to the Genesis and Super NES launch lineup.
1.) The Commodore 64 will out do a NES (MMC5 starts to get a good fight
), you can hem and haw about it. But higher res, more colours, and no stupid vblank limits,more sprite coverage and more sprite data per line. And a better sound chip, and a commercial market. Established means of digital distribution and common 1Meg carts that users can flash. Multiple fanzines, professional sites, news sites and a very active scene. The Mini has just been released and we are seeing a nice uptick in eyeballs and interest in the C64 again. And the mini while cumbersome at the moment can and does allow you to add your own disk images to play which should improve soon, and it hasn't launched in the USA yet.
But you want more... ok you want more like a SNES but not quite a SNES.. you want to be "Celeste" 10/10 levels of graphics ...
2.) The Amiga 500, dual field, 32 colours, BOBs, 68K and C development, there are a couple of engines around as well. Sample based sound makes the audio chip argument moot.
To which you can go for OCS(to cut back) or ECS(for "normal")... want a a bit more... ok go 1200 and AGA then.
3.) I feel another growth market would be MS DOS.. CGA/EGA/VGA/SVGA as you like it ;The 8bit guy is currently making a game for it and I'm curious to see the results vs the C64 market.
Oziphantom wrote:
1.) The Commodore 64 will out do a NES (MMC5 starts to get a good fight
), you can hem and haw about it. But higher res, more colours, and no stupid vblank limits,more sprite coverage and more sprite data per line. And a better sound chip, and a commercial market. Established means of digital distribution and common 1Meg carts that users can flash. Multiple fanzines, professional sites, news sites and a very active scene. The Mini has just been released and we are seeing a nice uptick in eyeballs and interest in the C64 again. And the mini while cumbersome at the moment can and does allow you to add your own disk images to play which should improve soon, and it hasn't launched in the USA yet.
Super fat wide pixels, a single button on the controller, a pansy sound chip with 3 channels and no individual gain control (hope you want arpeggios all day), complete balls for character banking, and a blanking region that is 10km wide.
Sixteen entire colors, as saturated as a worn 1960s educational film. Yes, surely this'll stomp out the NES.
Oziphantom wrote:
1.) The Commodore 64 will out do a NES
I think both systems have their strengths so there's no objective winner - which one is "the best" is a matter of opinion and the personal criteria used by whoever is judging.
Quote:
But higher res
Are you kidding me? With those fat pixels? Unless you mean the 2-color mode, but Spectrum-like graphics are hardly competition for the NES.
I bet that the average person will consider C64 graphics more outdated than what the NES has to offer, mainly because of the fat pixels that result in an overall blocky look.
Quote:
more colours
Again, are you kidding? The C64 may have better color distribution, IDK, but its master palette is much shorter than the NES's, and looks quite washed out.
Quote:
and no stupid vblank limits,more sprite coverage and more sprite data per line.
Now those are more like actual advantages. I don't think the vblank limitation is that bad though... it only starts getting in the way when you need to transfer atipically high amounts of VRAM data for NES standards (e.g. CHR-RAM animations, full backgrounds). Sprite coverage does kinda suck on the NES.
Quote:
And a better sound chip
I'm no musician, but from what I hear the C64 is indeed highly praised for its sound chip, but the NES seems quite capable too, compared to most other 8-bit systems.
SMS is the most halfway between NES and SNES, in my opinion.
If only the Master System were actually popular in North America though...
mikejmoffitt wrote:
Super fat wide pixels
In 2bpp mode. But I'll give you that one, somewhat. Then again, it's like some people think you cant have hi-res and multi-colour pixels on the same frame...
Quote:
a single button on the controller
Controllers were pretty much entirely 3 party driven (I snigger when people refer to the Competition Pro as 'the C64's joystick'). If one of them wanted to design a 2+ button controller then they were more than welcome to.
Quote:
a pansy sound chip with 3 channels
3 fully programmable channels with four mixable waveforms, 8 octaves and pulse width control that is epochs above the 2a03.
Quote:
and no individual gain control
Okay, I'll give you that.
BUT... Lets not forget the per channel ring modulators, the per channel ADSRs, oscillator sync and most of all the extremely powerful multi mode analog filter, which can be applied to any combination of the SID's channels AND an external analog audio input.
To paraphrase the SID's designer, audio chips of the time were designed with an engineer's mindset. The SID was designed with a
musician's.
Quote:
complete balls for character banking
In what respect? The VIC-II can see 16K of memory at any time. This memory is further divided into 8 character banks of 256 8x8 (or 4x8 for 2bpp) characters. That same bank is also two bitmapped screens at 8KB each, sixteen 1KB character mapped screens or 256 sprite blocks. The video bank can be changed at
any time during a frame. Can the NES execute native code from CHR-RAM without a complicated mapper? The C64 certainly can.
Quote:
and a blanking region that is 10km wide
Displaying sprites in the borders has been something in the C64 coder's toolbox for decades now. Another reason why PAL is superior, more border space to display our large sprites in!
Quote:
Sixteen entire colors, as saturated as a worn 1960s educational film.
Sixteen was still more than some of the C64's contemporaries of the time and as for the colour selection? Purely a 'Marmite' situation... you either love them or hate them. If you hate them then you can always just turn your colour dial up the the max.
Quote:
Yes, surely this'll stomp out the NES.
I could be wrong, but isn't the C64's commercial homebrew market just a bit more healthy than the NES'?
tepples wrote:
If only the Master System were actually popular in North America though...
That's kinda how people in many parts of the world feel when North Americans talk about the C64, TG16 and Atari systems other than the 2600... As far as
I am concerned, the Master System won the 8-bit war!
I don't think the Master System is anywhere halfway between the NES and the SNES though, the only real advantage it has over the NES (it is a big one, though!) are the 4bpp tiles, everything else is either at the same level or inferior to the NES (e.g. no sprite flipping, no mid-screen vertical scroll changes).
Hojo_Norem wrote:
I could be wrong, but isn't the C64's commercial homebrew market just a bit more healthy than the NES'?
A prolific homebrew market has hardly anything to do with technical superiority of a system, but with its popularity/availability. Ease of distribution is also a big factor, and computers will usually have the edge on that over gaming consoles. It wasn't until fairly recently that new parts for cartridges became more accessible.
tokumaru wrote:
everything else is either at the same level or inferior to the NES.
Eh, I'd count the fixed VDP windows on the top and/or right in its favor also. (Yes, you
can use timed code or sprite 0 hit or an IRQ to fake a top
or bottom fixed window, but not having to is better, and there's nothing like the status window on the side)
Really a shame about the sound chip, though. While I've heard some modern music composed for the SN76489 that shines, almost nothing in the commercial library really works.
Hojo_Norem wrote:
Controllers were pretty much entirely 3 party driven (I snigger when people refer to the Competition Pro as 'the C64's joystick'). If one of them wanted to design a 2+ button controller then they were more than welcome to.
Enjoy jacking up the game price to cover the non-recurring engineering cost of producing a controller to bundle with each copy of the game.
Hojo_Norem wrote:
To paraphrase the SID's designer, audio chips of the time were designed with an engineer's mindset. The SID was designed with a musician's.
A harpsichordist's, perhaps. Any other musician would have wanted an instrument that can play both
p and
f.
Hojo_Norem wrote:
Another reason why PAL is superior, more border space to display our large sprites in!
Enjoy having to translate your game for the major written languages of the European market. An NTSC game can more easily get away with being English-only.
Virtually every C64 game published in Europe since the 1990s is already English-only.
tokumaru wrote:
Sprite coverage does kinda suck on the NES.
Sprite and background coverage both, I think. (Well, MMC5 Ex maybe solves the background problem.)
tokumaru wrote:
Are you kidding me? With those fat pixels? Unless you mean the 2-color mode, but Spectrum-like graphics are hardly competition for the NES.
This was drawn in "Spectrum Mode", so I'm willing to say that the C64 is superior. Two colors per tile.
Attachment:
101528.png [ 24.31 KiB | Viewed 1111 times ]
Source:
http://csdb.dk/release/?id=101528
Localized games always struck me as odd/needless even back in the day. The flavor text on my brothers' magic the gathing cards taught me some rudimentary english before school did, while things like shadowgate etc were just poorly translated. We'd been better off with the english version. And since the 80s/early90s, non-english europeans have generally gotten a lot better at reading/listening/talking english due to the increased exposure from podcasts, forums, news sites, "tv" shows being less stilted in dialogue, etc.
Alp wrote:
This was drawn in "Spectrum Mode", so I'm willing to say that the C64 is superior. Two colors per tile.
Looks cool, but... I don't think the NES would stay much behind trying to render a similar scene, if a competent artist was behind it. I'm definitely not giving it a try, though... too much work and I'm only good with stylized graphics anyway.
Alp wrote:
tokumaru wrote:
Are you kidding me? With those fat pixels? Unless you mean the 2-color mode, but Spectrum-like graphics are hardly competition for the NES.
This was drawn in "Spectrum Mode", so I'm willing to say that the C64 is superior. Two colors per tile.
Attachment:
101528.png
Source:
http://csdb.dk/release/?id=101528This is a static screen. Very little content from "demo works" will find its way into a fully featured homebrew game.
Alp wrote:
This was drawn in "Spectrum Mode", so I'm willing to say that the C64 is superior. Two colors per tile.
Attachment:
101528.png
I could swear someone made a very similar NES screen of an old mill at some point. I thought it was by bisqwit demonstrating an automatic nametable+sprites screen generator he had made, or maybe it was thefox...? It was a long time ago though and I'm having difficulty finding the thread (if it was even in a thread).
tepples wrote:
Enjoy jacking up the game price to cover the non-recurring engineering cost of producing a controller to bundle with each copy of the game.
Exactly! When your input port is essentially 5 bits of GPIO in the Atari standard and two ADCs, you blame the market for not evolving the controller, not the computer. Three buttons were possible with some cheap electronics to abuse the ADCs, but that would have made the controllers more C64-centric and less 'works on anything that a Atari stick will'. The digital I/O lines on the C64's game ports can be switched to output. I dare say that NES style serial shifted controllers could be made to work without any extra electronics at the computer side.
Actually, come to think of it, Ocean software came up with their own cartridge bank switching system (which is uesd by the Easyflash) and used it to produce their own carts. Back then the big software houses had some real clout. If somebody like Ocean, Domark or Thalamus came along and said "We're making our own enhanced joystick and all our games from now on will use it" then it wouldn't have taken long for the others to reverse engineer it and add compatibility to their own games and/or produce their own compatible controller.
They could have, but didn't. One button and a board of keys was (most of the time) all we needed!
Quote:
Any other musician would have wanted an instrument that can play both p and f
Honest question from somebody whose musical theory is close to non-existant, what do you mean by this and is it something that the stock NES can do?
Quote:
Enjoy having to translate your game for the major written languages of the European market. An NTSC game can more easily get away with being English-only.
Back then, the devs and software houses targeted their domestic markets and their dominant language. Foreigners either had to translate stuff or like it or lump it.
tokumaru wrote:
It wasn't until fairly recently that new parts for cartridges became more accessible.
The Easyflash has been around for a few years now and some people are really beginning to use the potential. Case in point
here. No co-processors, no DMA, just pure 6502!
mikejmoffitt wrote:
This is a static screen.
You're right. How well a system represents that static scene is in no way representative of what actual games can look like.
Hojo_Norem wrote:
tepples wrote:
Any other musician would have wanted an instrument that can play both p and f
Honest question from somebody whose musical theory is close to non-existant, what do you mean by this and is it something that the stock NES can do?
p is the musical symbol for
piano or soft.
f is the musical symbol for
forte or loud.
The software-defined volume envelope of NES pulse and noise channels is versatile enough to allow sound drivers on NES to play soft, loud, or anywhere in between. Super NES S-DSP has both channel volume and either ADSR or software-defined ("gain mode") envelope control. Scaling a volume envelope is a bit trickier on Game Boy with its piecewise-linear envelopes though.
Hojo_Norem wrote:
Back then, the devs and software houses targeted their domestic markets and their dominant language. Foreigners either had to translate stuff or like it or lump it.
The market has changed since then. Because the whole market for retro games has become smaller, those developing a game of larger scope than 1000 man-hours must consider foreign markets.
Hojo_Norem wrote:
tokumaru wrote:
It wasn't until fairly recently that new parts for cartridges became more accessible.
The Easyflash has been around for a few years now and some people are really beginning to use the potential. Case in point
here. No co-processors, no DMA, just pure 6502!
That sounded surprisingly good (listening to Ichiro Mizuki was a pleasant surprise, too)! Is it streaming compressed data and decompressing it in real-time? Can't the NES do the same using a PowerPak or an Everdrive? But again, that isn't indicative of what actual games can realistically do.
Anyway, my point was that since it was a computer that could use tapes and disks in addition to cartridges, software distribution was simpler on the C64, and that may have helped with the early establishment of a homebrew scene compared to the NES, where developers had a harder time running their programs on hardware and making said programs available to the general public.
Hojo_Norem wrote:
To paraphrase the SID's designer, audio chips of the time were designed with an engineer's mindset. The SID was designed with a musician's.
Enh, this is just a marketing slogan. Also I think the NES APU is somewhat distinct from other audio chips of the same time.
There was an interview I read with the designed of the NES APU talking about how it was somewhat based on the idea of a rock band instrumentation, e.g. bass and drums = triangle and noise/DPCM. There's also the length counter feature, which seems to have a bunch of built-in durations designed around musical concepts of metre -- this feature is not really very useful, but it definitely indicates to me a "musician's" goal, if you really must drive a wedge between engineer and musician.
Really I think you get the best result when you have good engineering and good artistic capability going into the same design, but it seems to be a rare case where the person doing the work understands both, or a partnership where the two people can collaborate well with each other. Most of the time chip design probably is indeed just an "engineer" type person, because you need that skill to even build the chip in the first place.
I think both the NES APU and SID have some good and bad musical ideas, and some good and bad engineering implementations in them. TBH the per-channel volume, and extra channels of the NES win me over here, vs. the SID having such extravagant waveform control, but I think there's some great music for both.
Both of them beat the pants off many prior PSG chips like the AY or that even more limited chip in the SMS. NES' 3 duties is already way better than square only.
tepples wrote:
p is the musical symbol for piano or soft.
f is the musical symbol for forte or loud.
The software-defined volume envelope of NES pulse and noise channels is versatile enough to allow sound drivers on NES to play soft, loud, or anywhere in between.
Ah, right. Makes sense. I suppose you just have to compose the music for the hardware, rather than trying to bend the hardware to do something it really cant. I wouldn't be surprised if the SID chip that 'would have been' would have had volume per channel... but time and Commodore's executives were sometimes cruel masters.
tokumaru wrote:
That sounded surprisingly good (listening to Ichiro Mizuki was a pleasant surprise, too)! Is it streaming compressed data and decompressing it in real-time?
From what I have read that is exactly what it's doing. At 48Khz there is about 21 CPU clock cycles (at PAL C64 speed) per audio sample. That's 21 cycles to fetch, decompress, loop and poke the SID! There's a
blog post detailing it.
Quote:
Anyway, my point was that since it was a computer that could use tapes and disks in addition to cartridges, software distribution was simpler on the C64, and that may have helped with the early establishment of a homebrew scene compared to the NES, where developers had a harder time running their programs on hardware and making said programs available to the general public.
That's true. I'm surprised that somebody hasn't come up with some kind of reasonably cost effective limited mapper/memory SD card solution for NES homebrew by now. A Famicom 'SD' system of sorts.
rainwarrior wrote:
I think both the NES APU and SID have some good and bad musical ideas, and some good and bad engineering implementations in them. TBH the per-channel volume, and extra channels of the NES win me over here, vs. the SID having such extravagant waveform control, but I think there's some great music for both.
Both of them beat the pants off many prior PSG chips like the AY or that even more limited chip in the SMS. NES' 3 duties is already way better than square only.
I prefer the variety of the SID's voices myself, but I can also appreciate the 2a03's qualities... just point me in the direction of its equivalent of the HVSC and I'll be set!
And yes, what
we have is lightyears ahead of those Z80 powered AY junkheaps...
Mutter mutter Spectrum mutter mutter CPC mutter mutter...Anyway, I think I've derailed this thread long enough.
Hojo_Norem wrote:
Both of them beat the pants off many prior PSG chips like the AY or that even more limited chip in the SMS. NES' 3 duties is already way better than square only.
I prefer the variety of the SID's voices myself, but I can also appreciate the 2a03's qualities... just point me in the direction of its equivalent of the HVSC and I'll be set![/quote]
This is the best I know of:
ftp://ftp.modland.com/pub/modules/Nintendo%20Sound%20Format/.
Only problem is that it doesn't have any modern tunes like HVSC, and the organization isn't as good (IMO).
As for SID vs. NES, I vastly prefer the SID. Arbitrary sound waves for each channel, true PWM for pulse waves, programmable filters, ring modulation, etc.
The 2A03 simply cannot touch the SID from a technical aspect, but I also like the 2A03 as a separate chip, and I make music for it, whereas I have not (yet) made music for the SID, although I listen to a ton of SID music.
The 2A03 does have a sample channel, but samples are possible on the SID as well though various hacks, even going so far as to play MODs in addition to its own SID music (example:
https://www.youtube.com/watch?v=uSk9qE6_2Oc).
syboxez wrote:
samples are possible on the SID as well though various hacks, even going so far as to play MODs in addition to its own SID music
I mean, if you're going to include that, you have to include the SuperNSF playback engine that mixes MODs using the 2A03's sample channel and also plays normal sequence data using the other four channels.
I'm not thrilled by adding softsynths to either console, but they do both have ones.
lidnariq wrote:
I mean, if you're going to include that, you have to include the SuperNSF playback engine that mixes MODs using the 2A03's sample channel and also plays normal sequence data using the other four channels.
I'm not thrilled by adding softsynths to either console, but they do both have ones.
I would count that in the same category, so consider it "included".
I feel like using samples in chiptunes is cheating in general (at least when I make music), but I wouldn't count them out completely.
But taking out the use of samples with the SID, I still feel like the SID is the superior sound chip.
syboxez wrote:
I feel like using samples in chiptunes is cheating in general (at least when I make music), but I wouldn't count them out completely.
Fortunately, there's a sound chip built for those who love to cheat: the S-DSP in the Super NES.
tepples wrote:
Fortunately, there's a sound chip built for those who love to cheat: the S-DSP in the Super NES.
I'd eventually like to move to making sampled music (especially seeing as how I want to make a SNES game in the long term future), but for now I'm expanding my musical "talent" (very strong double quotes there) without samples. Also the SNES's 64KB of audio RAM is extremely limiting.
Seriously though, promoting sampled sound chips? It's almost like we're on SNESdev or something
psycopathicteen wrote:
SMS is the most halfway between NES and SNES, in my opinion.
It is a truth universally acknowledge that the SMS is more powerful than a NES.
However I've been looking at the SMS, and I'm not so sure. They say 4Mhz, the really mean 3.58mhz. The graphics are higher quality and it has VRAM build in. But lack of flipping as noted above, same sprite per line limits, the sound chip is no where near in league with the NESs. No Sprite data DMA and you have to go via the Z80 "ports" to set data. Although you can talk to the VDP during rendering, albeit at a slower pace. To which I conclude, slower CPU, less graphics update capabilities, poorer sound but more RAM and cheaper cart manufacturing, and a built in raster counter even if its a "what where they thinking" kind of implementation. Personally I'm of the option that the pad is worse than the NES but that is matter of personal preference and not something that could be counted either way. I think for raw power and capabilities the NES wins, when you throw in a MMC5 no contest.
I though the bank switching of the cart was built in, their docs are not up to the Y0shi standard, however upon closer inspection just the registers are defined not the actual banking chip is in the SMS... which doesn't make the carts as cheap as they seemed...
Oziphantom wrote:
however upon closer inspection just the registers are defined not the actual banking chip is in the SMS... which doesn't make the carts as cheap as they seemed...
It seems that they almost always just added the bankswitching hardware into the mask ROM. Which ... is probably incrementally free?
Unlicensed games seemed to usually end up with something vaguely similar to the game boy MBCs (fixed bank from $0000-$7FFF; switchable bank from $8000-$BFFF)
When I said more colours I meant "more colours on screen" something like Mayhem in Monsterland is known to have 20 colours on screen at once thanks to various blending tricks.
Another aspect of the SID is you don't have to play music to which you can put any SFX onto any channel at any time, allowing you to have 3 channels of SFX. And if one compares say Robocop 3 NES to Robcop 3 C64, C64 by a long shot. Skate or Die is a bit 50/50 but the samples on the NES lack "raw edge" that the game goes for to which C64. There there is the Turbo Outrun title screen. All of these are commercial games so not "its demo only shennigans apply"
The FM-YAM cart has just been released, there is also the SndFX cart of yore and if you really really want to make YM sound then people who own this cart would love you too, you can then use the SID for SFX with music
just beware the clocks..
The C64s wide pixels only look fat compared to their height, they are not that much bigger than a S/NES. Give then C64 divides the TV into 402x292 pixels of which we than take 320 out of those 402, in multicolour you get 201 pixels vs 256 pixels but we take 160 out of them. So you get a bit smaller than a NES pixel, or a bit wider than a NES pixel. Only you can have wider and smaller on the same screen to use it where it counts
We also get colour per 8x8 not 16x16
which means we can scroll without artifacts
The bitmap is just a bitmap there is not any special Demo effects for it. See Law of the West C64 version which uses hires bitmaps for the the game, compare with the NES for a laugh
Caren and IK/IK+ use multicolour bitmaps, Bombjack does as well I believe, Summer Camp uses bitmaps ( although underused ), Stormlord and Deliverence us scrolling bitmap. Another world ( not that one ) use AGSP to get scrolling bitmaps as well.
Another thing is the C64s 16:10 aspect ratio means if you don't use the border area you can trim the borders and it still works on a 16:9/16:10 tv/monitor without warping. It also makes it easier to port modern games.
Controller there is a standard 2 button ( the GS used it ) which has mostly been ignored, I have made a SNES to C64 adapter which is low impact on the CPU, but there is a commercial 8 SNES pad to C64 adapter people can buy, if you want to really go multiplayer
or you can get carts with 2 extra DB9s on it like the MD micormachines carts for 4 players.
All of the games are English only, however Sam's is translated into Spanish. The Spanish community is quite passionate about it and they fund raise the translation. For the Hunters Moon remaster one of the stretch goals was to add FIGS to the game and Manual. However it is not required to do FIGS.
I'm not sure the C64 scene is a little bigger than the NES. For what I can tell (please let me know if otherwise as that really help sway producers
) but selling 100 copies is a really good run on the NES. On the C64
Hunters Moon remaster KS ~350
Planet-X is 500+
Bear Essentials is 800+
Sam's Journey is 1250+
Although as noted this has nothing to do with the technically prowess of the C64 over a NES.
However logic tells me that a NES and SNES market should blow those numbers out of the water... if only Nintendo didn't make the NES mini and SNES mini "sealed "units....
Quote:
everything else is either at the same level or inferior to the NES (e.g. no sprite flipping, no mid-screen vertical scroll changes).
I agree, and the stupid vscroll lock is a big mistake IMO .
lidnariq wrote:
Oziphantom wrote:
however upon closer inspection just the registers are defined not the actual banking chip is in the SMS... which doesn't make the carts as cheap as they seemed...
It seems that they almost always just added the bankswitching hardware into the mask ROM. Which ... is probably incrementally free?
Unlicensed games seemed to usually end up with something vaguely similar to the game boy MBCs (fixed bank from $0000-$7FFF; switchable bank from $8000-$BFFF)
If you can get a SEGA mask rom made then great. However if it was built in, then you could put a 512K 5V part on a PCB put it in a case and ship. $4~5 for the cart. Now you have to add decode logic, you are going to need some 74LS parts, you need to get the cart designed by an electric engineer, your looking at $7~12 for the cart. More parts = more chance of faults/duds. Its not as "nice" at it seemed
We have such things for the C64, but the maker is able to order 10,000 at once to push the per cart price down, I doubt the SMS is in a position to do such order at the moment...
syboxez wrote:
Also the SNES's 64KB of audio RAM is extremely limiting.
It's not so bad if you're careful, skilled, and/or clever. The limits of a sound chip are what make it interesting to use, after all. And on top of the standard tricks of efficient sample use, there are all sorts of cool things you can do with the S-SMP, and some of them are recent or ongoing developments - KungFuFurby's loop switching and distortion techniques, psycopathicteen's software FM synthesizer, and so on. Even some commercial games used stuff like granular synthesis, pitchmod and FIR filter exploits, not to mention Square's famous wind noise generator. If the S-SMP had been given direct cartridge access, there might have been less interest in exploring some of the more obscure possibilities.
Besides, if you really need to bust the limit there are multiple streaming solutions out there fast enough for (low-fi) real-time playback or at least on-the-fly sample replacement. There's even commercial precedent in Tales of Phantasia and Star Ocean.
I maintain that an HDMA streaming scheme could be written to be capable of stable 2x32 kHz BRR, or 3x22 kHz, in parallel with a reasonably full-featured high-precision (>60 Hz) music engine. But I still haven't had a chance to test the streaming code I wrote, never mind write a music engine able to maneuver around it at high bandwidth. So until I do that, or someone else steps up to tackle the problem, the state of the art is (AFAIK) either N-Warp Daisakusen's stack-based HDMA scheme or SNESMOD's lazy-sync block transfer scheme (or am I out of date on what Super SNESMOD can do?). blargg's 2x32 kHz uncompressed demo doesn't count, as it requires the full attention of both CPUs and cannot be downscaled, and is thus all but useless in a game scenario...
Twin Dragons' KS (NES) had 329 backers, and they've sold carts afterwards too.
Sydney Hunter KS (NES + SNES) had 406 backers, and additional sales.
Super Russian Roulette, 1090 backers, plus sales.
Eskimo Bob, 264 backers, plus sales.
Haunted Halloween 86, 318 backers, plus sales.
Full Quiet, 509 backers.
Tower Defense 1990, 117 backers.
So at least with Kickstarter public data, the NES market is nice.
rainwarrior wrote:
Hojo_Norem wrote:
To paraphrase the SID's designer, audio chips of the time were designed with an engineer's mindset. The SID was designed with a musician's.
Enh, this is just a marketing slogan. Also I think the NES APU is somewhat distinct from other audio chips of the same time.
I don't think it's just marketese... the guy who designed SID went on to found Ensoniq. Obviously he paid a lot of attention to what musicians would want.
One could say that NES APU is designed with a musician's mindset, too, though. I don't think an engineer would implement things like the length counter lookup table without specifically being asked to.
93143 wrote:
syboxez wrote:
Also the SNES's 64KB of audio RAM is extremely limiting.
It's not so bad if you're careful, skilled, and/or clever. The limits of a sound chip are what make it interesting to use, after all. And on top of the standard tricks of efficient sample use, there are all sorts of cool things you can do with the S-SMP, and some of them are recent or ongoing developments - KungFuFurby's loop switching and distortion techniques, psycopathicteen's software FM synthesizer, and so on. Even some commercial games used stuff like granular synthesis, pitchmod and FIR filter exploits, not to mention Square's famous wind noise generator. If the S-SMP had been given direct cartridge access, there might have been less interest in exploring some of the more obscure possibilities.
Besides, if you really need to bust the limit there are multiple streaming solutions out there fast enough for (low-fi) real-time playback or at least on-the-fly sample replacement. There's even commercial precedent in Tales of Phantasia and Star Ocean.
I maintain that an HDMA streaming scheme could be written to be capable of stable 2x32 kHz BRR, or 3x22 kHz, in parallel with a reasonably full-featured high-precision (>60 Hz) music engine. But I still haven't had a chance to test the streaming code I wrote, never mind write a music engine able to maneuver around it at high bandwidth. So until I do that, or someone else steps up to tackle the problem, the state of the art is (AFAIK) either N-Warp Daisakusen's stack-based HDMA scheme or SNESMOD's lazy-sync block transfer scheme (or am I out of date on what Super SNESMOD can do?). blargg's 2x32 kHz uncompressed demo doesn't count, as it requires the full attention of both CPUs and cannot be downscaled, and is thus all but useless in a game scenario...
The spc700 is frustrating to program though. There's no interrupts so if you're doing anything in real time, you have to make sure everything is within a frame.
You do realize the SPC-700 was designed by Kutaragi , and is a "Kutaragi Special" so being a pain to program is its M.O.
Oziphantom wrote:
When I said more colours I meant "more colours on screen" something like Mayhem in Monsterland is known to have 20 colours on screen at once thanks to various blending tricks.
The NES can show 25 colors per screen without tricks.
Quote:
which means we can scroll without artifacts
The NES can scroll without artifacts too. Check out Jurassic Park, Felix the Cat, Alfred Chicken or Super Cars for various different ways in which it can be done. It's not the console's fault if Nintendo got "lazy" with its flagship title SMB3.
Oziphantom wrote:
Give then C64 divides the TV into 402x292 pixels of which we than take 320 out of those 402, in multicolour you get 201 pixels vs 256 pixels but we take 160 out of them.
I always thought the C64's dramatic underscanning looked rather unfortunate.
Nothing a modern HDTV's "zoom" feature can't fix, but...
Quote:
Another thing is the C64s 16:10 aspect ratio means [...] it still works on a 16:9/16:10 tv/monitor without warping.
Different PARs in PAL/NTSC mean different DARs...
NTSC C64 320x200 : SDTV- PAR is 3:4 , DAR is 6:5 ; HDTV stretch- PAR is 1:1 , DAR is 16:10
PAL C64 320x200 : SDTV- PAR is ≈0.94, DAR is ≈1.5 ; HDTV stretch- PAR is ≈1.25 , DAR is ≈2
And you don't get vertical chroma blending in NTSC-land ... although maybe the reduced horizontal chroma bandwidth helps there?
Oziphantom wrote:
You do realize the SPC-700 was designed by Kutaragi , and is a "Kutaragi Special" so being a pain to program is its M.O.
If you try to manipulate BRR samples in real time, you'd have to cut corners such as only using "filter 0". I don't know how long it would take the SPC700 to check which of the 4 filter types is best for an arbitrary waveform.
Oziphantom wrote:
is a "Kutaragi Special" so being a pain to program is its M.O.
Citation needed
psycopathicteen wrote:
If you try to manipulate BRR samples in real time, you'd have to cut corners such as only using "filter 0". I don't know how long it would take the SPC700 to check which of the 4 filter types is best for an arbitrary waveform.
That'd be going about it the wrong way. Instead, if you assume that you'll use the same filter for all blocks, then you can treat it as
known filtering relative to the sample rate you play back at.
If you want to blend a square with a saw and an FM synth wave (crazy example), it might get a little less clear what filter is best.
Filters 1, 2, and 3 are just nothing more than one of three fixed lowpass filters applied to filter 0.
It's really only useful for fidelity when you can switch from block to block: if you use a constant setting you're instead just saying that you want that lowpass filtering.
Actually, that's probably a good model for which filter to choose. The lower the pitches the softsynth is mixing, the stronger the lowpass filtering.
tokumaru wrote:
Oziphantom wrote:
When I said more colours I meant "more colours on screen" something like Mayhem in Monsterland is known to have 20 colours on screen at once thanks to various blending tricks.
The NES can show 25 colors per screen without tricks.
Hmm the docs I've read said 13... but I guess they meant per Background/Sprites to which sprites get 12?
C64 I can have 16 in the background(12 normally in multicolour mode), 16 in sprites. I can then use blending to push either or both above 16. Colour splits are trivial. And the colour is per 8x8 block for background, but 24x21 on sprites.. seems like the fortunes are reversed
tokumaru wrote:
Quote:
which means we can scroll without artifacts
The NES can scroll without artifacts too. Check out Jurassic Park, Felix the Cat, Alfred Chicken or Super Cars for various different ways in which it can be done. It's not the console's fault if Nintendo got "lazy" with its flagship title SMB3.
I though it was only with enchantment chips, MMC3 etc but some of those are NROM so I was wrong
lidnariq wrote:
Oziphantom wrote:
Give then C64 divides the TV into 402x292 pixels of which we than take 320 out of those 402, in multicolour you get 201 pixels vs 256 pixels but we take 160 out of them.
I always thought the C64's dramatic underscanning looked rather unfortunate.
Nothing a modern HDTV's "zoom" feature can't fix, but...
Well loosing the side of the a screen and the bottom on a NES oh well(Its possibly even a feature).. even on the PS3 we still had a "safe area", but on a word processor, spreadsheet not acceptable
lidnariq wrote:
Quote:
Another thing is the C64s 16:10 aspect ratio means [...] it still works on a 16:9/16:10 tv/monitor without warping.
Different PARs in PAL/NTSC mean different DARs...
NTSC C64 320x200 : SDTV- PAR is 3:4 , DAR is 6:5 ; HDTV stretch- PAR is 1:1 , DAR is 16:10
PAL C64 320x200 : SDTV- PAR is ≈0.94, DAR is ≈1.5 ; HDTV stretch- PAR is ≈1.25 , DAR is ≈2
And you don't get vertical chroma blending in NTSC-land ... although maybe the reduced horizontal chroma bandwidth helps there?
the Programmers Reference Guide does have a table of "don't put this colour next this colour" (p152 if you are interested) not sure what spares the NTSC from blending vertically though, we use it in PAL as one of the blending techniques. lines of Pink and light blue make a nice purple for example, sadly all the online screenshots are emulator grabs and not photos.
Punch wrote:
Oziphantom wrote:
is a "Kutaragi Special" so being a pain to program is its M.O.
Citation needed
http://www.interactive.org/special_awar ... lAwards=13https://en.wikipedia.org/wiki/Super_NES_CD-ROM See also the PS1 uses a high bit depth BBR as its main sample format like the SPC-700
Oziphantom wrote:
I though it was only with enchantment chips, MMC3 etc but some of those are NROM so I was wrong
Actually, none of those are NROM (can't remember what Super Cars uses, though!), but Jurassic Park is the only one that uses mapper features (MMC3's scanline IRQs and CHR bankswitching) for hiding scrolling artifacts, the other techniques are possible in NROM. There are a few other ways to do this without mapper assistance, even though I can't think of any games that demonstrate them all.
*UNROM
lidnariq wrote:
Filters 1, 2, and 3 are just nothing more than one of three fixed lowpass filters applied to filter 0.
It's really only useful for fidelity when you can switch from block to block: if you use a constant setting you're instead just saying that you want that lowpass filtering.
Actually, that's probably a good model for which filter to choose. The lower the pitches the softsynth is mixing, the stronger the lowpass filtering.
If you have a 64 sample loop, it could happen where one part of the loop is busier than the other.
Oziphantom wrote:
Well loosing the side of the a screen and the bottom on a NES oh well(Its possibly even a feature).. even on the PS3 we still had a "safe area", but on a word processor, spreadsheet not acceptable
Sure ... it'd just be nice if games had been able to use the whole width. The NES (and almost all the 3rd-generation-and-newer consoles) targeted an active portion of the scanline of 75%; the C64 (and Apple 2) targets an active duty of 60%. IBM CGA, Atari 2600, and Amiga OCS target a 70% active duty.
Oziphantom wrote:
the Programmers Reference Guide does have a table of "don't put this colour next this colour" (p152 if you are interested)
Yeah, that would be the low chrominance bandwidth.
Too bad the dots for "excellent" and "fair" in the scanned copy I found are indistinguishable:
Attachment:
suggested-screen-and-character-color-combinations.png [ 34.6 KiB | Viewed 2414 times ]
Quote:
not sure what spares the NTSC from blending vertically though, we use it in PAL as one of the blending techniques.
PAL and SECAM explicitly decode chroma using vertical subsampling, averaging the decoded chroma from any given scanline with the one before.
NTSC just doesn't. Better vertical color bandwidth, but worse horizontal color bandwidth.
End-of-SDTV NTSC sets often added a so-called "comb filter", i.e. the same thing as what PAL sets do, for the same reason (improving horizontal chrominance bandwidth at the cost of vertical). But that wasn't there in the 1980s.
lidnariq wrote:
Too bad the dots for "excellent" and "fair" in the scanned copy I found are indistinguishable:
This
text version has it distinguishable, starting at line 7898.
Still looks bad, so...
..................CHARACTER.COLOR................
....0..1..2..3..4..5..6..7..8..9.10.11.12.13.14.15
00 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
01 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
02 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
03 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
04 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
05 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
06 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
07 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
08 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
09 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
10 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
11 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
12 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
13 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
14 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
15 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
↑↑SCREEN COLOR
EXCELLENT - FAIR - POOR
I don't know how this topic got off on hardware capabilities, but as a homebrewer for the TG16, I can guarantee it's NOT the hardware specs. At least, *for me*, it's the lack of a good C compiler, or any decent tutorials. You can see my work here -
https://www.youtube.com/user/DarkKobo1d/videosThe turbografx has a pretty great small C compiler (1), an easy to use audio library Squirrel (2), an intro tutorial that teaches you the basics (3), and documentation on all the cool parts of the C library that make the handling of graphics and scrolling way easy for any novice coder (4). Seriously, I am making homebrews fast and easy, thanks to the great community support.
1.
https://github.com/uli/huc2.
http://www.aetherbyte.com/aetherbyte-sq ... fx-16.html3.
http://obeybrew.com/tutorials.html4.
http://www.archaicpixels.com/Main_PageSo, this is my 2 cents. If I had a decent, easy to use C compiler, I'd be porting my homebrews to the SNES, for sure.
DarkKobold wrote:
I don't know how this topic got off on X,
Welcome to NESdev, DK.
DarkKobold wrote:
So, this is my 2 cents. If I had a decent, easy to use C compiler, I'd be porting my homebrews to the SNES, for sure.
I've mentioned a few in the past:
viewtopic.php?f=12&t=15191&p=184312 . Mention of a heavily modified lcc816 has been discussed as well, by Charles Doty nonetheless:
viewtopic.php?f=12&t=1877
koitsu wrote:
So, all that said: the lack of C compiler really isn't what's keeping people from doing SNES homebrew. There's a term for this that I can't recall right now, but it's one of those "convenient excuses" that people use rather than actually putting in the time/effort to do what their heart is set on. The elephant in the room isn't the lack of C compiler, it's that "writing stuff on the SNES is hard". "What are all the registers? OMG", "I don't understand assembly language, it's nothing like Ruby/Python/Node/blah blah", that kind of thing. Consoles, much like arcades, are a completely different world. The potential gamedevs that might be considering the SNES probably come from backgrounds that are PC-centric, using a plethora of tools and languages and frameworks to accomplish their goal. You throw them into an environment that offers none of that and they're like a fish out of water. Why do you think there's such a humongous influx of indie games on Steam/etc. that have "16-bit-like graphics" but are PC (possibly Mac/Linux) titles?
You pretty much contradict yourself here. You mention that when developers have tools, languages, and frameworks, there is a "humongous influx" of games. Yet you essentially call it laziness that more homebrews don't exist for SNES.
I think I'm proof that a having a C-compiler results in more homebrews. HuC exists specifically for the Turbografx-16, which has specifically enabled me to make homebrews. Trust me, if I had to do ASM, I wouldn't be writing these. Despite the turbografx's HuC6280 (6502 architecture) not loving C, I'm still able to make fun, competent homebrews. Maybe it won't be the next Rendering Ranger, but a game just has to be fun. Alter Ego for NES was written all in C, and that game is great.
I'm by no means demanding that NESDev experts expend effort by creating a competent C compiler specifically for SNES, that handles the backend stuff of importing graphics, sounds, etc. I'm just explaining my answer as to why there is not a SNES homebrew scene.
There are a significant number of people doing hacks of SMW and other SNES games.
That tells me that there are hundreds of people who could make a SNES homebrew. But they don't. They don't need a C compiler; they know ASM. But, because a first homebrew game would look like PONG or Space Invaders, would be embarrassingly bad, as compared to the commercial SNES games.
Whereas making Space Invaders for Atari 2600 would fit in with the commercial games. So you see people happy to make those.
Consider this, in SMW, Mario has over 100 unique sprites. Thats just Mario. Add all the enemies and BG graphics... That is very time consuming.
dougeff wrote:
There are a significant number of people doing hacks of SMW and other SNES games.
That tells me that there are hundreds of people who could make a SNES homebrew. But they don't. They don't need a C compiler; they know ASM. But, because a first homebrew game would look like PONG or Space Invaders, would be embarrassingly bad, as compared to the commercial SNES games.
Whereas making Space Invaders for Atari 2600 would fit in with the commercial games. So you see people happy to make those.
Consider this, in SMW, Mario has over 100 unique sprites. Thats just Mario. Add all the enemies and BG graphics... That is very time consuming.
Not every game has to be SMW. Also, I'm just giving my perspective. I'd love to port Catastrophy to the SNES, but without a decent C compiler, I don't see that happening.
Continually repeating the mantra "if there was a SNES-centric C compiler there would be more homebrew" does not make it true. Just because you found a PCE/TG16-centric C compiler helpful doesn't mean that's the case for for a) others, and b) other systems.
I'm one of the individuals from the early 90s snesdev scene, and wrote public-domain SNES documentation. Even during the SNES's heyday there were very few homebrewn titles. I can count them on two hands, maybe even one. People back then enjoyed writing demos and things of that nature (a very 90s-esque fad) moreso than doing actual games. Because actual games require a large amount of work -- often years. For most folks, they didn't have that kind of time to dedicate to something... or the ones I knew who did wanted to be paid for it (which is why they went to work for places like Tiburon, etc.).
dougeff provided a pretty valid counterexample to the premise that if there were more tools there would be more interest. There's a huge romhacking community relating to SMW and Zelda 3 simply because those games were pivotal and people have latched on to them over the past 30 years. All that work has been done by a large number of people without a C compiler; read: people who do 65816 already. Doing an entire game engine from scratch (in any PL!), coming up with all the assets, etc. involves huge effort. Romhacking communities that dabble in things other than translation like tinkering but not creating entirely from scratch; reverse-engineering for them is part of the challenge thus fun. My point here is to demonstrate that there are people already out there with SNES-centric skills (that do not need/use a C compiler, i.e. assembly is OK for them) that have interests which don't involve making new games: only tinkering with old ones.
And actually... why does it even matter if there is a lot of homebrew for the SNES? Why does the quantity matter? Everyone should think about that one for a while; don't reply, just think deeply about it.
DarkKobold wrote:
dougeff wrote:
Consider this, in SMW, Mario has over 100 unique sprites. Thats just Mario. Add all the enemies and BG graphics... That is very time consuming.
Not every game has to be SMW.
Which popular Super NES games are
less graphically complex than
Super Mario World?
koitsu wrote:
why does it even matter if there is a lot of homebrew for the SNES? Why does the quantity matter?
It's related to something I was told in Fedora's legal issues mailing list. Unlike Debian, Fedora doesn't carry emulators because of legal threats from first-party developers, particularly Nintendo. The substantial noninfringing use argument is weak without plentiful homebrew games.
tepples wrote:
Which popular Super NES games are less graphically complex than Super Mario World?
Earthbound, of course.
<runs away>
My own experience seeing stuff like BYOND, Game Maker, ROBLOX, ZZT, MegaZeux, Klik & Play, and so on is that it doesn't matter how shitty or obscure your platform is, as long as it's easy to make games for. There's honestly so many people out there who want to make games that you're bound to scoop up
someone.
Personally, I don't think a lot of people honestly even care that much about making a professional quality game. For a lot of people, it'd just be cool to make a game on the SNES, regardless of quality, simply because it's what they grew up with.
Even for those that do want to make a game that looks on par with other SNES games, it's exactly the same issue that any indie game going for that art style would have to deal with, SNES or no, and I think artists can handle the concept of hard limitations just fine. Saying "you can only use this many colors and it has to be within this size" is not exactly a hard concept to grasp, and not every game has to push the limits with clever hardware tricks.
I don't think we should only be looking at those who already have the skills to make SNES games. Yeah, there's a lot of people making SMW hacks, but they're doing that because that's what they want to do. Meanwhile, I'm sure there's plenty of people who would like to make a SNES game, and have the patience to carry it through, but can't (or at least believe they can't) because of the barrier to entry involved.
Learning ASM really
is an extremely daunting proposition for a lot of people; keep in mind a lot of programmers have trouble just adjusting to other high-level languages with different syntax. And to those who scoff at that, no, you really don't have to be a great programmer to make a game. You don't even have to be a
good programmer. There are quite a few games out there (successful commercial ones, even) that manage to be fun to play despite their code being a hacked-together mess.
Not to mention, knowing ASM doesn't stop it from being tedious to write, especially on the scale of an entire game. Even for a technically-impressive game, not all of the code is speed-critical. In fact, personally, this is the biggest thing dissuading me from making a homebrew game. It's not that I don't have the knowledge or the skills needed. It's just that it's the graphic capabilities of the SNES that interest me the most, not the boring slog of writing out pages of 65816 ASM to do the equivalent of far less code in a higher-level language, especially when it's tedium for no particular gain.
I don't even believe it's a given that using a C compiler would be that much worse performance-wise than writing in ASM. Certainly what we have right now is pretty bad at optimization, but the 65816 is better-suited to C than the 6502 is, and on top of that, there are ways a compiler could avoid using the stack if necessary (
a relevant discussion is taking place in the NESdev forum right now, in fact).
koitsu wrote:
And actually... why does it even matter if there is a lot of homebrew for the SNES? Why does the quantity matter? Everyone should think about that one for a while; don't reply, just think deeply about it.
Would it matter if the entire SNES homebrew community was just one person sitting in an empty room, poking at a SNES circuit board with a bit of wire in a vain attempt to make a game? Would it matter if the only SNES homebrew in existence was just a text file that consisted of
lda #1 and nothing else?
I think cool stuff being made is good in general. Anything that serves to make that process easier is likewise a good thing.
(By the way, to be honest, I wouldn't even bother telling people not to reply to stuff like this; if people think it's worth discussing, they will, myself included.)
koitsu wrote:
Continually repeating the mantra "if there was a SNES-centric C compiler there would be more homebrew" does not make it true. Just because you found a PCE/TG16-centric C compiler helpful doesn't mean that's the case for for a) others, and b) other systems.
I'm literally saying "I'm a dev, I'd make homebrew for the SNES if it had a C compiler." So, at least for one dev... it's true for the SNES.
Quote:
And actually... why does it even matter if there is a lot of homebrew for the SNES? Why does the quantity matter? Everyone should think about that one for a while; don't reply, just think deeply about it.
The title of the thread is "Why no SNES homebrew scene?"
Why does an internet commentator go to a thread with a topic he isn't interested in? Everyone should think about that one for a while; don't reply, just think deeply about it.
Nicole wrote:
... I don't even believe it's a given that using a C compiler would be that much worse performance-wise than writing in ASM.
I beg to differ, though this is for a different (and substantially less limiting!) architecture:
https://stackoverflow.com/questions/250 ... erformance . Not only is the investigation and outcome itself relevant, but even more so is the fact that
one had to examine the assembly to find out the cause. And that's not even on a 90s video game console.
As an Apple IIGS user, I can tell you that C on 65816 does not particularly result in impressively fast code. We had commercial C compilers for the Apple IIGS -- specifically
ORCA/C -- which went to great lengths to do the best they could, but were always substantially slower than their pure assembly counterparts. Does speed matter? Yes, especially when doing something like implementing code run in an NMI/VBlank handler. Possible to mix C and assembly? Absolutely, and was common in the Apple IIGS days for those exact reasons -- a platform where portability wasn't a concern. Some commercial SNES games were developed this way (a mix of some C-like language and assembly).
Is C it better on the 65816 than on the 6502? Yes, mainly due to the additional addressing modes and instructions. But not substantially. The biggest problem is the lack of registers -- something that plagues the 65xxx platform in its entirety. C is better-suited for CPUs that have lots of registers and/or lots of addressing modes (68K comes to mind). There's a fairly authoritative person on the subject who I've mentioned in the past: Toshi Morita. There's
an old forum post with him discussing how he did that with lcc816 (the port generated 65816 assembly code, intended for use with ORCA/M (65816 assembler for the IIGS)), but you can see very clearly in the thread how it works under the hood -- note the reliance on large numbers of registers. Do not overlook the part discussing dags2gs2 and *.dag files.
The tarball contains a README.65816 that explains how it works.
Should I even bring up the aspect of debugging compiled C code? AFAIK there's no SNES emulator that ties into native C, unlike present-day platforms with things like Visual Studio and gdb.
My point: you're going to have to know assembly either way when working on console platforms. There are several NES/6502 threads demonstrating that already. It's funny, these aspects of development are always avoided/overlooked when discussing this subject; it's no one person's fault, but it does amuse me; it's like pragmatism/realism is thrown out the window in favour of PL fixation, no matter the realities.
Nicole wrote:
I think cool stuff being made is good in general. Anything that serves to make that process easier is likewise a good thing.
I generally agree, and don't have a problem with such efforts (to make homebrew or to make tools).
But I stand firm on my opinion that lack of a C compiler isn't the reason why SNES homebrew isn't prolific. The reason is multi-faceted. There is not an influx of people coming to forums screaming "if there was a C compiler for the SNES I'd be doing homebrew!" We now have
literally 1 person saying that. And that 1 person already has existing experience with classic consoles, plus is one of those people with deep dedication to their projects. This is often not the case with people; for every 100 people who say "I wanna {do a thing} on {classic retro system}", probably 98 of those give up because they don't want to dedicate the time to learn the system (read: not the PL, the system/architecture). My point is further proven by the fact that even in the heyday of snesdev in the early 90s, where we were all doing assembly all the time, people
still weren't putting out homebrew -- and we actually had more tools and available platforms for development at the time (ex. doing SNES code on the IIGS, actively-maintained cross-assemblers, graphics file conversion tools, and an active community and mailing list. Probably 99% of those tools never got ported from MS-DOS or Amiga to newer systems (ex. PC), so they're dead tools. I still have several of them on my hard drive!). I was part of and lived through that time, so I speak literally from experience.
Nicole wrote:
(By the way, to be honest, I wouldn't even bother telling people not to reply to stuff like this; if people think it's worth discussing, they will, myself included.)
Sorry about that, I didn't phrase my sentence well. What I meant to say was: think long and hard about what I say in this paragraph. Do not reply in haste, let the question roll around your (the readers') brain for a few days first.
I'm now regretting even replying to this thread now that I know the real reason behind it:
tepples wrote:
It's related to something I was told in Fedora's legal issues mailing list. Unlike Debian, Fedora doesn't carry emulators because of legal threats from first-party developers, particularly Nintendo. The substantial noninfringing use argument is weak without plentiful homebrew games.
I wish this had been stated right up front in the initial post, because I wouldn't be wasting my time with it otherwise. A Linux distribution doesn't include SNES emulator packages citing legal fear... okay, that's nice.
koitsu wrote:
tepples wrote:
It's related to something I was told in Fedora's legal issues mailing list. Unlike Debian, Fedora doesn't carry emulators because of legal threats from first-party developers, particularly Nintendo. The substantial noninfringing use argument is weak without plentiful homebrew games.
I wish this had been stated right up front in the initial post, because I wouldn't be wasting my time with it otherwise. A Linux distribution doesn't include SNES emulator packages citing legal fear... okay, that's nice.
I've been saying it for over seven years.
Oh look a "commercial" new game written for the SNES using C
https://collectorvision.com/shop/snes/s ... -of-death/ pity about the glitches ....
If the only thing that stops you is not having a C compiler, then you probably don't want to make a SNES game. Writing 65816 is a means to an end, if you want to make a SNES game then you make a SNES game, using the 65816 is just the tool to make it. As koitsu points out you have to be fluent in 65816 to debug and work on the game, once you have crawled and walked in ASM then you can take the taxi that is C for the bits you can. This is still somewhat true today, Being able to read MIPS really helped when developing for the PSP, PS2. Yes it gives you C++ level debugging but sometimes you just get a random crash and being able to look at the ASM to work out what and where was critical. With iOS knowing ARM really really helps as the iOS debugger is rubbish.
Games don't have to be as good as SMW, people don't want SMW they expect DKC3
What might help is making conditions that drop the entry expectations. For example in C64 land we have a 4K crap-tastic game compo, then we have 16K cart compos this drops the concepts and expectations for games, so more get made as people can commit enough time to bash out a 4K game or 2, but to make a 512K cart top of the line game takes 3 years. Maybe a 32K SNES game compo?
Quote:
But I stand firm on my opinion that lack of a C compiler isn't the reason why SNES homebrew isn't prolific.
Just my $2, but I wanted to say I fully agree with Koitsu. If someone really wants badly to make a SNES game they will use whathever tools are available, and possibly make their own if that's possible and makes the work easier. They'll use whathever language is available for the platform, it's just a tool to get the game done. Needed to code the game specifically in C seems ridiculous to me.
Quote:
If the only thing that stops you is not having a C compiler, then you probably don't want to make a SNES game.
Exactly.
Oziphantom wrote:
What might help is making conditions that drop the entry expectations. For example in C64 land we have a 4K crap-tastic game compo, then we have 16K cart compos this drops the concepts and expectations for games, so more get made as people can commit enough time to bash out a 4K game or 2, but to make a 512K cart top of the line game takes 3 years. Maybe a 32K SNES game compo?
This actually sounds like a great idea!
koitsu wrote:
We now have literally 1 person saying that. And that 1 person already has existing experience with classic consoles, plus is one of those people with deep dedication to their projects.
Hey, I've also been saying that, probably a few pages back in this very thread, as well in others. I don't want to reiterate everything I said before, but there's plenty of reasons supporting the need for a C compiler.
Oziphantom wrote:
Oh look a "commercial" new game written for the SNES using C
https://collectorvision.com/shop/snes/s ... -of-death/ pity about the glitches ....
The glitches in Sydney Hunter are not the fault of C, but mostly just programming bugs. I had higher expectations given alekmaul's reputation.
As for my current SNES project, it was shown at Too Many Games at Mega Cat's booth recently, and will soon be available on the website. It uses cc65, and we're all familiar with cc65's quality; however it's currently the best option for a SNES C compiler. It even supports some of the 816 constructs, generating slightly better code than for 6502. Unlike tcc816, it's not absolutely unusable quality, and the codegen bugs are few and known. OTOH it does not support the SNES banking scheme nicely, which would be a requirement to do bigger SNES games.
Has anyone tried the official WDC C compiler? The website claims it to be free.
http://www.westerndesigncenter.com/wdc/tools.cfm
also worth noting that the 65816 has 6502 emulation mode but also in its native with a/x/y as 8 bits it has most of the extra R6502 opcodes. So you could use the PCE compiler, you won't have its fancy Test/set bit opcodes but they should be easy to mitigate in you c code?
dougeff wrote:
Has anyone tried the official WDC C compiler? The website claims it to be free.
http://www.westerndesigncenter.com/wdc/tools.cfmI tested it some time ago. Unfortunately it produced wrong code when using arrays of chars (if I remember correctly). I gave up on it assuming more errors were waiting.
Quote:
But I stand firm on my opinion that lack of a C compiler isn't the reason why SNES homebrew isn't prolific.
I don't understand why many of you are fighting against that idea... Of course not having a good C compiler is a problem.
That is not the *only* problem but definitely it closes some (a lot of) doors.
Generally speaking i think the lack of good development tools / library plays for a big part in this situation, and lack of good C compiler is one of the major issue. Myself i wanted to do some development for the SNES but i didn't pushed it for 2 reasons:
- the lack of GCC toolchain for the 65816 CPU (preventing compiling my own dev env for it)
- the convoluted hardware (i was terribly disappointed when i started to read documentations after having played with MD hardware).
If we can get a decent SDK with a good C compiler then i would do some coding for the SNES as it would "resolve" these 2 problems.
PVSnesLib is a good start imo but it need some polishes (easier installation), probably a better C compiler (at least one where you don't have to care about banking issue and be able to use basic 8/16/32 bit data type) and higher level methods to have a bit more abstraction with the hardware (which is quite complicated to deal with).
I would even say that having a good C compiler isn't much of a problem, as you can always use 65816 assembly when you require it. The problem for me isn't having to use 65816 assembly, i think that at some point you may need it but i just don't want to do 100% assembly code, that is imo terribly painful and a complete waste of time... Ideally i would stay with as much C code as possible (90%) and only put assembly on critical sections (10% at most) when i need it, and I think that is possible even with an average C compiler.
The SNES is more popular than the PC Engine and the Sega Megadrive however it receives much less homebrew than these 2 systems... there is probably a good reason (or several) for that.
Stef wrote:
Ideally i would stay with as much C code as possible (90%) and only put assembly on critical sections (10% at most) when i need it, and I think that is possible even with an average C compiler.
Why would do need C specifically ? You could just as well code 90% in any other language and the critical 10% in assembly.
Bregalad wrote:
Stef wrote:
Ideally i would stay with as much C code as possible (90%) and only put assembly on critical sections (10% at most) when i need it, and I think that is possible even with an average C compiler.
Why would do need C specifically ? You could just as well code 90% in any other language and the critical 10% in assembly.
You're right, but C is a well know language,and you can also code easily in basic on Md,but the SDK is less powerfull than SGDK .
For a starter it's more easy to learn only a coding language and after the whole machine than both at the same time,mainly on snes which is a bit complicated to learn for a non experienced coder .
For me a high level language is a good and easy way to learn how to manage datas for a specific system, like graphics,sounds, etc .. without the complexity of the assembly that can scare a newbie,and later permit him to migrate slowly to the assembly .
On PCE, this was the main purpose of Huc,and not to code complex games .
Bregalad wrote:
Stef wrote:
Ideally i would stay with as much C code as possible (90%) and only put assembly on critical sections (10% at most) when i need it
Why would do need C specifically ? You could just as well code 90% in any other language and the critical 10% in assembly.
Because C compilers targeting 65816 are known to exist. Or which "high-level" language other than C do you recommend that compiles to 65816 assembly language?
What kind of hardware abstractions does it need? I know it probably needs a DMA function, but what if that ends up being very speed critical?
When i said hardware abstraction, i speak about low level stuffs in general. In the end the library / API still need to fit the hardware design in some ways, but for instance it would be nice to not having to know that the OAM is split in 2 parts. At higher level i would say you won't even need to know you need to fill a OAM.
I don't necessary want to promote my work but let take an example with SGDK (which is for the MD system).
You have 2 sprites API, the first one is a low level API close to the hardware:
https://github.com/Stephane-D/SGDK/blob ... /vdp_spr.hThis API is really close to the hardware design and you really need to know how sprite hardware is working to use it correctly, still it provides advanced feature as "dynamic" allocation of hardware sprite to make easier usage of it, and of course as it's low level you can get really good performance out of it if you use it correctly
Then you have the advanced sprite engine which is much higher level (as the one you're designing on SNES):
https://github.com/Stephane-D/SGDK/blob ... rite_eng.hWith the sprite engine you don't really need to know how hardware sprite work internally, it will do all the heavy stuff for you (meta sprite, handling resource allocation, depth sorting, easy animation...). Still the sprite engine is flexible enough to allow more control which can be useful to optimize resource allocation and performance in general. With the sprite engine you won't get 100% of what the hardware can do but it will make your life much much easier to display and animate sprites in general. And it will be good enough for 90% of the use case (as you can always use static allocation when needed)... i really believe that kind of high level API / library which can bring more developers to a platform: you just need to be familiar with C language (which a lot of developers already known) and understand a bit about how old 2G game systems were working to start developing on the system. And when you get more familiar with the system hardware you can try to go on lower levels parts...
Starting immediately with very low level and assembly is just too much for a lot of people, we don't want to spent 3 weeks just to understand how to display a simple "hello world" string on the screen.
Stef wrote:
Starting immediately with very low level and assembly is just too much for a lot of people, we don't want to spent 3 weeks just to understand how to display a simple "hello world" string on the screen.
If they don't want to spend 3 weeks for "hello world", then they probably won't ever spend the time to make a full game for the system. I spent probably well over 3 weeeks when I wanted to do a "hello world" on NES back when I started this activity in 2002 at age 13 without any knownledge of the english language back then.
While good C tools may be an inclusion factor for additional devs, i don't think language choice is the main problem here. It's assets, and scope (you need more content for the same measure of playtime, and buyers will expect more playtime). Developing a new product identity with all-original content from scratch for the SNES is well beyond the pain threshold for many devs and artists alike. I do hope to get there one day, but not before i've established a good product identity for the NES first that just might be viable for expansion, which is still a significant task. Once i have one that might fit the bill, stepping the assets up won't be as large a leap as creating all-new. Tilesets can be drawn over and expanded. Music can be rearranged. For me at least, that's the most sensible route: to make a nes game good enough to maybe warrant a follow-up with a super prefix.
65816 assembly is principially more convenient than 6502 assembly. You can be more wasteful with resources, and you have convenience instructions that reduce the human error factor. The 5A22 has additional convenience features beyond that. But if all you have is "programmer art", then what purpose is there developing for the SNES in the first place? You're probably doing it for the specifics of its visuals, sound and controller interface.
Bregalad wrote:
If they don't want to spend 3 weeks for "hello world", then they probably won't ever spend the time to make a full game for the system. I spent probably well over 3 weeeks when I wanted to do a "hello world" on NES back when I started this activity in 2002 at age 13 without any knownledge of the english language back then.
Because you were truly passionate and you deeply wanted to do it... but that is not the case of everyone.
If the first step seems to be too high then a lot of people will be discouraged even if they had motivations to do it. At the opposite if things seems to be really easy (you can get your first "hello world" working in a couple of hours) then you may gain attention to the system when you weren't in first place, and at the end you may eventually find interests in developing something bigger.
Stef wrote:
When i said hardware abstraction, i speak about low level stuffs in general. In the end the library / API still need to fit the hardware design in some ways, but for instance it would be nice to not having to know that the OAM is split in 2 parts. At higher level i would say you won't even need to know you need to fill a OAM.
There's syntax vs. semantics. A higher-level language should be able to translate "a = b;" (or "a := b") to the necessary mnemonic, depending on the current register state and where these variables/values are located. But it shouldn't abstract the SNES-specific hardware features; that can indeed be handled by an API function call.
i.e. the language for the 65c816, a lower-level library for the SNES and a higher-level library for a game engine.
Bregalad wrote:
Stef wrote:
Starting immediately with very low level and assembly is just too much for a lot of people, we don't want to spent 3 weeks just to understand how to display a simple "hello world" string on the screen.
If they don't want to spend 3 weeks for "hello world", then they probably won't ever spend the time to make a full game for the system. I spent probably well over 3 weeeks when I wanted to do a "hello world" on NES back when I started this activity in 2002 at age 13 without any knownledge of the english language back then.
I'm sorry but you're just showing your prejudice against high level programming. The small-C ish compiler for the PC engine is responsible for all current (and excellent) homebrew available, which despite being completely ignored when posted some pages before it's a pretty strong real-life example of real programmers doing real games for real 16-bit systems. Same with other consoles with varying levels of processing power (even Batari Basic expanded the 2600 homebrew library quite well).
Punch wrote:
I'm sorry but you're just showing your prejudice against high level programming. The small-C ish compiler for the PC engine is responsible for all current (and excellent) homebrew available, which despite being completely ignored when posted some pages before it's a pretty strong real-life example of real programmers doing real games for real 16-bit systems. Same with other consoles with varying levels of processing power (even Batari Basic expanded the 2600 homebrew library quite well).
To me, it seems like a form of "gatekeeping." You are only allowed to program for SNES if you learn ASM, and really care to put in the hard work! Who wants more homebrew anyway?
I love the SNES, and I'd love to port my games. While C isn't the be-all end-all, and has it's own caveats, it's the easiest general way to put a game together. I feel like the general people here don't want more homebrew.
I may just port to Genesis, and it's horrid sound chip.
DarkKobold wrote:
I feel like the general people here don't want more homebrew.
I know I've said nothing else here, but I'd really be happy to see more SNES homebrew. (And yes, I wouldn't care what language it was written in!) I just don't have the correct kinds of skills to help with it.
We do have a few grumpy people, unfortunately.
In C compilers, is it common to pad 8-bit variables to 16-bit words? Otherwise it would have to do all kinds of stuff with XBA and REP/SEP if you're adding or subtracting an 8-bit value from a 16-bit value.
psycopathicteen wrote:
In C compilers, is it common to pad 8-bit variables to 16-bit words? Otherwise it would have to do all kinds of stuff with XBA and REP/SEP if you're adding or subtracting an 8-bit value from a 16-bit value.
C structs are often padded, usually just to align to the size of the type of the next variable in the struct. The compiler is allowed to do this if needed for alignment or optimization. It's also common to have #pragma pack directives to disable it, where you need a specific memory layout.
Alignment is the biggest issue necessitating this for the most part. On many modern platforms unaligned access might be a large performance problem, or even cause a crashing fault. It can also help with calculating the stride offsets for an array of structures if it's a power of two.
Similarly, the result of malloc() is usually always aligned to 16-bytes or some other size so that it can be safely used with any primitive types the platform requires alignment for. There are compiler-specific extensions to add alignment requirements to types/structs as well. (C++11 finally created a standard "align" keyword.)
If you're asking if CC65 does it, no I don't think it does (there's not even a #pragma pack), but it also has no aligned types since it only generates 8-bit code, so it doesn't really have any need for it either. Manually padding a struct for power-of-two stride might help a little though.
rainwarrior wrote:
Similarly, the result of malloc() is usually always aligned to 16-bytes or some other size so that it can be safely used with any primitive types the platform requires alignment for. (There are compiler-specific extensions to add alignment requirements to types/structs as well.)
And if it's not implied or apparent to readers: this details of how this is accomplished (re: dynamic memory allocation) is complicated, compounded with mass variances between implementations (GNU libc vs. uClibc vs. musl vs.
FreeBSD 9.x and earlier libc (uses its own implementation) vs.
FreeBSD 10.x later libc (uses jemalloc). Functions like
aligned_alloc() (and non-standard
MALLOCX_ALIGN() and
MALLOCX_*_ALIGN() for jemalloc) can guarantee alignment on some other boundary of your choice.
Off-topic but semi-relevant: what's often unknown to general programmers is that many malloc implementations actually allocate more than what you ask for (ex.
malloc(32) will probably allocate 4096 bytes internally, but may pick something larger or smaller depending on all sorts of logic and heuristics), since the malloc implementation itself manages pages into different categories/sizings to greatly minimise memory fragmentation. I believe several implementations also care deeply about cache line size. For jemalloc, the implementation is actually described in the IMPLEMENTATION NOTES section of the man page I linked, ditto with older FreeBSD's libc.
As for compilers (not libc/malloc!) deciding what to pad: depends on compiler. This is especially a problem for
structs (it's one of the most commonly-discussed topics). rainwarrior covered that most of its controlled with
#pragma, varying per compiler. Usually you'll find someone using something like
__attribute__((aligned(XXX),packed)).
Wikipedia has an article on the general matter of data structure alignment complexities with lots of C details. Eric Raymond also has
a very detailed page on the matter.
Today's C compilers are often focused on portability (which was not a focus of C when originally created in the 70s, but within 4-5 years became a serious focal point that remains today), so there's that trade off too.
It sounds to me like folks complaining about lack of C compiler essentially are saying "assembly is fine but it takes a long time to write + is more tedious to deal with than something like C". And that's very true! Reading between the lines, to me that means an intermediary PL that is 65xxx-series friendly (re: limited registers, etc.), but not as tie-consuming as assembly, would benefit the masses. What's funny about that is in the 70s and early 80s, there were some PLs invented with that sort of thing in mind (given the design of CPUs and systems during that era)... all of which by today have (generally) fallen out of favour in exchange for more commonplace PLs... C being one such PL. :-)
There really isn't something that fills the gap between C and assembly, and definitely even more so when taking the limits of the 65xxx architecture into consideration. As such, the best two things we have right now are: a) cc65, which has had some games written in it (with assembly being required for important bits), and is 6502-centric (read: does not benefit from additional 65816 instructions, addressing modes, and register sizes), and b) Toshi Morita's lcc816, which in its current form won't emit 65816 assembly that's compatible with any present-day 65816 cross assembler.
If I could magically wave my arms and make something happen, it would be to fix/improve 65816 support for cc65 and ca65 (the assembler, which does not cater well to 65816 in its present form (I've discussed this before)), and tell people "if you know C, use this, but you are expected to also know 65816". If said magic happened, I think Stef would probably put in the time/effort to do the dev env/lib/framework to make development easier for folks. But I'm not a magic wizard. IMO, the effort to make TM's lcc816 work with some present-day 65816 cross assemblers (ex. WLA-DX, etc.) would probably take less effort, *unless* the person doing the work is more familiar with compiler internals and compiler theory.
And none of this even begins to touch base on graphical or audio tools. That's a whole other world of hurt that, much like assemblers, had better support back in the snesdev heyday of the early 90s. I could talk about that for hours but it's way off topic. I do remember one thing, though: in the early 90s, there were lots of people who got interested in snesdev, did little doo-dads, then disappeared into the void once the subject of SPC700/audio/music came up. I think the SNES happens to be an incredibly complicated console, probably overly so, but in a lot of ways I still think it feels way, *way* easier to program/work on than the NES. I guess because I started with the SNES and later did NES stuff makes me a bit biased towards the 16-bit console.
koitsu wrote:
It sounds to me like folks complaining about lack of C compiler essentially are saying "assembly is fine but it takes a long time to write + is more tedious to deal with than something like C". And that's very true!
Of course, definitely this. I still think that for some people it would be even better to avoid using assembly at all if possible...
Quote:
Reading between the lines, to me that means an intermediary PL that is 65xxx-series friendly (re: limited registers, etc.), but not as tie-consuming as assembly, would benefit the masses. What's funny about that is in the 70s and early 80s, there were some PLs invented with that sort of thing in mind (given the design of CPUs and systems during that era)... all of which by today have (generally) fallen out of favour in exchange for more commonplace PLs... C being one such PL.
There really isn't something that fills the gap between C and assembly, and definitely even more so when taking the limits of the 65xxx architecture into consideration. As such, the best two things we have right now are: a) cc65, which has had some games written in it (with assembly being required for important bits), and is 6502-centric (read: does not benefit from additional 65816 instructions, addressing modes, and register sizes), and b) Toshi Morita's lcc816, which in its current form won't emit 65816 assembly that's compatible with any present-day 65816 cross assembler.
I don't think we really need to create a new intermediate PL, i think it would be better to improve the current available C compilers, standing with C language is definitely preferable as many people already know it and it offers easier portability (at least for some parts of the code).
Quote:
If I could magically wave my arms and make something happen, it would be to fix/improve 65816 support for cc65 and ca65 (the assembler, which does not cater well to 65816 in its present form (I've discussed this before)), and tell people "if you know C, use this, but you are expected to also know 65816". If said magic happened, I think Stef would probably put in the time/effort to do the dev env/lib/framework to make development easier for folks. But I'm not a magic wizard. IMO, the effort to make TM's lcc816 work with some present-day 65816 cross assemblers (ex. WLA-DX, etc.) would probably take less effort, *unless* the person doing the work is more familiar with compiler internals and compiler theory.
To be honest i don't know well these compilers but from what you told here, it sounds that trying to improve LCC816 to make it generate compatible assembly listing would be easier. But i don't really get it, i guess LCC816 is already producing valid binary code right ? what is the problem with it ? it don't allow to mix assembly code with C code ?
Quote:
And none of this even begins to touch base on graphical or audio tools. That's a whole other world of hurt that, much like assemblers, had better support back in the snesdev heyday of the early 90s. I could talk about that for hours but it's way off topic. I do remember one thing, though: in the early 90s, there were lots of people who got interested in snesdev, did little doo-dads, then disappeared into the void once the subject of SPC700/audio/music came up.
...
Yeah but that is something that will come next, first a "usable" C compiler, then a good library with good tools :p
That is just story of developing existing tools / libraries... from what i saw on this forum today things get better, we have sound driver good enough to be usable in game condition. Just need to include them in a SDK with a C API so they become easier to use
Stef wrote:
To be honest i don't know well these compilers but from what you told here, it sounds that trying to improve LCC816 to make it generate compatible assembly listing would be easier. But i don't really get it, i guess LCC816 is already producing valid binary code right ? what is the problem with it ? it don't allow to mix assembly code with C code ?
Syntax for directives and expressions varies from one assembler to another. It's not nearly as big as the difference between Intel syntax and GNU assembler's AT&T syntax in i386, between Sony and MOS syntax in SPC700, or between Intel and Zilog syntax in 8080/Z80, but it does mean you can't assemble the same source code file in (say) ASM6 and ca65. My solution when building
Action 53 was to write preprocessors to turn a subset of NESASM or x816 syntax into something that ca65 could handle.
I think you can make an assembler with new instructions to make it more orthogonal, such as:
ldx long
but that will have to assemble to:
sta shadow_reg
lda long
tax
lda shadow_reg
which can slow it down quite a bit, it would have to use a bunch of variations depending on which regs are available.
if A is available:
lda long
tax
if A is unavailable, but Y is:
tay
lda long
tax
tya
If directly before or after a "sta mem"
sta mem
lda long
tax
lda mem
Just too many variations.
Stef wrote:
To be honest i don't know well these compilers but from what you told here, it sounds that trying to improve LCC816 to make it generate compatible assembly listing would be easier. But i don't really get it, i guess LCC816 is already producing valid binary code right ? what is the problem with it ? it don't allow to mix assembly code with C code ?
Toshi's lcc816 outputs assembly, not binary. Its assembly is intended for use with ORCA/M, the Apple IIGS assembler -- which obviously nobody here is using. :-) I still have both my IIGS and ORCA/M (incl. manuals in PDF format); it's a top-grade assembler, so understanding what all the mnemonics and control directives do is very much possible. There are also several bits that apparently output not-very-great code, which were rectified somehow but I believe Toshi lost the macros that improved it. Please refer to the 6502.org thread I linked in a previous post for some details that he himself provides. Toshi's also still around/active -- you can find him on LinkedIn or talk to him on the 6502.org forum -- and is a super friendly guy who did actual commercial SNES games (specifically the Zombies Ate My Neighbours SNES port).
what actually is the "difficult" part about the SNES?
The DMA stuff could just be wrapped in a macro, or you make macro that presets the 8 channels to do a thing, then get them to fire each DMA channel off as they want to do Thing X.
How modular is ORCA, it is probably fairly easy to get a 65816 simulator and then enough Apple //gs file system rom mocked enough to give it what it expects and then run the ORCA assembler at ghz speed on a pc without having to go through a whole //gs emulator? That and its probably not that hard to translate the assem output. But having the 65816 simulator would be nice for other debugging tasks such as linking it in with BDD6502
For me, the banking is the greatest PITA.
All this time spent discussing SNES compilers, could have been spent working on a support library.
I think I attempted making one a long time ago, but I forgot where it is.
Oziphantom wrote:
How modular is ORCA, it is probably fairly easy to get a 65816 simulator and then enough Apple //gs file system rom mocked enough to give it what it expects and then run the ORCA assembler at ghz speed on a pc without having to go through a whole //gs emulator?
I expect by linking
my collection of 65816-related assembler documentation that you will read it. When I said, quote, "top-grade assembler", I am not kidding. You'll understand soon enough. But I feel you're asking the wrong question. There is no point in trying to "port ORCA/M" in its entirety. The question you should be asking is "what ORCA/M directives does Toshi's lcc816 emit", followed by looking at it, followed by referencing the ORCA/M manual for answers, followed by changing the relevant code in lcc816 to emit output for other types of present-day assemblers. When Charles Doty said that he did a SNES homebrew in a heavily-modified lcc816, I'm fairly sure this is what he meant (combined with probably lots of macro/code generation changes and optimisation; Charles does 65816 just like the rest of us). So, really, spending the time to examine TM's lcc816 would probably make a better first step... if someone even wants to do it. Talk is cheap these days, and I'm just as subject to that statement as anyone else.
I have a working signed and unsigned 16x16 to 32bit multiplication routine, for anybody working on a library.
Code:
signed_16_bit_multiplication:
stz {product}+2 //high word of product needs to be cleared
sep #$10
ldx {temp}
stx $4202
ldy {temp2}
sty $4203 //set up 1st multiply
ldx {temp2}+1
clc
lda $4216 //load $4216 for 1st multiply
stx $4203 //start 2nd multiply
sta {product}
lda $4216 //read $4216 from 2nd multiply
ldx {temp}+1
stx $4202 //set up 3rd multiply
sty $4203 //y still contains temp2
adc {product}+1
adc $4216 //add 3rd product
sta {product}+1
ldy {temp2}+1
sty $4203 //set up 4th multiply
lda {product}+2 //carry bit to last byte of product
bcc +
adc #$00ff
+;
adc $4216 //add 4th product
cpx #$80 //x is currently temp high byte
bcc +
sbc {temp2}
+;
cpy #$80 //y is currently temp2 high byte
bcc +
sbc {temp}
+;
sta {product}+2 //final store
rep #$10
rts
unsigned_16_bit_multiplication:
stz {product}+2 //high word of product needs to be cleared
sep #$10
ldx {temp}
stx $4202
ldy {temp2}
sty $4203 //set up 1st multiply
ldx {temp2}+1
clc
lda $4216 //load $4216 for 1st multiply
stx $4203 //start 2nd multiply
sta {product}
lda $4216 //read $4216 from 2nd multiply
ldx {temp}+1
stx $4202 //set up 3rd multiply
sty $4203 //y still contains temp2
adc {product}+1
adc $4216 //add 3rd product
sta {product}+1
ldy {temp2}+1
sty $4203 //set up 4th multiply
lda {product}+2 //carry bit to last byte of product
bcc +
adc #$00ff
+;
adc $4216 //add 4th product
sta {product}+2 //final store
rep #$10
rts
koitsu wrote:
If I could magically wave my arms and make something happen, it would be to fix/improve 65816 support for cc65 and ca65 (the assembler, which does not cater well to 65816 in its present form
I actually think 65816 support in CC65 would be a detriment; writing an alternate CRT library for it would be okay, but I think it would add so much complication to the internal code generators to support both 8 and 16 bit that it would be a huge drag on the project going forward.
A
fork of CC65, on the other hand, that doesn't have a mandate to continue its primary support for the 8-bit 6502, might be fairly feasible for an interested programmer? Maybe you could even replace enough modules from the original completely, so that you have a separate compiler binary that can otherwise share some code cleanly with the original CC65...
CA65, on the other hand, has rather good support for 65816, in my view, and it was very practical for it to do so.
koitsu wrote:
Oziphantom wrote:
How modular is ORCA, it is probably fairly easy to get a 65816 simulator and then enough Apple //gs file system rom mocked enough to give it what it expects and then run the ORCA assembler at ghz speed on a pc without having to go through a whole //gs emulator?
I expect by linking
my collection of 65816-related assembler documentation that you will read it. When I said, quote, "top-grade assembler", I am not kidding. You'll understand soon enough. But I feel you're asking the wrong question. There is no point in trying to "port ORCA/M" in its entirety. The question you should be asking is "what ORCA/M directives does Toshi's lcc816 emit", followed by looking at it, followed by referencing the ORCA/M manual for answers, followed by changing the relevant code in lcc816 to emit output for other types of present-day assemblers. When Charles Doty said that he did a SNES homebrew in a heavily-modified lcc816, I'm fairly sure this is what he meant (combined with probably lots of macro/code generation changes and optimisation; Charles does 65816 just like the rest of us). So, really, spending the time to examine TM's lcc816 would probably make a better first step... if someone even wants to do it. Talk is cheap these days, and I'm just as subject to that statement as anyone else.
Modular is probably not the right word, or at least doesn't easily convey what I meant.
The Docs are there and the assembler doesn't look that intense, I have assemblers on the C128 that are getting to be as much, not quite as much but getting there, no linker though. However the whole package is quite complete, the debugger for example. My question was more does it roll everything itself or does it have a small program set that one can fire form what ever Apple //gs uses. Its been a long time since I've used one. Is it a ProDos? set, or did it throw the Apple stuff out the window and roll its own. The Docs mention how to do everything in the shell, but does the assembler exist by it self and can just be run from prodos for example. Something that I feel can probably only be answered by somebody familiar with the tool and the Apple //gs.
I agree its not the best long term solution and one would only do what is needed. However if one could easily get the assembler and linker running in a simulator it would greatly add testing I would think as you can then write tests to check the binary comparability of the original output vs 'the new system'
ORCA/M only runs under GS/OS, and from a system with a hard disk (you heard me right). It includes a CLI shell and tons of tools -- meaning: an entire development environment. It isn't an assembler/tool suite that is intended to be used from, say, a bootable floppy disk running ProDOS 8. Merlin 8/16 is more for the latter. ORCA/M is a very large suite of programs -- Byteworks also made a Pascal compiler (ORCA/Pascal) and a C compiler (ORCA/C) for the IIGS too. The shell is just what makes using the programs necessary, because the IIGS (incl. in GS/OS) does not provide a native CLI. So, the ORCA shell is what makes using the tools possible.
But for Toshi's stuff, you don't need to
run ORCA/M to port his work over to a different assembler. All you need is to understand the ORCA/M assembler's syntax -- Chapters 18 and 19 are important -- and then convert whatever code is generated into output for other assemblers that you want to use (ex. WLA-DX). You don't need a simulator, there's nothing to simulate***.
Anyway, it might not be necessary at all, instead different work can be done. I don't know how complete Toshi's work was at the time, but here's something I found:
There is apparently
a different lcc816 port that can output 65816. It has IIGS support -- I can see it supports
-target=wdc65816/iigs. That is to say: it has knowledge of different Apple IIGS capabilities, such as toolbox functions in GS/OS, ProDOS API/filesystem calls, GSBug interfacing, blah blah blah... but that's not important. What's important is the fact that
it can generate 65816 from C, and its
crt support seems OK. What's in the former directory are essentially the dags that control the code generation. The Apple IIGS itself doesn't have to be the "target platform", the SNES can be the target platform (and of course someone has to write all the necessary interfaces for MMIO registers blah blah if they want), but I'm not sure it's necessary at first (for just raw 65816 assembly generation); the
multiplication/division routines for example, could be modified to use the SNES's mult/div MMIO registers/circuitry.
I believe that version of lcc816 could be modified to work for what people want. I can't exactly figure out what assembler it's outputting for -- Toshi's version from days of yore was outputting for ORCA/M, but this may be very different -- and the docs are a complete travesty (IMO), but a brief skim of some of the grammar and declarations (
example) look like it it may be using some ORCA/M-like syntaxes but I imagine some other assemblers use similar syntax. Refer to ORCA/M's manual, Chapter 18 and Chapter 19 for some syntactical details.
Point is: all the necessary bits to get C->65816 generation are there. Someone just needs to build binaries for different platforms (ex. Win32, etc.) and try to figure it all out. I sound like a broken record, but: if people want it this bad, they will put in the effort to figure it out and make it work with what they want (ex. WLA-DX or whatever else). Changing those assembler syntactical details means you have to understand what the original syntax was intending to do. WLA-DX, for example, uses weird syntax (weird to me, anyway; I'm an old IIGS person :P), but it certainly has all the equivalents needed.
*** -- If you wanted to do that, for nostalgia reasons (or to get familiar with ORCA/M in general, you'd need an Apple IIGS emulator like KEGS, ActiveGS, etc. with a hard disk image and the ORCA/M floppy disks (there are 4, and it's commercial software -- yes I have them in
.img format, as I bought the software long ago -- and you need a system that has multiple floppy drives (the installer has major bugs with disk identification if you've only got 1 drive)), install GS/OS (if not pre-installed on the HDD image), mount the ORCA/M installer disk, run the installer, swap in/out disks during the installation process, get ORCA/M installed, run the shell, and start playing with the tools. It's tedious for people who aren't old IIGS users (if you are, it'll feel like home); no IIGS emulator I know of (for the PC) supports a native way to get files to/from the "host" (PC) into the "guest" (IIGS / GS/OS). You have to use tools like CiderPress to manipulate Apple II disk images to put files from the PC into those, etc. and then mount them in GS/OS as disks. IIGS emulation does not have good native integration for the "host" (PC), so you're forced to do this. The IIGS is literally one of the most neglected emulated systems out there, IMO; even the Apple II/II+/IIE/IIC have better overall support emulation-wise.
I think the problem is
The people who want a C compiler for SNES, want it because they don't know 65816 and they don't know the SNES. So hooking up a C compiler from something else that then needs you to potentially modify images formats, make modifications to the output in ASM to make it work on the SNES due to its hardware quirks.
vs
Those who do have said skills, don't see the point in having a C compiler for a SNES and hence can't be bothered to put a lot of effort into to make one.
This needs a bunch of SNES devs who are thinking "man I could save so much time on a bunch of the code I write by having a C compiler handle the boring stuff like menus and intro/outro etc and modifying my existing code with small changes is getting to be too much of a drag." Who then band together using their SNES expertise to make a solution for themselves, that others can then use.
The main issue being there are not many of the 2nd option and none of the 3rd needed case.
( I think Apple II emulation is just bad in all senses, the //c+ for example isn't even emulated. The machine was not very popular despite all the propaganda Apple used to spew about it. It's a pity as the //gs is the best computer Apple have ever made. I wonder if there is a /// emulator
- beyond a novelty look I did a crazy thing )
Oziphantom wrote:
want it because they don't know 65816 and they don't know the SNES. So hooking up a C compiler from something else that then needs you to potentially modify images formats, make modifications to the output in ASM to make it work on the SNES due to its hardware quirks.
That set of requirements is not really any different from where the NES toolchain is right now...
From experience watching people come here using C on the NES, people don't seem to be too badly chagrined about having to look at the generated asm. They just want to program C first and foremost.
It's true that it'd be nice to have something like NESst; I don't know of an analog off the top of my head.
People don't need to write their own SPC700 drivers; they just need something similar to Famitone, that can play a soundtrack and sound effects.
calima wrote:
For me, the banking is the greatest PITA.
When did you have trouble with banking?
It's rather annoying compared to a flat address space of the Genesis, and having two banks (program and data) doubles the chance of bugs, as well as the manual handling. It's an awkward system that can be worked around, but having to in the first place is ugly.
On cc65 specifically, it doesn't support banking where you have to switch everything. On the NES, you can usually keep a fixed bank and switch another bank. If the compiler and runtime had 816 support in the "long only" sense - all subroutine jumps and returns were forced to jsl and rtl - it would help nicely, leaving only the data bank to manual handling, but even that is a decent amount of work.
That's part of why SNES work tends to take several times longer vs Genesis work.
Something similar could be said about the segmented architecture of 8086, 80186, and 80286 compared to the flat memory model of i386, correct?
I don't think anybody would argue that a banking or overlapping memory space is better than a linear memory space for the programmer. Usually faster and easier for the machine in question thou
Although I have used overlays on linear memory space machines T_T
Although in practice I find the 65816's banking to be very generous and with a little planning mostly not an issue
Although one of my todo features it to make a CALL function, RETURN function construct that allows the the assembler to work out if I only ever call it from in bank or if it needs to be across bank, and set the JSR/L and RTS/L accordingly automatically for me. However this is below auto collapsing REP/SEPs on my list
Yes, 286 is supposedly similar, but I'm too young to have experienced that.
calima wrote:
Yes, 286 is supposedly similar, but I'm too young to have experienced that.
C compilers had the "near" and "far" type modifier keywords for exactly this. (...and they were annoying. DPMI was such a relief for me when it happened.)
Quote:
It's true that it'd be nice to have something like NESst [for the SNES]
It's on my TODO list to make one.
lidnariq wrote:
Oziphantom wrote:
want it because they don't know 65816 and they don't know the SNES. So hooking up a C compiler from something else that then needs you to potentially modify images formats, make modifications to the output in ASM to make it work on the SNES due to its hardware quirks.
That set of requirements is not really any different from where the NES toolchain is right now...
From experience watching people come here using C on the NES, people don't seem to be too badly chagrined about having to look at the generated asm. They just want to program C first and foremost.
It's true that it'd be nice to have something like NESst; I don't know of an analog off the top of my head.
People don't need to write their own SPC700 drivers; they just need something similar to Famitone, that can play a soundtrack and sound effects.
Took me a while but I think I've worked it out...
IMG format as in for the disks, like a D64, ADF but whatever the Apple //gs emulators use, not as in PNG, BMP, IFF
You're talking about another issue
dougeff wrote:
Quote:
It's true that it'd be nice to have something like NESst [for the SNES]
It's on my TODO list to make one.
I would make a plugin for Pro Motion NG, its already got a tile engine, drawing engine, animation system and basically everything in Deluxe Paint V cranked to 15. It also has the abilty to set and enforce colour limits and pallete formats. It already has the SNES limits built in. It does export GB and GBA natively but not SNES as it post dates the SNES era. It has a plugin load/save system that could be used to convert its internal data into what ever external format one needs. For me it would be the 'Pro' way to do it.