Page 2 of 2

Re: Weird behaviour on longer BASIC lines

Posted: Wed Jul 28, 2021 12:14 pm
by drogon
floobydust wrote:
I linked it earlier in this post... but not quite that obvious as it was to another post ;-)
basic-p5c.asm
Got it, thanks.

Well as for p4c, the trivial bit is to add

Code: Select all

        .feature        labels_without_colons
to make it asemble with ca65 from the cc65 suite.

I have the following in my Makefile:

Code: Select all

        $Q ca65 -g --cpu 65c02 -l $(basename $@).lst $< -o $@
and

Code: Select all

        $Q ld65 -t none -S 0x8000 -vm -m ehBasic.map -o ehBasic $(OBJ)
to assemble and link it to start at $8000.

My changes to the p4c version (which I'll incorporate into my p5c version soon) are to change the character in/out, as required and also to use my own 'getline' code in my Ruby OS which allows for command-line editing, history and is much nicer with access to the "star" commands that my OS provides to do stuff like list directorys, etc. I also call the OS to get the value of LOMEM (PAGE) and HIMEM and make it "BBC Micro compatible" (I think I could run that image in a real BBC Micro if I wanted to)

I have "spool" and "exec" commands for save/load - which means I save text versions to the SD card rather than binary blobs.

I'll put more in another thread later.

-Gordon

Re: Weird behaviour on longer BASIC lines

Posted: Wed Jul 28, 2021 8:22 pm
by jaccodewijs
Hi All!

Well, I converted that CMOS version for CA65 and it actually worked like a charm!
(no surprise there)
Very nice to have a no-IRQ/NMI version with a clean ZeroPage use!

Then I ported it to my full fledged system where I got the original issue and guess what...
AGAIN!

But, I found the culprit in the end...

The CHROUT routine needs to return with the original byte back in the accumulator!
And my routine clobbered that... So a simple PHA/PLA combination did the trick.

Issue fixed.


Now I have one more issue, unrelated, but maybe floobydust could help me out:
How do i set the terminal width to 0 (infinite) in the code?
I need to enter WIDTH 0 when I first start EhBasic to play nice with my screen routine
(Yes, I am outputting it to a V9958 VDP!)
Is it as simple as STZ TWidth? because that doesn't seem to work like that.


Thanks again for all the help!
This is why I love this community ;)

Re: Weird behaviour on longer BASIC lines

Posted: Wed Jul 28, 2021 9:50 pm
by floobydust
jaccodewijs wrote:
Hi All!

Well, I converted that CMOS version for CA65 and it actually worked like a charm!
(no surprise there)
Very nice to have a no-IRQ/NMI version with a clean ZeroPage use!

Then I ported it to my full fledged system where I got the original issue and guess what...
AGAIN!

But, I found the culprit in the end...

The CHROUT routine needs to return with the original byte back in the accumulator!
And my routine clobbered that... So a simple PHA/PLA combination did the trick.

Issue fixed.


Now I have one more issue, unrelated, but maybe floobydust could help me out:
How do i set the terminal width to 0 (infinite) in the code?
I need to enter WIDTH 0 when I first start EhBasic to play nice with my screen routine
(Yes, I am outputting it to a V9958 VDP!)
Is it as simple as STZ TWidth? because that doesn't seem to work like that.


Thanks again for all the help!
This is why I love this community ;)
When you start EhBasic, there are two initial ROM to RAM transfers; one for page $04 for system vectors and Ctrl-C and another for page $00 which contains the startup cold/warm jumps along with some other variables, one being the width.

The WIDTH command sets that variable to $00 for infinite.

If you want to change the default, you can edit the data under "StrTab" where it shows the screen width. It's currently set to $50 (80 decimal). Just make it $00 and that should do it.

Re: Weird behaviour on longer BASIC lines

Posted: Wed Jul 28, 2021 10:34 pm
by jaccodewijs
Found it, thanks!