XB Compiler v2.1

[+Lee Stewart]

I presume that the console keyboard scan routine is used by the compiler. Is that right, Harry?

 

If so, I posted how all this works over in the "Assembly on the 99/4A" topic: http://atariage.com/forums/topic/162941-assembly-on-the-994a/page-11?do=findComment&comment=2848971

 

Regarding restoring the keyboard mode to the entire keyboard (5 for Basic and XB) after scanning the left side (1) or right side(2) with CALL KEY, I would think that restoring 8374h to 5 as the last thing that CALL KEY does is the way the compiler should do it to emulate what XB does. That way when CALL KEY (0,...) is coded by the user, keyboard mode 5 will be used as with XB (see my post above for why this is so).

 

I'm not sure how XB gets the values for CALL JOYST; but, I would guess it also uses KSCAN because KSCAN also checks the actual joystick lines. If that is the case, I would make the same recommendations as the last paragraph.

 

I don't mean to suggest more work for you, Harry, but that is just how the programmers of TI Forth did it and I retained that in fbForth.

 

...lee

[senior_falcon]

Yep, the console keyboard scan is used. Now, as to what the compiler should do to emulate what XB does: when in BASIC or XB, use Classic99's debugger to look at >83C4 and >8374. Write a simple program: 10 CALL KEY(4,K,S) 20 GOTO 20. According to what you wrote, both >83C6 and >8374 should be 4. But that's not the case - both of them are zero. I'm with Rich Gilbertson on this - the default value in BASIC/XB sure seems to be zero. To make a believer out of me, show an example that keeps a value that is not zero at these locations. (in XB, not forth) For that matter I've never found any way in BASIC or XB to use a key unit of 0 to use a mode previously specified by CALL KEY.

[sometimes99er]

Try setting up a breakpoint like M8374=04, and you see it actually stops when it turns to 4.

[+Lee Stewart]

Yep, the console keyboard scan is used. Now, as to what the compiler should do to emulate what XB does: when in BASIC or XB, use Classic99's debugger to look at >83C4 and >8374. Write a simple program: 10 CALL KEY(4,K,S) 20 GOTO 20. According to what you wrote, both >83C6 and >8374 should be 4. But that's not the case - both of them are zero. I'm with Rich Gilbertson on this - the default value in BASIC/XB sure seems to be zero. To make a believer out of me, show an example that keeps a value that is not zero at these locations. (in XB, not forth) For that matter I've never found any way in BASIC or XB to use a key unit of 0 to use a mode previously specified by CALL KEY.

 

Nope. For a key unit of 4, >83C6 = 1 (KEYSCAN subtracts 3 from key unit number) and >8374 = 0 (KEYSCAN changes the 4 to 0 after changing >83C6). And, that is exactly what your two-line program shows in Classic99's debugger for both TI Basic and XB. They both restore the key unit to 5, i.e., >83C6 = 2 and >8374 = 0, when the program is stopped.

 

KEYSCAN does not change >83C6 if a key unit of 1 or 2 is used nor does it change >8374 to 0. However, both TI Basic and XB change >8374 back to the previously specified a key unit of 5 immediately after CALL KEY (1,...) or CALL KEY (2,...) is used and any use of CALL KEY (0,...) will use the previously specified key unit. Keep in mind that the previously specified key unit includes only 3, 4 and 5

 

...lee

Edited March 11, 2014 by Lee Stewart

[senior_falcon]

Lee, thanks for the info. If the previously specified key unit must be 3,4 or 5 then that explains why my tests didn't work, as I was using a key unit of 1 or 2. Actually, this makes some sense - if I recall correctly, you use a key unit of 1 and 2 to scan for the joystick fire buttons. Then a key unit of 0 puts you back where you began. Perhaps this makes for more compatibility between the 99/4 and the 4A? Anyway, it ooks like when XB starts up, >8374 is 0 and >83C6 is 2 (for a key unit of 5) and that is how I will initialize the compiler when it starts, then just clear the byte at >8374 after scanning the keyboard. Will do a little more looking with the debugger to be sure this is right.

 

(Edit) OK, so the kopek finally dropped. XB puts a 0 at >8374 and a 2 at >83C6 and that causes keyscan to use a key unit of 5 to scan the keyboard. You're saying to bypass all that and simply put a 5 at >8374 which would have the same results as the default XB values. Sounds good - I'll check it out tonight if I get a chance.

Edited March 11, 2014 by senior_falcon

[+Lee Stewart]

Pretty much. What I think I would do, however, is to always start up with key unit 5, but to restore only 0 to >8374 immediately after a keyscan of 1 or 2. That way, while a program is executing, the user can use whatever key unit (3,4 or 5) they wish for the whole program or whenever they change it. One easy way to prove what I'm trying to say works is to change the key unit to 3 at the beginning of a Basic/XB program and use INPUT and/or ACCEPT to attempt to enter lowercase characters, then print what was entered. It shouldn't work because key unit 3 puts the keyboard in 99/4 mode, which only allows uppercase letters.

 

...lee

[senior_falcon]

Dang it, you beat me to it. I was going to write a post almost identical to yours! What I will do is put a 2 at >83C6 (which will be key unit 5) and clear the byte at >8374 after any CALL KEY. That should behave just like BASIC or XB do.

[+Lee Stewart]

Dang it, you beat me to it. I was going to write a post almost identical to yours! What I will do is put a 2 at >83C6 (which will be key unit 5) and clear the byte at >8374 after any CALL KEY. That should behave just like BASIC or XB do.

 

Not quite like Basic/XB. I would initialize >83C6 and >8374 as you say, but only as the default before any user code gets compiled. After any CALL KEY, I would only clear >8374. No user may ever want anything but key unit 5; but, that way, they can change it to 3 or 4 if they wish and expect it to stay that way until they change it again or the program ends.

 

...lee

 

PS: Perhaps I jumped the gun! That's probably what you said and I just didn't read it correctly.

Edited March 12, 2014 by Lee Stewart

[RXB]

GPL even XB and BASIC use key unit 0 more often in >8374 so I have never understood this use of 5 as being preferred.

<0209>               ***********************************************************
<0210>                      COPY 'DSK8.SRXB3-C'
<0001>               ***********************************************************
<0002>               *            START OF BASIC INTERPETER
<0003>               ***********************************************************
<0004>                      AORG >0372
<0005> 6372 86,A3,70 TOPLEV CLR  V@>0370           Initialize temp area
<0006> 6375 35,00,4D        MOVE 77,V@>0370,V@>0371
       6378 A3,71,A3
       637B 70
<0007>               * RXB MODULE PATCH CODE FOR RXB MODULE ********************
<0008>               *      ST   5,@KEYBD          Select full keyboard
<0009>               *      SCAN
<0010>               *      CZ   @KEYBD
<0011>               *      BR   G6388             99/4A Console?
<0012>               * RXB HARDWARE CARTRIDGE PATCH
<0013>               *      CALL CART              * RXB PATCH CODE FOR CARTRIDGE
<0014> 637C BE,A3,BB        ST   >01,V@CONFLG      Select 99/4A console
       637F 01
<0015> 6380 86,74    G6388  CLR  @KEYBD
<0016>               * RXB MODULE PATCH CODE FOR RXB MODULE ********************
<0017>               *      DST  NLNADD,V@BUFSRT   Initialize edit-buffer start
<0018>               *      DST  NLNADD,V@BUFEND   Initialize edit-buffer end
<0019> 6382 31,00,02        MOVE 2,G@ATNZZ,@INTRIN Get address of ATNZZ
       6385 38,00,32
<0020> 6388 B2,38,1F        AND  >1F,@INTRIN       Throw away the BR opcode
<0021> 638B A3,38,00        DADD >5B,@INTRIN       Address of polynomial constan
       638E 5B
<0022>                
<0023>               * RXB PATCH CODE *************
<0024> 638F BE,A3,71        ST   >31,V@LODFLG      indicate try auto-boot
       6392 31
<0025> 6393 05,63,A5        B    SZNEW
<0026>                      AORG >03A4
<0027> 63A4 00              RTN                    Byte to even address

As you can see RXB does not even use Key Unit 5 except to check to see if this is 4A console or a TI99 as the 4A has key unit 5 and TI99 does not.

The GPL command:

 

CLR @>8374

 

Is mostly what is used as Key Unit 0 as per page 109 of the Extended Basic Manual quote:

 

"Values of 3, 4, and 5 are reserved for possible future uses."

 

So again why this preference for Key Unit 5?

 

I am just curious as being a GPL programmer for XB and exclusively that for so many years this strikes me as odd that people keep doing this?

[+Lee Stewart]

...

As you can see RXB does not even use Key Unit 5 except to check to see if this is 4A console or a TI99 as the 4A has key unit 5 and TI99 does not.

The GPL command:

 

CLR @>8374

 

Is mostly what is used as Key Unit 0 as per page 109 of the Extended Basic Manual quote:

 

"Values of 3, 4, and 5 are reserved for possible future uses."

 

So again why this preference for Key Unit 5?

 

I am just curious as being a GPL programmer for XB and exclusively that for so many years this strikes me as odd that people keep doing this?

 

With all due respect, Rich, the reason that "people keep doing this" strikes you as odd is because you apparently are not understanding the console keyboard scan routine (I'll call it KEYSCAN) that is used by TI Basic, XB and, I would presume, RXB.

I will grant you that the XB manual is confusing in the context of this discussion precisely because it says what you excerpted above, viz., "Values of 3, 4, and 5 are reserved for possible future uses." This probably is because the TI programmers of TI Basic and XB did not want to confuse Basic users with unnecessary facts when they had no plans to deal with anything but key units 1, 2 and 5. And, yes, it is indeed key unit 5 that TIB and XB use, your protestations to the contrary notwithstanding. Even though you can, indeed, put a 0 in the CALL KEY statement for the key unit, there is no actual key unit 0. It is a term of convenience in the XB manual. When you use 0 for the key unit, you are asking KEYSCAN to look at >83C6 for the previously invoked whole keyboard key unit, i.e., 3, 4 or 5. KEYSCAN will add 3 to that number to get the actual key unit it should use. The fact is that TIB and XB go out of their way to enforce the use of key unit 5 by always starting up with >83C6 = 2 and >8374 = 0 (remember that KEYSCAN adds 3 to the value in >83C6 for the key unit it will use when it finds that >8374 = 0). However, while a user program is running, the key unit can be changed at the user's whim. I proved that in one of my posts above for key unit = 3, which forces KEYSCAN to treat the keyboard as a TI-99/4, i.e., all caps and no control characters.

To prove that you can also use key unit = 4 (Pascal keyboard), try this code and tap the BREAK key, F4, at the '?' prompt:

10 CALL KEY(4,K,S)

20 INPUT X$

It won't abort the program! That's because the keycode for the BREAK key is 2 for the Basic keyboard (key unit = 5); but, the keycode on the Pascal keyboard for the BREAK key is 130. To get the program to abort, you must use CTRL+B (Pascal keyboard keycode = 2).

One last point: During a user's program that has a CALL KEY(4,K,S), any use of CALL KEY(0,K,S) will NOT restore the Basic keyboard mode. The program will continue to use the Pascal keyboard mode because that was the last invoked whole keyboard key unit code. As soon as the program exits, it will indeed be restored to Basic keyboard mode (key unit = 5).

...lee

[+OLD CS1]

To prove that you can also use key unit = 4 (Pascal keyboard), try this code and tap the BREAK key, F4, at the '?' prompt:

10 CALL KEY(4,K,S)

20 INPUT X$

It won't abort the program! That's because the keycode for the BREAK key is 2 for the Basic keyboard (key unit = 5); but, the keycode on the Pascal keyboard for the BREAK key is 130. To get the program to abort, you must use CTRL+B (Pascal keyboard keycode = 2).

Ooooooo... that is actually a neat trick. Depending upon how useful Pascal keyboard is for most programs, that could be a sneaky way to "disable" BREAK in TI BASIC programs.

[Willsy]

to Lee. That's the most concise distillation of KSCAN that I've seen. We should frame it.

[RXB]

 

 

With all due respect, Rich, the reason that "people keep doing this" strikes you as odd is because you apparently are not understanding the console keyboard scan routine (I'll call it KEYSCAN) that is used by TI Basic, XB and, I would presume, RXB.

I will grant you that the XB manual is confusing in the context of this discussion precisely because it says what you excerpted above, viz., "Values of 3, 4, and 5 are reserved for possible future uses." This probably is because the TI programmers of TI Basic and XB did not want to confuse Basic users with unnecessary facts when they had no plans to deal with anything but key units 1, 2 and 5. And, yes, it is indeed key unit 5 that TIB and XB use, your protestations to the contrary notwithstanding. Even though you can, indeed, put a 0 in the CALL KEY statement for the key unit, there is no actual key unit 0. It is a term of convenience in the XB manual. When you use 0 for the key unit, you are asking KEYSCAN to look at >83C6 for the previously invoked whole keyboard key unit, i.e., 3, 4 or 5. KEYSCAN will add 3 to that number to get the actual key unit it should use. The fact is that TIB and XB go out of their way to enforce the use of key unit 5 by always starting up with >83C6 = 2 and >8374 = 0 (remember that KEYSCAN adds 3 to the value in >83C6 for the key unit it will use when it finds that >8374 = 0). However, while a user program is running, the key unit can be changed at the user's whim. I proved that in one of my posts above for key unit = 3, which forces KEYSCAN to treat the keyboard as a TI-99/4, i.e., all caps and no control characters.

To prove that you can also use key unit = 4 (Pascal keyboard), try this code and tap the BREAK key, F4, at the '?' prompt:

10 CALL KEY(4,K,S)

20 INPUT X$

It won't abort the program! That's because the keycode for the BREAK key is 2 for the Basic keyboard (key unit = 5); but, the keycode on the Pascal keyboard for the BREAK key is 130. To get the program to abort, you must use CTRL+B (Pascal keyboard keycode = 2).

One last point: During a user's program that has a CALL KEY(4,K,S), any use of CALL KEY(0,K,S) will NOT restore the Basic keyboard mode. The program will continue to use the Pascal keyboard mode because that was the last invoked whole keyboard key unit code. As soon as the program exits, it will indeed be restored to Basic keyboard mode (key unit = 5).

...lee

 

RXB and XB have the same exact code. RXB only differs in the patches I put into the ORIGINAL XB Source Code.

Thus if you look at RXB source files I put * RXB PATCH * before any section that gets modified in the Original XB Source then a * (Asterisk) before that line with original comments from TI Programmers that wrote XB.

 

Looking at the source XB always does a CLR @KEYBD (@>8374) before it returns and saves the old KEYBD values in one of four temporary variables depending on which routine was called at the time.

 

I will not comment on what the Console does as that is a separate issue and I have not worked with the Console GROM as much as my 20 some years on XB.

 

By the way the reason it does this is the TI99 does not support or able to use key unit 5.

This is why you can use XB or RXB in a TI99 or TI99/4A also.

XB was modified to use key unit 5 and the Original Source Code for XB shows this.

The only known copy of the XB Source can only be found in RXB Source.

I know of no one else that has ever had it or could explain what is going on.

 

I suspect the Console ROM/GROM routines are the reason for your results. Or that one of the Temporary Variables is being used to restore a Key Unit Scan.

 

But KEY UNIT 5 is not anywhere in the XB or RXB source.

I can not find a ST 5,@KEYBD or anything like it anywhere in the XB or RXB source.

(Except the code I posted at the INITIALIZATION of XB/RXB)

 

Could you explain the results of this program in XB and RXB?

100 FOR A=0 TO 5
110 CALL PEEK(-31884,X)
120 CALL KEY(A,K,S)
130 CALL PEEK(-31884,Y)
140 PRINT X,Y
150 NEXT A

Why are the results 0,0 and even after the program ends >8374 still has zero in it? (This is why I suspect the Console is doing this.)

 

P.S. Just checked all the XB and RXB source and not a single use of >83C6 anywhere, so that confirms XB or RXB is not using the value there or looks at it.

Edited March 14, 2014 by RXB

[+Lee Stewart]

...

Looking at the source XB always does a CLR @KEYBD (@>8374) before it returns and saves the old KEYBD values in one of four temporary variables depending on which routine was called at the time.

 

This merely restores the keyboard to the current default, which is key unit (KU) 5 unless the user changes it within the program.

 

I will not comment on what the Console does as that is a separate issue and I have not worked with the Console GROM as much as my 20 some years on XB.

 

Actually, it is not a separate issue—It is precisely the issue. BTW, KEYSCAN is in console ROM, not GROM. It reads values from tables located in console GROM, but does not link to GPL.

 

...

I suspect the Console ROM/GROM routines are the reason for your results. Or that one of the Temporary Variables is being used to restore a Key Unit Scan.

 

KEYSCAN (my temporary name for the console ROM keyboard scanning routine) is very much the reason for the results I've been discussing. It takes the key unit value it is passed to decide what to scan and how to report it.

 

But KEY UNIT 5 is not anywhere in the XB or RXB source.

I can not find a ST 5,@KEYBD or anything like it anywhere in the XB or RXB source.

(Except the code I posted at the INITIALIZATION of XB/RXB)

 

That's all it takes, Rich! That one initial use of KU = 5 tells KEYSCAN that will be the default unless it gets changed within the user's program. And, then, of course, it gets re-initialized to KU = 5 when the program ends. If that's the only place, then somehow that get's re-executed when a program ends. KEYSCAN will subtract 3 from the value at >8374, store it at >83C6 and clear >8374. All CALL KEY(0,...) calls after that will cause KEYSCAN to look at >83C6 for the current, default KU. For >83C6 = 0, KU = 3; for >83C6 = 1, KU = 4; for >83C6 = 2, KU = 5.

 

Could you explain the results of this program in XB and RXB?

 

Certainly! See my comments at the end of each code line.

 

100 FOR A=0 TO 5

110 CALL PEEK(-31884,X) X = 0

120 CALL KEY(A,K,S) For A = 3, 4 and 5, KEYSCAN will change >83C6 to 0, 1 or 2 and clear >8374. CALL KEY finishes by clearing >8374, even when A = 1 or 2 (KEYSCAN does NOT do that).

130 CALL PEEK(-31884,Y) Y = 0

140 PRINT X,Y 0 0

150 NEXT A

 

Why are the results 0,0 and even after the program ends >8374 still has zero in it? (This is why I suspect the Console is doing this.)

 

As I said, the console KEYSCAN is doing it when KU = 3, 4 or 5. But, ultimately, CALL KEY is doing it at the end of its routine by clearing >8374. KEYSCAN will not clear >8374 when it finds 1 or 2 there—that's on CALL KEY. You will never find anything but 0 at >8374 after CALL KEY finishes.

 

P.S. Just checked all the XB and RXB source and not a single use of >83C6 anywhere, so that confirms XB or RXB is not using the value there or looks at it.

 

I never said that XB or RXB do anything with >83C6. They only pass information to KEYSCAN through >8374 as you say. It is KEYSCAN that looks at >83C6 when it finds 0 at >8374.

 

...lee

[senior_falcon]

The ROM is completely different in the TI-99/4, which should come as no surprise. It looks like the TI-99/4 does not store anything at >83C6 when doing a keyscan and that the choices for the key unit are 0,1,2. Zero scans the whole keyboard (uppercase only), 1 and 2 look like they do the normal split keyboard scan. So there actually is a keyscan unit of zero, but only in the 99/4. This looks like how they kept compatibility (within the limits of the uppercase only keyboard.)

 

I will say it is a bit perplexing at first when Lee and Tursi talk about using a key unit of 5 when you never see anything but a zero at >8374, but Lee's explanation has cleared up the mystery for me.

[RXB]

Well from a GPL perspective no GPL programs I can find ever use key unit 5 except XB or RXB or other XB variations.

 

And none of them ever set the value to 5 except to check for the type of TI it is running from i.e. TI99 or TI99/4A

 

Besides like I said after the check you can see in the Source code it resets that value back to zero.

 

The CONSOLE ROM is doing it's own thing here.

 

So getting back to the point as before that value has nothing to do with any Cartridge you are running.

 

By the way a standard practice in all the GPL I have seen is to use CLR @>8374 after any KEYSCAN

Edited March 16, 2014 by RXB

[senior_falcon]

As you can see RXB does not even use Key Unit 5 except to check to see if this is 4A console or a TI99 as the 4A has key unit 5 and TI99 does not.

The GPL command:

 

CLR @>8374

 

Is mostly what is used as Key Unit 0 as per page 109 of the Extended Basic Manual quote:

 

"Values of 3, 4, and 5 are reserved for possible future uses."

 

So again why this preference for Key Unit 5?

 

I am just curious as being a GPL programmer for XB and exclusively that for so many years this strikes me as odd that people keep doing this?

Rich, I think I figured out what your stumbling block is. The full title of the manual you are using is "TI Extended BASIC for the TI-99/4 computer". For the 99/4 there were only 3 possible key units: 0,1, and 2. The key unit of zero scanned the entire keyboard, just as you say. Appendix C on page 196 gives the ASCII values available from keyscan. Note that, unlike the 99/4A, the values are 30 to 95 with no lower case characters.

 

For a much better description of KEY on the 99/4A turn to page II-87 in the "User's Reference Guide". This was written for the 99/4A. There you will see that the future uses for values 3,4, and 5 have been implemented and that KEY works the way Lee says it does.

 

Now let's turn to TI INTERN, page 135. Under "Begin BASIC" the code at address g219D is:

219D ST @>8374,>05 Keyboard mode

21A0 SCAN

21A1 code goes on...

 

The only purpose of the SCAN here seems to be to place a 2 (for key unit 5) into >83C6. I can see nothing else that is done with the key value at >8375. Back to the User's Reference Guide, on page II-87, we read: "0 = console keyboard, in mode previously specified by CALL KEY" and since the last scan was in mode 5, that's the mode that the keyboard will be scanned in. And that's how a key-unit of 0 is really a key unit of 5.

 

BTW. the above two lines of GPL code are 4 bytes long. To do that in assembly would take 10 bytes or so. That's quite a savings in memory!

[+Lee Stewart]

I always seem to be pulled up short by forgetting to consult the 16-page addendum that accompanied my TI Extended BASIC for the TI-99/4 Home Computer entitled Important Product Information for TI Extended BASIC! You can find a scanned copy of it at the back of xb.pdf here. It's not OCRed, but it's readable. Here is a relevant excerpt from pp. 4 – 6:

 

 

 

 

CALL KEY SUBPROGRAM

The information given on the KEY subprogram in Chapter 4 of the TI Extended BASIC manual is accurate for the TI-99/4 Computer. The values 3, 4, and 5 are not accessible key units.

However, the TI-99/4A maps key units 0 through 5 to specific modes of operation. If the key-unit is 0, the keyboard is mapped in whichever mode was specified by the previous CALL KEY program line.

If the key-unit is 1, input is taken from the left side of the keyboard. If the key-unit is 2, input is taken from the right side of the keyboard.

A key-unit of 3 maps the computer into the standard TI-99/4 keyboard mode. Both upper- and lower-case characters are returned as upper-case characters only. Function codes 1 through 15 are active, but no control characters are returned.

A key-unit of 4 places the computer in Pascal mode with both upper- and lower-case characters active. The function codes 129 through 143 and the control characters 1 through 31 are also active.

The key-unit 5 maps the TI-99/4A Computer in the BASIC mode. Both upper- and lower-case characters are active. The active function codes are 1 through 15, and the active control character codes are 128 through 159 (and 187).

In addition, codes are assigned to the function and control keys so that these can be referenced by the CALL KEY subprogram in TI Extended BASIC. The codes assigned depend on the key-unit value specified in a CALL KEY program statement.

...

You may also obtain detailed CALL KEY subprogram information, including keyboard diagrams, in your User's Reference Guide for the TI-99/4A Computer.

...lee

[RXB]

I presume that the console keyboard scan routine is used by the compiler. Is that right, Harry?

 

If so, I posted how all this works over in the "Assembly on the 99/4A" topic: http://atariage.com/forums/topic/162941-assembly-on-the-994a/page-11?do=findComment&comment=2848971

 

Regarding restoring the keyboard mode to the entire keyboard (5 for Basic and XB) after scanning the left side (1) or right side(2) with CALL KEY, I would think that restoring 8374h to 5 as the last thing that CALL KEY does is the way the compiler should do it to emulate what XB does. That way when CALL KEY (0,...) is coded by the user, keyboard mode 5 will be used as with XB (see my post above for why this is so).

 

I'm not sure how XB gets the values for CALL JOYST; but, I would guess it also uses KSCAN because KSCAN also checks the actual joystick lines. If that is the case, I would make the same recommendations as the last paragraph.

 

I don't mean to suggest more work for you, Harry, but that is just how the programmers of TI Forth did it and I retained that in fbForth.

 

...lee

XB does not restore the last value it does the same thing GPL always does.

CLR @>8374

 

So the Console must be doing this when GPL KSCAN is called with a XML SCAN Console must be saving that value at >83C6

[senior_falcon]

Yep, the keyscan routine in rom saves the value to >83C6 if it is 3,4 or 5 and fetches the value from >83C6 if (and only if) >8374 is a zero.

[Willsy]

XB does not restore the last value it does the same thing GPL always does.

CLR @>8374

 

It restores the last value by re-setting >8374 to zero. That's it right there. You're looking right at it. The actual value to use is in >83C6. If >8374 is zero, then the value at >83C6 is used. It's as simple as that.

[Gazoo]

spain.txt

 

So I decided to try this compiler for the first time, and I picked what I thought would be an easy program to try it with.

The DV163 text file is attached. It's the music program "Spain". I took out all the lines I thought would be a problem. Still it doesn't compile correctly and gives some errors, they seem to be 'step' commands that use decimals in the step.

 

Any ideas? Or is this just not going to work? I've put in quite a bit of time trying to get this to work and am hesitant to try another program if that's going to throw a lot of errors, too.

 

Gazoo

 

[Retrospect]

spain.txt

 

So I decided to try this compiler for the first time, and I picked what I thought would be an easy program to try it with.

The DV163 text file is attached. It's the music program "Spain". I took out all the lines I thought would be a problem. Still it doesn't compile correctly and gives some errors, they seem to be 'step' commands that use decimals in the step.

 

Any ideas? Or is this just not going to work? I've put in quite a bit of time trying to get this to work and am hesitant to try another program if that's going to throw a lot of errors, too.

 

Gazoo

 

30 FOR X=0 TO A STEP S :: CALL SOUND(-200,B,X,C,E,D,E) :: E=E+1 :: IF E>30 THEN E=30

 

That's the culprit.

 

Instead use this;

 

30 FOR X=0 TO A STEP S :: CALL SOUND(-200,B,X,C,E,D,E) :: E=E+1 :: IF E>30 GOSUB 150

 

150 E=30 :: RETURN

 

When compiling , we can't use and logic after a THEN statement, it needs to branch to a line number .

 

If you still get an error, then maybe use THEN GOSUB ... but im fairly certain simply GOSUB will do. Also check for other THEN statements make sure they follow a line number instead of any logical commands.

Edited March 23, 2014 by Retrospect

[Gazoo]

30 FOR X=0 TO A STEP S :: CALL SOUND(-200,B,X,C,E,D,E) :: E=E+1 :: IF E>30 THEN E=30

 

That's the culprit.

 

Instead use this;

 

30 FOR X=0 TO A STEP S :: CALL SOUND(-200,B,X,C,E,D,E) :: E=E+1 :: IF E>30 GOSUB 150

 

150 E=30 :: RETURN

 

When compiling , we can't use and logic after a THEN statement, it needs to branch to a line number .

 

If you still get an error, then maybe use THEN GOSUB ... but im fairly certain simply GOSUB will do. Also check for other THEN statements make sure they follow a line number instead of any logical commands.

 

That didn't seem to be the problem, but what you suggest might result in nested GOSUBs. Nevertheless, I'll check into it.

Lines 132, 139, and 141 seem to be the troublesome ones.

 

Gazoo

[senior_falcon]

I think Retrospect's fix will work. There are a couple of more direct methods. The lines in question are:

30 FOR X=0 TO A STEP S :: CALL SOUND(-200,B,X,C,E,D,E) :: E=E+1 :: IF E>30 THEN E=30

31 NEXT X :: RETURN

You can invert the logic this way:

30 FOR X=0 TO A STEP S :: CALL SOUND(-200,B,X,C,E,D,E) :: E=E+1 :: IF E<=30 THEN 31:: E=30

31 NEXT X :: RETURN

Or: E=E-(E<30)

If (E<30) is true then it gives a value of -1. If false then the value returned is 0.

BTW,I don't think line 30 will throw an error. You have to be extra vigilant to find stuff like this.

 

Also you have a problem in lines 33,139, and 141 where you use a step value of .5 which rounds down to 0 in integer arithmetic. So you would never be able to exit the loop. Use a value of 1 and you should be OK. That's probably the source of the errors.

 

There are a lot of GOSUBs in your program - it should give the compiler a real workout! Try out those changes and let us know if they work.