docbacardi/dreamass

A cross-assembler targetting the C64.

dreamass's Issues

Branch allows +128 offset.

You don't get a branch error with the following expression:

beq *+$82

It assembles as:

$f0 $80

which is -128, not +128.

This creeps up on me in a couple of places where my branches are just a bit too far away and they branch backwards rather than forwards. I haven't checked the other limits to be sure.

Add a README

PC definition does not detect undefined vars

PC definition does not detect undefined vars and successfully compiles the code without any warning, which leads to bugs that are very hard to track down:

ADDR_1  = $1000
        *= ADDR_1
        lda #$00
        *= ADDR_2
        ldx #$00

Surprisingly this successfully compiles:

Segment 'seg1' sorted MemElems:
0 : $1000 - $1004, id: 0
I'm done

Expected behaviour would be to report ADDR_2 as an undefined var:

Some vars still undefined. Dump not yet supported, sorry!
error:variable undefined: ADDR_2

Please note that undefined vars detection works properly in all other contexts.

Core dumped on an undefined variable with a new PC definition

When an undefined variable is encountered in a source code accompanied by an additional PC definition command, it results in a failed assertion and a consequent core dump.

Here is a minimal example to reproduce the issue:

        *= $0800
        ora $1000
        jmp $0900

        *= $0900
        jmp show

Compilation of this syntactically valid code snippet fails with the following error message:

Some vars still undefined. Dump not yet supported, sorry!
dreamass: segment.c:430: segment_enterSegElem: Assertion `false' failed.
Aborted (core dumped)

An expected behaviour would be to report show as an undefined variable just like this:

Some vars still undefined. Dump not yet supported, sorry!
program.src:6: error:variable undefined: show

Program counter computation is broken for "fill area" pseudo opcode with size specified in a later defined constant

The following example reveals a bug with program counter computation for fill area pseudo opcode with size specified in a later defined constant:

        *= $1000
        jmp proc
ouch    .dsb SIZE,$00
SIZE    = 2
proc    inc $d020
        jmp *-3

Compiled output program is:

00 10 4c 05 10 00 00 ee 20 d0 4c 06 10

But it should have been:

00 10 4c 05 10 00 00 ee 20 d0 4c 05 10

Please note that jmp *-3 opcode should have been compiled into JMP $1005, but it compiles to JMP $1006 instead.

Macro expansion broken for same-prefixed parameter names

When parameter names share the same prefix, macro expansion results in a broken code. Steps to reproduce follow below.

Here is an example minimal source code:

$ cat test.src 
#macro test(var,varname)
{
        lda {var}
        lda {varname}
}

        *= $1000

        .test($2000,$3000)

The expected compiled code should have been:

        ; .:1000 ad 00 20 ad 00 30
        *= $1000
        lda $2000
        lda $3000

However it currently is:

        ; .:1000 ad 00 20 ad 00 20
        *= $1000
        lda $2000
        lda $2000

{varname} is substituted with the same value as {var}, and as such the second parameter of the marco gets completely discarded. The expected behaviour is to correctly substitute the parameter names as specified in the macro expansion code.