OSI Basic won't parse commands - syntax error

[AndersNielsen]

BigEd wrote:

Old-school debugging involves adding diagnostic output - could your character input routine print the character's hex value to the screen, for each character? Similarly, you could get Basic to dump the input buffer as hex just before it starts to parse the line.

Yup, I have debugging that's dumping x & y & a and i/o to screen

[AndersNielsen]

Even though I’m careful to save registers it looks like it’s writing numbered lines wrong

[AndersNielsen]

I just noticed that Grant's version has a hardcoded TOKEN_NAME_TABLE whereas the original I'm using... is using some sort of macro that I don't really understand.
https://github.com/mist64/msbasic/blob/master/macros.s

Everything seems to be working up until PARSE_INPUT_LINE - which would make sense if TOKEN_NAME_TABLE isn't working as intended. .. but I can't seem to verify from the LST file.

[barrym95838]

AndersNielsen wrote:

I think I'll try making my own ZP use more relocatable - maybe something is addressed expecting the blocks to have exactly the same offsets from each other.

That's an excellent idea. Especially, keep an eye on small ZP,X loops that try to initialize or otherwise affect more than one "thing" to save a few precious bytes of ROM. Woz did that a lot, and it's possible that Gates and company did too. Woz would even take advantage of ZP,X "wrap-around" which worked fine but qualified as a bit abstruse.

Code: Select all

1F66  A2 FA     RTLOG1 LDX =$FA    INDEX FOR 6 BYTE RIGHT SHIFT
1F68  A9 80     ROR1   LDA =$80
1F6A  B0 01            BCS ROR2
1F6C  0A               ASL
1F6D  56 0F     ROR2   LSR E+3,X   SIMULATE ROR E+3,X
1F6F  15 0F            ORA E+3,X
1F71  95 0F            STA E+3,X
1F73  E8               INX         NEXT BYTE OF SHIFT
1F74  D0 F2            BNE ROR1    LOOP UNTIL DONE

There's no mention of "M1" in the comments, but if it's not placed directly before "E" then the code is suddenly broken.

[AndersNielsen]

Well that didn't help much. I got some crap moved out of ZP that didn't need to be there though and I can move everything around at will.

One thing I find weird is what get's written to RAMSTART2 when I try to run a LIST and nothing else. (And get a syntax err)
When inspecting my RAMSTART2 at $1300 it shows 00 00 00 24 4C 00 00 00 00 00 24 24 24 24 24 24 24 (24 is test pattern and continues for rest of RAM).

I have a feeling that's not what should be there and that could explain the SN ERR... But what does it mean? Maybe tokens really don't load?

[floobydust]

Well, I hate to ask... but is there any chance you might have a hardware problem? It seems that the OSI and other Basic versions have been successfully assembled/linked before, so perhaps there's another cause for the failure.

I've had one (new) SRAM that refused to run in one of my 65C02 boards some years ago. It turned out to have an intermittent memory location(s) that stored some required variables for the BIOS. Perhaps you have some other software that is working properly and a detailed memory test to ensure the system itself is not the cause.

[HansO]

You mention interrupt driven I/O. The V1.x 6502 Microsoft Basics are not interrupt friendly, especially stack handling in the input part. Microsoft advised to turn interrupts off.
Commodore learned that the hard way (crashing machines) so they rewrote that part.

https://vintagecomputerstories.blogspot ... ricky.html

The error you see sounds familiar btw, I have seen that (in my KIM-1 Simulator) when the I/O routines destroys the contents of registers. Preserving and restoring is key.

Other Basic variants have the inputbuffer at e.g. $0200, all configurable in the source of the pagetable archive. OSI Basic has the garbage collection bug afaik.
SYM-1 Basic variant is a convenient version also.

Hans

[BillG]

Interesting that you mention that.

One of my many projects is paraphrasing the SWTPC 6800 Disk BASIC interpreter into 6502 assembly language. Its symbol table search code disables interrupts then proceeds to use the stack pointer as a second index register, something the 6800 woefully needs.

[AndersNielsen]

HansO wrote:

You mention interrupt driven I/O. The V1.x 6502 Microsoft Basics are not interrupt friendly, especially stack handling in the input part. Microsoft advised to turn interrupts off.
Commodore learned that the hard way (crashing machines) so they rewrote that part.

https://vintagecomputerstories.blogspot ... ricky.html

The error you see sounds familiar btw, I have seen that (in my KIM-1 Simulator) when the I/O routines destroys the contents of registers. Preserving and restoring is key.

Other Basic variants have the inputbuffer at e.g. $0200, all configurable in the source of the pagetable archive. OSI Basic has the garbage collection bug afaik.
SYM-1 Basic variant is a convenient version also.

Hans

That sound exactly like my problem. This might be tough..
I read the 11 bit PS/2 scan codes by setting IRQ after 6 bits and then again after 5 bits so it is a bit timing sensitive. I guess I can try disabling IRQ's while parsing a line...
I guess it can also be a stack issue..

RAM is fine floobydust

[AndersNielsen]

Note to self: What if MONRDKEY returns $00 instead of $20 for space?

Edit: No, of course it doesn't.

[AndersNielsen]

Still desperately trying to debug this..
Can anyone explain what's going on below?

I've set my timer IRQ to display the contents of INPUTBUFFER every half second-ish - works great and doesn't affect anything.

1) When typing an unnumbered line it ends up in the input buffer just fine.
2) When I press return the input buffer seems to be tokenized ... or something - I've decided to save the loads from PARSE_INPUT_LINE to see what actually happens.

If I type in LIST LIST LIST LIST, the input buffer changes to this on return(HEX):
4C A8 20 4C A8 20 4C A8 20 4C A8 00

If I save a numbered line (10 LIST) on the c1p emulator and peek memory I get this(DECIMAL):
0 7 3 10 0 153 0 0 0

153 == $99 == 25 decimal ORA $80.
When counting down the list of keywords I see LIST is #26... Hmm.. Maybe it means nothing. But certainly that the LIST token should be $99.

This is what I get when entering a numbered line no my SBC with (10 LIST) (HEX):
00 08 13 0A 00 4C A8 00 00 00

Somehow LIST seems to be tokenized into two bytes - 4C A8... Which makes no sense to me.

Code: Select all

000226r 3  B5 00                lda     INPUTBUFFERX,x
000228r 3  9D 00 05             sta     $0500,x ; <--------Debug line

The above from the PARSE_INPUT_LINE routine gives this dump at $0500:
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 4C 49 00 00 20
4C 49 00 00 20 4C 49 00
FF 20 4C 49 FF FF 00 FF ; <-- This line seems to indicate the FF's are uninitialized and X has skipped them.

Code: Select all

000220r 3               ; ----------------------------------------------------------------------------
000220r 3               ; TOKENIZE THE INPUT LINE
000220r 3               ; ----------------------------------------------------------------------------
000220r 3               PARSE_INPUT_LINE:
000220r 3  A6 C3                ldx     TXTPTR
000222r 3  A0 04                ldy     #$04
000224r 3  84 60                sty     DATAFLG
000226r 3               L246C:
000226r 3  B5 00                lda     INPUTBUFFERX,x
000228r 3  9D 00 05             sta     $0500,x ; <--------Debug line
00022Br 3               .ifdef CONFIG_CBM_ALL
00022Br 3                       bpl     LC49E
00022Br 3                       cmp     #$FF
00022Br 3                       beq     L24AC
00022Br 3                       inx
00022Br 3                       bne     L246C
00022Br 3               LC49E:
00022Br 3               .endif
00022Br 3  C9 20                cmp     #$20
00022Dr 3  F0 3A                beq     L24AC
00022Fr 3  85 5C                sta     ENDCHR
000231r 3  C9 22                cmp     #$22
000233r 3  F0 58                beq     L24D0
000235r 3  24 60                bit     DATAFLG
000237r 3  70 30                bvs     L24AC
000239r 3  C9 3F                cmp     #$3F
00023Br 3  D0 04                bne     L2484
00023Dr 3  A9 97                lda     #TOKEN_PRINT
00023Fr 3  D0 28                bne     L24AC
000241r 3               L2484:
000241r 3  C9 30                cmp     #$30
000243r 3  90 04                bcc     L248C
000245r 3  C9 3C                cmp     #$3C
000247r 3  90 20                bcc     L24AC
000249r 3               ; ----------------------------------------------------------------------------
000249r 3               ; SEARCH TOKEN NAME TABLE FOR MATCH STARTING
000249r 3               ; WITH CURRENT CHAR FROM INPUT LINE
000249r 3               ; ----------------------------------------------------------------------------
000249r 3               L248C:
000249r 3  84 BA                sty     STRNG2
00024Br 3  A0 00                ldy     #$00
00024Dr 3  84 5D                sty     EOLPNTR
00024Fr 3  88                   dey
000250r 3  86 C3                stx     TXTPTR
000252r 3  CA                   dex
000253r 3               L2496:
000253r 3  C8                   iny
000254r 3               L2497:
000254r 3  E8                   inx
000255r 3               L2498:
000255r 3               .ifdef KBD
000255r 3                       jsr     GET_UPPER
000255r 3               .else
000255r 3  B5 00                lda     INPUTBUFFERX,x
000257r 3                 .ifndef CONFIG_2
000257r 3  C9 20                cmp     #$20
000259r 3  F0 F9                beq     L2497
00025Br 3                 .endif
00025Br 3               .endif
00025Br 3  38                   sec
00025Cr 3  F9 rr rr             sbc     TOKEN_NAME_TABLE,y
00025Fr 3  F0 F2                beq     L2496
000261r 3  C9 80                cmp     #$80
000263r 3  D0 2F                bne     L24D7
000265r 3  05 5D                ora     EOLPNTR
000267r 3               ; ----------------------------------------------------------------------------
000267r 3               ; STORE CHARACTER OR TOKEN IN OUTPUT LINE
000267r 3               ; ----------------------------------------------------------------------------
000267r 3               L24AA:
000267r 3  A4 BA                ldy     STRNG2
000269r 3               L24AC:
000269r 3  E8                   inx
00026Ar 3  C8                   iny
00026Br 3  99 0E 00             sta     INPUTBUFFER-5,y
00026Er 3  B9 0E 00             lda     INPUTBUFFER-5,y
000271r 3  F0 34                beq     L24EA
000273r 3  38                   sec
000274r 3  E9 3A                sbc     #$3A
000276r 3  F0 04                beq     L24BF
000278r 3  C9 49                cmp     #$49
00027Ar 3  D0 02                bne     L24C1
00027Cr 3               L24BF:
00027Cr 3  85 60                sta     DATAFLG
00027Er 3               L24C1:
00027Er 3  38                   sec
00027Fr 3  E9 54                sbc     #TOKEN_REM-':'
000281r 3  D0 A3                bne     L246C
000283r 3  85 5C                sta     ENDCHR
000285r 3               ; ----------------------------------------------------------------------------
000285r 3               ; HANDLE LITERAL (BETWEEN QUOTES) OR REMARK,
000285r 3               ; BY COPYING CHARS UP TO ENDCHR.
000285r 3               ; ----------------------------------------------------------------------------
000285r 3               L24C8:
000285r 3  B5 00                lda     INPUTBUFFERX,x
000287r 3  F0 E0                beq     L24AC
000289r 3  C5 5C                cmp     ENDCHR
00028Br 3  F0 DC                beq     L24AC
00028Dr 3               L24D0:
00028Dr 3  C8                   iny
00028Er 3  99 0E 00             sta     INPUTBUFFER-5,y
000291r 3  E8                   inx
000292r 3  D0 F1                bne     L24C8
000294r 3               ; ----------------------------------------------------------------------------
000294r 3               ; ADVANCE POINTER TO NEXT TOKEN NAME
000294r 3               ; ----------------------------------------------------------------------------
000294r 3               L24D7:
000294r 3  A6 C3                ldx     TXTPTR
000296r 3  E6 5D                inc     EOLPNTR
000298r 3               L24DB:
000298r 3  C8                   iny
000299r 3  B9 rr rr             lda     MATHTBL+28+1,y
00029Cr 3  10 FA                bpl     L24DB
00029Er 3  B9 rr rr             lda     TOKEN_NAME_TABLE,y
0002A1r 3  D0 B2                bne     L2498
0002A3r 3  B5 00                lda     INPUTBUFFERX,x
0002A5r 3  10 C0                bpl     L24AA
0002A7r 3               ; ---END OF LINE------------------
0002A7r 3               L24EA:
0002A7r 3  99 10 00             sta     INPUTBUFFER-3,y
0002AAr 3               .ifdef CONFIG_NO_INPUTBUFFER_ZP
0002AAr 3                       dec     TXTPTR+1
0002AAr 3               .endif
0002AAr 3  A9 12                lda     #<INPUTBUFFER-1
0002ACr 3  85 C3                sta     TXTPTR
0002AEr 3  60                   rts

[teamtempest]

At first glance it looks like you're saving the input buffer each time the routine goes back to fetch another character (that's not between quotes or in a REM statement). So it gets overwritten each time, and you don't really see how it progresses.

It might be more helpful to start by saving the contents of the input buffer just twice, to two different locations, one just before tokenization and once just after it ends, so you can compare "before" and "after".

You actually wouldn't need to save anything afterwards, since the result would be in the input buffer anyway, but putting them next to each other in memory might make for easier comparisons.

After that you could, if it seemed helpful, save the buffer each time the routine goes back to the top, at increasing memory locations, so you can track the progress at each step and see if it's what you expect. But that's more work, and might be unnecessary if the first step solves the problem.

Or, hmm, instead of saving the buffer, at the top JSR to a subroutine that prints out the buffer contents and then waits for a keypress to return. That might be quickest.

[AndersNielsen]

Using LIST as a test the input buffer correctly contains LIST followed by null's.
Considering it has worked before that leaves variables, x, y and status register.

X is loaded from TXTPTR (should check that. Edit: Was $13 == start if inputbuffer as expected - should doublecheck it's not supposed to be something else)
Y is loaded immediate to $#4
Status register is overwritten pretty quickly

X is used as an index into the input buffer
Y is used as an index into the TOKEN_NAME_TABLE

There really not that many things that can break here.. Seems like the only things that can be wrong going in is TXTPTR or the TOKEN_NAME_TABLE.. Maybe..

[floobydust]

Seems like you're making progress, but I still have the odd feeling that something else is causing issues.

If you consider the fact that the code has been proven to assemble/link and run correctly (including making the correct ROM images), then you can sorta narrow possible causes down:

- possible issue with assembly and linking - if you can use your software setup to successfully build the ROM images correctly, then that "should" validate your development software config.
- possible software issues between your SBC code RAM usage and the OSI Basic RAM usage - knowing exactly what RAM resources are using between the two.
- possible hardware issue... I know you're stating that it's working properly, but sometimes the problem doesn't show up until you start using more RAM, ROM, and software that exercises the system more.

When diagnosing odd system issues, it's nice to be able to use a known working configuration, be it hardware or software. An example is the Micromon code I wrote years ago. It's a very simple monitor that requires a CMOS CPU, a 6551 ACIA and minimal ROM and RAM to work.... bottom line, if this code doesn't work on a small 65C02 system, you have a hardware problem.

Taking a similar approach for running a Basic interpreter, I'll suggest the following:

Take my recent EnHanced Basic source file and make the required config changes to match your system. These include the following:
- change the console in and console out routines to your system. (character out and character in, but note that character in requires no waiting)
- change the page zero start if needed. It currently starts at $0000 and is contiguous in usage
- change the input buffer location if needed. It currently starts at $0500
- change the RAM start and Top of RAM locations if needed. Currently starts at $0800 and ends at $7FFF (RAM top is $8000)
- change the start address for the code in ROM if needed. Currently set for $B000

Here's the section of source code that contains the required parameters to run on any given system.

Code: Select all

; Ibuffs can now be anywhere in RAM, ensure that the max length is < $80,
; the input buffer must not cross a page boundary and must not overlap with
; program RAM pages!

Ibuffs          .EQU $0500     ; Start of input buffer
Ibuffe          .EQU $0500+$7E ; end of input buffer (127 bytes)

ccflag          .EQU Ibuffe+1  ; BASIC CTRL-C flag, 00 = enabled, 01 = dis
ccbyte          .EQU ccflag+1  ; BASIC CTRL-C byte
ccnull          .EQU ccbyte+1  ; BASIC CTRL-C byte timeout

VEC_CC          .EQU ccnull+1  ; CTRL-C check vector

VEC_IN          .EQU VEC_CC+2  ; input vector
VEC_OUT         .EQU VEC_IN+2  ; output vector
VEC_LD          .EQU VEC_OUT+2 ; load vector
VEC_SV          .EQU VEC_LD+2  ; save vector
VEC_EXIT        .EQU VEC_SV+2  ; exit vector

Ram_base        .EQU $0800     ; start of user RAM (1st 2KB used/reserved)
Ram_top         .EQU $8000     ; end of user RAM+1 ($8000 is start of ROM)

; Host system routine addresses are defined here for convienence.
; They provide the following functions required by EhBasic:
; CHRIN_NW      - Character Input with no waiting - carry flag indicates data
; CHROUT        - Character Output
; LOAD          - Load data via Xmodem-CRC
; SAVE          - Save data via Xmodem-CRC
; EXIT          - Exit to warm start of C02 Monitor

B_CHRIN_NW      .EQU    $FF36
B_CHROUT        .EQU    $FF3C
M_LOAD          .EQU    $E015
M_SAVE          .EQU    $E012
M_EXIT          .EQU    $E003

; The start address can be changed, noting the BIOS/Monitor locations

      .ORG    $B000              ; Start of Basic in ROM
                                 ; C02Monitor starts at $E000
                                 ; C02BIOS starts at $F800

ROM_START
; BASIC cold start entry point

      JMP   BOOT_BASIC        ; jump to Basic cold start routine

Note that you only need to handle the CHRIN_NW and CHROUT routines to get it working. Also, several other folks out here have had no issues getting this CMOS version of EhBasic working on their systems. The build size is just under 10KB. The source is setup for assembly and linking with WDC Tools (a free download).

It can't hurt to try... I'm happy to take your system parameters and build it for you if you like... I use S19 records by default.

Here's a link to my CMOS version:

viewtopic.php?f=5&t=5760&start=15#p76030

[AndersNielsen]

floobydust wrote:

Seems like you're making progress, but I still have the odd feeling that something else is causing issues.

If you consider the fact that the code has been proven to assemble/link and run correctly (including making the correct ROM images), then you can sorta narrow possible causes down:

- possible issue with assembly and linking - if you can use your software setup to successfully build the ROM images correctly, then that "should" validate your development software config.
- possible software issues between your SBC code RAM usage and the OSI Basic RAM usage - knowing exactly what RAM resources are using between the two.
- possible hardware issue... I know you're stating that it's working properly, but sometimes the problem doesn't show up until you start using more RAM, ROM, and software that exercises the system more.

First of all, thank you so much for the help!

As I mentioned earlier in this mess of a thread I made, I did manage to assemble an MD5 matching binary with the unmodified source. The system has certainly been exercised very aggressively over the last year and I've yet to see a failed RAM test. With that in mind it comes down to two likely problems:

1) Misconfiguration
2) Bad assumptions in my MONRDKEY and MONCOUT routines.

For 1):
I'm considering a few things. I enter msbasic @ COLD_START from my monitor but I'm a bit unsure about how I should configure STACK_TOP. When entering basic I do a TSX and it shows $FF like it's configured to at reset - which tells me nothing is left on the stack at that time. However - coexistence doesn't seem easy so I've set STACK_TOP to $80.
I've moved all my ZP variablev out of the way as far as I can tell.

For 2):
For MONRDKEY I'm saving and restoring x & y to memory. Returning ASCII code(high bit not set) in A. Not paying special attention to any flags returned(which doesn't seem to be a problem to me). The routine is blocking until a key is available from the keyboard(serial, PS/2, via IRQ).
For MONCOUT I'm also saving index registers but not paying special attention to what I return in A or flags.
For MONISCNTC (which shouldn't affect the issue at hand) I simply CLC and RTS.

I'm not a big fan of C02-only code or proprietary build tools for that matter. I'm fairly certain I can get EhBasic running easier than msbasic but I'm also afraid it's going to be a bit of a detour that doesn't guarantee any success with this very specific tokenization issue. Also, I don't have an ACIA in my system - I/O via VGA, keyboard and SPI(RF module).

I feel like I'm getting close and at least I have an idea how tokenization works now, which makes debugging easier - but still no idea how I end up with two byte tokens.