Author Topic: The new fork of HuC  (Read 14107 times)

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: The new fork of HuC
« Reply #180 on: November 20, 2016, 06:04:30 PM »
At one point years ago, I fudged a drum sample.  if you get a short enough wave, you can break it into a few 32byte segments as custom waveforms, and then switch them.

 If you're talking about doing that at 60hz, that's only 1.9khz output. I can see that working for instruments with changing timbre, but that's not really what I meant by sample playback.

  And you'd have a loud noise floor at 60hz (beating noise) because of the "pops" on the channel when you turn it on and off - unless you have an SGX or one of the core grafx systems that used the revision 6280a that doesn't have this problem. That DAC pop is annoying. The only way to cancel out the popping for something like that (on the non 6280a cpu's), is to use two channels. You alternate between updating two channels. The turning off of one, cancels out the turning on of the other - since the pop direction is in relation to the volume change on the channel. But you still need to update faster than 60hz to get to the original PCE 7khz timer method - something like 218hz updates.

Quote
The HuCard version sure as shit doesn't use the system card player, since the system card doesn't exist.
Ok. So if you added sample support for the hucard version - then what? Just not have it for the CD games?

« Last Edit: November 20, 2016, 06:06:22 PM by Bonknuts »

elmer

  • Hero Member
  • *****
  • Posts: 2153
Re: The new fork of HuC
« Reply #181 on: November 20, 2016, 06:15:52 PM »
The HuCard version sure as shit doesn't use the system card player, since the system card doesn't exist.

This is one of the areas where you and I have been butting heads for a while.

We talk a different language.

Sorry ... but AFAIK (and with increasing certainty since I've recently compared the source code) the Squirrel HuCard audio player is a dissassembled-then-reassembled version of the Sytem Card audio player, with minor changes.

That's what TheOldMan has said (a few times, now), and that's what it *looks* like to me.

But you need to understand that dissassembly-into-source does *not* give you ownership rights over the code.

There's nothing horribly *wrong* with doing it ... and it's a sensible thing to do in order to keep compatibility with the System Card player.

But, if true, then it does mean that you don't *own* the copyright to Squirrel's audio playback code ... just to your MIDI-to-MML converter utility that you ship in the Squirrel package.

Again ... there's nothing horribly wrong with that, and your tool that converts MIDI to the System Card MML format is a boon to the community.

But ... please be honest and attribute the creators as appropriate.

From what I can see, TheOldMan has been very careful to do that with the playback code in the Squirrel package.

Please consider following his example rather than making statements that attempt to suggest that you're not using the System Card player. That may be true from a literal standpoint, but it's not true, from what I see,  from a copyright/legal/honest standpoint.
« Last Edit: November 20, 2016, 07:08:44 PM by elmer »

elmer

  • Hero Member
  • *****
  • Posts: 2153
Re: The new fork of HuC
« Reply #182 on: November 20, 2016, 07:02:36 PM »
But ... please be honest and attribute the creators as appropriate.

And, as a follow-up ... a lot of my recent posts have been about fixing bugs in Uli's improvements to HuC.

I want to be very clear here ... the incredible amount of hard work that he put into improving HuC is *why* I've spent a lot of my time over the last week-or-so into seeing if I can move things forward a little further and fix some of the bugs that were introduced.

AFAIK, HuC/PCEAS is the creation of David Michel, David Shadoff, and Oliver Jolly, with major contributions by Uli, and other improvements by Bonkunts, Artemio Urbina, and Markus Buretorp.

I'm still just playing and effing around at the edges of their project.

That may become more-significant if I can get the zero-page stack and register rearrangement working ... but it's still going to be a project based mostly upon the work of other people.

I've spent most of my professional life writing software ... an appreciation for these kind of distinctions comes with the territory.

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: The new fork of HuC
« Reply #183 on: November 20, 2016, 08:26:31 PM »
This is one of the areas where you and I have been butting heads for a while.
We have?  I can't say I recall that.

Quote
We talk a different language.

Sorry ... but AFAIK (and with increasing certainty since I've recently compared the source code) the Squirrel HuCard audio player is a dissassembled-then-reassembled version of the Sytem Card audio player, with minor changes.

That's what TheOldMan has said (a few times, now), and that's what it *looks* like to me.

But you need to understand that dissassembly-into-source does *not* give you ownership rights over the code.

Please consider following his example rather than making statements that attempt to suggest that you're not using the System Card player. That may be true from a literal standpoint, but it's not true, from what I see,  from a copyright/legal/honest standpoint.
I understand that this is how it works, and I am fully aware of the distinction.  I kinda do this thing for a living, you know.   We even have to go through the legal department all the time when doing things.


I am not trying to state otherwise.   You just misunderstand me.  Or we're all misunderstanding each other slightly.

When I hear "system card player", I assume "system card" or "IFU required", which isn't true in this case now.   

I'm talking strictly from a hardware-required standpoint.   System card / PSG BIOS to me implies you need a system card/CD dock/whatever.   That is what *I* mean when I say it's not the same thing.

So when Tom mentions the system card player, I assume he too is talking about when you have the CD hardware/etc. present.  He even mentioned ADPCM, which I assumed was the ADPCM RAM on the CD hardware.   You can't use that if you don't have the CD dock, because it's not there, lol.


Quote
But, if true, then it does mean that you don't *own* the copyright to Squirrel's audio playback code ... just to your MIDI-to-MML converter utility that you ship in the Squirrel package.

Again ... there's nothing horribly wrong with that, and your tool that converts MIDI to the System Card MML format is a boon to the community.

But ... please be honest and attribute the creators as appropriate.

I am being honest.  As I said, you're just misunderstanding me.   I am talking about from a usability/requirements standpoint.

We have already stated on here, somewhere,  probably repeatedly awhile ago, that it's simply recreated for HuCard so you can use it without having to make a CD game.  I think that topic came up before you came around, actually.  I've even stated this verbally to people who've asked at conventions.  I don't know if Spenoza remembers, but I definitely told him once.  Maybe Zeta too.

But, since it no longer requires the System card or CD hardware, it's not THAT one in terms of usability.   We moved it.    It wasn't straightforward, or easy, but we moved it.  It's clearly the same thing though, since it accepts the exact same format.   It was all created from... disassembly, develo book, Hu7 CD book, an oscilloscope, OldMan's excessive free time and curiosity....

This was not done to imply that we created some brand new player.  It was done so when people make goobery little games like Reflectron or Cabbage's adventure game (that won an award IIRC), they aren't required to distribute pain-in-the-ass ISO images of them, which are then another pain-in-the-ass just to fire up in an emulator or whatever.   

You can't jam em on a flash cart either.    That was the driving force behind making the PSG player exist outside of the CD hardware.    I don't recall us ever trying to take credit for any of that really outside of recreating and getting it to work.

That is also why Squirrel's manual's main focus is explaining MML, and how to make sounds come out, as opposed to rambling about the player stuff.  Squirrel isn't really the player crap.   Squirrel is literally the MML compiler.  It existed *before* the HuCard version of the player.   That's what was used for Insanity.   

There was no HuCard player yet, but there was Squirrel.   

The player crap is all tucked away and ignored because you are supposed to pretend it's still "built in".  Nobody should have to look at, or touch any of it.

I'm not trying to pretend or be dishonest about anything.  I am just saying, it's "not the system card one", because it doesn't require it anymore.   It's been extracted so you don't need a System Card anymore.   The big difference is that now, since the code is there and touchable, one could bastardize the flying shit out of it and make it no longer operate like the CD BIOS one, which could get hilarious and interesting.

The only ownership we really can claim is that "we moved it" so it's more useful to people.   

The MML compiler is the important part anyways, because the player is 100% useless without it.   

and most of this is a moot point since everyone's afraid of MML, lol.    I just find it comical that people making games for 30 year old game consoles don't want to deal with it, but people playing a goofy free MMO called Mabinogi (read: 15 year old kids) are completely OK with using it to make songs for their characters to play in-game.   

Kiiiiiiiinda goofy, I'd say.

Now, I think the big mixup comes from when you'd asked about tweaking squirrel to redistribute awhile back.

Maybe I/we misunderstood what you were asking with regards to that.   We don't own any of that code, technically.  All that was ever asked for if Squirrel as a whole is used is that you credit us, and if physical copies are made, mail us a copy.   That's pretty common for these scenes.  That's exactly how the licensing agreement is for the player I am using for MSX that my friend wrote.

We won't share the source for the compiler for Squirrel, but, we're already sharing the player code. 

I guess it's OK to redistribute that and credit as such, noting whatever changes are made and by who to get it fudged into working again. 

But, then we get into whatever license is used for HuC's distribution.   Is it actually OK to distribute the player code around in that, or do we get into that weird dicey territory?   I'm not sure.  I'm also not sure if, really, Hudson/NEC would come down on the whopping what, 6 people who would be partaking?  lol.


At one point years ago, I fudged a drum sample.  if you get a short enough wave, you can break it into a few 32byte segments as custom waveforms, and then switch them.

 If you're talking about doing that at 60hz, that's only 1.9khz output. I can see that working for instruments with changing timbre, but that's not really what I meant by sample playback.

  And you'd have a loud noise floor at 60hz (beating noise) because of the "pops" on the channel when you turn it on and off - unless you have an SGX or one of the core grafx systems that used the revision 6280a that doesn't have this problem. That DAC pop is annoying. The only way to cancel out the popping for something like that (on the non 6280a cpu's), is to use two channels. You alternate between updating two channels. The turning off of one, cancels out the turning on of the other - since the pop direction is in relation to the volume change on the channel. But you still need to update faster than 60hz to get to the original PCE 7khz timer method - something like 218hz updates.

Quote
The HuCard version sure as shit doesn't use the system card player, since the system card doesn't exist.
Ok. So if you added sample support for the hucard version - then what? Just not have it for the CD games?


I am talking about doing it with the regular waveform playback by bleeding notes together while changing the wave in use. 

Not by enabling the actual sample mode.  You don't get the same sonic capabilities as using the real sample playback, but you can still fudge some sounds.   You won't really get that AirZonk dance beat "yeah *bang* yeah *bang*" 90s dance beat rap jam drum crap out of it, lol.

and yes, if sample playback were to be fudged into the HuCard player, it would only exist for HuCard projects, because we can't really modify the system card....

..... yet.    8)


PS: I am starting a new thread about MML stuff here.  I hope it's exciting.
[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: The new fork of HuC
« Reply #184 on: November 20, 2016, 08:27:26 PM »
Holy shit that post was long ^^

edit:



This was pre-HuCard-Player-Ever-Existing footage of Squirrel.   note the description, lol.

Here's another one:



f*ckin trackers
« Last Edit: November 20, 2016, 08:38:16 PM by Arkhan »
[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: The new fork of HuC
« Reply #185 on: November 21, 2016, 02:37:44 AM »
elmer: You might want to disregard my post with the driver, code, and such. The driver is just that - software driver that emulates a hardware interface for something the PCE can't normally. It's NOT a music engine, or something that specifically aid in music generation (like the PSG music player on the system card, or countless other music drivers). The HuXMPlayer is not something I'm going to finish either. That nothing more than a simple "music engine" to demonstrate the "driver". Nothing more.

 Lol arkhan. You're all how and bothered now. I'll reply over at your new thread.

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: The new fork of HuC
« Reply #186 on: November 21, 2016, 04:47:23 AM »
Lol arkhan. You're all how and bothered now. I'll reply over at your new thread.

Nah, I'm not hot and bothered, lol

More like, I bought 30lbs of candy corn because it was on sale, and ate like 3lbs of it in one sitting. 

I think we've all just slightly misunderstood each other's word usage, and Elmer ended up thinking that I'm claiming we wrote some brand new, mind blowing player, lol

the MML thread was just made to break that discussion out because it's not HuC relevant and will just end up clogging this thread up.
[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

elmer

  • Hero Member
  • *****
  • Posts: 2153
Re: The new fork of HuC
« Reply #187 on: November 21, 2016, 05:01:08 AM »
I am not trying to state otherwise.   You just misunderstand me.  Or we're all misunderstanding each other slightly.

When I hear "system card player", I assume "system card" or "IFU required", which isn't true in this case now.

Yep, it's mostly just that we have different internal understandings of the precise connotations of what is meant by "System Card Player".

So you're hearing that phrase as "requires a System Card", where as I hear it as "the same software that is included in the System Card".

That comes from my having to sign long and scary contracts with folks that have big legal departments, and who don't want to get sued by a competitor for copyright infringement.


Quote
The MML compiler is the important part anyways, because the player is 100% useless without it.

Absolutely ... your work on that is/was marvelous!  :D


Quote
We have already stated on here, somewhere,  probably repeatedly awhile ago, that it's simply recreated for HuCard so you can use it without having to make a CD game.

Quote
But, then we get into whatever license is used for HuC's distribution.   Is it actually OK to distribute the player code around in that, or do we get into that weird dicey territory?   I'm not sure.  I'm also not sure if, really, Hudson/NEC would come down on the whopping what, 6 people who would be partaking?  lol.

Legally ... no. And as a professional in the software industry, I'm really surprised that you have to ask.

It's Hudson's code ... which makes it Konami's code, now.

Nobody has a right to distribute it without a license from Konami ... and neither did you, if you included it in Atlantean.

Practically speaking ... if Konami can't be bothered to sue Tobias for wholesale duplication of "Castlevania: Rondo of Blood", and now "Sapphire" again ... then they're not going to be bothered to come after anyone.

But some folks don't want to risk their personal reputation, and potential blowback from employers, by using unlicensed "stolen" code.


Quote
Now, I think the big mixup comes from when you'd asked about tweaking squirrel to redistribute awhile back.

Yes, I was under the impression that Aetherbyte had written its own playback code that was compatible with the System Card player.

That would have made it legal to use/license.

But that's not the case ... so it isn't.


Quote
Maybe I/we misunderstood what you were asking with regards to that.   We don't own any of that code, technically.  All that was ever asked for if Squirrel as a whole is used is that you credit us, and if physical copies are made, mail us a copy.   That's pretty common for these scenes.  That's exactly how the licensing agreement is for the player I am using for MSX that my friend wrote.

We won't share the source for the compiler for Squirrel, but, we're already sharing the player code. 

I guess it's OK to redistribute that and credit as such, noting whatever changes are made and by who to get it fudged into working again.

<sigh>

You don't seem to get it .. unlike your friend, who apparently wrote his/her own playback code, and therefore has legal and moral rights to it, and can license it under whatever terms they like .. you actually have almost no rights over the playback code in the Squirrel distribution.

It's a derivative-work of someone else's copyrighted code.

The only ownership rights that you have are to the excellent comments and explanations that TheOldMan has put into the source code.

All of those could be stripped out, and the label names changed, and what would be left would be 100% functional source code that you'd have no rights over.

But it would be both rude to do that, and pointless ... since whoever did that wouldn't have any rights to it, either!

It's all a bit of a mess for people wanting to develop for the HuCard format.  :(

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: The new fork of HuC
« Reply #188 on: November 21, 2016, 05:14:12 AM »
Oh.  I get it.

It's just, when I say "ok to redistribute", I'm speaking more loosely... to the tune of what you've already pointed out that Konami doesn't give a flying f*ck, and probably doesn't even have anyone on their staff that would understand any of the crap going on with the PCE right now.

We're talking about crap for a 30 year old console, from a company who is pulling out of the console industry, and literally said on Facebook "oh, hey! cool! You pirated Dracula X and made a boxed set!  We want copies too!".   They were handed copyright infringement, and said "neat! give us copies!"

All of the games any of us make are unlicensed. 

Also, I could be wrong, isn't some of the stuff in MagicKit derived from the actual development kits?   I don't think anyone was licensed to use that, either.

The whole thing's a bit goony, because of the target platform and such. 

Hence me speaking a bit more loosely than you'd see me doing when we're talking about current commercial/professional software.
[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

DarkKobold

  • Hero Member
  • *****
  • Posts: 1200
Re: The new fork of HuC
« Reply #189 on: November 21, 2016, 05:26:53 AM »
So, elmer, you said "Squirrel is working" but Catastrophy has been mute since the upgrade. I'm not sure if I fudged up the code, or if its a compiler issue.

Squirrel has worked fine for us, aside from the lack of any musical talent on our team of 2.
Hey, you.

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: The new fork of HuC
« Reply #190 on: November 21, 2016, 05:32:38 AM »
So, elmer, you said "Squirrel is working" but Catastrophy has been mute since the upgrade. I'm not sure if I fudged up the code, or if its a compiler issue.

Squirrel has worked fine for us, aside from the lack of any musical talent on our team of 2.

how are you calling PSGInit (or is it PSGOn, I don't remember.)

The one where you pass in what kind of timer.  I think Elmer only got the VSYNC one to work, so if you have it on something else, it might just be doing diddlydick.

[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

TheOldMan

  • Hero Member
  • *****
  • Posts: 958
Re: The new fork of HuC
« Reply #191 on: November 21, 2016, 07:38:19 AM »
Back on topic. Avoiding the arguement.

Quote
I'd prefer to avoid the overhead of a JSR if possible (especially in a TIMER interrupt)
I understand, but that's not -quite- what I was thinking...
My thoughts were more "We need to call the user routine from an irq...If we used a standard macro name....Wonder if that would work?"

Quote
If those were something like "sound/vsync.asm", "sound/timer/asm", and "sound/system.asm", then you'd just change your PCE_INCLUDE environment variable to include whichever driver you wanted.

I was actually thinking sound.inc would be an index of the available drivers, with a protected include for each one. Then in the main program file, you would #define which driver you wanted, which would enable the main include for the driver.
You wouldn't have to change anything other that the #define to change drivers (theoretically). And, if you didn't want sound at all, you could comment out/remove the #define from the main program.
When you wanted to choose a sound engine, you could see whats available by looking at sound.inc.

........................
Just an idle question: Is it possible to replace the 'new' system stuff with the 'old' Huc stuff, and still have the compiler generate a working executable? Or have enough things in the compiler changed that that's no longer feasable?

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: The new fork of HuC
« Reply #192 on: November 21, 2016, 08:00:03 AM »
I was actually thinking sound.inc would be an index of the available drivers, with a protected include for each one. Then in the main program file, you would #define which driver you wanted, which would enable the main include for the driver.
You wouldn't have to change anything other that the #define to change drivers (theoretically). And, if you didn't want sound at all, you could comment out/remove the #define from the main program.
When you wanted to choose a sound engine, you could see whats available by looking at sound.inc.

This would be good.


I have another question? 

Maybe this came up before.  Why not just port the HuC libs to SDCC or something, and then throw our hands up and walk away?

Is this all for curiosity's sake, or because we think that doing it this way will produce better, more PCE specific code, or something?
[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

elmer

  • Hero Member
  • *****
  • Posts: 2153
Re: The new fork of HuC
« Reply #193 on: November 21, 2016, 09:00:43 AM »
I understand, but that's not -quite- what I was thinking...
My thoughts were more "We need to call the user routine from an irq...If we used a standard macro name....Wonder if that would work?"

That could work. The question is ... where would the macros be defined?


Quote
I was actually thinking sound.inc would be an index of the available drivers, with a protected include for each one.

Where does that "sound.inc" come from, and who maintains it?

It's best to do something based upon the order of include paths, IMHO, so that people don't need to mess with the compiler or driver, or dump files into their project directory in order to change things.


Quote
Then in the main program file, you would #define which driver you wanted, which would enable the main include for the driver.
You wouldn't have to change anything other that the #define to change drivers (theoretically).

Unfortunately, theory and practice are at odds right now.

HuC doesn't seem to pass the #defines on to PCEAS, and it includes startup.asm before processing anything in you main C file anyway.

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

Hmmmm ... OK, with a bit more thought, that could work out quite well.

You'd just have a "sound.inc" as huc/include/pce/sound.inc, and have it define some empty macros.

Then you'd just place your sound-driver include path before the HuC include path, and put a "pce/sound.inc" in there, and the compiler would find the driver's one first.

Exactly the same as you're doing with startup.asm now, but it would allow the changes to be localized to a few macros instead of replacing the entire startup.asm file.

That sounds good to me!  :D


Just an idle question: Is it possible to replace the 'new' system stuff with the 'old' Huc stuff, and still have the compiler generate a working executable? Or have enough things in the compiler changed that that's no longer feasable?

If it works now, then it won't for much longer.

It's never a good idea to mix things from different distributions ... just pick the one that you want to work with.

We're basically at the point where Uli's version of HuC is fully working, and is backwards-compatible with old-HuC source code.

What would be the advantage in mixing things, or in going back to the older compiler?


Maybe this came up before.  Why not just port the HuC libs to SDCC or something, and then throw our hands up and walk away?

Mainly because the 6502 port of SDCC doesn't exist yet.

I spent the summer working on the Xanadu games, and not helping with SDCC, so now the main developer is busy again.

I suspect that further development won't happen until next summer.


Quote
Is this all for curiosity's sake, or because we think that doing it this way will produce better, more PCE specific code, or something?

Curiosity, and because HuC is a relatively-easy project to modify.

Too much of CC65's code-generation has been moved into the compiler itself. It's too hard to easily modify it.

Uli has shown that HuC can still be substantially improved, with only modest effort.

I wanted to see if the register-rearrangement would be possible in practice, and if the existing HuC libraries did things that would show it to be a bad idea.

They've actually shown it to be a good idea (IMHO).

Uli's addition of the "-msmall" and "-fno-recursive" flags just follow how people use HuC in practice, and how folks avoid anything to do with the stack.

So making the stack even smaller isn't going to cause problems, and just brings benefits.

FYI ... the last time that we talked, the C stack in SDCC was going to be put onto the hardware-stack ... so it would still be limited to 256 bytes.

BTW ... making stack access "abs,x" instead of "zp,x" makes it all a little larger, and slower, and loses you some of the instructions that only work on zero-page locations.

It's not *horrible*, but I was curious about what the zero-page stack would look like.
« Last Edit: November 21, 2016, 09:12:57 AM by elmer »

TheOldMan

  • Hero Member
  • *****
  • Posts: 958
Re: The new fork of HuC
« Reply #194 on: November 21, 2016, 09:06:06 AM »
Quote
Why not just port the HuC libs to SDCC or something, and then throw our hands up and walk away?

My goal is to split things up, so you only include the stuff you actually use. If you don't need scrolling areas, you don't include that code; if you do need them, you include them. If you don't need the system font, don't include it. Things like that.

I'm finally getting comfortable with HuC, and the stuff it uses. I have no desire to learn a new compiler setup, unless its something I write and am initimately familiar with. I would also like to be able to move functions, etc between compilers/assemblers/etc. I understand there would have to be changes made to do that. The basic code, however, -should- be moveable.

In theory, this would allow groups to set up a project, using what they are comfortable with, and the code could be re-built using whatever compiler/assembler/etc.