Jump to content

Photo

XB Game Developers Package


364 replies to this topic

#351 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Tue Oct 30, 2018 9:29 PM

Yep, just as I expected. Byte 1 of the PAB was not being cleared after the error and so the second error this causes forces the compiled program to halt. Here is a revised version of RUNTIME7. There are two changes:

The error bug is fixed.

I now reserve >110 bytes for the PAB which should allow a name with a length of up to 255 characters.

Replace RUNTIME7 in the FRAPPATO disk with this one. With any luck this will fix up the problems you are having.

This works in my (not very thorough) testing but it is a good idea to save the old version of RUNTIME7 just in case...

Attached Files



#352 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 3,829 posts
  • Location:Portland, Oregon USA

Posted Wed Oct 31, 2018 1:01 PM

Yep, just as I expected. Byte 1 of the PAB was not being cleared after the error and so the second error this causes forces the compiled program to halt. Here is a revised version of RUNTIME7. There are two changes:

The error bug is fixed.

I now reserve >110 bytes for the PAB which should allow a name with a length of up to 255 characters.

Replace RUNTIME7 in the FRAPPATO disk with this one. With any luck this will fix up the problems you are having.

This works in my (not very thorough) testing but it is a good idea to save the old version of RUNTIME7 just in case...

 

That resolved it!  

Greg



#353 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 3,829 posts
  • Location:Portland, Oregon USA

Posted Wed Oct 31, 2018 3:56 PM

btw.. with the new version on the latest classic99 I get a screen like this (and lockup/beeeeeeee)  when i go to assembler.. i end up running fw from the old version to assemble

 

Attached File  crash.jpg   19.19KB   2 downloads

 

Greg



#354 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Wed Oct 31, 2018 8:52 PM

btw.. with the new version on the latest classic99 I get a screen like this (and lockup/beeeeeeee)  when i go to assembler.. i end up running fw from the old version to assemble

 

Greg

That is a mystery to me. It works fine on my system. I was using QI398 so to be sure I just downloaded the latest version, QI399.004. It works the same - no funny colors and no lockup.

Maybe there is some setting in classic99 that is wrong? Maybe you downloaded a corrupted copy of either Classic99 or my program?

I am using Windows XP. Maybe it is a problem with Windows 10, but I don't see why that would matter.


Edited by senior_falcon, Wed Oct 31, 2018 8:56 PM.


#355 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,322 posts
  • HarmlessLion
  • Location:BUR

Posted Thu Nov 1, 2018 3:04 AM

I develop in Windows 10. If there's a Windows conflict with Classic99, it's from NOT running Windows 10. ;)



#356 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Thu Nov 1, 2018 6:02 AM

I develop in Windows 10. If there's a Windows conflict with Classic99, it's from NOT running Windows 10. ;)

As I remember you thoroughly tested Encruzado and had no problems like this.  



#357 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 3,829 posts
  • Location:Portland, Oregon USA

Posted Thu Nov 1, 2018 6:22 PM

That is a mystery to me. It works fine on my system. I was using QI398 so to be sure I just downloaded the latest version, QI399.004. It works the same - no funny colors and no lockup.

Maybe there is some setting in classic99 that is wrong? Maybe you downloaded a corrupted copy of either Classic99 or my program?

I am using Windows XP. Maybe it is a problem with Windows 10, but I don't see why that would matter.

 

Ok well I had this problem in cl99 older version and in the latest (I downloaded latest and overwrote the dir..)  I'll try first..resetting cl99 to stock (remove the ini) and then second re-downloading the compiler and try that..

 

Greg



#358 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 3,829 posts
  • Location:Portland, Oregon USA

Posted Thu Nov 1, 2018 6:31 PM

 

Ok well I had this problem in cl99 older version and in the latest (I downloaded latest and overwrote the dir..)  I'll try first..resetting cl99 to stock (remove the ini) and then second re-downloading the compiler and try that..

 

Greg

 

It took resetting the ini AND redownloading the package.. /shrug   I can crash again with the old ini..(attached)

Attached Files



#359 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Thu Nov 1, 2018 9:01 PM

 

It took resetting the ini AND redownloading the package.. /shrug   I can crash again with the old ini..(attached)

I tried your ini file and the assembler worked fine. Be sure to check "Write DV80 as windows text". Also it is helpful (but not essential) to "Enable long file names" and "allow more than 127 files"



#360 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,322 posts
  • HarmlessLion
  • Location:BUR

Posted Fri Nov 2, 2018 3:08 PM

I tried your ini file and the assembler worked fine. Be sure to check "Write DV80 as windows text". Also it is helpful (but not essential) to "Enable long file names" and "allow more than 127 files"

 

Both of those options are for directories only. They default to off, and I recommend they not be turned on in the general case, as any software that makes assumptions about the directory will probably crash. (My experience was that long filenames were often tolerated, but more than 127 files was almost always a crash).

 

New software that wants to read the directory in a more flexible manner may open the directory as IV0 rather than IF38 (IF0 was also legal for legacy) -- if it succeeds, you can expect long filenames and a potentially unlimited file count. If it fails, fall back on IF38 and expect the legacy behaviour.

 

https://docs.google....dit?usp=sharing


Edited by Tursi, Fri Nov 2, 2018 3:10 PM.


#361 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Sat Nov 3, 2018 1:19 PM

Tursi knows best. And come to think of it, you'll have trouble if you try to transfer a long filename to a real TI99. 



#362 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,322 posts
  • HarmlessLion
  • Location:BUR

Posted Sun Nov 4, 2018 2:34 PM

Oh, I use long filenames extensively, I just don't recommend letting Classic99 return them in the standard directory reads. Too much software was written with strong assumptions. :)

 

When I first did it I thought it was great, cause the standard TI BASIC directory program worked just fine. Then assembly software started crashing. ;) Having the different open mode lets programs that can deal with long filenames directly ask for them.



#363 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Wed Nov 14, 2018 10:47 PM

I'm excited about a change that is in the works. Currently the bottleneck in the compilation process is the compiler, which is an XB/Assembly hybrid program. I thought it would be too complex to convert it all to assembly, but I figured out how to modify it so that at least the main loops are totally in assembly. Although it is still an XB/Assembly hybrid, there is about a 5x improvement in speed. A program which used to take 60 seconds to compile now takes 12.

I am still in the testing stages at this point.



#364 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 783 posts
  • Location:The Great White North

Posted Yesterday, 7:00 AM

 A program which used to take 60 seconds to compile now takes 12.

I am still in the testing stages at this point.

 

I am curious. Is that compile time in Normal speed or overdrive?  Any idea how many lines are compiled in that time?

 

In normal speed I can't get Forth past 14 lines per second last time I checked. That is using the DSRLINK in Assembler and the wordlist search (linear linked list) in Assembler.



#365 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Yesterday, 9:47 PM

 

I am curious. Is that compile time in Normal speed or overdrive?  Any idea how many lines are compiled in that time?

 

In normal speed I can't get Forth past 14 lines per second last time I checked. That is using the DSRLINK in Assembler and the wordlist search (linear linked list) in Assembler.

This is compiling the BASIC program APERTURE. The modified compiler is now fully functional. Using CPU overdrive on an old Dell Optiplex 780, APERTURE is compiled in 14 seconds with the new version vs 89 seconds with the old version, so the speed increase is more than 6x to fully compile the program.

APERTURE has 506 lines. Running in normal speed compiling it takes 95 seconds which gives 5.3 lines per second. The 506 line XB merge file is read in two passes. The first time through no DATA statements are processed, and the second time through only DATA statements are processed. An assembly source code file of 2068 lines is created during the compilation process. (If you were running this on a real TI99 I think it would be slower; as far as I know Classic99 has faster disk access.)






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users