XB Information (Execute proceedure)

[+RXB]

Hi, I found this program in the Smart programmer.

 

1 CALL CLEAR :: PRINT:"Output to Device? (Y/N) N" :: ACCEPT AT(23,26)SIZE(-1)VALIDATE("YN"):A$ :: IF A$="Y" THEN OPEN #1:A$,OUTPUT :: P=1

2 CALL CLEAR :: CALL PEEK(-31952,A,B,C,D) :: A=A*256+B-65536 :: C=C*256+D-65536 :: PRINT #P:" PROGRAM INFORMATION": :"Line Number Table"

3 PRINT #P: :"Start Address ";A:"End Address ";C: : :"Line Bytes Start":"Number Used Address":"------ ----- -------"

4 FOR I=C-3 TO A STEP-4 :: CALL PEEK(I,B,D,E,F) :: B=B*256+D :: E=E*256+F-65536 :: CALL PEEK(E-1,D) :: D=D+5 :: T=T+D

5 PRINT #P,USING "##### ### ######":B,D,E :: IF E THEN CALL SCREEN(6) :: GOSUB 7

6 NEXT I :: A=(A-C-1)/-4 :: PRINT #P: : :TAB(;"Total Bytes =";T:" Number of lines =";A:"Average Bytes/Line =";INT(T/A) :: STOP

7 CALL KEY("",3,D,E) :: CALL SCREEN( :: RETURN

8 ! Note Variables: A$, P, A, B, C, D, E, F, and T are used in this program.

 

So you merge this program into a XB program and run it. My problem is I want to write new commands in RXB and how XB executes each line is in Assembly not GPL.

When my SCSI drive crashed I lost the Assembly source code of XB, and also the way to figure out how it executes from one line number to the next.

How I look at programs stored in RAM is like this using RXB 2001:

10 GOTO 50

30 REM COMMENT

50 CALL CLEAR

90 GOTO 10

CALL MOVES("RR",4096,-4096,8192)::CALL BSAVE("DSK2.DUMP")

 

Then use TI99DIR53b view to look at the file DUMP. I see the >C9(LineNumberToken) and line numbers but how would I find a line number out of the entire program?

 

Anyone have any clue on how XB does this? (Specifically how GOTO jumps from one line to the next)

Edited July 6, 2011 by RXB

[jacquesg]

Hi, I found this program in the Smart programmer.

 

1 CALL CLEAR :: PRINT:"Output to Device? (Y/N) N" :: ACCEPT AT(23,26)SIZE(-1)VALIDATE("YN"):A$ :: IF A$="Y" THEN OPEN #1:A$,OUTPUT :: P=1

2 CALL CLEAR :: CALL PEEK(-31952,A,B,C,D) :: A=A*256+B-65536 :: C=C*256+D-65536 :: PRINT #P:" PROGRAM INFORMATION": :"Line Number Table"

3 PRINT #P: :"Start Address ";A:"End Address ";C: : :"Line Bytes Start":"Number Used Address":"------ ----- -------"

4 FOR I=C-3 TO A STEP-4 :: CALL PEEK(I,B,D,E,F) :: B=B*256+D :: E=E*256+F-65536 :: CALL PEEK(E-1,D) :: D=D+5 :: T=T+D

5 PRINT #P,USING "##### ### ######":B,D,E :: IF E THEN CALL SCREEN(6) :: GOSUB 7

6 NEXT I :: A=(A-C-1)/-4 :: PRINT #P: : :TAB(;"Total Bytes =";T:" Number of lines =";A:"Average Bytes/Line =";INT(T/A) :: STOP

7 CALL KEY("",3,D,E) :: CALL SCREEN( :: RETURN

8 ! Note Variables: A$, P, A, B, C, D, E, F, and T are used in this program.

 

So you merge this program into a XB program and run it. My problem is I want to write new commands in RXB and how XB executes each line is in Assembly not GPL.

When my SCSI drive crashed I lost the Assembly source code of XB, and also the way to figure out how it executes from one line number to the next.

How I look at programs stored in RAM is like this using RXB 2001:

10 GOTO 50

30 REM COMMENT

50 CALL CLEAR

90 GOTO 10

CALL MOVES("RR",4096,-4096,8192)::CALL BSAVE("DSK2.DUMP")

 

Then use TI99DIR53b view to look at the file DUMP. I see the >C9(LineNumberToken) and line numbers but how would I find a line number out of the entire program?

 

Anyone have any clue on how XB does this? (Specifically how GOTO jumps from one line to the next)

 

Perhaps I am missing the reason for the question.

 

>C9 is hex for token 201 which signifies that the two bytes following will represent a line number. So if a line contained a GOTO statement then the line in token representation would contain >86 for token 134 being GOTO followed by >C9 and two bytes representing the line number. Multiplying the first byte by 256 and adding the second byte gives you the line number. I assume that this takes you to the line number table to figure out where to go next.

 

 

Jacques

[+RXB]

Ok you are right, I should rephrase the question.

 

Example:

10 GOTO 55

 

Address:Byte:What is does

>FFDE >00 LINE# 1ST BYTE

>FFDF >0A LINE# 2ND BYTE

>FFE0 >FF BYTE 1 OF ADDRESS POINTER

>FFE1 >E3 BYTE 2 OF ADDRESS POINTER

>FFE2 >05 LENGTH OF LINE IN XB

>FFE3 >86 GOTO TOKEN

>FFE4 >C9 LINE NUMBER TOKEN

>FFE5 >00 LINE# 1ST BYTE FOR GOTO

>FFE6 >37 LINE# 2ND BYTE FOR GOTO

>FFE7 >00 END OF LINE BYTE IS COUNTED IN LENGTH

 

The search for line number 55 does not exist in GPL, it is in Assembly does anyone know how it finds it?

Every line is of different sizes and the pointers are willy nilly located, how does it tell where to go?

 

I suppose I could just use >832E and just change the current line number pointer, XML >76 is the XML EXECG in GPL XB code. (Execute XB code)

Wish I had the Assembly Source code, could speed up XB if I still had it.

Edited July 7, 2011 by RXB

[Willsy]

The search for line number 55 does not exist in GPL, it is in Assembly does anyone know how it finds it?

 

I believe there is a line number table? A small database where the line number is the key (presumably) and a single datum representing the beginning address of the line of code elsewhere in memory.

 

By the way, did you see the GPL related programs on the TI Tech Pages? Well work look.

 

http://nouspikel.group.shef.ac.uk//ti99/download.htm#disass

 

Scroll down to the free software section. Some nice stuff.

 

Mark

[jacquesg]

My understanding has always been that a line number is somehow linked to its location in memory. I have always thought of it as two tables, a line number table and a memory location table that were linked. I wonder if line 2 of the SP program gives the answer.

 

A*256+B gives you a line number and subtracting 65536 from this gives you the position in memory where this line is stored. Likewise C and D minus 65536 gives you the position in memory where the line ends and is immediately before where the next line will start. This compensates for the line length that can vary.

 

We know that lines are recorded in the order entered and that this includes corrections to existing lines. I have no idea whether or not the line number table is kept in numerical order. Perhaps it is a linked listing.

 

I would think that both TI Basic and XB handle this process in the same way, I wonder if the TI Intern book or the Thierry site would have a more technical explanation than I am able to give. I am very much of a novice in this area so please accept my apology if my understanding is faulty.

 

Jacques

[Willsy]

My understanding has always been that a line number is somehow linked to its location in memory. I have always thought of it as two tables, a line number table and a memory location table that were linked. I wonder if line 2 of the SP program gives the answer.

 

A*256+B gives you a line number and subtracting 65536 from this gives you the position in memory where this line is stored. Likewise C and D minus 65536 gives you the position in memory where the line ends and is immediately before where the next line will start. This compensates for the line length that can vary.

 

We know that lines are recorded in the order entered and that this includes corrections to existing lines. I have no idea whether or not the line number table is kept in numerical order. Perhaps it is a linked listing.

 

I would think that both TI Basic and XB handle this process in the same way, I wonder if the TI Intern book or the Thierry site would have a more technical explanation than I am able to give. I am very much of a novice in this area so please accept my apology if my understanding is faulty.

 

Jacques

 

You're quite right Jacques. I should have just run the program!

 

Actually, the program has some errors in line 1. It's impossible to output to disk as written. I modified the code as follows to produce output to a disk file:

 

1 CALL CLEAR :: A$="DSK3.OUTPUT" :: OPEN #1:A$,OUTPUT :: P=1
2 CALL CLEAR :: CALL PEEK(-31952,A,B,C,D) :: A=A*256+B-65536 :: C=C*256+D-65536 :: PRINT #P:" PROGRAM INFORMATION": :"Line Number Table"
3 PRINT #P: :"Start Address ";A:"End Address ";C: : :"Line Bytes Start":"Number Used Address":"------ ----- -------"
4 FOR I=C-3 TO A STEP-4 :: CALL PEEK(I,B,D,E,F) :: B=B*256+D :: E=E*256+F-65536 :: CALL PEEK(E-1,D) :: D=D+5 :: T=T+D
5 PRINT #P,USING "##### ### ######":B,D,E :: IF E THEN CALL SCREEN(6) :: GOSUB 7
6 NEXT I :: A=(A-C-1)/-4 :: PRINT #P: : :TAB(;"Total Bytes =";T:" Number of lines =";A:"Average Bytes/Line =";INT(T/A) :: STOP
7 RETURN
8 ! Note Variables: A$, P, A, B, C, D, E, F, and T are used in this program.

 

which yeilds the following:

 

 PROGRAM INFORMATION

Line Number Table

Start Address -671 
End Address -640 


Line Bytes Start
Number Used Address
------ ----- -------
   1  48    -67
   2 128   -191
   3 112   -299
   4 103   -398
   5  58   -452
   6 111   -559
   7   7   -638
   8  80   -635


      Total Bytes = 647 
Number of lines = 8 
Average Bytes/Line = 80 

[John Doe]

Edited February 22, 2014 by Tony Knerr

[+RXB]

Well I saw the Line Number table and that still does not explain how XB finds the next line. Dang wish I had the Assembly ROMs source code still. That is where GOTO resides.

 

What I am working on is a CALL GOKEY(string,KeyboardNumber,KeyReturnVariable,StatusVariable,LineNumber)

If any character in the string is the same as the Key pressed it does a GOTO LineNumber.

It may end up more like this CALL GOKEY(string,KeyBoardNumber,KeyReturnVariable,StatusVariable) LineNumber

Also

CALL ONKEY(string,KeyboardNumber,KeyReturnVariable,StatusVariable) LineNumber,LineNumber,LineNumber,...

The string character location in the string is numbered with the LineNumber, so "ABC" would be the 3 LineNumbers in the list. If not true just goes to next line or command.

And

CALL JOKE(Joyst1Y,Joyst1X,Key1,Joyst2Y,Joyst2X,Key2,Status)

This scans both joysticks and Keyboard and returns the variables and staus. Also the Y value can be used on Sprites without a extra line to make it negative.

 

If you have any ideas that are reasonable then let me know. I have had many requests that are almost impossible with a complete rewrite of XB.

 

If I knew the debugger better in Classic99 I might be more successful at finding the ROM code being used.

Edited July 7, 2011 by RXB

[jacquesg]

Well I saw the Line Number table and that still does not explain how XB finds the next line. Dang wish I had the Assembly ROMs source code still. That is where GOTO resides.

 

What I am working on is a CALL GOKEY(string,KeyboardNumber,KeyReturnVariable,StatusVariable,LineNumber)

If any character in the string is the same as the Key pressed it does a GOTO LineNumber.

It may end up more like this CALL GOKEY(string,KeyBoardNumber,KeyReturnVariable,StatusVariable) LineNumber

Also

CALL ONKEY(string,KeyboardNumber,KeyReturnVariable,StatusVariable) LineNumber,LineNumber,LineNumber,...

The string character location in the string is numbered with the LineNumber, so "ABC" would be the 3 LineNumbers in the list. If not true just goes to next line or command.

And

CALL JOKE(Joyst1Y,Joyst1X,Key1,Joyst2Y,Joyst2X,Key2,Status)

This scans both joysticks and Keyboard and returns the variables and staus. Also the Y value can be used on Sprites without a extra line to make it negative.

 

If you have any ideas that are reasonable then let me know. I have had many requests that are almost impossible with a complete rewrite of XB.

 

If I knew the debugger better in Classic99 I might be more successful at finding the ROM code being used.

 

 

I do not know if this will help.

 

Page 70 and 71 of the TI Intern book lists a jump table for most of the TI tokens.

 

GOTO (134) points to >1AFC and Line Number (201) points to >1A2C.

 

It is beyond my understanding to track what is happening at these locations but I am sure it can be done.

 

Jacques

[+RXB]

A look at Bruce Harrison's XB Compiler source code should provide any answers needed on this subject. I'm sure it was included in the package. As I recall, he didn't convert all the XB statements to assembly and had to 'hand feed' the unconverted statements into the

GPL interpreter. Surely he would have to have known how to find the line numbers to accomplish this.

 

Tony

 

LOL Bruce spent many phone calls with me on helping him do the XB Compiler. I mailed him the XB ROM Source code to help him out also.

[+RXB]

Well I have finally found something to use.

 

The GPL source I am trying out is:

 

CALL GOKEY("Y",3,K,S)GO 32000

 

It mostly behaves like RXB CALL KEY("Y",3,K,S) but does not wait for a keypress, instead it scans for a key pressed 16 times and moves on to the next command, but if a key is pressed it looks for the GO >85 then >C9 the line number token.

 

CHKRB CEQ >B6,@CHAT * )?

BR ERRSYN * SYNTAX ERROR

XML PGMCHR * SKIP )

CEQ >85,@CHAT * GO?

BR ERRSYN * SYNTAX ERROR

XML PGMCHR * SKIP GO

CEQ >C9,@CHAT * LINE NUMBER TOKEN?

BR ERRSYN * SYNTAX ERROR

XML PGMCHR * SKIP LINE NUMBER TOKEN

ST @CHAT,@FAC * GET LINE NUMBER HIGH BYTE

XML PGMCHR * SKIP LINE NUMBER HIGH BYTE

ST @CHAT,@FAC * GET LINE NUMBER LOW BYTE

XML PGMCHR * SKIP LINE NUMBER LOW BYTE

XML SPEED * FIND LINE NUMBER IN FAC IN THE LINE NUMBER TABLE

BYTE SEETWO * LINE NUMBER TABLE POINTER

BR ERRLNF * ERROR LINE NUMBER NOT FOUND

B EXEC * EXECUTE A PROGRAM IN EDIT OR PROGRAM MODE

 

Hopefully this will work, if the EXEC is a RUN command then I am back to square one as it resets variables. I would just prefer to insert the code token in the ROMs if I had the source code. It would run faster.

[+RXB]

I made a updated version of the program using RXB:

 

1 CALL CLEAR :: PRINT:"Output to Device? " :: ACCEPT AT(23,19):A$ :: IF LEN(A$) THEN OPEN #1:A$,OUTPUT :: P=1

2 CALL CLEAR :: CALL PEEK(-31952,A,B,C,D) :: A=A*256+B-65536 :: C=C*256+D-65536 :: PRINT #P:" PROGRAM INFORMATION": :"Line Number Table" :: CALL HEX(A,A$,C,C$)

3 PRINT #P: :"Start Address ";A;A$:"End Address ";C;C$: : :"Line Bytes Start Hex":"Number Used Address Address":"------ ----- ------- ----"

4 FOR I=C-3 TO A STEP-4 :: CALL PEEK(I,B,D,E,F) :: B=B*256+D :: E=E*256+F-65536 :: CALL PEEK(E-1,D) :: D=D+5 :: T=T+D

5 CALL HEX(E,E$) :: PRINT #P,USING "##### ### ###### ####":B,D,E,E$ :: IF E THEN CALL SCREEN(6) :: GOSUB 7

6 NEXT I :: A=(A-C-1)/-4 :: PRINT #P: : :TAB(;"Total Bytes =";T:" Number of lines =";A:"Average Bytes/Line =";INT(T/A) :: STOP

7 CALL KEY("",3,D,E) :: CALL SCREEN( :: RETURN

 

Now it gives Hexadecimal and Decimal. Also press ENTER to just go to screen only, or DSK#.NAME and just keep pressing any key till done to make a DV80 file.

So far nothing I try for RXB will get it to jump to that line. It does allow RES in XB and COPY or MOVE or LIST for all the line numbers, but just will not run that go linenumber even though the syntax is exactly the same as normal XB.

 

Next I wil try just finding the line number table and force it to run that address instead of the line number.

Edited July 9, 2011 by RXB

[Tursi]

So far nothing I try for RXB will get it to jump to that line. It does allow RES in XB and COPY or MOVE or LIST for all the line numbers, but just will not run that go linenumber even though the syntax is exactly the same as normal XB.

 

At risk of missing the point, do you mean the "GO 32000" command? Because that is not valid XB.. I think maybe you meant "GOTO 32000"?

[+RXB]

So far nothing I try for RXB will get it to jump to that line. It does allow RES in XB and COPY or MOVE or LIST for all the line numbers, but just will not run that go linenumber even though the syntax is exactly the same as normal XB.

 

At risk of missing the point, do you mean the "GO 32000" command? Because that is not valid XB.. I think maybe you meant "GOTO 32000"?

 

 

No, I am using the token >85 = GO and >86 = GOTO the reason why is that if you type in this to XB.

10 CALL KEY(3,K,S)GO 30

20 GOTO 10

30 END

 

Of course my command is GOKEY so it finds my Subprogram in the list. But when you RES the program it will be:

RES

100 CALL KEY(3,K,S)GO 120

110 GOTO 100

120 END

 

The EDITOR in XB sees GO as a valid token and the notes in the ROMs I remember said something about a future expansion of XB that was never released.

(There are other extra tokens and spare tokens but that is why I needed the ROMs source code)

[+OLD CS1]

So far nothing I try for RXB will get it to jump to that line. It does allow RES in XB and COPY or MOVE or LIST for all the line numbers, but just will not run that go linenumber even though the syntax is exactly the same as normal XB.

 

At risk of missing the point, do you mean the "GO 32000" command? Because that is not valid XB.. I think maybe you meant "GOTO 32000"?

 

XB allows a statement like "10 GO TO 10". Does GO and TO each have their own tokens? If so, then GO would appear to be valid based upon interpretation.

[+RXB]

XB allows a statement like "10 GO TO 10". Does GO and TO each have their own tokens? If so, then GO would appear to be valid based upon interpretation.

 

Yea but you get extra space wasted.

100 GO TO 120

110 REM

120 END

 

The GO >85 is followed by TO >B1 then Line# token >C9 then the Line number. But if you type:

 

100 GOTO 120

110 REM

120 END

 

This one is GOTO >86 followed by Line# token >C9 then the Line number. So uses one less byte to do the same thing, not counting the space bytes.

 

I am looking at using GO only as it is smaller and works fine for what I am doing. Still can not find a routine that will execute the Line# or Address.

Edited July 11, 2011 by RXB

[Tursi]

"GO 30" is not a valid XB statement. Just try it - it doesn't work (I tried it to see myself!) Your assertion was that the syntax is exactly the same as in XB - I am trying to save you some time by pointing out that it is not. I bet your code will work if you use GOTO instead.

[+RXB]

"GO 30" is not a valid XB statement. Just try it - it doesn't work (I tried it to see myself!) Your assertion was that the syntax is exactly the same as in XB - I am trying to save you some time by pointing out that it is not. I bet your code will work if you use GOTO instead.

 

 

As the syntax for GO is not the same as GOTO I wanted to use a unused token that is in XB and not used for anything. I am just using the future expansions for expansions. By the way it does work.

 

[+OLD CS1]

Is there a construct currently or up-coming which allows for a ON-GOTO type of list based upon key press?

 

For instance,

CALL GOKEY("YNM",3,K,S)GO 200,300,400

Also, what in the TI would prevent an INKEY$ function similar to other BASICs?

 

ON POS("YNM",INKEY$)GOTO 200,300,400

 

Where I believe in most BASICs INKEY$ waited for a key press. I'm not exactly sure, now I think about it, I would have to pull up a couple of programs to check. In the case of the TI, it could be INKEY$(x) where "x" is the keyboard scan mode, and perhaps an additive flag to indicate to wait or not. For instance, INKEY$(0) would mean wait for a key press on unit 0, and INKEY$( or even INKEY$(128) would be check once for a key press on unit 0.

 

For that matter, what about something like "GET A$" in which a single key press is returned in A$? This would be equivalent to

A$=""::CALL KEY(0,K,S)::IF S THEN A$=CHR$(K)

Should be less execution time. (I know, this does not really account for A$="" versus A$=CHR$(0), it is just illustrative.)

 

Ugh. I suppose at some point what you wind up doing is porting CBM, ATARI, or AppleSoft BASIC to the TI. And what good (or fun) is that?

Edited July 12, 2011 by OLD CS1

[+RXB]

Is there a construct currently or up-coming which allows for a ON-GOTO type of list based upon key press?

 

For instance,

CALL GOKEY("YNM",3,K,S)GO 200,300,400

Also, what in the TI would prevent an INKEY$ function similar to other BASICs?

 

ON POS("YNM",INKEY$)GOTO 200,300,400

 

Where I believe in most BASICs INKEY$ waited for a key press. I'm not exactly sure, now I think about it, I would have to pull up a couple of programs to check. In the case of the TI, it could be INKEY$(x) where "x" is the keyboard scan mode, and perhaps an additive flag to indicate to wait or not. For instance, INKEY$(0) would mean wait for a key press on unit 0, and INKEY$( or even INKEY$(128) would be check once for a key press on unit 0.

 

For that matter, what about something like "GET A{:content:}quot; in which a single key press is returned in A$? This would be equivalent to

A$=""::CALL KEY(0,K,S)::IF S THEN A$=CHR$(K)

Should be less execution time. (I know, this does not really account for A$="" versus A$=CHR$(0), it is just illustrative.)

 

Ugh. I suppose at some point what you wind up doing is porting CBM, ATARI, or AppleSoft BASIC to the TI. And what good (or fun) is that?

 

Yea I am testing the CALL ONKEY("ABCDE",3,K,S)GO 200,300,400,500,600 now, so far some bugs I have to work out.

 

As for the PC version of INKEY in TI XB would required a total re-write of the ROMs and I no longer have the source code for them. Maybe someone has a copy somewhere as I sent then to many people.

 

In RXB CALL KEY("YN",5,K,S) will always wait for a key press so not very useful with sprites or joysticks, but my new GOKEY and ONKEY are similar to normal KEY and do not wait for a keypress.

 

I could make an new KEY for strings like CALL KEY(3,K,S,S$) that would put the character into a string variable, but can not see the value of this as it is only one key.

Maybe a better approach should be CALL KEY(3,K,S,S$,COUNT) where the COUNT is the number to put into S$ and when COUNT is reached it no longer puts characters into the string.

[+OLD CS1]

Yea I am testing the CALL ONKEY("ABCDE",3,K,S)GO 200,300,400,500,600 now, so far some bugs I have to work out.

 

That is pretty nifty.

 

As for the PC version of INKEY in TI XB would required a total re-write of the ROMs and I no longer have the source code for them. Maybe someone has a copy somewhere as I sent then to many people.

 

So it seems that it is totally a restriction within XB itself, not so much the console OS. I noticed you mentioned a few people to whom you sent the source code; it would be a great stroke of luck if just one of them still had it.

 

In RXB CALL KEY("YN",5,K,S) will always wait for a key press so not very useful with sprites or joysticks, but my new GOKEY and ONKEY are similar to normal KEY and do not wait for a keypress.

 

But useful for prompts. The big problem I always had with CALL KEY was the lack of a keyboard buffer -- if you did not press a key at the CALL KEY call, it would be missed. Always sucked having to hold down a key until the program reacted. Is it that syntax of statement which waits for a key press, or the use of unit 5 in particular?

 

I could make an new KEY for strings like CALL KEY(3,K,S,S$) that would put the character into a string variable, but can not see the value of this as it is only one key.

 

GET and INKEY$ are (were?) widely used, so a single key press does have some merit.

 

Maybe a better approach should be CALL KEY(3,K,S,S$,COUNT) where the COUNT is the number to put into S$ and when COUNT is reached it no longer puts characters into the string.

 

This would seem to be like a hidden ACCEPT...SIZE, without the cursor?

[Tursi]

"GO 30" is not a valid XB statement. Just try it - it doesn't work (I tried it to see myself!) Your assertion was that the syntax is exactly the same as in XB - I am trying to save you some time by pointing out that it is not. I bet your code will work if you use GOTO instead.

As the syntax for GO is not the same as GOTO I wanted to use a unused token that is in XB and not used for anything. I am just using the future expansions for expansions. By the way it does work.

 

I saw your video on Youtube - congrats!

 

You sometimes are difficult to follow, since I didn't know exactly what you were doing, I was trying to help based on what you did say.

[+RXB]

But useful for prompts. The big problem I always had with CALL KEY was the lack of a keyboard buffer -- if you did not press a key at the CALL KEY call, it would be missed. Always sucked having to hold down a key until the program reacted. Is it that syntax of statement which waits for a key press, or the use of unit 5 in particular?

 

That would not change for RXB or XB. The problem is the OS, now in the XB or RXB it does a SCAN as often as it can but it is not a interrupt driven system like a PC is. The TI only services the SCAN when requested or when the need arises. The ROM 0 OS would have to be rewritten.

 

So it seems that it is totally a restriction within XB itself, not so much the console OS. I noticed you mentioned a few people to whom you sent the source code; it would be a great stroke of luck if just one of them still had it.

 

It is like I said both, I could attack the problem from the ROMs better as I could add a SCAN in the ROMs by removing the goofy code that was never needed as the OS has the same code. And I wish someone would say "Hey I have the XB ROMs source code."

[+RXB]

Well always hit another snag, never fails.

After the CALL ONKEY several times I get a Stack Overflow error.

So my access to the ROMs is the problem I was hoping to overcome.

 

This project may be doomed as I no longer have the source code of the XB ROMs and trial and error is just crazy.

 

Update: doing a RXB CALL SIZE is allowed so turns out that it is not a STACK OVERFLOW at all, that is just the error that XB is reporting as a problem.

 

So something in the ROMs is crashing but I am clueless as to what is causing it to report a stack overflow when even a stack reset is being ignored.

 

It has to be ALC (Assembly Language Commands) as all the GPL checks out fine. Crap no source code so screwed.

 

 

UPDATE: Started from scratch on the syntax and just bypassed the Assembly using GPL only to fix the problem. Works great. No stack problems and not a single crash yet.

 

YIPPEE! ONKEY and GOKEY work great.

Edited July 14, 2011 by RXB

[+OLD CS1]

Keep up the good work.

 

On quick question: I realize it would be without comments, but would it not be possible to disassemble the XB ROMs again, maybe "crowd-source" the documentation of the result? (I hate that term, but I lack a better t"erm right now.)