Peeking for colours in XB?

[Bones-69]

I am writing an XB program at the moment and I would like to be able to determine the screen colour plus the foreground and background colour for each colour set, without knowing in advance what the values were set at. I can't help but think this question came up once before....

 

Does anybody know if this information can be retrieved with the right CALL PEEK's?

 

On the PEEK concept, if I wrote a small program to write every peek value from -32767 through to 32767 to disc, then made a single change of screen colour or colour set to the program, would I be able to drill down where this information is held by comparing a second scan of peek values and investigating the values which have changed? ie- Would changes in before/after PEEK values lead me to the information I need?

 

Thanks guys.

[RXB]

The background and forground colors are not stored in RAM anywhere in XB.

Well they are but quickly overwritten.

This is the GPL source for CALL COLOR in XB or RXB:

<0017>			   ***********************************************************
<0018>			   *			   SUBROUTINE FOR 'COLOR'
<0019>			   ***********************************************************
<0020> A91D 0F,7E    COLOR  XML  SPEED			 Must be
<0021> A91F 00			  BYTE SYNCHK	    *	 at a
<0022> A920 B7			  BYTE LPARZ		 *	   left parenthesis
<0023>			   * RXB PATCH CODE
<0024> A921 87,00    COL08  DCLR @VAR0			 Clear ALL pointer
<0025> A923 D6,42,EC	    CEQ  ALLZ,@CHAT	    ALL?
<0026> A926 49,34		   BR   COL09			 No.
<0027> A928 BE,00,EC	    ST   ALLZ,@VAR0	    Yes, store it in pointer
<0028> A92B 87,4A		   DCLR @FAC			  Set 0
<0029> A92D 0F,79		   XML  PGMCHR		    Skip ALL token.
<0030> A92F 06,B0,E4	    CALL COMMA2		    Skip comma.
<0031> A932 49,52		   BR   COL21			 Start ALL RXB routine
<0032> A934 D6,42,FD COL09  CEQ  NUMBEZ,@CHAT	  If sprite number specified
<0033> A937 49,49		   BR   COL20
<0034> A939 06,AE,00	    CALL CHAR1			 Check sprite number (SPNUM3)
<0035> A93C 06,A9,89 COL10  CALL SPCOL			 Put the color in SAL
<0036> A93F D6,42,B3	    CEQ  COMMAZ,@CHAT	  More color changes
<0037> A942 4B,1A		   BR   LNKRTN
<0038> A944 06,AE,02	    CALL CHAR2			 Skip and get sprite number (S
<0039> A947 49,3C		   BR   COL10
<0040>			   * This part for regular color change routine
<0041> A949 0F,7E    COL20  XML  SPEED			 Parse the character
<0042> A94B 01			  BYTE PARCOM		 *   set and insure a comma
<0043> A94C 0F,7E		   XML  SPEED			 Insure in range of
<0044> A94E 02			  BYTE RANGE		  *   0<= x <= 14
<0045>			   * RXB PATCH CODE
<0046>			   *	  BYTE 0,0,14
<0047> A94F 00,00,10	    BYTE 0,0,16
<0048> A952 A3,4A,08 COL21  DADD >080F,@FAC	    Color table addr(>0810 - >081
   A955 0F
<0049> A956 0F,77		   XML  VPUSH			 Push table set address
<0050> A958 0F,7E		   XML  SPEED			 Parse the foreground color
<0051> A95A 01			  BYTE PARCOM		 *   and insure a comma
<0052> A95B 06,AC,A0	    CALL RAN16			 Error if >16 or <1
<0053> A95E BC,0E,4B	    ST   @FAC1,@VAR4	   Save it
<0054> A961 E2,0E,04	    SLL  4,@VAR4		   Foreground color in 4 MSBits
<0055> A964 0F,74		   XML  PARSE			 Get background color
<0056> A966 B6			  BYTE RPARZ
<0057> A967 06,AC,A0	    CALL RAN16			 Error if >16 or <1
<0058> A96A B4,0E,4B	    OR   @FAC1,@VAR4	   Background color in 4 LSBits
<0059> A96D 0F,78		   XML  VPOP			  Get color table address
<0060> A96F BC,B0,4A	    ST   @VAR4,V*FAC	   Load the colors into the tabl
   A972 0E
<0061>			   * RXB PATCH CODE
<0062> A973 D6,00,EC	    CEQ  ALLZ,@VAR0	    ALL in pointer.
<0063> A976 49,80		   BR   COL22			 No.
<0064> A978 35,00,0E	    MOVE 14,V*FAC,V@1(@FAC) Fill color table with values
   A97B E0,01,4A
   A97E B0,4A
<0065> A980 D6,42,B3 COL22  CEQ  COMMAZ,@CHAT	  End of call. Go back.
<0066> A983 4B,1A		   BR   LNKRTN
<0067> A985 0F,79		   XML  PGMCHR		    Skip ","
<0068> A987 49,21		   BR   COL08			 Take care of the next set
<0069>			   *	  CALL SPCOL -- Changes color of sprite.
<0070>			   *				    Called also from SPRITE.

99/4 GPL-ASSEMBLER (Pass 3) correct								   PAGE 0032
EQUATES EXEC-359
<0071> A989 0F,74    SPCOL  XML  PARSE
<0072> A98B B6			  BYTE RPARZ		  *  Get the color number
<0073> A98C 06,AC,A0	    CALL RAN16			 Check range 1 - 16
<0074> A98F BC,E0,03	    ST   @FAC1,V@3(@SPSAL) Store in SAL
   A992 08,4B
<0075> A994 00			  RTN

 

As you can see all of the address are temporary.

>8308 (SPSAL) is a temporary Scratch Pad address used most for Color, Sprites, and Background/Foreground.

 

Rich

[senior_falcon]

The color table is in VDP ram from >0800 to >081F. The addresses we care about in XB are >080F to >081D. (Character sets 0 to 14) Each byte contains the foreground color and the background color for one 8 byte character set in this form: FG*16+BG You have to add 1 to both foreground color and background color to be the same as XB which has colors from 1 to 16, and not 0 to 15.

 

Unfortunately XB does not have PEEKV or POKEV like the mini memory cartridge, or your job would be simple. An assembly language program can be used to read the bytes from VDP into CPU memory where they can be PEEKed. The following is one way to do it:

START LWPI WKSP

LI R0,>080F character set 0 starts at this vdp address

LI R1,10000 read to this address

LI R2,17 17 bytes

BLWP @>202C vdp multiple byte read

LWPI >83E0

B @>006A back to basic

WKSP BSS 32

 

The following XB program will load this A/L program into memory and run it, then return to XB.

10 CALL LOAD(9460,2,224,37,16,2,0,8,15,2,1,39,16,2,2,0,17,4,32,32,44,2,224,131,224,4,96,0,106)

20 CALL LOAD(8192,36,244)::CALL LINK("X")::CALL LOAD(8192,32,90)

After the program runs 17 bytes of the color table are copied into CPU RAM starting at 10000. Now you can PEEK the bytes and determine the color of any character set. To find out the color of character set 3:

CALL PEEK(10003,X)::FG=1+INT(X/16)::BG=X-FG*16+17

 

Unfortunately the screen color is set by writing to a VDP register and I don't think there is any way that you can read from the register.

Edited January 15, 2013 by senior_falcon

[+InsaneMultitasker]

For what its worth,a "good" XB place to store values (assuming you have the 32K expansion) is in high memory, starting at ">A000" (-24576). I use approximately 30 bytes (-24576 to -24547) to pass info between programs, since the values survive

 

CALL LOAD(-24576,100,200) then
CALL PEEK(-24576,A)
CALL PEEK(-24575,B)
or
CALL PEEK(-24576,A,B)

will return A=100 and B=200

 

One could couple this with some assembly code similar to what is shown above.

[RXB]

RXB has built in CALL VPOKE and CALL VPEEK if you have the a RXB cart.

Edited January 12, 2013 by RXB

[senior_falcon]

Bones, I see that you have been playing with the compiler. If this application of yours will be for a compiled program, then there is a fairly direct way to look at the VDP.:

CALL LINK("VREAD",2063,15,A$) will copy the 15 bytes of the color table into A$. You can then use ASC(SEG$(A$,N,1)) to get the color value for character set N-1. (The 1st character in the string is the value for character set 0)

To use this in XB you need to load the CXTRAS as described in the manual.

 

Of course, Rich's VPEEK is the simplest if you have the cart.

[Tursi]

And just to add in, there's no way to read the screen color on the TI, as it's stored in a write-only register on the VDP.

 

[Bones-69]

Thanks for the feedback guys. Greatly appreciated.

 

 

An assembly language program can be used to read the bytes from VDP into CPU memory where they can be PEEKed. The following is one way to do it:

START LWPI WKSP

LI R0,>080F character set 0 starts at this vdp address

LI R1,10000 read to this address

LI R2,17 17 bytes

BLWP @>202C vdp multiple byte read

LWPI >83E0

B @>006A back to basic

WKSP BSS 32

 

The following XB program will load this A/L program into memory and run it, then return to XB.

10 CALL LOAD(9460,2,224,37,16,2,0,8,15,2,1,39,16,2,2,0,17,4,32,32,44,2,224,131,224,4,96,0,106)

20 CALL LOAD(8192,36,244)::CALL LINK("X")::CALL LOAD(8192,32,90)

After the program runs 17 bytes of the color table are copied into CPU RAM starting at 10000. Now you can PEEK the bytes and determine the color of any character set. To find out the color of character set 3:

CALL PEEK(10003,X)::FG=1+INT(X/16)::BG=FG*16-X-15

 

Unfortunately the screen color is set by writing to a VDP register and I don't think there is any way that you can read from the register.

 

This seems like this should fit my requirements really well, I can *just* get by with not knowing the screen colour.

 

I have NEVER stepped outside of XB. Everything to do with Assembler makes me want to take up the fetal position in a dark room.... Everything is, unknown, kinda scary and I suspect out of my league so please excuse me asking some (probably) dumb questions

 

To test the above I copied pasted the following into EA;

 

START LWPI WKSP
LI R0,>080F
LI R1,10000
LI R2,17
BLWP @>202C
LWPI >83E0
B @>006A
WKSP BSS 32

 

I then attempted to assemble this file. I got the following message.

END ASSUMED - 0009

0001 ERRORS

 

Is END ASSUMED the 0001 error or is END ASSUMED just a passing comment?

 

I tried it anyway in XB after the above error and was surprised to see the FG was always reported correctly, however BG value is incorrect - but still fairly usable with a little work (awesome!).

 

COL / BG VALUE

1 / 1

2 / 0

3 / 1

4 / 2

5 / 3

6 / 4

7 / 5

8 / 6

9 / 7

10 / 8

11 / 9

12 / 10

13 / 11

14 / 12

15 / 13

16 / 14

 

Regarding the incorrect BG answer liseted above, is this the result of the Assembling 0001 ERROR, or a calc error with FG/BG or is there a reasonable chance I have just stuffed it all up?

 

But.... at the end of the day I think this really nailed things for me so thanks heaps.

Edited January 15, 2013 by Bones-69

[Bones-69]

OK.. So after testing and getting good answers, I put it into my program and the numbers are now coming out strange with -9's and stuff like that. So at this stage, I don't have a fix. Ahhh... The highs and then the lows.

[senior_falcon]

Hi Bones:

 

I had a senior moment when writing the code to compute the background value. It should be BG=X-FG*16+17. Make that change and it should come out right. I edited my initial post to include that change.

 

The end assumed message is nothing to worry about. I should have included an END directive. This is about the only error that you can get away with in assembly. Good for you for trying out the assembly program!

[+InsaneMultitasker]

I am writing an XB program at the moment and I would like to be able to determine the screen colour plus the foreground and background colour for each colour set, without knowing in advance what the values were set at. I can't help but think this question came up once before....

Just out of curiosity.. do you have the option of defining the colors yourself and storing them so you always know the current colors? Of course, not knowing what magic you are creating, I'm just tossing out the question

[Willsy]

Just out of curiosity.. do you have the option of defining the colors yourself and storing them so you always know the current colors? Of course, not knowing what magic you are creating, I'm just tossing out the question

That's what I was thinking... If you are setting the colours yourself then you have the power to know what they currently are...!

[Bones-69]

OK... Thought my program would be ready for release by now and my silly request would be understood, but the final stages are taking longer than expected so I should explain.

 

I am writing an XB program that will grab any screen displayed, then package the screen into the smallest format possible (that I have been able to develop in XB anyway), then have my program export a second program that reproduces the exact screen it grabbed including colours & char definitions. This exported program, which is specifically compatible with the XB Compiler, can then be merged/pasted into any program destined to be XB compiled (or be copy pasted to and from text editors without loosing characters 0-31 and characters 127-159). My main motivation for writing this was to get Magellan designed screens straight into the XB Compiler but it will work on any 24x32 screen it is given (including the prompt).

 

Now, when merging my program with an XB Magellan exported program I have access to all the data which the screen was designed with, but if I want my program to be able to build any screen (without knowing in advance what the colours were set to, or where to find this information), then I needed a way to "back door" the colour and screen values. Especially if my program is going to be used with the RUN command directly from another program.

 

Anyway... All should be clear in a few days when it is finished (hopefully). The good news it is working and it is only the additional features that are holding things up. Here is the current output (still a few glitches to sort), that my program exported after it was merged into a Magellan exported program. It will also write a true XB version (without the X-B compiler "DISPLY" or the relevant RXB CALL statement which escapes me at the moment).

 

PROGRAM #1																																		
Use in XB programs which are going to be compiled.																								
																																				
*Program #1 requires DSK1.C-XTRAS to be loaded if testing in XB environment. Refer XB Compiler documentation or use Program #2.					
																																				
User defined preferences;																															
>Program line number start:100																													
>Program line number Increment:10																												
>Data line number start:1000																														
>Character 31 has been replaced by character 32 to create less data and draw screen faster.														
>Magellan data was used to identify correct screen colour.																						
>Hex Data and character definition routine has been included.																					
*Standard XB hex char data has been selected. (Hex data has not been optimised to reduce programming space.										
>Characters 0-31, character 33 & characters 127-159 are drawn to screen during a second pass using CALL HCHAR. The number of characters requiring
a second pass is 41. (Support option for Magellan which skips BLANK characters rather than writing 0000000000000000.)							
-Characters found with hex code 3C5ADBFF18244281 have been reset to 0000000000000000.															
																																				
* A second file has been created, refer "DSK1.SS-S". This file has additional information and formatting styles which may be useful.				
																																				
PROGRAM #1 START (Copy/Paste the following program into Classic99. Program is ready to be compiled or included elsewhere.)							
110 CALL CLEAR::RESTORE 1000																														
120 READ A::CALL SCREEN(A)::FOR I=0 TO 14::READ A,B,C::CALL COLOR(A,B,C)::NEXT I																	
130 FOR I=1 TO 28::READ A,A$::CALL CHAR(A,A$)::NEXT I																								
140 FOR I=1 TO 24 STEP 4::READ A$::CALL LINK("DISPLY",I,1,A$)::NEXT I																				
150 READ A$::FOR I=1 TO LEN(A$)STEP 3::A=ASC(SEG$(A$,I,1))::IF A=42 THEN 170																		
160 CALL HCHAR(A-77,ASC(SEG$(A$,I+1,1))-77,ASC(SEG$(A$,I+2,1))+33)::NEXT I::GOTO 150																
170 CALL KEY(0,A,B)::IF B=0 THEN 170																												
180 END																																			
1000 DATA 2																																		
1010 DATA 0,2,1,1,5,2,2,7,2,3,12,2,4,12,2,5,12,2,6,12,2,7,12,2																						
1020 DATA 8,12,2,9,8,2,10,8,5,11,15,5,12,12,5,13,12,5,14,16,13																						
1030 DATA 32,"0000000000000000800000000000000000000000000000000000000000000000",36,"FFFFFFFFFFFFFFFF007E7E7E7E7E7E0014143E143E1414003844040810207C00"
1040 DATA 40,"0000001F1F181818000000F8F8181818000000FFFF0000001818181818181818",44,"1818181F1F000000181818F8F8000000181818F8F81818181818181F1F181818"
1050 DATA 48,"00708888888888700010301010101038003844040810207C0038440418044438",52,"00081828487C0808007C4078040444380018204078444438007C040810202020"
1060 DATA 56,"0038444438444438003844443C04083000FF0000000000000020505020544834",60,"0002040810204000000000000018081000201008102000000038440408100010"
1070 DATA 64,"0000000000003030003844447C44444400782424382424780038444040404438",68,"0078242424242478007C40407840407C007C404078404040003C40405C444438"
1080 DATA 72,"004444447C444444003810101010103800040404040444380044485060504844",76,"004040404040407C00446C545444444400446464544C4C44007C44444444447C"
1090 DATA 80,"0078444478404040003844444454483400784444785048440038444038044438",84,"007C101010101010004444444444443800444444282810100044444454545428"
1100 DATA 88,"00444428102844440044442810101010007C04081020407C0028287C287C2828",92,"0000090D0B09090000007456555474000000B8A1B0A1B8000000A050A050A000"
1110 DATA 96,"00000000000000FF8080808080808080FF000000000000000101010101010101",100,"007E7E7E7E7E7E00000000000000000000000000000000000000000000000000"
1120 DATA 104,"030E1D2D767BCDB6B6CD7B762D3D0E03C070BCB46EDEB36D6DB3DE6EB4B870C0",108,"0000000000000000000000000000000000000000000000000000000000000000"
1130 DATA 112,"0000000000000000000000000000000000000000000000000000000000000000",116,"0000000000000000000000000000000000000000000000000000000000000000"
1140 DATA 120,"0103060C15252D36250D14262C3720200080C060504868D8486050C868D80808",124,"3F61446637121009091110120B08070000C060201030E0800080C0601010E000"
1150 DATA 128,"00003F21EDADA1A8AFE02E3B0E000000082008000C0CFF01F98539EF38000000",132,"005824020F3975FBDEDF240408102000001C2242F09CAEDF7BFB242010080400"
1160 DATA 136,"0103070F1F3F793F3939BFF195F591FF0080D8F8F8FC9EFC9F9FFFFF09FF09FF",140,"FF0000000000000000EE44444E0000000000000000000000FF00EAACAAEA0000"
1170 DATA " ````````````````	 MENU c%%%%%%%%%%%%%%%%a	 :::: c%%%%%%%%%%%%%%%%a 1@SELECT CHARc%%%%%%%%%%%%%%%%a 2@FILL;ERASE "		
1180 DATA "c%%%%%%%%%%%%%%%%a 3@INVERT;MOVEc%%%%%%%%%%%%%%%%a 4@SWAP;COPY c%%%%%%%%%%%%%%%%a 5@HEX CODES c%%%%%%%%%%%%%%%%a 6@COLOUR	 "		
1190 DATA "c%%%%%%%%%%%%%%%%a 7@MEDIA SETUPc%%%%%%%%%%%%%%%%a 8@HELP	 c%%%%%%%%%%%%%%%%a			 c%%%%%%%%%%%%%%%%a ```` MEDIA "		
1200 DATA "c%%%%%%%%%%%%%%%%ac a::::: c%%%%%%%%%%%%%%%%ac a>PLAYINGc%%%%%%%%%%%%%%%%ac a[4	 c%%%%%%%%%%%%%%%%ac a	 "		
1210 DATA "c%%%%%%%%%%%%%%%%ac a>SHOWING bbbbbbbbbbbbbbbb c a[5=[6=[7 BG [1(*&'*)[3 [4 c a;[8 PLUS(*****.$$$$/*****)c aB<GROUND"		
1220 DATA "+xz |~+$hj$+	 + bbbb		 +y{ } +$ik$+	 + F@LOAD<SAVE ,*****.$$$$/*****- E@EXIT			 ,\]^_-			 V1@0"		
1230 DATA "ZamZbmZcmZdl[am[bg[ci[dm\am\bh\cj\dm]am]bm]cm]dm^ak^bk^ck^dn_am_bg_ci_dm`am`bh`cj`dmaamabmacmadmbZ_b[ab]cb^ecS^cZ`c[bc]dc^f***"

 

When you dismiss all the char & colour data statements (which are required regardless), plus the 6 lines which make up the drawing routine, you are basically left with a reasonably small amount of data responsible for displaying 768 characters - so grabbing complex screens is made fast and not occupy too much XB & XB Compiler programming space.

1170 DATA " ````````````````	 MENU c%%%%%%%%%%%%%%%%a	 :::: c%%%%%%%%%%%%%%%%a 1@SELECT CHARc%%%%%%%%%%%%%%%%a 2@FILL;ERASE "		
1180 DATA "c%%%%%%%%%%%%%%%%a 3@INVERT;MOVEc%%%%%%%%%%%%%%%%a 4@SWAP;COPY c%%%%%%%%%%%%%%%%a 5@HEX CODES c%%%%%%%%%%%%%%%%a 6@COLOUR	 "		
1190 DATA "c%%%%%%%%%%%%%%%%a 7@MEDIA SETUPc%%%%%%%%%%%%%%%%a 8@HELP	 c%%%%%%%%%%%%%%%%a			 c%%%%%%%%%%%%%%%%a ```` MEDIA "		
1200 DATA "c%%%%%%%%%%%%%%%%ac a::::: c%%%%%%%%%%%%%%%%ac a>PLAYINGc%%%%%%%%%%%%%%%%ac a[4	 c%%%%%%%%%%%%%%%%ac a	 "		
1210 DATA "c%%%%%%%%%%%%%%%%ac a>SHOWING bbbbbbbbbbbbbbbb c a[5=[6=[7 BG [1(*&'*)[3 [4 c a;[8 PLUS(*****.$$$$/*****)c aB<GROUND"		
1220 DATA "+xz |~+$hj$+	 + bbbb		 +y{ } +$ik$+	 + F@LOAD<SAVE ,*****.$$$$/*****- E@EXIT			 ,\]^_-			 V1@0"		
1230 DATA "ZamZbmZcmZdl[am[bg[ci[dm\am\bh\cj\dm]am]bm]cm]dm^ak^bk^ck^dn_am_bg_ci_dm`am`bh`cj`dmaamabmacmadmbZ_b[ab]cb^ecS^cZ`c[bc]dc^f***"

 

Because the above data contains no characters that get lost when pasting between text editors ie- chars <32 & >126 , nothing gets lost when using text editors. I needed a solution for this problem during a time the XB Compiller does not support disc file functions.

 

Sorry to rave. This info really belongs in its own thread when I finsh the program.

[Bones-69]

Woops... Somthing got lost there in the copy/paste to the forum. Hope you get the idea anyway...