It is currently Tue Dec 18, 2018 4:49 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: Interleaving on the NES
PostPosted: Tue Nov 06, 2018 2:36 pm 
Offline
User avatar

Joined: Fri Jan 24, 2014 9:05 am
Posts: 164
Location: Hungary
I have a long-going project to use the DMC IRQ to stream PCM data at 8.2kHz while still having enough time to run a game (with the tasks spread out across two frames for 30FPS). However, this is done by sitting around in the IRQ handler so that I can land another $4011 write right in between two IRQs, wasting a lot of time throughout the frame.
I have attached a terrible timeline made in paint to illustrate what's happening in my system.
Attachment:
IRQ.png
IRQ.png [ 7.22 KiB | Viewed 2514 times ]

What I wonder is what a good way is to cram in processing of the game logic into that waiting time, essentially doing something like interleaving or "multithreading". What game tasks are generally less likely to be full of branches, and therefore easier to break up into 100-150 cycle segments to be executed in?


Top
 Profile  
 
PostPosted: Tue Nov 06, 2018 9:52 pm 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 629
Stupid question
Why don't you make the IRQs fire twice as fast so you don't have to sit around?

If for some reason the DMC can't do it, switch to a mapper that has a timer/counter.


Top
 Profile  
 
PostPosted: Tue Nov 06, 2018 10:03 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20898
Location: NE Indiana, USA (NTSC)
Oziphantom wrote:
Why don't you make the IRQs fire twice as fast so you don't have to sit around?

DMC maximum IRQ rate is 4.2 kHz

Oziphantom wrote:
If for some reason the DMC can't do it, switch to a mapper that has a timer/counter.

That would cost more per cartridge than using a simple discrete mapper, a cost that would have to be passed on to crowdfunding backers and post-release buyers. Or it would disqualify a developer from participation in NESdev Compo.


Top
 Profile  
 
PostPosted: Tue Nov 06, 2018 10:03 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4110
Possible tasks that could be made to run in constant time:
* Filling buffers for scrolling
* Filling buffers for sprites

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


Top
 Profile  
 
PostPosted: Wed Nov 07, 2018 12:47 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7604
Location: Chexbres, VD, Switzerland
tepples wrote:
That would cost more per cartridge than using a simple discrete mapper, a cost that would have to be passed on to crowdfunding backers and post-release buyers. Or it would disqualify a developer from participation in NESdev Compo.

Not to mention it would take all the interesting challenge away.


Top
 Profile  
 
PostPosted: Wed Nov 07, 2018 3:35 am 
Offline
User avatar

Joined: Fri Jan 24, 2014 9:05 am
Posts: 164
Location: Hungary
Dwedit wrote:
Possible tasks that could be made to run in constant time:
* Filling buffers for scrolling
* Filling buffers for sprites


Thanks for the ideas. Thankfully I wouldn't even have scrolling updates because the rooms would be non-scrolling screens with fadeouts for transitioning, where the game draws the next room during forced blanking, so that removes one layer of complexity. Actually now that I'm thinking about it, as long as there is a reasonable wiggle room and not too many branches so that no matter how many long branches are taken the intervowen task never eats more than the waiting time it should work just fine. Sometimes there will be unused CPU time, but it's still better to spend some of the waiting on something useful than to spend none. About 69 DMC IRQs happen in one frame, so on an optimistic average I can regain 7 000 CPU cycles if I could have every single IRQ wait spent on something useful. Actually that could be enough to have a normal 60 frames per second game without too much lag.

Designing code in this way, chopping it up into short segments, feels like working around the manual display kernel one would do for an Atari game.


Top
 Profile  
 
PostPosted: Wed Nov 07, 2018 3:43 am 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 448
You could write an interpreter and have it process bytecode in 150 cycle segments.


Top
 Profile  
 
PostPosted: Thu Nov 22, 2018 3:45 am 
Offline
User avatar

Joined: Fri Jan 24, 2014 9:05 am
Posts: 164
Location: Hungary
As it turns out, my original guess of being able to save 100-150 cycles was an extremely generous assumption. Currently, in the middle of redesigning the PCM code to accomodate this interpreter, it seems that the interpreter needs to be aware of how many cycles it has to spend before it has to return control to the PCM stream and then finally to the main thread. This count can be a variety of values, as every time there is a branch in the code, a different outcome can occur, and keeping count by itself also eats up more of those precious cycles, but it might be worth it in the end because the interpreter will be able to handle non-fixed time tasks as well.
I will have to set up a task flag system where the main thread and the interpreter inside the IRQ can assign a task to themselves so that there won't be any conflicts later... this sounds like there will be even less cycles to spend on actual processing. I'm starting to think that this is an ambitious idea, but the 6502 is just not powerful enough to do all these things effectively.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] 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