9938/9958 Discussion Forum

[Omega-TI]

Go for it!

[+InsaneMultitasker]

OK I'll bite.

 

Here is a gem I encountered recently. It is a "rewrite" of the V9938 technical manual. It has helped me decipher a few mysteries. One mystery I have been gnawing on is why the Geneve's video routines appear to write more than double the number of bytes to generate a bitmap character in graphics mode 6.

 

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

 

http://www.konamiman.com/msx/msx-e.html#msx2th (MSX reference with code examples for various commands)

Edited November 9, 2013 by InsaneMultitasker

[TheMole]

That's a cool effort, would be nice if the same could be done for a lot of these older datasheets.

[Omega-TI]

OK I'll bite.

 

Here is a gem I encountered recently. It is a "rewrite" of the V9938 technical manual. It has helped me decipher a few mysteries. One mystery I have been gnawing on is why the Geneve's video routines appear to write more than double the number of bytes to generate a bitmap character in graphics mode 6.

 

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

 

This is truly a fantastic find, I'm impressed The guy who re-wrote this devoted a TON of time and effort and talent. Thank you Eugeny Brychkov, wherever you are. I especially like how the index is linked to the information in the document. I imagine this will become the functioning "Bible of the chip" to some, now that it's existence is known.

 

Thanks for sharing.

[+InsaneMultitasker]

I have asked Michael some related questions but thought that I would post a bit to this thread. Perhaps one or more of you have come across information related to the 9938 VDP internal commands to move memory within VRAM or CPU<>VRAM. I have a puzzle that is driving me crazy!

 

In the Geneve OS, there are routines to generate a 16-color, 80-column text mode using bitmap graphics mode 6. I use this mode in my PORT terminal emulator to display color ANSI text/ibm graphics.

 

The logical CPU to VRAM move command is used to 'draw' each character, dot by dot. (I was confused about this because the manual shows pixels to bytes in one area, and dots in another). After some pondering I modified the OS routine into a standalone function. I then modified it from logical to high-speed move in an attempt to generate the character faster. I succeeded to a degree: my routine works and displays text slightly faster. But there is a troubling bit of code I do not understand.

 

The Geneve OS routines follow each byte of data with a second byte 0xAC. I searched MSX and other forums for an explanation. I scoured the 9938 manual and any technical data I could locate. I even came across an example (posted below) that shows this same byte being transferred in another non-TI/Geneve related routine... with no explanation.

 

If I remove the step of writing 0xAC to the 9938, the VDP will not process any further data. The system is held hostage until power down. I admit the explanation could be staring me in the face... but I can't see it. Best I can tell is this step may have been documented in a developers kit or some other unavailable-to-the-masses doc.

 

My intent is to speed up the drawing routine and couple it with the horizontal scroll register #23 to create a much faster terminal emulation. By creating a standalone routine, I also think it may be possible to port the 80-column color text routine to the other 9938/9958 devices used with the TI.

 

Here is the snip of code showing the 0xAC write by a non-TI/Geneve computer.

 

Any thoughts or ideas would be appreciated.

.waitvdp:       call ReadStatus         ; reads S#2
                bit 0,l
                jp z,.endvdp            ; the command is over
                bit 7,l
                jp z,.waitvdp           ; still not ready to transfer next byte
                inc de
                ld a,[de]
                out ($99),a
                ld a,128+44    ;****************  writing 172 to vram after each byte ******
                out ($99),a             ; write next byte to R#44
                jp .waitvdp             ; loop
.endvdp:        xor a
                call $00D8
                jr z,.endvdp            ; waits for spacebar pressed
                xor a
                call $005F              ; screen 0
                ret

Edited November 9, 2013 by InsaneMultitasker

[matthew180]

Note: that 9938 Programmers Manual has errors. I found a few the other day when trying to get solid answers to the 80-column problem. So make sure you double check your information.

[+InsaneMultitasker]

Note: that 9938 Programmers Manual has errors. I found a few the other day when trying to get solid answers to the 80-column problem. So make sure you double check your information.

Unfortunately, there appears to be no reference to or explanation of this bit of magic - not in the manual nor anywhere else I've searched.

 

I found references but little help example-wise within the manual. I came across another site with the "MSX Technical Handbook" which I have linked to above. It contains more good information and code examples related to the various commands.

Edited November 9, 2013 by InsaneMultitasker

[+Lee Stewart]

It looks like the color register (VR44) is used for data transfers to/from CPU from/to VRAM.

 

...lee

[+InsaneMultitasker]

It looks like the color register (VR44) is used for data transfers to/from CPU from/to VRAM.

 

...lee

 

Hmmmm... could it be the register number needs to preceed the data for each individual byte written? Ughhhhh. I hope that's not the case then again you might be on to something. Time to step away and let the thoughts percolate.

 

(I added an MSX2 reference link to my earlier post. It contains code examples for many of the commands. )

[jens-eike]

Doesn't VWTR transfers the data byte then the register# OR >80 ?

In http://www.konamiman.com/msx/msx2th/th-4b.txt

the "data to be transferred" is always written to R44

Edited November 9, 2013 by jens-eike

[+InsaneMultitasker]

Doesn't VWTR transfers the data byte then the register# OR >80 ?

In http://www.konamiman.com/msx/msx2th/th-4b.txt

the "data to be transferred" is always written to R44

 

Agreed. And with that knudge I tracked down the last troubles -- related to VDP R#17 and the indirect register addressing auto-incremember function.

 

The reason the Geneve OS is setting the VDP register each pass (in VWTR fashion) is because indirect addressing auto-increment is never properly turned off after the command registers are loaded. So Instead of pumping data to VDP Port #3, the routine had to send a byte of data, reset the VDP register, sent another byte, and repeat until finished.

 

Further complicating matters is that the indirect addressing bit is in the same position as the "VWTR" register bit. I was 'blind' to this while reading the code. However, after reading your comment I took a closer look at the HMMV code in "th-4b.txt". I noticed that unlike the Geneve, the MSX code turned off the auto-increment. The MSX also was writing to VDP Port #3 and that was the final definitive clue.

 

What of value 0xAC? If we break it down to 0x80 + 2C, we see this is VDP Register 44 OR'd with the value to write the register. So you and Lee were again spot on. I did get confused thinking this was setting the inhibit bit, which was driving me crazy since the opposite worked for setting the commands a few routines earlier.

 

I have since modifed my test routine to inhibit auto-increment then write the data stream to port #3. Things are much easier to understand and a lot cleaner code-wise. And most importantly the character routine is now working properly

 

The recommended VDP status test is missing from the routine so I may need to revisit that. Who knows, the V9938 may be fast enough to outperform the Geneve.

 

I'll see about posting some code when I clean up my mess.

 

Whew.

[+Ksarul]

Ack! The first site appears to be offline from here. . .I hope someone has a downloaded copy of the manual, just in case it doesn't reappear.

 

I tried again this morning and it downloaded promptly (it took about 10 seconds). Thanks for the link!

Edited November 10, 2013 by Ksarul

[eck]

Hello, Mr. InsaneMultitasker!

 

You might quiet catch this, but the VR23 provides no scrolling with the V9938. We can alter the starting position of the screen-top. Don't ask me if this has any use. The V9958 has a scrolling register, but I have no idea how to use it, if I would own one. I can not follow the description in the manual. For scrolling purposes the YMMM might be the best command with the V9938. I did not test this, yet. To speed things up in your program take a look at the HMMM command. A full blown 6*8 character set needs a space of >1800 bytes in the VRAM. I post a not so useful code which is working with the EVPC from the SNUG. The program does not do much, but it might be worth a short look.

       DEF ST
ST     LWPI >B000
       CLR  9
       LI   13,>9100
       LI   14,>8C02
       LI   15,>8C06
       MOVB @G6+1,@>83D4
       MOVB 9,*14
       BL   @UNTERP
       DATA G6,12
       MOVB @R36,*14
       BL   @UNTERP
       DATA LO,11
       BL   @TSR2
       MOVB @R36,*14
       BL   @UNTERP
       DATA HMMCA,11
       LI   0,ASCA
SCHR3  BL   @TR2
       COC  @MASK,9
       JNE  FERTI
HALT3  BL   @TR2
       COC  @MA,9
       JNE  HALT3
       MOVB *0+,*14
       MOVB @R44,*14
       JMP  SCHR3
FERTI  LI   12,>1400
FERTIG MOVB *1,*14     Statusregister 0
       MOVB @R15,*14    zur Sicherheit
       MOVB @>8802,0       lesen
       MOVB 1,@>8374
       MOVB 1,@>837C
TASTE  BLWP @>2108     E/A KSCAN
       MOVB @>837C,1
       JEQ  TASTE
       CLR  2
       MOVB @>8375,2
       SRL  2,5        KEYSCAN *8
       AI   2,>40E2    ASCII 0 des ROM-Zeichensatzes der EVPC für T2-Mode
       LI   3,HMMC2+8  zu manipulierende Adresse
       MOVB @LO,*3     Adresse erst einmal löschen
       CLR  4
       LI   5,2        zwei Bit für ein Byte
       LI   6,3        mal 3-1+1 (2*3=6*8 Zeichen)
       SBO  0          ROM einschalten
WIEDER SLA  4,1
       JOC  AN         ist ein Pixel an?
       LI   7,HINTER-1 nein, also Hintergrundnibble vorbereiten
       A    5,7        Nibble +1 oder 2
       AB   *7,*3      Nibble landet auf HMMC2+8
       DEC  5          SCHON 2*?
       JNE  WIEDER     nö
       JMP  ERLEDI     ja
AN     LI   7,VORDER-1 bekannte Prozedur für ein gesetztes Pixel
       A    5,7
       AB   *7,*3
       DEC  5
       JNE  WIEDER
ERLEDI BL   @TSR2      ist an dieser Stelle sicher überflüssig
       MOVB @R36,*14   HMMC+8 ist jetzt einsatzbereit
       BL   @UNTERP
       DATA HMMC2,11
ERNEUT DEC  6          Vorabzug, daher 3-1*+1
       JEQ  NEUER      3*2 schon abgearbeitet?
       INCT 5          nein, also 5 wieder auf zwei setzen
       CLR  3
WIEDE2 SLA  4,1        Bits testen für die folgenden Datenbytes
       JOC  AN2
       LI   7,HINTER-1
       A    5,7
       AB   *7,3
       DEC  5
       JNE  WIEDE2
       JMP  ERLED2
AN2    LI   7,VORDER-1
       A    5,7
       AB   *7,3
       DEC  5
       JNE  WIEDE2
ERLED2 BL   @TR2       wichtig an dieser Stelle
       COC  @MASK,9
       JNE  SCHLUS     ist HMMC2 fertig?
HALT2  BL   @TR2       nein, aber dies hier ist vielleicht auch überflüssig?
       COC  @MA,9
       JNE  HALT2
       MOVB 3,*14      das Colorregister mit Daten füttern
       MOVB @R44,*14
       JMP  ERNEUT
NEUER  SBO  0
       MOVB *2+,4      weiteres Byte aus dem ROM holen
       SBZ  0
       LI   6,4        drei Durchläufe, dank Vorabzugs +1
       JMP  ERNEUT     noch 'ne Runde
SCHLUS B    @FERTIG    endloses Programm, bereit für neuen Tastendruck
*ENDE  MOVB @G1,+1,@>83D4
*      MOVB @G1,*14
*      BL   @UNTERP
*      DATA G1,12
*      B    @>0000
UNTERP MOVB 13,*14     Videoregister 10010001 17 vorlegen
       MOV  *11+,0
       MOV  *11+,1     DATA Werte abholen
UNTER1 MOVB *0+,15     Daten in Port 3 unterbringen
       DEC  1
       JNE  UNTER1     alle geschrieben?
       B    *11        Ja, dann geht es zurück
TSR2   MOVB @SR2,*14
       MOVB @R15,*14
       MOVB @>8802,9
       COC  @MASK,9
       JEQ  TSR2
       B    *11
TR2    MOVB @SR2,*14
       MOVB @R15,*14
       MOVB @>8802,9
       B    *11
MASK   DATA >0100     der Befehl ist noch am ackern
MA     DATA >8000     der VDP ist noch beschäftigt
G6     DATA >0A62,>3F00,>00F7,>3E07,>0A82,>0003
G1     DATA >00E0,>0020,>0006,>0007,>0802,>0000
LO     DATA >0000,>0001,>0002,>D400,>FF00,>C0A6   sichtbaren Bereich mit Weiß füllen
R38    EQU  LO+11
LI     DATA >0000,>0001,>0002,>0000,>0900,>70AC   ist aus dem Programm geflogen
LIX    EQU  LI+10
R44    EQU  LI+11
R46    BYTE >AE
R36    BYTE >24
SR2    BYTE 2
R15    BYTE >8F
RS     DATA >018E,>007A      wird hier nicht mehr gebraucht
HMMC2  DATA >0000,>0001,>0600,>0800,>FF00,>F000
VORDER DATA >0110        Schwarz
HINTER DATA >0000        Transparent
HMMCA  DATA >0700,>0001,>0600,>0800,>0000,>F000 aus 06 wird 3
ASCA   DATA >0000,>0011,>1001,>0001,>0100,>0101,>1111
       DATA >0100,>0101,>0001,>0100,>1000
       END

[+InsaneMultitasker]

I will definitely take a look at this! Thank you!!

 

My code isn't written very well but I have created some 'test' code which uses VR#23 to set the new screen position and perform a scroll as follows:

 

1. Write a new line of pixels "off screen"

2. During the next VDP interrupt, adjust VR#23 with a new offset so that the top line is no longer visible, and the new line becomes visible.

 

Some additional logic is required once you hit the last row in memory, meaning instead of writing a new line to the last row, you must return to row 0.

 

In this manner, a scroll seems possible in the bitmap V9938 graphics modes! I have not had much time to see how practical this will be for real-time use.

[eck]

Huh!

 

That confuses me like the V9958 manual. Lets say, if you wrap around the top line of the screen to the bottom of the non visible screen ( i. e. from 0 or what value is the top line number to 255) than the VRAM content after the last visible line 192+1 or 212+1 should not become part of the visible screen. I am talking about the V9938 - with the V9958 there is a way - or I misunderstand the manual of the V9938 at this point. It would be nice if it works like you were telling me.

[+InsaneMultitasker]

Huh!

 

That confuses me like the V9958 manual. Lets say, if you wrap around the top line of the screen to the bottom of the non visible screen ( i. e. from 0 or what value is the top line number to 255) than the VRAM content after the last visible line 192+1 or 212+1 should not become part of the visible screen. I am talking about the V9938 - with the V9958 there is a way - or I misunderstand the manual of the V9938 at this point. It would be nice if it works like you were telling me.

Hehehheh

I have looked at this many times over many years and only recently better understood the poor 9938 manual.

 

My test program is incomplete, so let me share a portion of the 9938 manual which helped me reconsider the scrolling possibility. From the 9938 MSX manual, page 55, emphasis mine:

 

2. Page Concept

The parameters used for the MSX-VIDEO are all x-y coordinates. In

other words, the internal command processor of the MSX-VIDEO accesses

the entire VRAN area as x-y coordinates of the display mode.

When a screen is to be displayed, 212 lines of the same page are

displayed (selected by R#23). To select the page to be displayed, use

R#2.

When a command is being executed, the contents of the display screen

are ignored.

The display modes and their relationships to the coordinates are shown

in the table below.

 

This appears to contradict the R#23 explanation on page 7, register functions. I suspect it refers only to graphics modes which do NOT operate in a page coordinate fashion, namely text 1/2 and the lower res. graphics modes. When I tried to use R#23 long ago, I wanted to use it in my PORT terminal emulator. In Text II mode I had no luck and gave up on the idea.

 

However... finally understanding that certain commands are primarily for graphics modes, namely 4,5,6,7, and knowing that they operate in dot/coordinate fashion, we can test R#23 again. If we set R23 to begin displaying at row 11, the VDP should display 212 rows starting at 11. I have already tested the wraparound and it appears to work as expected. Instead of an "undisplayed" area, we see 212 contiguous rows.

 

I will try to produce some test code this weekend.

[RXB]

Wish I could post a video of the 9938/9958 vs 9918 vs F18

 

T9938/9958 would clearly win hands down!

 

More pixel per screen more color per pixel and more modes to do half modes. (Not to mention the 128K of VRAM)

[RXB]

Wish I could post a video of the 9938/9958 vs 9918 vs F18

T9938/9958 would clearly win hands down!

More pixel per screen more color per pixel and more modes to do half modes. (Not to mention the 128K of VRAM)

[RXB]

The Atari Page told me my Posts was empty so I posted again????

[+InsaneMultitasker]

 

Wish I could post a video of the 9938/9958 vs 9918 vs F18

T9938/9958 would clearly win hands down!

More pixel per screen more color per pixel and more modes to do half modes. (Not to mention the 128K of VRAM)

 

I'm no V9938 expert, but none of what I have read so far indicates more split modes. There is an ability to change modes during the scan based on testing various interrupt and status bits, though it would require some fancy footwork to accomplish.

 

Do we really need to keep comparing the 9938 to the 9918 and the F18A?

[Willsy]

 

F18A != 9938

[eck]

Mister ... Multitasker, hello!

You are right, I have the picture on page 7 in my mind regarding the VR23. I am using code from Alexander Hulpke which sets the VDP-Write-Adress that allows you to poke into the whole VRAM plus expansion RAM. His code was published in a german user magazin. There he mentioned his trouble having with the VRAM usage "below" the grafic modes G4 to G7. I have had this trouble too, because my program failed in seting all these promissed video pages in G1 mode. In his article I read the explanation: from G1 to G3 and in both text modes every fourth byte is used in the 64K VRAM of the MSX2 video-chip. One used byte, three unused bytes and so forth. I think this is the reason why the VR23 can not handle the text mode scrolling properly. I spotted a hint from Tursi here in the forum wich might change that behavior of the standart modes of the TMS9918 plus Text2 mode. Though, I did not tried it out yet.Here is an other point: I changed my posted code above to display 255 characters found in the ROM of the EVPC-Card. Well, all that heavy bits and byte crunching, VDP-adress-changing slows it visible down. With a 6*8 charset there are 85 chars per row with 1*8 pixels spared. 3 rows à 85 chars totals to 255. ASCII 255 would become the first character on the fourth row. I have no idea which character size you are using for your terminal program. But for now I stoped thinking about an easy way to find the right x- and y-coordinates to use them with the HMMM command with the character setup my program has produced. If you are thinking about "proportional Schrift (font)" then you are forced to use the LM.. commands with in the G4 to G6 modes. Wish you success.

[RXB]

Maybe someone can make a Video of Y.A.P.P. or XHI on the Geneve or a TI with a AVPC card and show that the F18 is just no contest for performance.

 

Yea the F18 has a nice display on VGA but performance wise it is no contest. That extra VRAM and graphics modes with 4 times more pixels is amazing.

[Asmusr]

Maybe someone can make a Video of Y.A.P.P. or XHI on the Geneve or a TI with a AVPC card and show that the F18 is just no contest for performance.

 

Yes it would be nice with some videos for those of us who have never seen a 9938/9958 in action.

[TheMole]

 

Yes it would be nice with some videos for those of us who have never seen a 9938/9958 in action.

 

It's not that hard to find videos of a 9938 in action, but they're all from the MSX2. But I have never seen anything except for the Geneve boot screen (in MESS) that actually ran on a TI alike platform. And it shouldn't be that difficult to find, since both MESS and ti994w support all graphics modes from the 9938. All it would take for someone like Rich to show off what the 9938 can do is simply install the software in one of those emulators and make a video...

 

Rich, is the software you are so nostalgic about available as disk images/cartridges on whtech?