mcsfs
reverse engineering the Classpad 300 MCS filesystemMemory layout
Here's a rough sketch of what the memory layout looks like for folders, files and data.If you want to get more info on bits and bytes, read on below.
Folder content aka variables
Folder: "LuaNumAn"Address: 0x0000279c
Internal folder number: 10
Content: 14 files
File entries listed in example: "Bisect", "Brent"
struct VALMANSTRUCT {
0000279c 42 69 73 65 63 74 00 00 NAMEBUFFER naName = "Bisect"
000027a4 00 00 01 18 DWORD dwOffsetAdr = 280 Byte // relative to 0x0000279c
000027a8 00 00 03 28 DWORD dwDataSize = 808 Byte // incl. header and padding bytes
000027ac 4e UCHAR ucType = 78
000027ad 00 UCHAR ucFlag = 0
000027ae 00 UCHAR ucReserve = 0
000027af 0a UCHAR ucFolderNo = 10
};
struct VALMANSTRUCT {
000027b0 42 72 65 6e 74 00 00 00 NAMEBUFFER naName = "Brent"
000027b8 00 00 04 40 DWORD dwOffsetAdr = 1088 Byte // relative to 0x0000279c
000027bc 00 00 05 64 DWORD dwDataSize = 1380 Byte
000027c0 4e UCHAR ucType = 4e
000027c1 00 UCHAR ucFlag = 0
000027c2 00 UCHAR ucReserve = 0
000027c3 0a UCHAR ucFolderNo = 10
};
..... // next folder entry
File header of "LuaNumAn/Bisect" (a CPLua script)
The first file of the above folder.
FILE HEADER: // 4 byte aligned
000028c4 0c 08 01 00 // the magic number, probably RTTI info
// maybe class CPMEMFileHeader or atleast a
// struct used inside the class invisible to the user
000028c8 4c 75 61 00 00 00 00 00 20 chars for m_AppName = "Lua" ... "Source"
00 00 00 00 53 6f 75 72 // "Source" starts 4 byte aligned, so this might
63 65 00 00 // be a sign of this data being actually 2 strings
// and maybe something else in between
000028cc 31 30 3e 6a c1 d9 // unknown
000028d2 03 07 WORD dataSize = 775 Byte
File contents
Starts right after the above file header.Basically just huge zero-delimited string.
Padded with zero bytes to end on a 4 byte limit
FILE DATA: // 4 aligned (and padded)
000028d8 72 65 71 75 69 72 65 28 char[] = "require("Lua"....
22 4c 75 61
......
