Arkos AKG player source code problem (out (c),0)

[Joseman]

Hi

I'm trying to compile the source code of the AKG player from Arkos.

It seems that with rasm compiles. But if i use Disark to generate Winape source code. there are several out (c),0.

If i look to the original source code this lines are there too (see the image).

What is the correct way to make source code compatible with winape? maybe some parameter?

Thankyou!

[Jean-Marie]

It's a known bug from WinAPE assembler. Use this instead :
DW &71ED ;; *OUT (C),0

[roudoudou]

not a bug but unsupported opcode, you must use proper dizark options to produce DEFB => --undocumentedOpcodesToBytes

[Joseman]

At last!! it's working!!

thankyou for the hints!!

[Targhan]

Wow, Roudoudou beat me at it .
Maybe an evolution do to, then... The Winape profile should set this flag by itself. Thanks .

[Prodatron]

The Winape profile should set this flag by itself. Thanks .

It already does.
At least the Disark (great tool btw!) which I am using is producing:...

    db 237
    db 113

when using the "--sourceProfile winape" option.
I wonder if Joseman used another profile?

[Targhan]

It already does.

I admit I didn't check, but I was pretty sure I had done things right, unless proven wrong . Well, let's wait for @Joseman's answer...

[Joseman]

Hi

Thanks for the answers!

It was my first attempt to make something with music on CPC. I have no idea about trackers or players.

Some history:

I was reading and documenting the disassemble of Ninja Gaiden Port for ZX.

I reach to the point it was decompressing some "vortex" files and after read some information I downloaded the Vortex 2 tracker,  then I discovered that the files were PT3 format.

Some webpages later i reach Arkos player (that i did know about it, but no experience with it), but no PT3 support.

Doing some investigation i read that PT3 was not allowed but VT2 it was.

Converted PT3 to VT2 and loaded on Arkos Tracker. Generated the asm files with it.

Then i looked to the asm players and i choose PlayerAkg.

Tried to compile it with winape and then the party started.

More research, a tool called Disark. I compiled the source code with RASM and then tried to make the source code compatible with winape using Disark. (I assume that is not possible to convert directly asm to asm?)

and here is where the out (c),0 started to show!

I read the -h help, use hex numbers... use sym file...

and when i tried the symbolprofile option it didnt exist, or so disark was saying.

then i came to this post

when i read the Targhan and Prodatron posts, I tried again...

and then i realised one little thing... the options are case sensitive!!! this is why Disark was displaying that the option didn't exist!

I tried now with the uper case letters correctly, and yes, it works like you say!!

It was my fault.

At this point only 2 little question:

I suposse that compiling with RASM or with winape makes no different bin code?

any advise with the player i must use? AKG player? Player lightweight? another player?

thankyou for all guys!

Targhan I don't know much about trackers or players, but I can see a hard work here with the players and tracker. Good work without a doubt! Only reading a little the player code i realized how you are using the stack to point to different zones depending of what you want to do. I'm a forever apprentice of asm and it amazes me that level of coding!

[Prodatron]

I suposse that compiling with RASM or with winape makes no different bin code?

First you always create the BIN + Symbol file with RASM, when compiling the code.
Then you can e.g. create a Maxam/WinApe style source code using Disark.
If you compile this source code with WinApe again, you will get exactly 100% the same binary like you got with RASM.

any advise with the player i must use? AKG player? Player lightweight? another player?

https://www.julien-nevo.com/arkostracker/index.php/the-players/
It really depends on your needs.
AKG is the choice if you want to have all features and don't need "maximum" speed (the player is still very fast!).
If you need as much speed as possible, use AKY, but the musicdata itself is larger, as it is a streamed/compressed AY thing.
Lightweight etc. are just players with smaller code, maybe only interesting for very small programms (like 4K demos).

Only reading a little the player code i realized how you are using the stack to point to different zones depending of what you want to do. I'm a forever apprentice of asm and it amazes me that level of coding!

Arkos Tracker 2 with all its tools and libraries is just an amazing piece of work!
That's for the speed as well!
I am happy that the PSG part of the SymbOS sound daemon is based on Targhans Arkos Tracker 2, that works just fantastic!

[SerErris]

Of cause you can convert RASM to MAXAM (winape) compatible code.

It is typically a matter of search and replace.

You typically only need to convert:
1. Labels (if at all)
2. Number format, esp hex numbers. rasm supports $ where MAXAM uses #
3. Directives .. there might some you would need to look at, esp the "current memory address".

Typically all that is required is a free search and replace operations on the source code and you are good to go.

The WinApe Assembler will tell you where the errors are, so you can do the heavy lifting in an texteditor and then give it a try and then work your way up.

You could also create a script to automatically convert anything in the future, but as everyone uses slightly different things, that also would not work universally.

[SerErris]

Just ignore the above ... as soon as it comes to macros you most probably at a dead end. So to get a compilable version that is the best you can do. 

[roudoudou]

Of cause you can convert RASM to MAXAM (winape) compatible code.

It is typically a matter of search and replace.

You typically only need to convert:
1. Labels (if at all)
2. Number format, esp hex numbers. rasm supports $ where MAXAM uses #
3. Directives .. there might some you would need to look at, esp the "current memory address".

Typically all that is required is a free search and replace operations on the source code and you are good to go.

The WinApe Assembler will tell you where the errors are, so you can do the heavy lifting in an texteditor and then give it a try and then work your way up.

You could also create a script to automatically convert anything in the future, but as everyone uses slightly different things, that also would not work universally.

3 wrong points! 

Winape/Rasm handle labels the same, Winape/Rasm handle # for hex values and Rasm macros were designed to be Winape compatible so...

For AT2 it's mostly a matter of special opcodes, == comparison and IF/IFDEF if i'm not wrong but the 3 points you talk about behave the same

[Joseman]

First you always create the BIN + Symbol file with RASM, when compiling the code.
Then you can e.g. create a Maxam/WinApe style source code using Disark.
If you compile this source code with WinApe again, you will get exactly 100% the same binary like you got with RASM.


*I suspected that, thanks for the confirmation!

https://www.julien-nevo.com/arkostracker/index.php/the-players/
It really depends on your needs.
AKG is the choice if you want to have all features and don't need "maximum" speed (the player is still very fast!).
If you need as much speed as possible, use AKY, but the musicdata itself is larger, as it is a streamed/compressed AY thing.
Lightweight etc. are just players with smaller code, maybe only interesting for very small programms (like 4K demos).

*Ok, i'll take a look to the AKY player, only one question, the player itself take up less memory?


Arkos Tracker 2 with all its tools and libraries is just an amazing piece of work!
That's for the speed as well!
I am happy that the PSG part of the SymbOS sound daemon is based on Targhans Arkos Tracker 2, that works just fantastic!

*Yes, i can see a lot of work and dedication only touching the pack a little moment.

Targhan and you are god programmers, always an example to follow!

Thanks for the help!

[Targhan]

>Ok, i'll take a look to the AKY player, only one question, the player itself take up less memory?

The player takes less memory because it is much simpler, however, the music WILL take more memory. In my opinion, only use AKY if you are short on CPU and don't care too much about memory (which is usually the case for a demo). For a game, I would go for the AKM, unless the song uses special things it cannot handle (you will be notified on export). If it does, fallback to the AKG.