Interleaving on the NES

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
User avatar
za909
Posts: 249
Joined: Fri Jan 24, 2014 9:05 am
Location: Mijn hart woont al in Nederland

Interleaving on the NES

Post by za909 »

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.
IRQ.png
IRQ.png (7.22 KiB) Viewed 6308 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?
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Interleaving on the NES

Post by Oziphantom »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Interleaving on the NES

Post by tepples »

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.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Interleaving on the NES

Post by Dwedit »

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!
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Interleaving on the NES

Post by Bregalad »

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.
User avatar
za909
Posts: 249
Joined: Fri Jan 24, 2014 9:05 am
Location: Mijn hart woont al in Nederland

Re: Interleaving on the NES

Post by za909 »

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.
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: Interleaving on the NES

Post by pubby »

You could write an interpreter and have it process bytecode in 150 cycle segments.
User avatar
za909
Posts: 249
Joined: Fri Jan 24, 2014 9:05 am
Location: Mijn hart woont al in Nederland

Re: Interleaving on the NES

Post by za909 »

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.
Post Reply