arfink
Offline
Minneapolis

Nice, thanks Neil. OK then, I'll design my cart with extra PRG ROM space and I can just pad it out for now. And, just so you know, I was going to spend money on some MMC1 dev carts anyways, so what the heck, right? I think that since you're shooting for more than 128kbit of PRG space sometime down the line I'll just plan on modding an SNROM cart and just dealing with the WRAM to CHR ROM conversion anyway, since an SKROM can't do bigger than 128kbit PRG ROM.

Of course, you could just get really crazy and change the mapper entirely... which I wouldn't mind. Do what you need to do. I only asked because I happen to have an MMC1 in the works here, and wanted to make sure I could accommodate your code as long as I'm at it.

EDIT: HMM... looking at the hardware, it seems to me that getting more than 128kbit in PRG ROM on an MMC1 is going to require a) using CHR RAM or b) omitting SRAM, at least on a real cartridge. I think maybe the repropacks can do it, but I can't find any original NES hardware which can actually give you more than 128kbit in PRG ROM without stealing CHR space in order to do it.

Last edited by arfink (Jan 13, 2010 5:26 pm)

neilbaldwin
Offline
WOW MAN!
arfink wrote:

Nice, thanks Neil. OK then, I'll design my cart with extra PRG ROM space and I can just pad it out for now. And, just so you know, I was going to spend money on some MMC1 dev carts anyways, so what the heck, right? I think that since you're shooting for more than 128kbit of PRG space sometime down the line I'll just plan on modding an SNROM cart and just dealing with the WRAM to CHR ROM conversion anyway, since an SKROM can't do bigger than 128kbit PRG ROM.

Of course, you could just get really crazy and change the mapper entirely... which I wouldn't mind. Do what you need to do. I only asked because I happen to have an MMC1 in the works here, and wanted to make sure I could accommodate your code as long as I'm at it.

Cool.

I chose MMC1 because it seemed the simplest and most common mapper. If going over 128k is awkward then I'll try to mitigate my ROM space issues.

bucky
Offline
philly
neilbaldwin wrote:

Method one offers the most stable timing as it's always based on a factor of 60fps e.g. a "tempo" of 3 would have a delay of 180 frames between each tick. However, this means that you have little in the way of tempo resolution as the smallest difference between one tempo and the next is 60 frames.

Method two offers you more resolution (I won't get into why) but is less stable because, depending on the speed, every X ticks, it will miss an update. This shows up as tiny fluctuations in your song tempo.

So the question is, which one to use for NTRQ? You've all probably more experience of trackers than me so I'd value any input.

Dare I say I've thought of a way of maybe having both. Maybe... but forget I said that for the time being smile

Haha, awesome. If you can't do both, I am a fan of stability. I've worked on some tracks in famitracker with unstable tempos and it can become VERY noticeable. Like an entire 32nd note or more being dropped, depending on the tempo, making any 16th note rhythm stand out as sounding clearly wrong / inconsistent.

neilbaldwin
Offline
WOW MAN!

DAMN YOU O'HARE!

Actually I've just put both in and it works fine. Needs a bit more thinking about though as currently;

$00-$1F = index into pitch table using frame counter, $00-$1F
$80-$9F = index into pitch table using overflow method, $00-$1F

which is not the most obvious thing in the world but it does work.

I forgot to say that you can get some "extra" resolution from the frame counter method by specifying a loop between two values in the speed table;

00:03 01        ;speed 3, jump to step 1
01:04 00        ;speed 4, jump to step 0

which would be slightly slower than speed 3 but slightly faster than speed 4, and so on.

Plus you can do the "swing feel" trick using the same method;

00:02 01
01:02 02
02:04 00

etc.

akira^8GB
Offline
New York City
neilbaldwin wrote:

I forgot to say that you can get some "extra" resolution from the frame counter method by specifying a loop between two values in the speed table;

00:03 01        ;speed 3, jump to step 1
01:04 00        ;speed 4, jump to step 0

That's like issuing F commands on Protracker (and others) on every step, like

--F03
--F04
--F03
--F04

and so on... right? Only on a table (convenient)
It's kind of a standard and I like it. I love the idea that it can be put in a table instead of using the Effect column of a channel.

Last edited by akira^8GB (Jan 13, 2010 6:34 pm)

neilbaldwin
Offline
WOW MAN!

@akira Yep, exactly the same.

Yeah, you want that stuff in a table. Frees up the effect column then smile

Oh, I'm also going to have a command in the Song Master Track too, you'll then have the flexibility of setting the speed table index either in a Pattern on in the Song.

I'm too good to you all wink

neilbaldwin
Offline
WOW MAN!

Scratch that, I've just made it better.

Now, you just specify the Speed Table index, $00-$1F. Then in the table itself, if the speed setting is lower than $20, its treated as a frame counter, otherwise it's used in a overflow calculation. So;

00:03 00        ;set frame counter sped 3, loop

or

00:50 00        ;set overflow counter to $50, loop

Perfect! big_smile

PixyJunket
Offline
Plano, TX

Dude, you are a monster.

(and have great taste in TV shows).

egr
Offline
Abandoned on Fire
neilbaldwin wrote:

I'm too good to you all wink

True.  Rock on!

neilbaldwin
Offline
WOW MAN!
PixyJunket wrote:

Dude, you are a monster.

(and have great taste in TV shows).

There's a story behind that that I may share with you all if I get 5 minutes smile

akira^8GB
Offline
New York City
neilbaldwin wrote:

Oh, I'm also going to have a command in the Song Master Track too, you'll then have the flexibility of setting the speed table index either in a Pattern on in the Song.

There's something in AHX I really love and helps you save memory, and maybe you want to implement: when you arrange your song, you can TRANSPOSE the pattern you arrange there with a command. Like this:


010 0F0
(pattern number, then transpose byte)

That's because AHX doesn't use "chains" like LSDJ, but LSDJ is not your conventional tracker smile

ant1
Offline
uhajdafdfdfa

Judging by this post, Neil is already doing/has already done that. smile

neilbaldwin
Offline
WOW MAN!
ant1 wrote:

Judging by this post, Neil is already doing/has already done that. smile

Yup smile

Random
Offline
Stockholm
bucky wrote:

I've worked on some tracks in famitracker with unstable tempos and it can become VERY noticeable. Like an entire 32nd note or more being dropped, depending on the tempo, making any 16th note rhythm stand out as sounding clearly wrong / inconsistent.

Hey bucky,

I'm also having similar problems of unstable tempo in famitracker. First I thought it only had to do with the speed being to high, and therefor overloading the CPU somehow, but that does not seem to be the case any more.

Do you know if there's a way to work around this? Is it a known "bug" to jsr?

bucky
Offline
philly

Ah, it turns out it's not really a bug, just something you have to deal with. I posted a thread about it here-
http://8bitcollective.com/forums/viewtopic.php?id=10361

The best way to avoid unstable tempos is to not bother with tempo (Fxx) commands and simply use the global speed settings. Doesn't quite give you a lot of freedom, I know!

tRasH cAn maN
Offline

Theoretically speaking. would this be the case also if the clock would be an external one? Say a sync signal via the expansion port.