Falls niemand fertigen Code hat, scheint die serielle Ansteuerung hier recht gut beschrieben zu sein:
sparks.gogo.co.nz/jq6500/serial.html
Hast Du Dir wahrscheinlich auch schon einmal angesehen die Seite.
Wie gesagt: Falls niemand etwas Fertiges hat.

Dann könntest Du ja einmal Gnd mit Gnd verbinden.
Dann Tx vom Mikrocontroller (über einen 1k-Widerstand) an Rx vom Modul:
If you are communicating from a 5v device, it is sufficient to put a 1k resistor in series between the TX on your 5v device and the RX on the JQ6500.

Und dann mit PRINTBIN die angegebene Folge an das Modul senden:

1. 0x7E – Start Byte
   
2. 0x02 – 2 Bytes Follow
   
3. 0x0D – Command Byte
   
4. 0xEF – Termination Byte
   

Siehe:
avrhelp.mcselec.com/index.html?printbin.htm

Mit Semikolon,
Printbin &H7E ; 2 ; 13 ; &HEF

Schau dir mal im Lexikon den Beitrag zum DF-Player-Mini an.
Für den habe ich mal eine Bibliothek entwickelt.
Beim JQ6500 ist die Befehlsfolge IMHO ähnlich so dass man daraus ableiten kann wie der im Gegensatz zum DFPM funktioniert.

Ich habe mal ein Ansagemodul entwickelt dass wohl mit dem anderen Modul (da gibt es mindestens zwei verschiedene ohne SD-Karte die aber alle ähnlich arbeiten).
Da kannst du ja sehen wie das mit der seriellen Steuerung funktioniert.
Zeitansage V1.png
Ansagemodul V1.bas

Ja und auch am Ende weil da sonst noch CRLF nachkommt und das mögen die Module auch wieder nicht.
Diese Module erwarten alle einen Befehlsstring aus einer Mindestanzahl (je nach Modul sogar immer acht oder zehn Bytes je nach dem ob auch noch die CheckSum mitkommt) an Byte (welche auch Null-Bytes sein können!) wo auch im String Chr(13) und/oder Chr(10) vorkommen können!

Nur beim normalem Print. Das Printbin sendet nur was es bekommt.
Es stört aber auch nicht. Der Compiler ignoriert es einfach.

Fast genau so geht es doch:

„the command to play a specific file (0x012) has two arguments (folder number and file number) so it looks like this

1. 0x7E – Start
   
2. 0x04 – 4 Bytes Follow
   
3. 0x12 – Command
   
4. 0x02 – 1st Argument (in this case, “Folder 02”)
   
5. 0x03 – 2nd Argument (in this case, “File 003”)
   
6. 0xEF – Termination Byte“
   

Also einmal PRINTBIN wie oben beschrieben.

Schreib‘ doch einmal ein kleines Testprogramm, um Dich heranzutasten. Wenn es dann hakt, dann beschreibe Deine Verschaltung und poste das (kompilierbare) Programm.

ich "vermute" mal, dass Du Dich im Hauptprogramm nicht um die einzelnen Commands kümmern möchtest. Benutze in diesem Fall einfach Unterroutinen.

Für das Abspielen eines bestimmten Liedes in einem bestimmten Ordner könnte die Unterroutine z.B. so aussehen (ungetestet):




Im Hauptprogramm müsstest Du dann nur noch die Routine aufrufen und den gewünschten Ordner sowie das gewünschte Lied als Parameter übergeben, z.B. so:


oder so

Der ATtiny13 hat keinen HW-UART
ww1.microchip.com/downloads/en/devicedoc/doc2535.pdf
Da siehst Du beim Pinout nichts von Tx.

Versuche es mit Software-UART.
avrhelp.mcselec.com/index.html?uart.htm
Unten auf der Hilfeseite.

So etwas wie:
open "COMB.4:9600,8,N,1" For Output As #2
Printbib #2 , xxxx ;



Und da ich nicht weiß, wieviel Erfahrungen Du mit BASOM hast:
Achte darauf, dass der Wert bei $crystal dem entsprechen muss, wie schnell derATtiny13 laut Fuses tatsächlich läuft und, dass der ATtiny13 weniger Stack hat. An besten schreib erst einmal ein Programm ohne Software-UART und lass nur eine LED im Sekundentakt blinken. Dann die Software-UART-Thematik einbauen.

Standardmäßig - also im Auslieferungszustand - läuft ein ATtiny13 mit 1,2 MHz.
Besser für die serielle Datenübertragung ist es, wenn Du in den Fusebits den Teiler DIV 8 deaktivierst und dann Dein ATtiny13 mit 9,6 MHz läuft. Dann ist der Baudratenfehler kleiner. Ein interner Oszillator gilt sowieso als nicht so optimal für serielle Übertragungen.

Aus dem Datenblatt des ATtiny13:
6.2.4 Default Clock Source
The device is shipped with CKSEL = “10”, SUT = “10”, and CKDIV8 programmed. The default
clock source setting is therefore the Internal RC Oscillator running at 9.6 MHz with longest startup
time and an initial system clock prescaling of 8.

Default ist also ein Takt von 9,6 MHz / 8 = 1,2 MHz
Wenn Du nichts an den Fuses gemacht hast, läuft Dein Attiny13 also mit 1,2 MHz und Du musst auch $Crystal = 1200000 schreiben.
Wenn Du den ATtiny13 mir 9,6 MHz laufen lassen möchtest - was den Baudratenfehler rechnerisch etwas kleiner macht - dann musst Du entsprechend in den Fusebits den Teiler durch 8 deaktivieren und dann darfst/musst Du auch $Crystal = 9600000 schreiben.


Program - Send to Chip - Manual Program - Lock and Fuse bits - Divide Clock by 8
bzw.
Programmieren - zum Chip senden - Manuell programmieren - Lock and Fuse bits - Divide Clock by 8Fusebits.jpg

Guck Dir mittelfristig auch einmal den DEBOUNCE-Befehl von BASCOM an.
avrhelp.mcselec.com/index.html?debounce.htm
Es ist sicherlich nicht gut, den Befehl tausendfach hintereinander an das Soundmodul zu senden, solange der Taster gedrückt ist. Mit DEBOUNCE wird der Tasterzustand abgefragt. Wenn der Taster gedrückt wird, dann wird das Kommando einmal ausgeführt und vor der erneuten Aussendung muss der Taster zunächst einmal wieder losgelassen worden sein. Auch Tastenprellen wird mit DEBOUNCE durch eine kleine Wartezeit abgefangen. (Daher der Name DEBOUNCE)

Wichtig ist bei serieller Übertragung übrigens immer, dass mit genau der Geschwindigkeit gesendet wird, wie es der Empfänger (hier das Soundmodul) erwartet. Man muss also immer im Datenblatt oder bei den technischen Daten oder in funktionierenden Beispielprogrammen nachsehen, welche Übertragungsgeschwindigkeit vom Empfänger erwartet wird. Genau das muss man dann auch beim Sender einstellen.

Lies Dir bei Gelegenheit auch einmal den Lexikoneintrag bezüglich Stack durch:
Speicheraufbau

sorry: Printbin natürlich.

Für die Version des Soundmoduls mit eingebautem Speicher (also keine Speicherkarte) hier ein kleines Testbeispiel:

Soft-UART-Ansteuerung eines JQ6500 Soundmoduls (Version mit integriertem Speicher)