nesdev.org

I'm not sure if anyone of you needs this but I wanted to share it with all people who don't get it working on Windows. These are the binaries of the SNES SDK SVN revision 67 (the latest).
http://www.nakido.com/F5A782221F500F58A ... 7C034655F0
For those interested I also included some notes on how to compile the SVN code for oneself as it is not so easy to do this under Windows.

I can't get this to download. Would it be possible for you to upload it to a different site?

You can try http://jiggawatt.org/notmine/SNES_SDK_r67_Win32.zip instead.

Thanks! I really appreciate it!

I wouldn't mind if someone uploads the file to another hoster.

BTW, I noticed that the creator of the SDK started working again on the SDK for a short time some months ago. So this (my) SDK isn't the newest anymore, but nearly all his changes had to do with the replacement of Snes9X with BSNES as the test emulator.

Has anyone used the SDK to create something worth mentioning so far? Something looking like a game?

AndiNo wrote: Has anyone used the SDK to create something worth mentioning so far? Something looking like a game?

No, but that just means you can still be the first to make one

Sometimes I still think about it, but many other programming ideas have since crossed my mind and the difficulty of SNES programming is really high

Why is it high? I don't see any huge reason why it'd be that much harder than other platforms.

Of course it gets easier with the SDK as I can write C code. I also already had a small platforming engine running last time I tried it. But as I am used to programming on a PC where you have nearly unlimited power compared to the SNES it is quite difficult. It's interesting nonetheless
The most difficult part however is that for some things you HAVE to use assembly... which is another hurdle.
Maybe you're right and programming on the SNES is as difficult as on other platforms, however I'm used to using libraries which simplify things. For example OGRE3D for graphics, Lua for scripting etc

Yeah, you'd have to learn the hardware, but I'm not sure what parts you would have to code in assembly (the interrupts maybe?). regblah = 0 should translate to LDA #0 / STA regblah, just as useless if you aren't 100% sure what 'regblah' is, heheh.

You sure about the amount of CPU power you need, too? I mean, even with how slow the NES is (SNES is almost twice as fast) the main limitation to run into is the amount of PPU data to transfer during vblank. SNES has DMA, so that has ceased to be a problem.

Thanks for uploading that, I've been really curious to see it, but wasn't sure how to get started. If you think you might want to maintain a windows build of that, and need an ftp account for storage, I could give you one.

Memblers wrote:what parts you would have to code in assembly

First thing that comes to mind is the code for the SPC as there is no C compiler for it. And I'm absolutely no good at compiler programming. And a game without sound is no game to me

Memblers wrote:You sure about the amount of CPU power you need, too?

I experienced a slowdown from only having a handful of game objects on the screen which I'm not used to when using the PC. Of course I know it's the SNES after all, and my code was written with the PC in mind (performance wise). I could have optimized it easily I guess.

If you want to upload the SDK binaries somewhere to your website I would like it, as it won't get lost so easily. I wouldn't want to call myself a maintainer as I'm currently working on other things again, however I have included a detailed description on how to compile the SDK. From what I read not all steps written there are still needed because of said updates to the SDK. My revision is 67, the newest is 78.

BTW what has been on my mind for some time, are you the same as this person?
http://ocremix.org/artist/4344/memblers
Just looking at the homepage link on OC Remix, I think I have answered the question myself

I'm not sure what parts you would have to code in assembly

Any time-critical code (e.g. the NMI handler). Go ahead and look at the output from the compiler sometime A human being can write code that's 2-3 times faster in most cases.

Assembly is also the preferred way of writing code that's going to be copied to RAM; both because the C compiler AFAIK lacks any way of specifying that a function should go into RAM, but also because of the dramatic savings in code size that you can achieve.

Then there are the inexplicable compiler bugs that I ran into when I tried to compile a .c file consisting of 3000+ lines, split into about 50 functions. The compiler barfed on it, and my only guess is that it has some hard limit for how many local labels it can manage within the same source file, or something crazy like that.

mic_ wrote:Then there are the inexplicable compiler bugs that I ran into

How did you see these? Were there any compiler warnings or errors or did the program simply misbehave? I think that specific case could be circumvented easily by splitting up the files. Did you find any compiler problems which are real "show-stoppers"?

AndiNo wrote:

mic_ wrote:Then there are the inexplicable compiler bugs that I ran into

How did you see these? Were there any compiler warnings or errors or did the program simply misbehave? I think that specific case could be circumvented easily by splitting up the files. Did you find any compiler problems which are real "show-stoppers"?

Consider this beauty (this was generated by the C compiler in the case I mentioned):
*Why* is it trying to squeeze in a label in the middle of a section directive? That label shouldn't be anywhere near there. And it does the same thing a few lines further down.


Or this line:
The compiler gives me an error with the very meaningful description "ICE 2". So I rewrite it as:
And then it magically compiles.

I can see your point there, however this seems to be a free one man project. Even the big compilers like GCC have faults, only they get fixed pretty fast. And as this is the only C SNES compiler so far I think we'll have to live with it
Coming to think of it, maybe you have any idea how to fix this problem in the compiler's source?