nurpax / c64jasm Goto Github PK

When the program is running and you set a breakpoint, VICE remotemon pauses the app (at whereever it happened to be running when break was set). Once you continue with 'c' or 'g' from this point, the actual breakpoint will be hit.

It'd be better if setting a breakpoint wouldn't immediately pause but rather it'd continue and then let VICE break on actual breakpoints.

Maybe should change MonitorConnection API from setBreakpoint to setBreakpoints which'd also delete earlier breakpoints and reset the whole array and then resume execution.

reported via a twitter DM

they could be used as functions this way..?

Rather than having all c64jasm asm files wrap stuff like Math.floor, sin, etc. figure out a way to pull Math directly into scope in the compiler.

TBD are there some other modules like Math that should also be imported?

Also: Math.random is not great in compilers (unreproducible builds!), so should trampoline this function and issue a warning if it's used.

!for frame in xyzzy {
!for x in range(8) {
!let fi = frame[i]
; !byte frame[i].x & 255
}
}

where xyzzy is something like

xyzzy = [[{x:0,y:0}]]

plugins now get called once per pass. for any type of larger input file processing, this might be pretty bad for perf. could just memoize the plugin results based on input args.

 lda #0

(note the space between first column and LDA)

gives syntax error

search for this.variables.add, many of these are not guarded by check for existing variables of the same name.

add a bindVariable() that checks for this and use that instead.

also fix word splitting in the language definition.

copy_screen_top_half: {
    copyscreen(screen0, screen1, 0, 12)
    rts
}

this should error about +copyscreen (e.g., macro call is wrong) but instead if complains about

{
	"resource": "/Users/janne/dev/c64-palju/main.asm",
	"owner": "_generated_diagnostic_collection_name_#0",
	"code": "undefined",
	"severity": 8,
	"message": "Syntax error: Expected \"x\" but \"s\" found.",
	"source": "c64jasm",
	"startLineNumber": 94,
	"startColumn": 25,
	"endLineNumber": 94,
	"endColumn": 26
}```

	lda #0
	sta $d020

!macro foo(col) {
	lda #col
	sta $d020
}

+foo(3)

If say "lda #col" above has an error, the error is shown for that LDA line. But sometimes the error is due to the expansion call +macroname. So would be nice to show the full expansion path with some diagnostic notes.

allow things like:

    lda #Math.sin(Math.PI*0.1)

currently doing

x = 3

in a macro or a for loop will trigger multiple declarations error

forgetting to expand a macro with + gives always weird error messages (confuses with instruction parsing)

maybe there's a way to deal with this better.

some mechanism to wrap a whole included file inside a scope. this scope should be accessible from outer scopes with

filescope.label

This doesn't compile, errors out with a syntax error:

    !let numSprites = s.numSprites
    !byte s.numFrames * s.numSprites * 2

This can be worked around with:

    !let numSprites = s.numSprites
    !byte s.numFrames * numSprites  ; * s.numSprites * 2

https://www.npmjs.com/package/progress-estimator

this should give an error

* = $100
lda #1 
nop
nop
nop
* = $102
nop
nop

Local labels can be specified with a .dot prefix. Every new normal label defines a new local scope:

foo:
  lda #0
.bar:

bar:
  ldx #1
.baz:

These get resolved to foo, foo.bar, bar, bar.baz.

The .prefix syntax is especially helpful when used in macro declarations.

would support #20 too.

some problems in current scoping:

foo: {
bar:
}

lda foo.bar

the dot operator resolution in the assembler is sort of complicated since it can be either an object reference or a sort of undefined scope resolve.

perhaps nested access should instead be done by :: like in C++. e.g.,

lda foo::bar

to make it explicit and simplify symbol resolution.

macro expanded labels should also be accessible. KA does it like this, this seems good:

        *=$1000
start:  inc c1.color
        dec c2.color
c1:     :setColor()
c2:     :setColor()
        jmp start

KA also supports for-loop labels and if-labels:

       jmp myIf.label

myIf: .if (true) {
         ...
label:   lda #0  // <-- Jumps here
         ...
      } else {
         ...
label:   nop
         ...
}

similarly, for-loop labels can be accessed similarly (in c64jasm syntax):

foo: !for i in range(4) {
lbl: 
}
lda foo[0].lbl

maybe there's an error generated for branch instructions when another pass would be needed instead.

!let music = sid("../sid/PoingPrev20181007.sid")

rename to music2 and keep uses as "music"

like ~lbl in acme

foo: {
baz:
}

jmp foo.baz

should work

it's annoying to have to create a new file for each plugin function

c64jasm --disassembly

should generated a listing file with machine code.

this should be plugged into the assembler so that it can tell apart actual machine instructions from byte data.

the patched kernal really speeds up boot time. see http://codebase64.org/doku.php?id=base:using_a_running_vice_session_for_development

would always use this but probably not ok to ship a patched kernal with c64jasm.

Add elif blocks

something like this (from shell pegjs):

ifBlock "an if/elif/else statement"
 = "if" spaceNL+ test:condition
   "then" spaceNL+ body:script
   elifBlocks:elifBlock*
   elseBody:("else" script)?
   "fi"

elifBlock
 = "elif" spaceNL+ test:condition "then" spaceNL+ body:script

!macro xyz(col) {
	lda #col
	sta xyz; $d020
}

(xyz is undeclared)

this gives:

Must have a label or a variable identifier here, got macro name