MPASM Bug with 18F Tables

[Nobody/Anonymous]

MPASM seems to have a problem with any line longer than about 200 characters. Using PIC18F tables in GCBasic with all the values on one DB line in the asm file you end up with a truncated table in the hex file. Here is some sample code -

'Chip settings
#chip 18F4320, 8
#config OSC = INTIO2, PWRT = ON, MCLRE = OFF, WDT = OFF

Main:
ReadTable LongTable, 1, Test
goto Main

Table LongTable
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
end table

When I compile this there are no errors and the asm file looks fine but in the hex file the table only goes up to just past 63. Can anyone else confirm this with MPASM. I've tried it with MPLAB 7.6 and 8.14. If I edit the db line in the asm file and split it in half the table is ok.

Frank

[kent_twt4]

Don't have the solution for table length, but have you tried it in EEPROM?  Look here for a note on it from the developer.  http://gcbasic.sourceforge.net/update.html

[Hugh Considine]

Fixed in http://gcbasic.sourceforge.net/newfiles/update.zip , GCBASIC will now split the db lines if they exceed 80 characters. Hopefully that is a safe limit!

[Nobody/Anonymous]

Well Hugh, it appears that there is another complication here.  The DB statements must have an even number of items on each line or it adds another byte to the table.  So when you break the DB into 80 character, you will need to count the entries to make sure they are even, unless its the end of the table.  Keep up the good work!

[Nobody/Anonymous]

Here's test code to reproduce the extra byte on any DB line with odd number of bytes.  Inside MPLAB shows ok, dissassembly shows correct.  But program memory or the hex download file have an extra byte at position 101 in the table (will compile with an odd byte count at that DB statement).  See code below to reproduce.  bytTest will come back as 00 instead of 95. I'm using MPASM dated 5/12/08.

'Chip model
#chip 18F4550, 8
#config FOSC = INTOSCIO_EC, MCLRE = ON

'Main routine
Start:

Readtable tblTable, 101, bytTest

End

Table tblTable
255
255
255
255
255
255
255
255
255
248
241
235
229
224
219
215
211
207
203
200
196
193
190
188
185
183
180
178
176
173
171
169
167
165
164
162
160
158
157
155
154
152
151
149
148
146
145
144
142
141
140
139
137
136
135
134
133
132
131
130
128
127
126
125
124
123
122
122
121
120
119
118
117
116
115
114
113
113
112
111
110
109
108
108
107
106
105
104
104
103
102
101
101
100
99
98
98
97
96
96
95
94
93
93
92
91
91
90
89
89
88
87
87
86
85
85
84
83
83
82
81
81
80
79
79
78
78
77
76
76
75
74
74
73
73
72
71
71
70
69
69
68
68
67
66
66
65
64
64
63
63
62
61
61
60
59
59
58
58
57
56
56
55
54
54
53
53
52
51
51
50
49
49
48
47
47
46
45
45
44
43
43
42
41
41
40
39
39
38
37
37
36
35
34
34
33
32
31
31
30
29
28
27
27
26
25
24
23
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
3
2
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
End Table

Hex file shows:
:1000B0006C6B6A69686867666565646362626160E3
:1000C00060005F5E5D5D5C5B5B5A595958575756DF

Should be :1000C000605F5E...

Thanks!

[Nobody/Anonymous]

Are table lengths still a concern on 18F's in GCB?
What is the max "working" length of a table in GCB?

Thanks.

[Hugh Considine]

Should all work fine, I just checked GCBASIC with tables of 5 and 10 bytes, no problems, so the padding is being added correctly.

The maximum length is 255 bytes on all chips.