The new fork of HuC

[Bonknuts]

Well.. the whole 60hz vs something higher is a never ending debat. I personally think anything higher than 60hz is a waste for what it offers and what it requires. And that's personal preference, but more to the point, only note parsing needs to be done at TIRQ rate. Doing anything else at that rate is lazy and resource wasteful (you're not going to hear the difference in drop of an envelope at a rate higher than a 60hz tick - simply because such things are always in the LF range, like vibrato and everything else in the real world of music). Also, you can do increased tempo on 60hz tick with fixed point system, but purists scuff at the idea.

 The only thing I really take issue with (if you want to eat the additional resource for higher than 60hz, than fine), is when people let the TRIQ drift out of sync. The max resource for parsing all channels and having to do something, mixed at an inopportune time - sucks. Anchor that bitch in every v-int call so it doesn't drift.

 Though I think a better compromise is 120hz, re-sync'd TIRQ, and fixed point system for tempo control (as well as note length). But the programmer in me says 60hz or GTFO... damn ass musicians always wanting the world lol.

 If the PCE actually had a real PAL system (that unreleased TG doesn't count - not official), then using the Timer could make sense in that respect; music runs the same regardless of the system. Though that's being pretty lazy.

 

What-on-earth do you want more than 4 regions for??? 

AirZonk clone.

 Normally, I'd suggest emulating HDMA setup of the snes. An array for; x.lsb, x.msb, y.lsb, y.msb, bit flag for sprites on/off;bg on/off, color #0 updating, and finally one for RCR. Since H-INT uses a jump indirection, you could limit what features to use. Let the programmer build the table each vblank. The problem, is trying to manage those tables via C code. This is where the idea fails. I wrote one for someone using HuC.. then when I wrote some demo code to update the arrays in C - I was horrified by the performance hit. 

[Bonknuts]

As Bonkuts said, this sounds more like an interrupt-handling issue, or someone is using Txx instructions with larger than 32-byte transfers which are delaying the interrupt.

 I just looked at Squirrel 3.0 hucard code, and it's setting a flag and reenabling interrupts at the start of the call, so I'm not sure what Rov was experiencing. Made an older version?

[nodtveidt]

Please forgive my ignorance but what is the sort all about? Is there a specific way the scroll() regions should be used? I've always done them top-to-bottom, but if there's a faster/better way, then spill the beans, yo

[TheOldMan]

....what is the sort all about?

My understanding is that the scroll regions are sorted by display lines. Then, when an hsync occurs, you don't have to look for the region to see if things need changed. Because they are sorted, you can check the current region, and if its the correct line, update the scroll registers and move to the next region.

Sorting is needed because the scroll regions aren't fixed in place. You can move region 1 to any (valid) spot on the screen; you can also expand/contract them, from frame to frame. So the  regions need to be sorted before being used. IIRC, something like this happens in some example code on how to use them.

The problem comes in because of that; iirc, when you update a scroll region, it re-sorts them (at least in the code I was looking at). Which causes problems.
(ie, what if they are being sorted and an hysnc occurs, for a matching line? for one example)

....................

...damn ass musicians always wanting the world lol.

+1. Though in fairness, Arkhan does manage some really nice sounding stuff in a small space...

[Bonknuts]

The problem comes in because of that; iirc, when you update a scroll region, it re-sorts them (at least in the code I was looking at). Which causes problems.
(ie, what if they are being sorted and an hysnc occurs, for a matching line? for one example)

 Yeah, good point. If your code that's making these changes to the scroll are at the very edge of vblank's end, then it's possible something in vblank code is pushing it over.

 Rov: You're not trying to fit all game logic inside vblank time, right? I.e. the time between vsync() and the start of active display.

[nodtveidt]

Rov: You're not trying to fit all game logic inside vblank time, right? I.e. the time between vsync() and the start of active display.

Hell if I know.

[TheOldMan]

Yeah, good point. If your code that's making these changes to the scroll are at the very edge of vblank's end, then it's possible something in vblank code is pushing it over.

It's not even that. Consider the following:
You have 2 scroll regions, each taking half the screen.
You also have the player playing, on the timer. It just so happens that when you start the music, the timer irq kicks off it's countdown at just before that same spot, due to initialization operations.

Now, during active display, you update the scroll areas, and they get re-sorted. The player doesn't have much to do, so its okay.
Until you hit a point in the music where a lot has to happen (for example, we need to change waves). Now the player will update. It takes longer than 'normal' because of the extra things it has to do. So your game code is delayed a little bit more than normal. And you end up (eventually) changing the parameters for the bottom scroll region. Unfortunately, because of the sorting that happens, the scroll update is delayed.

By one friggin scanline. Which means the bottom region bounces up and down.
Yes, it really does happen.
In fact, it can happen with small scroll regions near the top, and the player on vsync also.

[Bonknuts]

Yeah, but.. why would you make changes to the scroll layout during active display? I mean, calculate your offsets during active display, sure, but stash them in a buffer, and then when vblank happens - call scroll() function over whatever iterations from the buffer. Unless I'm missing something. I don't use scroll() with HuC (I use my own h-int routine).

[Arkhan]

It also only lets you have 4 regions by default.

What-on-earth do you want more than 4 regions for??? 

Status bar w/ Radar = 1 region.  The f*ck if that's going to be done with sprites with that radar.  Hell to the nope.

Blue area = 1 region
back row of buildings = 1 region
second row of buildings = 1 region with sprites on the roofs
floor = 4 regions, so you can create a nice line scroll parallax effect. 

That's 8 regions, along with sprites to create more layering.

And for gawd's sake ... why run Squirrel in a timer-interrupt anyway???

I find it highly-unlikely that anyone is currently creating music complicated-enough that a 120Hz or 240Hz timer-interrupt would make an substantial quality-difference to the stepping in the envelopes/sweeps.

IMHO, part of the "sound" of these old consoles is that the music drivers ran at 60Hz.

And if anyone is using Squirrel on a 60Hz timer interrupt instead of the vsync interrupt, then they need to be slapped around the face with a wet kipper.

Is there a list anywhere of HuCard games that ran music drivers at 120Hz with a timer interrupt???

Something I was f*cking around with at one point with arps and dicking around required the timer.

When I started Atlantean, songs I had made were already in that environment, and code I was using was setup for it already.

I never changed it, because it didn't impact anything in the game, and I had thought about speeding up songs as mentioned, but never actually did it.

Since it doesn't hurt anything, works perfectly fine, and everyone likes the end result, I can't say I feel bad about not bothering.

Though I think a better compromise is 120hz, re-sync'd TIRQ, and fixed point system for tempo control (as well as note length). But the programmer in me says 60hz or GTFO... damn ass musicians always wanting the world lol.

The irony of this statement is quite hilarious.  lol.

If the PCE actually had a real PAL system (that unreleased TG doesn't count - not official), then using the Timer could make sense in that respect; music runs the same regardless of the system. Though that's being pretty lazy.

How is that being lazy?  Would you rather the music run all doofy on the wrong system?

[elmer]

Though I think a better compromise is 120hz, re-sync'd TIRQ, and fixed point system for tempo control (as well as note length). But the programmer in me says 60hz or GTFO... damn ass musicians always wanting the world lol.

Ouch, that sounds a bit expensive for a feature that I don't remember ever hearing being used.

Sure ... a slow tempo change is sometimes nice in a pop song, but you really don't hear it in classic-era videogames, do you? 

That's 8 regions, along with sprites to create more layering.

Doh! Pretty stupid of me to forget about parallax!    :oops:

OK, so more-is-better.

The problem comes down to the sort-time, and the double-buffering or whatever-other scheme that you come up with to ensure that scroll-regions don't suffer from this "instability-bounce" that The Old Rover is seeing.

Since it doesn't hurt anything, works perfectly fine, and everyone likes the end result, I can't say I feel bad about not bothering.

There's definitely the case of "if it isn't broken, then don't fix it.".

The problem is one of drift, interrupt-priority, and the desire to use the timer interrupt for sample playback.

If the interrupt-handlers are written properly so that sound driver running-on-the-timer is smart-enough to avoid delaying the handling of a vblank-interrupt, then it's not too bad ... just rather pointless when running the sound driver at 60Hz.

The question is ... is the System Card Player, and the IRQ handling in both the System Card and HuC smart enough to handle not only timer-followed-by-vblank, but also vblank-follow-by-timer???

The vblank processing MUST always have priority over the sound driver's update logic.

Would you rather the music run all doofy on the wrong system?

Well, BITD, everyone used to just change the equates for how many ticks were in a 1/16th note depending upon the PAL or NTSC target, and then *maybe* change the envelopes.

Not a huge deal, and far less of a problem than the poor European programmers that had to make their games run in a 1/60th second frame time instead of 1/50th second (20% less time per frame).

[Bonknuts]

Though I think a better compromise is 120hz, re-sync'd TIRQ, and fixed point system for tempo control (as well as note length). But the programmer in me says 60hz or GTFO... damn ass musicians always wanting the world lol.

Ouch, that sounds a bit expensive for a feature that I don't remember ever hearing being used.

Sure ... a slow tempo change is sometimes nice in a pop song, but you really don't hear it in classic-era videogames, do you? 

 Full disclaimer: I've never actually used a fixed point tick system for 60hz. I've only read over at nesdev forum. Actually, maybe that's not true. I've done the "mod" trick.. switching between base tick and tick+1, or tick-1, ever other frame to get in between ranges. It works. In trackers, you just increment or decrement the base tick if you want fine tempo shifts. It's not any different than doing it with the TIMER unit down counter, just that the steps are obviously larger. But again, it works. I have MODs and XMs that do this. 

[elmer]

Actually, maybe that's not true. I've done the "mod" trick.. switching between base tick and tick+1, or tick-1, ever other frame to get in between ranges. It works.

I'm still trying to get my head around this ... do you mean changing the mod's base tick setting every 1/60th of a second, or on every row of the mod's pattern? 

In trackers, you just increment or decrement the base tick if you want fine tempo shifts. It's not any different than doing it with the TIMER unit down counter, just that the steps are obviously larger. But again, it works. I have MODs and XMs that do this.

Yes, this is what I'm more-familiar with.

Something like deflemask has "base" timings for even and odd rows of the pattern.

That allows him (for example) to set an even time of 4, and an odd time of 3, and basically have 1/16th note time be 7/60, and have 1/32nd note time be either 3/60 or 4/60 depending upon which row it is on.

Then you can change the base time for either row to speed up or slow down the tempo.

That's effectively the same thing that the System Card player is doing by encoding notes with a duration in 1/16th note increments, and then multiplying that by a base value (say 7).

In either system you're basically allowing a variable tempo, but in coarse steps:

Base Tempo = 5/60s = 180 bpm
Base Tempo = 6/60s = 150 bpm
Base Tempo = 7/60s = 128 bpm
Base Tempo = 8/60s = 112 bpm
Base Tempo = 9/60s = 100 bpm

That was good-enough BITD, and I just don't see that using a timer interrupt to provide a finely-tunable tempo is going to allow previously unheard-of streams of creativity that would outweigh the practical costs. But that's just my opinion.

[Bonknuts]

Actually, maybe that's not true. I've done the "mod" trick.. switching between base tick and tick+1, or tick-1, ever other frame to get in between ranges. It works.

I'm still trying to get my head around this ... do you mean changing the mod's base tick setting every 1/60th of a second, or on every row of the mod's pattern? 

 Like this:

Code: [Select]

        ;// Pattern line read every <n> ticks
        dec RegPlayerTick
        beq .FetchPatternEntry
  rts
.FetchPatternEntry
        lda PlayerTick.flt
        eor TickMode
        sta PlayerTick.flt
        lda PlayerTick
        sec
        sbc PlayerTick.flt
        sta RegPlayerTick
So if the BPM is based on down count of 3 (1/60 ticks), when that expires refill the downcount to 3-1, then on expire back to 3 - and repeat. You'd think this would get you 'warbly' sounds, but it doesn't. It gets you a BPM that's in between a 3 tick and a 2 tick. In MOD or XM files, you can set the tick on every pattern line, and a pattern line is read once the tick down count reaches 0. So it's not uncommon to see something like tick defines as 3,2,3,2,3,2,3,2 going all the way down the pattern - etc. Of course, you could do this on the player side too.

[Arkhan]

The problem comes down to the sort-time, and the double-buffering or whatever-other scheme that you come up with to ensure that scroll-regions don't suffer from this "instability-bounce" that The Old Rover is seeing.

Yeah, I am really curious what is going on there, since Atlantean is quite a busy game, with music, sprites, and scrolling.  I never see this bounce.

The question is ... is the System Card Player, and the IRQ handling in both the System Card and HuC smart enough to handle not only timer-followed-by-vblank, but also vblank-follow-by-timer???

The vblank processing MUST always have priority over the sound driver's update logic.

AFAIK, the vsync always gets priority.  I've not seen or had issues where it did not.

Also, I recall now (and OldMan reminded me), that Squirrel with vsync doesn't support tempo changing because it was a PITA, and the timer mode was not. 

vsync has a fixed tempo, so you must set note durations accordingly.   It kind of sucks, and I forgot about it until all of this came up.

Well, BITD, everyone used to just change the equates for how many ticks were in a 1/16th note depending upon the PAL or NTSC target, and then *maybe* change the envelopes.

lol, tell that to Shadow of the Beast for Genesis.

[Sunray]

So if the BPM is based on down count of 3 (1/60 ticks), when that expires refill the downcount to 3-1, then on expire back to 3 - and repeat. You'd think this would get you 'warbly' sounds, but it doesn't. It gets you a BPM that's in between a 3 tick and a 2 tick. In MOD or XM files, you can set the tick on every pattern line, and a pattern line is read once the tick down count reaches 0. So it's not uncommon to see something like tick defines as 3,2,3,2,3,2,3,2 going all the way down the pattern - etc. Of course, you could do this on the player side too.

Well, when modules do alternating speed changes it is not to simulate an in-between tempo, it is to create a rhythmical feel where every other note is longer/shorter. If they wanted to change tempo they would just change the BPM.

Of course you could do this to simulate a different tempo but to me that would change the musical impression of the song.

60 Hz is always going to be 125 BPM in a tracker, so I would avoid creating modules in other tempos.

Anyway, back to topic perhaps.