NES Multithreading Demo

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Post Reply
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

NES Multithreading Demo

Post by blargg » Tue Mar 28, 2006 10:48 pm

I wrote a simple demo of how to support multiple threads on the NES, both cooperative and pre-emptive. The latter are implemented using the APU's 60 Hz interrupt, and another version using the DMC interrupt running at 4000 times per second for finer switching granularity. Source is generously commented and assembles with NESASM. It has been tested on my NES.

nes_threads.zip

The cooperative version could be implemented on modern architectures without much difficulty. Using it an emulator could simplify things a lot.

User avatar
oRBIT2002
Posts: 634
Joined: Sun Mar 19, 2006 3:06 am
Location: Gothenburg/Sweden

Post by oRBIT2002 » Wed Mar 29, 2006 1:59 am

Multithreading on a NES? This is cool stuff. What's next? A multi-threaded operating system? :)
(Hm well, that'd be cool for developing.. :))

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Wed Mar 29, 2006 2:41 am

The people over on the 6502.org forum discuss operating system implementation on the 65xxx series. Some are pretty hard-core about it. I think Solomon's Key might use some kind of multithreading, or at least a prioritization scheme for giving time to enemy objects. On some rooms the enemies go slower when there are lots of them, but the game speed never changes.

One thing to remember is that the main benefit of multithreading is the ability to write some kinds of code in a clearer way. It's all about which execution structure is most straightforward. The message-based scheme has objects responding to inputs via subroutine calls, while a multithreaded scheme gives each object its own thread from which it actively checks for things and responds to them.

It generally doesn't work very well to give every on-screen object its own thread, but it can help to have two or three threads in a program, each performing specific tasks. An interesting example would be a thread doing some lengthy calculation over the span of multiple frames during whatever free time there was. Using a pre-emptive thread would allow it to be written without constant checks for "is it time to go to sleep yet".

Post Reply