gekido_ken Posted November 27, 2018 Share Posted November 27, 2018 (edited) Hi, I have a question for XB256. I know that the TMS9918 has 7 registers plus 1, and that register 1 is used to set the different text / graph modes. However I know that it is possible (as I do on MSX) to disable the video signal while the screen is drawn, and then reactivate it after the construction of the graphics. This is to prevent the visualization process of the on-screen graphics from appearing and showing everything only at the end of the process. With which address and command CALL LOAD is it possible to do the same? Thank you. Edited November 27, 2018 by gekido_ken Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted November 27, 2018 Share Posted November 27, 2018 (edited) Hi,I'm not familiar with the MSX, or XB. but the 9918, mmm a little. Maybe Register 1, Bit 1... Edited November 27, 2018 by HOME AUTOMATION Quote Link to comment Share on other sites More sharing options...
Stuart Posted November 27, 2018 Share Posted November 27, 2018 Register 1 bit 1 as message above … but you can't set that directly using a CALL LOAD. You'll need to write and load a small assembly program to set the register bit, and call that program through a CALL LOAD. (Although I now wonder if you can use CALL LOAD to set the screen timeout counter to blank the screen?) Quote Link to comment Share on other sites More sharing options...
RXB Posted November 28, 2018 Share Posted November 28, 2018 Or use RXB to do that it has CALL POKER(VDP register #,numeric variable) POKER subprogram PAGE P4 ------------------------------------------------------------- Format CALL POKER(vdp-number,numeric-variable[,...]) CALL POKER(numeric-variable,number[,...]) Description The POKER command writes to vdp register a byte value. Only registers 0 to 7 are valid. The byte value ranges 0 to 255. Programs This sets text mode. | >100 CALL POKER(7,244,1,240) This is a delay loop. | >110 FOR L=1 TO 500 :: NEXT L This sets multi color mode | >120 CALL POKER(1,232) This is a delay loop. | >130 FOR L=1 TO 500 :: NEXT L This sets bit map mode. | >140 CALL POKER(0,2,1,2) This is a delay loop. | >150 FOR L=1 TO 500 :: NEXT L This sets normal XB mode. | >160 CALL POKER(0,0) | Not released yet RXB next version has CALL VDPSTACK(address) to move the VDP stack location in VDP to where you want it. Not release yet is RXB next version has CALL PRAM(address) to move the RAM end address in RAM to where you want it. So in RXB you can customize XB to where everything is located. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted November 28, 2018 Share Posted November 28, 2018 (edited) Hi, I have a question for XB256. I know that the TMS9918 has 7 registers plus 1, and that register 1 is used to set the different text / graph modes. However I know that it is possible (as I do on MSX) to disable the video signal while the screen is drawn, and then reactivate it after the construction of the graphics. This is to prevent the visualization process of the on-screen graphics from appearing and showing everything only at the end of the process. With which address and command CALL LOAD is it possible to do the same? Thank you. With a little cleverness this can be done XB256. Here is the description of SCREEN in the XB256 manual: CALL LINK(“SCREEN”,color-code) (both screen1 and screen2) This can be used to change the background color in the current screen. This is identical to CALL SCREEN except the background colors of the screens are saved/restored when you switch screens. Here is the assembly code for SCREEN: SCREEN LWPI WKSP CLR R1 BL @GETNUM DATA 1 DATA 16 MOV @>834A,R0 AI R0,>070F REGISTER 7, foreground=black BLWP @VWTR (and a few omitted lines that save the screen color) The 1 and 16 are limit checks so the screen color is a valid number from 1 to 16. But with CALL LOAD(14864,128) you can defeat the lower limit check by making the 1 into >8001. Now with CALL LINK("SCREEN",-1391 you can set VDP R1 to >A0 which blanks the screen. (-1391 is >FA91. When you add >070F you get >01A0 which tells VWTR to write A0 to VR1) With -1327 you can set it back to the default >E0 to make the screen visible. If you wanted to totally disable both lower and upper limit checks, you can CALL LOAD(14864,128,0,127,255) and then any VDP register can be changed to any desired value - just remember that >070F will be added. If you will be compiling the program you don't need the CALL LOAD because the compiler does not do limit checks. Edited November 28, 2018 by senior_falcon 2 Quote Link to comment Share on other sites More sharing options...
gekido_ken Posted November 28, 2018 Author Share Posted November 28, 2018 The 1 and 16 are limit checks so the screen color is a valid number from 1 to 16. But with CALL LOAD(14864,128) you can defeat the lower limit check by making the 1 into >8001. Now with CALL LINK("SCREEN",-1391 you can set VDP R1 to >A0 which blanks the screen. (-1391 is >FA91. When you add >070F you get >01A0 which tells VWTR to write A0 to VR1) With -1327 you can set it back to the default >E0 to make the screen visible. If you wanted to totally disable both lower and upper limit checks, you can CALL LOAD(14864,128,0,127,255) and then any VDP register can be changed to any desired value - just remember that >070F will be added. If you will be compiling the program you don't need the CALL LOAD because the compiler does not do limit checks. Computer left message BAD VALUE Quote Link to comment Share on other sites More sharing options...
Tursi Posted November 28, 2018 Share Posted November 28, 2018 Computer left message BAD VALUE XB256 is an add-on suite you need to load. There's no way to do it with pure XB. The closest you can get is to set all color sets to transparent (CALL COLOR) then load the correct colors after your screen is ready. It's not quite instantaneous, but it's not bad. 1 Quote Link to comment Share on other sites More sharing options...
gekido_ken Posted November 28, 2018 Author Share Posted November 28, 2018 (edited) XB256 is an add-on suite you need to load. There's no way to do it with pure XB. The closest you can get is to set all color sets to transparent (CALL COLOR) then load the correct colors after your screen is ready. It's not quite instantaneous, but it's not bad. Infact I load and run XB256. I write my DATA routines for colorset, charset and mapscreen. But before the routine of drawscreen I insert this: REM DRAW MAP(S) 1420 CALL CLEAR 1423 CALL LOAD(14864,128) 1425 CALL LINK("SCREEN",-1391) 1430 RESTORE 900 1440 READ W,H,SC::CALL SCREEN(SC)::CALL CLEAR 1450 FOR Y=1 TO H 1460 FOR X=1 TO W 1470 READ CP::CALL VCHAR(Y,X,CP) 1480 NEXT X 1490 NEXT Y 1495 CALL LINK("SCREEN",-1327) 1500 CALL KEY(0,K,S)::IF S=0 THEN 1500 1510 END The error message il "BAD VALUE IN 1425" Where is the wrong? Edited November 28, 2018 by gekido_ken 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted November 29, 2018 Share Posted November 29, 2018 (edited) Infact I load and run XB256. I write my DATA routines for colorset, charset and mapscreen. But before the routine of drawscreen I insert this: REM DRAW MAP(S) 1420 CALL CLEAR 1423 CALL LOAD(14864,128) 1425 CALL LINK("SCREEN",-1391) *************** 1495 CALL LINK("SCREEN",-1327) The error message il "BAD VALUE IN 1425" Where is the wrong? This works for me. Make sure you are using the "Frappato" version. One drawback of using direct CALL LOADs to poke a value into a memory location is that revisions to the code can put it in a new location. This means the CALL LOAD is specific to a particular version and may need to be changed for different versions. Frappato can be found in "TI99/4A development resources" or in 99er.net under downloads. Edited November 29, 2018 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
LASooner Posted November 29, 2018 Share Posted November 29, 2018 Might I recommend the compressed data feature? It captures VDP data and reads it in so fast you don't even need to blank the screen 1 Quote Link to comment Share on other sites More sharing options...
Retrospect Posted November 29, 2018 Share Posted November 29, 2018 XB256 is an add-on suite you need to load. There's no way to do it with pure XB. The closest you can get is to set all color sets to transparent (CALL COLOR) then load the correct colors after your screen is ready. It's not quite instantaneous, but it's not bad. Yes, this is the trick I use sometimes and even with your code compiled, it still makes a visible difference (if you're looking for it) ... especially in the case of say "Eric In Monsterland" where sometimes the screens can be fairly graphics-heavy. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted November 29, 2018 Share Posted November 29, 2018 This brings up an interesting possibility for both XB256 and RXB. Normally CALL SCREEN expects a value from 1 to 16. Make that 0 to 16 and have a CALL SCREEN(0) that blanks the screen. CALL SCREEN(1 to 16) enables the screen and sets the screen color. It would be nice to save the sprite magnification and size. 7 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted November 29, 2018 Share Posted November 29, 2018 (Although I now wonder if you can use CALL LOAD to set the screen timeout counter to blank the screen?) I tried that, but it doesn't seem to work. Not sure why. Quote Link to comment Share on other sites More sharing options...
gekido_ken Posted November 29, 2018 Author Share Posted November 29, 2018 This works for me. Make sure you are using the "Frappato" version. One drawback of using direct CALL LOADs to poke a value into a memory location is that revisions to the code can put it in a new location. This means the CALL LOAD is specific to a particular version and may need to be changed for different versions. Frappato can be found in "TI99/4A development resources" or in 99er.net under downloads. OK THANKS!! I've downloaded "Frappato" version and it works!!!! 3 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 30, 2018 Share Posted November 30, 2018 (edited) This brings up an interesting possibility for both XB256 and RXB. Normally CALL SCREEN expects a value from 1 to 16. Make that 0 to 16 and have a CALL SCREEN(0) that blanks the screen. CALL SCREEN(1 to 16) enables the screen and sets the screen color. It would be nice to save the sprite magnification and size. Hmm just looked at code for XB and RXB both use 1 for Transparent in CALL COLOR and CALL SCREEN commands. The value of 1 is used in Decimal but there is no 16 in HEX (>F0) so every value is decremented thus when you put in 1 it is actually decremented to 0 by GPL GROM. That means XB and RXB both have 1 for Transparent (>00 in GPL) and 16 White (>0F in GPL). Edited November 30, 2018 by RXB Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted December 1, 2018 Share Posted December 1, 2018 Hmm just looked at code for XB and RXB both use 1 for Transparent in CALL COLOR and CALL SCREEN commands. The value of 1 is used in Decimal but there is no 16 in HEX (>F0) so every value is decremented thus when you put in 1 it is actually decremented to 0 by GPL GROM. That means XB and RXB both have 1 for Transparent (>00 in GPL) and 16 White (>0F in GPL). This is in the EA manual and is nothing new. What does it have to do with the proposed CALL SCREEN(0)? Quote Link to comment Share on other sites More sharing options...
RXB Posted December 1, 2018 Share Posted December 1, 2018 This is in the EA manual and is nothing new. What does it have to do with the proposed CALL SCREEN(0)? Is CALL SCREEN(0) supposed to be BLANK SCREEN or TURN SCREEN OFF or just CALL SCREEN(transparent) ?? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted December 1, 2018 Share Posted December 1, 2018 Is CALL SCREEN(0) supposed to be BLANK SCREEN or TURN SCREEN OFF or just CALL SCREEN(transparent) ?? What would the point be in having CALL SCREEN(0) do the same as CALL SCREEN(1)? What is this thread about? It's about how to blank the screen from XB. You do that by setting bit 1 of VR1 to 0. You make the screen visible again by setting that bit to 1. So.. CALL SCREEN(0) sets bit 1 to zero CALL SCREEN(1 to 16) sets bit one to 1 and sets the color as specified. It would be nice, though not essential, to keep the sprite magnification the same. Since you can't read VDP registers, you'd have to store the value for VR1 somewhere and then MAGNIFY would update both the register and also the stored value. Quote Link to comment Share on other sites More sharing options...
RXB Posted December 1, 2018 Share Posted December 1, 2018 What would the point be in having CALL SCREEN(0) do the same as CALL SCREEN(1)? What is this thread about? It's about how to blank the screen from XB. You do that by setting bit 1 of VR1 to 0. You make the screen visible again by setting that bit to 1. So.. CALL SCREEN(0) sets bit 1 to zero CALL SCREEN(1 to 16) sets bit one to 1 and sets the color as specified. It would be nice, though not essential, to keep the sprite magnification the same. Since you can't read VDP registers, you'd have to store the value for VR1 somewhere and then MAGNIFY would update both the register and also the stored value. Yea that would be better. And you can do that in RXB of course using a variable in XB for storage CALL VPOKER(register-variable,numeric-variable,numeric-variable) Would love a version of 256RXB... Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted December 1, 2018 Share Posted December 1, 2018 This brings up an interesting possibility ... Normally CALL SCREEN expects a value from 1 to 16. Make that 0 to 16 and have a CALL SCREEN(0) that blanks the screen. CALL SCREEN(1 to 16) enables the screen and sets the screen color ... Absolutely. Should have been like that in the original XB. Quote Link to comment Share on other sites More sharing options...
RXB Posted December 2, 2018 Share Posted December 2, 2018 Absolutely. Should have been like that in the original XB. Well that would mean a 1 of a kind routine as here is the GPL Code from TI Extended Basic: [2336] *********************************************************** [2337] * SUBROUTINE FOR 'RANGE' USED IN ALL SOUND AND GRAPHICS [2338] *********************************************************** [2339] ACA0 0F,7E RAN16 XML SPEED Insure in range [2340] ACA2 02 BYTE RANGE * of 1 to 16 [2341] ACA3 01 BYTE 1 [2342] ACA4 00,10 DATA 16 [2343] ACA6 92,4B DEC @FAC1 Adjust to internal range [2344] ACA8 00 RTN This subroutine is used by CALL COLOR, CALL SCREEN, CALL SOUND so like I said a special version would be needed for CALL SCREEN(0) Also a new routine would been needed for blanking the screen. Thus what use would this be? I mean a CALL CLEAR is normally used in XB for this effect? Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted December 2, 2018 Share Posted December 2, 2018 Well that would mean a 1 of a kind routine as here is the GPL Code from TI Extended Basic: [2336] *********************************************************** [2337] * SUBROUTINE FOR 'RANGE' USED IN ALL SOUND AND GRAPHICS [2338] *********************************************************** [2339] ACA0 0F,7E RAN16 XML SPEED Insure in range [2340] ACA2 02 BYTE RANGE * of 1 to 16 [2341] ACA3 01 BYTE 1 [2342] ACA4 00,10 DATA 16 [2343] ACA6 92,4B DEC @FAC1 Adjust to internal range [2344] ACA8 00 RTN This subroutine is used by CALL COLOR, CALL SCREEN, CALL SOUND so like I said a special version would be needed for CALL SCREEN(0) Also a new routine would been needed for blanking the screen. Thus what use would this be? I mean a CALL CLEAR is normally used in XB for this effect? Not talking about just clearing the screen, they are talking about setting the bit which turns off all layers except the background, same as how the screen blanker works. It would require detecting that 0 has been sent to SCREEN() and then setting the proper register bit. It also means that any other value passed to SCREEN() will need to either track that bit manually (which, IIRC, there is a copy of the register in CPU RAM) or simply set the proper value for that bit to make sure the screen is turned back on. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted December 2, 2018 Share Posted December 2, 2018 This subroutine is used by CALL COLOR, CALL SCREEN, CALL SOUND so like I said a special version would be needed for CALL SCREEN(0) Also a new routine would been needed for blanking the screen. Thus what use would this be? I mean a CALL CLEAR is normally used in XB for this effect? Read the original post. Quote Link to comment Share on other sites More sharing options...
RXB Posted December 2, 2018 Share Posted December 2, 2018 (edited) The only way to track that would be in the TI OS that I can see. Now in RXB POKER is POKE VDP Register using Classic99 I typed in: CALL POKER(0,0) :: CALL KEY("",0,K,S) :: CALL POKER(0,1) And Classic99 Debugger showed It changed VDP Register # 0 but nothing happened???? This should have disabled Video Display??? And CALL POKER(0,1) should have re-enabled it...so can someone try this on real iron TI99/4A? Edited December 2, 2018 by RXB Quote Link to comment Share on other sites More sharing options...
Asmusr Posted December 2, 2018 Share Posted December 2, 2018 (edited) You need something like CALL POKER(1,-96) to turn off the screen, and CALL POKER(1,-32) to turn it on again. Edited December 2, 2018 by Asmusr 1 Quote Link to comment Share on other sites More sharing options...
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.