cmpxchg wrote: ↑13 Jul 2019, 18:24
I would like a bit more guidance to make an informed decision on what (two) items to vote in the poll
There's no hurry. The poll is open until the end of September
Knowing the expected instruction mix in existing vCPU programs and added value, speedups for example.
De concept proposals above are as concrete as I can make them without actually implementing, testing and characterising.
Is this the complete document that defines 'vCPU binary compatibility' ?
It looks like you found links to (some of) the documents in the
Docs/ directory of the ROM repository. That's where we intend to maintain all ROM documentation.
- are all opcode/mnemonic arguments 16 bit or sometimes also 8 bit ?
Code: Select all
The vCPU interpreter has 34 core instructions. [..]
Most instructions take a single byte operand, but some have two and others none.
The formulas are pseudo-formal. Better take them with a grain of salt.
Mnem. Encoding #C Description
----- --------- -- -----------
ST $5E DD 16 Store byte in zero page ([D]=vAC&256)
STW $2B DD 20 Store word in zero page ([D],[D+1]=vAC&255,vAC>>8)
LD $1A DD 18 Load byte from zero page (vAC=[D])
LDI $59 DD 16 Load immediate small positive constant (vAC=D)
LDWI $11 LL HH 20 Load immediate word constant (vAC=$HHLL)
So 'DD' or 'D' are intended to represent a single byte. 'LL HH' is intended to represent a 16-bit word in little-endian order. '[X]' is intended to represent a RAM location, as in the native instruction set. 'vAC=D' is intended to mean that the (16-bits) vAC gets the (unsigned) 8-bit value D, and therefore clearing its high 8 bits in the process.
- the width and signed/unsignedness of each register,
From the same link:
Code: Select all
The virtual regisers are 16-bits (except vSP) and reside in the zero page.
vAC is the virtual accumulator [...]
vPC is the virtual program counter [...]
vLR is the link register [...]
vSP is the stack pointer. The stack lives in the zero page top and grows down.
So vAC, vPC and vLR are 16-bits, and vSP is 8-bits.
Registers don't have a signedness by themselves. They're just untyped bits as in any other processor. Some instructions must interpret them in a certain way however. The only ones where this matters for us are BGT, BLT, BGE, BLE: they treat vAC's contents as signed as they compare vAC to zero (>0, <0, ≥0, ≤0). ADDxxx and SUBxxx instructions don't care about the sign because of the two-complement interpretation by these four.
and other state inside the vCPU
From the README.md file in the
top level of the repository (the one that GitHub displays) we have these:
Code: Select all
[Note: In the next section, names in parentheses refer to *internal*
variables that are subject to change between ROM versions. See for a
more detailed explanation on compatibility the file Docs/GT1-files.txt]
Address Name Description
-------- ------------- -----------
0015 (vTicks) Remaining interpreter ticks (=units of 2 CPU cycles)
0016-0017 vPC Interpreter program counter, points into RAM
0018-0019 vAC Interpreter accumulator, 16-bits
001a-001b vLR Return address, for returning after CALL
001c vSP Stack pointer
001d (vTmp) Scratch storage location for vCPU
001e (vReturn) Return address (L) from vCPU into the loop (H is fixed)
So there are more variables holding vCPU state, but they tend to change between ROM versions.
- method/library/call interface/ROM offsets for more complex functionality 'BIOS calls/software interrupts', framebuffer, character set
That's what SYS extensions do.
Docs/SYS-functions.txt attempts to document how the mechanism works. It's a summary of several explanations given here in the forum and from comments in the source code.
There are numerous example programs in
Apps/ that people use to figure out how to do specific things with them. The simpler ones (
Blinky,
HelloWorld) and the more recent ones (
TinyBASIC) are much better commented than the older ones (
Racer).
The online
BASIC tutorial goes pretty far in explaining the video and sound system.
At first glance it seems hardly more functional than the native hardware CPU instructionset, except 16 bit
- but still having the same-ROM page limitations everywhere.
From the first paragraph of the document you linked to:
Code: Select all
vCPU's advantages over native 8-bit Gigatron code are:
1. you don't need to think about video timing with everything you do
2. operations are 16-bits, and
3. programs can run from RAM.
- Is the reason we have applications at all: even Snake wouldn't exist without vCPU. The cycle counting to properly generate horizontal sync pulses every 200 cycles is tedious for regular application level code. In theory it can also be handled by a compiler, but nobody has walked that path yet.
- Is not really essential, although it makes it easier to build typical applications quickly. It's also more efficient than handling just 8-bits worth of data per instruction (more "bang per buck").
- Is the reason you can load programs into the Gigatron with Loader and without changing the EPROM.
perhaps better formatting in a table and releasing it as a PDF like other CPU instructionsets makes it easier to understand.
I believe everything is documented and every question gets a decent answer (and that often results in documentation updates as well). That has led to quite a few programs, emulators, and even a C compiler. Reconciling, in a PDF version, what we have written down already is an excellent suggestion for a next phase. Thank you!
2.
Then, the vCPU binary compatibility is technically not needed - the hardware is executing the 128 kbyte ROM code - but since it is currently not user-programmable (no ROM emulators in wide usage), I understand your wish of defining a new variant to having 'binary compatibility' for vCPU programs loaded and interpreted in the 32 kbyte RAM, using the vCPU in ROM. Perhaps also to maintain pluggyMcPlugface compatibility.
We don't want to render existing programs worthless by making arbitrary incompatibility changes. People put a lot of effort into making those programs. When they share them in Contrib/ as .gt1 files, we even make an effort to test them as well.
3.
Are there any suggestions for suitable off-the-shelf EPROM emulators for users that want to run their own ROMs and experiment at that level ?
Perhaps that's best discussed in a different thread. The FAQ has some ideas.