It is currently Sat Oct 20, 2018 5:36 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sun Dec 03, 2017 11:01 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
My current game uses coroutines, which are kind of like threads that pre-empt themselves, but how hard would it be to fully implement threads on an NES? I was wondering in the context of this conversation whether such a technique could be used to implement 300hz animation updates and then adjust how often the animation threads are updated on PAL or NTSC.

I don't personally feel motivated to go as far as implementing threading myself, but as I have spotted "threads" mentioned in some games' source code and by some homebrewers, it is making me wonder what the possibilities are. Note I'm well aware one often refers to the "main thread" and the "nmi thread," and I fully understand why that terminology was adopted, since these do behave like threads and you have to deal with concurrency issues, but I'm specifically asking about implementing a general pre-emptive threading scheme.


Top
 Profile  
 
PostPosted: Sun Dec 03, 2017 11:10 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7675
Location: Seattle
Context switches are expensive; when one uses coroutines there's much less state to save and restore. I'd be worried about the overhead overwhelming the benefits...


Top
 Profile  
 
PostPosted: Sun Dec 03, 2017 11:14 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
lidnariq wrote:
Context switches are expensive; when one uses coroutines there's much less state to save and restore. I'd be worried about the overhead overwhelming the benefits...

Good point, one would have to have a full copy of all cpu registers at the time a thread is pre-empted, whereas with coroutines all I need is the state associated with the coroutine (in my game's case, just the current entity's state)...(and the PC)

Given that, I'm guessing any time I've seen the word "thread" used in an NES game's source code, it is probably really a coroutine or similar idea...


Top
 Profile  
 
PostPosted: Sun Dec 03, 2017 12:41 pm 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 387
I don't see why you need threads for this or what benefit they would have.


Top
 Profile  
 
PostPosted: Sun Dec 03, 2017 1:20 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
pubby wrote:
I don't see why you need threads for this or what benefit they would have.

I don't; but I am accustomed to discovering that many folks here do things in ways I would have never thought of so I thought I'd ask and see if it's something anybody has done or is doing. Especially since I've seen it in source code and mentioned more than once.

If anything; it'd be a fun demo to write...


Top
 Profile  
 
PostPosted: Sun Dec 03, 2017 3:36 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4093
Interrupts (NMI and other IRQs) are already multiple threads that can preempt a main thread.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Mon Dec 04, 2017 2:51 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 617
http://codebase64.org/doku.php?id=base: ... n_the_6502

However what you are probably thinking of is best left for a C128 or a 65816 based system.


Top
 Profile  
 
PostPosted: Mon Dec 04, 2017 3:00 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7548
Location: Chexbres, VD, Switzerland
At the risk of angering you for not answering the question, there is absolutely zero reason to do such a thing in the first place. The point of pre-emptive multitasking is that if a program crashes, the whole system does not crash. If I'm not mistaking this was introduced rather late in the history of computers - perhaps with Windows 95. So that if an application crashed it was possible to resume computer usage without hard rebooting.

In the case of an embedded video game console where no 3rd party software you don't control is used, there is zero reason to do such a thing. Basically you're trying to solve a problem that doesn't even exist in your case. If one of your thread crashes, you should fix it - you should not hope it'll go unnoticed and hide it with pre-emptive thread switching.

Now if you're asking if this is possible technically, then the answer is probably yes - but does it make any sense in the case of a NES platform, the answer is no.


Top
 Profile  
 
PostPosted: Mon Dec 04, 2017 3:09 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 617
Sinclair QDos of 84 had it, but that machine had a lot of issues. It's main announcement to the world was the A1000 of 85. Windows kind of had it since 2.1 but yeah not really. 95 was when it got it for real. MacOS got it in 2001 when they ditched the old OS and used NextStep. There were some DOS hacks that added it as well I think, but none really took off.


Top
 Profile  
 
PostPosted: Mon Dec 04, 2017 3:36 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6897
Location: Canada
lidnariq wrote:
Context switches are expensive; when one uses coroutines there's much less state to save and restore. I'd be worried about the overhead overwhelming the benefits...

Hmm, what would a context switch look like here? Something like:

IRQ, save registers, some IRQ upkeep, move stack pointer, restore registers, return from IRQ.

I wonder if bankable WRAM could help here too, you could let the different threads independently use memory that way.


Though, aside from running a multitasking operating system with independent programs that come and go, I don't really understand the use for threads on a 6502. For multi-core systems threads are a very important way to parallelize. On a single core system, they can't do that.

In a game... the first situation that comes to mind is running AI for a chess game, where you want to let that run independently and keep doing user interface updates for the player in the meanwhile. For that, though, you only need one more thread... a single IRQ is already good enough to do that (if not just the NMI by itself).

Threads were also common for things like background loading, or background decompression, but the NES doesn't really have enough RAM for decompression to ever take that long, and its only loading device is the FDS... but again even for this kind of thing a single IRQ is already enough for this case too?

So I'd be quite curious to know of a good use case for it, as I can't think of anything, myself.


Coroutines on the other hand do make a lot of interesting code structures possible, especially for AI, but we're not talking about interrupts anymore with that. Coroutines aren't to be confused with "threads", at least in my understanding of them; it's a very different paradigm.


Top
 Profile  
 
PostPosted: Mon Dec 04, 2017 6:54 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4093
Bregalad wrote:
At the risk of angering you for not answering the question, there is absolutely zero reason to do such a thing in the first place. The point of pre-emptive multitasking is that if a program crashes, the whole system does not crash.


Preemptive multithreading also lets a single task do something that takes a long time, while doing something else at the same time. So if you have something like a long pathfinding sequence, you can interrupt it for something else.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Mon Dec 04, 2017 7:02 am 
Offline

Joined: Sun Mar 19, 2006 9:44 pm
Posts: 959
Location: Japan
If I recall, Tepples, or some other person here, made a "Sprite" demo where each sprite was its own thread. So a demo has been made.

_________________
http://www.chrismcovell.com


Top
 Profile  
 
PostPosted: Mon Dec 04, 2017 7:16 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7548
Location: Chexbres, VD, Switzerland
Dwedit wrote:
Preemptive multithreading also lets a single task do something that takes a long time, while doing something else at the same time. So if you have something like a long pathfinding sequence, you can interrupt it for something else.

True, I see some applications for that such as chess game AI or whatever, but then it could just be a specialized implementation for one specific CPU-intensive task, rather than general purpose pre-emptive multithreading.


Top
 Profile  
 
PostPosted: Mon Dec 04, 2017 7:28 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
...so what really prompted my thread was that the word "Thread" is present in the old Neotoxin source code. I also have heard at least one fellow homebrewer refer to things as "threads" in his code. I was just curious what these things actually were. Probably not "real" threads.


Top
 Profile  
 
PostPosted: Mon Dec 04, 2017 9:11 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20679
Location: NE Indiana, USA (NTSC)
rainwarrior wrote:
Threads were also common for things like background loading, or background decompression, but the NES doesn't really have enough RAM for decompression to ever take that long, and its only loading device is the FDS

NOR flash prices began to rise half a year ago, as I mentioned earlier. If this trend continues, there'll be more pressure to store the majority of the program on a serial flash (SPI, eMMC, microSD, etc.) and load the rest to a bankable 128Kx8 PRG RAM during the copyright screen, between levels, or even in the background if you can structure the level stream that way.

rainwarrior wrote:
... but again even for this kind of thing a single IRQ is already enough for this case too?

True. On 8- and 16-bit consoles, I don't see a use for more than three preemptive contexts in a game: video memory updates and music, game logic, and graphics decompression, software rendering, or heavyweight AI.

ccovell wrote:
If I recall, Tepples, or some other person here, made a "Sprite" demo where each sprite was its own thread.

It wasn't me. Neither the old version nor the 2011 version of the Sprite Cans demo uses anything thread-like. In fact, it probably uses the simplest possible NMI handler.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group