6502/PLASMA
1
0
Fork 0
mirror of https://github.com/dschmenk/PLASMA.git synced 2024-09-27 19:57:31 +00:00
Code Issues Projects Releases Wiki Activity

Tweak wording

ZornsLemma 2018-02-02 23:29:12 +00:00
parent d085885f1f
commit fb88e806e1
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Porting-Guide.md

@ -15,7 +15,7 @@ const addr = $4000
done
```
This allows the bytecode interpreter to be tested independently of "cmd". For example, after building an executable using the bytecode interpreter and the above mini "cmd", running it should store $1234 at address $4000 if the VM has started up correctly and the relevant VM opcodes have been implemented correctly - this can be verified using a debugger/monitor. (If you are porting to a 6502 system, it is highly likely the VM opcodes will be implemented correctly as you can use the Apple code almost unmodified, but this test is still useful as it shows that the VM has started up correctly and executed bytecodes.)
This allows the bytecode interpreter to be tested independently of the full and complex "cmd". For example, after building an executable using the bytecode interpreter and the above mini "cmd", running it should store $1234 at address $4000 if the VM has started up correctly and the relevant VM opcodes have been implemented correctly - this can be verified using a debugger/monitor. (If you are porting to a 6502 system, it is highly likely the VM opcodes will be implemented correctly as you can use the Apple code almost unmodified, but this test is still useful as it shows that the VM has started up correctly and executed bytecodes.)
If your system has no concept of terminal I/O (a games console or embedded system) or has no disks (needed by a full PLASMA implementation for random access to modules stored in files), the same technique allows you to write a PLASMA program which runs in place of the interactive "cmd" when the executable is started.