Weird behaviour on longer BASIC lines

[jaccodewijs]

Hello all,

I am implementing EhBasic on my 65C02 board, and all went well, until...
I hit a snag, of course.


After some testing, I found out that when I types somewhat longer lines of BASIC, weird stuff was happening.
A line like:
580 FOR I=1 TO 12: FOR J=1 TO 12: PRINT P$(I,J);: NEXT J
got corrupted when i LISTed it back.

The PRINT command was replaced by a byte 0x9f, the P$(I,J);: was OK again, then the NEXT command was again a single byte 0x82

(580 FOR I=1 TO 121: FOR J=1 TO 121: <0x9f> P$(I,J);: <0x82> J)
The HEX values between < > did not print like that, but I figured them out using my terminal program


Then I did some testing and I tried (not a runnable program, obviously!):

10 PRINT:PRINT:PRINT:PRINT:PRINT:<0x9f>:<0x9f>:<0x9f>:<0x9f>:<0x9f>
20 REM:REM:REM:REM:REM:REM:REM:REM:REM:REM
30 REM:REM:REM:REM:REM:REM:REM:REM:REM:REM:REM:REM:REM:REM:REM:REM:REM
40 BEEP:BEEP:BEEP:BEEP:BEEP:BEEP:<0xab>:<0xab>:<0xab>:<0xab>:<0xab>:<0xab>:<0xab>:<0xab>
50 END:END:END:END:END:END:END:END:END:END:END:END:END:END:END
60 CLS:CLS:CLS:CLS:CLS:CLS:CLS:CLS:CLS:CLS:CLS:CLS:CLS:CLS:CLS:CLS:CLS
70 LOOP:LOOP:LOOP:LOOP:LOOP:LOOP:<0x9e>:<0x9e>:<0x9e>:<0x9e>:<0x9e>:<0x9e>:<0x9e>:<0x9e>
80 RETURN:RETURN:RETURN:RETURN:RETURN:RETURN:RETURN:RETURN:RETURN:RETURN
90 WAIT:WAIT:WAIT:WAIT:WAIT:WAIT:<0x96>:wair:<0x96>:<0x96>:<0x96>:<0x96>:<0x96>:<0x96>
100 GOTO:GOTO:GOTO:GOTO:GOTO:GOTO:<0x98>:<0x98>:<0x98>:<0x98>:<0x98>
110 PRINT:prinit:PRINTn:PRINTn:PRINT:PRINT:PRINT:PRINT:prinint:PRINT
120 PRINT:PRINT:PRINT:PRINT:PRINT:<0x9f>:<0x9f>:<0x9f>:<0x9f>:<0x9f>:<0x9f>:<0x9f>
130 INC:INC:INC:INC:INC:INC:INC:INC:INC:INC:INC:INC:INC:INC:INC:INC
140 NULL:NULL:NULL:NULL:NULL:NULL:<0x94>:<0x94>:<0x94>:<0x94>:<0x94>:<0x94>:<0x94>
150 ON:ON:ON:ON:ON:ON:ON:ON:ON:ON:<0x93>:<0x93>:<0x93>:<0x93>:<0x93>:<0x93>:<0x93>
160 STOP:STOP:STOP:STOP:STOP:STOP:<0x92>:<0x92>:<0x92>:<0x92>:<0x92>:<0x92>

From this I concluded:
- Only affects recognised tokens (See line 90 and 110)
- Not all tokens; i.e. REM, END, CLS, RETURN, INC (and others?) are okay / PRINT, BEEP, LOOP, WAIT, GOTO, NULL, ON, STOP (and others?) are bad.
- Line numbering is not the problem; when using line number 100, the error point gets shifted 1 position to the right too (See line 110-120)
- When deliberately introducing some typo's in the keywords, the problem isn't the same (see line 110), but not gone (see line 90)
- HEX code is linked to the token (PRINT = $9F, BEEP = $AB, LOOP = $9E, WAIT = $96, GOTO = $98)
- HEX codes are in order and related to the Token list (TK_) and Decode table (at LAB_KEYT)

I cannot figure out for the life of me what is going on here!
Is someone familiar with this phenomenon?
Please help me out here, I have been banging my head over this for 3 whole days now...
Thanks in advance!


Jacco

P.S., BEEP and CLS are tokens that I added myself, and are working fine


Here is some info about my system:
- WDC 65C02 @ 4 MHz
- Serial connection @ 115200 baud
- User RAM from $0000-$7FFF ($0600-$6FFF available for BASIC programs)
- ROM from $C000-$FFFF
- EhBasic assembled in RAM from $8000-$BFFF

In EhBasic, I have set
MEMBOT =$0600 ; Bottom of user memory
MEMTOP =$7000 ; Top of user memory
ZPSTART =$00 ; Start of zero page workspace
WSSTART =$0500 ; Start of vector and input buffer workspace
CODESTART=$8000 ; Start of program code
ccflag = WSSTART ; BASIC CTRL-C flag, 00 = enabled, 01 = disabled
ccbyte = ccflag+1 ; BASIC CTRL-C byte
ccnull = ccbyte+1 ; BASIC CTRL-C byte timeout
VEC_CC = ccnull+2 ; CTRL-C check vector
VEC_IN = VEC_CC+2 ; input vector
VEC_OUT = VEC_IN+2 ; output vector
VEC_LD = VEC_OUT+2 ; load vector
VEC_SV = VEC_LD+2 ; save vector
Ibuffs = VEC_SV+4 ; aligned to $xx10
Ibuffe = Ibuffs+$7B ; end of input buffer
Ram_base = MEMBOT ; start of user RAM
Ram_top = MEMTOP ; end of user RAM+1
Stack_floor = 16 ; bytes left free on stack for background interrupts

[floobydust]

Well, I modified EhBasic with a lot of CMOS opcodes/addressing modes and removed the interrupt stuff, as it didn't really work. I think you might want to look at your code that's interfacing the console I/O to EhBasic... posting some more information might help, like some source code for your BIOS or whatever you refer to it as, i.e., the code that's interfacing your hardware to EhBasic.

Knowing more about your hardware might help as well... like a schematic and details on the serial port, i.e., are you using some hardware handshaking like RTS/CTS? Also, are you actually typing in directly or using a cut/paste via a serial terminal window.

[barrym95838]

So, the actual program isn't corrupted and still runs normally, correct? It's just LIST that temporarily loses the ability to detokenize properly?

[jaccodewijs]

Hi!

Thanks for your quick reply!

It has nothing to do with the Serial connection, as everything works regarding sending and receiving data.
It is also not a speed issue, it happens even when i am sending 1 character a second, so no RTS/CTS of buffer overrun issues.
(I even tried typing it that slowly instead of sending )

This is my kernal Serial routine:

Code: Select all

; ***** DUART_SCAN_A *****			
; Scans for an incoming byte from DUART CHANNEL A.
; Returns with byte in .A and Carry Set, or Carry Clear if no data is available.
DUART_SCAN_A:		        LDA SR_A ; Status register
						AND #$01
						BEQ NO_DATA_A
						LDA RHR_A ; Receive holding register
						SEC 
						RTS
  NO_DATA_A:      CLC 
						RTS	

And then in EhBasic (in minmon.asm)

Code: Select all

; byte in from emulated ACIA
ACIAin


waitForData	
	JSR DUART_SCAN_A ; Sets the carry if there is data available 
	BCC LAB_nobyw	 ; Else, exit with carry cleared
	RTS		 ; Exits with carry set (byte received)

LAB_nobyw
	CLC		; flag no byte received
	RTS		; Done.

So, pretty straight forward.

I suspect something is wrong with the input buffer in EhBasic (at Ibuffs)?
Seems like something there is overflowing, but I may be completely wrong.

[jaccodewijs]

Here is my ehbasic.asm file as-is:

[floobydust]

Well, if you're convinced you have zero issues with your hardware and serial connection and data transfer, then you should look at other software related problems and/or conflicts.

You might want to verify that you don't have any Page Zero conflicts between your EhBasic implementation and your Monitor code. If you suspect a problem with the buffer that EhBasic implements, perhaps try moving it to a different location to see if you might have a bad section of RAM. Granted it's pretty rare to get bad SRAM, but I've actually experienced a bad SRAM over the past 5 years... and it's a new production 32KB chip as well.

There's also the option of trying my CMOS version of EhBasic... if you have the same problems using it, then I suspect you have a hardware problem or something in your monitor that is causing the problem.

viewtopic.php?f=5&t=255&start=60#p77479

Note: my CMOS version uses WDC Tools to assemble/link and at a minimum requires two routines to operate:

Character in (no waiting)
Character out

All Page Zero required space is contiguous starting at $00, iBuff is located on page $0400. Also, I think there was a bug with moving iBuff around to a non-page boundary address... I'm quite certain I fixed that in my version, along with the many fixes that Klaus added over time.

Hey, it's worth a try.

[jaccodewijs]

barrym95838 wrote:

So, the actual program isn't corrupted and still runs normally, correct? It's just LIST that temporarily loses the ability to detokenize properly?

No, the program also fails.
It's not just the LISTing that produces the error.

The example line I gave (580 FOR I=1 TO 12: FOR J=1 TO 12: PRINT P$(I,J);: NEXT J) should have run fine, but got corrupted.
My test lines obviously woudn't run

[jaccodewijs]

Maybe good to know that I went from J.G.Harston's version of EhBasic (2.22p5)

[jaccodewijs]

Okay, I switched back to Klaus's original source.

Tested it again on a very basic serial connection and now it seems to behave correctly.
Thus, it might be that my kernal routines do mess up the zero page for EhBasic... *sigh*

Still, I do need some space on the ZP for my kernal, so I must get to grips with where EhBasic leaves me some space.

Next up: trying to remove all the IRQ/NMI stuff and consolidating the ZP addresses of Eh.

Will keep everyone here posted!

[barrym95838]

jaccodewijs wrote:

Next up: trying to remove all the IRQ/NMI stuff and consolidating the ZP addresses of Eh.

Will keep everyone here posted!

floobydust already did exactly that, so it's up you whether or not you will gain any pleasure or experience in reinventing the wheel.

[floobydust]

Well, hate to say it, but as Mike noted, you'd probably be better off just using my CMOS version of EhBasic. It has all of the latest p5 patches from Klaus, contiguous Page Zero usage (ala JG Harston), less page zero usage from leveraging the CMOS capabilities and some optimizations from Mike (barrym95838) on the main crunch routine. This CMOS version has been used by others on the forum as well ad has proved to be a solid release. If you need to add additional functions, you at least have a working version with known page zero usage and other resources as well.

As Mike said, "why reinvent the wheel"?

[jaccodewijs]

Actually, you are both right.
Even though I usually go the path of doing it myself as education, in this case it feels a bit superfluous to do that.
I may aswel write my own version of BASIC...

So, fair enough, I'll see if I can get your CMOS version running on my system.
(I would like to keepnusing my ca65/cc65 toolchain, so I will have to convert a few things, but hey; no work no play, right?)

Thanks both!

[drogon]

jaccodewijs wrote:

Actually, you are both right.
Even though I usually go the path of doing it myself as education, in this case it feels a bit superfluous to do that.
I may aswel write my own version of BASIC...

I keep thinking that myself - and I've already written a BASIC, although that one was in C and I don't fancy translating it to 6502/65816... I'll probably make a cut-down version in BCPL at some point (but then, I might also suggest that BCPL is my new BASIC ...)

Quote:

So, fair enough, I'll see if I can get your CMOS version running on my system.
(I would like to keepnusing my ca65/cc65 toolchain, so I will have to convert a few things, but hey; no work no play, right?)

I did a convert to ca65 a while back but I'm probably a few iterations behind. I might take the time to get the latest one going, but, frankly, it's a classic MS BASIC and I grew to like BBC Basic which runs on my own Ruby system very well.... But it's always nice to have alternatives... (I think!)

Hope you get something going, if I do the convert in the next couple of days I'll post it here.

-Gordon

[drogon]

drogon wrote:

I did a convert to ca65 a while back but I'm probably a few iterations behind. I might take the time to get the latest one going, but, frankly, it's a classic MS BASIC and I grew to like BBC Basic which runs on my own Ruby system very well.... But it's always nice to have alternatives... (I think!)

And following up my own post, the version I have is the P4C version - however I can't find the P5C version we're talking about here - got a link to it?

Cheers,

-Gordon

[floobydust]

drogon wrote:

drogon wrote:

I did a convert to ca65 a while back but I'm probably a few iterations behind. I might take the time to get the latest one going, but, frankly, it's a classic MS BASIC and I grew to like BBC Basic which runs on my own Ruby system very well.... But it's always nice to have alternatives... (I think!)

And following up my own post, the version I have is the P4C version - however I can't find the P5C version we're talking about here - got a link to it?

Cheers,

-Gordon

I linked it earlier in this post... but not quite that obvious as it was to another post

basic-p5c.asm

(334.38 KiB) Downloaded 154 times