Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

xt_words doesn't respect max line length correctly #270

Open
wkjagt opened this issue Oct 7, 2022 · 3 comments · May be fixed by #271
Open

xt_words doesn't respect max line length correctly #270

wkjagt opened this issue Oct 7, 2022 · 3 comments · May be fixed by #271

Comments

@wkjagt
Copy link

wkjagt commented Oct 7, 2022 •
edited
Loading

When using words on an 80 column terminal, many lines will be slightly longer than 80 characters, see screenshot below.

image

I've been staring at xt_words for a while but I can't see anything wrong with how it determines when to put a CR. But somehow it does manage to output lines well over 80 characters. I looked in headers.asm but the word lengths in there seem correct. I also directly hardcoded cmp #79 in the loop that loops over the words, but that changes nothing, so it doesn't compare to an accidental longer line length either.

I'm going to keep staring at this a bit more, but I thought you might know about this issue, or the cause of it.
@wkjagt
Copy link
Author

wkjagt commented Oct 8, 2022

I found what is causing this. This is setting the counter back to 0 while it already has the next word in memory that it's about to print, so it needs to take that word's length into consideration. So instead of lda #0, this should be lda 0,x, which holds the length of the current word. And then an additional inc to take the printed space into account, same as just above. I'll see if I can put up a pull request.

image

@SamCoVT
Copy link
Contributor

SamCoVT commented Oct 13, 2022

Hi @wkjagt. Thank you for opening an issue and your sleuthing work to find the root cause. That's a good catch. We have two master branches (for two different assemblers - we're moving to 64tass for conditional assembly support), but you can issue a pull request for either master branch and I'll apply the patch to the other branch. You're likely on the "master" branch using the Ophis assembler.
Scot hasn't been super active recently so it may be a bit before it gets pulled into this repository.

@wkjagt wkjagt linked a pull request Oct 13, 2022 that will close this issue
Open
@wkjagt
Copy link
Author

wkjagt commented Oct 14, 2022

👋 @SamCoVT Thanks for the message! Yeah, I'm on master, using Ophis. I just put up a PR here: #271. This change fixes it for me. I hope the PR is complete. I saw that some other changes were also generated when running make, in docs I think. I didn't commit those. Not sure if I should have.

This is an awesome project by the way. I am using it on my homebrew 6502. I have 80 column text output to a screen, and a custom keyboard, so this TaliForth works really well with that, and really makes it feel like a standalone computer with a fun OS and completely independent from a connection to a laptop 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix broken line length in xt_words wkjagt/TaliForth2
2 participants
@wkjagt @SamCoVT