Jump to content

Photo

9938 Programming


6 replies to this topic

#1 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • 752 posts
  • Location:Campbellsburg, KY

Posted Wed Feb 21, 2018 6:19 AM

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



#2 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,870 posts
  • Location:Silver Run, Maryland

Posted Wed Feb 21, 2018 10:51 AM

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



#3 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,997 posts
  • Location:Denmark

Posted Wed Feb 21, 2018 2:05 PM

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. 



#4 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 752 posts
  • Location:Campbellsburg, KY

Posted Wed Feb 21, 2018 2:24 PM

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

 

Beery



#5 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,316 posts

Posted Wed Feb 21, 2018 2:50 PM

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.   


  • RXB likes this

#6 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 752 posts
  • Location:Campbellsburg, KY

Posted Wed Feb 21, 2018 4:10 PM

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



#7 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,316 posts

Posted Thu Jan 3, 2019 4:14 PM

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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users