XB Game Developers Package

[+Vorticon]

Thank you for providing the new version.

 

I will test it tomorrow.

 

The response times are much better than in the basic version, time for a few more Stratego games.

 

Thank you! It's hard for me to be objective because I am obviously intimately familiar with the AI's workings.

Barring any compiler-related issues, I'm going to move that discussion to the dedicated Stratego thread and will be updating the files and manual there after I hear back from you.

 

I have to say that this project has eminently demonstrated the power of the XB compiler even with very complex programs, allowing the programmer to freely use XB for its ease of programming, especially when coupled with Matthew180's TIdBiT, then end up with an assembly-speed final product.

[+TheBF]

 

Thank you! It's hard for me to be objective because I am obviously intimately familiar with the AI's workings.

Barring any compiler-related issues, I'm going to move that discussion to the dedicated Stratego thread and will be updating the files and manual there after I hear back from you.

 

I have to say that this project has eminently demonstrated the power of the XB compiler even with very complex programs, allowing the programmer to freely use XB for its ease of programming, especially when coupled with Matthew180's TIdBiT, then end up with an assembly-speed final product.

 

Some credit has to go to you for pushing the envelope as well.

 

This caused a "rise to the occasion" response so the combination has been wonderful to observe. Truly outstanding IMHO.

 

Congratulations to all involved.

 

Now about creating "an Assembly-speed final product" … I suspect some Assembly language coders would beg to differ.

[+Vorticon]

OK so maybe near-assembly speed There is no question that nothing can match the power and flexibility of pure assembly language, but for complex projects, it can be extremely time-consuming. I have a half-finished science fiction wargame programmed entirely in assembly that's been sitting idle for years now because I can't bring myself to re-familiarize myself with the massive code (Ultimate Planet - http://atariage.com/forums/topic/162102-ultimate-planet/page-1?hl=+ultimate%20+planet ). I am still committed to finishing it, something I tell myself every year!

 

So to be honest, at least for projects not requiring complex floating point calculations or high res graphics needs, there is very little reason not to just use XB and then compile. Forth, of course, is also a contender, but there is a learning curve there.

 

There might be some chest thumping going on when one produces something in assembly, but really all that matters is the end-result and one is no less a programmer by sticking to XB alone.

[Tursi]

The odds are if this existed 30 years ago, I wouldn't have written anything in assembly. I think it's an amazing accomplishment!

[+TheBF]

I have a half-finished science fiction wargame programmed entirely in assembly that's been sitting idle for years now because I can't bring myself to re-familiarize myself with the massive code (Ultimate Planet - http://atariage.com/forums/topic/162102-ultimate-planet/page-1?hl=+ultimate%20+planet ). I am still committed to finishing it, something I tell myself every year!

 

 

 

At the risk of sounding like a broken record, a large assembly project might benefit from using a Forth Assembler.

You get the speed of Assembler, but you can write it in bite-sized chunks and test interactively, which can lead to improved productivity.

[senior_falcon]

I hope to upload a revised "Isabella" package this weekend.

[senior_falcon]

Here is "ISABELLA2". This has all the bug fixes developed in the course of the past few weeks getting Stratego to work and as far as I know it is complete. There was one quirk that I left in. That was found by Vorticon when he tried to display a print list using SIZE and found that the line was cleared all the way to the right side of the screen. I tried to fix this but found that the fix changed the display/print behavior elsewhere. It would take weeks of testing to get this all exactly the same as XB, so I decided to change the docs to describe the limitation.

 

I made a minor addition to the utility XB32K that allows the programmer to use all 32K of expansion memory for an XB program. It is more thoroughly tested and the docs go into much more detail. This is now part of XBGDP.

 

(edit) A bit of a snag. 256DEMO always compiled fine. Now it doesn't, so I am trying to work out what is going on.

Edited April 7, 2019 by senior_falcon

[+Vorticon]

Wonderful! One question: can you confirm that the structure below now works with Isabella 2.0? It would not have worked with 1.0, but I recall you fixed that. I'm experiencing some odd behavior which could potentially be related to that piece of code (maybe...).

 

EDIT: No that was not it after all... Never mind me.

IF EMOVED(I)=1 THEN
	IF HFLAG=0 THEN
		HFLAG=1::
		GOTO search_loop ..
	ELSE
		SCORE=-1::
		TFLAG=0::
		GOTO next_square

[senior_falcon]

Here is ISABELLA2. (again)

As often happens, I added a couple of lines for one tiny feature, and surely that could not mess anything up. Famous last words...

Anyway, that's fixed and as far as I know all works as it should.

Anyone who downloaded the first version I posted should junk that and get this one.

ISABELLA2.zip

Edited April 8, 2019 by senior_falcon

[Opry99er]

Unreal....

 

Falcon, you are a beast! And Vorticon, I'm blown away by this game you made.

 

Can't wait to play it on my real hardware tomorrow night!

[+Vorticon]

So Harry, I was experimenting with the possibility of combining the Stratego initialization and main programs into a single program and then using the full 32K to run it. It compiles fine, but when the assembler runs the symbol table overflows. Is there a way to mitigate that issue at all?

[senior_falcon]

Is this with the TI assembler? If so you can try Asm99 which (probably) does not have this issue.

 

(edit) Of course, there are other assemblers as well.

Edited April 8, 2019 by senior_falcon

[+Vorticon]

Unfortunately the asm99 assembler is choking and crashing when trying to assemble the text file produced by the compiler. Could it be too large for it? Would you mind trying to assemble it on your end? Text file attached below.

STRATBC.TXT

[senior_falcon]

Check that your disk is set up properly. What you sent is not a proper text file. What is at the top is the beginning of the file you sent. What is below that is how it should look

 

TIFILES†€ÀP† DEF RUNEA,RUN,RUNV,CONRUNEA DATA ENDCC-RUNEA DATA RUNEA5FRSTLNL100 DATA CHAR,NC1,SC1L110 DATA CLEARL120L130L140L150FOR1# DATA FOR,NV1,NC2,NC3,ONE,0,0" DATA INPUTN,NC2,NV2,NV3,NV4ÿ DATA COLOR,NV2,NV3,NV4 DATA NEXT,FOR1+2L160 DATA SCREEN,NC4L170FOR2# DATA FOR,NV1,NC2,NC5,ONE,0,0 DATA INPUTN,NC2,NV5,SV1 DATA CHAR,NV5,SV1 DATA NEXT,FOR2+2L180FOR3# DATA FOR,NV6,NC2,NC6,ONE,0,0ÿ ! DATA HCHAR,NV6,NC7,NC8,NC9 DATA NEXT,FOR3+2L190FOR4$ DATA FOR,NV1,NC2,NC10,ONE,0,0L200 DATA MLTPLY,RND,NC9,NT1 DATA INT,NT1,NT2 DATA ADD,NT2,NC7,NT3 DATA LET,NV7,NT3L210 DATA MLTPLY,RND,NC6,NT1ÿ DATA INT,NT1,NT2 DATA ADD,NT2,NC2,NT3 DATA LET,NV6,NT3L220 DATA MLTPLY,RND,NC11,NT1 DATA INT,NT1,NT2 DATA ADD,NT2,NC2,NT3 DATA LET,NV8,NT3L230 DATA CLE,NV8,NC7,NT1 DATA IF,NT1ÿ

       DEF RUNEA,RUN,RUNV,CON
RUNEA  DATA ENDCC-RUNEA
       DATA RUNEA5
FRSTLN
L8
       DATA PRINT,SC1
       DATA GOSUB,L10000
L9
L10
       DATA LET,NV1,NC1
       DATA LET,NV2,NC2
L11
       DATA PRINT,SC2
       DATA GOSUB,L10000
L15
       DATA SCRN2
       DATA PRINT,SC3
       DATA GOSUB,L10000         

[+Vorticon]

So it looks like the compiler outputs the text file in TIFILES format. I went ahead and listed it in TIDir then copied the text into a text editor then saved it back. Also the runtime routines needed to be loaded in low memory during compilation.

In any case, it worked! Now there in no further need to save and re-load the game data when transitioning from the initialization to the main program as it is all a single program taking most of the 32K available. Unfortunately, disk access is still needed to load the character definitions and to go from the splash screen to the main game. Also I had to trim the battle sounds to make everything fit into XB before compilation.

Nonetheless, this opens up quite a bit of options for the XB programmer with all of the 32K available. Really outstanding capability!

[senior_falcon]

So it looks like the compiler outputs the text file in TIFILES format. I went ahead and listed it in TIDir then copied the text into a text editor then saved it back. Also the runtime routines needed to be loaded in low memory during compilation.

 

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

Edited April 9, 2019 by senior_falcon

[+Vorticon]

I thought I had done that. Must have forgotten this time around...

Question: I still have memory left after the compilation process, but it is not usable because adding any more lines to the XB program will lead to a memory full error when trying to load it. I really would like to move the character data off disk and into DATA statements using that extra memory. Is there a way to do this at all?

[senior_falcon]

Are you using XB32K to use the extra 8K in low memory for an XB program.

[+Vorticon]

Are you using XB32K to use the extra 8K in low memory for an XB program.

 

No but I will definitely give it a shot. It looks like this should work. More to come.

[senior_falcon]

It's in the XBGDP with much better docs. Start small; work through the example programs first.

[senior_falcon]

Question: I still have memory left after the compilation process, but it is not usable because adding any more lines to the XB program will lead to a memory full error when trying to load it. I really would like to move the character data off disk and into DATA statements using that extra memory. Is there a way to do this at all?

Another way that should work would be to separate the program in two parts, PART1 and PART2. Save these in Merge format. Write a short XB program to OPEN "DSK1,PART1", input and OPEN "DSK1.PARTS12",OUTPUT. Read part1 and write each line to PARTS12. When at the end of PART1 then OPEN "DSK!.PART2",input. Then read each line of PART2 and write them to PARTS12.

 

There would be no way to test the program with this technique, but it should work.

[+Vorticon]

I tried this program to combine the 2 parts of Stratego as you detailed above, each saved in Merge format, but I got gibberish in the target file STRATEGO-M. Is my process correct here?

10 CALL CLEAR
20 OPEN #1:"DSK2.STRATEGO-M",OUTPUT
30 OPEN #2:"DSK2.STRATUP",INPUT
40 LINPUT #2:L$
50 PRINT #1:L$
60 IF EOF(2)THEN 80
70 GOTO 40
80 CLOSE #2
90 OPEN #2:"DSK2.STRATLO",INPUT
100 LINPUT #2:L$
110 PRINT #1:L$
120 IF EOF(2)THEN 140
130 GOTO 100
140 CLOSE #2
150 CLOSE #1
160 END

[senior_falcon]

You have to match the file characteristics. Default is Display, Variable 80. I can't remember what they are for Merge format. (It might be IV 163) If you can't find it easily you should be able to look the COMPILER program and find out..

Edited April 9, 2019 by senior_falcon

[+Vorticon]

I think it's going to be a moot point...

I used XB32K to create a single large program including the character definitions data, but unfortunately the loader reported -1302 bytes of memory left and hung. I guess I'm short about 1.3K of RAM beyond the 32K...

It was a valiant effort

By the way, even with the option to write DV80 files as Windows text turned on in Classic 99, I'm still getting a TIFILES output.

[senior_falcon]

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.