ggn wrote:So for anyone that cares: I just finished a 2nd pass at the source code, tidying up things and taking care of loose ends. Which in practice means:

a) It's now ready for debugging (so far I've been writing code at blind, so tons of bugs expected!)b) It is most certainly not optimal! For now it's simply mirroring the behaviour of the z80 routine in order to have a reference routine up and runningc) After (a) is done then the player can be reworked into something really optimal. At least that's my guess! Running the code under a debugger will also have the benefit of identifying lots of unneeded code and also enable doing things in a more 68000 friendly way

At least one musician apart from dma-sc expressed interest in it so hopefully this is not an exercise in futility (or at the very worst case the sndh archive will have some new tunes )

btw which debugger are you using

Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend

ggn wrote:So for anyone that cares: I just finished a 2nd pass at the source code, tidying up things and taking care of loose ends. Which in practice means:

a) It's now ready for debugging (so far I've been writing code at blind, so tons of bugs expected!)b) It is most certainly not optimal! For now it's simply mirroring the behaviour of the z80 routine in order to have a reference routine up and runningc) After (a) is done then the player can be reworked into something really optimal. At least that's my guess! Running the code under a debugger will also have the benefit of identifying lots of unneeded code and also enable doing things in a more 68000 friendly way

At least one musician apart from dma-sc expressed interest in it so hopefully this is not an exercise in futility (or at the very worst case the sndh archive will have some new tunes )

btw which debugger are you using

I'm a bugaboo man. For the really awkward cases I fall back to STEem debug.

ggn wrote:So for anyone that cares: I just finished a 2nd pass at the source code, tidying up things and taking care of loose ends. Which in practice means:

a) It's now ready for debugging (so far I've been writing code at blind, so tons of bugs expected!)b) It is most certainly not optimal! For now it's simply mirroring the behaviour of the z80 routine in order to have a reference routine up and runningc) After (a) is done then the player can be reworked into something really optimal. At least that's my guess! Running the code under a debugger will also have the benefit of identifying lots of unneeded code and also enable doing things in a more 68000 friendly way

At least one musician apart from dma-sc expressed interest in it so hopefully this is not an exercise in futility (or at the very worst case the sndh archive will have some new tunes )

btw which debugger are you using

I'm a bugaboo man. For the really awkward cases I fall back to STEem debug.

i don't know anything about ST debuggers, only one i tried is the one in devpac,how does it work do you load your prg files in it, and can it steep thought line?

Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend

No ST assembler I know of recognises this - can we please have two separate lines of dc.w?(I won't even mention here that a dc.w after dc.b is a huge issue as ST assemblers can auto-even after a dc.b! Plus the code that handles this gets really convoluted - I think I will revisit this in more detail once the player is working!)

b) This is probably a minor thing but it would help this debugging stage a lot: when outputting source code there are statements like:

dc.w Main_Subsong0_Track_0

Because of the org being forbidden usually on ST programs (unless you want to assemble something at a fixed address) the above line will get relocated in ram once a program is loaded. Ideally I would want this to be an offset relative to the beginning of the track. For now I get around this by doing a search/replace of these lines with something like

dc.w Main_Subsong0_Track_0-Main_Subsong0

but I think it'd be an easy change to add to the exporter. I realise that in most conditions people will simply export to binary, but like I said it'd help me with debugging for now.

(you can see the vile vim commands for both these on the git repositories)

dc.b 8 : dc.w Main_Subsong0_RegisterBlock_784 + 1 ; Optimization: goto common Block at index 1.No ST assembler I know of recognises this - can we please have two separate lines of dc.w?

Really? What kind of crappy assemblers are you using ? Well, I can add an option in the Source Profile: "Only one instruction per line". This can be added for the next release.

dc.w Main_Subsong0_Track_0-Main_Subsong0but I think it'd be an easy change to add to the exporter. I realise that in most conditions people will simply export to binary, but like I said it'd help me with debugging for now.

Mmmh, so you want EVERY label reference to be relative? Wouldn't it be simpler for the user to set the ORG at 0? It work the same way.

As for a thorough test result, I suggest you convert the songs in the package called "Targhan - Midline Process - Carpet.sks", "Targhan - Midline Process - Molusk.sks" and "Targhan - DemoIzArt - End Part.sks", in the "STarKos" folder (yep, these are songs I made). They are quite complex and long songs. If they work, everything will.

dc.b 8 : dc.w Main_Subsong0_RegisterBlock_784 + 1 ; Optimization: goto common Block at index 1.No ST assembler I know of recognises this - can we please have two separate lines of dc.w?

Really? What kind of crappy assemblers are you using ? Well, I can add an option in the Source Profile: "Only one instruction per line". This can be added for the next release.

Pardner, them are fightin' words - this ain't basic here, this is real men one instruction per line only club! (although at least one assembler has a very powerful command called 'init' that can initialise constants of any size in the same line).

Jokes aside, thanks!

dc.w Main_Subsong0_Track_0-Main_Subsong0but I think it'd be an easy change to add to the exporter. I realise that in most conditions people will simply export to binary, but like I said it'd help me with debugging for now.

Mmmh, so you want EVERY label reference to be relative? Wouldn't it be simpler for the user to set the ORG at 0? It work the same way.[/quote]

A normal ST application is PC relative all the way, so if I include a source file that contains a "org" instruction the assemblers will barf - how can you place absolute and pc-relative code in the same file? I'd have to resort to creating object files and linking them together which is a bother, or create binary files and incbin them, which loses debuggability. Like I said, this is low priority and only applies to source export anyway.

Targhan wrote:As for a thorough test result, I suggest you convert the songs in the package called "Targhan - Midline Process - Carpet.sks", "Targhan - Midline Process - Molusk.sks" and "Targhan - DemoIzArt - End Part.sks", in the "STarKos" folder (yep, these are songs I made). They are quite complex and long songs. If they work, everything will.

Thanks for the tips, I'll be giving them a go.

Also, I just pushed a fix that makes the tune I exported work :.! All sounds ok except the buzztones, something is still wrong there. A bit more debugging required there, but all the same people can grab the repository and compile/run the example .

The player now has been optimised quite a bit, and there's a way to create .sndh files directly. I am working on streamlining tune export with Targhan a bit, hopefully pretty soon it'll be easier. But as it is right now there are instructions on the repository and it is possible!

Sorry I didn't create any recordings yet - there's only so many hours in the day!

Hopefully a few more ST musicians will start using this tracker, it's a very good solution when low CPU usage is mandatory .

And hello from me everyone here at Outline 2018! Since we finished our entries for the party we thought we (me and Grazey) could have a crack at adding SID voices to the replay routine. Guess what - it worked

Here's a sneak preview, the source will be cleaned up and uploaded after the party!

You do not have the required permissions to view the files attached to this post.

Congrats for your "LovelyYM" demo, I really like it. Although I kinda hate sid, what you've done off the player is really interesting. We'll have to discuss about sid one day, though that's going quite difficult to satisfy everyone, since there are so many way of doing a "sid", and it's sooo difficult to do accurately on 8-bits...

As for vocals: it really was a 20 minute hack at the party, Grazey supplied me the code he used for hipsid and I simply piggybanked it to the player. Personally I won't even dare to ask you to add sid support to the tracker. My current view is that it can be enabled on the player directly (per channel) at the programmer/musician's wishes, probably switchable on and off using timing commands from the tracker.

Cool, only twice slower than raw YM and much, much much, more memory-efficient!Do you consider your player finished? If possible, I'd like a version to be integrated to the Arkos Tracker 2 package. Do you think it is a good idea, or do you prefer only having a repository? I like somehow having the AT2 package fully useable "stand-alone", but having to update it whenever you change a comment is quite bothersome .