So far with my initial testing everything is working except DIM, registers and strings.   Chip files like this assemble to a file containing the same bytes shown on the Vetus Pars view code screen.

[chipfile]
type = single

[chips]

---

[meta]
name = sandbox
pins = 14
type = 4
imageIndex = 2

[code]
LOOP 0xa 0x0 0x0
     CALL shiftLED
ENDLOOP 0x0 0x0 0x0

ENDTEST 0x0 0x0 0x0

FUNC shiftLED
     LEDON 0x0 0x0 0x0
     DELMS 0x12C 0x0 0x0
     LEDOFF 0x0 0x0 0x0
     DELMS 0x12C 0x0 0x0
ENDFUNC

[strings]
0=
1=
2=
3=
4=
5=
6=
7=

[ENDCHIPS]

DIM is now finished.  I also added /* */ and ; comments support.

It looks like Strings are uploaded to the device, so there isn't anything for the assembler to do with that yet.

Can you explain a little bit about how Registers are handled?   In the Code View on the Vetus Pars it shows #R0, but I'm assuming that's just for viewing.  What bytes are actually created when the assembler generates the machine code?

Registers are a little different and you're getting into things Vetus needs to do internally, that will be out when I get the docs done but I can tell you that the registers are obviously an array within the firmware so we need a way to tell which register we want to use. We can use a literal number 0x1 for instance, and that will work just fine anytime we want to tell Vetus which register we are talking about but there are many times where we have the choice between a literal number and a register value. In that instance, we need to differentiate between a literal number and a register index. To do that we use 0x80000000 where 0x80000000 is index 0, 0x80000001 is index 1 and so on up to 32. So when we want a value from the register we give it the 0x8000000n value and if we are talking about the register index itself we just give it a normal value. Vetus Pars takes care of translating it. 

The compiler now will report compilation errors, where they are, and parameter information.   
Also don't have to pad 0x0 anymore.   If you leave them out it will add them automatically since it knows the number of parameters each opcode requires.

./vp-asm.py ./chip-samples/sandbox-bad.chip ./output/sandbox-bad.chipout
=== vp-asm v1.00.00 ===
Assembly error: Assembly failed with 5 errors:
Line 12: Unknown instruction: FOO
Line 16: SET8 missing required parameter(s): Index, Address, In/Out (expected 3, got 0)
Line 17: SET8 missing required parameter(s): In/Out (expected 3, got 2)
Line 18: SET8 has too many parameters (expected at most 3, got 4)
Line 21: Unknown function: shiftLED2

./vp-asm.py ./chip-samples/sandbox.chip ./output/sandbox.chipout
=== vp-asm v1.00.00 ===
Assembly successful.
Wrote 48 bytes.

Hopefully the machine code generated is equivalent to your GUI.   We will find out once I can upload to the Vetus Pars.

Thanks.  That was very helpful.   

I made a very rudimentary loader this evening that sends the chipout data and some hardcoded strings and meta data.    It needs a LOT of polish and testing, and I still need to update it to read from the chip file instead of hardcoded placeholders, but I got it uploading, and uploading with save functional.

At the moment everything is done in Linux.  When I get it all documented and tested on Mac and PC, I'll give you access to my Git server so you can go over it yourself.

I don't code in python daily, so it's been fun working in something different.

./vp-loader.py --port /dev/ttyACM0 --chip ./output/sandbox.chipout --name sandbox --type 1 --pins 14 --image-index 2
Strings: 100%|████████████████████████████████████████| 9/9 [00:00<00:00, 13.93it/s]
Code: 100%|███████████████████████████████████████████| 1/1 [00:00<00:00, 13.91it/s]
Chip upload complete.