Jump to content

Photo

XB Game Developers Package


315 replies to this topic

#301 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Tue Aug 7, 2018 9:14 PM

I feel like a pain...

I am getting an assembler error SYMBOL TRUNCATION. While compiling XB256.  I am only using DISPLY so far in this app.

 

I tried shrinking variable size, but I still get the error. If I remove the DISPLY lines, it compiles in normal XB no errors.

 

I searched for the error in the docs and in this tread, but didn't get a hit.

You're not being a pain at all! But  I don't believe your problem is with DISPLY. I compiled this program and it worked the same in XB and compiled, with no errors and no problems:

3 CALL CLEAR
5 XTR=3
10 CALL LINK("DISPLY",10,1,"EXTRA"):: CALL LINK("DISPLY",11,1,STR$(XTR))

The "SYMBOL TRUNCATION' should be accompanied by a line number. That number refers to the line of the source code created by the compiler, not the line number in the XB program.

Take a look at the source code and you should be able to find out what the XB line number is. (Line 200 compiles to L200) See if you can see a problem in that line. If you can't find it, send me a copy of the XB program and I will have a look.

 

 


#302 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Tue Aug 7, 2018 10:11 PM

(RXB in post 298)

Example in XB (from 1980gamer)

XTR=3

DISPLAY AT(10,1):"EXTRA" :: DISPLAY AT(11,1):XTR

vs

CALL LINK("DISPLY",10,1,EXTRA) :: CALL LINK("DISPLY",11,1,XTR)

 

Looks like a SCREEN offset problem to me. I cannot imagine why this would look like a screen offset problem to anyone!

I could be wrong, (you are) I do not use XB256 as it is not compatible with RXB just XB.(It is, just not with the new features.)

 

Sorry you know the Title is XB Game Development Package, I guess it should be titled:  XB256 Game Development Package ONLY.

Rather misleading that anyone with anything else can be involved. People can chime in with whatever they want. But you seem to respond to virtually every post involving BASIC or XB with a list of RXB features which are frequently not relevant in solving the problem being discussed. 

 

This happens often in other threads that get off topic, but I never complained when it happened to me, now why is that? Threads always get off topic. That's fine and to be expected. I get it - you are proud of RXB and rightly so! I'm just saying that before responding to a post try asking yourself: is my response actually relevant to the question asked, or is it just another advertisement for RXB. For example, if the post is about MiniMemory, it is not likely that a solution requiring RXB would be useful.


Edited by senior_falcon, Tue Aug 7, 2018 10:11 PM.


#303 RXB OFFLINE  

RXB

    River Patroller

  • 3,238 posts
  • Location:Vancouver, Washington, USA

Posted Tue Aug 7, 2018 10:55 PM

Hmm TI Basic, Mini Memory and XB all have GPL which is a thread they all have in common, and XB256 is using that as a base to build upon.

So getting ideas from other strictly unlike sources is how anything is created or discovered.

 

And though may not be relevant to you personally I doubt you speak for everyone everywhere.

Thus I defer to you on this forum post. 



#304 1980gamer OFFLINE  

1980gamer

    Dragonstomper

  • 918 posts
  • Location:Charlton, MA

Posted Wed Aug 8, 2018 5:22 AM

The error was in line one.   That is the name of the file.

 

I was saving as NECXB256  I changed to NEC256 and it worked fine.

 

So it looks like 7 chars is to big.  I didn't try 6 yet.  I used to only use 4 in the older version.  IE NEC1-C would be the end result.

But with the new version and the File name auto passed through, I was less concerned with making the file name changes at every step.

 

Thanks for the help!   I need to XB256 the rest of the program now.  That is remove the call sounds I was using to slow things down and use DELAY instead etc.

It had been to long since I last worked on anything.  It is coming back to me now....


  • RXB likes this

#305 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Wed Aug 8, 2018 5:44 AM

The error was in line one.   That is the name of the file.

 

I was saving as NECXB256  I changed to NEC256 and it worked fine.

 

So it looks like 7 chars is to big.  I didn't try 6 yet.  I used to only use 4 in the older version.  IE NEC1-C would be the end result.

But with the new version and the File name auto passed through, I was less concerned with making the file name changes at every step.

 

Thanks for the help!   I need to XB256 the rest of the program now.  That is remove the call sounds I was using to slow things down and use DELAY instead etc.

It had been to long since I last worked on anything.  It is coming back to me now....

I don't see why that would matter. You should be able to have 10 byte long file names (15 if you count the DSK1.) Can you post the first few lines?

 

For what it's worth, I don't like DELAY. The computer does nothing when it is DELAYing. If it is part of a game loop it is much better if you can use CALL KEY or something else that is useful. 


Edited by senior_falcon, Wed Aug 8, 2018 5:49 AM.

  • RXB likes this

#306 1980gamer OFFLINE  

1980gamer

    Dragonstomper

  • 918 posts
  • Location:Charlton, MA

Posted Wed Aug 8, 2018 3:16 PM

Attached are the 2 files.  Working and Non-working.

 

The Delay is only used in NON-Action points.  I am using Call sound to pause now.  But it is easy to just set the duration.

 

I only changed the file name.

 

nec256 works necXB256 does not.

 

Attached Files



#307 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Wed Aug 8, 2018 9:53 PM

Here is the source code for two compiled programs. On the left is my 256DEMO and on the right is your NECXB256.

Why are they so very different from each other?? What is NECXB256.T doing at the top of the right hand one? Some possibilities are:

1 - You are not setting up the game developer's package as described in the docs.

2 - The docs do not properly describe how to set it up. (But when I follow them it works fine.)

3 - Something about Windows 10 is messing up the file when you save it, or is messing up the proper execution of Classic99.

4 - something else...

Start with a small program: 10 PRINT "HELLO WORLD" and experiment until you find a combination that produces source code like you see on the left.

I have never had problems like this and so do not have any more ideas. Until you do this I don't think it can ever work as designed.

 

gallery_34177_1100_47128.jpg


Edited by senior_falcon, Wed Aug 8, 2018 9:55 PM.


#308 1980gamer OFFLINE  

1980gamer

    Dragonstomper

  • 918 posts
  • Location:Charlton, MA

Posted Thu Aug 9, 2018 4:44 AM

Okay,  So, the only thing I did was save to DSK1 vs DSK2.  Also the name from NEC256 to NEC25 to tell them apart.

It is formatted properly.

 

       DEF RUNEA,RUN,RUNV,CON
RUNEA  B @RUNEA5
FRSTLN
L10
       DATA CLEAR
L20
       DATA SCREEN,NC1
L30
L110
       DATA RESTOR,L40
FOR1
       DATA FOR,NV1,NC2,NC3,ONE,0,0
       DATA READ,NV2,NV3,NV4
       DATA COLOR,NV2,NV3,NV4
       DATA NEXT,FOR1+2
 



#309 1980gamer OFFLINE  

1980gamer

    Dragonstomper

  • 918 posts
  • Location:Charlton, MA

Posted Thu Aug 9, 2018 4:54 AM

So, in DSK2  I have V9T9 Headers and No Long Filenames.  The file names may be the truncation piece?

 

Anyway,  I copied the Classic99 folder, all setting etc.  from my prior laptop.  I never had issues in the past.

I did move from V9T9 way back when. Actually, I used a different EMU before classic99...  Can't remember the name,  99Siim or something like that.

 

The crazy thing is, before the longer file name, my compiling worked fine, even though it was structured so differently.

( That is, After fixing the WIN10 security settings )



#310 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Thu Aug 9, 2018 8:22 AM

When I read it, what you have posted as NEC256.TXT begins like this:

NEC256.TXT##�##�P�##############################################################################################################
DEF RUNEA,RUN,RUNV,CON#RUNEA B @RUNEA5#FRSTLN#L10# DATA
CLEAR#L20# DATA SCREEN,NC1#L30#L110# DATA
RESTOR,L40#FOR1# DATA FOR,NV1,NC2,NC3,ONE,0,0# DATA
READ,NV2,NV3,NV4# DA

This is not the same as what you get in post #308. Somehow what you have posted as NEC256 will assemble, but I sure don't know how it can.

I think the problem is that you are saving using V9T9 format. All my files Use TIFILES and in the manual Tursi says:  "Classic99 considers the V9T9 file format to be deprecated." Use FIAD and TIFILES for everything. I'm not sure if the .TXT extension means that you need to enable long filenames but it won't hurt.
 



#311 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Thu Aug 9, 2018 6:03 PM

Well, that theory is disproved. I just checked and found that if you check "Write V9T9 headers" the results seem no than when using "TI files headers".

I also tried using a long file name, 10 characters in length plus the .TXT extension with V9T9 checked and it too compiled properly

I am out of ideas as to why your results are different than mine.

Download the NECXB256 that you posted above and look at it with a text editor. Does it look normal or does it look like it does in post #307 above.

 

 

See below.


Edited by senior_falcon, Thu Aug 9, 2018 9:11 PM.


#312 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Thu Aug 9, 2018 8:16 PM

I was finally able to duplicate the results you are getting by checking "Write V9T9 headers", unchecking "Write DV80 as windows text" and unchecking "Enable long filenames."

Classic99 will only save in windows format if you have checked "Write DV80 as windows text". Adding the .TXT extension will not save in windows format. When you want to open the file, the TXT extension helps windows know what program is needed to open it.

So it looks like the problem was with the documentation.

 

Any disk that will be used by the compiler must be set just like DSK1 as described in Using XBGDP. 

 

gallery_34177_1100_5880.jpg

 



#313 1980gamer OFFLINE  

1980gamer

    Dragonstomper

  • 918 posts
  • Location:Charlton, MA

Posted Fri Aug 10, 2018 4:41 PM

Wow, that is investigating above and beyond the call...

I have added a new DSK with the recommended config.  I'll eventually migrate everything over to the correct formatting.

 

Also, I am amazed how much faster your IRND is over RND  Very Impressive.



#314 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Fri Aug 10, 2018 7:57 PM

There was a big discussion a few years back regarding the relative speeds of RND in BASIC and XB, with XB being dramaticly slower. (I remember it being around 5x slower!) Rich modified RXB so it would use the faster TI BASIC random number generator. KALEIDOSCOPE runs much faster with the faster random number generator. As I recall it was 2-3x faster. This program makes very heavy use of RND and most would not benefit so much, but nevertheless, the speed increase is surprising.

After finding this out (thank you Rich!) I developed IRND to generate random numbers they way you would in XB with INT(RND*6) but done entirely in assembly. To minimize the overhead you can generate up to 8 random numbers per CALL LINK("IRND")

The main benefit comes when running in XB256. Because they both use the same random number generator, in a compiled program IRND probably doesn't have much speed advantage over RND


Edited by senior_falcon, Fri Aug 10, 2018 8:01 PM.


#315 RXB OFFLINE  

RXB

    River Patroller

  • 3,238 posts
  • Location:Vancouver, Washington, USA

Posted Fri Aug 10, 2018 11:06 PM

Thank you.



#316 1980gamer OFFLINE  

1980gamer

    Dragonstomper

  • 918 posts
  • Location:Charlton, MA

Posted Sat Aug 11, 2018 7:56 PM

I didn't time RND vs IRND just the eye test....

 

But I need to get 15 distinct random numbers to build a slide puzzle.  It is certainly much faster.  XB256 and compiled.

 

1 thing I didn't consider until now...  Distinct numbers. Maybe IRND doesn't repeat values as often as RND?  I test for uniqueness after each value.

 

Whatever the reason... I really like it. If the puzzle is not solvable, I rebuild it.  It makes a big difference.


  • RXB likes this




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users