SAS/C 6.3 and Assembler

Hello, I'm new here and was hoping a SAS/C expert could help me.

A bit of background: I am following the YouTube ScoopexUs tutorials on hardware programming. I am using a WinUAE emulated A1200 (KS3.0/WB3.0) and A500 (KS1.3/WB1.2) with SAS/C 6.3. I stopped doing the tutorials on the A1200 because they didn't seem to work properly. The exact same code on the emulated A500 works fine. I'm posting for a different reason, however.

I am using the SAS/C 6.3 compiler and assembler to write and build the code, and I am calling the ScoopexUs assembly language routine - which has a few modifications - from main().

The problem is that the assembler doesn't seem to understand "dc.w %0000000000000000", which, in tutorial 9, is used to define the shape of a sprite. The assembler replies with "syntax error" for these lines of code. The assembler will understand something like "dc.w $2cb8", but not binary representations. I don't know if this is also of any help, but earlier in the tutorials, I found that the SAS/C assembler also didn't understand the directive "DCB" for defining screen memory and replied with "unknown opcode" or something similar. I AllocMem()ed the memory for the screen to get around this particular problem, and is probably better that way anyway.

The SAS/C paper manual, which I have, shows "DCB" as a valid directive (although I have found no source code examples in the documentation of how it is used) and the '%' sign as the character to prefix binary numbers. What am I doing wrong?

I have included a couple of screen shots and the drawer with the Tutorial 9 SAS/C project.



Thanks for any help.

Justin.

[StingRay]

Originally Posted by JustinN

I don't know if this is also of any help, but earlier in the tutorials, I found that the SAS/C assembler also didn't understand the directive "DCB" for defining screen memory and replied with "unknown opcode" or something similar. I AllocMem()ed the memory for the screen to get around this particular problem, and is probably better that way anyway.

Try replacing dcb.b with ds.b, it does the same and the SAS/C assembler should allow this (most assemblers do). This replacement only works for statements which are in the form of dcb.x size,0 (defines a contant block with the value 0), as soon as something like dcb.b size,value_not_null is used, ds.b can't be used as a 1:1 replacement (you could use ds.b and fill the buffer afterwards with the constant though).

As for your problem with the binary dc.w statements, maybe the SAS/C assembler needs a special sign in front of the binary numbers (i.e. something else then %)?

Thank you for your reply. I forgot about ds.b.

The manual definitely states prefixing binary numbers with a '%'. I tried the '@' for octal notation and that works, as does '$' for hexadecimal, and no prefix for decimal numbers. I tried an '&' for binary, but that didn't work.

Justin.

A tilde - '~' - seems to assemble without error, but don't know if it actually works yet.

Thanks for your help.

[StingRay]

Originally Posted by JustinN

A tilde - '~' - seems to assemble without error, but don't know if it actually works yet.

The tilde is usually used as sign for "not" which means your dc.w %0000 will turn into dc.w %1111 which is not what you want.

I don't know what to do then, other than use hexadecimal.

Thanks.

[hooverphonique]

if you're using inline assembler, the syntax could be a little different than when having assembler code in a separate file, because the inline stuff is passed through the c compiler..

Originally Posted by hooverphonique

if you're using inline assembler, the syntax could be a little different than when having assembler code in a separate file, because the inline stuff is passed through the c compiler..

My assembler routine is in a separate file to the main c file.

[Leffmann]

It does choke on extraneous spaces between operands, maybe it doesn't like trailing spaces either, or requires tabs instead of spaces somewhere? Sometimes shift+space or shift+return will produce a different character, have you tried re-typing the line? What if you put a single operand on each line?

It seems to work correctly in SAS/C 6.58, if you want to try that instead:
https://www.dropbox.com/s/rt23fhty36...sc658.lha?dl=1

Originally Posted by Leffmann

It does choke on extraneous spaces between operands, maybe it doesn't like trailing spaces either, or requires tabs instead of spaces somewhere? Sometimes shift+space or shift+return will produce a different character, have you tried re-typing the line? What if you put a single operand on each line?

It seems to work correctly in SAS/C 6.58, if you want to try that instead:
https://dl.dropboxusercontent.com/u/8177628/sasc658.lha

I have tried your suggestions but I keep getting errors. I too have noticed that this assembler is fussy on formatting. Like you said, put a space between operands and it won't work. The assembler is happy with an instruction like:

move.b #%10001000,d0

so it seems it will work with binary notation, just not in a "dc" directive.

I purchased the 6.3 version back in the first half of the 90s, and I don't think I would have a license to use the 6.58 upgrade. I wouldn't like to use that version, really. It seems like the problem could be a bug with 6.3. I'll work around it.

Thank you for your help.

[Photon]

If move.w #%1000100010001000,d0 does NOT work, then the problem might be that the compiler only handles bytes. Then you can split the dc.w into dc.b. Or, since the sprite smiley face in the tutorial is quite ugly, you can just put dc.w $ffff,$ffff instead of each binary line

You can also try removing leading spaces before dc.w or add a tab or spaces to put the "d" in dc.w at the same position as the "m" in your move.b example.