QUESTION: Branch Size on QPC2 (68020+)?

[Derek_Stewart]

Hi,

That is why I said GWASS, as it supports the 68020+

Okay, so I can write 68020 op code with defining the codes with the binary codes in data statements.

[Peter]

Simply assemble in Qmac, then load and call this code (QPC2 or Qx0 only!) It should return with the error Invalid syntax if it worked.

Or SuperGoldCard.

Back when I designed the Q40/Q60, I was quite excited about the extra CPU features at first.
But in practice, QL software that does not run on 68000/68008 rarely makes sense.

That's why I did not synthesize a 68020 compatible CPU for the Q68. Using the smaller variant allowed to squeeze several more MHz out of the same silicon, which is overall more effective.

[Derek_Stewart]

Hi,

As I stated earlier, what is wrong with GWASS, which will assemble the required 68020, 040, 060 op codes.

If the Q68 or Qzero could i plement a 68020, then I would use GWASS

I do not have a working Q60 at present to use it on, which I will sort out in the New Year.

[Derek_Stewart]

I was reading the Miracle Super Gold Card Manual, which states in the Assembley Language section:

ASSEMBLY LANGUAGE

If you are interested in using assembly language on the QL please read
this section.

First and foremost the Super Gold Card is for running existing QL
programs faster. QL programs are written for the 68000 and there is
software on the Super Gold Card to make it look as much as possible
like a 68000 system.

Also we recommend that your programs do not make use of special 68020
instructions so that they run on all QL systems. This is a particularly
important consideration for any program destined for sale or
publication. The golden rule is: assume you are writing for the 68000.

Incidentally, we did not use or need a 68020 assembler in extending the
Gold Card software for the Super Gold Card. The only 68020 instruction
is the one to write to the cache control register.

Additional information regarding the 68020 is NOT available from
Miracle Systems.

So it looks like if we want to use 68020 assembley language, this not recommended.

The Assembley Language Mag, used GWASL, whivh is a 68000 assembler, but QPC2 v5 can emulate 68020 CPU, so GWASS can be used.

I use GWASS on the Q60, which assembles 68060 assembley op codes, in SMSQ/E.

[BSJR]

...
So it looks like if we want to use 68020 assembley language, this not recommended.
The Assembley Language Mag, used GWASL, whivh is a 68000 assembler, but QPC2 v5 can emulate 68020 CPU, so GWASS can be used.
I use GWASS on the Q60, which assembles 68060 assembley op codes, in SMSQ/E.

The GWASS directive "LOW_EA" will produce code fit for the 68000 so there is no need to use GWASL.
Of course no 680x0 specific instructions should be present but as GWASL is more strict in the syntax then GWASS I prefer to use the latter.

BSJR

[NormanDunbar]

The GWASS directive "LOW_EA" will produce code fit for the 68000 so there is no need to use GWASL.
Of course no 680x0 specific instructions should be present but as GWASL is more strict in the syntax then GWASS I prefer to use the latter.

Also, another reasons to use this in GWASS rather than GWASL, the latter doesn't treat lines as empty unless they consist only of a linefeed character. Some editors autoindent when you press ENTER and this means you get either a hard tab or a pile of spaces and GWASL doesn't like this at all. You get a weird error message similar to "invalid effective address" or possible "invalid instruction."

Apart from this foible, GWASL is an excellent assembler, as indeed is GWASS.


Cheers,
Norm.

[Derek_Stewart]

Hi,

I was reading the GWASS manual, and was wondering about the QM_PAR directive, which allows QMAC style parameters to GWASS macros.

Does this work in all QMAC macros?