Scrolling text in 80 column text mode

Welcome to the MSX (V9958) world, Aslak3!

Just for clarification and not for nitpicking, We call the V9958 and its predecessors (V9938 and TMS9918) VDP (Video Display Processor) because they have some processing power likewise we have on modern GPUs. VDC (Video Display Controller) is a nice description for CoCo's 6847.

Well, I've just discussed this with a friend a few days ago. Even if reading/writting the text on screen isn't (performance wise) a good way to do things, it would have a decent speed. Since you don't look satisfied and you're using V9958, you could use the VDP command engine, I think the command YMMM would be exactly what you're looking for.

But I have to ask: how are you doing the scroll? by rewritting the pattern data or the name table? And you are using the autoincrement VRAM address pointer during VRAM Writes?

This is true only for V9938; V9958 can run commands on any screen mode.

AHA thank you guys, very interesting...

In V9958 you can indeed enable VDP command engine to work in text modes as well... how ever this is pretty useless. When command mode is enabled it handles the screen as in SCREEN 8 (256 color mode, 1byte = 1pixel). So logically VDP sees the 128KB VRAM as one 256x512 resolution picture. Because 80-column mode is practically 80x24 picture, it is very hard to do anything useful with the engine as it does not have any linear copy... It can only copy rectangular areas... At this moment you may still think that it is a good idea, but the problems don't stop there, because the addressing of VRAM is "interlaced" in modes where over 32KB is needed for drawing a screen. This means that when VDP is reading or writing the address is divided by 2 and bit 0 becomes bit 16. This means that even if you manage to use the command engine for scrolling, it will actually scroll two screens 64KB from each other. ie. If you in SCREEN 8 write address range #10000-#1FFFF in SCREEN 0 this means you wrote address ranges #8000-#FFFF and #18000-#1FFFF (This kind of things happen when you try to keep downwards compatibility with TMS99x8 series)

Other possibility to use the engine is like ARTRAG suggested. When VDP is not drawing the display area of screen, you can ie. switch in to SCREEN 5 (16 colors, 1 nibble = 1 pixel) where 128KB of VRAM means virtual 256x1024 screen. In this mode the VRAM addressing works in same way as in text modes, but you have to make sure that your copies are finished before it is time to switch back to text & draw the visible screen again.

Practically both methods cause huge headache and I don't even know if anyone has ever used these methods. I would say that if you just have some spare RAM you can use, just keep the copy of screen in RAM and when scrolling, just dump the whole RAM buffer to VRAM... As PingPong explained, this will be fast enough to update whole screen in a screen draw.

Thanks everyone for your replies! I love this place already.

Righty ho. I wasn't aware of the distinction - I've heard of VDP but just assumed it was the same thing. Useful to know it is not!

As others have said, and I was able to very roughly determine myself reading the manual, this would be hard I think. I'm still unsure if it is totally unsuitable, but from the sounds of it, it is. It's a real shame because the VDP should be lightning fast at moving around 80x24 bytes.

Yes, I'm using auto-increment. So I actually have 6 console in VRAM, at 0x8000, 0x9000, 0xa000 etc. I'm doing the following actions:

1. "Seek", in read mode to 0x8000 + 80
2. Read in 80x23 bytes
3. "Seek", in write mode to 0x8000
4. Write out 80x23 bytes
5. "Seek", in write mode to 0x8000 + 80x23
6. Zero 80 bytes

In the 6809 I'm doing standard looping with a 16bit index register counting down. I have found that when writing I need 3 nops (2Mhz machine cycle in the 6809) after the store to the VDP port. Otherwise I get the odd missed byte when doing consecutive (unrolled) writes. I have no nops on the read loop.

Looking at the 6809 datasheet I've calculated that my read loop is 18 cycles long. The write loop, with the nops, comes in at 25 cycles. Doing clears only shaves 6 cycles from the write loop.

So the total cycles to do a scroll, ignoring setting up the VRAM pointer registers, is:

18 x (80 x 23) + 25 x (80 x 23) + 19 x 80 = 33120 + 46000 + 1520 = 80640

With a 0.5uS machine cycle, this is 0.04032 seconds, or just about 1/25th second. I really need to try shaving those nops. I should not need them inside the loop, only when doing "inline" writes. Anyway, does this sound roughly as good as I'll ever get, or am I missing some "tricks"?

For most uses, eg. if I wanted to run a BASIC in my little computer, or run a DOS shell that I intend to write, the scrolling would probably be fast enough. The problem is that I have another use in mind for my little micro - as a serial terminal. Right now I'm loosing data, a lot of data, at the start of each line, if the screen has to scroll. Even with a FIFO in the UART, the data cannot be pulled off fast enough since the 6809 is busy scrolling the text buffer.

One thing that might help a bit is chunking up the scrolling and scroll at every 2nd or 4th line or similar. This ould be nasty. Nastier still would be to not scroll at all and just wrap the cursor to the top of the screen, blanking out the current line. But... Yuck.

Boy, I wish the pattern name base was settable to a specific byte (or even modulo 80) RAM address.

Thanks everyone.