charly400 wrote:
totally agree, that way it is possible to make programs in c, the ORCA / C compiler for apple 2 allows to make programs that fit apple memory system and it/s peripherals, the way to compile for the snes memory system is not equal but similar, plus other devices
I don't know about the possibility of using ORCA/C to compile games for the SNES. ORCA/C is heavily reliant upon many aspects of the Apple IIGS and/or GS/OS or the built-in ROM (for bare-bones things); GS/OS actually provides you an entire OS and API for such things, including memory management; there is no
malloc on the SNES! For ANY this to work on the SNES -- and I think someone else already covered this -- you would have to write your own crt library that did equivalent things on the SNES to what was done on the IIGS. Any common libc functions you're used to? Throw them out -- they probably won't be very helpful on the SNES, and you'd have to dedicate a portion of CHR to a font. Possible? Yes. Useful? Maybe? Sort of? Probably not given that today we have tolerable emulators with debuggers. But that's just my view.
The IIGS and the SNES are MASSIVELY different in every single way except the CPU (
I'm an old Apple IIGS programmer, and
I do/did SNES stuff as well, so I'm not out of my element talking about this -- in fact, the reason I got into doing SNES programming and doing my documentation was
because I found out the SNES had a 65816 in it). For one, the SNES is a tile-based system, not pixel-based like the IIGS. Also unlike the IIGS there is no "text mode" or direct/native way to get text onto the screen (IIGS, much like the II/II+/IIC/IIE, has a stock ROM that provides a lot of this). These are one of many reasons why you didn't see games being ported from the IIGS to the SNES or vice-versa -- the systems are just way too different, especially graphically. And FYI: graphically, hands down the SNES is the more powerful of the two -- IIGS graphics are clever/neat but very limited (single background, limited palette, limited memory and access model, and things like having a 16-colour-per-horizontal-line limitation that cannot be overcome in any fashion (the "3200 colour" mode people talk about on the IIGS takes up something like 90% CPU time and involves very quickly swapping palette contents while the screen is drawn, i.e. during HBlank)), because they were designed by Woz with very real limitations of system resources (memory and budget); SNES, PC, and Amiga are all graphically superior in every way. In my youth I wanted to port so many SNES games to the IIGS and learned sadly most could not be done -- the other way around was more likely.
That said: people DID use ORCA/M (the 65816 assembler on the IIGS) to write some SNES games. There are better people than me to talk about this subject -- people who did commercial games -- but many of the folks at Tiburon Entertainment were Apple IIGS assembly programmers (guys like Ian Schmidt, Rich Wifall, James Brookes, Jason Andersen, and Steven Chiang). But honestly, most companies ended up writing their own sets of tools (including assemblers, and sometimes C compilers) -- guys like Toshi Morita did exactly this at several companies (LucasArts, Sega). Rebecca/Becky Heineman (then Bill Heineman) may also have done this, but you'd have to ask her. BTW, I'm dropping names because these are people I knew in my IIGS/SNES heyday/youth, many of whom I met, so I'm familiar with their skill.
There are some commercial SNES games that are strongly suspected to have used C (several are RPGs or involve complex text engines). I can't remember names off the top of my head right now, but disassembly and analysis turned up some signs that parts of some games may have involved code generated by a C compiler, mixed with very heavy amounts of native assembly for the SNES specifically. There were also games that had what were suspected to have a kind of "home-grown intermediary language" used to create portions of 65816 code -- disassembly turned up stuff that looked very "C-like" except not quite. So like I said, many companies just wrote their own tools.
People also often forget: unlike homebrew, these were companies with many paid employees, not just a single person trying to wrangle together something. You had pairs of people doing graphics, another guy working exclusively on a sound engine (and/or working with a musician -- sometimes the same person), others working on core game mechanics code, another working on menu/UI, blah blah. With homebrew, it's often one or two people. This is why incredible games like
Axiom Verge take nearly 6 YEARS -- done entirely by one guy on weekends and weeknights, while working a full-time job (
reference). With both the NES and the SNES, almost everyone involved with writing code had assembly experience (or had to learn it).
So we're back to what I said in my previous post: you're talking a lot about something you have little-to-no familiarity with. Start by learning assembly language. You're going to be fighting an uphill battle using C for the SNES, and you LITERALLY will have no way to debug things in real-time with C code (because all debuggers for SNES emulators are assembly-based). You need to get familiar with bare-metal and console development. Throw away everything you've learned that "holds your hand" (libc functions, kernel functions, etc.) and ask yourself: 'if all I had was a CPU, no libraries, nothing but an assembler and documentation, and told "here's the instruction set, here's RESET and NMI vector locations", how would I start?' Because that's exactly what you'll have to start with. You want to code on a video game system (essentially embedded) released in 1990? You're going to have to think like in 1990.