XB256 - Which address for VDP signal on/off?

[gekido_ken]

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

[HOME AUTOMATION]

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

[Stuart]

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?)

[RXB]

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.

[senior_falcon]

 

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

[gekido_ken]

 

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

[Tursi]

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.

[gekido_ken]

 

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

[senior_falcon]

 

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

[LASooner]

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

[Retrospect]

 

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.

[senior_falcon]

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.

[Asmusr]

(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.

[gekido_ken]

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!!!!

[RXB]

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

[senior_falcon]

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)?

[RXB]

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) ??

[senior_falcon]

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.

[RXB]

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...

[sometimes99er]

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.

[RXB]

 

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?

[+OLD CS1]

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.

[senior_falcon]

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.

[RXB]

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

[Asmusr]

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