XB Game Developers Package

[senior_falcon]

This is embarassing. To save a few bytes of memory, I made a change to CALL KEY and broke it.

In RUNTIME2, line 573 in DOLCETTO I have:

MOV @1(R4),@>8374 moves lsb *r4, saves one word

 

That should be MOVB@1(R4),@>8374

 

You can use a text editor to change this if you want, or you can wait till tomorrow when I will post a corrected version of DOLCETTO.

[senior_falcon]

Reuploaded in post 1 and 194. DOLCETTO1 has the corrected file.

[+OLD CS1]

To keep from cluttering up the JetBall thread:

 

I admit to have not having RTFMed so I apologize if this question is answered there.

 

Do I understand correctly that this

 

FOR I=110 TO 400 STEP 10

CALL SOUND(100,I,0)

NEXT I

 

would be properly compiled into a sound list of 100ms tones sweeping from 110Hz to 400Hz by increments of 10Hz?

[unhuman]

Full instructions are indeed in the manual.

 

To keep from cluttering up the JetBall thread:

 

I admit to have not having RTFMed so I apologize if this question is answered there.

 

Do I understand correctly that this

 

FOR I=110 TO 400 STEP 10

CALL SOUND(100,I,0)

NEXT I

 

would be properly compiled into a sound list of 100ms tones sweeping from 110Hz to 400Hz by increments of 10Hz?

[+OLD CS1]

Full instructions are indeed in the manual.

 

 

I will have to look at it later, then. While very interesting I am not using it but if I want to collaborate with others who are I should at least familiarize myself with the sound functionality.

 

BTW, I want to throw out there this kit puts the TI on-par with other computers of the era with their game development kits. I was musing on the potential of using XBGDP as part of a package similar to SEUCK or Amos.

[senior_falcon]

To keep from cluttering up the JetBall thread:

 

I admit to have not having RTFMed so I apologize if this question is answered there.

 

Do I understand correctly that this

 

FOR I=110 TO 400 STEP 10

CALL SOUND(100,I,0)

NEXT I

 

would be properly compiled into a sound list of 100ms tones sweeping from 110Hz to 400Hz by increments of 10Hz?

Not quite right. There are two ways to generate sound lists: SLCOMPILER and SLCONVERT. There are quite a number of pages devoted to this in the docs which I won't repeat here. Be sure you are reading the docs with "Dolcetto".

An example:

10 FOR I=1 TO 4

20 CALL SOUND(100,220,0)::CALL SOUND(100,330,0)::CALL SOUND(100,440,0)

30 NEXT I

SLCOMPILER would make a sound list that would play line 20 four times.

 

SLCONVERT works differently and could do what you want and more.

10 CALL LABEL("LOOP1")

20 FOR I=110 TO 400 STEP 10::CALL SOUND(100,I,0)::NEXT I

30 CALL LOOP("LOOP1",4)

 

SLCONVERT would make a sound list that would play the ascending notes in line 20 and they would be played 4 times.

[+OLD CS1]

Okay, so not so much for tone value sweeps but rather just for looping repeating sections, it appears. I can still be of service.

[+OLD CS1]

ON BREAK NEXT causes the compiled program to hang. How do you disable BREAK?

 

I guess this is not an issue running as an EA5, only when running with the XB loader.

[senior_falcon]

ON BREAK NEXT causes the compiled program to hang. How do you disable BREAK?

 

I guess this is not an issue running as an EA5, only when running with the XB loader.

ON BREAK NEXT does not compile to a meaningful instruction. The next release will give two different ways of running from XB; one with the current ability to BREAK and CON and the other to run as it does in EA5 with no BREAK possible.

 

Meanwhile, If it bugs you enough this should work (I haven't tested this!):

The first line of the compiled code should be this:

DEF RUN,CON

Change the RUN to RUNEA and save

Assemble, load and save the program as XB.

Change the XB loader to CALL LINK("RUNEA") and save

 

(edit) Another way that might work (again, not tested!):

Include CALL LOAD(-31931,64) which should do the same as ON BREAK NEXT

 

(edit again) I pictured the CALL LOAD being within the program and compiled, but it would work equally well running in BASIC in the one line loader program right after CALL INIT

Edited April 25, 2018 by senior_falcon

[+OLD CS1]

Since I plan to not use the BASIC loader it is not a big deal. I thought about that CALL LOAD and it does work.

 

Now I have another problem. I am trying to distribute the EA5 copy of the compiled program but it is not working for anyone else. Is it dependent upon any other files? The goal is to make a cartridge image of the program.

[LASooner]

Since I plan to not use the BASIC loader it is not a big deal. I thought about that CALL LOAD and it does work.

 

Now I have another problem. I am trying to distribute the EA5 copy of the compiled program but it is not working for anyone else. Is it dependent upon any other files? The goal is to make a cartridge image of the program.

 

 

Are you including the F and G files as well? Because you need to distribute those with the E file. When I compile Night Stalker it creates NSTALKR-E, NSTALKR-F, and NSTALKR-G and if those 3 files aren't in the same directory with one another it doesn't work.

[+OLD CS1]

 

 

Are you including the F and G files as well? Because you need to distribute those with the E file. When I compile Night Stalker it creates NSTALKR-E, NSTALKR-F, and NSTALKR-G and if those 3 files aren't in the same directory with one another it doesn't work.

 

Ah, there is an -F file for mine. I had not seen that, thank you.

 

Okay, I just tried and it is still not working. I put the -E and -F file on the DSK and I still get an ERROR 7 when trying to run it. Using the Classic99 debugger I find it is looking for a -G file but one does not exist. I will have to keep playing.

[+OLD CS1]

I am completely at a loss. If I run the -E file as FIAD from the compiler directory it loads the -F but does not search for a -G. If I copy those files to another directory or a DSK image it tries to load a -G and fails out. Anyone got any idea on this one?

[+OLD CS1]

Never mind. I figured out I had crossed up between two different versions of the compile. I have it working, now

[senior_falcon]

I am completely at a loss. If I run the -E file as FIAD from the compiler directory it loads the -F but does not search for a -G. If I copy those files to another directory or a DSK image it tries to load a -G and fails out. Anyone got any idea on this one?

I have no idea what is meant by " run the -E file as FIAD from the compiler directory".

 

You should be able to put in the Editor/Assembler cartridge and choose the option:

5 - RUN PROGRAM FILE and enter the name of the program: DSK1.PROGRAM-E and it should load and run. If it is looking for a -G file then the compiler loader should have created three files with the extensions -E, -F, and -G.

 

(Edit) Since it now works, ignore the reply above.

Edited April 26, 2018 by senior_falcon

[+OLD CS1]

Okay, challenge here. This is not working once compiled and I am not certain I can make it work. Any ideas would be greatly appreciated. I am trying to massage the compiler to give the results I need, but I am thinking there are too many points which require floating point for this to be successful and I will just have to use an array of the values I need.

 

INT(1047*2^(INT(RND*12)/12))

 

Should return these values for INT(RND*12) in {0..11}

 

1047

1109

1175

1245

1319

1397

1480

1568

1662

1760

1865

1976

[senior_falcon]

 

INT(1047*2^(INT(RND*12)/12))

Does this work in XB?

RND*12 will return a value from 0 to 11. Divide that by 12 and you have a number that is less than one. The INT of a number less than one will be zero

[+OLD CS1]

Does this work in XB?

RND*12 will return a value from 0 to 11. Divide that by 12 and you have a number that is less than one. The INT of a number less than one will be zero

 

It does and this is the exact intent. I am only taking the INT of RND*12, divided by 12 with the result as the exponent of two. This is the same as 2 to a fractional power. This will lead to a decimal value which is multiplied against the base of 1047.

[Asmusr]

 

It does and this is the exact intent. I am only taking the INT of RND*12, divided by 12 with the result as the exponent of two. This is the same as 2 to a fractional power. This will lead to a decimal value which is multiplied against the base of 1047.

 

Are you calculating random musical notes?

[senior_falcon]

From the compiler manual:

 

Remember that because of the integer arithmetic, dividing 5/2 will give 2, not 2.5. You can use INT in
the XB program when dividing (for example INT(5/2) to be certain that XB and the compiler give the
same results.

 

(INT(RND*12)/12) will always be zero because of the integer arithmetic. INT(RND*12) will give a number from 0 to 11. Whether 0/12 or 11/12, the integer arithmetic then turns that into a zero.

 

I'm sure this can be done via a different path and will think about it tonight, unless someone else beats me to it.

[+OLD CS1]

 

Are you calculating random musical notes?

 

Yup. Good eye.

 

From the compiler manual:

 

Remember that because of the integer arithmetic, dividing 5/2 will give 2, not 2.5. You can use INT in

the XB program when dividing (for example INT(5/2) to be certain that XB and the compiler give the

same results.

 

(INT(RND*12)/12) will always be zero because of the integer arithmetic. INT(RND*12) will give a number from 0 to 11. Whether 0/12 or 11/12, the integer arithmetic then turns that into a zero.

 

I'm sure this can be done via a different path and will think about it tonight, unless someone else beats me to it.

 

I was trying to massage it by thinking that MAYBE the integer application would be during the assignment. I failed and the compiler is smarter than me by apparently working with integer results of all calculations at all times. Instead I just created an array of the needed note values.

[senior_falcon]

You could create an array containing 12 super high notes in the 10th octave.

C10 = 16744 hz

then 17740

D10 = 18795

and so on up to

B10 = 31609 hz

Then dividing by the octave brings the note down to audible range.

Divide by:

2 for 9th octave

4 for 8th octave

8 for 7th octave

16 for 6th octave

and so on...

This way you can easily get any musical note with just a division and it would be compatible with integer arithmetic.

 

(Edit)

The reason for starting with a large number and dividing rather than starting small and multiplying is that it gives more accurate results when using integers. For example:

B2=123.471 hz. Multiply 123*16 and you get 1968 hz which is 6.6 cents flat

B6=1975.533 hz

B10=31608.528 Divide 31608/16 and you get 1975 hz which is .5 cent flat

Edited May 3, 2018 by senior_falcon

[senior_falcon]

Found an interesting problem with Assm994a:

ELSE cannot be used as a label! The assembler either just quits or else throws error messages for every label following the ELSE. In testing IF/THEN/ELSE in "Dolcetto" I did most of the testing using the TI Assembler where it worked fine and had no reason to think it wouldn't work with Assm994a. This is being fixed in the "Encruzado" version, but for now just use the TI Assembler.

[+Lee Stewart]

Found an interesting problem with Assm994a:

ELSE cannot be used as a label! The assembler either just quits or else throws error messages for every label following the ELSE. In testing IF/THEN/ELSE in "Dolcetto" I did most of the testing using the TI Assembler where it worked fine and had no reason to think it wouldn't work with Assm994a. This is being fixed in the "Encruzado" version, but for now just use the TI Assembler.

 

Yeah—I ran into that problem quite a few years ago. When I figured it out, I had to put ‘_’ in front of anything that would run into the mostly undocumented conditional assembly feature(s) of Asm994a.

 

...lee

[senior_falcon]

Here is the newest revision of the XB Game Developer's Package "Encruzado". This is a beta version. As far as I know everything works as it should, but there may be issues lurking in the shadows. In particular, giving the option to put the runtime routines in low memory may cause bugs, although all the ones I could find have been corrected.

COMPILER: The big change is that you now have an option to put the runtime routines into low memory from >2000 to >3FFF. This is necessary is if your compiled program is too large to run in the 24K of high memory, with both compiled code and the runtime routines all located there. With the runtime routines in low memory it is safe to say that you should have no memory problems when compiling even the largest XB programs. If the program is saved as EA5 the program will be loaded exactly as before. If you save as an XB loader there are two programs. The first loads the low memory portion of the code and then automatically loads and runs the second program. Other than a brief pause while the second program is loaded, you will see no difference in how this functions.

When running from XB there are now three ways to start the compiled program.

CALL LINK("RUN") starts the program with a scan that breaks the program execution when F4 is pressed.

CALL LINK("RUNEA") starts the program exactly as it would be when running as EA5. No F4 scan is performed.

CALL LINK("RUNV") starts the program but without resetting any of the Screen2 patterns or character definitions. This lets you chain compiled programs together while retaining all the graphics created by the first program.

A bug in playing sound lists from EA5 was corrected.

XB256: The big change here is that there is a second version of XB256 called XB256HM.This provides a way to save an XB program and XB256 in the same program; If you don't need the speed of a compiled program, this makes a nice, neat one program package

(edit) - Didn't take long to find a bug. I left out a file in the package. Those who already downloaded should download ENCRUZADO_BETA1

(edit) - There is a minor bug that needs to be fixed by editing line 520 in the compiler. See post 228 if you want more details.

OLD DSK1.COMPILER

Edit line 520 to be:

520 DISPLAY AT(21,1):SF$&" is compiled." :: CALL LOAD(-1,0)::RUN "DSK1.LOAD"

SAVE DSK1.COMPILER

ENCRUZADO_BETA1.zip

Edited May 31, 2018 by senior_falcon