Hello,

how can I read out vast amount of texts (hundreds of lines) and display them on a 20x4 display?
What I did so far is reading up to 256 characters from the space indicated with .BYTE or .ASCIIZ and displaying it, even with scrolling the lines from bottom to top on the 20x4.
Now I want to address much more text and I fear, I miss even how to ask the right questions regarding how to do it. Because reading from .BYTE is easy to do with just counting until 255 and handing the characters over to the display. But how to proceed for much more text stored in the program? How can i read this out properly?

Thank you for some suggestions.

You're going to want to come up with a plan to allow the user to interactively pause and/or scroll the display up and down. To access the text, I would use indirect addressing with a zero-page pointer, but I don't have time to provide a specific example ... my broken down house desperately needs my help right now ...

_________________
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)

It is fairly easy to handle more than 256 characters from a buffer. Consider:

Hi,

I've implemented, pretty much exactly what you're looking for, on my first SBC. You can find the current firmware here although it's a very preliminary version.

This is what I've done. I've assigned a nice chunk of RAM ($7000-$7FFF) as "screen memory". I then use two bytes in ZP as a pointer to the beggining of the portion I want to show on the display. On startup, $10.$11 points to the beggining of my screen:



I have a routine that moves the LCD cursor to the first location, then sends the first 80 characters (starting at (SCREEN_POINTER) to the LCD. Keep in mind the lines are "out of order" on the LCD (First, then third, second, and fourth"



This routine is called by my interrupt service routine. Given the slow refresh rate of the LCD display, 5 times per second is more than enough. BTW, lcdChar is a routing that sends the character on A to the LCD.

Finally, to move the window, I have two routines to scroll up or down a line. This is simply done by adding/substracting 20 from the current SCREEN_POINTER. Some additional code is needed to check for the boundaries of my screen memory.



As I said, is very preliminary, and it is been a very long time since I did anything in assembler... there is a big potential for improvements for sure. But I can say it does work.

Hope it helps.

Cheers!

Thank you all so much so far! Since I'm really new in programming in general and in assembly language especially, I tried to take any hint very serious.

Thanks to @barrm95838, I started to read quite a bit on all addressing modes for the 65C02 and especially on indirect addressing, memory structure and so on.

Thanks to you, @BillG, I was then able to apply your code and learn with it. I made it to read out from the data saved in the ROM for more than 255 characters and in my case to store them in the RAM at a certain address.
I am following an approach to enter a routine to display four lines (4x20 characters) at once and then to store the "next" 4 lines (which are the previous ones minus 60 characters) at that buffer in the RAM.
You can imagine now, where i failed: Exactly at that point where the 255 counter needs to subtract the "60 characters" from the pinter (right term here?) when i reached already 255 lines (and the ZPPtr+1 needs to be subtracted as well and so on).

@daniMolina: Thank you for your post! I will try your code as well. I have some questions: Do you store the long text you are displaying at the address starting with $7000? Where is the text located first? Because I burn all the text first in the EEPROM and then try to shift it to an address in the RAM from where I read it in for the display. Where in your code is this transfer from ROM to RAM (starting with $7000, I assume)? I'm pretty sure I am missing something. Thanks for some more hints!

Here is my code example. What works perfectly is displaying the first 255 characters, each 4 lines are perfectly scrolling ... until I reach the 255 threshold and it doesn't to subtract properly (see below in the print "ROWS" routine: SBC #60 and so on):

First, a comment, then I will get to the cause of your problem.

The SBC instruction uses the carry flag to indicate whether there is a borrow from a previous subtraction; carry set means no borrow.

Usually, you will see the sequence



It was not a problem in your case because the code above



was leaving carry set. Advanced programmers sometimes take advantage of these opportunities to save bytes and cycles, but document them well because the code is not as obvious.

Anyway...

The code



steps from one 256-byte page of text to the next.

When you are trying to step back by subtracting three lines from Y, you are not reversing the process when you hit the beginning of a page.

Thank you! That is very helpful to understand. I will integrate for now SEC and SBC and comment it.




Thanks a lot for this information! It solved the problem, everything works fine now!

So the carry flag is set, when after the subtraction of 60 the counter does not need to cross the 255 border again. Correct?

Made my day!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Hmm, there may be some confusing between load-immediate and load-zeropage in the above analysis. But some of the points remain valid.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

ç

It's stored nowhere. I have a "charPrint" routine that moves a character to (SCREEN_CURSOR_POINTER) which is $7000 on startup. After each char is printed, it increases the pointer by 1. On top of this I've built a "stringPrint", "decPrint", and "hexPrint" routines.

My idea was not to display a long text, but to have the hability to print to screen, and then scrollback to see what's been going on, so there's no initial big text stored anywhere.