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.

[TheOldMan]

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

[Bonknuts]

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?

[TheOldMan]

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.

[TheOldMan]

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.

[Bonknuts]

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

[TheOldMan]

Yep, that's the one.

[Bonknuts]

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.

[TheOldMan]

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]

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

-#define NUMMEMB         30
+#define NUMMEMB         128

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

Code: [Select]

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

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

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

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.