Sound list library?

[senior_falcon]

Seems to me there is a sound list library that offers music and sound effects for assembly language program developers. Is my memory right, and if so then where would I find it.

Thanks!

[+retroclouds]

Marc Hull made a sound player that offers such sound effects. Look for the advanced sound list player at dsapc.com

[TI-Sissy]

Marc Hull made a sound player that offers such sound effects. Look for the advanced sound list player at dsapc.com

it looks like a dead page. comes up go daddy.

[+retroclouds]

Guess I screwed up the URL. Here's the link:

 

http://www.dsapsc.com/new-developments.html

[Asmusr]

Are any collections of interesting sound effects in assembly sound list format available?

[senior_falcon]

Attached is a short assembly language object code file called MAKEHM-O. This is used to make a TI BASIC loader that loads an assembly language program into the memory expansion starting at >A000. Here's how to use it;

1 - Write your assembly program and assemble it into object code. (No AORG's please)

2 - Go to TI BASIC.

3 - CALL INIT

4 - CALL LOAD("DSKn.ALPROG-O") this will load the assembly program starting at >A000

5 - CALL LOAD('DSKn.MAKEHM-O")

6 - CALL LOAD(-31804,240) now the loader has been created with your program embedded

7 - SAVE DSKn.PROGNAME

 

When you run this BASIC program your assembly code will be copied back to >A000, then program execution starts at >A000. Registers and character tables are set to the standard TI BASIC values and the workspace is >83E0.

 

Because this runs out of BASIC there can be a cartridge in the slot and your assembly program can look into the cartridge ROM and GROM. It shouldn't be too hard to write a program that finds all the sound lists in a cartridge and saves them to disk as a text file. Here's some ideas in case anyone is interested in tackling this:

 

In a sound list, the first byte is the number of bytes to send to the sound processor. That will be from 1 to 11. The next byte will be >8000 or higher. Add the first byte to the starting address and increment. That points to the duration byte. That would almost certainly be less than 60 which would be one second. If it passes these tests then it could be a sound list. Keep looping until it either fails or comes to a duration of 0 which occurs at the end of a sound list. If you get that far then it is almost certainly a sound list, so open up a disk file and write the bytes to it in a way the assembler can use. (Sound lists can loop and so you need to test for that as well.)

 

With a little effort, the sound lists from all the cartridges could be collected into a library and put in the development resources section.

 

Any takers?

 

 

 

MAKEHM-0.zip

[Asmusr]

It's amazing how many things the escape-from-the-sandbox trick can be used for, but if I was to look for sound lists I would probably just dump the memory from Classic99 and do the searching and exporting on a PC. Perhaps that's cheating, but it would be much more efficient.

[senior_falcon]

No cheating about it if it works! I don't see any provision for dumping GROM in Classic99. Also, the memory dump does not support paged memory. So there is a good chance that some soundlists would be missed. Once dumped it looks like you have a binary file and then you'd have to search that on the PC side. You might be able to do that from a PC, but it sure wouldn't be more efficient for me, as I would not have a clue even how to begin.

[Tursi]

One thing you /can/ do in Classic99 is breakpoint on write to the sound chip (>8400). When the breakpoint triggers, you can look back in the assembly and see where it's pulling sound data from... for cartridges with console ROM-based sound lists, it'll always stop in the interrupt code and you can just check >83CC to see where the sound list is coming from.

 

For instance, I used this technique to find Alpiner's title music:

 

-I selected Alpiner in Classic99.

-Press any key to enter the selection list

-BEFORE selecting the game, I made sure scroll-lock was on and brought up the debugger window

-I entered a breakpoint for writes to the sound chip, with ">8400"

-Press '2' for English (or your choice of language) - the console will breakpoint right away for the selection beep

-Check the Disasm view, and it should be stopped at 0A38, right after the statement "movb *r6,@>8400", which is the write to the sound chip from the console interrupt routine.

-Switch to the CPU memory view and enter "8300" to view scratchpad memory. There are two addresses you are interested in:

--83FD - Check the least significant bit, if it is 0 (the number is even), then the sound list is in GROM, otherwise it is in VDP RAM - for this case, we see "08" which means GROM

--83CC - two byte address of the sound list -- at the first entry it is NOT yet incremented, so contains the first address. At this point it shows "0479"

-If you switch to the GROM view and enter "0479". The sound list format is "number of bytes, data bytes, delay byte" - a zero delay marks the end of the list. At 0479 in GROM we see "06 BF DF FF 80 05 92 0A 01 9F 00" - it writes 6 bytes which mutes channels 2,3,4, then writes a tone to channel 1 and waits for 10 frames. After that, it writes one more byte which mutes channel 1. This is the console accept tone.

-At this point, if you hit F1 it will breakpoint for every byte that it writes.. which is slightly annoying, but just keep track. For this short list, it should only be seven times. (You can also watch R8 count down for you - it will count down the 6 bytes, then the 1 byte parts).

-At this point the game will launch and the title will appear, then it will breakpoint again. Disasm confirms that it's in the console interrupt, so we can look at the pointers. 83FD confirms GROM, and 83CC says 90A5.

-Open GROM to 90A5, and we see a short sound list "04 9F BF DF FF 00" - this just mutes all four channels. We aren't interesting in this one, so we can step through it (again, watching R8 count down on each press of F1 to continue is easiest for me)

-When it breaks again (quite quickly), 83CC now shows "91B9". A look at "91B9" in GROM shows a much longer soundlist starting with "03 C9 3F D4 12 01 DF 06...". If we remove the breakpoint and continue, it plays the title music. A likely candidate! How do we prove it?

-Press QUIT (ALT-=") or reset back to the menu. If that really is a soundlist, we can easily use the debugger to make it play on the master title screen.

-Go back to the CPU view, and make sure that the LSB of 83FD is cleared for GROM (it should be 08 still, which is correct for our needs).

-Enter the address of the playlist into 83CC. Classic99's debugger only takes bytes, so you have to enter "C83CC=91" and then "C83CD=B9". Make sure the values have taken in the memory view.

-Start playback with "C83CE=1"

[Tursi]

Of course... that's just one way. If you KNOW it's a sound list you are after played through the console ROM routine, it occurs to me that it's probably easier just to breakpoint on writes to >83CD and watch for the program to write the address.

[Asmusr]

No cheating about it if it works! I don't see any provision for dumping GROM in Classic99. Also, the memory dump does not support paged memory. So there is a good chance that some soundlists would be missed. Once dumped it looks like you have a binary file and then you'd have to search that on the PC side. You might be able to do that from a PC, but it sure wouldn't be more efficient for me, as I would not have a clue even how to begin.

 

Actually, if you can identify sound lists just by looking at byte patterns you could just analyze the raw ROM/GROM/EA5 files - no need to involve a TI-99/4A at all. I would write a small Java program, but you could perhaps also use an advanced hex editor?

[senior_falcon]

That's the difference between you and me - you have the ability to write a java program. I would have to make a cup of java, then sit at the Ti-99 to get it done.

[+OLD CS1]

I, for one, rather enjoy the native way of doing things, less efficient or not. It helps keep the brain sharp.