The new fork of HuC

[elmer]

It also only lets you have 4 regions by default.

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

I was thinking about reducing it to 3 regions in order to speed-up the sorting time!

A 3-region sort can be done in 3 compares.
A 4-region sort can be done in 5 compares (HuC uses a bubble-sort with up to 6 compares).
A 5-region sort can be done in 9 compares (the bubble-sort would take up to 10 compares).

I can see the *potential* use for 4 regions in a split-screen game with status bars at the top and bottom ... but who-on-earth would write that in HuC, and if they did, why wouldn't they just use sprites for the top and bottom status bars???

If the problem is because Squirrel is running on the TIRQ instead of V-INT, then just simply add two small bits of logic at the very start of the TIRQ routine
...
If you're already doing this AND it's still delaying H-int routine - then you need to seriously look at both to find out what's going on.

scroll() is hooked into the hsync irq. It has to monitor the raster-hit irq bit.
One problem with that is, I think, that it re-sorts it's list (at least thats what I think it's doing) during this process.
Which leads to the problem; if something is already in an irq (be it vsync or timer), the hsync routine can get delayed, causing the scroll area adjustment to be delayed a line.

I'm not entirely sure why/when it happens, but it does happen. Especially is squirrel is running at a high timer rate, or if lots of small regions are being constantly scrolled.

From what I've seen, the scroll() does it's sorting and preparation during the vblank interrupt.

The stuff that's done in the hsync interrupt isn't particularly slow.

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.

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???

[touko]

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

i agree and it's difficult with that to play PCM with timer interrupt .

[OldRover]

I very frequently use all four scroll regions.... both Henshin Engine and Lucretia do this. Henshin Engine's stage 00 actually needed five, but I found a way to work around that with dynamic tiles and sprite tricky-trickies.

[OldMan]

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

(faked) multi-layer parallax. Say, 3 sky sections and 3 ground sections.

why wouldn't they just use sprites for the top and bottom status bars???

Because they're in use for enemies/shots/etc. Not to mention, it's easier to update the BAT than it is to re-load the sprite data (especially for scoring).

From what I've seen, the scroll() does it's sorting and preparation during the vblank interrupt.

What version of scroll are you looking at?
I don't see how this would be possible (ie, only sort/prepare during v-blank) without some kind of buffer....

why run Squirrel in a timer-interrupt anyway???

Because we would like to speed the sound up during boss battles. And tempo adjustments are only available using the timer irq.

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.

Take it up with Arkhan. He had a 135 BPM song with 32'nd notes for an arpeggio using faked adsr envelopes.  It made a difference to him.

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

...where's that wet kipper. I owe him a few, I guess....

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

As Bonkuts said, this sounds more like an interrupt-handling issue

I agree. I just don't know which irq is actually causing the problem, or why.

The bios guys were pretty good, imo.  Vsync/HSync/Timer already have lockouts to prevent multiple nested calls (ie, if you get a hsync and are already servicing one, it will return right away). The bios player also has a sound lockout (ie, if it's in use, and an irq occurs, the sound part of the irq returns immediately).

It's been a while since I looked at all this, though. And I never was good with irq code.

I very frequently use all four scroll regions.

Rover: We did 5 or 6 on the pp title screen. You just have to adjust some sizes for the scroll list.
Not something I'd want to do in a high-speed game (unless scroll became way faster), but definately fixable. Without sprite/tile trickery.

[ccovell]

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

Not that I know of, but anecdotally, Keith Courage & Neutopia (though the former only needs it for sound effects).  Out Live runs its music routine at around 108Hz.

[TurboXray]

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.

[TurboXray]

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?

[OldRover]

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

[OldMan]

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

[TurboXray]

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.

[OldRover]

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.

[OldMan]

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.

[TurboXray]

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 Asylum]

It also only lets you have 4 regions by default.

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

https://youtu.be/34PIDiVHv6g&t=54s

Status bar w/ Radar = 1 region.  The fuck 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 fucking 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!   

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).

[TurboXray]

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.

[TurboXray]

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 Expand

        ;// 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 Asylum]

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.

[elmer]

Anyway, back to topic perhaps.

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

[TurboXray]

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.

[TurboXray]

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 Asylum]

why does the list get sorted, anyways?

[TurboXray]

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!!

[TurboXray]

Woot!

[elmer]

Woot!

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

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. 

[DildoKKKobold]

I'm super excited for this!!!

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

[OldRover]

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.

[OldMan]

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?

[elmer]

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?

Good catch! 

I hadn't seen the usage of PSG_BANK as a BIOS call in system.inc, and it was stupid of me not to search. 

OTOH ... it's also stupid of HuC/PCEAS not to raise an error at the redefinition!!! 

To-be-honest, it was a label that I copied from your startup.asm in Squirrel 3.0 ... so you've got the same bug in there! 

You'd have to tell me what it is that you guys are using it for.

I just changed how the bank number itself was calculated, under the assumption that you needed a free bank for some reason.

Looks like you guys are setting it to bank 2 in HuCard builds, and the new startup.asm is setting it to 2 or 3 depending upon whether LIB3_BANK is needed.

I changed to code to set things more flexibly using .rsset and .rs instead of the tangled mess of conditionals that it was using previously, and I'm not really sure under *what* circumstances LIB3_BANK is used.

Isn't that the bank for the Arcade Card and SuperGrafx add-on libraries?

The .rs directives should change the CONST_BANK and DATA_BANK numbers depending upon how many other banks are defined/used earlier.

It's working for Catastrophy, which uses Squirrel, and for the HuC example HuCard programs, which don't.

Anyway ... since there's a conflict, it should probably be renamed to something like "SOUND_BANK".

BTW, what are you guys using it for?

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?

If you can send me the source to the test program, then I can find out what's going on and fix it.

The HuC example CD programs are compiling fine, so I wasn't aware of any problems.

[OldMan]

To-be-honest, it was a label that I copied from your startup.asm in Squirrel 3.0 ... so you've got the same bug in there!
You'd have to tell me what it is that you guys are using it for.

Nope. I renamed the bios function numbers to PSGF_xxx.

It's used to make calls to the bios, for things like setting up wave table, envelopes, etc. And for starting playback
Look at the actual bios stuff; there's a table of functions, and those are the indexes.

And in any case, it's set to 3 explicitly in the old Huc...both places, iirc.
Which should kick up a "redefinition" warning, but since the values are the same, not an error.

...I'm not really sure under *what* circumstances LIB3_BANK is used

Yeah, I figure thats what the problem with bank overflow is.
I *think* they may be included by default.
I'll sit down tonight and figure out how the banks are being used.
But overall, I'm probably gonna have to change more than sound.inc/sound.asm to get it straightened out.

The program I'm testing with is test1.c from the squirrel 3.0 zip on aetherbyte. It uses the HuC bios
interface (a bunch of simple asm routines to call the bios functions). Most programs I've seen don't use it, other than possibly the play function.

[elmer]

To-be-honest, it was a label that I copied from your startup.asm in Squirrel 3.0 ... so you've got the same bug in there!
You'd have to tell me what it is that you guys are using it for.

Nope. I renamed the bios function numbers to PSGF_xxx.

It's used to make calls to the bios, for things like setting up wave table, envelopes, etc. And for starting playback
Look at the actual bios stuff; there's a table of functions, and those are the indexes.

And in any case, it's set to 3 explicitly in the old Huc...both places, iirc.
Which should kick up a "redefinition" warning, but since the values are the same, not an error.

This is from system.inc in the old HuC 3.21 from zeograd's lair, and it is unchanged in Uli's HuC, or in my fork of Uli's HuC ...

; --------
; This block defines PSG BIOS function
; number.
;

PSG_ON      = 0
PSG_OFF      = 1
PSG_INIT   = 2
PSG_BANK   = 3
PSG_TRACK   = 4
...


This is from the customized startup.asm in Squirrel 3.0 that I downloaded a few hours ago from the Aetherbutt site ...

; ----
; setup flexible boundaries for startup code
; and user program's "main".
;
START_BANK   .equ   0
LIB1_BANK   .equ   START_BANK
LIB2_BANK   .equ   START_BANK+1
          .ifdef HUC
FONT_BANK   .equ   START_BANK+1

      .if  (CDROM)
CONST_BANK    .equ   START_BANK+2
DATA_BANK    .equ   START_BANK+3
      .else
PSG_BANK    .equ   START_BANK+2
CONST_BANK    .equ   START_BANK+3
DATA_BANK    .equ   START_BANK+4
      .endif

          .else

; HuC (because of .proc/.endp) does not use MAIN_BANK
MAIN_BANK   .equ   START_BANK+2
          .endif   ; HUC

So, unless I'm having a terrible senior-moment, the default system.inc is setting PSG_BANK to 3, and then your customized startup.asm is setting PSG_BANK to 2.

You are setting your new PSGF_* equates in squirrel.s

Did I change those PSGF_* equates in the "fixed (or not)" version that I sent you (I'm dog-sitting and don't have access to those files right now)?

And whatever ... why-on-earth did you guys create PSGF_* aliases for the BIOS function numbers instead of using the one already defined in system.inc, and why did you create the PSG_BANK define in your startup.asm that conflicts with the defines in the old HuC system.inc ???

The program I'm testing with is test1.c from the squirrel 3.0 zip on aetherbyte.

Thanks!

I can look at it later on tomorrow.

[OldMan]

If you look at the original startup.asm for the old huc,
you will find (line 33) that -we- did not define PSG_BANK.
The original HuC had the problem.

We used (and defined) the PSGF_ versions because of it.
I didn't want to break anything else that may have used them
(like the included psg player), so I left them alone. I tried to
isolate the PSGF_versions, so they were only used by
the card bios setup; I may have failed there, but it didn't
hurt anything.

I still don't understand *why* the original bank setup works...but it
does, so I left it alone.

And no, I don't think the PSGF_ equates got changed. No real
reason to do so. I think the PSG_ function equates should be
removed myself (they are only applicable for the bios player),
but I can also see where it might cause other problems.

So, unless I'm having a terrible senior-moment,....

You too? I have them all the time...

You are setting your new PSGF_* equates in squirrel.s

??  afaik there is no squirrel.c to generate a .s file.
And .s is a generated file, so it has to be somewhere else.
(psgdefs.h)

Okay, I'm gonna start looking now....
We -will- get this sorted out

[OldMan]

The bank overflow problem for cds I *think* I got figured out.
..................................................................................................
I've been using bank 6 to hold the MML song codes.
Apparently, that kicks the heap to page 7. That means
there isn't enough space for the interface functions.

So: How do I disable the heap?
And any other code that got added?

I'm putting in my feature request now...Can we get an equ/define for the last page used by the system? So i don't have to go hunt for a place to put music

[OldMan]

And the PSG_BANK problem?

The original HuC only defined PSG_BANK as START_BANK+2 if you were not compiling for a CD
(startup.asm, line 34.)
It was defined as 3 (in system.inc), which is included only if you are building a CD.
(startup.asm, line 65)

I understand why there was no conflict now.
I do think it's misleading to re-use the name that way, though.

The way you have the bank definitions set up, PSG_BANK gets set whenever NEED_SOUND_BANK is defined.  If you are not building a cd, (ie, you're building a card), then
there is no problem; system.inc won't be included, and things are fine.
If you are building a CD, however, system.inc -will- be included, and you get the name clash.

Note that if you are building a CD, PSG_BANK should be 2 - that's where the bios expects the cd driver routine to be.

Personally, I'm not sure how you would fix it. I think I'd just change the name, and search for uses (if any).
..................................................................
As an aside (and I could be wrong about this). I believe PSG_BANK is where the player routine should reside. There is actually a call somewhere in the original startup that maps that in, calls it, and maps it back out iirc. One of the things I vaguely remember from doing squirrel was that the psg_bios functions may also be in in that page. I remember thinking it was stupid to do the mapping, because the page was already mapped in. That may be something else I have to look further into.

[dshadoff]

And the PSG_BANK problem?

The original HuC only defined PSG_BANK as START_BANK+2 if you were not compiling for a CD
(startup.asm, line 34.)
It was defined as 3 (in system.inc), which is included only if you are building a CD.
(startup.asm, line 65)

I understand why there was no conflict now.
I do think it's misleading to re-use the name that way, though.

The way you have the bank definitions set up, PSG_BANK gets set whenever NEED_SOUND_BANK is defined.  If you are not building a cd, (ie, you're building a card), then
there is no problem; system.inc won't be included, and things are fine.
If you are building a CD, however, system.inc -will- be included, and you get the name clash.

Note that if you are building a CD, PSG_BANK should be 2 - that's where the bios expects the cd driver routine to be.

Personally, I'm not sure how you would fix it. I think I'd just change the name, and search for uses (if any).
..................................................................
As an aside (and I could be wrong about this). I believe PSG_BANK is where the player routine should reside. There is actually a call somewhere in the original startup that maps that in, calls it, and maps it back out iirc. One of the things I vaguely remember from doing squirrel was that the psg_bios functions may also be in in that page. I remember thinking it was stupid to do the mapping, because the page was already mapped in. That may be something else I have to look further into.

OK, looks like you guys have found a bug (yes of course they existed in HuC before - you should see some of the bugs in some of the professional games too !).

So the original PSG_BANK in startup.asm was intended to declare where the System-card-compatible-but-never-properly-working PSG code was intended to be located.

There was a conflict because the DEVELO assembler book declared this to be a subfunction type for the PSG BIOS routine (which the HuC code was intended to mimic).  The assembler, as I recall, doesn't flag redefinitions of EQU values, so this never showed up as a problem during compiles, but it seems that this could be a contributing factor to why the sound driver never worked.  I ran out of time to debug just as I finished the code, and left it in, in the hopes that somebody else would help debug.  In the end, everybody targeted CDROM so it was never examined.

The idea about mapping is that the sound driver occupies a considerable amount of memory and should not be kept mapped.  Only map it in during the interrupt, and then hide it as soon as it is no longer needed.  If other code occupies the same bank, it is a coincidence.  Same goes for the tune that it's playing.

-Dave

[elmer]

So the original PSG_BANK in startup.asm was intended to declare where the System-card-compatible-but-never-properly-working PSG code was intended to be located.

There was a conflict because the DEVELO assembler book declared this to be a subfunction type for the PSG BIOS routine (which the HuC code was intended to mimic).  The assembler, as I recall, doesn't flag redefinitions of EQU values, so this never showed up as a problem during compiles, but it seems that this could be a contributing factor to why the sound driver never worked.  I ran out of time to debug just as I finished the code, and left it in, in the hopes that somebody else would help debug.  In the end, everybody targeted CDROM so it was never examined.

Thanks, Dave!

The way you have the bank definitions set up, PSG_BANK gets set whenever NEED_SOUND_BANK is defined.  If you are not building a cd, (ie, you're building a card), then there is no problem; system.inc won't be included, and things are fine.
If you are building a CD, however, system.inc -will- be included, and you get the name clash.

Note that if you are building a CD, PSG_BANK should be 2 - that's where the bios expects the cd driver routine to be.

Personally, I'm not sure how you would fix it. I think I'd just change the name, and search for uses (if any).
..................................................................
As an aside (and I could be wrong about this). I believe PSG_BANK is where the player routine should reside. There is actually a call somewhere in the original startup that maps that in, calls it, and maps it back out iirc. One of the things I vaguely remember from doing squirrel was that the psg_bios functions may also be in in that page. I remember thinking it was stupid to do the mapping, because the page was already mapped in. That may be something else I have to look further into.

Hahaha ... OK, I *was* having a senior-moment, but it wasn't your code that was doing something strange, you were just trying to work around stuff in the old HuC. 

I was under the impression that you'd disassembled the original System Card Player to the point where it could live somewhere other than bank 2, but I guess that I was wrong.

I was trying to engineer a solution where any new sound driver could say that it needed it's own bank, even *if* you were building for CD.

I suspect that the easiest solution (to one of the problems) is to rename that equate to SCP_BANK or SOUND_BANK, and for me to rearrange the new startup.asm to make sure that it is always in bank 2, if it is invoked. And then to document *WHY* it is that way!!!

Then I guess that we need some way to decide where the music data actually goes.

Do you know if HuC actually starts putting program data in the DATA_BANK? 

In Catastrophy, it doesn't *seem* to start putting data in until it reaches bank 8.

[OldMan]

I was trying to engineer a solution where any new sound driver could say that it needed it's own bank, even *if* you were building for CD.

Discovery of the problem was entirely due to regression testing the compiler before I started bringing in Huc. I wanted to know it was going to work for cds before I started on the card stuff.
That's on the agenda for the rest of the week.

...easiest solution (to one of the problems) is to rename that equate to SCP_BANK or SOUND_BANK, and for me to rearrange the new startup.asm to make sure that it is always in bank 2, if it is invoked.

Got it. I can change it to SOUND_BANK here.
I believe the player part is moveable to any bank. It's the psg_bios stuff I have to check on.
Even if it currently has to reside in a specific bank, that can easily be fixed, provided we know where
it is.

I, too would like to have the player/interface moveable to any bank. Not only for cards, but for cds as well; it's the only way we are going to be able to extend the player.

Then I guess that we need some way to decide where the music data actually goes.
...
In Catastrophy, it doesn't *seem* to start putting data in until it reaches bank 8.

We left that open to the user.
The MML compiler defaults to bank 9, I believe. There is a switch to move things to a user-selectable bank(s) however. Assuming Catastrophy is using the generated snginit.c, you can look at the very end of the file to determine where the song data is placed.

Be aware that there are problems with how we do it, however. AFAIK there is no way to preserve the current bank number (in either Huc or pceasm), or even find out what it is. Thus, there is no way to return to the last bank in use. Thats a big problem, since once the song data is processed, anything after it will be in the next bank(s). That's why we say put the snginit() include at the end of the file.
The problem is compounded by the fact that HuC doesn't fill pages; things either fit or they don't, and it moves to a new page. So a small re-arrangement of code (or adding something to the program) can cause things to shrink (leaving a gap) or expand (potentially being overwritten). Bank 9 seemed to be generally available, and we had to pick some default

[OldMan]

Okay, I looked over the psg-player code.
There are 2 routines (psg_bios and psg_driver) that *must* be in an always-mapped page.
I -believe- they were originally in START_PAGE.

psg_bios maps in the bios functions, does an indirect call, and then restores the original mapping.
psg_driver maps in the player code and music, steps the player along, and then restores things.

The actual bios functions and the player code can reside in any page that is available. Together,
they do a good job of filling a page, though. It would probably be possible to split them (since they have seperate map-in functions), but I wouldn't recommend it.

Next step is to get psg_bios and psg_driver seperated out into start.asm, and to make sure they load into the correct bank. After that, it should be easy to set the psg_xxx functions and the psg_driver into SOUND_BANK. Then, I have to setup the macros for the interrputs.

That should create a setup that is compatible across the board for the bios MML player. Cards should use the compiled-in code, and cds should use the bios code.

[elmer]

I'm putting in my feature request now...Can we get an equ/define for the last page used by the system? So i don't have to go hunt for a place to put music

That would be a good idea!


****************


OK, I'm back at my main computer today with the latest HuC and the copy of the working Squirrel that I sent you guys.

And I'm having trouble replicating the problem that you're seeing. 

The program I'm testing with is test1.c from the squirrel 3.0 zip on aetherbyte. It uses the HuC bios
interface (a bunch of simple asm routines to call the bios functions). Most programs I've seen don't use it, other than possibly the play function.

I can't find "test1.c" in the Aetherbutt_Squirrel3.zip that I just downloaded (again) from Aetherbutt.

Can you please tell me where to find it?

Can you also let me know the command line that you're using to build it?

Yeah, I figure thats what the problem with bank overflow is.
I *think* they may be included by default.
I'll sit down tonight and figure out how the banks are being used.
But overall, I'm probably gonna have to change more than sound.inc/sound.asm to get it straightened out.

My test-build makes both HuCard and SCD builds of your Squirrel.c example program, and they both run fine with no problems at all.

A build for regular CD fails with ...

  966  03:60C8                .bank   9
       Bank index out of range!
# 1 error(s)

But it fails in the same way on the old HuC as well.

The "sound.inc" that I sent you guys protects itself from inclusion on CDROM builds, and doesn't set NEED_SOUND_BANK on a CD build ... and so PSG_BANK doesn't get overridden, and there is no problem.

There is no conflict!!!

The only thing that I'm seeing that would be sensible to add to the sound.asm that I sent you is to add ".bank START_BANK" above the psg_bios function.

It goes in that bank anyway in the current HuC startup.asm, but it doesn't hurt to be safe.

Okay, I'm gonna start looking now....
We -will- get this sorted out

I really need to see that test1.c file, and whatever command line you're using ... because from where I'm standing right now, it looks like it is already sorted out in the code that I sent you.

The bank overflow problem for cds I *think* I got figured out.
..................................................................................................
I've been using bank 6 to hold the MML song codes.
Apparently, that kicks the heap to page 7. That means
there isn't enough space for the interface functions.

So: How do I disable the heap?
And any other code that got added?

Errr ... I *think* that is is all disabled by default.

You have to add a "-lmalloc" to your build line in order to get the malloc/heap added.

I'm not seeing anything at all in bank 6, I have no idea why you're seeing code in there.

I *really* need a copy of your test setup in order to replicate whatever you're seeing.


******************
Squirrel.c built as a HuCard ...

                                    USED/FREE
      ZP    $2000-$2015  [  22]       22/ 234
     BSS    $2200-$2985  [1926]     1926/6266

BANK  0  Base Library 1             6995/1197
    CODE    $E010-$FB58  [6985]
    CODE    $FFF6-$FFFF  [  10]
BANK  1  Base Library 2/Font        5815/2377
    DATA    $6000-$65FF  [1536]
    CODE    $A600-$B6B6  [4279]
BANK  2  PSG Driver                 7892/ 300
    CODE    $C000-$C029  [  42]
    CODE    $C043-$DEEC  [7850]
BANK  3  Constants                   180/8012
    DATA    $4000-$40B3  [ 180]
BANK  4  User Program                200/7992
    DATA    $6000-$60C7  [ 200]
BANK  5                                0/8192
BANK  6                                0/8192
BANK  7                                0/8192
BANK  8                                0/8192
BANK  9                             1227/6965
    DATA    $8000-$84CA  [1227]
BANK  A                             2441/5751
    CODE    $A000-$A988  [2441]
BANK  B                               18/8174
    CODE    $8000-$8011  [  18]
                                    ---- ----
                                      25K  71K

                        TOTAL SIZE =       96K

******************
Squirrel.c built as an SCD ...

                                    USED/FREE
      ZP    $2000-$2015  [  22]       22/ 234
     BSS    $2200-$29CC  [1997]     1997/6195

BANK  0  Base Library 1             7509/ 683
    CODE    $C000-$C027  [  40]
    CODE    $402F-$406D  [  63]
    CODE    $4070-$4127  [ 184]
    CODE    $C130-$DD65  [7222]
BANK  1  Base Library 2/Font        5955/2237
    DATA    $6000-$65FF  [1536]
    CODE    $A600-$B742  [4419]
BANK  2  Constants                   180/8012
    DATA    $4000-$40B3  [ 180]
BANK  3  User Program                200/7992
    DATA    $6000-$60C7  [ 200]
BANK  4                                0/8192
BANK  5                                0/8192
BANK  6                                0/8192
BANK  7                                0/8192
BANK  8                                0/8192
BANK  9                             1227/6965
    DATA    $8000-$84CA  [1227]
BANK  A                             2441/5751
    CODE    $A000-$A988  [2441]
BANK  B                               18/8174
    CODE    $8000-$8011  [  18]
                                    ---- ----
                                      18K  78K

                        TOTAL SIZE =       96K


<edit>

Just for reference, I'm using the latest version of HuC, and the same version of Squirrel that I sent you guys back on November 21st (the download link is still the same).

[elmer]

Finally, here's a version of squirrel.c built with the SuperGrafx library so that LIB3 is invoked, and the main Squirrel Player gets bumped into bank 3 instead of bank 2.

"huc -v -v -msmall -fno-recursive -sgx squirrel.c -lmalloc"


                                    USED/FREE
      ZP    $2000-$2022  [  35]       35/ 221
     BSS    $2200-$2BD6  [2519]     2519/5673

BANK  0  Base Library 1             7482/ 710
    CODE    $E010-$FD3F  [7472]
    CODE    $FFF6-$FFFF  [  10]
BANK  1  Base Library 2/Font        7876/ 316
    DATA    $6000-$65FF  [1536]
    CODE    $A600-$BEC3  [6340]
BANK  2  Base Library 3              405/7787
    CODE    $A000-$A194  [ 405]
BANK  3  PSG Driver                 7892/ 300
    CODE    $C000-$C029  [  42]
    CODE    $C043-$DEEC  [7850]
BANK  4  Constants                   180/8012
    DATA    $4000-$40B3  [ 180]
BANK  5  User Program                200/7992
    DATA    $6000-$60C7  [ 200]
BANK  6                                0/8192
BANK  7                                0/8192
BANK  8                                0/8192
BANK  9                             1227/6965
    DATA    $8000-$84CA  [1227]
BANK  A                             2441/5751
    CODE    $A000-$A988  [2441]
BANK  B                               18/8174
    CODE    $8000-$8011  [  18]
                                    ---- ----
                                      28K  68K

                        TOTAL SIZE =       96K


And again, it all works!

I also tried it without the "-msmall -fno-recursive" and that works, too.

[OldMan]

I *really* need a copy of your test setup in order to replicate whatever you're seeing.

I'll be mailing it in a few minutes. It's a .zip, you have to re-name it. Google won't mail zips.

I can't find "test1.c" in the Aetherbutt_Squirrel3.zip that I just downloaded (again) from Aetherbutt.

My bad. I re-named it in the test directory. It's squirrel.c

And I'm having trouble replicating the problem that you're seeing. 

I didn't see you trying to build a cd version, with the mml in the right place. Bank 9 doesn't exist on a 2.0 card, and you don't appear to be re-building the mml....

Just for reference, I'm using the latest version of HuC, and the same version of Squirrel that I sent you guys back on November 21st (the download link is still the same).

Nobody sent me anything. And I don't run Java unless absolutely required, so sropbox is out.
Luckily I have friends who send me things - that's how I grabbed the compiler. But it took a couple of weeks.

.............................
FYI. This includes the new version of the mml compiler. Not for public consumption, yet.

[elmer]

I'll be mailing it in a few minutes. It's a .zip, you have to re-name it. Google won't mail zips.

OK, thanks I've got it.

My bad. I re-named it in the test directory. It's squirrel.c

OK, so it is the same file that I've been working with, and compiling successfully.

I didn't see you trying to build a cd version, with the mml in the right place. Bank 9 doesn't exist on a 2.0 card, and you don't appear to be re-building the mml....

Nope, I didn't rebuild the MML because I didn't need to ... there's already a working MML file.

And you already know that I need you guys to change mml2pce in order to add the "__" to the variable names.

So ... with your new version of mml2pce, I've built a working CD of squirrel.c, and I can see that "yes", there's a problem when you try to put the sound data in bank 6 ... but everything is happy if you change it to put the sound data in bank 5.

Err ... I'm not seeing any problem with that. The new HuC is a bit more strict about where it puts the trampoline code for banking in the .proc functions.

It now goes in the last bank in the ROM/ISO.

So if you build a regular CD, and put the sound data in bank 6 ... then the game code starts in bank 7 ... and the trampoline code goes into bank 8, which doesn't exist, and so everything fails.

The big question is why-on-earth put the sound data into bank 6???

You've got multiple wasted-banks with nothing in them much lower than that.

You should be putting the sound data into bank 4.

HuC puts all of its data first, bank-by-bank, and then it puts its code after the data banks.

By declaring that the sound data starts in bank 6 (or 5, or 9), you're just pushing all of the code into later banks and wasting space.

Nobody sent me anything. And I don't run Java unless absolutely required, so sropbox is out.
Luckily I have friends who send me things - that's how I grabbed the compiler. But it took a couple of weeks.

I sent you and Arkhan a link to the files on dropbox as part of our PM'd conversation at the time.

That seemed to be good-enough for Arkhan, and I didn't hear any complaint from you, or a request to have them sent by email instead.

Dropbox doesn't use Java (the programming language), it uses Javascript (aka ECMAscript), which is built into all web browsers. They are totally different technologies.

Now, if you choose to avoid all websites which use Javascript, then good-for-you ... but it would be helpful to know that.

BTW ... you can just install noscript or something like that to gain control over the execution of Javascript in your web browser.

****************

Anyway, I've emailed you the fully-working version of Squirrel (for both the old and new HuC).

It includes the latest change to use SOUND_BANK instead of PSG_BANK.

[OldMan]

Nope, I didn't rebuild the MML because I didn't need to ... there's already a working MML file.

Yes, but it was built for an SCD. You need to re-build it for a CD, which involves specifying a cd-useable bank number.

And you already know that I need you guys to change mml2pce in order to add the "__" to the variable names.

Already in there, with the -p flag.

So ... with your new version of mml2pce, I've built a working CD of squirrel.c, and I can see that "yes", there's a problem when you try to put the sound data in bank 6 ... but everything is happy if you change it to put the sound data in bank 5.

Err ... I'm not seeing any problem with that. The new HuC is a bit more strict about where it puts the trampoline code for banking in the .proc functions.

So, if I understand this right....
It uses the entire last page for the trampoline code?

The big question is why-on-earth put the sound data into bank 6???

Because it was the highest unused bank. That way, we didn't have to keep going back and moving it
everytime we added something.

You should be putting the sound data into bank 4.

And have it over-written when we added new graphics and stuff?
(which is why we picked bank 6, after about the third time it happened...)

By declaring that the sound data starts in bank 6 (or 5, or 9), you're just pushing all of the code into later banks and wasting space.

Understood. But there's no reliable way to know the last-used bank ahead of time, that we have found. Of course, its been a few years since I looked at, and I've learned some things since then, so maybe I'll find a better way.
Keep in mind, this is a test program. Good tests highlight the problem only.

Dropbox doesn't use Java (the programming language), it uses Javascript (aka ECMAscript), which is built into all web browsers. They are totally different technologies.
Now, if you choose to avoid all websites which use Javascript, then good-for-you ... but it would be helpful to know that.

Same basic technology - the website wants to run a program on my computer. Sorry you didn't know.
Yes, I'm paranoid like that.

BTW ... you can just install noscript or something like that to gain control over the execution of Javascript in your web browser.

So i should install and run someone elses (possibly buggy, possibly invasive) program when I can just turn Java and it's variants off? And lose the added bonus of no more forced ads and tons of spam? <sarc>

Also, keep in mind I'm on XP. Does firefox 34 even support plug-ins?

Anyway, I've emailed you the fully-working version of Squirrel (for both the old and new HuC).

I'll pick it up tomorrow. E-mail me the latest compiler, too, when you get a chance, so I can check to see if I've broken anything else.