Jump to content
IGNORED

Sound List Demo in XBasic


Kurt_Woloch

Recommended Posts

I decided to do a bit of TI-99 programming again in order to have something to show at the next meeting...

 

so I whipped together a small demo yesterday which creates a sound list in XBasic and plays it... without loading any assembler subroutines!

 

Now, how do I get the sound list into VDP RAM, you may ask? Well... just look at the code:

 

1000 CALL CHAR(128,"019F20" & "0390850509" & "028F0509" & "02870912" & "02870812" & "02850609" & "02810709" & "028E0B12")
1010 CALL CHAR(132, "028A0A12" & "02810709" & "028F0709" & "028A0C12" & "028A0A12" & "028F0724" & "019FA0" & "000700")

1190 CALL INIT
1200 CALL LOAD(-31796, 7, 0) ! SOUNDLIST STARTS AT VDP ADDRESS $0700 (CHARACTER 128)
1210 CALL PEEK(-31747,A) :: CALL LOAD(-31747,A OR 1)
1220 CALL LOAD(-31794,1)
1230 END

 

Sorry, you need a 32K expansion for this to work (basically because XBasic refuses to execute "Call Load" if "Call Init" hasn't been called, and refuses to execute "Call Init" without a RAM expansion, not because it would really be necessary for this demo).

  • Like 6
Link to comment
Share on other sites

If you use RXB or any XB that has Miller Graphics XB mods in it you do not need to do the CALL INIT, only XB suffrers this BUG.

 

Also even without a 32K memory this program works in RXB.

Edited by RXB
Link to comment
Share on other sites

  • 1 year later...

Just caught this thread. That's actually quite an excellent little demonstration. =) I wouldn't have thought to do this in this manner.

 

 

=) Made me smile, thank you for posting this. I'm a couple years late in getting to it, but hey... better late than never.

Link to comment
Share on other sites

I decided to do a bit of TI-99 programming again in order to have something to show at the next meeting...

 

so I whipped together a small demo yesterday which creates a sound list in XBasic and plays it... without loading any assembler subroutines!

 

Now, how do I get the sound list into VDP RAM, you may ask? Well... just look at the code:

 

1000 CALL CHAR(128,"019F20" & "0390850509" & "028F0509" & "02870912" & "02870812" & "02850609" & "02810709" & "028E0B12")
1010 CALL CHAR(132, "028A0A12" & "02810709" & "028F0709" & "028A0C12" & "028A0A12" & "028F0724" & "019FA0" & "000700")

1190 CALL INIT
1200 CALL LOAD(-31796, 7, 0) ! SOUNDLIST STARTS AT VDP ADDRESS $0700 (CHARACTER 128)
1210 CALL PEEK(-31747,A) :: CALL LOAD(-31747,A OR 1)
1220 CALL LOAD(-31794,1)
1230 END

 

Sorry, you need a 32K expansion for this to work (basically because XBasic refuses to execute "Call Load" if "Call Init" hasn't been called, and refuses to execute "Call Init" without a RAM expansion, not because it would really be necessary for this demo).

 

 

 

RXB does not need the CALL INIT nor does it required a 32K to run this.

So you do not need line 1190 CALL INIT

And as no 32K is required either this program can only be loaded and run in RXB.

I do not believe any other XB can pull this off.

Link to comment
Share on other sites

well, there are many tools, but there is a nice one that Tursi and I collaborated on which converts XB CALL SOUNDs into BYTE data. That's how I did the music for Honeycomb Rapture and Riding for the Brand. Then using Matthews XB soundlist player, I got background music in an XB arcade game. And by "collaborated on" I mean Tursi did all the algorithm work and I just did the user interface. :)

Link to comment
Share on other sites

The EA-manual covers sound lists and sound process triggering okay from page 312.

 

An relatively identical tool to the one mentioned by Owen in the post above, is this one. It converts TI Basic/XB Call Sound parameters to sound list data. One tone/chord at a time. This might work as embedded media ...

 

[media=544,416]http://sometimes.planet-99.net/vgm.swf[/media]

 

On and off I've been looking into tools, like both tracker-, MIDI-list- and music-sheet oriented approaches. Trying to keep it both simple, user-friendly and effective. I guess it depends a great deal on where you're coming from, so eventually I'm going to stick with Windows or Java tools and custom data conversion/processing and emulation. Not only for music but also for constructing sound-effects. I did a relatively easy multi channel player in the eighties, and that's what one needs with almost any game, otherwise you'll end up with the annoying hiccups of Burgertime (music interrupted/halted/restarted by soundeffects every other second).

 

:)

Link to comment
Share on other sites

Well RXB has a few you can use:

CRASH SOUND

100 CALL CLEAR! CRASH
110 DATA 2,228,242,5
120 DATA 2,228,240,18
130 DATA 2,228,241,16
140 DATA 2,228,242,14
150 DATA 2,228,243,12
160 DATA 2,228,244,10
170 DATA 2,229,245,9
180 DATA 2,229,246,8
190 DATA 2,229,247,7
200 DATA 2,229,248,6
210 DATA 2,229,249,5
220 DATA 2,230,250,4
230 DATA 2,230,251,3
240 DATA 2,230,252,2
250 DATA 2,230,253,1
260 DATA 2,230,254,1
270 DATA 1,255,0,0
280 FOR AD=4096 TO 4160 STEP 4
290 READ V1,V2,V3,V4
300 CALL POKEV(AD,V1,V2,V3,V4)
310 NEXT AD
320 CALL IO(1,4096)
330 PRINT "CRASH": :"TYPE:":"CALL IO(1,4096)"

CHIMES SOUND

10 ! RXB EXAMPLE CALL IO	 (SOUND LIST)
100 A=8191
110 DATA 5,159,191,223,255,227,1
120 DATA 9,142,1,164,2,197,1,144,182,211,6
130 DATA 3,145,183,212,5
140 DATA 3,146,184,213,4
150 DATA 5,167,4,147,176,214,5
160 DATA 3,148,177,215,6
170 DATA 3,149,178,216,7
180 DATA 5,202,2,150,179,208,6
190 DATA 3,151,180,209,5
200 DATA 3,152,181,210,4
210 DATA 5,133,3,144,182,211,5
220 DATA 3,145,183,212,6
230 DATA 3,146,184,213,7
240 DATA 5,164,2,147,176,214,6
250 DATA 3,148,177,215,5
260 DATA 3,149,178,216,4
270 DATA 5,197,1,150,179,208,5
280 DATA 3,151,180,209,6
290 DATA 3,152,181,210,7
300 DATA 3,159,191,223,0
310 A=A+1 :: READ B :: CALL POKEV(A,B)
320 IF B=0 THEN 330 ELSE 310
330 CALL IO(1,8192)

 

Have fun

Rich

 

P.S. If you load CRASH run it and then CHIMES and run it you can then use CALL IO(1,4096) or CALL IO(1,8192)

Edited by RXB
Link to comment
Share on other sites

  • 5 months later...

The EA-manual covers sound lists and sound process triggering okay from page 312.

Well, not quite completely, as it turned out. I mainly worked from this, but the E/A manual omits the "jump" feature where at any point in the sound list, you can jump to a different location (either in VDP RAM or in GROM) and continue processing there. You can also jump back to the start of the sound list, of course, which is what I did here. Maybe TI omitted this because including it would have meant admitting that there is such a thing as a GROM. ;-)

  • Like 1
Link to comment
Share on other sites

xb came first so how can it be a bug? r u the troll here?

 

There are a number of silly things which TI did which we get to consider as "bugs" since they do not necessarily make sense. One of them is the requirement to execute CALL INIT before using CALL LOAD. CALL LOAD, in and of itself, does not mean we are planning to use machine language as it doubles as a TI version of "POKE." Nonetheless, in order to "POKE" values into memory in TI Extended BASIC, you have to INIT first, which requires the 32k memory expansion.

Link to comment
Share on other sites

 

There are a number of silly things which TI did which we get to consider as "bugs" since they do not necessarily make sense. One of them is the requirement to execute CALL INIT before using CALL LOAD. CALL LOAD, in and of itself, does not mean we are planning to use machine language as it doubles as a TI version of "POKE." Nonetheless, in order to "POKE" values into memory in TI Extended BASIC, you have to INIT first, which requires the 32k memory expansion.

 

I can agree from a programmer's point of view it's very silly, and to the technical staff at TI, I imagine it was too. Now from a marketing aspect, it's just plain devious, and could have intentional, which means it was not a bug. But like the answer to the center of a Tootsie Pop, "The World May Never Know."

I can just hear the marketing guys at TI now.... "Okay, suckers, you want access to THIS, you have buy ALL OF THIS FIRST! Ka-CHING!

Link to comment
Share on other sites

xb came first so how can it be a bug? r u the troll here?

 

 

LOL I have the entire source of XB in RXB so I have fixed many bugs.

Unless you use RXB and put it up against XB you do not have any idea what bugs are in XB.

 

And besides do you think XB is prefect with no bugs at all? Or that no one is capable of fixing them? Or that you have ever used RXB?

 

I have posted many videos to show these bugs and that they are fixed.

An example is the CALL INIT bug that Miller Graphics fixed and is in all the later XB's released like SXB, XB 2.5, Miller Graphics XB, and RXB.

 

Calling me a troll when I showed RXB in 1987 for the first time would make me one hell of a old troll.

Link to comment
Share on other sites

 

I can agree from a programmer's point of view it's very silly, and to the technical staff at TI, I imagine it was too. Now from a marketing aspect, it's just plain devious, and could have intentional, which means it was not a bug. But like the answer to the center of a Tootsie Pop, "The World May Never Know."

I can just hear the marketing guys at TI now.... "Okay, suckers, you want access to THIS, you have buy ALL OF THIS FIRST! Ka-CHING!

 

Actually in the source code of XB I bought were hand written noted on the borders of the code that said derogatory remarks like "Why did they never talk to us about this?"

 

He was referring to the Assembly guys never talked to the GPL guys about stuff they did.

EXAMPLES:

GVWRITE is assembly that does exactly the same thing as the GPL command MOVE does.

GVREAD is assembly that does exactly the same thing as the GPL command MOVE does.

(Both about the same speed but requires a more complex set up.)

 

Recently a debate has started on the RND function in XB being much slower then the RND in TI BASIC and again the Assembly guys version is slower and way more complicated.

I have posted the Source code of XB on this and pretty much is easy to see the problems created by the difference. Just run a test to prove it.

 

The problems are communication between the different groups that created XB, and the bugs are the results of no communication on standards. I would say bad management at TI.

  • Like 1
Link to comment
Share on other sites

 

Actually in the source code of XB I bought were hand written noted on the borders of the code that said derogatory remarks like "Why did they never talk to us about this?"

 

 

One reason why some of them may not have talked to the others is because some programmers are temperarmental prima donna's who think their way is the only way, and all others must conform and submit to their view, or be hounded repeatedly to the point of death. I've known some people who would rather spend more time arguing about how to do something, than it would have taken to actually to do the job. There is simply no point on kicking a dead dog. They might still be arguing about it to this day, having never completed a viable product.

 

To be fair, the TI programmer's were probably under pressure to get the project done on time and on budget. Somethings fall through the cracks under those conditions. I suppose, if they had years to tweak and play on their home computers, they too would probably have cleaned up the loose ends, tightened the code and improved the final product.

Link to comment
Share on other sites

Even folks on the same project don't always talk. Take a look at the original TI Forth Manual and you can see such an example. It is obvious that some of the chapters were written by different people, who were keeping their own counsel. Of course, it never got to final production before TI gave up or it surely would have had that problem polished out of it.

 

...lee

Link to comment
Share on other sites

Hey I am typing in the entire GROM source for a rewrite of GROM 0 and GROM 1 and GROM 2 (TI BASIC) has this already been done from the TI Intern Manual or am I the first?

 

I was the one that did this with the TI XB Source of GPL plus ROMs. That took a long time if someone has done this before it would save me a ton of time.

Link to comment
Share on other sites

My TIImageTool has a GPL disassembler. You could use a GROM dump and create the source code from it. However, I had the problem that there was no standard for GPL syntax. My diassembler, for example, uses a different argument order than shown in TI Intern listings. In fact, the official GPL source files (which I have for the TI-99/8) also adhere to the version I implemented. Moreover, the official GPL sources contain constructs that disappear in the object code (like loops).

 

So it depends on which GPL assembler you plan to use whether the output of TIImageTool is useful or not.

Edited by mizapf
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...