Interfaccia di Arduino alla porta del nastro di C64

Aggiornamento : un'implementazione pratica di questo viene fatta nel progetto Tapuino realizzato da Peter Edwards. Dai un'occhiata, tutto è open source: https://github.com/sweetlilmre/tapuino

Sto lavorando a un progetto in cui sto usando il mio Arduino per trasmettere in streaming i file di dati del nastro TAP dal mio PC al C64. Il lato software del progetto sta andando bene, ma sono ancora nuovo nell'elettronica e non mi piace friggere il mio Commodore. Quindi ho davvero bisogno di aiuto per l'interfacciamento hardware.

I nastri C64 utilizzano la modulazione PWM per memorizzare il programma su nastro a cassetta e sulla lettura dei dati un trigger opamp + schmitt converte il segnale audio in onde quadrate. Ogni transizione alto-basso fa scattare un interrupt nella macchina e la distanza tra due interrupt (che è la lunghezza dell'impulso) rappresenta una parte atomica del flusso.

La piedinatura della porta della cassetta si presenta così (la parte superiore e quella inferiore hanno gli stessi pin due volte):

A-1 , GND, Terra

B-2 , + 5 V, 5 Volt CC

C-3 , MOTORE, Controllo motore, ca. Alimentazione a 6 Volt del motore

D-4 , LEGGI, Inserimento dati, leggi i dati dal set di dati

E-5 , WRITE, Output dei dati, scrivere i dati nel set di dati

F-6 , SENSE, Detection, se viene premuto uno dei tasti PLAY, RECORD, F.FWD o REW

La mia idea attuale è la seguente:

Basato sul C64 Interfacing Blue Book (a partire da pagina 29), la macchina utilizza il livello TTL sulla porta READ e WRITE, quindi immagino di poter collegare direttamente un pin PWM dall'Arduino al pin READ.

Devo anche interfacciarmi con il pin SENSE. Penso di poterlo collegare direttamente anche a uno dei PIN digitali e scrivere LOW digitale lì quando devo segnalare lo stato del pulsante premuto. È corretto?

Successivamente desidero rilevare la presenza del segnale + 6V sul pin MOTORE. Alcuni caricatori interrompono il set di dati nel mezzo del processo di caricamento, quindi devo rilevare anche questo per emulare correttamente il nastro. Dovrei usare un qualche tipo di resistenza per limitare la corrente lì o posso anche collegarlo direttamente? Forse dovrei usare un relè lì?

Secondo il documento fornito, la porta del set di dati è alla ricerca di un segnale digitale puro con ciclo di lavoro variabile (0,75 per H, 0,25 per L).

Finché il pin Arduino può pilotare una corrente sufficiente (dovrebbe essere in grado di farlo) e funziona a 5 V, funzionerà una connessione diretta. Potresti voler investigare usando un buffer TTL tra Arduino e C64 (il buffer sarebbe alimentato dall'alimentazione +5 della porta del datasette e il terreno sarebbe comune sia al C64 che ad Arduino).

Per quanto riguarda il SENSE, sarebbe più semplice utilizzare un'uscita digitale per pilotare un MOSFET a segnale piccolo (come un 2N7002) - un alto logico attiva il MOSFET, che tira a terra il pin SENSE (collegato allo scarico) alla fonte) senza che Arduino debba sprofondare alcuna corrente.

Il pin MOTOR può anche essere usato per pilotare un gate MOSFET. Lo scarico verrebbe portato alla tensione di alimentazione di Arduino con un pullup debole (circa 10k), la sorgente collegata a terra. Lo scarico andrebbe anche a un pin logico digitale. Quando MOTOR è alto, l'ingresso logico è basso e viceversa, e Arduino vede un segnale logico pulito.

Per esempio...

Nota usando due porte NAND come una sorta di buffer. (Puoi dire che ero solito scroccare per le parti?)

TTL è abbastanza robusto. Non credo che ci siano molte possibilità di danneggiare qualcosa.

Suona come un progetto interessante. Il mio ricordo è che l'hardware del VIC-20 ha alimentato gli impulsi della Datasette in un circuito di rilevamento dei bordi (dimentico se ha rilevato fronti di salita o di discesa); le routine di caricamento su nastro C64 erano compatibili con quelle del VIC-20, quindi non credo che il caricatore standard avrebbe potuto usare qualsiasi trucco che il VIC-20 non avrebbe supportato, anche se i caricatori personalizzati potrebbero. Nel corso della giornata non ho mai giocato con roba abbastanza per determinare se la stessa Datasette ha convertito sia i fronti di salita che di discesa in impulsi (ad esempio, alimentando un segnale ritardato e non ritardato in un gate XOR). Ho escogitato una routine per convertire i dati in ampiezze di impulsi, ma non ho mai capito come usare il rilevatore di bordi.

Per quanto riguarda il trasferimento di dati dal PC al C64, se non si desidera utilizzare una scheda audio (alcune schede audio hanno l'elaborazione di immagini stereo e tali da provocare il caos con la fase dell'audio in uscita) ci sono due approcci I potrebbe suggerire: (1) inviare dati ad intervallo di impulsi dal PC ad Arduino e semplicemente disporre del tempo di Arduino per singoli impulsi in uscita. Forse codificare il formato dei dati con due impulsi per byte, usando qualcosa come la seguente codifica:

Funzionamento1100 - Emette un massimo di 20us seguito da un minimo di 24-60us (in multipli di 3us)
1101 - Uscita 40us bassa
1110 - Uscita 80us bassa
1111 - I valori byte di $ FF verranno ignorati
          - Altri ciao con una stretta pari a 1111 potrebbero essere usati per simulare il
             pulsanti del motore del nastro o indicare un'indicazione "ok per mettere in pausa qui".

Non credo che alcuno schema di caricamento proverà a cronometrare gli impulsi con una precisione migliore di 3us, e questo schema consentirebbe l'invio di dati su un UART a 115200. Il PC dovrebbe aggiungere byte di riempimento 0xFF in modo che la velocità con cui i dati vengono inviati a l'Arduino corrisponderà ragionevolmente bene alla velocità con cui l'Arduino lo sta registrando. Poiché ogni nybble impiegherà tra i 44 e gli 80 microsecondi per l'elaborazione, l'Arduino dovrebbe solo eseguire il polling del proprio UART tra i nybbles e potrebbe disabilitare gli interrupt vicino alla fine di ciascun impulso. Se il PC esegue il pading dei dati in modo abbastanza efficace, si potrebbe (1) far sì che il PC tenti di inviare i dati leggermente più velocemente di quanto Arduino li emetterebbe, e utilizzare l'handshaking hardware o software per rallentarli, oppure (2) avere Arduino radere un microsecondo da ogni impulso quando il suo buffer è quasi pieno, oppure aggiungi un microsecondo a ciascun impulso quando il suo buffer è quasi vuoto. Per evitare il risultato di anomalie audio dovute a momentanei singhiozzi del PC, si potrebbe fare in modo che Arduino sospenda l'output in un byte "okay to pause here" se il suo buffer non è quasi pieno.