Jump to content
IGNORED

XB Game Developers Package


senior_falcon

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.

Link to comment
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
Link to comment
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
Link to comment
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. ?

 

Link to comment
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
Link to comment
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
Link to comment
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!

 

 

Link to comment
Share on other sites

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
Link to comment
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
Link to comment
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 12
  • Thanks 1
Link to comment
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
Link to comment
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. 

Link to comment
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

 

  • Like 1
Link to comment
Share on other sites

11 hours ago, senior_falcon said:

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.

It seemed to play through fine here... is the stutter a buffer-like stutter? Pretty cool to see this running compiled :)

 

Link to comment
Share on other sites

3 hours ago, Tursi said:

It seemed to play through fine here... is the stutter a buffer-like stutter? Pretty cool to see this running compiled :)

 

It is hard to describe. It plays fine for a while, then for a short time it seems to put an audible "click" into the notes. Then it that goes away and the notes play properly again. I checked the classic99 debugger and nothing is reported. I moved the files to Win994a to see what would happen, but that just crashes. Tonight I will try to move the files over to the real TI to see what happens there.

This development should get your Teenage Mutant Ninja Turtle program running at an acceptable speed.

  • Like 1
Link to comment
Share on other sites

Hehe, I thought about that. Then I thought, "But that might just reveal how shallow a game it is!" ;)

 

The jitter buffer stats aren't reported into the log anymore, so if that code is messing up it won't be much help. If it's gappy with the clicks, or repeating an old sound, that's possible. You could also try changing the sampling rate (up or down doesn't matter, just change) to see if it affects it.

 

Edited by Tursi
Link to comment
Share on other sites

I transferred the files for the demo program to my real TI99. The screen produced is the same as the screen produced by Win994a. Since it works fine in Classic99, it seems that the real TI99 and Win994a are less forgiving of something I have done in the code. Win994a does not have a debugger, but I should be able to work out some short test programs in Classic99, transfer them to Win994a, and try to find out where the program is going off the rails.

Stay tuned....

  • Like 1
Link to comment
Share on other sites

Using the Classic99 debugger, setting VR0 to 0 I makes the screen in Classic99 match the screen in Win994a. So it appears that VDP register 0 is somehow either not being set to 2 for bit mapped or else it is being reset from 2 back to 0 at some point early in the program.

Why it behaves in Classic99 and misbehaves in real iron and Win994a is still a mystery...

Link to comment
Share on other sites

7 hours ago, Asmusr said:

It doesn't work in JS99er either. The log says "Write >04 to F18A register 8 (>08) without unlocking." (which ends up affecting VR0) if that's any help.

That's a big help! My sub to change the registers to the bit mapped registers had the condition for exiting the loop in the wrong place! It was trying to change VR8. Evidently Classic99 ignores this, but the real TI sets VR0 to zero. Win994a and JS99er duplicate this behavior.

  • Like 2
Link to comment
Share on other sites

I don't see the description of the original problem, but yes, that seems likely! That is part of the compatibility code to allow 80 column mode without unlocking... it would be interesting to know if the problem also happens on F18A, but it's more likely Classic99 specific. That'll clean up a bit when I split the chips up.

 

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...