1
0
mirror of https://github.com/fadden/6502bench.git synced 2024-09-10 13:54:52 +00:00
Commit Graph

5 Commits

Author SHA1 Message Date
Andy McFadden
149e763821 Change the way ASCII is handled for 64tass
The documentation for 64tass says you're required to pass "--ascii"
when the source file is ASCII (as opposed to PETSCII).  We were
ignoring this, but it turns out that everything works a bit better
if we don't.

So we now pass "--ascii" on the command line, and add a two-line
character encoding definition to every file that is generated with
ASCII as the default encoding.  The sg_petscii and sg_screen
encodings go away, as PETSCII is now the default, and we can use the
built-in "screen" encoding.
2019-08-20 11:21:30 -07:00
Andy McFadden
0abea2beac Update 64tass handling of StackInt ops
The operands for BRK and COP must be expressed as immediate mode
constants, with a leading '#'.
2019-08-19 16:09:11 -07:00
Andy McFadden
835c1c7fe2 Reverse position on '#' in block move operands
During a discussion with the cc65 developers, I became convinced that
generating "MVN $01,$02" is wrong, and "MVN #$01,#$02" is correct.
64tass, cc65, and Merlin 32 all accept this syntax; only ACME does
not.  Operands without a leading '#' should be treated as 24-bit
values, and have the bank byte extracted.

This change updates the on-screen display and assembled output to
include the '#'.  The ACME generator uses a Quirk to suppress the
hash mark.  (It doesn't currently accept values larger than 8 bits,
so there's no ambiguity.)
2019-08-08 13:02:01 -07:00
Andy McFadden
98914e9f80 Treat BRK as a 1-byte instruction
The 65816 definition makes it a two-byte instruction, like COP.  On
the 6502 it acted like a two-byte instruction, but in practice very
few assemblers treat it that way.  Very few humans, for that matter.
So it's now treated as a single byte instruction, with the following
byte encoded as a data value.
2019-08-02 17:21:50 -07:00
Andy McFadden
f7e5cf2f45 Progress toward 64tass support
Most tests pass, but 2007-labels-and-symbols fails because the
expressions recognized by 64tass don't match up with either of the
other assemblers.

This is currently using a workaround for the local label syntax.
64tass uses '_' as the prefix, which is unfortunate since SourceGen
explicitly allowed underscores in labels.  (So does 64tass for that
matter, but it treats labels specially when the '_' comes first.)
We will need to rename any non-local user labels that start with '_'.

(issue #16)
2018-10-23 20:08:01 -07:00