XB Game Developers Package

[senior_falcon]

You should set up XBGDP as suggested above, but that is not the problem. I believe what is happening is that you are pressing "Y" for "Assembling with Asm994a?" but then are assembling with the TI assembler. The error you are getting is because the assembler cannot find RUNTIME1.TXT. If you answered "N" for "Assembling with Asm994a?" then you would be prompted for a disk number and if the assembler couldn't find the runtime routines the error would have a DSK in it, like "DSK1.RUNTIME1.TXT".

If you are answering "N" and getting the "RUNTIME1.TXT" error then there is an error in the compiler program.

[+arcadeshopper]

You should set up XBGDP as suggested above, but that is not the problem. I believe what is happening is that you are pressing "Y" for "Assembling with Asm994a?" but then are assembling with the TI assembler. The error you are getting is because the assembler cannot find RUNTIME1.TXT. If you answered "N" for "Assembling with Asm994a?" then you would be prompted for a disk number and if the assembler couldn't find the runtime routines the error would have a DSK in it, like "DSK1.RUNTIME1.TXT".

If you are answering "N" and getting the "RUNTIME1.TXT" error then there is an error in the compiler program.

Ahh k

 

Sent from my LM-G820 using Tapatalk

[senior_falcon]

Ahh k

Did that work for you?

[+arcadeshopper]

Did that work for you?

I will try when I get home

 

ok well didn't have time to try when i got home so trying now at work

 

set my settings. said no, DSK1 for runtime was asked..

 

yep that was it thanks!

[senior_falcon]

If you downloaded ISABELLA4, you should replace it with the new version in post 1 or post 667. When I posted earlier, I did not include the licensing agreement for Asm994a which Burrsoft says must be included.

[wolhess]

Hello Senior_Falcon,

 

I created my first XB program after more than 30 years and used your XB compiler. It's great, what speed can be achieved,
so the time for the program start of> 3 min. shortened to about 20 sec.

 

Thanks again for this tool.

 

When I switched to a version compatibel with the compiler, I noticed some issues I did not find in the description:

 

Using DIM A$(X) Variables:

 

1. ACCEPT AT (10,1): A$(X) does not work!

This is compiled without error, but when the program reaches the command, the computer locks up.

- Workaround
ACCEPT AT (10,1):B$ :: B$=A$(X)

 

2. CALL DP(A$(X),D$,P$) does not work!

This is compiled without error, but when the program reaches the command, the computer locks up.

- Workaround
B$=A$(X)::CALL DP(B$,D$,P$)

 

ACCEPT AT COMMAND

 

DISPLAY AT (24,1):”Continue (Y/N):Y” :: ACCEPT AT(24,16)SIZE(-1)X$

 

If you enter in XB a “N” or a “Y” you will hear a BEEP
In the compiled version you will hear a HONK. That irritated me when testing.

 

OPEN COMMAND

 

ON ERROR 1000

OPEN #1:”DSK1.PROGRAM”,INPUT,DISPLAY,VARIABLE

LINPUT #1:X$

CLOSE #1

 

If the file does not exist you get no error message and ON ERROR 1000 is not working.
The program continues with reading something from memory or the computer locks up.

 

- Workaround
If I need a data file the program creates the file and stores the filename in a log file.
Before I use file name in the OPEN statement, I look in the log file. If the program name exits,
the program continues and if not the program creates the new file and stores the new name in the log file.

 

Maybe you can add these hints in the documentation of your next version.

 

regards

 

Wolfgang

 

[senior_falcon]

I am looking into these issues. Only one answer for you so far:

 

ACCEPT AT COMMAND

DISPLAY AT (24,1):”Continue (Y/N):Y” :: ACCEPT AT(24,16)SIZE(-1)X$

If you enter in XB a “N” or a “Y” you will hear a BEEP

In the compiled version you will hear a HONK. That irritated me when testing.

This happens because the compiler uses the TI BASIC line editor and not the XB line editor. The difference is just what you heard - when the XB line editor comes to the end of the line it gives a "beep" of around 1400 Hz. When the BASIC line editor comes to the end of the line it gives a "honk" of 220 Hz.

Run this in TI BASIC. Hold down a key until the cursor reaches the end of the line and you hear the honk. Press enter and you'll hear the same honk 220 Hz. If you run it in XB, you will find that a frequency of 1400 Hz matches the beep.

10 INPUT A$

20 CALL SOUND(500,220,0) (or 1400 in XB)

This could be avoided if the compiler used the XB line editor, but then you would lose EA5 compatibility. The line editor could be duplicated within the compiler, but that would waste a bunch of memory to address what is a minor discrepancy. I guess the best fix is to add a description of this quirk to the docs.

Now to figure out the other two issues....

(edit) It looks as if the line ACCEPT AT (10,1):B$ :: B$=A$(X) compiles correctly. The error appears to be in the runtime routines. I will have to see why that is.

Edited May 10, 2019 by senior_falcon

[senior_falcon]

Making some progress:

 

1. ACCEPT AT (10,1): A$(X) does not work!

The subroutine that finds the address of an array was modifying the value at >8320. This is needed for the GPL input routine used by INPUT and ACCEPT. This has been fixed.

 

2. CALL DP(A$(X),D$,P$) does not work!

This worked for me in my short test, but then there was some odd behavior after returning from the subprogram. I will work some more on this.

[+retroclouds]

If you downloaded ISABELLA4, you should replace it with the new version in post 1 or post 667. When I posted earlier, I did not include the licensing agreement for Asm994a which Burrsoft says must be included.

 

senior_falcon you might consider switching to Ralphs' xas99 ?

[senior_falcon]

2. CALL DP(A$(X),D$,P$) does not work!

This worked for me in my short test, but then there was some odd behavior after returning from the subprogram. I will work some more on this.

Still wrestling with this. I hope to have some answers in the next couple of days.

[senior_falcon]

There is something very subtle going on here. I have written a simple test program called TEST-X. If you do a cold reset and load TEST-X it will crash in the subprogram or immediately upon return. If you do a cold reset, then load the compiler (which is a long XB program) and then load and run TEST-X it returns from the subprogram just fine but you cannot break the program with Fctn 4. I added a couple of lines to the subprogram to help debug and now it runs exactly as it should. (which it always did in my pre-release testing.)

I don't yet know why this is, but have patience-I am close to understanding what is happening.

[senior_falcon]

 

Using DIM A$(X) Variables:

 

1. ACCEPT AT (10,1): A$(X) does not work!

This is compiled without error, but when the program reaches the command, the computer locks up.

 

I finally was able to get some traction on this and my test program works properly. I am hopeful that this fix has not broken something else. I will test thoroughly tomorrow.

[senior_falcon]

The problem using DIM A$(X) Variables seems to be fixed. Now for the problem with the OPEN COMMAND:

-----------------------------------------------------------------------------------------------------------------------------------------

"OPEN COMMAND

ON ERROR 1000

OPEN #1:”DSK1.PROGRAM”,INPUT,DISPLAY,VARIABLE

LINPUT #1:X$

CLOSE #1

If the file does not exist you get no error message and ON ERROR 1000 is not working.

The program continues with reading something from memory or the computer locks up."

-----------------------------------------------------------------------------------------------------

From the manual:

Error checking should be set up just like in XB with the following limitations:

ON ERROR line number - transfers control to the desired line number

If you are not using ON ERROR and an error is encountered:

-If running from an XB loader, the program will end and return to the line editor. No disk error

message is printed.

-If running as an EA5 program the program will return to the master title screen.

RETURN line number – this only works to return to a specific line number. Do not use

RETURN or RETURN NEXT

The program below works as described in the manual. The file does not exist, so OPEN causes an error sending the program to line 1000. This prints "DISK ERROR", then RETURNs to line 200 which prints "LINE 200" and then ends. RETURN must be to a line number.

If you remove line 10 and run the program, when the error is encountered the program returns to the line editor with no error message as described in the manual.

10 ON ERROR 1000
20 OPEN #1:"DSK1.PROGRAM",INPUT ,DISPLAY ,VARIABLE 80
30 LINPUT #1:X$
40 CLOSE #1
200 PRINT "LINE 200" :: END
1000 PRINT "DISK ERROR"
1001 RETURN 200

[wolhess]

Hello,

 

Thank you for your time and support.

 

I had tracked the problem with "open" in my program and had reached the row number 1000 in XB, but not in the compiled version. Maybe that's because my DSK1. Is a mapped TIPI drive. I'll try that again with my physical DSK2.

 

Wolfgang

[senior_falcon]

Yes, check whether it works with a physical drive. If it works there but not on the TIPI then at least we have a starting point for how to fix this issue.

 

(edit) Here is the section of code that looks for a disk error. Maybe more is needed?

 

BLWP @DSRLNK (this uses millers graphics dsrlnk)

DATA 8

JEQ GODSRE if EQ then there was an error

Edited May 17, 2019 by senior_falcon

[senior_falcon]

Try replacing the old RUNTIME7.TXT with this one. This checks more thoroughly for errors and perhaps it will work on TIPI.

 

(edit) Works the same.

Edited May 19, 2019 by senior_falcon

[wolhess]

Can I simple rename the runtime7 for using in my real System?

 

I converted the txt runtime file and it works on the real TI!

Edited May 18, 2019 by wolhess

[wolhess]

Hello Senior_Falcon,

my OPEN problem is homemade!

In my ERROR routine I have used CALL ERR (C, T, G, Z) to intercept different situations depending on line number.

CALL ERR () does not generate an error message in the assembler, but the compiled program stops, so a RESET is required.
This happens in the TIPI mapped DSK1. same as in the physical DSK2. Even with the new runtime7 there is no difference.

If I use my program without Call ERR, then the program runs as expected!

Sorry for the inconvenience!

Here is my test program:

100 CALL CLEAR

110 ON ERROR 1000

120 OPEN # 1: "DSK1.TEST", INPUT, DISPLAY, VARIABLE

130 LINPUT # 1: X$

140 CLOSE # 1

150 PRINT "LINE 150" :: END

1000 PRINT "DISK ERROR"

1010! CALL ERR (C, T, G, Z)

1020! PRINT "IN LINE:"; Z

1030 RETURN 150

Without lines 1010 and 1020 everything is OK!

Edited May 18, 2019 by wolhess

[senior_falcon]

Not your fault! As you discovered, CALL ERR is not supported. This should have stated in the docs, but somehow I overlooked it - probably because I have never used this subprogram. I will edit the docs to describe this properly.

If you eliminate the lines with CALL ERR, does the original RUNTIME7 detect the error and send the program to line 1000? Or do you need the more recent version I posted yesterday?

 

(Edit) I see why the assembler didn't issue an error message for this. The label ERR is used in another part of the code, so the compiled code just assumes you want to go to this address and crashes when it gets there. I will modify the code so that CALL ERR doesn't crash, probably by bypassing CALL ERR entirely.

Edited May 18, 2019 by senior_falcon

[wolhess]

 

...

If you eliminate the lines with CALL ERR, does the original RUNTIME7 detect the error and send the program to line 1000? Or do you need the more recent version I posted ...

 

I had tested with the new runtim7. I like to use the old runtime again tomorrow. Then we see if there is a difference.

[wolhess]

Now I tested it with the old runtim7 and it returns as expected.

I do not see any difference between the two runtime versions.

[senior_falcon]

Here is ISABELLA5 which addresses the issues that Wolfgang found above. The changes include:

Fixed a bug that caused a crash when inputting an array element with ACCEPT AT. Fixed a bug that caused problems passing an array element to a subprogram. When using ACCEPT AT with SIZE, the XB source program will "beep" when reaching the right hand boundary. The compiled version will 'honk". This is a side effect from using the console text editor and is not practical to change. The behavior is noted in the manual. CALL ERR is not supported by the compiler and the docs have been revised to describe this.

ISABELLA5.zip

[+TheBF]

 

Here is ISABELLA5 which addresses the issues that Wolfgang found above. The changes include:

Fixed a bug that caused a crash when inputting an array element with ACCEPT AT. Fixed a bug that caused problems passing an array element to a subprogram. When using ACCEPT AT with SIZE, the XB source program will "beep" when reaching the right hand boundary. The compiled version will 'honk". This is a side effect from using the console text editor and is not practical to change. The behavior is noted in the manual. CALL ERR is not supported by the compiler and the docs have been revised to describe this.

 

 

This is a very nice piece of work Senior_Falcon. May I ask what language you wrote it in?

 

(I am noodling away on a compiler that converts Forth source code to machine code so my respect has for your work grown)

Edited May 30, 2019 by TheBF

[senior_falcon]

 

This is a very nice piece of work Senior_Falcon. May I ask what language you wrote it in?

 

(I am noodling away on a compiler that converts Forth source code to machine code so my respect has for your work grown)

The compiler was written in XB with a LOT of XB subprograms to make the speed bearable. Recently I converted it to almost straight assembly language which boosted the speed about 5x.

The way I did it is faster, but my original intention was to write the compiler in XB and then compile the compiler. It is a cool idea but didn't work out that way.

[wolhess]

Hi Senior_Falcon,

 

Thank you for providing the version 5 of Isabella!

 

To upgrade to Isabella5 do I have to use all the files from the new package or can I simply copy the RUNTIME files?

 

I changed some Files e.g. LOAD and COMPILER for using on "DSK3.", because my programs are using always "DSK1."

and they look there for the program config files.

 

 

 

Is there a way to use the XB256 / LOAD flexibly from DSK2 or DSK3?

At every compiler run, I have to change the DSK1.LOAD to DSK3.LOAD.

 

 

The first time I use it, the compiler looks for the RUNTIME files on DSK2 instead of DSK3.

But this is correct for the second and further compiler run on DSK3.

 

 

I would wish that the compiler can be consistently start from "DSK3." with all the default settings for compiler and assembler.
Only the program should be set of DSK1 or variable as it does.

 

Wolfgang