Hello,
I'm studying ROM files and there's a question about that.
I attached a picture. It may be useful to understand my question.
The assembly instruction 'jmp' can do the 'far jump' action, so if 'jmp(Y,'vBlankStart')' is executed, we jump to 'vBlankStart'.
Then can 'SYS_Reset_36' be executed?
Even though the next line of 'jmp()' is already fetched and even executed, we should jump to 'vBlankStart' and do not come back to this line. This is how I understand.
I think 'SYS_Reset_36' part is executed when I do the soft reset, but then how can I reach that line? Ain't I need some code lines to approach there like pointing the line number?
As I browsed the whole code, no line branches to that label.
I need your help
Thx.
ROMv1.asm.py
Forum rules
Be nice. No drama.
Be nice. No drama.
ROMv1.asm.py
- Attachments
-
- asm.jpg (123.68 KiB) Viewed 8475 times
Re: ROMv1.asm.py
It's a SYS function/call, SYS functions are called from vCPU code like this:
Code: Select all
LDWI 0xFFFF ; 4 pixels
STW 0x24
LDWI 0xFFFF
STW 0x26
LDWI 0x0800 ; pixel address
STW 0x28
LDWI 0x04d4 ; SYS_Draw4_30
STW 0x22
SYS 30
loop BRA loop
Re: ROMv1.asm.py
A little bit before your screenshot, you'll see this piece of code:
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
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.
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])
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!!
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.