The following does not work:

SET A, 65535

It translates to

0000:[7c01]0000 0000 0000

The following works:

SET A, 65534

It translates to

0000:[7c01]fffe 0000 0000

SET [0x8000], 72
ADD [0x8000], 0x1
BRK

The result of this is that 0x8000 contains some value other than 73.

Been working on my fork a bit, and I believe the assembler is outputting the wrong result for instructions like SET [0x1000], 0x20. The assembler uses 0x1E for [0x1000], but for most instructions, the CPU already treats the value of the first argument as the address of the location to write to.

This isn't reproducible on your fork because of these lines, which handle 0x1E and 0x1F identically. That isn't what's specced though (0x1E denotes an address, 0x1F denotes a literal). Fixing this in my fork revealed the above issue.

This compiles to 7DC1 0002:

SET PC, loop
:loop

However, this compiles to 85C1:

SET PC, 1

They both do the same thing, but the latter uses one less word.

Consider the following code:

SET A, 100
DIV A, 3

This results in the following state:
==== REGISTERS: ====
A: 21.555555555556
...

Seeing as all registers are 16-bit integers, this shouldn't happen. Since JavaScript isn't statically typed it looks like you'll need to cast the result of a DIV

Reading the 1.5 specs: "b is always handled by the processor after a"

So: SET b, a should produce opode A, B

Currently, SET 0x1110, 0x1120
produce: 7fe1 1110 1120

which is wrong

:break
SET PC, :break

Compiled to SET PC, A instead of show error.

As seen in http://www.0x10cforum.com/gallery/m/4932873/detail/56189#pid=466442

It does not appear to be in the spec yet. It looks like notch is freely mixing hex and strings. I'm guessing the instruction just copies bytes verbatim, probably expanding chars to 16 bits.

We have a regression of #10. The example program from #10 fails to assemble with

Error: Subroutine 0 was not defined (address 4)

Please add a license so we know how we can use this code. I'd like to use some in my own emulator, but can't unless you specifically say it's ok in some fashion :)

It seems like your JSR instruction moves the PC to 1 word further than it should when it jumps. Here is a test program. It computes:

sum(1 to 5) + sum(1 to 6) = 15 + 21 = 36 (or 0x24)

In the end, the result should be in the Z register.

Running the following in your emulator results in an infinite loop because the JSR jumps one word too far.

SET X, 5
SET Y, 6
SET PUSH, X
SET PUSH, Y
SET A, X
SET C, sum
JSR C
SET Y, POP
SET X, POP
SET B, A
SET PUSH, X
SET PUSH, Y
SET PUSH, B
SET A, Y
SET C, sum
JSR C
SET B, POP
SET Y, POP
SET X, POP
SET C, A
SET Z, B
ADD Z, C
BRK
:sum SET I, A
SET J, 0
:loopsum ADD J, I
SUB I, 1
IFN I, 0
SET PC, loopsum
SET A, J
SET PC, POP

SET a,0x1 fails to assemble, giving the error as "Error: Subroutine a,0x1 was not defined (address 1)". It works fine with a space after the comma, but not without.

When setting PC to stack value, PC drops to zero instead of this value.

Test program:

SET PUSH, goto1
SET PC, sub1
:goto1
SET PC, end

:sub1
SET B, 0x1
ADD A, B
SET PC, POP

:end
BRK

Expecting A=1 and B=1, then return from subroutine to "goto1" label and jump to "end" from there. Instead we get an infinite loop - PC is set to 0 and restarts program, constantly increasing A.

Blecki reported that this code does something it shouldn't. I don't know if it's a bug yet or not, and I have to go at the moment, but I'n recording it here.

http://0x10co.de/qhx5v

It prints "TRING". Apparently it shouldn't.

Hi mappum,

the following program is supposed to have X = 100 at the end:

SET C, SP
SUB C, 256
SET [0+C], 100
SET X, [0+C]

BRK
:crash SET PC, crash

It does not. X = 0 (please, run the program in http://mappum.github.com/DCPU-16/)

At the same time, the following works:

SET C, SP
SUB C, 256
SET [1+C], 100
SET X, [1+C]

BRK
:crash SET PC, crash

Would you like to take a look? I'm going to do the same, because this issue blocks my works on the LLVM backend, but I guess that you would be able to find the issue faster than me.

Technically we have 128k of ram to mess with but allot of assemblers push strings characters in to individual words. It would be nice if your assembler supported a tag for packing DAT lists.

Tested in goforth: http://0x10co.de/hiwhx
Try typing:
-50 5 / .
50 -5 / .
The first results in -6564 and the second in -1. Both should be -10.

Try:
-50 5 mod .
50 -5 mod .
The first results in -2 and the second in 50. Both should be 0.

Here is a pure ASM test of DVI:
http://0x10co.de/69nbr

The specs doesn't mention it but it is visible in screenshots that the video memory starts at 0x8000.
(Some discussions here: http://0x10cforum.com/forum/m/4932880/viewthread/2702717-sneaky-peek-or-poke )

This would mean that there is no need for the unofficial PRT command, and it makes your code more future proof to just assume that the video ram starts at 0x8000 and use it directly in your html frontend.

If this will change in the future then it would just be easy to start using another ram location.
Another added bonus is that the asm code written for this compiler will be compatible with the other implementations.

dcpu.stop(); when it's called?
I've wrote some loop in loop with total 512 iterations, and it stops at every one of it. It's so annoying.
Here is some code with this issue:

SET I, 16
:LOOPX
  SUB I, 1
  SET J, 32
  :LOOPY
    SUB J, 1
    SET A, I
    MUL A, 32
    ADD A, J
    ADD A, 0x1000
    JSR COUNT
    SET Z, 0
    IFE C, 3
      SET Z, 0x01
    IFE C, 2
      SET Z, 0x10      

    SET X, 0x8000
    ADD X, A
    ADD C, 48
    SET [X], C


    IFN J, 0
      SET PC, LOOPY
  IFN I, 0
    SET PC, LOOPX

SET PC, END

:COUNT
SET C, 0
SET PC, POP

:END
BRK

I haven't done assembly language before, so I don't know if this is a problem on my end or yours. But from reading the documentation, for this code:

SET A, 50
IFG A, 100
SET 0x8000, 33
BRK

the exclamation point shouldn't print because that instruction should be skipped, but it prints anyway. I get similar results for the other IF* commands. Is this a bug, or am I misunderstanding it?

This never halts:

JSR fx
SET PC halt

:fx SET PC, POP
:halt SET PC halt

It's compiling wrong; I haven't taken the time to work out why. Naming the label anything NOT containing x works fine; if it contains x, it never stops running. I think something funny's happening...

I may have misunderstood the manual, but I was a bit surprised that I couldn't do this:

ADD [sp], [sp+1]

and instead have to POP them up from the stack first.
Notch use something similar in his spec example ( SET [0x2000+I], [A] )

How does the other assemblers do this? Or am I fooling myself a bit here? :)

If the emulator is not throttled to the speed of the 'real' processor (100hz, I think) then I apologize. If it is, I'd like the ability to turn it off, so I don't have to wait to see if slow programs work as expected.

Consider

SET A, SP
SET [0x1+A], B

which stores B on the stack, 'below' the stack pointer. This could be written more efficiently as

SET [0x1+SP], B

I do not know if the DCPU is supposed to support this, but the emulator does not. Of course you have to emulate Notch's assembler exactly, errors and all, but this actually compiles without reported error and when run, always sets to the address 0x0.

Not strictly necessary at this stage, but there's a snippet of assembly floating around with Notch's name on it that supports parametric macros: http://0x10co.de/np4yl

Hi there,

LLVM backend has to emit the instructions like:

:autoinit       ;;Init data stack register C
    SET I, SP
    SUB I, 256

:autostart
    JSR main
:autohalt SET PC, autohalt
    ; .file "/home/jookia/Programming/YADOS/main.c"
    .text
    .globl  main
    ; .align    2
:main
    SUB I, 2 ; The Notch order
    SET [I], 0 ; The Notch order
    SET A, 1337 ; The Notch order
    ADD I, 2 ; The Notch order
    SET PC, POP ; The Notch order

.text, .globl, .align, .size and may be a few others. It's possible to disable output of some of them (like .align), but disabling .text .globl breaks LLVM test suite and makes it impossible to develop.

In the long run, DCPU16 assemblers will likely support these directives, because they are there for a reason. Since there's no demand for proper support of these directives from the users, but there's demand to use Clang/LLVM and there's no technical possibility to avoid emitting them, I would kindly ask Mappum assembler to ignore lines with these directives.

These directives always match the regex like "[\s]*[.]globl", so it should be pretty easy to ignore such lines.

The full list of directives to ignore (for now) is:

.globl
.size
.text
.data
.align

Console outputs every symbol from its memory, thus resulting in printing zeros like this:
http://dl.dropbox.com/u/59293229/console.jpg

Also console output is not flushed during reset (but 0x8000..0x8180 cells are zeros).

And maybe it will be better to have more height for console instead of inner vertical scroll.

In order to be sure that all fixed bugs are fixed, it's usually convenient to have regression tests.

One of the option is to use d8 shell from http://code.google.com/p/v8/ and run it on tests from https://github.com/krasin/dcpu16-tests/tree/master/asm

What's your opinion?

SET A, [B+3] fails to assemble, whereas SET A, [3+B] assembles fine.

It would be nice to have hex literals working. :)

If I've run a program that outputs to the console, and then I reset and write a program with a different output, the output from the previous program will still be there.

Is it planned to have the ability to read from stdin and write to stdout?

This case should emit 0x1a, not 0x18.

3D background is eating 100% of CPU at mine PC. Can we have an option to turn it of?

When I click the "run" button (against the demo code) and nothing happens. Checking the console I can see that a reference error exception is thrown because "display" isn't defined. This is triggered in line 212 of the inlined javascript in the index page.

Fairly self explanatory :P

Clicking the buttons at the bottom of the form appears to do nothing. I am not sure what the expected behavior is. I'm very interested in using this to test the output of a compiler I'm writing. I'm using firefox 10.0.2.

See title. Creating a function that attempts to write to those values does nothing.
0x1111
set [0x001f] 0x1111 does not work

set [0x0020] 0x1111 does work.

I know DAT is an implementation specific directive, but it seems lots of other people have allowed DAT to support multiple arguments. e.g.

DAT "hi"

works fine, but

DAT "hi", " there"

fails currently.

Minimal code to reproduce:

SET PUSH, 0xCDCD
SET A, 0xFFFF
IFN 0x0, POP
SET A, 0xABAB

Expected result: A = 0xABAB
Actual result: A = 0xFFFF

Since 'IFE 0x0, 0x0' does what's expected, this might be a problem with POP, not branching.

Nothing appear in the output screen and I don't know how to fix.

Do you have this problem too?

I believe there is a memory leak somewhere. The chrome process ended up using over a GB of memory after running a game of life program1.