I'm afraid I'm going to need some help to get this working..

I've assembled OSI Basic from https://github.com/mist64/msbasic and I'm trying to get past the welcome screen on my 6502 SBC.

After correctly setting memory size and terminal width I end up with an OK prompt that refuses to give me anything but "?SN ERROR" no matter what I throw at it. I usually use LIST as my test phrase.
It looks like it's writing to the zero page input buffer just fine, but has issues parsing it and I'm having a hard time debugging it.

Currently I can't seem to enter numbered lines either - if I enter "10 LIST" I can't seem to finish the line and get a new "OK".

My MONRDKEY and MONCOUT routines both backup and restore x & y. MONRDKEY also converts $0A from the keyboard to $0D (CR).

I'm hoping a little bit that someone can confirm or deny that OSI Basic assembles correctly with a recent version of cc65 or has a hint to debug the syntax errors.

Anyone had this running on any hardware with a recent cc65 version?

This is my current defines_osi.s file - I have zero page locations moved around to get out of the way of my keyboard routines(original address in the comments):

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

Is it a caps-lock kind of problem? If the interpreter thinks you typed "list" then a syntax error would be right.

I just checked in the online uk101 emulator, and after entering a numbered line there is no response - that's correct. If you could RUN or LIST that might demonstrate the program is there. But even if you just type a command that's rejected with a syntax error, that will demonstrate that the interpreter was waiting for more input.

I don’t think it’s a caps problem. I think it expects all caps but neither works - both get entered correctly to the input buffer in zp
Does the emulator work for unnumbered lines? Gotta check out that one.

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

There's another emulator here, an OSI one:
https://www.pcjs.org/machines/osi/c1p/

Both of them are happy to
PRINT 22/7
and to accept and run a program like
10 LIST

(Sorry, these emulators don't directly help you debug your build-from-source! But perhaps they can help, especially if find a way to inspect memory.)

I can't be certain, but your symptoms suggest that you need to take a close look at your ZP allocations to see if your line input routine is accidentally stomping on something important. I have trouble dissecting sources spread out across dozens of files ... can you upload a .LST file for us to inspect?

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I’ve been working with that theory for a week now but no stomping seems to be going on - my ROM listing is complicated by serial double buffered keyboard input and bunches of unrelated code so I was hoping someone could build basic from source as well to help me figure out if it’s my code or the assembler.
I’ll upload a listing file later though - I’ll appreciate any help I can get

Hmm. I think I actually forgot to check if the hashes match the ones on GitHub if I build it unmodified..
Edit: MD5's for the ones on github and the ones built with local tools match.

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

I can certainly use it to PRINTPEEK zero page to check some locations!

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

Here's the LST. The userlisting.txt clears ZP and jumps to COLD_START. (You might want to do the same thing and take my word for the fact that MONRDKEY and MONCOUT behave as intended).

I'm sorry for all the half-finished code in the 12k line file - the BASIC ROM itself though matches the repo in OP.

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

Well, I took a quick browse thru your listing file... still seems to have numerous unresolved addresses. It's not entirely clear what your hardware system is either... perhaps a 6551 ACIA chip??

You might want to take a look at Grant Searle's OSI BASIC source that he implemented on his 6502 system... it's a single source file and is configured for the CA65 assembler. If you can get this running, then that should help clear things up.

Granted, I haven't tried to get the older MS BASIC code running, but did a fair amount of work getting EhBasic sorted for my SBCs... which is mostly a derivative work from MS BASIC.

_________________
Regards, KM
https://github.com/floobydust

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

True enough, Basic should be a separate piece of code. However, the OP is trying to figure out what's wrong.... and without knowing much about his system and other software bits, suggesting Grant's code might be a reasonable diagnostic path.

When I worked on the CMOS version of Enhanced Basic, I removed the interrupt bits as they would interfere with the BIOS functions of my SBC. I also moved the chrget/chrgot equivalent routine to ROM and used CMOS instructions and addressing modes to make it more efficient. It also saved a decent amount of page zero space.

Here's the current equivalent routine from my source. It uses two page zero locations for the 16-bit pointer:



27 bytes of ROM space and 2 bytes of page zero. If desired, the same modification could be made to the OSI Basic version, provided he's using a CMOS processor.

_________________
Regards, KM
https://github.com/floobydust

Could it be something as simple as parity on the input? ie. terminal set to even (or odd) parity and the input code expecting no parity?

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Let me see if I can clear some things up

System is my 6502 SBC - designed to use scrap == can't depend on 65c02 but there's one in the system right now. https://hackaday.io/project/184725-abn6502-sbc-r1 (Also a video in my signature)
It uses a PS/2 keyboard for input(scan codes to a scan code buffer in IRQ -> remapped to ASCII in a system input buffer in a checkkeyboard routine -> fetched via MONRDKEY). Only interface to BASIC is the MONRDKEY and MONCOUT routines. I see the inlin routine in msbasic strips off the top bit but otherwise doesn't mess much with it.
Grant's version is simply a hardcoded version of the same thing - not allowing to easily enable/disable features. I've looked through it for hints many times but came up empty handed.
I know using ZP for input buffer is wasteful but that's how the OSI version did it - some of the other versions don't but they have to many kernel interface routines, complicating things further.

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.

If I can move the ZP locations to exactly the same locations as the binary original I can move on to PEEK'ing the c1p emulator ZP.
After that I guess I have to look closely at the tokens and parseline routines...

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

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.