The new fork of HuC

[elmer]

Anyway, back to topic perhaps.

Good point, I'll reply to these last few messages in the MML topic where this stuff belongs. 

[Bonknuts]

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.

 The original MOD spec doesn't allow you to change the 'BPM' setting. That's a later thing, in other trackers. And it has nothing to do with rhythmical feel. Because artists have told me what they were trying to do. I don't know about you, but I can't distinguish between a tick difference every other frame in relation to note lengths; I can only perceive it as change in tempo.

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

No, 50hz is 125BPM. 60hz is 150BPM in trackers. Hz * 60 / 4 / 6. (The default tracker setting)

[Sunray]

The original MOD spec doesn't allow you to change the 'BPM' setting. That's a later thing, in other trackers. And it has nothing to do with rhythmical feel. Because artists have told me what they were trying to do. I don't know about you, but I can't distinguish between a tick difference every other frame in relation to note lengths; I can only perceive it as change in tempo.

I was mainly talking about more advanced module formats though, like S3M, XM and IT. But for MOD this is probably true, but the same can be seen in XM songs which always had tempo control. The original MOD format is near useless as a intermediate music format.

To me it's very apparent in drum sequences. But usually it's at least a 2+ tick alternation and probably in a different BPM as well.

I recently fixed a "bug" in my replayer for PC that was causing each tick to be +-2.9 ms off (rounded to nearest audio frame of 128 samples). When I fixed this to be sample accurate there was a night and day difference, especially when you used the retrig command.

No, 50hz is 125BPM. 60hz is 150BPM in trackers. Hz * 60 / 4 / 6.

Yeah of course. I mixed up PAL and NTSC, I'm too used with PAL.

[Bonknuts]

Ok. Elmer.. I was looking through HuC scroll handling routine and I see that the sorting is called via vblank handler. So it pretty much sets up hscroll sections immediate on vsync int.

 My question to you is, should this be moved to the first hsync call - giving more time before the list gets sorted? Or leave it but provide some explanation as to how to properly layout main code in relation to a frame setup? I mean, the whole SATB happening on specifically right at vblank and NOT at the start of the display - kinda means you need to structure your frame logic differently than other systems of the era anyway. This probably isn't apparent to people dev'ing on the PCE until you try to sync sprites with the BG layer (even some professional PCE games get this wrong!).

 I'm not sure if my question is clear. I can elaborate more if needed (I'll post pics!).

[Arkhan]

why does the list get sorted, anyways?

[Bonknuts]

I'm guessing that because scroll() defines a "window" rather than just changes to a specific scanline, that you can have a window region inside another region? So if you define one window region from top to bottom of y1 = 128 and y2=192, but then have another window with a definition of y1=150 and y2=160. That, and one window's start position could be another window's end position, etc. It's gotta do some sort of.. sorting to figure out what to do on a specific scanline in the case of overlaps?

[elmer]

why does the list get sorted, anyways?

I'm guessing that because scroll() defines a "window" rather than just changes to a specific scanline, that you can have a window region inside another region?

It's so that you can move windows on the screen ... look at this example in Sapphire (at 7:38) ...

Ok. Elmer.. I was looking through HuC scroll handling routine and I see that the sorting is called via vblank handler. So it pretty much sets up hscroll sections immediate on vsync int.

My question to you is, should this be moved to the first hsync call - giving more time before the list gets sorted? Or leave it but provide some explanation as to how to properly layout main code in relation to a frame setup?

I'd recommend just documenting it and getting programmers to use it properly, but perhaps you're thinking of something that I'm failing to see.

[elmer]

So, its inserting a random zero into the rom, in between incspr? That seems lame.

Also, a faster load_vram would be amazing. wink wink nudge nudge say no more.

OK, here you go, it's an early Christmas! 

https://www.dropbox.com/s/b5c2mjhof9m98h7/huc-2016-12-20.zip?dl=0


This is the cumulative changelog for the current version ...

New in version 3.99:
--------------------
2016-12-20
- Imported Uli's v3.98 version of HuC (https://github.com/uli/huc)
  See README for all the changes that Uli made
- Applied changes from Artemio Urbina's fork of HuC
- Applied changes from Markus Buretorp's fork of HuC
- Fixed compilation on Windows with mingw-w64
- Fixed a few bugs related to Uli's improvements
- Changed System Card parameter equates to have a "__" prefix
- Changed startup.asm to allow a sound driver to use macros to integrate
- Removed Uli's support for interrupt handlers in HuC (they're too slow)
- New str/mem package to replace the old code
    Note 1 : Strings are 255 bytes maximum (+ trailing null)
    Note 2 : When a ptr is returned, it points to the end of the str/mem
             This breaks ANSI/ISO compatibility, but is more useful
    Note 3 : strncpy handing of the 'length' is the same as strncat
             This breaks ANSI/ISO compatibility, but reduces code size
- Bumping version number for all the current changes
- Stop HuC adding an extra ".dw" to usage of .incchr/.incspr/.incpal/etc
- Add extra parameter to set_tile_data() to set the tile type (8 or 16)
    set_tile_data(char *tile, int nb_tile, char *ptable, char type);
- Rewrite load_vram to use 32-byte TIA instructions (3x speed improvement)


Please note the change in the set_tile_data() function call!!! 

Everything is in github for those folks that want to make their own build.

[Gredler]

Christmas came early!!

[Bonknuts]

Woot!

[elmer]

Woot!

Sorry, but I didn't update the load_vram in your SuperGrafx support package.  :oops:

I don't think that anyone out there *currently* needs it, and I'd like to handle the SuperGrafx a bit differently when it comes to the exciting-next-gen version of HuC that I'll eventually get back to working on.

Too many projects, too little time in the day. 

[DarkKobold]

I'm super excited for this!!!

Hopefully it will clean up some glitches, without me having to become a better programmer!

[nodtveidt]

I'm guessing that because scroll() defines a "window" rather than just changes to a specific scanline, that you can have a window region inside another region? So if you define one window region from top to bottom of y1 = 128 and y2=192, but then have another window with a definition of y1=150 and y2=160. That, and one window's start position could be another window's end position, etc. It's gotta do some sort of.. sorting to figure out what to do on a specific scanline in the case of overlaps?

I didn't even know that this was possible, honestly... the way I have it set up, each zone is set up from top to bottom with absolutely no overlap. For example... scroll region 0 might be 0 to 95, scroll region 1 might be 96 to 127, etc. I am not sure if this direction is correct or not, but the one thing I never do is something like scroll region 0 from 0 to 180 and then scroll region 1 from 90 to 120... that doesn't seem right. If my order is backwards and I should start from the bottom and go up, then that'd be ok... if it doesn't have to sort at all because the order is already sorted by hand, that'd be good.

[elmer]

That, and one window's start position could be another window's end position, etc. It's gotta do some sort of.. sorting to figure out what to do on a specific scanline in the case of overlaps?

I didn't even know that this was possible, honestly... the way I have it set up, each zone is set up from top to bottom with absolutely no overlap.

Yep, the sort is needed to allow for things to move on the screen ... there's the Sapphire example that I linked to. But it's not a common effect.

HuC is using a bubble-sort that exits early if there are no changes, so it's not *horribly* slow.

You're doing a good job by giving it a pre-sorted list of areas to deal with.

The classic causes for instability in an hsync split like that are ...

1) Running some code that delays the hsync interrupt for too long.
2) Having the interrupt-driven sorting code run at the same time that you're actually calling scroll() to change the screen position, and seeing a partially-written 16-bit value.
3) Letting something else interrupt the sorting code in the middle of its job.

I have no idea which of those situations you're hitting.

I forgot ... did you say whether you were using Squirrel or the System Card Player in timer mode instead of vsync mode?

I'll look at all of this stuff in detail, at some point, but I'll probably only be doing it for the even-newer HuC with the zero-page stack.

[TheOldMan]

Elmer, I gots a question....

First, I haven't grabbed the latest version of Huc. I'm still working with the last one.
In startup.asm. line 139 (by my editor), you have a check for NEED_SOUND_BANK.
If that's true, you set PSG_BANK. (presumably to 4, but I could be wrong there)
Is that supposed to be the bank for the psg player?

If so, there's a problem.  system.inc uses PSG_BANK for the bios function number.
And if you are using HuC, won't that overlap with either CONST_BANK or  DATA_BANK?

Also, is LIB3_BANK used by default? My first test program compiles/runs fine as a cd with the old Huc, but complains about the banks being full when I compile as cd with the new Huc. Any ideas there?