Jump to content

Photo

9938/9958 Discussion Forum

9938 9958 Video

108 replies to this topic

#26 eck OFFLINE  

eck

    Space Invader

  • 44 posts

Posted Sat Nov 23, 2013 5:17 AM

Rich, please remember that the f18 runs at 100MHz while the V9938 runs on ~21MHz. Your V9958 TIM-board did a better job than mine V9938 card today. And do not forget that the TMS9900 is slower than the Z80 used on MSX computers. So the bigger VDP RAM can be a disadvantage depending on the things to do. I took Bruce Harisons shuffling routine - published in MICROPendium - to write a card game using G4 mode (32K VRAM). Harald Krafthöfer told me that the graphics were to small. He is right, but changing the program to G6 mode would more than double the amount of data used with the commands of the VDP. And the V9938 commands take their times, believe me.

 

But here is an other one: Does anybody knows the status of the Geneve2? I would give "him" a try.



#27 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 762 posts
  • Location:Belgium

Posted Sat Nov 23, 2013 6:08 AM

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.

 

I was actually intrigued by your statement about the 4 times more pixels, as I had been investigating potential software compatible successors to the 9918a myself a while back and I don't remember seeing anywhere that the v9938 or the v9958 have a resolution of 512x384. On wikipedia it says the max resolution of both chips is 512x212 or 108554 pixels. Now, this is about 2.2 times more than the tms9918a, not 4 times. Still a good bump in resolution though, so no complaints there.

 

Where it becomes interesting is when you start comparing to the F18A's highest resolution mode of 80 columns, 30 rows. This mode effectively gives you a resolution of 480 x 240 ( 80*6 x 30*8 ) or 115200 pixels. This is actually more than either the 9938 or the 9958. On top of that, the pixel ratio is much better since it's closer to the 4:3 ratio of the screen (the ratio on the 9938 is roughly 2.4, on the F18A it is 2, the target is to get as close to 1.333 as possible in order for the pixels to be square on the screen).

 

It is true that the v9938 has two interlaced modes that give the appearance of doubling the horizontal resolution, but that's nothing more than a parlour trick that degrades overall image quality and most people would find headache inducing. I'm not sure if any games ever made use one of these modes, and I'd be really surprised if graphics programs/editors would've for anything except for looking at static pictures. In my mind, this is comparable to the flicker trick that Tursi shows in his image viewer: a nice novelty that works relatively well on old display devices, but it doesn't actually increase the number of colors the 9918a can display.

 

If you want to extend the comparison to other features, not only is the GPU in the F18A clocked at a speed that is 5x higher than the v9938 as Eck indicates above, it's also a general purpose processing unit, while the v9938 has a fixed function processing unit. This means that the F18A can not only do all the things the v9938 can, but can be extended by the game developer to do so much more, such as 3D calculations, game AI, real time decompression of level data, etc...

 

So while I do agree that the extended VRAM in the v99x8's is cool, I tend to believe that for a system like the TI it won't actually give you enough of a benefit to warrant the higher FPGA cost (or cost of external static RAM) that it would have taken for Matthew to include the 128k or 192k in his design. The Sega Master System, considered to have the more graphically impressive games compared to its peers, also had only 16K video RAM. And yet, somehow not even the MSX2 with more RAM and the v9938 has a game library with the same quality of games.


Edited by TheMole, Sat Nov 23, 2013 10:26 AM.


#28 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,853 posts
  • Location:Flyover State

Posted Sat Nov 23, 2013 9:25 AM

Having more VRAM would actually benefit the TI a lot. You can preload more data into the VRAM to have it displayed on screen without delays from the slow CPU during gameplay.

#29 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 762 posts
  • Location:Belgium

Posted Sat Nov 23, 2013 10:23 AM

Having more VRAM would actually benefit the TI a lot. You can preload more data into the VRAM to have it displayed on screen without delays from the slow CPU during gameplay.

 

That's certainly true, and I didn't mean to say that more VRAM isn't a good thing to have. It's just not the most important thing, imho.

 

It's worth considering that the amount of data that you need to transfer to the VDP during gameplay per frame is relatively limited in all but the scariest cases. For scrolling on a single page you need to transfer between 3 and 4 bytes every frame. Hardly "overkill" for the system. Now, if you need to upload a whole bunch of new tile patterns, that can indeed become a significant challenge. But even the genesis has only 64kb of VRAM (and again a very similar VDP architecture based on the original tms9918a design), and I'm not asking for Genesis quality games on the TI. I'd be plenty happy with more NES/SMS level games first.



#30 InsaneMultitasker OFFLINE  

InsaneMultitasker

    Stargunner

  • 1,742 posts

Posted Sat Nov 23, 2013 1:00 PM

 

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.

 

I recall reading a similar article regarding the VRAM limitation. 

 

Do you happen to have your modified source in a format I can use with TIDIR such as a .DSK or TIFILES file?    Also, I was wondering if you would be able to translate a few of the comments to English?  I understand much of the code but not all of it.  :grin:  

 

I am using 6x8 characters and presently the Geneve routines use the LM.. command to paint one dot at a time.  The character is drawn by creating a rectangle 6x8 then writing 48 dots in series.  From the 8-byte character definition, for any bit set (1) the foreground color is written and any bit set (0) the background color is written.  I have been trying to come up with a way to pre-process the characters but a solution has eluded me.



#31 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Sat Nov 23, 2013 5:57 PM

 

That's certainly true, and I didn't mean to say that more VRAM isn't a good thing to have. It's just not the most important thing, imho.

 

It's worth considering that the amount of data that you need to transfer to the VDP during gameplay per frame is relatively limited in all but the scariest cases. For scrolling on a single page you need to transfer between 3 and 4 bytes every frame. Hardly "overkill" for the system. Now, if you need to upload a whole bunch of new tile patterns, that can indeed become a significant challenge. But even the genesis has only 64kb of VRAM (and again a very similar VDP architecture based on the original tms9918a design), and I'm not asking for Genesis quality games on the TI. I'd be plenty happy with more NES/SMS level games first.

Number of Pixels is very important as the less you have the more crappy the display looks and the more blocky it gets.

VRAM allows more pixels. Who cares if you have more pixels but not enough space to load anything on the TI?

This is the major issue the 9938/9958 have as a advantage also you can NEVER MAKE a version of Y.A.P,P. or XHI (XB version of TML) on the F18 as where the hell would you store and run it from?

 

The 9938/9958 are much older chips but had hardware registers for transfer of VRAM to RAM or RAM to VRAM.

Show me a single program on the F18 software to touch those programs please.

The only possible way is to use the SAMS and you have to use RAM to pull that off so gunna be a huge program.



#32 eck OFFLINE  

eck

    Space Invader

  • 44 posts

Posted Sat Nov 23, 2013 6:29 PM

Sorry, but I am not able to transfer data between my TI and my Pc other than with .hfe-files. They are containers used by the HxC Floppy Emulator. Maybe someone with a HxC and the ability to transfer the data to a Pc might help us? I can convert .dsk-files on a Pc, safe them on a SD-card and use them with my Corcomp controller. But the other way round did not work for me in the past. Looks like an one-way solution. I am in the same situation as Owen. My system fails from time to time. I have to learn how to use Mess then the data-transfer problem would no longer exist. Sometimes ...

 

You are writing that the Geneve routine writes a rectangle (space?) and then writing 48 dots in series? Even(?) if someone uses the LM.. commands to print data to the screen, setting the right logical bit(s), makes a space write redundant, this is my thinking - feeling (we have to proof my feelings). They are great commands to generate colorful software sprites of any size. Please be patient with the routine to pre-process the characters. I have my handwritings in front of me with the thoughts to program it, but they are hard to understand, even for the author himself.

 

I hope that my denglish won't hurt you to much. Here is my translation attempt:

      DEF ST
ST     LWPI >B000                Workspace setting for debugging purposes - bad style
       CLR  9                    the hi-byte of register 9 will be used to check status bits from SR2 of                                 the MSX video chip 
       LI   13,>9100             fixed register hi-byte contains VR17 for VWTR purposes
       LI   14,>8C02             fixed register with port 1
       LI   15,>8C06             fixed register with port 3
       MOVB @G6+1,@>83D4         copy of VR1 for the time out routine of the TI99/4A
       MOVB 9,*14                at the moment R9 is cleared so the routine to write VDP registers will
*                                start with VR0
       BL   @UNTERP              this routine uses R0, R1, R11, R13, R14 and R15        
       DATA G6,12                12 video registers to write preset data - use your own routine here 
       MOVB @R36,*14             using the same routine but transfer data to                            *                                11 consecutive command registers
       BL   @UNTERP
       DATA LO,11                preset data to clear the visible screen area                           *                                - change the color register to your own preferences VR44 set with >FF
       BL   @TSR2                this subprogram checks if the command is done and than will return 
       MOVB @R36,*14      *      here you find code which should help me to track down the errors I made
       BL   @UNTERP       *      skip this
       DATA HMMCA,11      *      displays a pre calculated A 6*8 black (1) and transparent (0)
       LI   0,ASCA        *      recycles R0 to point to the pre calculated char definition
SCHR3  BL   @TR2          *      a different version of the @TSR2 sub program - checking R9 inside the
                          *      main program
       COC  @MASK,9       *      important check here while testing the end of the command
       JNE  FERTI         *      if the bit found in @MASK is reset in R9 representing SR2 then we are                            *      done
HALT3  BL   @TR2          *      this is the flowchart I found in the manual, so the VDP might be fast                            *      enough to skip this bit checking - I never tried this without it
       COC  @MA,9         *      check the bit if the VDP is busy or not
       JNE  HALT3         *      busy here jump to hold on3 wait
       MOVB *0+,*14       *      ready to pump the data R0 is pointing to to port 1
       MOVB @R44,*14      *      direct these data to VR44 to make the command work 
       JMP  SCHR3         *      go to check, if the command is done
FERTI  LI   12,>1400      *      setting R12 with the cru of my video-card - obsolete on a geneve
FERTIG MOVB 1,*14         *      writing my card game I noticed that is not a bad practice to read SR2                            *      from time to time - I think you can skip these too
       MOVB @R15,*14      *      starting a read of SR0 R1 is 0 at this time
       MOVB @>8802,0      *      do the read and forget the thing
       MOVB 1,@>8374             prepare the TI for a key scan
       MOVB 1,@>837C             GPL status cleared
TASTE  BLWP @>2108               E/A KSCAN
       MOVB @>837C,1             is any key pressed?
       JEQ  TASTE                no go to TASTE
       CLR  2                    prepare R2
       MOVB @>8375,2             move the ascii code in hi-byte of R2
       SRL  2,5                  while the value is in the hi-byte, a right shift by 5 equals to *8
       AI   2,>40E2              bad practice to use the absolute address here but with your Geneve you *                                have to use here a ram, rom address with the character definition you  *                                want to start with: CALL CHAR(30,"0078787878787878") you get the       *                                picture. I am using the null character as the starting point. The key  *                                value times 8 gives us the position of the ascii based on our ram, rom *                                starting position. 
       LI   3,HMMC2+8            we want to use the HMMC command and the label contains the needed data *                                to write a 6*8 char. x position 0 and y position 256 are preset        *                                (second page first visible area). We have to manipulate the byte at    *                                HMMC2+8 with the first byte of the selected character. Remember that   *                                this is forced by the way I used to set up the commands of the VDP
       MOVB @LO,*3               get rid of an old entry at HMMC+8; I think you can skip this 
       CLR  4                    preparing R4
       LI   5,2                  two bits of the old charset will be used for one byte
       LI   6,3                  3 pairs are used for a 6 pixel wide char but during the command setup  *                                I have to strip one (3-1) but the position of the DEC 6 makes an extra *                                count, so we are again with LI 6,3  
       SBO  0            *       strip this on the Geneve
       MOVB *2+,4                VERDAMMT I forget to copy this, so this is the point you might stumble *                                over. Copies the first byte of our character to write in the HMMC+8    *                                position.
       SBZ  1            *       related to source of my TI data. see SBO 0
WIEDER SLA  4,1          here we go to check our bits
       JOC  AN           is a bit shifted out then a pixel is set within the character definition. Go to*                        label AN 
       LI   7,HINTER-1   no pixel is set, so HINTER-1 prepares the color to be set if the bit is 0.     *                        Remember our R5 starts with 2 decreases to one and than the loop is over.
       A    5,7          our color code is build by two nibbles in a reversed order. I have preset the  *                        values to >00 00. The first nibble contains the color of the second shifted bit
       AB   *7,*3        one of the preset data is put into HMMC2+8
       DEC  5            did we handle 2 bits yet?
       JNE  WIEDER       no, do it again
       JMP  ERLEDI       yes, see what is next
AN     LI   7,VORDER-1   if the sla jocs us here
       A    5,7          find the preset color nibble
       AB   *7,*3        add it to HMMC2+8
       DEC  5
       JNE  WIEDER
ERLEDI BL   @TSR2      * check, if the VDP is ready. I think you can skip this here.                    *                        But this is the save way.
       MOVB @R36,*14     we can now start our HMMC command.HMMC+8 is ready
       BL   @UNTERP
       DATA HMMC2,11
ERNEUT DEC  6            here I am one ahead. But we load R6 with 3 and we have no to worry
       JEQ  NEUER        did we expand every 6 bits?
       INCT 5            no, R5 equals to 0 but we need it to have 2 in it.
       CLR  3            R3 gets a new task
WIEDE2 SLA  4,1          this is the same routine as above, but now VR44 will get its bytes.
       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       this is important here
       COC  @MASK,9
       JNE  SCHLUS     we are checking, if the command is over? Yes, go to SCHLUS
HALT2  BL   @TR2       no, but you might skip this for faster execution.
       COC  @MA,9      see the flow chart in the manual
       JNE  HALT2      of the HMMC command
       MOVB 3,*14      we are writing our bit crushing to port 1
       MOVB @R44,*14   and directing it to VR44 - color register
       JMP  ERNEUT     go and check the content of R6
NEUER  SBO  0          skip this
       MOVB *2+,4      R2 must point to your character definition
       SBZ  0          skip this
       LI   6,4        when the setting of HMMC+8 is done and the 4 remaining bits are processed than   *                      we have to work on 3*2 bits. Due to the position of the DEC 6 the 3 is           *                      incremented to 4
       JMP  ERNEUT     do it again, Sam
SCHLUS B    @FERTIG    here starts the logic to write all chars into the VRAM you need.
*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 the command is being executed 
MA     DATA >8000     der VDP ist noch beschäftigt VDP is busy
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 not used anymore 
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 not used here artefact
HMMC2  DATA >0000,>0001,>0600,>0800,>FF00,>F000
VORDER DATA >0110        Schwarz color code black 
HINTER DATA >0000        Transparent 
HMMCA  DATA >0700,>0001,>0600,>0800,>0000,>F000 aus 06 wird 3 means there are only 3 bytes involved
ASCA   DATA >0000,>0011,>1001,>0001,>0100,>0101,>1111
       DATA >0100,>0101,>0001,>0100,>1000
       END 


#33 InsaneMultitasker OFFLINE  

InsaneMultitasker

    Stargunner

  • 1,742 posts

Posted Sat Nov 23, 2013 7:33 PM

 

Sorry, but I am not able to transfer data between my TI and my Pc other than with .hfe-files. They are containers used by the HxC Floppy Emulator. Maybe someone with a HxC and the ability to transfer the data to a Pc might help us? I can convert .dsk-files on a Pc, safe them on a SD-card and use them with my Corcomp controller. But the other way round did not work for me in the past. Looks like an one-way solution. I am in the same situation as Owen. My system fails from time to time. I have to learn how to use Mess then the data-transfer problem would no longer exist. Sometimes ...

 

You are writing that the Geneve routine writes a rectangle (space?) and then writing 48 dots in series? Even(?) if someone uses the LM.. commands to print data to the screen, setting the right logical bit(s), makes a space write redundant, this is my thinking - feeling (we have to proof my feelings). They are great commands to generate colorful software sprites of any size. Please be patient with the routine to pre-process the characters. I have my handwritings in front of me with the thoughts to program it, but they are hard to understand, even for the author himself.

 

I hope that my denglish won't hurt you to much. Here is my translation attempt:

 

 

Your comments are translated very well, thank you!    I did not understand why you were using R12 and CRU operations, because I have never used that hardware.   Most interesting!   There is very little I need to change to test this on the Geneve.  I am fairly certain VDP port#3 shows up in the same location on both computers.  In the native Geneve mode, the video ports are in the 0xF000 block, but still recognizable. 

 

Next, my rectangle explanation was written hastily.   When you set up the H... and L... commands, you must specify parameters for the command.  I am not writing a rectangle, I am setting up the LM.. command to paint within the coordinates of a 6 pixel x 8 pixel rectangle.  The LM.. command operates only on one dot/pixel per byte sent to the VDP, which requires us to write 48 bytes.  The Hxxx commands can send more than one dot/pixel per byte, depending on the graphics mode.   It took me a long time to realize the difference. 

 

I use Fred's and Michael's programs to copy files between images.  I use my Geneve, a UDS-10 device, and terminal emulator to transfer files to and from the PC.  Perhaps that is an option for you? 

 

I just remembered that I can copy your source code to a text file, then send the file ASCII to my Geneve over the 'modem', and use the buffer capture to turn it into source code :)   I will do that tonight while I am working on my test program. 



#34 eck OFFLINE  

eck

    Space Invader

  • 44 posts

Posted Sun Nov 24, 2013 6:48 AM

Hello!

 

My pcs did not have serial ports. I have to look, what a UDS-10 device is, to verify this option. I downloaded a pdf how the data on a .hfe-file is stored, but I did not understand a single word. Using Mess, saving on a pc99 disks, converting them to .hfe-files swapping SD-cards would not be the worst solution, I am thinking.

 

Anyhow, I did not understand the cru magic myself. Simon Koppelmann's TMS 9900 Assembler book helped me. I searched the rom of the EVPC for the character definitions with a hex monitor program. I am using the absolute address, but it would be better using a look up table to get the address inside the rom. Any existing dsr rom could be enabled in the manner LI R12,>1x00, Set cru Bit to One on position >1x00/2 (+ operand 0 is reading SBO  0) and you can use the data stored at >4xxx. So with your Geneve follow my advise and use a ram or rom destination inside your system. Do not use this cru "Hokuspokus".

 

Study your Geneve code to find the right address for port 3. Look were the "R17"  data >91 is used to write data into other VDP registers. The code in the example above is not right. Change it to: UNTER1 MOVB *0+,*15.

 

One reminder concerning my code when we are using commands: the number of bytes in consecutive order written to port 3 are X-1. The missing byte hides in the setup for the used command. That is the reason why I have to do things twice in a slightly different way. Maybe someone provides us a better solution to this problem?

 

I think my printer cable is defect. Printing Hallo results in """"""""JCNNO.  So OCR is no option for the moment. I copied the following code right away from the CRT. So we both have to remember the errors I made in the previous posts:

       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
       
       LI   12,>1400   this is 99/4A specific - skip this 
       SBO  0          and this
       LI   2,>40E2    and adjust this to the first byte where your simple ASCII 0 definition starts
ASCII0 CLR  8          preparing R8
ASCII1 LI   3,HMMC3+8  using a new setup for the HMMC command
LOPO   MOVB @LO,*3     clearing the location indicated by R3. Don't ask me if this is necessary.
       CLR  4          set R4 to zero
       LI   5,2        in one go we are shifting two bits
       LI   6,3        times 3-1 (reason is the X-1 byte I was talking about above)+1 (the position of   *                      DEC  6 instruction takes the responsibility here) 
       MOVB *2+,4      copies the first byte of ASCII code in R4
WIEDER SLA  4,1
       JOC  AN         bit found?
       LI   7,HINTER-1 no, nibble for background color start position -1   
AUCHAN A    5,7        nibble +1 or 2 equals to @HINTER, @HINTER+1 or new @VORDER and @VORDER+1 in any   *                      combination
       AB   *7,*3      nibble gets added to HMMC3+8
       DEC  5          2 times?
       JNE  WIEDER     no
       JMP  ERLEDI     yes
AN     LI   7,VORDER-1 nibble for pixel color start position - 1
       JMP  AUCHAN     I changed this while I was copying the text. It saves the 
*       A    5,7       code
*       AB   *7,*3     here
*       DEC  5         but
*       JNE  WIEDER    the old "pasta code" runs faster on every bit that is set
ERLEDI BL   @TSR2      test, if the VDP is busy. This might be obsolete?
       MOVB @R36,*14   HMMC+8 holds the first byte needed for VR44
       BL   @UNTERP
       DATA HMMC3,11
ERNEUT DEC  6          is R6 zero
       JEQ  NEUER      than 3*2 bits are done?
       INCT 5          no, so set R5 for an other two bits to shift
       CLR  3          preparing R3
WIEDE2 SLA  4,1        see above but using R3 to get the data for VR44
       JOC  AN2
       LI   7,HINTER-1
AUCHA2 A    5,7
       AB   *7,3
       DEC  5
       JNE  WIEDE2
       JMP  ERLED2
AN2    LI   7,VORDER-1
       JMP  AUCHA2
*       A    5,7
*       AB   *7,3
*       DEC  5
*       JNE  WIEDE2
ERLED2 BL   @TR2       Important! Do not strip this.
       COC  @MASK,9
       JNE  SCHLUS     is HMMC3 done?
HALT2  BL   @TR2       no, go and check SR2
       COC  @MA,9      needs the VDP a pause? 
       JNE  HALT2      yes, than go to HALT2
       MOVB 3,*14      no, copy byte into port 1
       MOVB @R44,*14   assign it to the color register
       JMP  ERNEUT     go and see, if there is an other byte in the queue 
NEUER  MOVB *2+,4      fetch the next byte from your basic char set definition
       LI   6,4        again 3 +1
       JMP  ERNEUT     an other round
SCHLUS AI   8,>0006    add 6 to the x position represented in R8
       MOVB @>B011,@HMMC3 @>B011 equals to MyWorkspace+11 it is the low byte of R8
       MOVB 8,@HMMC3+1 the high order bit of the x position
       DEC  2          I have to adjust R2 here
       CI   8,510      check if the x position is lower than #510. 85 chars per line
       JL   LOPO       not done yet
       CI   2,>48E3    I have had a counter here loaded with 3. 3*85=255 (0 to 254)chars in three rows.  *                      My first thought was to add char 255 when the main loop is done. More pasta.      *                      So I come up with this solution. The >48E3 was a little bit trial and error.      *                      ASCII(255)*8+starting position of ASCII(0)+9. So, I didn't catch my logic for     *                      myself. The disadvantage to the former solution is, that the routine is filling   *                      the whole fourth line.
       JH   C255       Make sure that we are testing the >L bit to make this bulletproof 
       AB   @PLUS8,@HMMC3+2 skip to the next row
       CLR  HMMC3      start with x position zero
       JMP  ASCII0     return. The JH   C255 stops this routine
C255   SBZ  0          here comes your own stuff
ENDLOS JMP  ENDLOS     I am using my reset button here
*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
HMMC3  DATA >0000,>4001,>0600,>0800,>0000,>F000   This is your data pool. >4001 prints the chars on      *                                                 screen. To hide the chars alter this values (byte 1    *                                                 and 2) >01 indicates the second page I am using with   *                                                 G6 setup no sprites.
PLUS8  EQU  HMMC3+6
VORDER DATA >0110        Schwarz
HINTER DATA >0000        Transparent
       END

Well, I hope that I did not do any other copying errors.



#35 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 762 posts
  • Location:Belgium

Posted Sun Nov 24, 2013 11:20 AM

Number of Pixels is very important as the less you have the more crappy the display looks and the more blocky it gets.

VRAM allows more pixels. Who cares if you have more pixels but not enough space to load anything on the TI?

This is the major issue the 9938/9958 have as a advantage also you can NEVER MAKE a version of Y.A.P,P. or XHI (XB version of TML) on the F18 as where the hell would you store and run it from?

 

The 9938/9958 are much older chips but had hardware registers for transfer of VRAM to RAM or RAM to VRAM.

Show me a single program on the F18 software to touch those programs please.

The only possible way is to use the SAMS and you have to use RAM to pull that off so gunna be a huge program.

 

Did you read my other post as well? The F18A actually displays more pixels, I would still like to know where you get the "4 times more" figure from.

 

As for VRAM, like I said before: I'm not denying more VRAM gives more possibilities. But even the v9938 supports a configuration of only 16kb, and the only thing you lose is the two more colorful bitmap modes. But those aren't useful for games, only if you want to display a static colorful picture.

 

But just to make sure I understood your argument as well as I could, I hunted around a little bit to find disks for YAPP and XHI. It took me a while, but I did find them. Below you can see a video of the "HIRESDEMO" program that came with the XHI disk, made in MESS with the EVPC driver (so using a v9938). Frankly, I'm not impressed... all I see is a slightly more colorful version of what the @pesoft guys were able to do on the stock tms9918a. Be warned though, the video is a bit boring and I gave up after 18 minutes. You'll also see me go into the MESS tab menu to speed things up a bit by toggling the throttle, so on real iron this would've been even slower.

 

 

I also found YAPP, but in all honesty I couldn't figure out what to do with it without the manual. It loads, I get the main drawing screen (with one-colored sprite as a cursor, yuck...), but I can't figure out how to use it. Maybe you can give it a go and record a video? The .dsk files are linked here, and I can give you the MESS command line for the EVPC driver if you want.

 

ftp://ftp.nekochan.net/pub/sites/ftp.whtech.com/mess/disks/YAPP55.dsk

ftp://ftp.nekochan.net/pub/sites/ftp.whtech.com/mess/disks/XHI.dsk

 

Suffice it to say, I'm not impressed at all, XHI is dog-slow and YAPP looks like only half a step above TI Artist. Are there any other programs on the TI that use the v9938's features well? I know the chip is capable of much more looking at what the MSX guys have done with it, but I don't know if the TI ever used it for anything really cool.



#36 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Sun Nov 24, 2013 4:45 PM

Kinda hard to watch that Video as it is labeled PRIVATE so no one can watch it.

 

Like I said before show me F18 programs to compare please.

 

Otherwise you are pushing pure vaporware from your imagination and that is nutty to knock a real product in favor of a fiction in your mind only.


Edited by RXB, Sun Nov 24, 2013 4:45 PM.


#37 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Sun Nov 24, 2013 4:50 PM

 

Your comments are translated very well, thank you!    I did not understand why you were using R12 and CRU operations, because I have never used that hardware.   Most interesting!   There is very little I need to change to test this on the Geneve.  I am fairly certain VDP port#3 shows up in the same location on both computers.  In the native Geneve mode, the video ports are in the 0xF000 block, but still recognizable. 

 

Next, my rectangle explanation was written hastily.   When you set up the H... and L... commands, you must specify parameters for the command.  I am not writing a rectangle, I am setting up the LM.. command to paint within the coordinates of a 6 pixel x 8 pixel rectangle.  The LM.. command operates only on one dot/pixel per byte sent to the VDP, which requires us to write 48 bytes.  The Hxxx commands can send more than one dot/pixel per byte, depending on the graphics mode.   It took me a long time to realize the difference. 

 

I use Fred's and Michael's programs to copy files between images.  I use my Geneve, a UDS-10 device, and terminal emulator to transfer files to and from the PC.  Perhaps that is an option for you? 

 

I just remembered that I can copy your source code to a text file, then send the file ASCII to my Geneve over the 'modem', and use the buffer capture to turn it into source code :)   I will do that tonight while I am working on my test program. 

 

The 9938 and 9958 both have built in blocks or wire frames or lines or rays or circles and I do not see these being used. Why?



#38 InsaneMultitasker OFFLINE  

InsaneMultitasker

    Stargunner

  • 1,742 posts

Posted Sun Nov 24, 2013 5:02 PM

 

The 9938 and 9958 both have built in blocks or wire frames or lines or rays or circles and I do not see these being used. Why?

 

The V9938 can execute "high speed" moves and fills based on coordinates, though they are limited to lines and rectangles and dots.  There is nothing built-in to draw wire frames or circles directly.  There are also no facilities to mimick a pattern table in the higher graphics modes, so one must plot the dots to create a character.  Even with the high-speed routines, the amount of data necessary to display a simple 6x8 character is 50x that of standard text mode.   Eck's code is using the built-in routines.  



#39 --- Ω --- OFFLINE  

--- Ω ---

    TI-Runner

  • Topic Starter
  • 10,690 posts

Posted Sun Nov 24, 2013 7:37 PM

Below you can see a video of the "HIRESDEMO" program...

 

 

 The video comes back as 'Private' and I'm unable to watch, even after logging in.



#40 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 3,985 posts
  • Location:Denmark

Posted Mon Nov 25, 2013 1:29 AM

Yark.

Edited by sometimes99er, Tue Nov 26, 2013 2:15 PM.


#41 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 762 posts
  • Location:Belgium

Posted Mon Nov 25, 2013 2:43 AM

Kinda hard to watch that Video as it is labeled PRIVATE so no one can watch it.

 

Like I said before show me F18 programs to compare please.

 

Otherwise you are pushing pure vaporware from your imagination and that is nutty to knock a real product in favor of a fiction in your mind only.

 

Apologies, the video was not meant to be private. Should be changed now, if you scroll up you should see the clip.

 

Don't get me wrong, Rich. I'm not trying to push the F18A on anyone and would not have made the comparison if you hadn't. I don't think the F18A is the best thing since sliced bread (I think the Master System VDP has a nicer programming model and stays closer to the tms9918a at the same time), nor do I think the v99x8 is a piece of crap. I'm genuinely interested in all upgraded VDP solutions out there and have been since before I learned of the F18A.

 

But looking at the examples you've given, I just don't see any of the super duper cool shit you've been talking about, so should I consider that vaporware as well? If you really want, I can point you to two videos that have been made by people on this forum that are freely available on youtube and show the F18A doing things that the v9938 is not able to do. I don't want to foul up a v99x8 thread by posting it full of F18A stuff, but if you insist I'll happily oblige.

 

But do me a favor, and spend some time setting up MESS with EVPC support (like I did), and make some videos that showcase things that you think are cool examples of Yamaha VDP gloriousness. It's not fair for you to blame me for not showing you F18A examples while you won't show me anything from the v9938/9958 either.



#42 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,853 posts
  • Location:Flyover State

Posted Mon Nov 25, 2013 3:41 PM

That demo looks horribly slow.  The text alone tells me they must not be using the video chip to render it.

 

All I know is there are some impressive MSX2 demos out there.  The music in this is horrible but it shows quite a few lines being updated per frame.
http://www.youtube.c...h?v=QEl-SK0fw8w


This was written in BASIC
http://www.youtube.c...h?v=z27a9tXlnz4


Edited by JamesD, Mon Nov 25, 2013 3:48 PM.


#43 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 762 posts
  • Location:Belgium

Posted Mon Nov 25, 2013 4:25 PM

All I know is there are some impressive MSX2 demos out there.  The music in this is horrible but it shows quite a few lines being updated per frame.

http://www.youtube.c...h?v=QEl-SK0fw8w

 

That's a good one. But yeah, definitely some cool MSX2 demos and games that show off some of the v9938 features, as I said, I'm not knocking the chip itself. It's just that I have never seen anything cool done with it on the TI. And I think there's two reasons for that: the TI crowd has always been of the more serious kind, much more into 80 columns than into games and such; but I think the second reason is that the design of the TI makes it incredibly difficult to pull stuff like that off. We have one third of the bandwidth to the VDP compared to the z80 guys and no matter how much VRAM you have these demos require you to push new data to the VDP at much higher rates than we can push from the TMS9900. None of these things are drawn using lines, patterns or block moves, so they're all being rendered by the CPU and more or less full frames pushed to the VDP.

 

Now, I'd love to see what people can get out of their TI's with 80 column cards in terms of graphics, so I'm eager to see more (and hopefully) better showcases of what the combination is worth. Just thought I'd kick things off since these videos seem to be rarer than hen's teeth... and I never had the pleasure of owning a vintage 80 columns card.



#44 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,609 posts
  • Location:Germany

Posted Mon Nov 25, 2013 5:22 PM

Does this count (I posted it half a year ago already)? It's running on the Geneve, though.

In my FRACTALS program I made use of several 9938 features:

- Clear screen with fill command
- Multicolored mouse pointer
- Graphics mode 6 (512x212)
- Definable color palette
- Zoom window is drawn with line command using XOR mode
- and mouse, of course.

Attached Files



#45 Gazoo OFFLINE  

Gazoo

    Stargunner

  • 1,507 posts
  • Location:Downingtown, PA

Posted Mon Nov 25, 2013 5:41 PM

TAKING ANOTHER TACK

 

Just jumping in with another reason to have the expanded Vram available - Programming.

Fire up Funnelweb configured for 80 columns and 128k buffer.

Load the file SOURCE from the disk image attached to this message. It's about 60k.

 

I like to be able to view the entire source of a program, rather than the time consuming process of loading shorter segments to find the part I'm looking for, and Funnelweb allows me to do this. Saves a lot of time for me and makes the process infinitely easier. If I had to go back to a 16k buffer I'd probably discontinue my programming efforts, too much of a hardship.

 

I'm sure there will be many jumping in to berate me for my opinions as this is the standard practice on this forum, but I've got big shoulders and can put up with that childish nonsense.

 

Gazoo

Attached File  HSGPLMENU.zip   271.38KB   6 downloads


Edited by Gazoo, Mon Nov 25, 2013 5:42 PM.


#46 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Mon Nov 25, 2013 5:49 PM

 

Apologies, the video was not meant to be private. Should be changed now, if you scroll up you should see the clip.

 

Don't get me wrong, Rich. I'm not trying to push the F18A on anyone and would not have made the comparison if you hadn't. I don't think the F18A is the best thing since sliced bread (I think the Master System VDP has a nicer programming model and stays closer to the tms9918a at the same time), nor do I think the v99x8 is a piece of crap. I'm genuinely interested in all upgraded VDP solutions out there and have been since before I learned of the F18A.

 

But looking at the examples you've given, I just don't see any of the super duper cool shit you've been talking about, so should I consider that vaporware as well? If you really want, I can point you to two videos that have been made by people on this forum that are freely available on youtube and show the F18A doing things that the v9938 is not able to do. I don't want to foul up a v99x8 thread by posting it full of F18A stuff, but if you insist I'll happily oblige.

 

But do me a favor, and spend some time setting up MESS with EVPC support (like I did), and make some videos that showcase things that you think are cool examples of Yamaha VDP gloriousness. It's not fair for you to blame me for not showing you F18A examples while you won't show me anything from the v9938/9958 either.

 

Ok I had a TIM card and X80 & XHI & Y.A.P.P. & 80 Column Funnel Web and they never looked that crappy. I have no clue why that Video is so slow and so crappy looking.

Some of the speed is spot on by XHI was never that slow or that crappy looking. I mean really slow and crappy looking. Something is really wrong with your set up on MESS.

 

I also used a alternate crystal mode in my TI99/4A with a switch to up the speed of the TI and put it in Turbo mode as long as I was not using the RS232 or timing critical programs like clocks.

The Turbo mode really made XB speed up a considerable amount using any programs.

 

As for VAPORWARE that is any software that does not exist but some one cites a example of how it could be faster on modern hardware compared to existing old hardware.

(Despite the new hardware does not have a single program that exists to do it!) VAPORWARE is musings with no evidence.

 

I would love to set up MESS but every attempt requires me to load something like Visual Studio which of course I do not have. Or load things that breaks other things.

Last attempt broke my BOOTCAMP drivers and made a mess that took me 3 days to fix.



#47 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Mon Nov 25, 2013 6:14 PM

 

The V9938 can execute "high speed" moves and fills based on coordinates, though they are limited to lines and rectangles and dots.  There is nothing built-in to draw wire frames or circles directly.  There are also no facilities to mimick a pattern table in the higher graphics modes, so one must plot the dots to create a character.  Even with the high-speed routines, the amount of data necessary to display a simple 6x8 character is 50x that of standard text mode.   Eck's code is using the built-in routines.  

 

 

Both the 9938/9958 have hardware built in xy to xy Line or Ray. Also for scrolling in any direction you have built in hardware move VRAM to VRAM or VRAM to CPU or CPU to VRAM.

As for your view that Text mode is slow in 80 column FW 80 Column was very very fast except for loading or saving. I could click through 200 pages in a few seconds.

 

Using a SCSI Hard drive and FW 80 Column I could load the entire GROM XB source in one file and save it. It was fantastic to use. 

 

And why the hell would you want to mimic GRAPHIC MODE in TEXT MODE? Talk about going backwards deliberately? Going from 8x8 to 6x8 on purpose?


Edited by RXB, Mon Nov 25, 2013 6:17 PM.


#48 InsaneMultitasker OFFLINE  

InsaneMultitasker

    Stargunner

  • 1,742 posts

Posted Mon Nov 25, 2013 8:31 PM

 

 

Both the 9938/9958 have hardware built in xy to xy Line or Ray. Also for scrolling in any direction you have built in hardware move VRAM to VRAM or VRAM to CPU or CPU to VRAM.

As for your view that Text mode is slow in 80 column FW 80 Column was very very fast except for loading or saving. I could click through 200 pages in a few seconds.

 

Using a SCSI Hard drive and FW 80 Column I could load the entire GROM XB source in one file and save it. It was fantastic to use. 

 

And why the hell would you want to mimic GRAPHIC MODE in TEXT MODE? Talk about going backwards deliberately? Going from 8x8 to 6x8 on purpose?

 

You are partially correct.  The hardware moves -can- be used for scrolling but have you actually implemented scrolls using the hardware? It isn't all that quick as the VDP works to pump 55,000 bytes more or less per full screen scroll.  I have used the hardware scrolls both for testing and in my own programs.

 

Secondly, I did not mean to infer TEXT II mode was slow.  We were talking in the context of the graphics modes, which in order to display text require you to emulate character patterns by plotting the dots.  It is only by plotting the characters that 16-color text display is possible, because the higher res modes do not operate on "characters".  As for the size, 6x8 characters are required to achieve 80 column character width.  An 8x8 character would only allow 64 characters per line. 

 

Anyway, perhaps a picture or two will clear things up.  Here are TWO screenshots taken from my -real- V9938 hardware, as installed in a real Geneve.  Here I am telnetted to heatwavebbs.com via my Geneve, connected to my UDS10 device, at 38.4K.  The monitor is my ol' faithful  Magnavox 8cm515 RGB analog.  The terminal emulator is PORT, programmed by me.  The BBS software on the other end is running on a Geneve, in Extended BASIC. 

Attached Files



#49 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 762 posts
  • Location:Belgium

Posted Tue Nov 26, 2013 3:00 AM

Does this count (I posted it half a year ago already)? It's running on the Geneve, though.

In my FRACTALS program I made use of several 9938 features:

- Clear screen with fill command
- Multicolored mouse pointer
- Graphics mode 6 (512x212)
- Definable color palette
- Zoom window is drawn with line command using XOR mode
- and mouse, of course.

 

Yeah saw it before, that's a pretty nifty example. I also know that there's at least one arcade style game for the Geneve, but the name is eluding me. Either way, showing off more Geneve stuff is great, except for some very basic fiddling in MESS I haven't had any opportunity to see what it can do.

 

Do you think this fractal program is something that could run on the TI as well? Slower obviously, but would it be possible? Also, how long does it take the Geneve to generate one screen?


Edited by TheMole, Tue Nov 26, 2013 3:07 AM.


#50 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 762 posts
  • Location:Belgium

Posted Tue Nov 26, 2013 3:33 AM

TAKING ANOTHER TACK

 

Just jumping in with another reason to have the expanded Vram available - Programming.

Fire up Funnelweb configured for 80 columns and 128k buffer.

Load the file SOURCE from the disk image attached to this message. It's about 60k.

 

I like to be able to view the entire source of a program, rather than the time consuming process of loading shorter segments to find the part I'm looking for, and Funnelweb allows me to do this. Saves a lot of time for me and makes the process infinitely easier. If I had to go back to a 16k buffer I'd probably discontinue my programming efforts, too much of a hardship.

 

Gazoo

attachicon.gifHSGPLMENU.zip

 

Yes, absolutely. FunnelWeb makes good use of the memory to achieve something that could otherwise not be done on a stock TI+32k.

 

But can the same thing not be achieved using the SAMS (or AMS) instead? Load the entire file in the SAMS and only push the visible pages to the VDP? Because like I said before, I'm not against more memory in the TI, but if I have to choose I would prefer it to be on the CPU bus instead of having to go through the VDP. If this type of thing would be possible, as a developer I would probably choose that route instead.

 

Curious why you thought you would get flack for posting this, seems like a perfectly good use case to me...







Also tagged with one or more of these keywords: 9938, 9958, Video

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users