XB Game Developers Package

[+hloberg]

Good job!

[+Ksarul]

Many thanks for this tool!

[Bones-69]

Is disk file access something that is eventually likely Harry? I have had some ideas kicking around for some time but I haven't been able to work around the challenge of requiring a lot of text data.

[senior_falcon]

Is disk file access something that is eventually likely Harry? I have had some ideas kicking around for some time but I haven't been able to work around the challenge of requiring a lot of text data.

I wouldn't say it is impossible, but it would definitely have to be some time in the future. I need a break from programming so I can build some model planes and get out on my boat.

[+Ksarul]

Oooohhhhh! Two very fun activities. I spent a lot of time sailing on Lake Erie when I was younger. . .but I've been away from the water for a looooonnnnnggg time. Too long. . .have much fun though--you definitely deserve as many breaks as you want to take!

[senior_falcon]

My grandfather had a cottage on Sandusky Bay. I have many fond memories from those days. My sister and I flew to South Bass island on a Ford Trimotor in 1974.

[+hloberg]

Very good job, except, the version of Funnel Web you use in the compiler isn't CF7+ compatible. There is a modified version of Funnel Web for the CF7+ that I put on the .zip below. I also modified your LOAD file to call it. I don't think it transfers the file name right but the Assembler does now work with the CF7+. I'm sure you can modify it right very easily, it's a bit over my head right now.

CMPLR256C.zip

[senior_falcon]

This CF7 is gonna be the death of me! You probably got the modified program from the post 16 in "Funnelweb and DSKU fix - CF7/nanopeb". From what I read there, it looks like you just need to replace the file FW. Just to keep you on your toes, you have to rename LOAD on the funnelweb disk to FW, and replace the original FW on the compiler disk with the new FW. Hopefully it will work. I will take a look tomorrow to see if it is compatible with a non CF7 TI. Another possibility would be to use the RAG assembler. I think it is a little slower but not by a lot.

Edited May 20, 2014 by senior_falcon

[+hloberg]

Just replacing FW didn't work, the files were a different size or something. What I did change though does work with the CF7.

Not to drive you crazier, I was playing with TML 2.0 on classic99 and in the manual you have the command CALL LINK ("BITMAP") put it doesn't work. did you take out that command in later version?

[senior_falcon]

Just replacing FW didn't work, the files were a different size or something. What I did change though does work with the CF7.

Not to drive you crazier, I was playing with TML 2.0 on classic99 and in the manual you have the command CALL LINK ("BITMAP") put it doesn't work. did you take out that command in later version?

There are five additional A/L subroutines that have been added to TML; GETPAT, GETPIX, DECHEX, GRAFIX, BITMAP. Page 28 of the manual describes how to use these. They will not fit in low memory, so they have to be located in high memory and run from there. You have to be careful, because if you type "NEW" then they are gone and will have to be reloaded. BTW, the utility HMLOADER is not restricted to TML. It can be used to embed assembly code in any XB program. Systex and similar loaders transfer the embedded code to low memory, but with HMLOADER the code runs directly from high memory. Using this makes for a tidy package which contains your XB program and the supporting A/L subs in one file. Plus it doesn't use low memory at all, so you can have additional subroutines there. Read the docs starting on page 26 to find out more about HMLOADER.

Edited May 20, 2014 by senior_falcon

[+hloberg]

There are five additional A/L subroutines that have been added to TML; GETPAT, GETPIX, DECHEX, GRAFIX, BITMAP. Page 28 of the manual describes how to use these. They will not fit in low memory, so they have to be located in high memory and run from there. You have to be careful, because if you type "NEW" then they are gone and will have to be reloaded. BTW, the utility HMLOADER is not restricted to TML. It can be used to embed assembly code in any XB program. Systex and similar loaders transfer the embedded code to low memory, but with HMLOADER the code runs directly from high memory. Using this makes for a tidy package which contains your XB program and the supporting A/L subs in one file. Plus it doesn't use low memory at all, so you can have additional subroutines there. Read the docs starting on page 26 to find out more about HMLOADER.

Thanks, I must have did a NEW before I test it is why they came up with errors. Still learning the ins and outs of A/L on the TI99. I will read the docs on HMLOADER, sounds interesting.

Edited May 20, 2014 by hloberg

[senior_falcon]

Back to the CF7 and COMPILER256 incompatibility. This is probably the most bizarre thing I've ever encountered on the TI, and there have been a lot! I downloaded the CF7 compatible version of Funnelweb. The funnelweb program for XB is called LOAD. As long as it is named LOAD the TI can find it without complaint. If you change the name using Classic99 it cannot be found and an error message is issued. BUT, if you load it when the file name is LOAD and then save DSK1.FW then you can load it normally. So try this: Put the CMPLR256C disk in drive 1. Put the FW44-CF7 disk in drive 2. (That's the one mentioned in post #33 above).

 

Then type OLD DSK2.LOAD

And then SAVE DSK1.FW

 

Test the compiler using CF7 and let me know if the assembler loads.

 

(Just tested this and it behaves the same as the normal Funnelweb. If this works for you I will modify the package and change the colors to white on blue)

Edited May 21, 2014 by senior_falcon

[senior_falcon]

The attached version works with real iron and Classic99. It uses the CF7 compatible version of Funnelweb contained in the Funnelweb/CF7 post. Try it out with the CF7 and see if it actually does work properly

CMPLR256C.zip

[+hloberg]

The attached version works with real iron and Classic99. It uses the CF7 compatible version of Funnelweb contained in the Funnelweb/CF7 post. Try it out with the CF7 and see if it actually does work properly

works with my CF7. thanks.

[1980gamer]

Here are a couple of very quick samples using XB256.

 

A space invaders type movement, This little game loop was big and slow in my original XB version.

Very easy to do this movement with XB256.

 

Also Frogger sample. I would not have even tried this in straight XB. I would like to learn more about the single pixel movement.

Can someone put up some simple samples like these?

 

Also, I was not able to compile these? I thought they were able to be compiled? Anyway, if not, I'd most likely not use XB256 very much.

I am so spoiled with the speed of compiled XB! Sprite collisions actually work ( or can be polled enough to work ).

 

Thanks all.

[senior_falcon]

I downloaded both of these and had no trouble compiling them. When you are using XB256 and you are ready to compile, first save the program in merge format (as usual), then quit and load the compiler and use it as usual. You cannot have XB256 loaded when you are compiling a program written in XB256. Be sure you are using the latest version - there were some changes made in how the video ram is used.

 

There is one difference (besides speed) in how INVXB256 runs in XB or compiled. In XB it gives a "BAD VALUE in 220" error message. The compiler assumes that you have already debugged the program and doesn't check for errors, so you get some interesting screen effects instead of an error message. Oddly enough, it doesn't crash the program. Not to beat a dead horse, but always be sure to debug your program in XB before compiling it.

[1980gamer]

Here are a couple of very quick samples using XB256.

 

A space invaders type movement, This little game loop was big and slow in my original XB version.

Very easy to do this movement with XB256.

 

Also Frogger sample. I would not have even tried this in straight XB. I would like to learn more about the single pixel movement.

Can someone put up some simple samples like these?

 

Also, I was not able to compile these? I thought they were able to be compiled? Anyway, if not, I'd most likely not use XB256 very much.

I am so spoiled with the speed of compiled XB! Sprite collisions actually work ( or can be polled enough to work ).

 

Thanks all.

INVXB256.txt

FROG.TXT

[1980gamer]

"In XB it gives a "BAD VALUE in 220" error message."

 

Yup, I was not checking for the aliens "landing". It was just a sample to see what could be done.

 

These are pretty cool commands. I would like to do the single pixel version of these.

If I could do that and compile to make this run fast... I can see a ton of potential.

 

I'll keep playing... I'll try the compiling again. Maybe I didn't save as merge?

 

Thanks!

[senior_falcon]

Here are 1980 gamer's two demo programs running in XB with XB256, then running as compiled programs.

[1980gamer]

Wow, those run FAST! Plenty of room for sound and collision detection etc.

However, I can not get them to compile. I get undefined symbol 0026, 0057, 0076, 0095

for invx-s going to invx-o

 

Did you make any code changes? I'll look them over again. I could swear it is the call link commands though.

[senior_falcon]

Be sure you are using the package in post #1 above. That should be the same as I am using. If it doesn't work for you I will repost the package.

 

Above is a comparison of two programs, both running in XB using XB256. The first is your FROG demo running normally. The second is the same program, but I used the COMPRESS utility to save the screen, colors, and character definitions in compressed data statements after your program defined them. All the lines that created the screen were then deleted and replaced with the DATA statements and a one line loader. The second program is not compiled. It is one fifth the size and loading the screen is more than 50 times faster, and it all runs in XB. The big drawback is that you cannot edit the DATA statements, so you wouldn't want to do this until you had finalized your graphics. And yes, this is supported by the compiler.

 

(Edit June 5- I just timed it. The screen, colors, and character definitions load 75 times faster!)

Edited June 6, 2014 by senior_falcon

[1980gamer]

It is always the easiest things isn't it! I never pointed classic99 to the correct version of the compiler...

Works just fine now.

 

I will continue to play with these new tools and see if I can come up with something new. I have a creative road block at the moment.

Thus 2 demos that have already been done.

[senior_falcon]

While playing around with compiling APERTURE I found a bug in COMPILER256, the new compiler that supports the XB256 routines. A CALL SOUND will crash the compiled program. I never tested CALL SOUND with the modified compiler because it always worked fine in the past, but the ability to play sound lists had a side effect. One line of code must be added to fix this. In the file RUNTIME1 find line 741 which should be:

MOV R0,@>83CC this should be line 741

MOV R0,@MONWS+24 add this line after the line above, then save.

 

Compiled programs should now behave just like the XB program running under XB256.

I will put a complete package together with this change and the CF7 modifications and post it sometime soon.

[1980gamer]

Bumping this topic.

 

I still have no idea what to do next. I don't want to "port" something, I want to do something NEW....

[senior_falcon]

Here's an updated version of the Game Developers Package. XB256 now has a disk catalog program (CAT) and a faster random number generator. CALL LINK("IRND",8,X) gives the same results as X=INT(8*RND) but is twice as fast as the slow XB random number generator. There are now two converter utilities for turning XB programs with CALL SOUND statements into sound tables. (The sound lists created are compatible with Matt's sound list player) The documentation has been expanded especially as pertaining to sound lists. The bug where CALL SOUND crashed the compiled code is corrected.

 

Post #1 has been updated to contain the new files.

XB Game Developers Package Nov15 2014.zip

Edited November 16, 2014 by senior_falcon