Hi,
I am a newbie of mc9sdp512 ucontroller. I am digging a CF file issue for my company and I had a hard time to understand some legacy asm code.
The following is the code:
_gfOpen::
pshx
tfr d,x ;file name pointer is in accd
lda 5,sp ;get drive num and operation type
ldb #14
swi
clra
pulx
rts
What I don't understand is that after load 14 to accumulator b and call software interrupt. The file on CF card is open "magically". How it is opened I don't know. Here in the vector table, swi is defined as this:
word swiHndl ;$fff6 SWI
this is swiHndl:
swiHndl:
tsx
xgdx ;accd = sp of current stack
jmp jOS_call ;do OS_call
And jOS_call:
jOS_call:: jmp 0 ;operating system call
Anyone can hlep me figure how the file on the CF card is opened?
Hi Kef,
Thanks for the reply. The snippet in my question is a combination of asm code I grabbed from different place to make them make sense. However I just don't understand what makes them meanningful. I found one more cacro def in one of header file like this:
.macro fileOpen
ldab #_FLASH_OPEN ;file open function call
swi ;result code/filenumber in accb, x:y = file size
.endmacro
swi is the same as what I posted
Still does not make sense.
I think OS routine is expected at address 0. It seems OS function number is passed to OS routine in register B. This makes sense.
Do you wonder how pointer to file name is passed to OS routine? Yes, I also don't see how it is done. Pointer to file name seems to be passed to _gfOpen in reg D, then it is transferred to reg X and finally SWI call is made. But swiHndl overwrites reg X with SP, so I don't know how _gfOpen is passing file name to OS routine.
The file name is in reg x. At the beginning of gfOpen, pshx save it in memory and then tfr d, x will copy it to d. Eventually, when the file is opened, the size of the opened file is in y. What I don't understand is this:
ldb #_FLASH_OPEN ( _FLASH_OPEN = 14)
why put a int 14 to b before swi? and how software int can do file operation like this?
And about address 0, is it address of register PORTA? I got this line from the Freescale spec 9SDP256BDGV2:
Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
$0000 PORTA
Read:
Bit 7 6 5 4 3 2 1 Bit 0
Oh yes, swi handler can access file name pointer pushed previously to the stack. It is transferred from d to x, but later x is destroyed doing tsx.
Why not? SWI doesn't change any CPU register. What you load to any CPU register before SWI, everything will be passed to SWI handler.
Yes, but S12D allows register, EEPROM and RAM remapping. So your legacy code could move registers block away from 0 and map here RAM or EEPROM with some code.
Based on your reply, I understand this is what happened:
swi actually does the magic to open file, and the integer #_FLASH_OPEN is passed to swi to ask it to open file.
The bits in reg x: I have no clue how the file name can survive after tsx
I had that thought while we talk back and forth. However I have no idea how you figure out reg x is pushed to sp+9. I check the chip spec and it says x will be pushed to sp-4 and sp-5.
This is what I got from spec:
Table 5-5. Stacking Order on Entry to Interrupts
Memory Location CPU Registers
SP PCL
SP–1 PCH
SP–2 IYL
SP–3 IYH
SP–4 IXL
SP–5 IXH
SP–6 ACCA
SP–7 ACCB
SP–8 CCR
Could you tell me how you get the mem location of SP+9 as where reg x is pushed? Thanks!
Oh, my mistake. Comment in gfOpen states that file name pointer is in D, and I thought it was in X and pushed to the stack. And contents of X, that was pshx'ed in gfOpen is available in the SWI handler at SP+9. Your list of stacked registers confirms that. 2bytes X + 2 bytes Y + A + B + CCR + 2 bytes PC = 9 bytes.