eck Posted November 23, 2013 Share Posted November 23, 2013 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. Quote Link to comment Share on other sites More sharing options...
TheMole Posted November 23, 2013 Share Posted November 23, 2013 (edited) 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 November 23, 2013 by TheMole Quote Link to comment Share on other sites More sharing options...
JamesD Posted November 23, 2013 Share Posted November 23, 2013 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. 2 Quote Link to comment Share on other sites More sharing options...
TheMole Posted November 23, 2013 Share Posted November 23, 2013 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. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted November 23, 2013 Share Posted November 23, 2013 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. 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted November 23, 2013 Share Posted November 23, 2013 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. Quote Link to comment Share on other sites More sharing options...
eck Posted November 24, 2013 Share Posted November 24, 2013 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 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted November 24, 2013 Share Posted November 24, 2013 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. Quote Link to comment Share on other sites More sharing options...
eck Posted November 24, 2013 Share Posted November 24, 2013 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. Quote Link to comment Share on other sites More sharing options...
TheMole Posted November 24, 2013 Share Posted November 24, 2013 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. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 24, 2013 Share Posted November 24, 2013 (edited) 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 November 24, 2013 by RXB Quote Link to comment Share on other sites More sharing options...
RXB Posted November 24, 2013 Share Posted November 24, 2013 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? Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted November 24, 2013 Share Posted November 24, 2013 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. Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted November 25, 2013 Author Share Posted November 25, 2013 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. Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted November 25, 2013 Share Posted November 25, 2013 (edited) Yark. Edited November 26, 2013 by sometimes99er Quote Link to comment Share on other sites More sharing options...
TheMole Posted November 25, 2013 Share Posted November 25, 2013 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. Quote Link to comment Share on other sites More sharing options...
JamesD Posted November 25, 2013 Share Posted November 25, 2013 (edited) 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.com/watch?v=QEl-SK0fw8wThis was written in BASIChttp://www.youtube.com/watch?v=z27a9tXlnz4 Edited November 25, 2013 by JamesD 1 Quote Link to comment Share on other sites More sharing options...
TheMole Posted November 25, 2013 Share Posted November 25, 2013 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.com/watch?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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted November 25, 2013 Share Posted November 25, 2013 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. 1 Quote Link to comment Share on other sites More sharing options...
Gazoo Posted November 25, 2013 Share Posted November 25, 2013 (edited) 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 HSGPLMENU.zip Edited November 25, 2013 by Gazoo 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 25, 2013 Share Posted November 25, 2013 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted November 26, 2013 Share Posted November 26, 2013 (edited) 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 November 26, 2013 by RXB Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted November 26, 2013 Share Posted November 26, 2013 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. 2 Quote Link to comment Share on other sites More sharing options...
TheMole Posted November 26, 2013 Share Posted November 26, 2013 (edited) 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 November 26, 2013 by TheMole Quote Link to comment Share on other sites More sharing options...
TheMole Posted November 26, 2013 Share Posted November 26, 2013 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 HSGPLMENU.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... 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.