Jump to content

Photo

XB Game Developers Package


695 replies to this topic

#676 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,516 posts
  • Location:Lansing, NY, USA

Posted Wed Apr 24, 2019 7:52 PM

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.



#677 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 4,401 posts
  • Location:Portland, Oregon USA

Posted Wed Apr 24, 2019 8:01 PM

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

#678 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,516 posts
  • Location:Lansing, NY, USA

Posted Wed Apr 24, 2019 9:10 PM

Ahh k  

Did that work for you?



#679 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 4,401 posts
  • Location:Portland, Oregon USA

Posted Wed Apr 24, 2019 10:00 PM

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!



#680 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,516 posts
  • Location:Lansing, NY, USA

Posted Sat Apr 27, 2019 10:12 AM

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.



#681 wolhess OFFLINE  

wolhess

    Star Raider

  • 83 posts
  • Location:Germany

Posted Thu May 9, 2019 2:42 AM

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

 



#682 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,516 posts
  • Location:Lansing, NY, USA

Posted Thu May 9, 2019 9:05 PM

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 by senior_falcon, Thu May 9, 2019 9:16 PM.


#683 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,516 posts
  • Location:Lansing, NY, USA

Posted Fri May 10, 2019 8:32 PM

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.



#684 retroclouds OFFLINE  

retroclouds

    Stargunner

  • 1,705 posts
  • Location:Germany

Posted Sat May 11, 2019 10:27 AM

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 ?



#685 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,516 posts
  • Location:Lansing, NY, USA

Posted Mon May 13, 2019 10:55 AM

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.



#686 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,516 posts
  • Location:Lansing, NY, USA

Posted Tue May 14, 2019 12:02 PM

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.



#687 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,516 posts
  • Location:Lansing, NY, USA

Posted Wed May 15, 2019 9:32 PM

 

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.



#688 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,516 posts
  • Location:Lansing, NY, USA

Posted Thu May 16, 2019 9:44 PM

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


#689 wolhess OFFLINE  

wolhess

    Star Raider

  • 83 posts
  • Location:Germany

Posted Thu May 16, 2019 11:32 PM

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

#690 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,516 posts
  • Location:Lansing, NY, USA

Posted Fri May 17, 2019 5:18 AM

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 by senior_falcon, Fri May 17, 2019 5:25 AM.


#691 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,516 posts
  • Location:Lansing, NY, USA

Posted Fri May 17, 2019 8:04 PM

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 by senior_falcon, Sun May 19, 2019 5:01 AM.


#692 wolhess OFFLINE  

wolhess

    Star Raider

  • 83 posts
  • Location:Germany

Posted Sat May 18, 2019 2:35 AM

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 by wolhess, Sat May 18, 2019 4:51 AM.


#693 wolhess OFFLINE  

wolhess

    Star Raider

  • 83 posts
  • Location:Germany

Posted Sat May 18, 2019 5:16 AM

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 by wolhess, Sat May 18, 2019 5:17 AM.


#694 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,516 posts
  • Location:Lansing, NY, USA

Posted Sat May 18, 2019 5:54 AM

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 by senior_falcon, Sat May 18, 2019 6:10 AM.


#695 wolhess OFFLINE  

wolhess

    Star Raider

  • 83 posts
  • Location:Germany

Posted Sat May 18, 2019 2:20 PM


...
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.

#696 wolhess OFFLINE  

wolhess

    Star Raider

  • 83 posts
  • Location:Germany

Posted Sun May 19, 2019 2:15 AM

Now I tested it with the old runtim7 and it returns as expected.
 
I do not see any difference between the two runtime versions.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users