6502 with the RA8875

[AlexeyM82]

PaulaM wrote:

AlexeyM82 wrote:

PaulaM wrote:

I managed to get scrolling working on my 6502 laptop screen.
This uses the block transfer engine, which copies the bottom portion of the screen (0,16 - 800,480) to the top of the screen (0,0) and then fills the bottom 16 pixels with black (draw fille square in black).
The scrolling is instant and seamless

https://files.mastodon.social/media_att ... 8741af.mp4

Hello, Paula!
As far as I understand, this scrolling task was purely for testing the BTE's capabilities? As far as I remember from the datasheet, the RA7588 has powerful screen or window scrolling capabilities, both horizontally and vertically.

Not quite, the built in scrolling "wraps" the window, so whatever goes off the bottom appears at the top. This means that the origin (x = 0, y = 0) moves as the screen scrolls.

I understand, yes, I have encountered this effect. You need either to adjust the coordinates when outputting by the amount of offset when scrolling, or a method similar to the one you proposed.

[AlexeyM82]

PaulaM wrote:

AlexeyM82 wrote:

PaulaM wrote:

Hi Alexey,

As Glenn says there is a way to clear the screen quickly, use the built in engine to draw a square that is the size of the screen, in black and then fill the square in black.
It needs about 16 commands, to be sent, but takes a fraction of a second (I think I measured around 270milliseconds to do this).

with reference to the level translators I used the TX0108, and as Glenn says again, when I'm not reading/writing to the display it is in the high impedance state.

Paula, I looked at your circuit from the posts above. In it, the OE converter inputs are connected to the +3.3 volt circuit. Could you please tell me how they are configured for high impedance operation? Or is there a modified circuit? What signal controls the OE?

for the status/control lines (RnW, nCS, E, etc) they are connected to a CPLD.
For the databus There is an enable like, through a resistor diver that is controlled by the CPLD (this is actually the same as the chip select, just inverted so it is active high)

Screenshot 2026-01-28 131354.png

Thanks, Paula. Now everything is clearer about controlling the converters. I'll try connecting the display to my 65802 via the parallel interface. I hope to get a performance boost compared to the SPI. Did you see my video showing the screen fill rate?

[PaulaM]

AlexeyM82 wrote:

Did you see my video showing the screen fill rate?

I did, but if you use the block fill as suggested previously it's instant.
See my RA8875 based 9" screen switch on, initialise and clear in under 1 second using that method

https://files.mastodon.social/media_att ... 8dc643.mp4

[AlexeyM82]

PaulaM wrote:

AlexeyM82 wrote:

Did you see my video showing the screen fill rate?

I did, but if you use the block fill as suggested previously it's instant.
See my RA8875 based 9" screen switch on, initialise and clear in under 1 second using that method

https://files.mastodon.social/media_att ... 8dc643.mp4

I wrote in the post above that I used the 6502 to fill the screen only to understand the speed. Clearing and filling can obviously be done using the PA7588 hardware, and I've learned how to do that too. But how, for example, do we solve the problem of displaying an image from RAM or loading it from disk into the display's memory? Let's say we want to load the playing field for the next stage of a game, or an image from disk. This task will be accomplished by transferring a large amount of information using our 6502.

[PaulaM]

I would expect parallel loading to be quicker than SPI.

[AlexeyM82]

Good day, friends.

I had this idea (I haven't tested it in practice): the Ra7588 has 768 kilobytes of video memory. If you use 256 colors per pixel, only half is displayed. The other half (384 kilobytes) is used as layer 2, which doesn't need to be displayed. The idea is that you can load some graphic bitmaps (sprites) into this memory, store them there, and use the BTE to quickly move them and display them in the visible area. This should be very fast, and the 6502 will only issue commands to move and position these sprites. What do you think about this?

[PaulaM]

an interesting idea, worth trying
Let us know how you get on

[AlexeyM82]

PaulaM wrote:

an interesting idea, worth trying
Let us know how you get on

Hello, Paula!
Of course, I'll tell you if you don't beat me to it. I'm currently struggling with free time, so I'm not progressing as quickly as I'd like. But my idea is absolutely feasible and doable. Today, I delved into the theory in the datasheet, and section 7-6-4-3 confirmed this possibility.

The Move BTE source/destination can be a rectangular area or a linear area. This function
allows the temporary saving of a portion of the visible DDRAM to an off-screen area for later
usage. Or copy the off-screen data to the visible area.
The suggested programming steps and registers setting are listed below as reference.
1. Setting source layer and address Æ REG[54h], [55h], [56h], [57h]
2. Setting destination layer and address Æ REG[58h], [59h], [5Ah], [5Bh]
3. Setting BTE width and height Æ REG[5Ch], [5Dh], [5Eh], [5Fh]
4. Setting BTE operation and ROP function Æ REG[51h] Bit[3:0] = 2h
5. Enable BTE function Æ REG[50h] Bit7 = 1
6. Check STSR REG Bit6 Æ check 2D final

[AlexeyM82]

Hello, friends!
I don't like the TX0108. I found another alternative, which seemed more suitable to me: the ADG3308. I ordered it and am waiting. Once my order arrives, I'll build the parallel interface.

[PaulaM]

AlexeyM82 wrote:

Hello, friends!
I don't like the TX0108. I found another alternative, which seemed more suitable to me: the ADG3308. I ordered it and am waiting. Once my order arrives, I'll build the parallel interface.

Any special reason?
I have found the TX0108S to be better than the TX0108B

[GlennSmith]

GlennSmith wrote:

Cool pic!
Two last questions (I hope) :

• I'm trying to read back from TEXT memory - has anyone managed to do this? (ie I would like to be able to make a sort of screen-based editor)

So far I'm always getting zeros wherever I place the read cursor...

• (touchpanel : fixed)

I don't think I've ever had to spend so long getting a finished product to work properly!

I'm bumping my own post - for documentary completeness. I have been trying to read back text from the RA8875 display, in vain. I used the "post a support question" form on RAIO's website, and got a reply from one of their engineers in less than a day! The answer : it's not really possible... The reason : the RA8875 passes text mode bytes through the font conversion process and sends the resulting pixel pattern into the graphics layer. To prove it the guy sent me a little code snippet which could read back the 16x16 pixel pattern of a text chr. from the display. So I slept better last night, not worrying about why I couldn't get something to work...

[BigDumbDinosaur]

GlennSmith wrote:

I'm bumping my own post...used the "post a support question" form on RAIO's website...it's not really possible...

The solution, for what it’s worth, would be to shadow the text display in RAM, unfortunately an expensive undertaking with the 65C02 and its limited address space.  If there are also text attributes, shadowing those in RAM as well would get even more expensive.

I’ve messed around a bit with the idea of text mirroring for editing purposes with my POC V1.3 unit, which has 112K of user-accessible RAM.  Even there, it is expensive, not only in terms of required address space (about 4K for text and attributes, plus some pointers to track the cursor), but in processing time to maintain the mirrors.  It’s one of those situations in which the greater processing power of the 65C816 doesn’t really help.  Maybe when I build a unit for more free RAM I’ll give it another look.

[PaulaM]

I guess you could just keep track of the characters as ASCII values, it won't use as much as pixel by pixel, but will still use a chunk of memory.

FWIW, I'm going to try the RA8889 next as I want to use a 10.1" screen which is 1024x600 (I'm not fussed about the resolution, I just wanted a larger screen).
I'll post updates here when I get things working.

[BigDumbDinosaur]

PaulaM wrote:

I guess you could just keep track of the characters as ASCII values, it won't use as much as pixel by pixel, but will still use a chunk of memory.

Yep.  For an 80 × 24 display such as I use, that’s nearly 2K.  Since each character has attributes (bold, underline, etc.), which are expressed in a byte-wide bit field, another 2K is needed for that.  The usage of 4K of RAM is bad enough.  Functions are needed to maintain the shadows so they always reflect what is on the screen.  For example, if the display is told to scroll up a line, a while bunch of bytes have to be shifted in the text and attribute shadows.  Lotsa work for the MPU. 

[GlennSmith]

PaulaM wrote:

FWIW, I'm going to try the RA8889 next as I want to use a 10.1" screen which is 1024x600 (I'm not fussed about the resolution, I just wanted a larger screen). I'll post updates here when I get things working.

Does that exist as a complete display like the 7" one I have, or do I have to dust-off my new microscope to solder tiny ribbon connectors?
(edit : OK, I've found the display on the 'net)
For the editor, I think I'll try some different tactics. (Edit : probably creating my own ANSII compatible driver for a RA88xx display)
Oh how I miss my HP2621 VDU...