Jump to content
IGNORED

68k syntax questions


Otto1980

Recommended Posts

hi all,

 

some stupide syntaxquestions for the 68k (because i cant find it in any books or online)

 

what stands this pipe ("|") for and what exactly does it:

move.l #(BRANCHOBJ|O_BRLT),d1

(taken from startup.s)

 

what exactly is doing this "<<" in this equeal

O_BREQ EQU (0<<14)

 

sorry for noobish question.. but i want to know EVERYTHING :-D

 

greets to all

Edited by Otto1980
Link to comment
Share on other sites

what stands this pipe ("|") for and what exactly does it:

move.l #(BRANCHOBJ|O_BRLT),d1

(taken from startup.s)

 

Bitwise OR (exactly like "C" syntax).

 

what exactly is doing this "<<" in this equeal

O_BREQ EQU (0<<14)

 

Logical shift left 14 places (exactly like "C" syntax).

 

What assembler are you using?

Link to comment
Share on other sites

thanks for your tips.. step by step i have my docs set up ;-)

 

but smal question is left:

why we do the "logical shift left" in the jaguar.inc?

and why we do it this way and not by just declare fixed equ´s ??

 

O_DEPTH1 EQU (0<<12) ; DEPTH Field for BITMAP objects

O_DEPTH2 EQU (1<<12)

O_DEPTH4 EQU (2<<12)

O_DEPTH8 EQU (3<<12)

O_DEPTH16 EQU (4<<12)

O_DEPTH32 EQU (5<<12)

Link to comment
Share on other sites

thanks for your tips.. step by step i have my docs set up ;-)

 

but smal question is left:

why we do the "logical shift left" in the jaguar.inc?

and why we do it this way and not by just declare fixed equ´s ??

 

O_DEPTH1 EQU (0<<12) ; DEPTH Field for BITMAP objects

O_DEPTH2 EQU (1<<12)

O_DEPTH4 EQU (2<<12)

O_DEPTH8 EQU (3<<12)

O_DEPTH16 EQU (4<<12)

O_DEPTH32 EQU (5<<12)

 

The simplest explanation for this is that the programmer who did jaguar.inc liked it! It's just preference really, writing those EQUs down like that instead of $0000/$1000/$2000/etc might look better to some and the opposite!

 

I can imagine a couple of more reasons for favouring this syntax though. First of all, you can never forget which actual bits the depth field is on. Secondly, this file was internal to Atari while the hardware was being in the works. So, imagine if the hardware engineers suddenly realised that the values for depth would have to be placed on bit 13 onwards. With the above syntax, you'd simply change all 12s to 13s, while on the other syntax you'd have to replace them with $0000/$2000/$4000/etc. Now do that a couple of times and you can be sure that SDS (who was maintaining this file) would have gotten pissed off if he used the later syntax :).

 

As for only choice for assembler being smac for windows 7, you in fact have 2 more options: one is to use dosbox and run the official mac/aln from atari, or you can use rmac/rln which can be thought of smac/sln but with a few bug fixes :).

  • Like 5
Link to comment
Share on other sites

  • 1 year later...

thanks for your tips.. step by step i have my docs set up ;-)

 

but smal question is left:

why we do the "logical shift left" in the jaguar.inc?

and why we do it this way and not by just declare fixed equ´s ??

 

O_DEPTH1 EQU (0<<12) ; DEPTH Field for BITMAP objects

O_DEPTH2 EQU (1<<12)

O_DEPTH4 EQU (2<<12)

O_DEPTH8 EQU (3<<12)

O_DEPTH16 EQU (4<<12)

O_DEPTH32 EQU (5<<12)

The Depth bits ( lets say there is 3 bits which gives the values 0->7) start at bit 12 . The shifting syntax can make it easier to read

Link to comment
Share on other sites

As for only choice for assembler being smac for windows 7, you in fact have 2 more options: one is to use dosbox and run the official mac/aln from atari, or you can use rmac/rln which can be thought of smac/sln but with a few bug fixes :).

 

or using Devpac on an Atari machine :)

 

(Yes i know Bjl is dead ;) and USB driver on Atari is a dream :D )

Link to comment
Share on other sites

As for only choice for assembler being smac for windows 7, you in fact have 2 more options: one is to use dosbox and run the official mac/aln from atari, or you can use rmac/rln which can be thought of smac/sln but with a few bug fixes :).

 

Rmac seems to have removed all the main ram rules implementation that SubQmod put into Smac.

Link to comment
Share on other sites

I fixed it for you...

 

 

Rmac seems to have removed all the main ram rules stopped all the code changing fuckups and assembly errors from the implementation that SubQmod put into Smac.

 

In all seriousness, there have been far too many cases where I had crashes due to SMAC not assembling correctly that I stuck with DOSBOX/MAC for ages before moving onto RMAC. We still find bugs in RMAC, but unlike SMAC, they do get fixed. RMAC is, by far, the more reliable assembler.

Edited by CyranoJ
  • Like 1
Link to comment
Share on other sites

The "GPU in Main Rules" were a bunch of injected macros and other miscellaneous bodges that have no business being in an assembler--that kind of thing belongs in a preprocessor, if anywhere. And injected macros? Really?

 

If someone wanted that stuff bad enough, they could write a header with the appropriate macros to get that functionality back. :P

  • Like 7
Link to comment
Share on other sites

  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...