Native NES Tracker

tokumaru · Post by **tokumaru** » Mon Nov 16, 2009 7:14 pm

tepples wrote:Unless you're tracking at 150 BPM (tempo $96) with 32nd note resolution (speed 3).

I know that reducing the frame rate isn't the best solution.

What's the best way to do more than one split (one at the top of the region, one at the bottom) on a mapper without a scanline or CPU cycle counter and without wasting over one-third of the CPU time?

I can't think of anything. You either use IRQs or waste time (waiting for a sprite 0 hit). But depending on how he arranges the interface the scrolling window might be at the top or at the bottom, and then only one split will be necessary.

Considering the type of program he's making, wasting a chunk of time that big might not be such a problem, as it shouldn't be as CPU-intensive as games. If it's in edit mode, it will only do anything upon user input, and even with some of the time missing the response should still feel real-time enough. In playing mode, I doubt a music playback engine, as complex as it may be, will need more than 50% of the CPU time.

Given that someone's already having trouble fitting things into 2300 cycles, I'm not sure how helpful that would be.

By using hardware scrolling he gains a lot of cycles. Also, I said this could be done for data that isn't accessed often, as in not every VBlank. For a game I can think of a few kinds of data I would store there (game status information that is only accessed between levels, checkpoint information, maybe even level maps, depending on their format), but for a tracker I'm not sure, maybe he can think of something.

Tepples, are you against the idea of using hardware scrolling? 'Cause it seems you showed up just to bash my ideas. I suggested what I did because it's simply impossible to update 400+ bytes of NT data in a single frame (unless a considerable amount of the screen was cut for extra blanking time, but that's not so trivial either).

Post by **tepples** » Mon Nov 16, 2009 7:40 pm

tokumaru wrote:You either use IRQs or waste time (waiting for a sprite 0 hit).

Waiting for a sprite 0 hit isn't any more of a waste of time than waiting for vertical blank because you don't have to maintain a constant cycle count up to that point, just keep that part of the frame under a maximum cycle count. It's finding something to do while waiting exactly 96*341/3 = 10,912 cycles that's a problem.

But depending on how he arranges the interface the scrolling window might be at the top or at the bottom, and then only one split will be necessary.

Different TVs have different overscan amounts, especially at the top and bottom.

Tepples, are you against the idea of using hardware scrolling?

No, I'm just confused about the best way to implement it. I want hardware scroll to work. It's just that I investigated this a few years ago when I tried to implement an e-book reader with a proportional font on the NES. I ended up needing 1. a more accurate emulator than was available on the DVD player in question, and 2. two split points to change from pattern table 0 to 1 to 0 or from pattern table 1 to 0 to 1 when the player scrolled the text. Around that time, I thought of a long-shot method that involved waiting for sprite 0 at the top split and then abusing DMC IRQ as a crude timer to do something useful while waiting for the bottom split. But then, I had no writable cart to test it on. Now I do, and I want to prove myself.

'Cause it seems you showed up just to bash my ideas.

Perhaps I'm just the Adi Shamir to your Ron Rivest, blowing holes in your arguments to encourage all of us to make them stronger. Rivest would propose a cipher, and Shamir would find the hole in it.

tokumaru · Post by **tokumaru** » Mon Nov 16, 2009 8:05 pm

tepples wrote:Waiting for a sprite 0 hit isn't any more of a waste of time than waiting for vertical blank because you don't have to maintain a constant cycle count up to that point, just keep that part of the frame under a maximum cycle count. It's finding something to do while waiting exactly 96*341/3 = 10,912 cycles that's a problem.

Yeah, I got that, I just got confused when I mentioned sprite 0, I wanted to say "waiting 96 scanlines", sorry. The hit is used to detect the first split point.

Different TVs have different overscan amounts, especially at the top and bottom.

Sure, but a tracker sure will use a lot of the screen area. Something will have to be close (in a way that he considers safe) to the edges of the screen, even if it's not the scrolling window. And if something has to be there, why not the scrolling window, to make the split operation simpler?

No, I'm just confused about the best way to implement it.

Yeah, so am I. I'm not too fond of the idea of wasting a lot of cycles either.

Perhaps I'm just the Adi Shamir to your Ron Rivest

Everyone's Ron Rivest I guess, you're always looking for problems and alternatives! =) It's true, you are the very definition of the devil's advocate! XD But I guess you are right, in the end that should help us reach a better solution.

neilbaldwin · Post by **neilbaldwin** » Tue Nov 17, 2009 12:58 am

@Memblers : currently I'm only thinking about scrolling the window as you edit as opposed to the scrolling following the play head.

@tokumaru & tepples : plenty of food for thought gentlemen, great stuff.

@tokumaru : I absolutely love your animated diagram. Makes perfect sense now

I'm not far off getting to the stage where I'm able to edit the data at which point I'll be able to have a play around with the scrolling method a bit more.

neilbaldwin · Post by **neilbaldwin** » Wed Nov 25, 2009 2:28 pm

Update time again

OK, so now I'm making progress with the editor side and have pretty much got the Song Editor window working and partly got the Pattern Editor working (you can scroll around it at least).

I wanted to try a new thing and have video screen-grabbed me navigating around in Nestopia.

http://dutycyclegenerator.com/#NTRQ-Video-1

neilbaldwin · Post by **neilbaldwin** » Sun Nov 29, 2009 10:57 am

Another video update;

http://dutycyclegenerator.com/#NTRQ-Video-2

neilbaldwin · Post by **neilbaldwin** » Mon Dec 07, 2009 11:13 am

Another video update;

http://dutycyclegenerator.com/#NTRQ-Video-3

The editor is pretty advanced now

dXtr · Post by **dXtr** » Wed Dec 09, 2009 1:15 pm

looks great, really looking forward to hearing it scream :)

tokumaru · Post by **tokumaru** » Wed Dec 09, 2009 4:45 pm

It does look good. I don't know much about music or trackers, so I'm not really sure what everything is, but it certainly looks promising.

One thing worries me though: there are absolutely no margins in that interface. This will probably limit the usability of this tool on real hardware, because TVs tend to cut the edges of the frame. I don't know if this has changed with LCD and plasma TVs, but not being able to use it on hardware kinda kills the point in having a native tool.

neilbaldwin · Post by **neilbaldwin** » Wed Dec 09, 2009 5:13 pm

tokumaru wrote:It does look good. I don't know much about music or trackers, so I'm not really sure what everything is, but it certainly looks promising.

One thing worries me though: there are absolutely no margins in that interface. This will probably limit the usability of this tool on real hardware, because TVs tend to cut the edges of the frame. I don't know if this has changed with LCD and plasma TVs, but not being able to use it on hardware kinda kills the point in having a native tool.

I have a top and bottom margin of 8 pixels (losing the top and bottom line of the screen). I turned on the "NTSC stuff" in Nestopia and it cropped a pixel or two off the right-hand side but you could still see the numbers. Ignore the very top numbers - they are just debug sprites.

Weirdly, on my TV (NTSC NES->AV amp->60Hz plasma), it's the top two lines (of characters) that are cut off and not the top and bottom.

Is there a definitive guide for this stuff?

tokumaru · Post by **tokumaru** » Wed Dec 09, 2009 5:25 pm

neilbaldwin wrote:Ignore the very top numbers - they are just debug sprites.

Ah I see. I've seen some TVs hiding a good deal of the right side of the picture, but I believe the tracker should be usable on most TVs then.

Weirdly, on my TV (NTSC NES->AV amp->60Hz plasma), it's the top two lines (of characters) that are cut off and not the top and bottom.

I had 2 CRTs hat did the same thing.

Is there a definitive guide for this stuff?

No, each TV behaves differently, it seems. IIRC, CRT TVs could even be calibrated (by a technician, not a regular user) so that the image was more centered. I don't know if plasma/LCD has something like that.

Post by **tepples** » Wed Dec 09, 2009 5:57 pm

My guideline: If you can see it in PocketNES's scaled mode, you can see it on a TV.

neilbaldwin · Post by **neilbaldwin** » Thu Dec 10, 2009 1:05 am

tepples wrote:My guideline: If you can see it in PocketNES's scaled mode, you can see it on a TV.

Nice

I just tried this but using VisualBoyAdvance to run the PocketNES ROM. Vertically it's fine as you're only missing the top line of text but horizontally I'm losing the left-most and right-most column.

The top third of the interface (Song Info, Song Editor) is OK as I can move both of these panels in towards the centre.

The biggest problem is the Instrument/Table Editor. I need to rethink that bit as it uses the whole 32 char width of the screen.

The latest version of the editor runs really quite cool in PocketNES.

However, some of the features require you to hold B+A then press another button but I couldn't seem to make it work (works on the NES). Can anyone that runs this on actual hardware (I'm going to get myself set up) confirm that you can actually do this and it's just a limitation (for some reason) of VisualBoyAdvance?

neilbaldwin · Post by **neilbaldwin** » Thu Dec 10, 2009 1:27 am

neilbaldwin wrote: However, some of the features require you to hold B+A then press another button but I couldn't seem to make it work (works on the NES). Can anyone that runs this on actual hardware (I'm going to get myself set up) confirm that you can actually do this and it's just a limitation (for some reason) of VisualBoyAdvance?

Not to worry: I reconfigured the keys in VBA and it works fine now.

neilbaldwin · Post by **neilbaldwin** » Thu Dec 10, 2009 2:44 am

Had a quick go at a different layout.

Means;

- I've lost one line of the Pattern Editor
- The Song Info abbreviations are slightly more obscure. SNG=Current song number, TMP=Current song tempo, PLN=(global) Pattern length and PNS=maximum number of patters (changes dynamically as you change the global pattern length, hence being darker as you can't edit the number directly). Make sense?
- I've had to lose my 6th "Aux" byte from the instruments but as I'd yet to think of a use for it I guess it's no great loss

+ Slightly less to draw per frame
+ Will display OK on PocketNES and, I guess, most NTSC TVs

You might spot that there's a blank line between the Song Editor and Pattern Editor but this will be put to use for some simple key-press hints at a later stage so I want to keep that.