Jump to content

Photo

XB Game Developers Package


361 replies to this topic

#351 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,260 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 ONLINE  

arcadeshopper

    River Patroller

  • 3,820 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 ONLINE  

arcadeshopper

    River Patroller

  • 3,820 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,260 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,260 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 ONLINE  

arcadeshopper

    River Patroller

  • 3,820 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 ONLINE  

arcadeshopper

    River Patroller

  • 3,820 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,260 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,260 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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users