VDP stack access

[+Vorticon]

Hi.

I was reading up on the use of the assembly utilities for TI BASIC in the E/A manual, and there is mention that the information about the parameters passed with CALL LINK is stored in the stack in VDP RAM, but there is no mention of a location that I can see. Where in VDP RAM is the stack located?

[Sinphaltimus]

Hi.

I was reading up on the use of the assembly utilities for TI BASIC in the E/A manual, and there is mention that the information about the parameters passed with CALL LINK is stored in the stack in VDP RAM, but there is no mention of a location that I can see. How do I access that stack?

Vorticon, you may have touched on something huge for me. My zombi game. I'm stuck. Getting char pattern corruption. I know when running the game without corruption then breaking out and checking SIZE I get like 800 bytes of program free. The CHAR pattern corruption happens during multiple jump routines daisy chained. I am using a call link delay as part of the jump routines. This could be what's corrupting my char codes! And away I go!

 

EDIT: Nope, I was mistaken, I already took care of that call link. But you got me to rethink a few other things related to my issue and the VDP. Trying something new...

Edited December 31, 2016 by Sinphaltimus

[+Lee Stewart]

Hi.

I was reading up on the use of the assembly utilities for TI BASIC in the E/A manual, and there is mention that the information about the parameters passed with CALL LINK is stored in the stack in VDP RAM, but there is no mention of a location that I can see. Where in VDP RAM is the stack located?

 

See VDP section of Thierry's site. The bottom of the value stack is pointed to by >8324 and the top by >836E.

 

...lee

[+Vorticon]

 

See VDP section of Thierry's site. The bottom of the value stack is pointed to by >8324 and the top by >836E.

 

...lee

 

Ah thanks for the pointer. One residual question: how do I know where in that range the topmost item resides? Is there a pointer to it or is it always at >836E? In other words, is the VDP stack always full?

[marc.hull]

 

Ah thanks for the pointer. One residual question: how do I know where in that range the topmost item resides? Is there a pointer to it or is it always at >836E? In other words, is the VDP stack always full?

Maybe $836E points to the top of the stack ???

[+Vorticon]

Maybe $836E points to the top of the stack ???

 

OK duh! I didn't even think that these addresses may actually be pointers to the actual location of the top and bottom of the stack and not absolute addresses. Makes sense now.

Thanks for the clarification

[marc.hull]

 

OK duh! I didn't even think that these addresses may actually be pointers to the actual location of the top and bottom of the stack and not absolute addresses. Makes sense now.

Thanks for the clarification

It's another layer of abstraction involved Walid so it's confusing when you are trying application. CPU memory locations pointing to VDP RAM locations when the 9900 doesn't have a hardware stack in the first place mind fucks us all for a bit. It's a cross dressing nightmare IMHO. What are you working on that you would have to de f#ck the gpl stack nightmare ?

[+Lee Stewart]

You might find this thread useful: TI Mini-Memory programs

 

There is information on passing arguments to/from TI Basic and XB from/to ALC with and without NUMREF, etc.

 

...lee

[+Vorticon]

It's another layer of abstraction involved Walid so it's confusing when you are trying application. CPU memory locations pointing to VDP RAM locations when the 9900 doesn't have a hardware stack in the first place mind fucks us all for a bit. It's a cross dressing nightmare IMHO. What are you working on that you would have to de f#ck the gpl stack nightmare ?

 

I want to create a set of routines that access the parallel port at the low level from TI Basic and XB for those interested in interfacing the TI to the real world but without the knowledge of assembly or Forth.

[+Vorticon]

You might find this thread useful: TI Mini-Memory programs

 

There is information on passing arguments to/from TI Basic and XB from/to ALC with and without NUMREF, etc.

 

...lee

 

Thanks. I'm going to look at that. Is there a good reference regarding using assembly routines with XB?

[+Lee Stewart]

 

Thanks. I'm going to look at that. Is there a good reference regarding using assembly routines with XB?

 

One of the Dow books (Beginning Assembly ...) is listed in my post #6 in that thread. The other Dow book (Assembly Language Primer) is also helpful and is on WHTech. If you don't find it by the time I get back to my computer this afternoon, I will post it here.

 

...lee

[+InsaneMultitasker]

The CYC contains (contained?) a document, "TI EXTENDED BASIC Assembly Language Code Programmer's Guide", that describes the XB argument and VDP stack information. I do not recall seeing the full document available anywhere. Maybe one of the archivists here has a version of the doc that could be scanned and/or posted in the reference section.

[+Ksarul]

I think I do have a copy of that one. I'll try and scan it and put it up. . .unless someone else beats me to it.

[+Lee Stewart]

I couldn't find where I got the file I mentioned in my last post and it is too big to upload here so, for awhile, it is available here (right click to download or left double click to open in your browser): Dow TI Home Computer Assembly Language Primer

 

...lee

[+Ksarul]

That one is in the Archive Ernie Pergrem did, Lee. As a matter of fact, I was the one that did that scan. . .

 

I also found the copy of "TI EXTENDED BASIC Assembly Language Code Programmer's Guide" that I scanned back in 2008. It is now attached here.

TI Extended BASIC Assembly Language Code Programmer's Guide.pdf

[+Vorticon]

Thanks guys! I now have all the info I need for my little endeavor

[RXB]

 

I want to create a set of routines that access the parallel port at the low level from TI Basic and XB for those interested in interfacing the TI to the real world but without the knowledge of assembly or Forth.

Did you ever look at RXB command:

 

CALL IO(type#,bits,cru-base,variable,variable)

 

type# = 0 GROM/GRAM SOUND LIST bits = 1 to 16 bits cru-base = CRU BASE value divided by 2 variables = Numeric variables will contain values 0 to 255

1 VDP SOUND LIST (Same as Assembly or GPL access) (0 to 255 would be same as Hex >00 to FF)

2 CRU INPUT

3 CRU OUTPUT

4 CASSETTE VDP WRITE LIST

5 CASSETTE VDP READ LIST

6 CASSETTE VDP VERIFY LIST

 

Most people do not understand the power they have with RXB vs any other XB made in comparison. No other has a CRU direct Input/Output GPL command built into XB.

[+Vorticon]

Did you ever look at RXB command:

 

CALL IO(type#,bits,cru-base,variable,variable)

 

type# = 0 GROM/GRAM SOUND LIST bits = 1 to 16 bits cru-base = CRU BASE value divided by 2 variables = Numeric variables will contain values 0 to 255

1 VDP SOUND LIST (Same as Assembly or GPL access) (0 to 255 would be same as Hex >00 to FF)

2 CRU INPUT

3 CRU OUTPUT

4 CASSETTE VDP WRITE LIST

5 CASSETTE VDP READ LIST

6 CASSETTE VDP VERIFY LIST

 

Most people do not understand the power they have with RXB vs any other XB made in comparison. No other has a CRU direct Input/Output GPL command built into XB.

 

Very interesting. So how would one read or write from/to the PIO port using RXB? Can you provide a small code snippet as an example?

Here's the general process in assembly:

 LI   R12,>1300         SELECT DSR ADDRESS OF CARD
 SBO  0                 ACTIVATE CARD
 SBO  7                 TURN CARD LED ON
 CLR  @>5000            CLEAR DATA LINES
 SBO  1                 SET PORT TO INPUT (SBZ 1 for output)
 CLR  R1
 MOVB @>5000,R1         READ THE PIO PORT

[RXB]

Ok

CALL IO(3,8,2432,0,3,8,2432,255)

Now to explain

3 is the type CRU output to the card or CRU address

8 number of bits to send

2432 is CRU address >1300 divided by 2 (Same as GPL IO command)

0 is all bits off.

255 is all bits on.

 

Now you need the CRU address for reading a port off the RS232 but would work like

CALL IO(2,8,CRU divided by 2,numeric variable)

 LI   R12,>1300         SELECT DSR ADDRESS OF CARD
 SBO  0                 ACTIVATE CARD
 SBO  7                 TURN CARD LED ON
 CLR  @>5000            CLEAR DATA LINES
 SBO  1                 SET PORT TO INPUT (SBZ 1 for output)
 CLR  R1
 MOVB @>5000,R1         READ THE PIO PORT

* RXB version of same Assembly

CALL IO(3,8,2432,0) ! Same as SBO 0 in Assembly

CALL IO(3,8,2432,7) ! Same as SBO 7 in Assembly

CALL IO(3,8,2432,0) ! Same as SBO 1 in Assembly

CALL IO(2,8,2432,X) ! This would read 8 bits into X 

Edited January 21, 2017 by RXB

[+Vorticon]

Rich, you used the same call for SBO 0 and SBO 1. Also, since the SBO operation is 1 bit, shouldn't the 8 be actually a 1? And finally how would SBZ be called?

Sorry I'm still a bit confused here.

[RXB]

Rich, you used the same call for SBO 0 and SBO 1. Also, since the SBO operation is 1 bit, shouldn't the 8 be actually a 1? And finally how would SBZ be called?

Sorry I'm still a bit confused here.

The GPL IO command is not like Assembly so there is no SBO or SBZ in GPL, see GPL uses the OS in ROM 0 to do all of this work so has a more simplified interface.

 

In RXB you only use the same exact thing as GPL, I just duplicated it for XB to use.

 

How about I show you a RXB XB programs:

Disk Drive Lights & All Card Lights & CRU Keys

100 CALL CLEAR
110 CALL HPUT(4,7,"This is a demo of the",6,7,"CALL IO(3,8,2176,B)",8,7,"3 = TYPE(CRU output)",10,7,"8 = NUMBER OF BITS",12,7,"2176=address/2")
120 CALL IO(3,8,2176,0) :: FOR B=0 TO 255 :: CALL HPUT(14,7,"B=bytes (value "&STR$(B)&")")
130 CALL HPUT(18,5,"**************************",19,5,"WATCH THE DRIVE LIGHTS",20,5,"**************************")
140 CALL IO(3,8,2176,B) :: NEXT B :: CALL HCHAR(14,24,32,7) :: GOTO 110
150 ! THIS ABOVE PROGRAM ONLY WILL WORK ON A REAL TI NOT A EMULATOR
160 ! Reason you see the 4 disk drive lights turn on and off like a Xmas tree

100 ! TURNS OFF/ON EACH CARD FROM >1000 TO >1F00 BUT WILL LOCK UP WITH CERTAIN CARDS
110 FOR CRU=2048 TO 3968 STEP 128
120 CALL IO(3,8,CRU,0,3,8,CRU,255) :: FOR A=1 TO 200 :: NEXT A :: CALL IO(3,8,CRU,0)
130 NEXT CRU

100 DISPLAY AT(1,1)ERASE ALL:"THIS PROGRAM CHECKS FOR     UNUSUAL KEYS BEING PRESSED, EVEN IF MORE THEN FOUR KEYS ARE PRESSED AT ONCE"
110 CALL IO(2,16,3,A,B) :: IF A=18 AND B=255 THEN 110 ELSE CALL HPUT(24,3,RPT$(" ",30),24,24,STR$(A)&" "&STR$(B))
120 IF A=146 THEN CALL HPUT(24,3,"FUNCTION KEY") ELSE IF B=191 THEN CALL HPUT(24,3,"CONTROL KEY") ELSE IF B=223 THEN CALL HPUT(24,3,"SHIFT KEY")
130 IF B=251 THEN CALL HPUT(24,3,"ENTER KEY") ELSE IF B=253 THEN CALL HPUT(24,3,"SPACE BAR") ELSE IF B=254 THEN CALL HPUT(24,3,"PLUS/EQUAL KEY")
140 GOTO 110
150 ! This program does not work correctly in a emulator as can not detect 4 keys at once
160 ! Also notice NO CALL KEY or ASSEMBLY to read keyboard keys

Also look at RXB Documents:

RXBDOC.zip

Edited January 22, 2017 by RXB

[+InsaneMultitasker]

 

100 CALL CLEAR
110 CALL HPUT(4,7,"This is a demo of the",6,7,"CALL IO(3,8,2176,B)",8,7,"3 = TYPE(CRU output)",10,7,"8 = NUMBER OF BITS",12,7,"2176=address/2")
120 CALL IO(3,8,2176,0) :: FOR B=0 TO 255 :: CALL HPUT(14,7,"B=bytes (value "&STR$(B)&")")
130 CALL HPUT(18,5,"**************************",19,5,"WATCH THE DRIVE LIGHTS",20,5,"**************************")
140 CALL IO(3,8,2176,B) :: NEXT B :: CALL HCHAR(14,24,32,7) :: GOTO 110
150 ! THIS ABOVE PROGRAM ONLY WILL WORK ON A REAL TI NOT A EMULATOR
160 ! Reason you see the 4 disk drive lights turn on and off like a Xmas tree

100 ! TURNS OFF/ON EACH CARD FROM >1000 TO >1F00 BUT WILL LOCK UP WITH CERTAIN CARDS
110 FOR CRU=2048 TO 3968 STEP 128
120 CALL IO(3,8,CRU,0,3,8,CRU,255) :: FOR A=1 TO 200 :: NEXT A :: CALL IO(3,8,CRU,0)
130 NEXT CRU
0 ! Also notice NO CALL KEY or ASSEMBLY to read keyboard keys

You should only use bit 0 (the base address) to turn each peripheral card on and off. Your example is setting and resetting 8 CRU bits starting at the base, which is certainly a reason for some lockups and may also put cards in an unknown/unexpected position. The drive light code is also potentially dangerous depending on the controller.

 

To Vorticon's point, wouldn't changing the bit count in the CALL IO parameters mimic SBZ/SBO? How else would you be able to set/reset/test a single bit ?

[+Lee Stewart]

As Rich indicated, the GPL I/O instruction does not support the SBO and SBZ ALC instructions. It also does not support the TB instruction. The GPL I/O instruction uses only the LDCR and STCR instructions, which as you probably know, are significantly slower than SBO, SBZ and TB. If you wish to issue SBO, SBZ or TB, you need to figure out how to get the I/O instruction to do your bidding. For RXB, Rich indicated this is via

CALL IO(type#,bits,cru-base/2,var,var)

If you set a variable named CRU to half the PIO CRU-base-address of >1300/2 = >0980 (2432), you can address CRU bits by adding to CRU in the call.

The following code will set, test and reset (clear) the indicated bits:

100 CRU = 2432

110 CALL IO(3,1,CRU,1) ' SBO 0 ;set bit 0

120 CALL IO(3,1,CRU+7,1) ' SBO 7 ;set bit 7

130 CALL IO(2,1,CRU+2,X) ' TB 2 ;test bit 2 and pass value to X

...

300 CALL IO(3,1,CRU,0) ' SBZ 0 ;reset bit 0

I have no idea whether reading and writing to >5000, where the PIO data lines are mapped, can be effected with 8-bit LDCR and STCR commands. To manage this, I would think you would need to turn on the card and use calls to LOAD() and PEEK() or whatever the RXB equivalents are.

...lee

[+Vorticon]

 

As Rich indicated, the GPL I/O instruction does not support the SBO and SBZ ALC instructions. It also does not support the TB instruction. The GPL I/O instruction uses only the LDCR and STCR instructions, which as you probably know, are significantly slower than SBO, SBZ and TB. If you wish to issue SBO, SBZ or TB, you need to figure out how to get the I/O instruction to do your bidding. For RXB, Rich indicated this is via

CALL IO(type#,bits,cru-base/2,var,var)

If you set a variable named CRU to half the PIO CRU-base-address of >1300/2 = >0980 (2432), you can address CRU bits by adding to CRU in the call.

The following code will set, test and reset (clear) the indicated bits:

100 CRU = 2432

110 CALL IO(3,1,CRU,1) ' SBO 0 ;set bit 0

120 CALL IO(3,1,CRU+7,1) ' SBO 7 ;set bit 7

130 CALL IO(2,1,CRU+2,X) ' TB 2 ;test bit 2 and pass value to X

...

300 CALL IO(3,1,CRU,0) ' SBZ 0 ;reset bit 0

I have no idea whether reading and writing to >5000, where the PIO data lines are mapped, can be effected with 8-bit LDCR and STCR commands. To manage this, I would think you would need to turn on the card and use calls to LOAD() and PEEK() or whatever the RXB equivalents are.

...lee

 

 

Now that makes sense to me! Thanks

Rich, how would one read/write to >5000 once the RS232 card is activated in RXB?

Once I have that info, I'd like to test it out on real hardware and compare execution speeds with my PIOLIB XB utilities.

Edited January 23, 2017 by Vorticon

[RXB]

Well like Lee said use PEEK to read at >5000

 

CAlL PEEK(20480,X) ! >5000 Hex = 20480 Decimal and X now has the value for what is there.

 

or LOAD to write to >5000

 

CALL LOAD(20480,X) ! >5000 HEX = 20480 Decimal and X now is the value put there

 

That is of course if >5000 is a buffer you can read or write to that address.

 

RXB is a tool I never expected to have to come up with all the uses it provides and was hoping everyone would find them.