XB Game Developers Package

[+Vorticon]

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.

STRATHI.bin

STRATLO.bin

[LASooner]

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.

[senior_falcon]

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 are not enough to make up for the bulkier compiled code. I will confess to being surprised by this!

[LASooner]

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 April 10, 2019 by LASooner

[+Vorticon]

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

[+Vorticon]

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?

STRATHIA-M.bin

[senior_falcon]

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

[senior_falcon]

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 April 12, 2019 by senior_falcon

[+Vorticon]

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.

STRATLO.bin

STRATHI.bin

[senior_falcon]

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.

 

Edited April 13, 2019 by senior_falcon

[+Vorticon]

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.

[senior_falcon]

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 April 13, 2019 by senior_falcon

[+Vorticon]

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

[senior_falcon]

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.

[+Vorticon]

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:

 

 

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

STRATHI.bin

STRATLO.bin

[senior_falcon]

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.

[+Vorticon]

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

STRATALL.bin

STRATHI.bin

STRATLO.bin

[senior_falcon]

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 April 14, 2019 by senior_falcon

[+Vorticon]

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!

[Opry99er]

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.

[senior_falcon]

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

I wondered that myself.

[senior_falcon]

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 April 15, 2019 by senior_falcon

[+Vorticon]

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?

[senior_falcon]

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

[+Vorticon]

Sure. Just send me the file.