G1M Format - MCS - Lists and BCD

[cakeisalie5 Profile Website]

Hi! I have a problem with lists in the G1M format, but as lists are not described in Simon Lothar's documentation, I'll first describe what I know here, so that you correct me if I'm wrong.

So after the MCS header and the MCS file header, then there is a List Header that is the following :
- 8 bytes: probably the title
- 2 bytes: element count (big endian)
- 5 bytes: unknown (align?)
- 1 byte: unknown (but looks like it takes fixed values)

After that, we have the real parts list and, if there is at least one number with an imaginary part, the imaginary parts list. To detect if there is this imaginary parts list, I use the datalength field in the MCS file header and make a check on "is it long enough to contain more than a list header and a real parts list?". If you have a cleaner way of checking this, I'd like it.

So first of all, if I got any of this wrong, or if you know what the unknown bytes mean, please correct me.
Secondly, this method has worked pretty well, until I tried to parse BCD numbers. It works for the list of real-only numbers:

LIST1: Show

[libg1m info] g1m_parse_mcs: [2,0] directory name is 'main'
[libg1m info] g1m_parse_mcs: [2,0] filename is '1LIST1'
[libg1m info] g1m_parse_mcs: [2,0] file type is 'list' (0x05)
[libg1m info] g1m_parse_mcs: [2,0] data length is 136
[libg1m info] g1m_parse_mcs_list: Title is ''
[libg1m info] g1m_parse_mcs_list: Browsing 10 list elements
[libg1m info] g1m_parse_mcs_list: Cell #0 is (7).
[libg1m info] g1m_parse_mcs_list: Cell #1 is (6).
[libg1m info] g1m_parse_mcs_list: Cell #2 is (4).
[libg1m info] g1m_parse_mcs_list: Cell #3 is (9).
[libg1m info] g1m_parse_mcs_list: Cell #4 is (6).
[libg1m info] g1m_parse_mcs_list: Cell #5 is (9).
[libg1m info] g1m_parse_mcs_list: Cell #6 is (5).
[libg1m info] g1m_parse_mcs_list: Cell #7 is (9).
[libg1m info] g1m_parse_mcs_list: Cell #8 is (8).
[libg1m info] g1m_parse_mcs_list: Cell #9 is (4).

But for a test list with complex, it gets wierder. LIST2 has "5+2i" and "124", and here is the thing, with BCD value (and alignment bytes, in case) logging:

LIST2: Show

[libg1m info] g1m_parse_mcs: [2,1] directory name is 'main'
[libg1m info] g1m_parse_mcs: [2,1] filename is '1LIST2'
[libg1m info] g1m_parse_mcs: [2,1] file type is 'list' (0x05)
[libg1m info] g1m_parse_mcs: [2,1] data length is 64
[libg1m info] g1m_parse_mcs_list: Title is ''
[libg1m info] g1m_parse_mcs_list: Raw header:
[libg1m info] 0000 0000 0000 0000 000A 0000 8803 A53C ...............<
[libg1m info] g1m_parse_mcs_list: Browsing 2 list elements
[libg1m info] g1m_parse_mcs_list: They have complex parts!
[libg1m info] 9005 0000 0000 0000 00 .........
[libg1m info] 0000 00 ...
[libg1m info] 1002 0000 0000 0000 00 .........
[libg1m info] 0000 00 ...
[libg1m info] g1m_parse_mcs_list: Cell #0 is (-5^300)+(2)i.
[libg1m info] 1021 2400 0000 0000 00 .!$......
[libg1m info] 0000 00 ...
[libg1m info] 8004 1D44 FFFF FFFF 80 ...D.....
[libg1m info] 1629 28 .)(
[libg1m info] g1m_parse_mcs_list: Cell #1 is (124)+(-41=44????????8^187)i.

Why does it have 0xD and 0xF values? It thought it would be zero'd, but it isn't, so am I supposed to only read it if valid? If this is the case, how can I know this?

You can grab the source code here ^^

[SimonLothar]

If at least one cell of a "LIST n" contains a number with an imaginary part, the BCD-list of real numbers of this "LIST n" is followed by a BCD-list of imaginary numbers of the same count.
It looks as if an imaginary number can be detected by the leftmost bit of the exponent.
F. i.
90 05 00 00 00 00 00 00 00 00 00 00 (5 with some imaginary part)
10 05 00 00 00 00 00 00 00 00 00 00 (5 without imaginary part)
E0 05 00 00 00 00 00 00 00 00 00 00 (-5 with some imaginary part)
60 05 00 00 00 00 00 00 00 00 00 00 (-5 without imaginary part)

T. i., if there is at least one number with an imaginary part, the length of the complete BCD-list is double the size.

In the BCD-list of imaginary parts only these entries are significant, which correspond to an entry in the real part BCD-list, which is designated to have an imaginary part (leftmost bit of the exponent set).
The other entries of the imaginary part BCD-list
f. i. 80 04 2D 78 FF FF FF FF 80 16 39 98
seem to be meaningless. It looks as if they grab some RAM from heap or stack to build the imaginary part BCD-list and only initialize the significant entries, leaving the meaningless parts untouched (f. i. some previously used values on stack or heap, which look to be random).

[cakeisalie5 Profile Website]

Works great ! Thanks a lot