Sound Conversion

[RXB]

I can not seem to find any programs that convert a Basic or XB sound list to a Assembly or GPL.

 

I tried to write code that took the Basic sound command and copied it to lower 8K so I could see how it does it but it is always zeros?

 

I have never worked with sound files much, so I really as lacking in data on how to pull this off.

[Tursi]

Seems to me that Marc or Matthew wrote something for Owen a year or so ago, do a quick search of the forums here.

 

It's pretty straightforward what it does though.

 

A sound list consists of a count, the raw bytes to load into the sound chip, and a duration (in jiffies, that is, how many 1/60th of a second frames). After the count of bytes is loaded to the sound chip, the duration counts down. When it hits zero, the next block in the sound list is processed. A count of 0 means the list is complete. See section 20.1 of the Editor/Assembler manual.

 

From TI BASIC's point of view, it more or less works like this.

 

First, if the duration is negative, it stops the current sound list by writing 0 to >83CE. (Section 20.0 covers the scratchpad addresses used). If it is not negative, then it waits until >83CE is set to zero on its own, meaning that the list is complete.

 

Next it creates a sound list containing all the tones specified in the CALL SOUND:

The duration is divided by 16.6 (not sure offhand the exact value TI BASIC uses, but roughly) to convert milliseconds to ticks.

The frequency is converted using the formula 111860.8/HZ = counter, and the counter value is loaded to the sound chip along with the appropriate channel flags.

The volume is divided by two, so that the range is 0-15, and the appropriate channel flags added.

The noise channel setting is simply added to the appropriate flags for noise.

 

The generated sound list (containing one note and a stop) is then started and the console interrupt plays it.

 

Converting a stream of CALL SOUND commands shouldn't be too hard, but you'll have to track down the thread where Owen was doing it.

[+retroclouds]

This might be exactly what you are looking for: http://sometimes.planet-99.net/vgm.html

[RXB]

This might be exactly what you are looking for: http://sometimes.pla...99.net/vgm.html

 

Thanks but dang wished it worked. Example that crashes your link: CALL SOUND(50,-5,0) or CALL SOUND(-1000,110,0,220,0,400,0,-7,0)

 

What is a -1000 timing?

Or -5 or -7 sound?

 

This is the Basic Program I am converting to GPL for the next GPLHOW2, never worked on sounds as never needed to before.

BROBOCHASE.txt

Edited May 10, 2011 by RXB

[+retroclouds]

ok, no expert on this and perhaps sometimes99er can chime in (it's his program),

but you should be safe to replace the negative sound durations with positive ones.

 

As you know sounds are played by the ISR routine and as such you basic program continues with the next statement. By using a negative duration, e.g. -1000 you delay your program until the sound has played.

 

Should check TI Intern how this was actually done in the Basic interpreter. Guess that the sign bit is used as a flag for the basic interpreter. I don't know what the negative sounds are for though.

 

Anyone ?

 

EDIT: hold on. Tursi mentioned is his previous post:

 

From TI BASIC's point of view, it more or less works like this.

 

First, if the duration is negative, it stops the current sound list by writing 0 to >83CE. (Section 20.0 covers the scratchpad addresses used). If it is not negative, then it waits until >83CE is set to zero on its own, meaning that the list is complete.

Edited May 10, 2011 by retroclouds

[RXB]

ok, no expert on this and perhaps sometimes99er can chime in (it's his program),

but you should be safe to replace the negative sound durations with positive ones.

 

As you know sounds are played by the ISR routine and as such you basic program continues with the next statement. By using a negative duration, e.g. -1000 you delay your program until the sound has played.

 

Should check TI Intern how this was actually done in the Basic interpreter. Guess that the sign bit is used as a flag for the basic interpreter. I don't know what the negative sounds are for though.

 

Anyone ?

 

Yea the XB manual page 170 says they are sounds. Periodic and white noise. So how would you put in the negative numbers in the converter?

[John Doe]

Edited February 22, 2014 by Tony Knerr

[+retroclouds]

oopppss.. guess memory didn't serve me right there. Was that me doing some wishful thinking?

 

The TI Extended Basic manual says:

 

Duration is from .001 to 4.250 seconds, although it may vary up to 1/60th of a second. The computer continues performing program statements while a sound is being played. When you call the SOUND subprogram, the computer waits until the previous sound has been completed before performing the new CALL SOUND. However, if a negative duration is specified, the previous sound is stopped and the new one is begun immediately.

 

....

A value of -1 to -8 specifies one of eight different types of noise.

[RXB]

oopppss.. guess memory didn't serve me right there. Was that me doing some wishful thinking?

 

The TI Extended Basic manual says:

 

Duration is from .001 to 4.250 seconds, although it may vary up to 1/60th of a second. The computer continues performing program statements while a sound is being played. When you call the SOUND subprogram, the computer waits until the previous sound has been completed before performing the new CALL SOUND. However, if a negative duration is specified, the previous sound is stopped and the new one is begun immediately.

 

....

A value of -1 to -8 specifies one of eight different types of noise.

 

Yea but how do you convert that into assembly or GPL? What I started to do was make a Basic patch to do that but it did not work, most likely as interupts are needed to run sounds. My list copy always was just zeros.

[sometimes99er]

This might be exactly what you are looking for: http://sometimes.pla...99.net/vgm.html

Thanks but dang wished it worked. Example that crashes your link: CALL SOUND(50,-5,0) or CALL SOUND(-1000,110,0,220,0,400,0,-7,0)

ok, no expert on this and perhaps sometimes99er can chime in (it's his program),

Only accepts positive durations and positive frequencies. As is it's only meant to convert simple TI Basic music without use of noise generator. Basically does the same as Opry99er's original TI Basic program.

[RXB]

This might be exactly what you are looking for: http://sometimes.pla...99.net/vgm.html

Thanks but dang wished it worked. Example that crashes your link: CALL SOUND(50,-5,0) or CALL SOUND(-1000,110,0,220,0,400,0,-7,0)

ok, no expert on this and perhaps sometimes99er can chime in (it's his program),

Only accepts positive durations and positive frequencies. As is it's only meant to convert simple TI Basic music without use of noise generator. Basically does the same as Opry99er's original TI Basic program.

 

Ok thanks will see what I can do with it.

 

Just for kicks here is the source I have so far.

ROBO.txt

[RXB]

Welll found a great soulution in Computes Guide to Beginer Assembly Language.

 

The attached file is a Basic program that does even the Noise generator.

 

Also the book explains how you add the values together to make a sound list.

Example:

 

* BYTE >09,>89,>3F,>90,>AC,>1F,>B0,>C8,>11,>D0,3C using the link Sometimers posted.

* NOISE >02,>E6,>F0,>01 using the Basic program that accepts negative values.

 

Would be >0B,>89,>3F,>90,>AC,>1F,>B0,>C8,>11,>D0,>E6,>F0,>01

 

The >OB is >09 and >02 added and the Noise had the correct value of negative duration so >01 replaced the >3C that was a positive duration.

 

Very well explained in book, the manuals look like the computer wrote them and do not really explain much, even the Assembly or GPL books suck at explaining this.

SOUNDTABLE.txt

[RXB]

Well I am pretty perplexed on this. When I take a sound that I generate with the SOUNDTABLE converters I get sound lists that look correct.

 

The sample I posted, a Basic program that is from the Computes guide to TI99/4A programming.

 

Example: CALL SOUND(50,300,0,600,0,1200,0) from BASIC converted would be DATA >0985,>1790,AA0B,>B0CD,> 05D0,>0300

 

But when I do a GPL command

 

SOND EQU >832C

S1620 DATA >0985,>1790,AA0B,>B0CD,> 05D0,>0300

MKSND DST S1620,@SOND

GPLIO I/O 0,@SOND

 

This produces garbled sounds for about 1 minute.

 

Yet CALL SOUND(200,440,0,880,0,523,0) is DATA >098E,>F090,>AF07,>B0C6,>0D0C,>0000

And pretty much works exactly as it is suppose to.

 

I would say 90% of the ones I have converted do not work correctly. Something major is missing in the data on sounds in GPL and how they work.

 

So I guess I going to have to disassemble tons of games wrtiten in GPL to see what the heck is going on.

 

Assembly does a great job but sucks at Autosound during a game. Funny that I never had to do this before as I never wrote games in GPL before.

[Tursi]

I/O writes data to the sound chip - the sound chip does not process sound lists. The interrupt routine does.

 

Read the section in Editor/Assembler that I directed you to earlier. It describes how to set up a sound list. Load the same scratchpad values from GPL and your sound list will play.

[marc.hull]

Well I am pretty perplexed on this. When I take a sound that I generate with the SOUNDTABLE converters I get sound lists that look correct.

 

The sample I posted, a Basic program that is from the Computes guide to TI99/4A programming.

 

Example: CALL SOUND(50,300,0,600,0,1200,0) from BASIC converted would be DATA >0985,>1790,AA0B,>B0CD,> 05D0,>0300

 

But when I do a GPL command

 

SOND EQU >832C

S1620 DATA >0985,>1790,AA0B,>B0CD,> 05D0,>0300

MKSND DST S1620,@SOND

GPLIO I/O 0,@SOND

 

This produces garbled sounds for about 1 minute.

 

Yet CALL SOUND(200,440,0,880,0,523,0) is DATA >098E,>F090,>AF07,>B0C6,>0D0C,>0000

And pretty much works exactly as it is suppose to.

 

I would say 90% of the ones I have converted do not work correctly. Something major is missing in the data on sounds in GPL and how they work.

 

So I guess I going to have to disassemble tons of games wrtiten in GPL to see what the heck is going on.

 

Assembly does a great job but sucks at Autosound during a game. Funny that I never had to do this before as I never wrote games in GPL before.

 

 

 

Hmmmmmmm. Perhaps it is not assembly that sucks at sound processing but rather your understanding of sound processing. I think you need to go back to step 1 and try again.....

[RXB]

I/O writes data to the sound chip - the sound chip does not process sound lists. The interrupt routine does.

 

Read the section in Editor/Assembler that I directed you to earlier. It describes how to set up a sound list. Load the same scratchpad values from GPL and your sound list will play.

 

Thanks Tursi, but I am dong GPL not Assembly. As long as the list continues a stream like the ones in EA manual or other examples it works fine.

But when I use single one like the two I posted in the last message, one works and the other does not , put them in Assembly and they work fine.

But put the first one in GPL and it never stops, the Accept tone and Honk tone in the Basic or XB both have the same exact list and work fine.

Then put in the two I posted and one works but the other just never stops even though they both have a >00 at end to stop playing the list.

I have tried using every method that I can find, the XB/BASIC versions use >83CE and test for Zero but even those still keep playing after the end of the list.

What I am missing is information on how GPL works doing this, and the manuals are no better then my RXB one at explaining this.

Turns out no one seems to have written anything on this in GPL ever. If you try this in GPL you will find the same inconsitency I am finding.

 

The BASIC/XB version of Accept tone or Honk do not need a check of >83CE in the GPL code to end playing, but for some reason one of these tones does.

I am just missing some info on GPL that is not in any book or manual I have found.

Edited May 16, 2011 by RXB

[RXB]

Well I am pretty perplexed on this. When I take a sound that I generate with the SOUNDTABLE converters I get sound lists that look correct.

 

The sample I posted, a Basic program that is from the Computes guide to TI99/4A programming.

 

Example: CALL SOUND(50,300,0,600,0,1200,0) from BASIC converted would be DATA >0985,>1790,AA0B,>B0CD,> 05D0,>0300

 

But when I do a GPL command

 

SOND EQU >832C

S1620 DATA >0985,>1790,AA0B,>B0CD,> 05D0,>0300

MKSND DST S1620,@SOND

GPLIO I/O 0,@SOND

 

This produces garbled sounds for about 1 minute.

 

Yet CALL SOUND(200,440,0,880,0,523,0) is DATA >098E,>F090,>AF07,>B0C6,>0D0C,>0000

And pretty much works exactly as it is suppose to.

 

I would say 90% of the ones I have converted do not work correctly. Something major is missing in the data on sounds in GPL and how they work.

 

So I guess I going to have to disassemble tons of games wrtiten in GPL to see what the heck is going on.

 

Assembly does a great job but sucks at Autosound during a game. Funny that I never had to do this before as I never wrote games in GPL before.

 

 

 

Hmmmmmmm. Perhaps it is not assembly that sucks at sound processing but rather your understanding of sound processing. I think you need to go back to step 1 and try again.....

 

My point about Assembly was you have to manage every single millisecond of the Sound processing in Assembly, this is just a fact.

The I/O command in GPL just runs the list and takes care of the interrupts for you, but some information is missing on what sounds are allowed and are not.

Like I said before if you try GPL you will see for yourself that this is happening.

Example: 1620 CALL SOUND(50,300,0,600,0,1200,0)

50,300,0=>-365,>1770,>0300

50,600,0=>038A,>0B90,>0300

50,1200,0=>03AD,>05B0,>0300

This converted for generators 0, 1, 2 would be: >0985,>1790,>AA0B,>B0CD,>05D0,>0000

You add >03 three times so that is the generators used and the last bytes are the duration >0300 and Assembly needs >0000 but GPL only needs one byte.

I just have to find out why it does not stop playing on some sound lists and other it does stop like expected.

Edited May 16, 2011 by RXB

[+retroclouds]

Well I am pretty perplexed on this. When I take a sound that I generate with the SOUNDTABLE converters I get sound lists that look correct.

 

The sample I posted, a Basic program that is from the Computes guide to TI99/4A programming.

 

Example: CALL SOUND(50,300,0,600,0,1200,0) from BASIC converted would be DATA >0985,>1790,AA0B,>B0CD,> 05D0,>0300

 

But when I do a GPL command

 

SOND EQU >832C

S1620 DATA >0985,>1790,AA0B,>B0CD,> 05D0,>0300

MKSND DST S1620,@SOND

GPLIO I/O 0,@SOND

 

This produces garbled sounds for about 1 minute.

 

Yet CALL SOUND(200,440,0,880,0,523,0) is DATA >098E,>F090,>AF07,>B0C6,>0D0C,>0000

And pretty much works exactly as it is suppose to.

 

I would say 90% of the ones I have converted do not work correctly. Something major is missing in the data on sounds in GPL and how they work.

 

So I guess I going to have to disassemble tons of games wrtiten in GPL to see what the heck is going on.

 

Assembly does a great job but sucks at Autosound during a game. Funny that I never had to do this before as I never wrote games in GPL before.

 

 

 

Hmmmmmmm. Perhaps it is not assembly that sucks at sound processing but rather your understanding of sound processing. I think you need to go back to step 1 and try again.....

 

My point about Assembly was you have to manage every single millisecond of the Sound processing in Assembly, this is just a fact.

The I/O command in GPL just runs the list and takes care of the interrupts for you, but some information is missing on what sounds are allowed and are not.

Like I said before if you try GPL you will see for yourself that this is happening.

Example: 1620 CALL SOUND(50,300,0,600,0,1200,0)

50,300,0=>-365,>1770,>0300

50,600,0=>038A,>0B90,>0300

50,1200,0=>03AD,>05B0,>0300

This converted for generators 0, 1, 2 would be: >0985,>1790,>AA0B,>B0CD,>05D0,>0000

You add >03 three times so that is the generators used and the last bytes are the duration >0300 and Assembly needs >0000 but GPL only needs one byte.

I just have to find out why it does not stop playing on some sound lists and other it does stop like expected.

 

Don't you have to add an additional data statement for muting the sound generators, otherwise the last tone keeps playing ?

[marc.hull]

Well I am pretty perplexed on this. When I take a sound that I generate with the SOUNDTABLE converters I get sound lists that look correct.

 

The sample I posted, a Basic program that is from the Computes guide to TI99/4A programming.

 

Example: CALL SOUND(50,300,0,600,0,1200,0) from BASIC converted would be DATA >0985,>1790,AA0B,>B0CD,> 05D0,>0300

 

But when I do a GPL command

 

SOND EQU >832C

S1620 DATA >0985,>1790,AA0B,>B0CD,> 05D0,>0300

MKSND DST S1620,@SOND

GPLIO I/O 0,@SOND

 

This produces garbled sounds for about 1 minute.

 

Yet CALL SOUND(200,440,0,880,0,523,0) is DATA >098E,>F090,>AF07,>B0C6,>0D0C,>0000

And pretty much works exactly as it is suppose to.

 

I would say 90% of the ones I have converted do not work correctly. Something major is missing in the data on sounds in GPL and how they work.

 

So I guess I going to have to disassemble tons of games wrtiten in GPL to see what the heck is going on.

 

Assembly does a great job but sucks at Autosound during a game. Funny that I never had to do this before as I never wrote games in GPL before.

 

 

 

Hmmmmmmm. Perhaps it is not assembly that sucks at sound processing but rather your understanding of sound processing. I think you need to go back to step 1 and try again.....

 

My point about Assembly was you have to manage every single millisecond of the Sound processing in Assembly, this is just a fact.

The I/O command in GPL just runs the list and takes care of the interrupts for you, but some information is missing on what sounds are allowed and are not.

Like I said before if you try GPL you will see for yourself that this is happening.

Example: 1620 CALL SOUND(50,300,0,600,0,1200,0)

50,300,0=>-365,>1770,>0300

50,600,0=>038A,>0B90,>0300

50,1200,0=>03AD,>05B0,>0300

This converted for generators 0, 1, 2 would be: >0985,>1790,>AA0B,>B0CD,>05D0,>0000

You add >03 three times so that is the generators used and the last bytes are the duration >0300 and Assembly needs >0000 but GPL only needs one byte.

I just have to find out why it does not stop playing on some sound lists and other it does stop like expected.

 

That appears to be a sound list for the console player which correct me if I am wrong is written in assembly ? As far as managing every single micro second goes..... That is simply not the case. I don't understand why you think assembly is such a poor choice for programming ???

[sometimes99er]

My point about Assembly was you have to manage every single millisecond of the Sound processing in Assembly, this is just a fact.

Not true.

[RXB]

Well I am pretty perplexed on this. When I take a sound that I generate with the SOUNDTABLE converters I get sound lists that look correct.

 

The sample I posted, a Basic program that is from the Computes guide to TI99/4A programming.

 

Example: CALL SOUND(50,300,0,600,0,1200,0) from BASIC converted would be DATA >0985,>1790,AA0B,>B0CD,> 05D0,>0300

 

But when I do a GPL command

 

SOND EQU >832C

S1620 DATA >0985,>1790,AA0B,>B0CD,> 05D0,>0300

MKSND DST S1620,@SOND

GPLIO I/O 0,@SOND

 

This produces garbled sounds for about 1 minute.

 

Yet CALL SOUND(200,440,0,880,0,523,0) is DATA >098E,>F090,>AF07,>B0C6,>0D0C,>0000

And pretty much works exactly as it is suppose to.

 

I would say 90% of the ones I have converted do not work correctly. Something major is missing in the data on sounds in GPL and how they work.

 

So I guess I going to have to disassemble tons of games wrtiten in GPL to see what the heck is going on.

 

Assembly does a great job but sucks at Autosound during a game. Funny that I never had to do this before as I never wrote games in GPL before.

 

 

 

Hmmmmmmm. Perhaps it is not assembly that sucks at sound processing but rather your understanding of sound processing. I think you need to go back to step 1 and try again.....

 

My point about Assembly was you have to manage every single millisecond of the Sound processing in Assembly, this is just a fact.

The I/O command in GPL just runs the list and takes care of the interrupts for you, but some information is missing on what sounds are allowed and are not.

Like I said before if you try GPL you will see for yourself that this is happening.

Example: 1620 CALL SOUND(50,300,0,600,0,1200,0)

50,300,0=>-365,>1770,>0300

50,600,0=>038A,>0B90,>0300

50,1200,0=>03AD,>05B0,>0300

This converted for generators 0, 1, 2 would be: >0985,>1790,>AA0B,>B0CD,>05D0,>0000

You add >03 three times so that is the generators used and the last bytes are the duration >0300 and Assembly needs >0000 but GPL only needs one byte.

I just have to find out why it does not stop playing on some sound lists and other it does stop like expected.

 

Don't you have to add an additional data statement for muting the sound generators, otherwise the last tone keeps playing ?

 

Yea but even if I do it still keeps playing. Like I said even muting does not seem to shut it up. It is like a crap shoot to what works and does not.

 

Like when I play the Accept tone or Honk tone they do not need a mute or stop to quit playing but most of the ones I make do.

[RXB]

Well I am pretty perplexed on this. When I take a sound that I generate with the SOUNDTABLE converters I get sound lists that look correct.

 

The sample I posted, a Basic program that is from the Computes guide to TI99/4A programming.

 

Example: CALL SOUND(50,300,0,600,0,1200,0) from BASIC converted would be DATA >0985,>1790,AA0B,>B0CD,> 05D0,>0300

 

But when I do a GPL command

 

SOND EQU >832C

S1620 DATA >0985,>1790,AA0B,>B0CD,> 05D0,>0300

MKSND DST S1620,@SOND

GPLIO I/O 0,@SOND

 

This produces garbled sounds for about 1 minute.

 

Yet CALL SOUND(200,440,0,880,0,523,0) is DATA >098E,>F090,>AF07,>B0C6,>0D0C,>0000

And pretty much works exactly as it is suppose to.

 

I would say 90% of the ones I have converted do not work correctly. Something major is missing in the data on sounds in GPL and how they work.

 

So I guess I going to have to disassemble tons of games wrtiten in GPL to see what the heck is going on.

 

Assembly does a great job but sucks at Autosound during a game. Funny that I never had to do this before as I never wrote games in GPL before.

 

 

 

Hmmmmmmm. Perhaps it is not assembly that sucks at sound processing but rather your understanding of sound processing. I think you need to go back to step 1 and try again.....

 

My point about Assembly was you have to manage every single millisecond of the Sound processing in Assembly, this is just a fact.

The I/O command in GPL just runs the list and takes care of the interrupts for you, but some information is missing on what sounds are allowed and are not.

Like I said before if you try GPL you will see for yourself that this is happening.

Example: 1620 CALL SOUND(50,300,0,600,0,1200,0)

50,300,0=>-365,>1770,>0300

50,600,0=>038A,>0B90,>0300

50,1200,0=>03AD,>05B0,>0300

This converted for generators 0, 1, 2 would be: >0985,>1790,>AA0B,>B0CD,>05D0,>0000

You add >03 three times so that is the generators used and the last bytes are the duration >0300 and Assembly needs >0000 but GPL only needs one byte.

I just have to find out why it does not stop playing on some sound lists and other it does stop like expected.

 

That appears to be a sound list for the console player which correct me if I am wrong is written in assembly ? As far as managing every single micro second goes..... That is simply not the case. I don't understand why you think assembly is such a poor choice for programming ???

 

Again I did not say that. I was saying Assembly has NO AUTO SOUND which is absolutely true. That is the whole point of Assembly in that you have total control, therefore much more work.

You have to load more and manage more just a fact. It is not worse just more work, which again is the point of Assembly. I am just pointing out a fact of life here.

[RXB]

Well I am pretty perplexed on this. When I take a sound that I generate with the SOUNDTABLE converters I get sound lists that look correct.

 

The sample I posted, a Basic program that is from the Computes guide to TI99/4A programming.

 

Example: CALL SOUND(50,300,0,600,0,1200,0) from BASIC converted would be DATA >0985,>1790,AA0B,>B0CD,> 05D0,>0300

 

But when I do a GPL command

 

SOND EQU >832C

S1620 DATA >0985,>1790,AA0B,>B0CD,> 05D0,>0300

MKSND DST S1620,@SOND

GPLIO I/O 0,@SOND

 

This produces garbled sounds for about 1 minute.

 

Yet CALL SOUND(200,440,0,880,0,523,0) is DATA >098E,>F090,>AF07,>B0C6,>0D0C,>0000

And pretty much works exactly as it is suppose to.

 

I would say 90% of the ones I have converted do not work correctly. Something major is missing in the data on sounds in GPL and how they work.

 

So I guess I going to have to disassemble tons of games wrtiten in GPL to see what the heck is going on.

 

Assembly does a great job but sucks at Autosound during a game. Funny that I never had to do this before as I never wrote games in GPL before.

 

 

 

Hmmmmmmm. Perhaps it is not assembly that sucks at sound processing but rather your understanding of sound processing. I think you need to go back to step 1 and try again.....

 

My point about Assembly was you have to manage every single millisecond of the Sound processing in Assembly, this is just a fact.

The I/O command in GPL just runs the list and takes care of the interrupts for you, but some information is missing on what sounds are allowed and are not.

Like I said before if you try GPL you will see for yourself that this is happening.

Example: 1620 CALL SOUND(50,300,0,600,0,1200,0)

50,300,0=>-365,>1770,>0300

50,600,0=>038A,>0B90,>0300

50,1200,0=>03AD,>05B0,>0300

This converted for generators 0, 1, 2 would be: >0985,>1790,>AA0B,>B0CD,>05D0,>0000

You add >03 three times so that is the generators used and the last bytes are the duration >0300 and Assembly needs >0000 but GPL only needs one byte.

I just have to find out why it does not stop playing on some sound lists and other it does stop like expected.

 

That appears to be a sound list for the console player which correct me if I am wrong is written in assembly ? As far as managing every single micro second goes..... That is simply not the case. I don't understand why you think assembly is such a poor choice for programming ???

 

Again I did not say that. I was saying Assembly has NO AUTO SOUND which is absolutely true. That is the whole point of Assembly in that you have total control, therefore much more work.

You have to load more and manage more just a fact. It is not worse just more work, which again is the point of Assembly. I am just pointing out a fact of life here.

If Assembly was number one then no one would be using C or any other language. But they do for very good reasons, the facts I just pointed out.

 

(If Microsoft and Mac wrote in only Assembly then most likely we would not have the billions of bugs we have as C just pushes more bad subroutines onto the stack everyday.)

Edited May 16, 2011 by RXB

[John Doe]

Edited February 22, 2014 by Tony Knerr

[John Doe]

Edited February 22, 2014 by Tony Knerr