It is currently Tue Nov 20, 2018 5:14 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 7 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: 163
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 1412 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: 628
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: 20789
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: 4105
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: 7580
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: 163
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: 423
You could write an interpreter and have it process bytecode in 150 cycle segments.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 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