Jump to content

Photo

XB Game Developers Package


654 replies to this topic

#626 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Tue Apr 9, 2019 11:09 AM

In the compiler there is an option to put the runtime routines into low memory. Are you using that option? It seems to me that if the XB program fits in 32K then the compiled version would also fit.

 

Yes I did place the runtime routines in low memory....

I tried it a couple of times with similar results. You do have a point though, so I'm not sure what's going on here... It is compiling the entire combined program without errors. I am attaching the 2 XB files, STRATHI for the upper memory portion and STRATLO for the lower memory section so you can check for yourself (just strip the .bin extension first). I did follow to the letter your instructions and did not get any errors in the process.

Attached Files



#627 LASooner OFFLINE  

LASooner

    Moonsweeper

  • 401 posts

Posted Tue Apr 9, 2019 4:47 PM

This should not be necessary. You have to check "Write DV80 as windows text." Refer to the manual (there is a screen shot) and be sure the disk is set up properly. If it is then Classic99 it will directly output a standard text file. 

(edit) It isn't the .TXT that makes it a text file, it is checking "write DV80 as windows text".

 

 

you can also add ".?W" to the file name when you compile and it will force it to a text file without having to change it in preferences.



#628 senior_falcon ONLINE  

senior_falcon

    Stargunner

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

Posted Tue Apr 9, 2019 8:09 PM

you can also add ".?W" to the file name when you compile and it will force it to a text file without having to change it in preferences.

That's what happens when you read the manual!

To answer Vorticon's question:

In general the code produced by the compiler is more compact than the original XB code. It usually is around 2/3 the size.

2260 GOTO 2290              (10 bytes in XB)

L2260
       DATA GOTO,L2290      (4 bytes compiled)
*****************************************************************
Even this is not too bad:
1920 FOR J=SX+24 TO SSX-24 STEP 24   (30 bytes in XB)

L1920
       DATA ADD,NV13,NC19,NT1        (30 bytes compiled)
       DATA SBTRCT,NV45,NC19,NT2
FOR21
       DATA FOR,NV41,NT1,NT2,NC19,0,0
*****************************************************************
But as program lines get more complex, things get out of hand:
3500 IF (NT=1 AND NC=0)OR(NT=2 AND NL=0)OR(NT=3 AND NM=0)OR(NT=4 AND NB=0)THEN 3490   (74 bytes in XB)
L3500
       DATA CEQ,NV59,NC2,NT1
       DATA CEQ,NV55,NC17,NT2
       DATA AND,NT1,NT2,NT3
       DATA CEQ,NV59,NC7,NT4
       DATA CEQ,NV56,NC17,NT5
       DATA AND,NT4,NT5,NT6
       DATA CEQ,NV59,NC24,NT7
       DATA CEQ,NV57,NC17,NT8
       DATA AND,NT7,NT8,NT9
       DATA CEQ,NV59,NC32,NT10
       DATA CEQ,NV58,NC17,NT11
       DATA AND,NT10,NT11,NT12
       DATA OR,NT3,NT6,NT13
       DATA OR,NT13,NT9,NT14
       DATA OR,NT14,NT12,NT15
       DATA IF,NT15
       DATA GOTO,L3490
       DATA ENDIF 
(130 bytes when compiled!!!!)

There are a lot of convoluted program lines like this. So it looks like you are just plain running out of memory. The savings in the variables (2 bytes vs 8) are not enough to make up for the bulkier compiled code. I will confess to being surprised by this!



#629 LASooner OFFLINE  

LASooner

    Moonsweeper

  • 401 posts

Posted Tue Apr 9, 2019 8:16 PM

If the variables were in an array and you used a for next loop to accomplish the same thing would it compile the same?

FOR A=1 TO 4
IF NT=A AND N(A)=0 THEN 3490
NEXT A

Just a thought.


Edited by LASooner, Tue Apr 9, 2019 8:17 PM.


#630 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Tue Apr 9, 2019 9:18 PM

Yeah the character definitions are pretty large. Like I said, a valiant effort :)

#631 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Thu Apr 11, 2019 8:54 AM

I've been trying to use XB32K to combine both parts of Stratego minus the character definitions which require disk access, and I'm getting a FILE ERROR IN 450 during the prescan phase of the compilation process. I am by now pretty familiar with how to use XB32K and I'm pretty certain it's not a process error on my part. Attached is the MERGE file for the program. Would you mind looking into it?

Attached Files



#632 senior_falcon ONLINE  

senior_falcon

    Stargunner

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

Posted Thu Apr 11, 2019 7:13 PM

Can you send the two XB programs for high and low memory for this.



#633 senior_falcon ONLINE  

senior_falcon

    Stargunner

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

Posted Fri Apr 12, 2019 5:47 AM

Look at line 3590 and see if there is anything funny about it.

 

Since I cannot look at your program I do not know for sure, but here is what I think is happening.

I see that for memory reasons you are using short variable names and I'm guessing that line 3590 is probably the longest line in the program. When the compiler analyzes a line of code it puts the line into a 256 byte long buffer. It then looks through the line of code looking for variables and constants. If it finds one, it substitutes the appropriate "compiler friendly" variable name. At this point in your program, A,B,C,D might become NV100,NV101,NV102,NV103 which of course makes the line longer. There will be trouble if the line grows to over 255 bytes long.

 

If this is actually what is happening, breaking up the line into two segments should work. If the NV's are in the 100's as described above, simply moving that part of code earlier in the program might work.

 

Send me the XB programs so I can see for myself. There is no practical fix for this, but perhaps a "line too long" error message could be issued.

 

(edit) I think this is wrong. There should not be a problem with exceeding the size of the buffer.


Edited by senior_falcon, Fri Apr 12, 2019 7:23 AM.


#634 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Fri Apr 12, 2019 7:35 AM

Harry, line 3590 belongs to the high memory section of the program and only consists of 

FOR YH=Y-2 TO Y+2 STEP 2

Looking at the Merge file, however, it seems that that line is corrupted somehow, which is interesting... This must be happening during the XB32K process.

Below are the 2 segments of the program. Perhaps you can reproduce that error on your end.

Attached Files



#635 senior_falcon ONLINE  

senior_falcon

    Stargunner

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

Posted Fri Apr 12, 2019 7:29 PM

This works as advertised. Here is a short video showing the procedure. I saved the low memory portion as STRATLOX and the high memory portion as STRATHIX. I then saved in merge format as STRATALL-M. This compiled uneventfully and Asm99 assembled it without error.

You can see that 3590 is OK and that the jump from hi memory code to low memory code is seamless. (100 - 4840 is in high memory; 4850 to 6110 is in low memory)

This will not run in XB. It runs out of memory. You could move almost 3K of additional code into low memory. Maybe then there would be enough ram for your program to run in XB.

 

gallery_34177_1071_55763.gif


Edited by senior_falcon, Fri Apr 12, 2019 8:27 PM.


#636 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Fri Apr 12, 2019 9:24 PM

I think my issue was that I was not pressing F3 to erase the OLD DSK prompt in the compiler environment when starting XB. 

Now the files compile and assemble fine. However, the program crashes when attempting to run it, either in XB or EA. I assume that is because the high memory portion is too large. I'll tinker with it some more tomorrow.



#637 senior_falcon ONLINE  

senior_falcon

    Stargunner

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

Posted Sat Apr 13, 2019 6:19 AM

However, the program crashes when attempting to run it, either in XB or EA. I assume that is because the high memory portion is too large. I'll tinker with it some more tomorrow.

The beauty of compiling an XB program is that you can easily test it in XB to be sure it runs properly. When I tried to run the combined STRATHI and STRATLO I got a "memory full" message. Unless you have moved some program lines into low memory you are unable to test the program in XB. Without that interactive ability things get messy. Is the error in the XB code? Does it fail because of integer arithmetic? Is there a bug in the compiler? Finding where the problem lies can be a challenge.

Another possibility is that you are running out of memory. The XB version reports 1670 bytes of memory left. That should be enough to handle strings and the stack. but maybe not. I think you should get a "memory full" message if that happens. I notice that when I run the program it just returns to XB. I dunno...

 

From the XB32K docs:

If you have selected Extended BASIC from the compiler menu the code for autosave will be running in low memory and if you overwrite it with the XB program it will crash. You can turn it off by pressing F3 at the OLD DSK prompt, or you can enter CALL LINK(“OFF”).
 
I forgot to ask: Earlier you had -1302 bytes of memory left. Now you have 1670 bytes. Where did you find the extra 2972 bytes of memory?

Edited by senior_falcon, Sat Apr 13, 2019 6:33 AM.


#638 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Sat Apr 13, 2019 9:42 AM

I returned the character definitions to disk :)

I know that the program works because I have not made any modifications to it except for splitting it into 2 parts. 

Now here's the interesting part. The program can load in 24K in XB after trimming a few of the CALL SOUND statements, although it won't run, and then it can be compiled in the normal manner without resorting to the XB32K scheme and it works perfectly assuming the runtime routines are loaded in low-memory! I'm not sure why it's floundering with the XB32K process...



#639 senior_falcon ONLINE  

senior_falcon

    Stargunner

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

Posted Sat Apr 13, 2019 3:54 PM

It's hard to know how to help you because this always works for me without any issues.

Here is something to try. You say that after removing some CALL SOUNDs the program can be compiled and will run properly. Take that program which you know works and split it into two segments. Save them as 2 XB programs, let's say STRATLOW and STRATHI. Then create the 2 part XB32K style programs, saving them as STRATLOWA and STRATHIA. Immediately after saving STRATHIA save the merge format file you will be compiling, called STRATALL-M or something similar. Then go to the compiler. You will have to enter DSK!.STRATALL-M and after that things are compiled normally.

Report on your results.



#640 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Sun Apr 14, 2019 7:42 AM

I tried again as you suggested above, with similar results. Everything compiles and assembles fine, and the loader spits out the -X and -Y files as it should. However, when I attempt to run the program, it just exits back to XB. Below are the files. Please give them a try and see of you can replicate my problem. Either its a user error somewhere on my part (very possible despite my best efforts) or XB32K does not like my program...

 

EDIT: It WAS a user error! I had forgotten to place the character definition file in the same disk location as the program, so the latter was crashing. However, there is still an issue. There is corruption in the text window during a battle as shown below: 

 

Attached File  Stratego.gif   136.79KB   0 downloads

 

And this is related to this section of code: 

RESTORE char_ass
FOR J=1 TO DN::
	READ C1,C2::
NEXT J::
DC1=C1::
DC2=C2

IF ATTACKER=1 THEN
	CALL CHARPAT(AC1,C1$,AC2,C2$) ..
ELSE
	CALL CHARPAT(DC1,C1$,DC2,C2$)

CALL CHAR(142,C1$,143,C2$)::
CALL COLOR(14,9,2)

IF ATTACKER=1 THEN
	CALL DRAWPIECE(6,22,142,143,58,59,60,61)::
	CALL DRAWPIECE(25,22,DC1,DC2,120,121,122,123)

IF ATTACKER=2 THEN
	CALL DRAWPIECE(6,22,AC1,AC2,120,121,122,123)::
	CALL DRAWPIECE(25,22,142,143,58,59,60,61)

The DATA statement this code refers to is in the high portion of the program, while the code itself resides in the low portion....

Attached Files



#641 senior_falcon ONLINE  

senior_falcon

    Stargunner

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

Posted Sun Apr 14, 2019 10:15 AM

What you sent me is something that is not useful for testing. What I need is for you to take a program that can be loaded into high memory (and preferably that can be compiled and run), then split it into two parts and save them as STRATHI and STRATLO. I need to be able to save these two in merge format, then start with NEW and MERGE DSK1.STRATHI-M and MERGE DSK1.STRATLO-M, so as to be able to get back to your original program.  want to compare the program you get when it is all in high memory with the program you get when it is split between high and low memory. They should be the same.



#642 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Sun Apr 14, 2019 12:10 PM

OK here you go. The only difference from before is 6 CALL SOUND statements less...

STRATALL is the entire program which fits in the upper 24K and compiles and runs normally.

STRATHI and STRATLO are the same program split into 2 sections.

Let me know how you fare :)

Attached Files



#643 senior_falcon ONLINE  

senior_falcon

    Stargunner

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

Posted Sun Apr 14, 2019 1:40 PM

I took STRATHI and STRATLO and saved them as the merge files STRATHI-M and STRATLO-M. I then typed NEW, then merged STRATHI-M and STRATLO-M. This restores the entire program. Saved this as STLANDH-M. I then used XB32K to make a 2 part program with STRATLO in low memory and STRATHI in high memory. Saved this as ST32K-M. I also took your STRATALL and saved it in a merge format. These three programs should be identical. It's easy enough to compare; this program will do the trick:

5 LN=90
10 OPEN #1:"DSK1.STLANDH-M"
20 OPEN #2:"DSK1.ST32K-M"
30 LINPUT #1:A$ :: LINPUT #2:B$ :: LN=LN+10
40 IF A$=B$ THEN GOTO 30
50 PRINT LN :: GOTO 30

Sure enough, those two programs were identical. Then I compared STRATALL-M and ST32K-M. There were 3 differences in lines 5200, 5220, and 5560

In the original program these were RESTORE 2320

In the broken up program these were RESTORE CHAR-ASS

Perhaps TidBit did this?

 

(Edit) - If you had arranged the sections of code so more was put into low memory then you probably could have had enough memory to run this in XB. and debugging would have been a whole lot simpler.


Edited by senior_falcon, Sun Apr 14, 2019 1:50 PM.


#644 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Sun Apr 14, 2019 4:04 PM

Ah Ha!!! I see what is happening now. When I split the original TidBiT code into 2 parts, the label char_ass found itself in the upper memory portion. So when the lower memory portion was converted to plain XB by TidBiT, the latter could not reference char_ass correctly and so did not replace it with a line number, hence the issue with the character definitions.

Harry you are a genius!



#645 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 10,733 posts
  • Location:Hustisford, WI

Posted Sun Apr 14, 2019 7:09 PM

The sheer awesomeness of this is mind blowing. You guys are doing groundbreaking stuff here. :)

Still..... I can't help wonder what CHAR-ASS looks like.

#646 senior_falcon ONLINE  

senior_falcon

    Stargunner

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

Posted Sun Apr 14, 2019 7:37 PM

 I can't help wonder what CHAR-ASS looks like.

I wondered that myself.



#647 senior_falcon ONLINE  

senior_falcon

    Stargunner

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

Posted Sun Apr 14, 2019 7:39 PM

Ah Ha!!! I see what is happening now. When I split the original TidBiT code into 2 parts, the label char_ass found itself in the upper memory portion. So when the lower memory portion was converted to plain XB by TidBiT, the latter could not reference char_ass correctly and so did not replace it with a line number, hence the issue with the character definitions.

 

Can I send you the docs for XB32K so you can add the necessary information so that others know how to avoid this? Is ODT format OK? 


Edited by senior_falcon, Sun Apr 14, 2019 7:41 PM.


#648 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Sun Apr 14, 2019 8:26 PM

Char-ass points to very sexy DATA statements and is short for character association. But hey, feel free to fantasize! :)
Harry, what information exactly are referring to for the XB32K manual?

#649 senior_falcon ONLINE  

senior_falcon

    Stargunner

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

Posted Sun Apr 14, 2019 8:39 PM

Explaining this in a way that helps others avoid this pitfall:

 

"When I split the original TidBiT code into 2 parts, the label char_ass found itself in the upper memory portion. So when the lower memory portion was converted to plain XB by TidBiT, the latter could not reference char_ass correctly and so did not replace it with a line number, hence the issue with the character definitions."



#650 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Mon Apr 15, 2019 9:07 AM

Sure. Just send me the file.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users