The new fork of HuC

[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.  :oops:

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.

[TheOldMan]

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

[TheOldMan]

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

[TheOldMan]

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

[TheOldMan]

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

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.

[TheOldMan]

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

[TheOldMan]

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 Aetherbyte_Squirrel3.zip that I just downloaded (again) from Aetherbyte.

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.

[TheOldMan]

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 Aetherbyte_Squirrel3.zip that I just downloaded (again) from Aetherbyte.

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.

[TheOldMan]

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.