The new fork of HuC

[elmer]

It's moving the wrong address from the stack to the end of an assignment ... it's grabbing the address from one I-CODE too soon.

Now ... *why*??? 

Bug fixed, and the fix is checked-in to github.

There's no new build yet because there's still something else left to fix this weekend.

[OldMan]

Finally got a chance to look at the code for the new HuC, specifically with respect to the IRQ_TIMER/IRQ_VSYNC stuff.

It's only #defined in HuC.h. As far as I can tell, it's not used anywhere.

Any idea why Uli did that? I assume it's for the mod player, but shouldn't that code be more library-like? Not everyone is gonna want the mod player code in every program.
There's also a handful of new #defines there that I'm semi-sure are also gonna cause problems, notably the ADPCM stuff he added...

Can he even access a #define value in assembler? I never could get that to work....

[TurboXray]

What mod player program??? The one that DM made a long time ago and never publicly released the source (which I have, somewhere - but it's kinda useless in its unfinished state). That made it into HuC? Or at least part of it?

[OldMan]

What mod player program???

I'm not sure; I haven't looked into it that much. I'm not even sure there is a mod player, yet.
However, the version I downloaded and set up has tools that work on mod files. Again, not sure
what they do, but they are there.

I assume (and could be wrong) that there is either a mod player in the code, or that one was planned; In either case, I also assume that's why the #defines are there, as support for that.

Note that, like for squirrel, I did a find-in-all-files for IRQ_TIMER and IRQ_VSYNC. The only place they occur are in HuC.h. In addition, I also did a find-in-all on the original HuC files; the defines do not occur there, so they are apparently new.

I'll keep you posted as I look through the code. I'm particularly interested now in what changes were made to the irq handler.

[OldMan]

I'm particularly interested now in what changes were made to the irq handler.

From what I've looked at, at least the timer irq does nothing now (I think). It requires setting up a user irq handler to be useful. That's probably why the mml player doesn't work on the timer.

I'm not even sure there is a mod player, yet.

There is a pair of files (st.c/st.h) that appear to contain the code to play mods (?). Not sure if they get included in the system or not, but they are available for use.
Something called SimpleTracker? That's all I know about it.

[TurboXray]

This?

/* SimpleTracker
   Plays MOD files converted to ST format by mod2mml.
   Copyright (c) 2014, Ulrich Hecht
   All rights reserved.
   See LICENSE for details on use and redistribution. */

[OldMan]

Yep, that's the one.

[TurboXray]

It's not mod files. It says "SimpleTracker" but from the quick look over the code, it's not even a tracker format. I suspect is just commandstring format like mml, maybe with fixed length parameters or some hybrid. From the mention of "mod2mml", I'm guess it's just the raw note data; nothing that specifically attribute to real mod files or anything close to it. But yeah, looks unfinished or super bare bones.

[OldMan]

It's not mod files....

Okay. You would know more about that than me; I only assumed mod files because of the naming.

My point is that he was trying to get a new sound engine in Huc. That's what caused the problems with using the (disassembled) bios code. I think that's a good idea, just a poor way to do it :/

[Arkhan Asylum]

What mod player program??? The one that DM made a long time ago and never publicly released the source (which I have, somewhere - but it's kinda useless in its unfinished state). That made it into HuC? Or at least part of it?

Don't you remember, back when I first showed up to make Insanity, and there was that MOD thing for HuC that would supposedly be "released next week", and never actually happened?

It was either in the topic for #utopiasoft, or on one of the sites.  It was also mentioned verbally a few times.

and then I got tired of waiting, hate trackers anyways, and used a better solution to the problem, lol.

IIRC, there were/are some pretty goony PSG related things floating around in HuC, some of which may be commented out.

[elmer]

There's no new build yet because there's still something else left to fix this weekend.

Catastrophy is now working perfectly (as far as I can tell) with the latest version of HuC. 

The last problem was with PCEAS not handling "BANK(symbol+offset)" properly, which was messing up the sprites in Catastrophy.

That's a common construct in the new HuC, and is a major improvement over the previous code generation.

All in all, with the old HuC compiler, Catastrophy uses 92878 bytes of code, and with the new HuC compiler (using "-msmall -fno-recursive"), Catastrophy uses 57823 bytes of code.

That's a huge improvement! 

The changes are checked into github, and here's the latest Windows build ...

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

It would be nice to get a confirmation that this works (or not) from other HuC users.

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

There's a known issue with Squirrel, where the PSG player needs to be modified to run with the new code.

I've done that for Catastrophy, but it's really up to Aetherbutt to make an "official" release for the changes in the new HuC startup.

I'd recommend just putting the changes to the HuC startup.asm that they've made for the HuCard PSG player into my fork of HuC, and then make them conditional so that people can choose to use it, or not.

The rest of the PSG BIOS player code could stay on the Aetherbutt site as it is now, but at least it would mean that future changes to startup.asm (and there will be some coming up) won't keep on breaking Squirrel.

But that's up to TheOldMan and Arkhan. 

[Sunray]

How do you compile for Windows if you are not using Cygwin?

I can test your latest build but it is currently incompatible with my game due to the struct member limit. Here are a couple of changes I did to in my fork of Ulis HuC that I never pushed. Btw, I'm markusburetorp on Github, I also did some changes to pcxtool which you already integrated.

bump total number of struct members from 30 to 128
src/huc/defs.h

Code Select Expand

-#define NUMMEMB         30
+#define NUMMEMB         128

irq_enable and irq_disable behavior was inverted
include/pce/library.asm

Code Select Expand

_irq_enable:
  txa
+ eor #$ff
  sei
- ora irq_disable
+ and irq_disable
  sta irq_disable
  cli
  rts
 _irq_disable:
  txa
- eor #$ff
  sei
- and irq_disable
+ ora irq_disable
  sta irq_disable
  cli
  rts


[elmer]

Hi Markus, thanks for your work on pcxtool! 

How do you compile for Windows if you are not using Cygwin?

Msys2/mingw64 (the 32-bit "i686" version, and not the 64-bit version).

I use the old-fashioned installation instructions, but apparently there's a new executable installer at ...

http://msys2.github.io/

I can test your latest build but it is currently incompatible with my game due to the struct member limit. Here are a couple of changes I did to in my fork of Ulis HuC that I never pushed.

I've applied your fixes, checked them into github, and updated today's build with the changes.

It's at the same link that I gave in the last post.


<EDIT>

I have a question for you ... do you (or any other user of Uli's new HuC) actually use the new ability to create IRQ or SIRQ handlers in Huc?

That's something that I'd like to remove. It's sort-of-clever, but it's horribly inefficient.

IMHO, regular timed-events are better-handled in game's main loop, leaving the IRQs for *fast* assembly-language code.

[Sunray]

I use the timer interrupt for DDA sound streaming. The way I setup my IRQ handler is super hacky and it would much better if there was a cleaner way of doing this.

This is my initialization code

Code Select Expand

#asm
sei
setvec #2, pce_timer_interrupt
vec_on #2
cli
#endasm

irq_enable(IRQ_TIMER);
timer_set(1);
timer_start();

pce_timer_interrupt defined as follows

Code Select Expand

#asm
...

pce_timer_interrupt:
dda_update 0, _pce_dda0, _pce_dda0+1, _pce_dda0+2, _pce_dda0+4
dda_update 1, _pce_dda1, _pce_dda1+1, _pce_dda1+2, _pce_dda1+4

;// Remap old banks if changed
bbr7 <snd_flags, .return
rmb7 <snd_flags ;// Clear mapped bit
lda _pce_snd_oldbanks ;// a = old lower bank
tam #DATA_BANK
lda _pce_snd_oldbanks+1 ;// a = old upper bank
tam #DATA_BANK+1

.return:
rts
#endasm

I also modified startup.asm in HuC to get my handler up and running

Code Select Expand

timer_user:
  jmp   [timer_jmp]
 timer:
- bbs2 <irq_m,timer_user
  pha
  phx
  phy
+ bbr2 <irq_m,.ack
+ jsr timer_user
+.ack:
  sta   irq_status ; acknowledge interrupt
-.exit: ply
+ ply
  plx
  pla
  rti


As I said, this was just hacked together to get around the unfinished IRQ/timer implementation in HuC.

[Sunray]

I successfully compiled HuC with the msys2 you linked, but I cannot launch the executables outside the msys shell. Missing msys-gcc_s-1.dll and more.

[elmer]

I successfully compiled HuC with the msys2 you linked, but I cannot launch the executables outside the msys shell. Missing msys-gcc_s-1.dll and more.

You didn't make a static build, so it's bringing in a bunch of DLLs.

You can just copy the DLLs from their location in msys2 ... but it'd be better to make a static build so that they're not needed.

You may also be missing a bunch of the static libraries, it depends upon the packages that you've installed in the msys2 environment.

That's why I have my own batch file to automate an installation! 

<EDIT>

These 2 commands will install my base set of msys2 packages ...

 pacman -S --noconfirm --needed base-devel nano
 pacman -S --noconfirm --needed mingw-w64-i686-toolchain

I *may* have needed some other packages for my GCC and Mednafen builds, and they *may* have pulled in something else that's missing on your setup ... but if so, I don't know what.

[Sunray]

Yep, I installed the wrong gcc package (just named "gcc"). Apparently that is based on Cygwin... 

EDIT: Works now and the game runs. I also had to increase "#define NUMTAG 10" to 64.

[TurboXray]

elmer: But.. if you use ZP as a fast stack.. how are we going to use recursion to solve ackermann's function?

[elmer]

I'd recommend programming your new Sharper Image Internet-Connected Back Scratcher to solve the problem, instead.

It's probably got more processing power by itself than every PCE ever made put together! 

[TurboXray]

Yeah.. well... yeah.. but.. so.. well.. 3 PCE's networked together with three monitors to do a faithful port of Darius!

[elmer]

Yeah.. well... yeah.. but.. so.. well.. 3 PCE's networked together with three monitors to do a faithful port of Darius!

Well ... since it's you asking, I probably should have just said  ... "You can write it in assembly language with a couple of simple macros". 

It's best (IMHO) to tailor HuC to the things that the 6502/6280 does well ... and a small zero-page stack together with a reasonable use of "global/static" variables, and continued upgrades to the libraries, could allow us to get to that "only 2-4 times slower than hand assembly" goal that I'd love to see.

BTW ... it's going to be easy to modify Mednafen so that it will trap and report a stack-overflow condition with the small stack. That, together with a good error message about using "static variables" or the "-fno-recursive" option, should avoid the annoyances of the random crashes that a small stack architecture can lead to.

The next big question is going to be how to get a decent (and legal) sound driver.

As DK & Gredler have talked about with Catastrophy, it's hard to get someone on this side of the planet interested in MML.

A MOD player of some kind is going to be needed ... preferably with some sample playback, and/or use of the ADPCM hardware. I know that Arkhan loathes the format ... but musicians that either love or tolerate it are *much* easier to find on this side of the pond.

It's a pity that the Deflemask internal audio format isn't documented anywhere.

Do you know of any other good, popular MOD players? 

[OldMan]

The next big question is going to be how to get a decent (and legal) sound driver.

I'm voting for a stock interface to the sound driver from system code. Kind of "these are the routines you supply, and this is when they are called". That would allow us to have multiple drivers (presumably in seperate directories in pce/include), that could be turned on/off via #defines in the user code. [Which would use sound.inc to include the correct files]

Do you know of any other good, popular MOD players?

The place to start with that is Bonknauts. He did a -lot- of work on various sound routines.
After that, -if- we straighten out the system files, it should be (relatively) easy to install user supplied drivers, provided they work in a 'standardized' way.

[elmer]

I'm voting for a stock interface to the sound driver from system code. Kind of "these are the routines you supply, and this is when they are called". That would allow us to have multiple drivers (presumably in seperate directories in pce/include), that could be turned on/off via #defines in the user code. [Which would use sound.inc to include the correct files]

I'd prefer to avoid the overhead of a JSR if possible (especially in a TIMER interrupt) ... but it would certainly be possible to have a 2-level structure in startup.asm ...

Level 1 would just invoke different #include files for in-the-middle-of-vsync, in-the-middle-of-timer, and other-stuff-in-the-system-bank.

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.

Level 2 would be a #define to entirely remove the vsync and timer handling code from system.asm and let you define your own, in which you could do whatever you like.

I suspect that we don't need a more complex interface than just providing those two options to any programmer.

The place to start with that is Bonknauts. He did a -lot- of work on various sound routines.
After that, -if- we straighten out the system files, it should be (relatively) easy to install user supplied drivers, provided they work in a 'standardized' way.

I'm hoping that he'll have an opinion to share! 

In the meantime ... it looks like the Deflemask formats *are* somewhat documented ...

http://www.deflemask.com/DMF_SPECS.txt
http://www.deflemask.com/DMP_SPECS.txt

That's good/bad/annoying/hopeful. 

[TurboXray]

Sound drivers.. that's messy business

 I think by MOD, you're probably meaning "tracker" or tracked format? And not specifically long sample frequency-scaling MOD specific?


I wasn't going to release these yet, but whatever:

This is the sample sound driver. It's a real "MOD" sound driver. As in, it resamples the frequency on the fly to play whatever long samples on the PCE MOD style. It has some requirements for video setup (263 scanline mode recommended), but I have a future version that eases that timing requirement by a lot. They'll play identical. Mean while, you can take a look at this mess...
pcedev.net/HuPCMDriver/HuPCMDriver1.2.1.zip

 XM is sooo much a better fit than the traditional MOD format. Even if you just used PCE legal 32byte waveforms.. XM format is superior. I was able to write this super basic XM player for the PCE in 4 hours. The TXM format is just the XM file without its sample or envelope data. But other than that, it's XM song data to the tee.
pcedev.net/HuPCMDriver/HuPCMDriver_Demo_HuXMPlay.zip

In order to make the wave files repeatable, I have this utility that will convert 8bit wave files to 5bit special format (has terminator marker in the sample data either for end of sample or for looping. The converter allows creating loop points).
pcedev.net/HuPCMDriver/wave2six_ver1.1.2.zip


 It wasn't really meant for HuC. Matter of fact, I didn't think anyone would even use it (I use it, though).

[TurboXray]

In the HuPCMDriver, I'll be moving the ProcessPCM code (macro) inside the sound driver so timing will never be an issue. Simple fix, just didn't get around to it.

 Deflemask is a really good format to go with. It supports some nice PCE only effects. Something XM and other generic trackers don't.

 As far as Deflemask. Just use the cooked output. Yeah, it's big - but LZSS compress the shit out of the main data, and just slowly decompress to a small window and execute the updates as it goes along. Samples will always be samples. So nothing to lose there.

[Arkhan Asylum]

Squirrel can be fudged into using samples. 

Though, I really think everyone who doesn't like MML simply misunderstands it.

You don't write the songs in MML.   That's 100% stupid.   You write them elsewhere and simply CONVERT the songs to MML.   If you understand half an ounce of sheet music (anyone who claims they are a musician should be able to comprehend even the most basic bits), using MML is easy.

Especially with piano-roll software like 3MLE that visually shows the crap.

I think people need to get over it.  Everyone waves their dicks around about all this technical crap, and is stopped up by something that can be called from BASIC with a PLAY command?

Please., lol

[OldMan]

I think by MOD, you're probably meaning "tracker" or tracked format?

To me, MOD means some program that looks sorta like a piano roll, and makes sound.
I don't really understand the difference between trackers and mods, and probably never will (I don't care that much how it makes sound. Just that it does)

Just out of curiosity, would we need an HSync hook? I can foresee that being a problem; it already can be in the bios player, if you are doing scroll areas.

[TurboXray]

Squirrel can be fudged into using samples. 

Doesn't Squirrel use the sys card PSG player? AFIAK, it doesn't support samples. The two games that use it and ADPCM at the same time, use some hack-y audio driver on the side the peeks at the player, and syncs itself with it as it runs a separate data stream/channel for manipulating ADPCM stuffs. Other games just straight out bypass the sys card player all together. What do you guys do for sample support?

[TurboXray]

Just out of curiosity, would we need an HSync hook? I can foresee that being a problem; it already can be in the bios player, if you are doing scroll areas.

No Hsync. It's all timer based. Vblank is used to resync the timer every frame (reset the TIMER counter unit). And the Timer IRQ code immediately re-enables interrupts so that Hsync always has priority. That was a big thing I wanted in the player. The player also has a flag so that it can't be called more than once when interrupts are re-enabled during its initial call. That keeps things from crashing into each other. It might delay the sample(s), but "jitter" on these old systems is pretty much unavoidable. And it's not like it'll be Genesis bad - lol. So yeah, it plays nice with Hsync interrupts.


 MOD.. eh. In the context of computers, it just means tracked music. But in the context of consoles, it's about playing wave files at different frequencies. Basically what the PCE does with its little 32byte buffer each channel, but these are biiiiggg samples. It's why the Amiga and the PCE, while both technically the same in application - sound nothing a like. They both use samples. They both use the exact same period system and same period values for notes. But the PCE's sample memory is so gimped, that it sounds more like PSG than anything from "sample-based synthesis" (SNES, AMIGA, TRACKED music for 90's PCs, etc). MOD is basically sample-based synthesis. Lots of consoles in the 32bit generation (PS1, Saturn, Jag), and later generations (PS2, etc) use this but with better refinement.

[Arkhan Asylum]

Squirrel can be fudged into using samples. 

Doesn't Squirrel use the sys card PSG player? AFIAK, it doesn't support samples. The two games that use it and ADPCM at the same time, use some hack-y audio driver on the side the peeks at the player, and syncs itself with it as it runs a separate data stream/channel for manipulating ADPCM stuffs. Other games just straight out bypass the sys card player all together. What do you guys do for sample support?

The HuCard version sure as shit doesn't use the system card player, since the system card doesn't exist.

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.

It works, but isn't exactly ideal.   Especially for literally every other human that might use it besides me, since MML hurts everyone or whatever.

I decided I liked my deep kickdrum that is currently in use more anyways.   Some of the greatest PCE games don't even use samples, and rely on noise-drums, so I also stopped caring. 

[TurboXray]

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.

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?

[elmer]

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.

[elmer]

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

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.

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.

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.

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.   


PS: I am starting a new thread about MML stuff here.  I hope it's exciting.

[Arkhan Asylum]

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:

fuckin trackers

[TurboXray]

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

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.

[elmer]

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.

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

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

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.

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.

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

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

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

[DildoKKKobold]

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.

[Arkhan Asylum]

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.

[OldMan]

Back on topic. Avoiding the arguement.

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

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

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?

[elmer]

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?

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.

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! 

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.

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.

[OldMan]

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.

[Arkhan Asylum]

Yeah, it's good that some people with more curiosity and time to mess with it have proved that it can at least go somewhere.   We had toyed around with the idea of rewriting stuff at one point, but I personally am more wrapped up in the game writing than the tool writing, because... the tool writing is sometimes kind of boring, and working around it in assembly turned out to not hurt that bad.

How far away is a 6502 SDCC?  I could've sworn there was one.   

[elmer]

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.

I've sent you updated versions of HuC and Squirrel that will get you back the sound again.

I've also sent the changes to Squirrel to Arkhan and TheOldMan so that they can decide if they want to change anything before they release a new version.

In the meantime, the changes to HuC are checked into github, and here's the latest build ...

https://www.dropbox.com/s/abch2ar3krr4s9u/huc-2016-11-22.zip?dl=0

This build still won't work with the old version of Squirrel's HuCard player, but it'll work with the System Card, or if someone uses a different sound driver, or no sound driver at all.

How far away is a 6502 SDCC?  I could've sworn there was one.

At least a year. Progress has stalled (at least on my side).

[elmer]

I'm looking at the HuC graphics library function "fade_color()".

Has anyone tried to use this?

The code looks like it has a major bug in it, and I'm tempted to just remove it if people can't confirm that it works.

[TurboXray]

There's another function.. load something or other that has a bug in it. Rov' would probaby remember (loadbat or something like that?). I just remember that huc users were avoiding it, using loadvram instead (I think). Maybe someone else can confirm.

[OldRover]

I think you might be referring to load_sprites(), which wasn't buggy per se, it just wasn't documented very well so some people didn't quite understand how to use it. Originally, Bt was using load_sprites() for sprites that were smaller than 32x64 and it was causing major slowdown in his run-n-gun game. I just told him that it's a function intended to load multiple large sprite blocks and that he should use load_vram() for loading sprites that are smaller. He made the change and the performance of his game returned to normal. This is the only thing I can think of along these lines.