9938 Programming

[+9640News]

I'm trying to speed up some scrolling speed in Text mode 2 of the Geneve. Current code right now does a read of something like 24 x 80 lines, then does the standard scroll up. I know in Graphics mode, you can change the pointer by writing to a register and change the display position without the extra reading/writing. I have done that before and made some really FAST scrolling GIF graphics.

 

Is there something similar available in Text Mode 2? I know there are display pages, just wondering if I can change a pointer and "instant" scroll.

 

I know I can also tweek the VMBR and VMBW code to do repetitive reads/writes without looping as another option. Just trying to find the fastest way to scroll without thinking too hard this early in the morning. Up too late last night watching a ball game and brain is slow this morning.

 

Beery

[+Lee Stewart]

In the V9938 manual, VR02 allows setting address lines A16 – A12 for the Pattern Name Table (screen image) in Text Mode 2, which implies 4-KiB boundaries (32 unique tables for 128 KiB VRAM). However, the example shows use only of 8-KiB boundaries (16 unique tables for 128 KiB VRAM), with Color Tables and Pattern Generator Tables unique to each Pattern Name Table. This would obviously require changing not just VR02 but also VR03, VR04 and VR10, as well, for each change of Pattern Name Table.

 

That said, I would think you could have up to 31 unique Pattern Name Tables in 128 KiB VRAM if they all use the same Color and Pattern Generator Tables—requiring only changes to VR02. Tim?

 

...lee

[Asmusr]

I think it should be possible to use the vertical offset register R#23 for scrolling.

 

 

This register R#23 sets the value of the first line to display on the screen. Virtual screen size is 256 lines, visible vertical screen size can be 192 or 212 depending on LN bit of register R#9. Setting R#23 to value other than 0 may display un-initialized parts of the memory which may look as garbage. Display of virtual screen is performed in cycle, meaning that when increasing value of R#23 top of virtual screen appears at the bottom of visible screen.

 

Edit: It would work like a cyclic buffer where you always update the just below the visible viewport before changing the value of the register. When you reach the bottom you start again at the top.

[+9640News]

I know that works within Graphics mode. I just was not sure what happened within Text Mode 2.

 

Beery

[+InsaneMultitasker]

I remember reading through a few MSX forums while trying to find some answers about the video modes. My testing had concluded some functions, like the logical and high speed operations, are not meant for the lower mode numbers. The forums seemed to agree. Of course, you can easily test VR#23 yourself with a few VWTR calls.

 

For scrolling TEXT mode, you have a few options.

1. Keep a virtual screen in CPU RAM and just write from CPU to VRAM each time you scroll. This is how FastTerm achieved higher speeds. You are eliminating the need to read from the screen each time you scroll. An indexed buffer would probably do the trick. Clearing the screen could happen in tandem with clearing the CPU buffer.

2. PORT currently does a brute force copy/paste method. I believe I allow RS232 interrupts every 60-80 characters, which works mainly because I don't allow any VDP access within the interrupt handler. I really want to change this to option 1 some day,which would further increase the display speed.

3. Some time ago someone (Rasmus?) posted quick VMBW/VMBR routines that write/read 8 bytes unrolled at a time.

4. With the Geneve you can turn off the video wait states. You'll need a NOP delay, probably just before you write each byte, or you might overrun the 9938. This can depend on where your workspace is located, the type of RAM (slow or FAST), and whether the routine is in the 9995 ram space.

 

That's all I can think of at the moment.

[+9640News]

I remember reading through a few MSX forums while trying to find some answers about the video modes. My testing had concluded some functions, like the logical and high speed operations, are not meant for the lower mode numbers. The forums seemed to agree. Of course, you can easily test VR#23 yourself with a few VWTR calls.

 

For scrolling TEXT mode, you have a few options.

1. Keep a virtual screen in CPU RAM and just write from CPU to VRAM each time you scroll. This is how FastTerm achieved higher speeds. You are eliminating the need to read from the screen each time you scroll. An indexed buffer would probably do the trick. Clearing the screen could happen in tandem with clearing the CPU buffer.

2. PORT currently does a brute force copy/paste method. I believe I allow RS232 interrupts every 60-80 characters, which works mainly because I don't allow any VDP access within the interrupt handler. I really want to change this to option 1 some day,which would further increase the display speed.

3. Some time ago someone (Rasmus?) posted quick VMBW/VMBR routines that write/read 8 bytes unrolled at a time.

4. With the Geneve you can turn off the video wait states. You'll need a NOP delay, probably just before you write each byte, or you might overrun the 9938. This can depend on where your workspace is located, the type of RAM (slow or FAST), and whether the routine is in the 9995 ram space.

 

That's all I can think of at the moment.

I already have video wait states off. I had not thought of the NOP delay, thanks for pointing that out

 

One thing I thought about after posting that first message was mapping in a single page of ram during the scroll routine and having something like 25 * 80 continuous read and another continuous write instructions without an INCrementer or DECrementer. All that costs is a single page of ram. I'm probably going to have to insert a few routines to read the RS232 port and buffer characters. I'm just not sure what the frequency needs to be running at 38.4K.

 

Beery

[+InsaneMultitasker]

Revisiting this thread. If you limit your interrupt handler to non-VDP tasks, you can in theory leave interrupts enabled to allow the handler to capture RS232 characters during the scroll. Did you settle on a specific routine here?

 

I already have video wait states off. I had not thought of the NOP delay, thanks for pointing that out

 

One thing I thought about after posting that first message was mapping in a single page of ram during the scroll routine and having something like 25 * 80 continuous read and another continuous write instructions without an INCrementer or DECrementer. All that costs is a single page of ram. I'm probably going to have to insert a few routines to read the RS232 port and buffer characters. I'm just not sure what the frequency needs to be running at 38.4K.

 

The NOP delay may only be needed when setting the read/write address. I do seem to recall overrunning the 9938 under certain conditions so some experimentation is in order. It might be fun and worthwhile to replicate the 9918 overrun/timing tests using a real Geneve and 9938. A partially unrolled scroll loop (e.g., 8 VDP reads/writes per loop) with no delay between those 8 successive reads/writes - and placed into scratchpad/9995 RAM - would be a worthy speed test.

 

For the graphics mode 6 text display routines, VR#23 works well (in emulation) to scroll the active graphics display page. Moving the character rendering loop into scratchpad RAM increased character display speed by more than 50%. I've sent you a test program for the real iron.

[+9640News]

I have been converting a program that was originally in 40 column mode to 80 column mode with the 9938 on the Geneve.  I ran across an odd behavior, I hope someone can explain.

 

I set the registers, move the pattern table, and attempt to clear the first 26x80 characters with the space character.  At this point, the code goes into a loop waiting for a keypress.  The screen however, is not cleared with the space character and is filled with garbage.  If i touch a key that is ignored during the KSCAN call, the screen then updates to what it should be.  However, if no key is touched, garbage remains.

 

I ended up solving the issue with adding code setting a register to blank the screen right before setting 80 column mode, then disabling the blanking of the screen after setting the 80 column mode.  This restored the screen without having to touch a key during the KSCAN call.

 

At this point, I am just trying to understand the cause, etc.

 

Beery

[+FarmerPotato]

Checklist item 1: Have you stashed your VDP register 1 at >83D4?

 

“Garbage” sounds like the video mode has been changed. The 9938 uses the 3 reserved bits of R1 that the 9918 did not. 

2. Is this under GPL or GeneveOS?

 

Edited October 7, 2022 by FarmerPotato

[+9640News]

8 minutes ago, FarmerPotato said:

Checklist item 1: Have you stashed your VDP register 1 at >83D4?

 

“Garbage” sounds like the video mode has been changed. The 9938 uses the 3 reserved bits of R1 that the 9918 did not. 

2. Is this under GPL or GeneveOS?

 

I will need to double check >83D4.  It is under GPL mode.

[+FarmerPotato]

Backgrounder  for anyone interested:

 

It’s the Screen Saver. 
 

GPL has a countdown timer to blank the screen.  The console (GPL) decrements it as time passes.  At 0,  it blanks the screen.  
 

“Blank” means to set a bit in VDP register 1 named BL, which displays only the background color. Familiar!
 

KSCAN reloads the timer whenever it sees a key is pressed. It also restores VR#1 to its previous value, clearing the BL bit. 

 

You can’t READ a VDP register. So GPL keeps a copy of VDP register 1 cached in >83D4. If you change the video mode, you need to update that too. 

 

VR#1 contains mode bits M1 and M2 for text and multicolor mode. So if you set text mode in VR#1, and don’t update >83D4, KSCAN will put it back to Graphics mode. 

The 9918 modes

M3 M2 M1
0 0 0 Graphics
0 0 1 Text 40 (
0 1 0 Multicolor
1 0 0 Bitmap (Graphics 2) added in 9918A. 

(M3 is in VR#0)

Also:

M4 in VR#0 extends 40 column text to  80 column text. 

 

So here’s what could be going on:

 

You set M1 in VR#0 to get Text 40 mode.

You set M4 in VR#1 to get 80 columns. 

You don’t update >83D4. 
KSCAN resets M1 in VR#1 when it resets BL. 

 

The V9938 interprets this combination as G3, which is the familiar bitmap mode plus enhanced sprites.  So, lots of pixel vomit.

Don’t want to end this post with “vomit” so here’s a reference link. 
 

https://www.msx.org/wiki/VDP_Mode_Registers#Control_Register_0_.28All_VDPs.29

Sub page:

https://www.msx.org/wiki/VRAM_Maps

(I get Moses G3 and G4 confused.)
 

 

 

 

[+9640News]

@FarmerPotato

 

OK, thanks for that more detailed explanation.  I think that nails what I was seeing.

[+9640News]

OK, got another question for something I was searching for in the 9938 manual I could not find some time ago, and it was something I thought I had used in a demo in the past.

 

I had a number of 64K screen dumps/files I would scroll up by one pixel row at a time.  The bottom row from a buffer in cpu RAM, would then be written to update the last row. 

 

As I recall, I used a single video register that changed the display position row in the 128K of VDP.  It wasn't a block move or block copy, but rather a video register written where I gave it the new row position that adjusted the display position on the screen.

 

I've been through the 9938 manual and can not seem to find the particular register I need to use.

 

Is there such a video register?  Or maybe so much time has passed, it was actually a block move/copy I used instead.  I would have swore it was a position change as I could really scroll the screen smoothly and very fast.

 

Beery

 

 

[+mizapf]

32 minutes ago, FarmerPotato said:

I get Moses G3 and G4 confused.

Who of them is the one who parted the Red Sea?

[jbdigriz]

>>> Don’t want to end this post with “vomit"...

 

ROFL. There is really no good place for emesis, is there? Thanks for the nice exposition, @FarmerPotato

Edited October 7, 2022 by jbdigriz

[+9640News]

10 hours ago, FarmerPotato said:

Checklist item 1: Have you stashed your VDP register 1 at >83D4?

 

“Garbage” sounds like the video mode has been changed. The 9938 uses the 3 reserved bits of R1 that the 9918 did not. 

2. Is this under GPL or GeneveOS?

 

I just checked my code. I did store the register at >83D4.  I did find an error in the code that was the source code of the original code I used.  Instead of setting R0 to >01F0 and doing a VWTR, the original code did a R1 to >01F0.  

 

[+InsaneMultitasker]

12 hours ago, 9640News said:

I had a number of 64K screen dumps/files I would scroll up by one pixel row at a time.  The bottom row from a buffer in cpu RAM, would then be written to update the last row. 

 

As I recall, I used a single video register that changed the display position row in the 128K of VDP.  It wasn't a block move or block copy, but rather a video register written where I gave it the new row position that adjusted the display position on the screen.

You are most likely thinking of register #23.  Very handy for "fast vertical scrolling".   

 

I like the "programmers manual" version and recommend keeping a copy handy.  I believe that  @artrag provided some updates.  I visit the online version (you can download it) because there is a linked index.

 

Display Registers - Yamaha V9938 Programmer's Manual [Page 20] | ManualsLib

 

Also there is the old thread from 2019 where horizontal scrolling is touched on.

 

 

 

[+9640News]

16 hours ago, InsaneMultitasker said:

You are most likely thinking of register #23.  Very handy for "fast vertical scrolling".   

 

I like the "programmers manual" version and recommend keeping a copy handy.  I believe that  @artrag provided some updates.  I visit the online version (you can download it) because there is a linked index.

 

Display Registers - Yamaha V9938 Programmer's Manual [Page 20] | ManualsLib

 

Also there is the old thread from 2019 where horizontal scrolling is touched on.

 

 

 

Thanks Tim.  That was the register I was looking for.  Not sure how I overlooked it as I do have the Programmer's guide you referenced.  

[artrag]

http://rs.gr8bit.ru/Documentation/V9938-programmers-guide.pdf

 

This should be the updated manual

Edited October 8, 2022 by artrag

[+InsaneMultitasker]

I attached the disk image that I referenced back on 3 January 2019.  I had modified VCLR (my color ansi file viewer) to leverage scroll register 23.  The speed difference is very noticeable when you display a long text file, as it displays too quickly to read.  I haven't done anything further with the code and haven't located my source though I'm sure it's around here somewhere.   

 

MDOS expects VR#23 to remain static, so depending on the length of the file you could 'lose' the prompt off screen. Hopefully this works on real hardware, as I don't recall whether I ever tested it outside of emulation. 

 

See the !README file.

 

Graphics mode 6 for Beery 1-3-2019-360K.DSK

[+9640News]

5 hours ago, InsaneMultitasker said:

I attached the disk image that I referenced back on 3 January 2019.  I had modified VCLR (my color ansi file viewer) to leverage scroll register 23.  The speed difference is very noticeable when you display a long text file, as it displays too quickly to read.  I haven't done anything further with the code and haven't located my source though I'm sure it's around here somewhere.   

 

MDOS expects VR#23 to remain static, so depending on the length of the file you could 'lose' the prompt off screen. Hopefully this works on real hardware, as I don't recall whether I ever tested it outside of emulation. 

 

See the !README file.

 

Graphics mode 6 for Beery 1-3-2019-360K.DSK 360 kB · 1 download

Yes, it works on real hardware and is very fast!

 

Beery

[+InsaneMultitasker]

16 hours ago, 9640News said:

Yes, it works on real hardware and is very fast!

 

Thanks for trying it on the real thing.  I read through some of the source, and it occurs to me that my concerns about the sprite table might be easily resolved by relocating the screen to the 2nd 64K bank of vram.  VR#23 routines could free up space in the video XOPs by replacing the graphics mode scrolls, however, this isn't feasible in all cases since the current window size can be set to fewer rows and columns than the maximum, visible display window.