nesdev.org

So I'm finally looking to work on a NES game, but I'd like to prototype it in a higher level language first.

I really see this as 2 parts -
1) writing larger side 6502 programs
2) know the PPU inside and out

My 6502 assembly language skills aren't that great, so I was thinking...
Wouldn't it be neat if I could write my game in C (or Python even) code and just talk to an emulated PPU through a function (or port), and get a function callback when an IRQ occurs.
This would allow me to get familiar with the PPU before I have to deal with 8 bit assembly.

Are there any emulators that support this kind of thing?

You mean write a game in C, compile it, run it through a debugger and see exactly what instructions it is doing in ASM? (I really don't know anything about the NES, but I bet any debugging emulator will do if I'm right.) I don't know If you plan on making the entire game in C or Python and then doing this, but It would seem like it would take more effort to essentially write the game twice then to just have a slower first time.

Shiru does have the "how to write NES games in C" guide: http://shiru.untergrund.net/articles/pr ... s_in_c.htm

Yes, it's somewhat restricted, but is definitely a good way to get something made with minimal barrier to entry.

If you want something a little less constrained but less helpful, but still allowing you to use C in general, I've found thefox's KNES to be a good replacement/augment for CC65's neslib.

You could also look at the Mojon Twins' games, which are written in a C/asm blend and source is included.

I think he's talking about writing the prototype in C (or another high-level language) while still having access to an emulated PPU, so he can get the hang of how to talk to the PPU without having to learn a whole new language. He orobably does want to learn 6502 eventually, and by then, writing NES software might be easier.

I'm not sure it will work as you expect, but FCEUX can run Lua scripts in parallel with the game. Maybe you can start with a blank ROM (except for graphics) and write the game itself using Lua?

All things considered, I don't think the PPU needs such a big learning curve. Once you understand how the graphics are formed (something you can do with little to no programming experience by looking at the PPU debuggers in FCEUX or Nintendulator) you can get some graphics up very quickly. Learning how the CPU works is harder, if you don't have any experience with that, but the hardest thing of all is the logic that controls the game: the object management, interactions, level processing, that kind of stuff, no matter what language you use.

How can you "talk" to the PPU without actually making a game, which, if it is like the SNES, will go to the CPU and then the PPU? Are you wondering if you can essentially skip the processor altogether and just feed the PPU information directly?

I think once I or someone else should really do a deep reseach about existing high level alternatives for the NES (or the 6502 in general). Someone already did it, but he does not mention any numbers when it comes to efficiency of those solutions.

What exists so far :
1) Home-made tools done by random enthusiasts
1.1) ATALAN
1.2) uc65

Pros : High level languages designed specially to produce efficient 6502 assembly code
Con : Have to learn a specific programing language. Both are in development phase, not "stable" yet. Atalan doesn't seem under active devlopment anymore. Debuging capabilities and support could be seriously limited.

2) Virtual Machine solutions
2.1) FORTH
2.2) AcheronVM (github repository)
2.3) Plasma

Pros : Better code density than native 6502 code -> good for saving ROM space
Cons : Have to learn a specific programming language (except for FORTH which is widely recognized, but still not so well known). Slow, many parts will have to be developped in assembly, the learning cuve to learn VM and assembly could be high. Debuging capabilities and support could be seriously limited.

3) C compilers
3.1) CC65 Pros : open source, has been in development until recently. Con : Maintained by one author who did not allow other people to contribute (non-free, despite being costless and open-source), produces terrible code unless you are tuning both your code and the compile options at a point it becomes ridiculous and no C anymre, does not accept all C standard, not in development anymore.
3.11) Any random CC65 fork done by people who wanted it to make it more efficient. (Pros : Generates better code, Cons : Not officially maintained, not under active development)
3.2) Quezacoatl (Pros : Is free software, does not use this ridiculous "software stack" CC65 uses. Cons : Does not accept all C standard, is not under active development since long)
3.3) CoSy A compiler that is supposed to be re-targettable and very efficient. Con : Proprietary software, probably very expensive, but if many people raises funds pehaps it'd be possible to finally have a good 6502 C compiler, without spending years of non-paid development time for existing free software solutions that does not support the 6502 as a backend ?
3.4) GCC-6502 unofficial port. Is not yet quite stable, but who knowns. (6502.org thread where I learnt about the project)

As year 2020, two new C compilers targetting the 6502 has been released almost simultaneously :
3.5) VBCC Optimizing C-compiler
3.6) Kick-C


4) UCSD p-system which is a GNU clone of a UCSD Pascal system which was very popular in the 80s, it allows to compile Pascal code into a machine-independant byte-code and then run this on any low-power CPU, including the 6502.

5) Other well known language compilers
Does any ADA, Fortran or other compilable langauge compilers exist for the 6502 ? Are those language more suited to 6502 than C, which is often said to be in terrible mismatch with the 6502 ?

Espozo wrote:It would seem like it would take more effort to essentially write the game twice then to just have a slower first time.

It can still be faster to first prototype the physics and AI in a higher-level language that lets the programmer make large-scale changes more rapidly. Then the basic game design can be considered set in stone to an extent, and one can at least figure out how memory is likely to be laid out. This is how Mr. Podunkian made STREEMERZ: first make it in some Game Maker-type environment and then outsource the NES port to thefox.

Consider the constructed language Esperanto. Studies have shown that learning Esperanto then some other language like French is faster than just learning French because it prepares the mind to understand how languages differ, and Esperanto has fewer* fiddly irregularities in spelling and morphology than French.

Espozo wrote:How can you "talk" to the PPU without actually making a game

An emulator contains an emulated CPU together with an emulated PPU that exposes port read and port write commands. This setup would include only an emulated PPU, and a game engine in native code for the PC would execute these port read and port write commands. Think of it as like pulling the PPU from the NES motherboard and putting it on a circuit board that's connected to a PC.

* I'm not saying Esperanto is perfect; I'm aware of JBR's "Ranto". The point is that Esperanto is still not quite as hard as a major European language.

I think tepples understands exactly what I want to do. Sorry if I wasn't able to clearly convey what I'd like to do.

I understand the game will have to be re-written twice. It's just to make the learning process easier.
I've written games before in high level languages Java/Python/ObjC from scratch (no frameworks), so I understand game loops, objects, collision detection, cameras, etc...

Think of it as like pulling the PPU from the NES motherboard and putting it on a circuit board that's connected to a PC.

I actually thought about doing this, but it could be tricky getting the timing to work.

drk421 wrote:I actually thought about doing this, but it could be tricky getting the timing to work.

It has been done. Unfortunately I can't find the original information.

Bregalad wrote:I think once I or someone else should really do a deep reseach about existing high level alternatives for the NES..

Also, (not a language, but) my extension to ca65: https://www.assembla.com/spaces/ca65hl/wiki
I also like (even though I don't understand Lisp) (see links at bottom of the page) http://ahefner.livejournal.com/20528.html

But if you just want to poke the PPU in an emulator, try thefox's NintendulatorDX. You can code everything in Lua, rather than assembly. Then when you are ready, start coding in assembly. viewtopic.php?t=6773

I'm developing my game by writing it in C++ with a framework that fits the function/shape of the NES including its PPU operation. When parts of the code stop changing much, I port them to NES assembly.

I don't know what I'd suggest for you, though. I'm not willing to share my framework at this time. Writing an ersatz PPU layer kinda requires knowing how to use the PPU already, and to learn that you probably need to learn 6502 assembly. Edit: the framework source is now available here.

Shiru's NES screen tool might be a good way to learn how NES background graphics work without having to learn the programming details: http://shiru.untergrund.net/software.shtml

Part of the issue I see with this is that the PPU is so based on how much you can cram in before rendering starts. How do you make sure whatever C++ code you're writing doesn't massively blow through this limit? Counting int x = 3 as five cycles? What about loops or whatever? The framework works for rainwarrior because he's familiar with nesdev and would know how to limit that aspect.

Even if you hard limited yourself like "I can't write more than 80 bytes to the PPU in a frame," it's still massively difficult to write code that would set up and write these bytes in 6502.

You run into a similar problem just creating enemies and such for the game. It's very easy to create game logic in C that would slow your game down to a crawl. And again, I'd say those who prototype know what to avoid because they have already worked through the part you're trying to skip. (Or at least the part you don't want to do first.)

I think using Shiru's C library is about the best you can do. If you write unfeasible code, you'll at least immediately be able to tell. It would kind of suck to design your level format, then find you have to completely change it because it's not fast enough to decode once you start the NES version. Or find you're doing too many PPU updates, and have to change your game's design. I feel these are traps you'd fall into if what you were seeking was available.

Edit: Though actually most of that only matters if you plan to update things in the PPU during gameplay. If you don't (like for a non scrolling game with no background HUD), the PPU is actually super easy to deal with.