I read the text about the gt1 file format from: https://github.com/kervinck/gigatron-ro ... -files.txt and have one question.
Here is written: "In essence, the file format is a list of n>0 segments of 1 to 256 bytes each."
if the "segmentSize" = 0 then i can load 1 byte or zero bytes.
If zero then how load 256 bytes at the same time (one page)? i must do two steps?
Not only can individual vCPU instructions not straddle 256 byte boundaries, also vPC will not increment it's high byte, you have to use CALL or CALLI in the current ROM's to stitch pages together, which can get hairy when trying to stitch the video off-screen segments together on a base 32k system.
The simplest architecture to start with, is to partition your code so that main starts at 0x0200 and put all your <96 byte subroutines into the offscreen video segments.
Anything more complicated than that needs to stitch the memory fragments together using some sort of thunking mechanism, gtBASIC and glcc both do this, so you could look at their source code for ideas.
The native interpreter that decodes vCPU instructions and handles vPC always pre-increments vPC by 2 before an instruction is decoded/executed, so generally when dealing within any addresses in vCPU land, you need to decrement your address by 2 before hand.
Note the BCC instructions can only branch within a 256 byte absolute page, so not relative to the current vPC high and low byte, but relative only to the vPC high byte. This is because BCC uses one byte for an address that just replaces the low byte of vPC, (with you the programmer having to take into account the 2 offset fixup).
So it looks more like this vPC=(vPC&0xff00)+D where D = address byte encoded into BCC instruction. If you want to branch to 0x20 in the current vPC 256 byte page, then you need to make D = (0x20 - 2) & 0x00FF, (the AND is not strictly needed as you are only using the low byte of that arithmetic anyway).
