A little bit before your screenshot, you'll see this piece of code:
Code: Select all
# vCPU reset handler
vReset = videoTable + 240 # we have 10 unused bytes behind the video table
ld((vReset&255)-2); C('Setup vCPU reset handler')
st([vPC])
adda(2, X)
ld(vReset>>8)
st([vPC+1], Y)
st('LDI', [Y,Xpp])
st('SYS_Reset_36', [Y,Xpp])
st('STW', [Y,Xpp])
st(sysFn, [Y,Xpp])
st('SYS', [Y,Xpp])
st(256-36/2+maxTicks, [Y,Xpp])
st('SYS', [Y,Xpp]) # SYS_Exec_88
st(256-88/2+maxTicks, [Y,Xpp])
This creates a vCPU program at address vReset (0x1f0) that calls SYS_Reset_36 using the vCPU opcode SYS (after storing the address of SYS_Reset_36 at location sysFn). It also set the vCPU program counter vPC to 0x1ee, so that the vCPU will execute this little program next. Your screen shows the point where the reset code jumps into the video loop (vBlankStart). This carefully timed loop generates all the VGA signals and executes vCPU instruction when there is spare time. From that point on, everything that happens in native code must be carefully timed.
As soon as there is time between VGA signals, the little vCPU program above runs and executes the SYS opcode. This transfers control to SYS_Reset_36 and continues the reset sequence. When the SYS opcode returns (i.e. when SYS_Reset_36 jumps to REENTER), another SYS opcode is executed, but this time sysFn is equal to SYS_Exec_88 (this was set by SYS_Reset_36). As a result the second SYS opcode loads and executes the vCPU code for the GCL program Core/Reset_v1.gcl.
Eventually Reset_v1.gcl executes
Code: Select all
{ Load and start main program }
\Main _sysArgs0= $200 _vLR= \SYS_Exec_88 _sysFn= 88!!
which loads and executes the main menu application.
So the native reset code just does the minimum and starts the video loop as early as possible. Everything else is achieved under vCPU control during the time slices that are left free in the video/sound/io loop. All versions of the ROM boot more or less in that way.