Previously, while rummaging for scan codes, I was correlating known behaviour with key codes. One of those keys was the Clear File key (0x56). I forgot to post about that find, but it's still worthwhile to mention the file clearing operation itself.
There's two flavors of file clearing:- a 'delete', which simple resets pointers and does not destroy data
- an 'erase', that clears the data in addition to resetting the pointers
These were easy to find because there are two different textual prompts in the image.
The first prompts for doing a 'delete' of the current file.
EEE1 promptAndDeleteFile_EEE1:
EEE1 BD F6 18 jsr clearHomeLCD_F618 ; Clear LCD set cursor pos 0
EEE4 CE FD F6 ldx #aAreYouSureYo_0 ; "Are you sure you want to delete"
EEE7 BD F6 69 jsr showText_F669 ; show nts text @ X
EEEA BD F7 4E jsr setcpLine1_F74E ; set cursor Line 1
EEED CE FE 16 ldx #aAllTheDataInThisFile?YN ; "all the data in this file?(y/n)"
EEF0 BD F6 69 jsr showText_F669 ; show nts text @ X
EEF3 waitKey_EEF3:
EEF3 BD E5 A0 jsr scanKbd_E5A0 ; do key scan and enqueue
EEF6 BD EB EE jsr dequeueKbdScanCode_EBEE ; pull scan code A (rowno|colno) from keyboard buffer; V set if empty, clear if valid
EEF9 29 F8 bvs waitKey_EEF3
EEFB 81 22 cmpa #$22 ; scan code for 'y'
EEFD 27 02 beq delete_EF01 ; empty it if 'y' pressed
EEFF 20 03 bra leave_EF04 ; skip if anything else
EF01 delete_EF01:
EF01 BD EB 9B jsr deleteThisFile_EB9B ; delete file by resetting pointers (recoverable)
EF04 leave_EF04:
EF04 20 D4 bra sub_EEDA
The real deleting work is at deleteThisFile_EB9B, but first the erase version:
EF06 promptAndEraseFile_EF06:
EF06 BD F6 18 jsr clearHomeLCD_F618 ; Clear LCD set cursor pos 0
EF09 CE FE 36 ldx #aAreYouSureYouWantToPermanently ; "Are you sure you want to PERMANENTLY"
EF0C BD F6 69 jsr showText_F669 ; show nts text @ X
EF0F BD F7 4E jsr setcpLine1_F74E ; set cursor Line 1
EF12 CE FE 5B ldx #aEraseAllTheDataInThisFile?YN ; "erase all the data in this file?(y/n)"
EF15 BD F6 69 jsr showText_F669 ; show nts text @ X
EF18 waitKey_EF18:
EF18 BD E5 A0 jsr scanKbd_E5A0 ; do key scan and enqueue
EF1B BD EB EE jsr dequeueKbdScanCode_EBEE ; pull scan code A (rowno|colno) from keyboard buffer; V set if empty, clear if valid
EF1E 29 F8 bvs waitKey_EF18
EF20 81 22 cmpa #$22 ; scan code for 'y' key
EF22 26 18 bne leave_EF3C ; leave if any key other than 'y'
EF24 FE 01 26 ldx word_126 ; this file; file region end addr (inclusive)
EF27 DF 4C stx byte_4C ; /this/ keyboard scan column no (also scratch when erasing file)
EF29 FE 01 28 ldx word_128 ; this file; file region start addr
EF2C BD EC 80 jsr selectRAMpageForFile_EC80 ; select in the relevant RAM page based on file number (byte_15D)
EF2F loopEraseFile_EF2F:
EF2F 6F 00 clr 0,x
EF31 08 inx
EF32 9C 4C cpx byte_4C ; /this/ keyboard scan column no (also scratch when erasing file)
EF34 26 F9 bne loopEraseFile_EF2F
EF36 BD EC 79 jsr selectRAMPage0_EC79 ; select 32 KiB RAM page 0
EF39 BD EB 9B jsr deleteThisFile_EB9B ; set pointers to empty file
EF3C leave_EF3C:
EF3C 39 rts
This is almost the same as promptAndDeleteFile_EEE1 except for the loop zeroing out memory from *word_128 to *word_126 (inclusive). So those are probably the start and end region pointers for the current working file.
While working on the keyboard stuff, there were some locations that seemed to be relevant for those routines, but I found them to be re-used for completely different purposes in other routines (such as these). byte_4C is a case in point. So I am re-interpreting these locations as being 'scratch' variables used for various things. So long as two routines are never in the same call chain, and that it's not a 'static' variable, that's OK.
OK, the actual 'deleting' is done via deleteThisFile_EB9B:
EB9B deleteThisFile_EB9B:
EB9B FC 01 28 ldd word_128 ; this file; file region start addr
EB9E FD 01 20 std word_120
EBA1 FD 01 22 std word_122
EBA4 FD 01 24 std word_124
EBA7 86 01 ldaa #1
EBA9 97 6B staa word_6B
EBAB 97 6C staa word_6B+1
EBAD 39 rts
Pretty straightforward -- just resetting some pointers. Who knows what they actually do, but we can now at least mark those locations as being 'current file related'.
The word_6b is quite a curiousity. I marked it as a word based on access patterns, but here we seem to be accessing it byte-wise, putting a 1 in both locations when the file is cleared. What could be a (1,1) pair at file clearing? Maybe (line, col), though I'm not sure why this product would need that since there is no display for such or 'goto' capability. Maybe it's used to associate the location on the screen as to where the pointer for 'insert point' is located. And for some reason it is 1-relative. Food for future thought.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.