blob: 85ab792a716f06d0f649c16f3f6d4dce7855060e (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
# interpreter
This is a small program intended to help with testing the 6502 CPU, or running programs on it.
The expected input is machine code written in plaintext.
The program assumes you will write statements correctly so it doesn't waste time checking that you put four digits in instead of three. If you are using this I assume you know what you are doing.
The program accepts stdin, so it can be used in two ways.
- Typing instructions inline.
- Piping a file in with cat.
## Instructions
To express the syntax of instructions, here are some valid examples to express LDA $01:
a901
A901
A9 01
If you downloaded my project on Github, I have included a PDF called `opcodes_reference.pdf` which has a table with every legal opcode in it.
Statements can be seperated or on a single line. For instance,
a901
p
q
Can be written as
a901pq
The only case in which this should be avoided is after an M/m command.
## Debug Commands
The interpreter comes with multiple statements for the purpose of debugging the emulator.
`Q/q` Quits the program.
`R/r` Resets the virtual computer.
`P/p` Dumps processor state.
`M/m` Prints out memory.
There are two forms which memory can be printed.
The first is `sXX` where `XX` is a memory page. The whole page of memory is printed onto the screen.
The second is `sXXXX` where `XXXX` is a specific address. This prints out the value of the 1 byte requested.
Be aware that unallocated memory will be dumped if it happens to be accessed with this command.
`S/s` Directly set a piece of memory.
Syntax is strictly of form `sXXXX.xx` where `XXXX` is the address and `xx` is the value.
`/` Prints until newline.
`#` Ignores until newline.
## Anomalies
I don't care a whole lot about making this interpreter foolproof since its mostly for my personal debugging use. There are a couple anomalies to look out for if you intend to write programs with it.
1. After M/m command, a newline is *necessary* or it will have unexpected behavior.
2. Two newlines are necessary after single byte-length instructions or it will segfault.
3. If Q/q is not used at the end of a program, it will segfault. It's inconsequential if it does, but it's important to know.
|
