Jump to content
senior_falcon

XB Game Developers Package

Recommended Posts

The XB program is reading positive numbers as negative.  (from data statements)

I believe this started when I started using pixel scroll.  But I did a lot of work at the same time, so it may be completely unrelated.

 

I don't want you to start digging in the wrong place based on bad info!

 

What I will do is take the ABS function out and when the problem pops up again, I will try to figure out what might have triggered it.

 

SPEED is always important.  I didn't realize variables from an array were slower.  I figured all of these values were in memory and equally available.

Share this post


Link to post
Share on other sites

I see. It's misbehaving when using XB256.

Here is a tip that might help when this happens. DATA statements are part of the program and are kept in high memory. You can see this if you enter the following program:

10 DATA 1,2,3,-1,-2,-3

Get into the Classic99 debugger, choose CPU and look at >FF00. At the bottom of the screen you will the the numbers in the DATA statement.

Everything in a DATA statement is a string. If you READ X then the string is read and converted to a number (if possible) If you READ A$ then the string is read as a string.

20 READ X::PRINT X     (1 becomes the floating point number 1)

30 READ A$::PRINT A$  (2 becomes the string "2")

But I digress...

I don't see how a minus sign could get added to a DATA statement. But if it happens that a positive number is read as a negative number, use the debugger to find the line with the DATA and see if the minus sign has somehow been added.

Edited by senior_falcon
  • Like 1

Share this post


Link to post
Share on other sites
7 hours ago, TheBF said:

 

The RTN routine above is consuming a large percentage of the runtime in threaded systems.  It could approach 50% of the instructions being run for simple keywords!

ABS is about as simple as you can get. Below is the code to do ABS. There are 15 instructions if you don't use an array. That would be 13 without the LIMI's. Assuming all instructions take the same amount of time (they don't!), it would run a little faster, running in  87% of the time. Virtually all instructions are more complicated than ABS and I would guess that optimizing the lIMI's would result in a speed gain of 5% +/-

ABS	BL @GET2
	MOV *R5,*R6
	ABS *R6
	B @RTN

GET2	MOV *R13+,R5
	C R5,R14
	JLT GET1
	BLWP @GETARR
	DATA 5
GET1	MOV *R13+,R6
	C R6,R14
	JLT GET0
	BLWP @GETARR
	DATA 6
GET0	B *R11

	
RTN	LIMI 2			the main loop, all subs come back to here
	LIMI 0
	MOV *R13+,R12
	B *R12		

 

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, senior_falcon said:

ABS is about as simple as you can get. Below is the code to do ABS. There are 15 instructions if you don't use an array. That would be 13 without the LIMI's. Assuming all instructions take the same amount of time (they don't!), it would run a little faster, running in  87% of the time. Virtually all instructions are more complicated than ABS and I would guess that optimizing the lIMI's would result in a speed gain of 5% +/-

ABS	BL @GET2
	MOV *R5,*R6
	ABS *R6
	B @RTN

GET2	MOV *R13+,R5
	C R5,R14
	JLT GET1
	BLWP @GETARR
	DATA 5
GET1	MOV *R13+,R6
	C R6,R14
	JLT GET0
	BLWP @GETARR
	DATA 6
GET0	B *R11

	
RTN	LIMI 2			the main loop, all subs come back to here
	LIMI 0
	MOV *R13+,R12
	B *R12		

 

Thanks.  That's part I did not know.  So it's less important here than I imagined. 

It's far worse in Forth because there are many keywords that are a single machine instruction.  :( 

 

For some reason I woke up this morning thinking about this so I threw it out there.

 

The other thing I wonder about is in-lining the short routines, like ABS for example. Direct threading makes that possible.

Probably more trouble than it is worth. ?

 

Share this post


Link to post
Share on other sites

I have almost tamed the process of using assembly support routines with a compiled program. In general, any assembly support routines should now work. The ones that use interrupts such as T40XB, T80XB, The Missing Link, etc need a little extra work. At this point both T40XB and T80XB seem to work perfectly when used with a compiled program. The next challenge is The Missing Link. I believe it will be possible to include all the extra TML features that are included in the GEM 2.8 cartridge.

  • Like 4
  • Thanks 1

Share this post


Link to post
Share on other sites
On 3/27/2021 at 2:46 PM, SteveB said:

I stumbled across an issue with Isabella 7. I develop a game using XB256 and it progresses well. Most testing is done in Classic99 with CPU Overdrive, but I compile once in a while. Suddenly last night my program went bezerk. Still working fine when interpreted, but showing strange behaviour after being compiled. The lines 

180 RC=0 :: CALL JOYST(1,X,Y) :: CALL KEY(1,K,S) :: X1=X1+X/4 :: CALL POSITION(#10,Q1,W1)
190 CALL LOCATE(#11,Q1,W1-16)
200 IF W1<32 THEN X1=MAX(X1,0) ELSE IF W1>210 THEN X1=MIN(X1,0)

should obviously attach sprite #11 on the left side of #10 and do so in XP. After compiling, it is about 4 chars to the left. Furthermore the joystick is only working sideways, no up or down.

I assume something in the (xb256?) runtime does not work anymore.

Hi,

 

after hours of searching with a Diff-Tool (WinMerge) from the last known good version I finally found the problem: One line had a cut&paste error some lines after above code:

390 ON Lvl GOSUB 1170, 1190
400 IF KI=0 THEN Lvl=Lvl+1 ELSE Ship=Ship-1 :: CALL Ships(Ship) :: :: CALL SPRITE(#10,96,3,100,56) :: CALL SPRITE(#11,100,16,100,40)
410 IF NOT (Ship=0) THEN 380

The double-double-colons confused the compiler completely, while XB itself did not complain. 

 

I wanted to share this hint with the community.

 

Cheers

Steve

  • Like 3

Share this post


Link to post
Share on other sites

Thanks Steve,  I am certain I have had the same issue over the years.  Testing, adding and removing things on a line.

I initialize most variables on a single line if I can.  Sometimes you need to add sometimes you can remove but I can see me leaving  :: :: figuring, if I need to add something, I tuck it on that spot!

 

 

Share this post


Link to post
Share on other sites
Posted (edited)
5 hours ago, SteveB said:
390 ON Lvl GOSUB 1170, 1190
400 IF KI=0 THEN Lvl=Lvl+1 ELSE Ship=Ship-1 :: CALL Ships(Ship) :: :: CALL SPRITE(#10,96,3,100,56) :: CALL SPRITE(#11,100,16,100,40)
410 IF NOT (Ship=0) THEN 380

The double-double-colons confused the compiler completely, while XB itself did not complain. 

I compiled line 400 with the double-double colons, then corrected that and compiled again. The compiled code produced is identical in both versions, so I don't see how that can be your problem.

Line 410 IF NOT (SHIP=0) THEN 380 seems convoluted. Wouldn't 410 IF SHIP<>0 THEN 380 do the same thing? In any event, NOT works the same in XB and when compiled, so that shouldn't be the problem either.

 

(Edit) This double colon behavior is somewhat erratic in both XB and compiled.

100 CALL HCHAR(1,1,42,32) :: :: CALL HCHAR(2,1,65,32) works fine in XB, but gives a colorful screen when trying to compile. Add 3 double colons and even XB cannot handle it without crashing.

As noted above, the moral of the story is to avoid double double colons.

Interestingly, if you type 6 colons together, XB will separate them into 3 double colons.

 

 

 

 

Edited by senior_falcon
  • Like 1

Share this post


Link to post
Share on other sites

As the :: is just skipped:

In XB ROMs it finds a :: and skips the first : then jump to next character and again finds : and again skips thus looking for next character.

 

This explains the behavior of XB.

  • Like 1

Share this post


Link to post
Share on other sites

I have been making slow but steady progress in adapting The Missing Link to the compiler. The version of The Missing Link built into XB 2.8 G.E.M. has quite a number of additional features that will not fit in the standard XB version. All these are available in the compiled version.

To get the original TML to run in XB, quite a number of compromises had to be made that had a negative impact on execution speed. I have made a lot of  improvements which provide a nice boost to the speed.

At present I am converting the Missing Link Demo so it can be be compiled. Below is the turtle graphics demo. On the left is the XB version; on the right is the compiled version. I gave the XB program a big head start and removed all the pauses between each screen. Those advantages are not enough. The compiled version finishes quite a bit before the XB one.

 

TURTLE.gif

  • Like 11
  • Thanks 1

Share this post


Link to post
Share on other sites
On 4/8/2021 at 9:05 PM, GDMike said:

It appears that loading text was the same speed? 

A little bit faster but not much. As noted in an earlier post, once in the assembly routine the speed will be the same. For The Missing Link I have done some reworking of the assembly code which speeds things up considerably. But there are a lot of instructions to plow through to put text on the screen, so the speed increase is not so dramatic.

 

  • Like 3

Share this post


Link to post
Share on other sites
On 4/1/2021 at 4:49 AM, senior_falcon said:

 

Line 410 IF NOT (SHIP=0) THEN 380 seems convoluted. Wouldn't 410 IF SHIP<>0 THEN 380 do the same thing? In any event, NOT works the same in XB and when compiled, so that shouldn't be the problem either.

 

You are right, this is the only runtime-penalty for my SXB language conversion. REPEAT ... UNTIL <COND> gets translated to IF NOT <COND> THEN "Repeat-line". For simple expressions it would be possible to simplify the condition, but just thing of the options you have with AND, OR, NOT, <, <=, >=, >, = and even arethmetics. IF A-B+C THEN xxx would be executed if the computed value is not equal zero. I opted for the additional NOT and the parenthesis. But I will think of a REPEAT ... NUNTIL loop - for NOT-UNTIL where you can enter the condition already negated. 

Share this post


Link to post
Share on other sites

Here is a compiled version of the TMLDEMO that was part of the original The Missing Link package. This runs from XB and all the files should be in DSK1.

The Papersaver demo was deleted because it uses some direct pokes in order to work, and I didn't feel like figuring out what they were. Also deleted in the Text demo is the part showing that numbers can be formatted. This allows you to determine how many places should be displayed after the decimal point. With integer math this is not useful. in the Graphics demo a few routines were deleted that use trig functions, which are not available to compiled XB.

At the end of the Sprite demo, Moonlight sonata is played. On my equipment (Classic99 running in Windows XP running in Virtual Box on Linux Mint), usually at some point in this short musical piece the music has a strange "stutter" for a short time which then goes away. I would like to know if this is unique to me, or if other people encounter this as well.

 

TMLDEMOC.zip

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...