Strange AsmOne operator

[phx]

What does this mean:

copdma=1~lev6

The tilde looks like a complement operator. But a complement should be unary. In this example it is used as binary operator (from ThePlayer source).

[Leffmann]

It's bitwise XOR. It works as a unary too, and then it will use -1 as the other operand.

[phx]

Thanks.
That's unusual. Looks like the AsmOne-family has the one assemblers supporting that.

[hitchhikr]

It's a legacy from Seka.

[Photon]

Originally Posted by phx

a complement should be unary

AsmOne uses this as both complement and XOR in recognition of the fact that they are the same thing, only with or without an assumed operand. It's also implemented this way in any decent CPU.

Anyway, you should be able to use copdma=1-lev6 for this example, it's a shorthand for IF-calculations IIRC. This should keep it 0 or 1 and not 0 or nonzero, so the calculations are correct.

[phx]

Originally Posted by Photon

Anyway, you should be able to use copdma=1-lev6 for this example, it's a shorthand for IF-calculations IIRC.

Right. Provided lev6 is always 1 or 0.
Or just copdma=!lev6. Does that work with AsmOne?

BTW, is there any chance ThePlayer will assemble with other assemblers again, in the future? Would be great!

[SyX]

Originally Posted by phx

BTW, is there any chance ThePlayer will assemble with other assemblers again, in the future? Would be great!

Well, i have assemblied with vasm making a few changes, using -nocase, hardcoding the value of the <fill> in the dcb (dcb.w 15*16,$004A ;,P61_nocha-.j), making 0 the constant asmone, commenting the IF2s, making the incbins relative and changing the calling to the player subroutines in the example from PlayRtn+xx to the correspond P61_xxx (Init, SetPosition, Music, End).

I could attach the files with the changes, but with the next version of vasm with printt, printv, echo, fixing the dcb <fill>,... between other things, various of my changes it will not be needed, because that i would like to wait.

PD: It would be great take a look to the sourcecode of P61Con to convert to c (or python ) to make more easy the live of the cross-developing

[Photon]

Will be cool if you implement those nice AsmOne extras, some of them are very handy. And yes, if you're not assembling with AsmOne, that constant (which conditionally uses AsmOne-specific directives) should be 0.

(The PlayRtn+xx jumptable is just to make longjumps easier (when playroutine is a ready made binary and/or far away from the caller) and can be removed both from the playroutine and the example if you don't use them.)

P61Con source... I think that request has been put before and result is "not found" or something. At least I can't find it with a quick search. I noted some changes in encoding that would save a few cycles in the playroutine, but then there would be multiple versions of the converter... and I decided against it because I can't really think how to make it better, apart maybe from putting the usecode in the filename instead of the file comment...

Maybe some day I'll feel masochistic for long enough to Resource it, but ... don't hold your breath, it's very unlikely that I'll get into that. Maybe the need will arise if I decide I want to 'append' a synth module+echo effects etc for P6109. But then I would have to dictate the supported synth-format and chipmusic playcode, and I want to keep that open.

What do you need to port the converter for? (I'm trying to see the need, but it's not like a module format or anything; more like a compressed file format only used at the last stage of deving an Amiga game/demo.)

[phx]

Originally Posted by Photon

Will be cool if you implement those nice AsmOne extras, some of them are very handy.

Yes, some of them make sense. I implemented printt and printv yesterday. And I always liked basereg, which was even part of PhxAss, 15 years ago. Others, like if2, do not make any sense outside of AsmOne at all.

[Leffmann]

What about accessing local labels? In ASM-One you can do label\.local (though label.local would be nicer) and it's useful at times.

[phx]

Originally Posted by Leffmann

What about accessing local labels? In ASM-One you can do label\.local (though label.local would be nicer) and it's useful at times.

I was already asked about that several times.
That could be done, but such a modification would be quite intrusive. I'm still not sure if it is worth it, because I think that when you need such a construct you should better review your source code.

[SyX]

Originally Posted by Photon

What do you need to port the converter for? (I'm trying to see the need, but it's not like a module format or anything; more like a compressed file format only used at the last stage of deving an Amiga game/demo.)

Well, the main reason is the easy integration with my sdk (make + vasm + a few python scripts to crunch, convert images, make disk images, send to amiga or emulator, ...).

Of course, that you only have to convert the mod files once; but with a command line tool (mod2p61), i include it in my makefile and i forget about it, only edit and make

But don't worry Photon, you have made a Great Job!!! And i would must to take a look at P61Con in IDApro, too.

I thought I had released the source to P61con, but it seems I didn't after all. Thanks go to Robert Leffmann for bringing this to my attention :)

Anyway, I found it pristine in my old HD image and put it up at http://s2.org/~jpaana/p61consrc.zip

Sorry for the horrible code though :)

// Jarno

Edit: updated the file with a couple of missing incbin'ed files, nothing major, but the binary version of replay and module info file. So please re-download if necessary.

[SyX]

Thank you very much Jarno!!!

[Photon]

Awesome Jarno

I did find a reason for porting just after posting last - batch conversion on PC et al. But your reason is better, phx.

I still think I'll stay away from miniscule improvements on the format (no need to make a bifurcation in formats for that little time-gain). It's not that I've lost my extremist view on optimization :P, it's just a bad idea. I think the converter is as finished as an app can be. Possibly, I'll have a look at appending the USE code to the filename to survive copying onto filesystems that don't support file-comments. (Jarno, if you have a better idea of where to put it such as an unused longword in the final converted .p61-file, or some other ideas let me know.) If I do, I'll check if the playroutine in the converter has the fixes to it that came after Jarno's final playroutine. (F.ex. A4000 intreq-fix, playroutine in the converter is CIA but from memory there were more places where it was needed.)

So cool by Jarno to help you out I'm feeling inspired to add the synthchannel/echo/pan and make P6109 I think I'll do that and supply an example with a simple synth-player on the side. I still think it's a bad idea to dictate or limit synthformats in the converter though, so I won't modify the converter and everything related to that will be external to the module data.

My recollection of the format is quite hazy, but I don't think there is as much unused space that the use code would need. Appending it to the file name sounds quite portable and easy solution. Actual implementation to the messy source might be otherwise

The replay is not included in this source, it's incbin'ed as binary version. Unfortunately I only had binary for my last released buggy version at hand, but it should be straight forward to just use binary from a newer version.

Just in case someone else tries to run the default version within ASM-One and gets bitten by the same thing I did when doing this package is that there is a define called imaginatively "fromasmone" that needs to be set to one at the beginning of the source, otherwise the process detaching code, parameter parsing or something messes things up.

[Leffmann]

Thanks again for the the upload!

I've started a literal translation to C but there's a lot of code to unwind so I expect it will take a while before I have a finished CLI tool. Feel free to beat me to it

[hitchhikr]

Frank: if you're going for compatibility maybe you could add AsmOne's DR directive to vasm (it's basically dc.w AnyLabel-*).

Also there's an issue with BASEREG for example:

basereg dats,a4
tst.w (a4,d0.w)

will generate an illegal relocation error.

Also vlink crashes when using cross section pc relative code (such code doesn't make sense but vlink shouldn't crash on that).

And i seem to recall that vasm doesn't handle negative values for bitfield instructions (but maybe that one was fixed already).

[phx]

Originally Posted by hitchhikr

Frank: if you're going for compatibility maybe you could add AsmOne's DR directive to vasm (it's basically dc.w AnyLabel-*).

Ok, done.
Does anybody really use DR to build jump-tables?

basereg dats,a4
tst.w (a4,d0.w)

will generate an illegal relocation error.

Fixed.

Also vlink crashes when using cross section pc relative code

I cannot reproduce any crash. Which host OS? PC-relative references to another section will usually merge the two.

(such code doesn't make sense but vlink shouldn't crash on that).

It makes sense under Unix-like operating systems, where section start addresses are fixed.

And i seem to recall that vasm doesn't handle negative values for bitfield instructions (but maybe that one was fixed already).

Maybe I misunderstand you, but why should a negative offset or size in {offset:size} be legal?

If you have any more bugs or examples, please contact me by email. That's easier for me.

And to come back to the topic: I also implemented the Seka/AsmOne ~ operator now.

[hitchhikr]

I cannot reproduce any crash. Which host OS? PC-relative references to another section will usually merge the two.

Host is Windows (compiled with gcc), Target is Amiga (where it doesn't make any sense):

section co,code
lea dat(pc),a0
rts
section da,data
dat: dc.l 0

vasmm68k -DVASM -quiet -phxass -no-opt -Fhunk -o test.o test.asm
vlink -quiet -S -s -o test test.o

Vasm messages:
Warning 58: Relative references between code section "co" and data section "da" (test.o) force a combination of the two.
Warning 22: Attributes of section co were changed from r-x- in test.o to rwx- in test.o.

Link (mangled) message (before it crashes):
Error 32: Target amigahunk: Unsupported relocation type R_PC (offset=0, size=16, mask=ffffffff) at

Maybe I misunderstand you, but why should a negative offset or size in {offset:size} be legal?

Forget it, it's Asmpro which doesn't handle that properly (and allow negative offsets), vasm appears to be correct.

No more issues right now.