The gist of this unit is that you type text into a discrete 'file' and then you can edit and later transfer to a separate computer via the keyboard emulation.  While whizzing through the code doing other things, various strings caught my eye, such as:

FCFD 50 65 72 66+aPerformingEmer:fcc "Performing emergency recovery of"
FCFD 6E 67 20 65+       fcb 0
FD1E 66 69 6C 65+aFile: fcc "file "
FD1E 20 00              fcb 0

FD29 46 69 6C 65+aFileIsFull_Use:fcc "File is full.  Use another file or"
FD29 66 75 6C 6C+       fcb 0
FD4C 73 65 6E 64+aSendDataToYour:fcc "send data to your computer."
FD4C 61 20 74 6F+       fcb 0

FDF6 41 72 65 20+aAreYouSureYo_0:fcc "Are you sure you want to delete"
FDF6 73 75 72 65+       fcb 0
FE16 61 6C 6C 20+aAllTheDataInThisFile?YN:fcc "all the data in this file?(y/n)"
FE16 64 61 74 61+       fcb 0

FE36 41 72 65 20+aAreYouSureYouWantToPermanently:fcc "Are you sure you want to PERMANENTLY"
FE36 73 75 72 65+       fcb 0
FE5B 65 72 61 73+aEraseAllTheDataInThisFile?YN:fcc "erase all the data in this file?(y/n)"
FE5B 6C 20 74 68+       fcb 0

I had already associated all these with their referring locations in the code, but the file system itself has not been worked out.  One thing I noticed in the 'start' initialization code (and one other place in the keyboard scan routine) is a call this:

EB74             sub_EB74:
EB74 CE 01 2A        ldx     #$12A
EB77 18 CE FB 24     ldy     #$FB24
EB7B             loop_EB7B:
EB7B 18 EC 00        ldd     0,y
EB7E ED 00           std     0,x
EB80 ED 02           std     2,x
EB82 ED 04           std     4,x
EB84 C6 06           ldab    #6
EB86 3A              abx
EB87 C6 04           ldab    #4
EB89 18 3A           aby
EB8B 8C 01 58        cpx     #$158
EB8E 25 EB           bcs     loop_EB7B
EB90 86 01           ldaa    #1 it
EB92 B7 01 5D        staa    byte_15D
EB95 BD EA F9        jsr     sub_EAF9        ; XXX file open related
EB98 8D 01           bsr     sub_EB9B        ; XXX file open related
EB9A 39              rts

Which seems to be copying an array of 2-word structures in ROM to an array of 3-word structures in RAM.  (And the elements might not be words; the code might just be trying to bulk transfer more efficiently.  We'll find out later.)  As per the terminating condition (less than $0158), this means there are eight entries.

The fact that the source is 2-word and the dest is 3-word suggests that the extra word is some ephemeral quantity, hence not in the ROM image.

FB24        word_FB24:
FB24 01 60    fdb $160
FB26 7F FF    fdb $7FFF
FB28 01 00    fdb $100
FB2A 3F FF    fdb $3FFF
FB2C 40 00    fdb $4000
FB2E 7F FF    fdb $7FFF
FB30 01 00    fdb $100
FB32 3F FF    fdb $3FFF
FB34 40 00    fdb $4000
FB36 7F FF    fdb $7FFF
FB38 01 00    fdb $100
FB3A 2F FF    fdb $2FFF
FB3C 30 00    fdb $3000
FB3E 5F FF    fdb $5FFF
FB40 60 00    fdb $6000
FB42 7F DE    fdb $7FDE

Just an intuition:  knowing that the external RAM is mapped from 0x100-0x7fff, could these be the file partitions?  In particular, the first one starts at 0x0160, which is the first byte after all referenced RAM that I have found so far.  Whereas the others start at 0x0100, which is the start of external RAM disregarding the system usage.  So my hypothesis is that these are the file partition definitions, as [start,end].  This jibes with my earlier observation of 'page 0 has system variables, and is usually selected in, except in specific, localized cases'.  I know also that this device had some fixed number of 'files'.

I'm embarrassed to admit that in my enthusiasm to hack that it didn't occur to me to first download the user manual for this contraption!  So, doing so, I find that yes there are 8 'files', of varying maximal sizes that you cannot change.  The manual expresses them in terms of 'pages' of text, but later also states that there is "a total capacity of 64 pages, or 128,000 bytes".  So the values are approximate, based on 2,000 char/page.  Computing from this table:

File#   Start   End     Size    Manual Stated Size
1       0160    7FFF    32,416  16 pages (32,000 char)
2       0100    3FFF    16,128   8 pages (16,000 char)
3       4000    7FFF    16,384   8 pages (16,000 char)
4       0100    3FFF    16,128   8 pages (16,000 char)
5       4000    7FFF    16,384   8 pages (16,000 char)
6       0100    2FFF    12,032   6 pages (12,000 char)
7       3000    5FFF    12,288   6 pages (12,000 char)
8       6000    7FDE     8,158   4 pages ( 8,000 char)

This coincidence is too strong to ignore, so I think this is the file partition table.  Some observations:

• only the first field from ROM (start address) is copied to RAM, and copied into all three RAM structure entries.  The end address is not.  This suggests to me that the three RAM file entries might be 'start', 'current end', 'current position'.  This is purely a hunch.  Further discoveries could negate that hypothesis.
• the first entry offsets at 0x0160, which as mentioned is the start of otherwise unreferenced RAM.  So that 'file' is probably on RAM page 0.  The others start at 0x0100.  This is consistent with the first RAM page having system variables, and the others being just user data (files).  It also is consistent with the hypothesis that the 'quiescent' state might be to keep page 0 selected so those variables are available in the general case.  Maybe.  Many of the system variables are in the IRAM 0x40-0xbf which doesn't require paging.
• this table does not indicate what RAM page these files are on.  Our human biases will easily assume that these are sorted, and that file 1 is on page 0, files 2,3 are on page 1, files 4,5 are on page 2, and files 6,7,8 are on page 3.  This is reasonable, but the computer does not share these biases, so somewhere there is some logic or a table mapping file number to mapped RAM page.  As few files as there are, it could be done in logic rather than a table.  I'll have to be on the lookout for some 'switch' like constructs that select RAM page mappings from file numbers.

Having the manual in-hand is useful also in that it lists all the control codes and F-key functions.  Well, the documented ones.  There are clearly two magic buttons that you can hold down when powering the unit on that do things that are not documented in the manual.  Nothing too exciting -- invoking a memory test and clearing all memory.  But still.

Also, the manual mentions password protection of files.  This is default 'off', but you are meant to contact customer support to get the 'master password' that will unlock the feature.  Then your files become password protected with a default of 'secret'.  Now this is amusing!  However I don't think that feature is in this firmware because the prompts referenced in the manual do not exist in the image.  So maybe the manual I have is for a later version than this v2.03 device.  Oh well.  That scheme would have been fun to pick apart!