I'm porting EhBASIC to a new system (a 6502 CPU board for the RC2014) and am hitting Syntax Errors. I'm using the files in source.zip from Jeff Tranter's github repo.

I've set up V_INPT and V_OUTP along with Ram_base, Ram_top and Ibuffs.

The BASIC code is at $1000 in RAM and Ram_base points to $4000 with Ram_top at $8000.

I can get to the first Ready prompt. Typing in anything (e.g. LIST, NEW) will result in a syntax error.

After some tracing, the errors comes from LAB_1609.

Other than the I/O reconfiguration and memory settings, what else is needed for a port?

Do I need to do anything with IRQ/NMI? The hardware does have any interrupts running or enabled. I'm using a serial teminal so don't know if Twidth is something that needs to be preconfigured.

I've done similar ports of other BASICs (IMSAI 8K and PA Tiny) so I'm not lost (yet ).

Thanks!

It sounds like you've got everything set that should be. Try moving IBuffs below Ram_base if it isn't already.
The V_INPT needs to have the carry and zero flag set appropriately.

I got a copy of EhBASIC from Klaus's page on GitHub. It seems to work. Maybe you could compare the two and see if there are any differences.

_________________
http://www.finitron.ca

Thanks, Rob.

The files are the same.

On a hunch, I tweaked the memory locations a little bit. I had previously assembled the code to reside at $1000 and the Ram_base at $4000.

When I reversed it i.e. code at $4000 and Ram_base at $1000, I no longer get a Syntax error with LIST (or NEW ...).

Weird.

However, I'm not able to enter a program. Typing in "10 A=0" and then typing in LIST does not show anything. Then typing in "20 PRINT A" followed by "LIST" will give me a syntax error for line 20. Typing in NEW will give me the same syntax error message.

Is there a requirement for the BASIC code to be in ROM?

I know, for example, that the Z80 MS BASIC that comes with the RC2014 cannot run reliably in RAM.

_________________
Blog: http://ancientcomputing.blogspot.com/
GitHub: https://github.com/ancientcomputing

As far as I know no. I think it should be able to run from RAM. I've browsed the code a fair bit and I haven't seen anything that writes to the area the code is in.
The only self modifying code is for the BASIC char get routine, which gets copied to zero page.

Is the CPU board an ordinary 6502 or is it a custom chip ? Does it have a cache memory ? Does it share zero page memory with anything else ? EhBASIC uses most of zero page memory.
Can you try running Klaus's test suite on the 6502 ? Maybe it's a hardware problem of some sort.

_________________
http://www.finitron.ca

I have run EhBASIC from RAM without problems.

Here is my typical setup:



My SBC Monitor uses page 3 for Input buffer and other pointers, so I have Ram_base set to $400.

I initialize the V_INPT and V_OUTP variable then call LAB_COLD. Make sure your caps lock is on, as EhBASIC does not like lower case except inside of string variables.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Hmm, how do you generate the WE signal that's sent from the CPU card to the backplane? With 65xx processors (unlike Z80) there needs to be an external gate that forces the WE signal false except during the latter half (Phase2 high) of each cycle.

Sorry if I'm stating what you already know. Without such a gate the sytem might be totally DOA, or it might kinda-sorta work -- but its behavior would be weird. Hardware problems can certainly present that way.

Another scenario that can kinda-sorta work is when there's a flaky connection, or when a pin is supposed to be tied high or low but has been left unconnected instead. (BTW on this page Garth outlines how the CPU pins need to be tied.)

best of luck, and keep us posted,
Jeff
[edit: fix link]

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I seem to remember that somebody had problems with EhBasic that were caused by having the Decimal Mode flag set... does this ring a bell?

Decimal mode is only a problem in HEX$() producing a false result. Running EHBasic below Basic program RAM has a bug. Please see https://github.com/Klaus2m5/6502_EhBASI ... quirks.txt #2.

The only thing, that would cause EHBasic to overwrite itself is an address collision between RAM settings and EHBasic's location.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Thanks everyone for your suggestions etc.

I finally figured it out.

The main problem is where Ibuffs (and subsequently Ibuffe) is located. I had placed it at $400. With everything being equal, this will result in EhBASIC not recognizing anything you type. It will see your entry and echo it back, but will not be able to do anything with it and in some cases, will complain of a syntax error.

Now, if you reference Ibuffs in relation to IRQ_vec (copy it over from min_mon.asm), then things work.

So the following works:


Whereas the following doesn't:


I am of course careful to make sure that Ram_base is quite faraway from Ibuffs.

I don't know why this is so. Perhaps someone somewhere made some assumptions of the page where Ibuffs need to be e.g. be in the same page as ccflag and friends etc.

The other problem is what I've already observed: the EhBASIC binary has to be located in memory higher than Ram_base and Ram_top. Otherwise strange things happen.

I suggest documenting this in bugsnquirks....

_________________
Blog: http://ancientcomputing.blogspot.com/
GitHub: https://github.com/ancientcomputing

Glad you figured it out! And, by the way, welcome.

So, Ibuffs can be anywhere in RAM that's not $0400??

Any reason $0400 is magical?

Nope. $0400 is an example. $0500 gives you the same result: negative.

As long as Ibuffs is in the same page as ccflag and friends, it works. And ccflag can be at $0400.

So again, someone somewhere made an assumption

_________________
Blog: http://ancientcomputing.blogspot.com/
GitHub: https://github.com/ancientcomputing

I did a little experimenting this morning. This is on v2.22

With Ibuffs set to $0400 AND Ram_base set to $0500, I did a Cold start and entered this line - 10 PRINT "HELLO WORLD"

I examined the memory at Ram_base and found that the stored line was formatted correctly. However, when I typed LIST, all I got back was HELLO WORLD, as if I had typed RUN. Typing RUN also returned HELLO WORLD. When I ran the SYS command (my added command to return me to my Monitor), it just ignored it and returned to the BASIC input prompt.

Next, I changed Ibuffs to $0401 and reassembled. This time, everything performed as it should.

Next, I set Ram_base to $0600 with Ibuffs set to $0400 and entered the same line. This time, LIST returned nothing. Examining memory at $0600, the stored line is there and is correct. RUN and SYS also return nothing.

Finally, I set Ram_base to $0600 and Ibuffs to $0401 and all worked as it should.

I do not have time to research why this is happening, or if there are any other limitations to Ibuffs, but it appears that the low byte of the Ibuffs address cannot be $00. I'm not sure how to interpret the differences in results based on where Ram_base is in relation to Ibuffs, but there is some connection when its 1 page apart.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

I think I found the problem... and it would explain the issue with Ibuffs and Ram_base being 1 page apart too.

This piece of code is the problem:



Previously in the code, Bpntrl gets set to Ibuffs. When the DEC instruction gets executed, Bpntrl get set to $FF. Later in the code, we have this:



The routine LAB_IGBY is located in zero page (to increase speed). it looks like this:



The code at LAB_2CEE will INC Bpntrl, which becomes $00 and then INC's Bpntrh to $05. Now this pointer is pointing to the wrong page. And depending upon what is stored there, different things will happen.

This note is incorrect:


It should read (change if buffer starts at $xx00).

My fix would be to add this:



I have tested this fix and it worked for me.

Daryl

Edited - Changed BIT to LDA in my patched code....can't use BIT to test ZP=0 unless A is already 0.

_________________
Please visit my website -> https://sbc.rictor.org/

Thumbs Up !

edit(1):
Now that A is changed (LDA Bpntrl; test for $00) it is perhaps saver to preserve A by adding a PHA past STA IBuffs,Y and unstacking A before DEC Bpntrl .