[Closed?] Endianess weirdness when exporting to source

[Targhan]

Ah, so you’re in league with XiA, the one that finds me all these bugs and asks for features. I should have guessed :). But it’s great to have thorough users!

About point 2:
– The original code (the not “stabilized”) simply checks every bit of the type and branch on the code to jump to, instead of using a jump table. Maybe you should use that too (but the code will be harder to “stabilize”)?

To me, the real solution implies to that no one has to modify the output song by hand, so we should really find a solution to this. In my opinion, it is normal to have to configure either the source profile or the AKY export option, but it shouldn’t be more complicated.

I believe the macro solution is a good one. Please read it more carefully with a clear head, and tell me if it can work out!

[ggn]

Yes, XiA is one of the clients I brought for you 🙂 hopefully I can persuade a couple more to try the tracker out!

As for your reply on my point 2: I think you misunderstood me – I actually do use a jump table and it’s nice and efficient on 68000. The problem lies when reading opcode 8 (jump) that I have to read a word for the jump offset inside the track. For example:

https://github.com/ggnkua/Arkos-Tracker-2-ST/blob/master/Pachelbel’s%20Canon%20in%20D%20major%20003.s#L2885
https://github.com/ggnkua/Arkos-Tracker-2-ST/blob/master/Pachelbel’s%20Canon%20in%20D%20major%20003.s#L2885

Unless I counted wrong, the first dw will fall on odd address and will be auto-evened by the assembler, and the second is even. So the code on line 1155 (https://github.com/ggnkua/Arkos-Tracker-2-ST/blob/master/PlayerAky.s#L1155) will have to manually auto-even before reading the address.

Also, I went and re-read your macro idea. If I’m right you propose something like:

.macro my_dc_w value
.if (*&1)=1
dc.b 0
dc.w value
.else
dc.w value
.endif
.endm

if this is the case, then it’s automatically handled by the assembler when it encounters a dw immediately after a db!

That’s why I thought of that pre-process pass before starting to play the tune. And that’s always if we want to be super optimal or there are lots of branch commands so the performance hit is high. Otherwise it would be cool if the exporter did this, calculate beforehand if the dw is going to end up on odd address and insert a dummy db 0 before the register block starts.

Anyway in general I do agree 100% with you – the tune should not be post-processed once exported. If you check the github repo readme I do have some instructions on how to export and import the tune and I’m really not happy with that (horrible sed stuff!). I simply used these steps in order to move ahead and not get stuck on the exporter for now. Hopefully we can simplify things a bit 🙂

[Targhan]

My remark about the jump table was only if it was easier for you not to use it, but of course, do as you please :).

>Otherwise it would be cool if the exporter did this, calculate beforehand if the dw is going to end up on odd address and insert a dummy db 0 before the register block starts.

It is not really possible, currently: I simply generate the source, then use a third-party Z80 assembler, but I have no means of retrieving the address of each “lines” or label, the symbols are not exported. The address logic is not at all managed by my exporter, because I never thought it would be useful. However, now that I think about it, it shouldn’t be really hard to do. However, this would imply that the ORG address is known (to know if the music is encoded on an odd or even address)…

Other idea, which I think is better, does your assembler has an “align X” mnemonic? My source generator could add, if wanted, an “align 2” before each word declaration, which would then be rightfully interpreted by your assembler. No need for a macro that would require to be declared, either in the music source (clash could happen) or in the player.

[Targhan]

Oh, and by the way, the binary exporter only uses the Z80 profile under the hood (else, using a 68000 or a malformed profile would make the assembler fails). So I guess, for now, only the source export is usable for non-Z80 architecture. Embedding a 68000 assembler may be done one day though, if useful.

[Author]

Posts