0x80 == -3?

The bug that gave me -3 when reading 0x80 from a file was confusing me. Why did it convert to -3 and not -127? When I read from a file that started with the bytes 0xB2,0x80 I could read 0xB2 as -78, but 0x80 seemed to be read as -3.

First I thought there was something wrong with the read function, so I looked through the implementation of READ_BYTES in c_memory.c. The function cMemoryReadFile to be more specific. I suspected that perhaps there was a problem reading byte by byte with the READ_BYTES because I couldn’t find any other LMS file that did it, except for some test LMS code. So to verify that reading byte by byte was ok I swapped the data in the file so it read 0x80,0xB2 and I ran into the same problem.

The data I got from 0x80,0xB2 was -3 and -78. So there didn’t seem to be a problem with the READ_BYTES function after all. After that I decided to create a 256 byte file that contained every value from 0x00 to 0xff, and see what data I got. This is the result:

Print loop 0
Print loop 1
Print loop 2
Print loop 3
Print loop 4
Print loop 5
Print loop 6
Print loop 7
Print loop 8
Print loop 9
Print loop 10
Print loop 11
Print loop 12
Print loop 13
Print loop 14
Print loop 15
Print loop 16
Print loop 17
Print loop 18
Print loop 19
Print loop 20
Print loop 21
Print loop 22
Print loop 23
Print loop 24
Print loop 25
Print loop 26
Print loop 27
Print loop 28
Print loop 29
Print loop 30
Print loop 31
Print loop 32
Print loop 33
Print loop 34
Print loop 35
Print loop 36
Print loop 37
Print loop 38
Print loop 39
Print loop 40
Print loop 41
Print loop 42
Print loop 43
Print loop 44
Print loop 45
Print loop 46
Print loop 47
Print loop 48
Print loop 49
Print loop 50
Print loop 51
Print loop 52
Print loop 53
Print loop 54
Print loop 55
Print loop 56
Print loop 57
Print loop 58
Print loop 59
Print loop 60
Print loop 61
Print loop 62
Print loop 63
Print loop 64
Print loop 65
Print loop 66
Print loop 67
Print loop 68
Print loop 69
Print loop 70
Print loop 71
Print loop 72
Print loop 73
Print loop 74
Print loop 75
Print loop 76
Print loop 77
Print loop 78
Print loop 79
Print loop 80
Print loop 81
Print loop 82
Print loop 83
Print loop 84
Print loop 85
Print loop 86
Print loop 87
Print loop 88
Print loop 89
Print loop 90
Print loop 91
Print loop 92
Print loop 93
Print loop 94
Print loop 95
Print loop 96
Print loop 97
Print loop 98
Print loop 99
Print loop 100
Print loop 101
Print loop 102
Print loop 103
Print loop 104
Print loop 105
Print loop 106
Print loop 107
Print loop 108
Print loop 109
Print loop 110
Print loop 111
Print loop 112
Print loop 113
Print loop 114
Print loop 115
Print loop 116
Print loop 117
Print loop 118
Print loop 119
Print loop 120
Print loop 121
Print loop 122
Print loop 123
Print loop 124
Print loop 125
Print loop 126
Print loop 127
Print loop -3
Print loop -127
Print loop -126
Print loop -125
Print loop -124
Print loop -123
Print loop -122
Print loop -121
Print loop -120
Print loop -119
Print loop -118
Print loop -117
Print loop -116
Print loop -115
Print loop -114
Print loop -113
Print loop -112
Print loop -111
Print loop -110
Print loop -109
Print loop -108
Print loop -107
Print loop -106
Print loop -105
Print loop -104
Print loop -103
Print loop -102
Print loop -101
Print loop -100
Print loop -99
Print loop -98
Print loop -97
Print loop -96
Print loop -95
Print loop -94
Print loop -93
Print loop -92
Print loop -91
Print loop -90
Print loop -89
Print loop -88
Print loop -87
Print loop -86
Print loop -85
Print loop -84
Print loop -83
Print loop -82
Print loop -81
Print loop -80
Print loop -79
Print loop -78
Print loop -77
Print loop -76
Print loop -75
Print loop -74
Print loop -73
Print loop -72
Print loop -71
Print loop -70
Print loop -69
Print loop -68
Print loop -67
Print loop -66
Print loop -65
Print loop -64
Print loop -63
Print loop -62
Print loop -61
Print loop -60
Print loop -59
Print loop -58
Print loop -57
Print loop -56
Print loop -55
Print loop -54
Print loop -53
Print loop -52
Print loop -51
Print loop -50
Print loop -49
Print loop -48
Print loop -47
Print loop -46
Print loop -45
Print loop -44
Print loop -43
Print loop -42
Print loop -41
Print loop -40
Print loop -39
Print loop -38
Print loop -37
Print loop -36
Print loop -35
Print loop -34
Print loop -33
Print loop -32
Print loop -31
Print loop -30
Print loop -29
Print loop -28
Print loop -27
Print loop -26
Print loop -25
Print loop -24
Print loop -23
Print loop -22
Print loop -21
Print loop -20
Print loop -19
Print loop -18
Print loop -17
Print loop -16
Print loop -15
Print loop -14
Print loop -13
Print loop -12
Print loop -11
Print loop -10
Print loop -9
Print loop -8
Print loop -7
Print loop -6
Print loop -5
Print loop -4
Print loop -3
Print loop -2
Print loop -1

Each line number correspond to the value read from the file, so line 40 read the value 40 (0x28) from file, and line 220 read the value -36 (0xDC). As you can see on line 128 we read the value 0x80 and for some reason the VM gives us the value -3.

That lead me to investigate the -128 thing more. Trying to simply assign -128 to a DATA8 variable give me the VM PROGRAM VALIDATION error on the Brick. I also tried to assign 128 to a DATA8 just to see there was no funny business going on and that gave the same error.

So there you have it. The VM doesn’t seem to support -128 for DATA8.

Normally I wouldn’t really care as -128 works with DATA16 but the fact that the RGF file format start with two unsigned bytes that just cannot be read and trusted from the VM is a bit annoying. It means I would have to create my own file format to blit images from memory instead of blitting from “file”.

This, in combination with all values being signed, means I need to store values greater than 127 as DATA16, and values I want to have greater than 32767 is DATA32.

Also, the NUMBER_TO_STRING function also only accept DATA16, and there doesn’t seem to be any bitmask operations, so I still don’t know how to convert a 32 bit number to a string. There is a SELECTx function that I’ll look into.

Leave a Reply