There seems to be a bug introduced in the latest gcbasic update that wasn't there in the January release when passing strings into subs. The assembly code produced isn't handling the high byte of the string address its just being cleared even though the string is above 255 in the data memory. Compiling this test program -
'Chip settings
#chip 18F4320, 8
#config OSC = INTIO2, PWRT = ON, MCLRE = ON, WDT = OFF
The string mytext gets placed at address 469 but the PRINT assembly code shown below isn't using the high byte (SysPRINTDATAHandler_H) of the address that's passed into the sub. AFSR0_H is just being cleared or set to zero at two points in the sub.
There seems to be a bug introduced in the latest gcbasic update that wasn't there in the January release when passing strings into subs. The assembly code produced isn't handling the high byte of the string address its just being cleared even though the string is above 255 in the data memory. Compiling this test program -
'Chip settings
#chip 18F4320, 8
#config OSC = INTIO2, PWRT = ON, MCLRE = ON, WDT = OFF
dim mytext(32) as string
mytext = "Goodbye world"
'LCD connection settings
#define LCD_IO 8
#define LCD_DATA_PORT PORTD
#define LCD_RS PORTC.0
#define LCD_RW PORTC.1
#define LCD_Enable PORTC.2
PRINT mytext
The string mytext gets placed at address 469 but the PRINT assembly code shown below isn't using the high byte (SysPRINTDATAHandler_H) of the address that's passed into the sub. AFSR0_H is just being cleared or set to zero at two points in the sub.
;Overloaded signature: STRING:
PRINT48
movff SysPRINTDATAHandler,AFSR0
clrf AFSR0_H,ACCESS
movff INDF0,PRINTLEN
movlw 0
subwf PRINTLEN,W,BANKED
btfsc STATUS, Z,ACCESS
return
bsf PORTC,0,ACCESS
clrf SYSPRINTTEMP,BANKED
SysForLoop1
incf SYSPRINTTEMP,F,BANKED
movf SYSPRINTTEMP,W,BANKED
addwf SysPRINTDATAHandler,W,BANKED
movwf AFSR0,ACCESS
clrf WREG,ACCESS
movwf AFSR0_H,ACCESS
movff INDF0,LCDBYTE
call LCDWRITEBYTE
movf PRINTLEN,W,BANKED
subwf SYSPRINTTEMP,W,BANKED
btfss STATUS, C,ACCESS
goto SysForLoop1
return
I haven't tried it with a 16F chip.
Frank
Fixed now, thanks for letting me know. Fix is at http://gcbasic.sourceforge.net/newfiles/update-nochipdata.zip