Ready64 Forum
Commodore 64 => Programmazione, Grafica e Musica => Topic aperto da: Fabbroz75 - 23 Giugno 2006, 08:40:22
-
Anni fa ( e non ricordo come e quando ) qualcuno riusci' ad utilizzare il 6510 del 1541 come secondo processore.
qualcuno ha provato a fare qualcosa in asssembly?
sarebbe interessante utilizzarlo per programmi o giochi.
-
Ciao. Sarebbe bello approfondire questo argomento. Pensa che proprio un paio di sere fa mi era saltato in testa il pensiero circa l'utilizzo contemporaneo della RAM del 1541. :sabber:
Tanto i lettori floppy Commodore (mi sa che non tutti i "più giovani" lo sanno), erano dei piccoli computer con propri processore, ram e sistema operativo (il Commodore DOS) che dialogavano e interagivano con quelli degli home :c64:
Ian Coog aveva comunque fatto il nome di un solo programma che sfruttava la cosa..... mah ho dimenticato il nome... spero che legga qui e lo riscriva; comunque come ha detto giustamente lui, questa branca è roba per rari specialisti.
-
Su C64 ho poca eseprienza di Asm... contrariamente ad Amiga e 68000 in generale.
penso sarebbe una bella sfida... e potrebbe portare a sviluppo di applicativi interessanti.
Appena mi arriva il Sid2Sid completo, porvero' a gestirlo.
Pensa che mi è saltato in mente di sfuttare il vic20 + il processore del 1541... interessante vedere cosa accade.
-
Il drive coding e' un casino anche solo per quanto riguarda il fare da zero un semplice fastloader, non parliamo poi di far elaborare dati dal 1541 per poi farli rispedire al 1541. Come gia' dicevo in chat, meglio pensare a queste cose solo quando si sa benissimo cosa si sta facendo.
Il demo piu' recente che io conosca che utilizzi il 1541 come processore aggiuntivo e' Panta Rhei - Coopdemo di 3 gruppi: Plush+Insinct+Oxyron - e non e' certo roba per i nostri denti.
QUESTO (http://iancoog.altervista.org/hid/%23c-64.20051230-pantarhei.txt) e' un estratto epurato di una discussione a riguardo, svoltasi su #c-64@ircnet
Io non ci ho capito quasi niente, se non che i dati vengono elaborati dal 1541 e poi il C64 li ottiene man mano quando ne ha elaborati un po'.
Una cosa e' sicura: bisogna studiarsi Inside Commodore DOS, oltre ad avere una conoscenza tale da NON aver bisogno della programmers ref. guide.
-
Insomma il casino sta' nella sincronizzazione da quanto si capisce... Drive e C64 hanno tempi diversi e per non avere rallentamenti assurdi occorre sincronizzarli perfettamente.
Da quel che dicono, il resto e' piu' una routine di trasferimento dati tra le due macchine.
Oppure c'è altro?
-
Che effetti Panta Rei!!! :o
Chissà la resa visiva su postazione e schermo Pal reale.
-
Ho voluto fare un pò di reversing sulle routines del DOS e del kernal che gestiscono l'I/O sul bus seriale.
Qui di seguito riporto i disassemblati relativi alla trasmissione dei dati dal C64 al drive 1541
KERNAL (trasmissione)
ED62 LDA #$08
ED64 STA $A5
ED66 LDA $DD00
ED69 CMP $DD00
ED6C BNE $ED66 ;legge porta
ED6E ASL
ED6F BCC $EDB0
ED71 ROR $95
ED73 BCS $ED7A
ED75 JSR $EEA0 ;bit 0,alza data_out
ED78 BNE $ED7D
ED7A JSR $EE97 ;bit 1,abbassa data_out
ED7D JSR $EE85 ;abbassa ck_out
ED80 NOP
ED81 NOP
ED82 NOP
ED83 NOP
ED84 LDA $DD00
ED87 AND #$DF ;ok,abbassa data_out
ED89 ORA #$10
ED8B STA $DD00 ;ok,alza clock_out
ED8E DEC $A5 ;invia prossimo bit
ED90 BNE $ED66
...
DOS (ricezione)
EA0B LDA $1800
EA0E EOR #$01
EA10 LSR
EA11 AND #$02
EA13 BNE $EA0B ;attende ck_in basso
EA15 NOP
EA16 NOP
EA17 NOP
EA18 ROR $85 ;ok,salva bit ricevuto
EA1A JSR $EA59
EA1D JSR $E9C0 ;ok,legge porta
EA20 AND #$04
EA22 BEQ $EA1A ;attende ck_in alto
EA24 DEC $98
EA26 BNE $EA0B ;attende prossimo bit
EA28 JSR $E9A5 ;ok,alza data_out
EA2B LDA $85
EA2D RTS
...
Salta all'occhio che i due registri usati per comunicare sul bus sono allocati a $dd00 (per il C64) e a $1800 (per il drive 1541).
Per trasmettere un bit lungo il bus,il C64 alza o abbassa la linea 'data_out' (bit 5 di $dd00) a seconda che si tratti di un bit 0 o 1,e abbassa la linea di ck_out (bit 4 di $dd00) che è evidentemente collegata alla linea di ck_in lato drive (bit 2 di $1800) e viene usata come segnale di sincronizzazione durante la trasmissione.
Da notare:
- poco dopo l'invio il C64 rialza la linea ck_out,altrimenti il 1541 potrebbe vedere la linea abbassata quando il computer non ha ancora letto il bit successivo (con conseguenze facilmente immaginabili);
- per poter interpretare correttamente il bit ricevuto il DOS deve invertirlo:infatti,dal lato C64 a data_out=0 corrisponde un bit 1 e viceversa.
Le routine che regolano la comunicazione in senso inverso seguono una logica analoga;ovviamente stavolta il 1541 è il dispoitivo di output e pertanto userà le linee di uscita del suo registro (ck=bit 3,data= bit 1);viceversa il C64 è il dispositivo ricevente e pertanto userà le linee d'ingresso del suo registro (ck=bit 6,data=bit 7).
DOS (trasmissione)
E958 LDA #$08
E95A STA $98
E95C JSR $E9C0 ;legge porta
E95F AND #$01
E961 BNE $E999
E963 LDX $82
E965 LDA $023E,X
E968 ROR
E969 STA $023E,X
E96C BCS $E973
E96E JSR $E9A5 ;bit 0,alza data_out
E971 BNE $E976
E973 JSR $E99C ;bit 1,abbassa data_out
E976 JSR $E9B7 ;abbassa ck_out
E979 LDA $23
E97B BNE $E980
E97D JSR $FEF3 ;ritardo
E980 JSR $FEFB ;ok,alza ck_out e
;abbassa data_out
E983 DEC $98 ;invia prossimo bit
E985 BNE $E95C
...
KERNAL (ricezione)
EE56 LDA #$08
EE58 STA $A5
EE5A LDA $DD00
EE5D CMP $DD00
EE60 BNE $EE5A
EE62 ASL
EE63 BPL $EE5A ;attende ck_in alto
EE65 ROR $A4 ;ok,salva data_in
EE67 LDA $DD00
EE6A CMP $DD00
EE6D BNE $EE67
EE6F ASL
EE70 BMI $EE67 ;attende ck_in basso
EE72 DEC $A5
EE74 BNE $EE5A ;attende prossimo bit
...
Stavolta i collegamenti sono invertiti;infatti quando il 1541 abbassa la sua linea ck_out,il C64 vede alta la sua linea ck_in.Lo stesso vale per le linee dati:questo è il motivo per cui il C64 non deve invertire il bit ricevuto per poterlo interpretare correttamente.
Un pò di pazienza,timing delle istruzioni e tavole di DOS e kernel alla mano non è impossibile scrivere un diskloader o arrivare a sfruttare il 6502 come secondo mu-p :)
Ciao
-
Complimenti e grazie Alberto. E' molto istruttivo il lavoro che hai presentato.
Un pò di pazienza,timing delle istruzioni e tavole di DOS e kernel alla mano non è impossibile scrivere un diskloader o arrivare a sfruttare il 6502 come secondo mu-p
:fagiano: ...per me lo è di certo ;)
-
Grazie Alberto!
Provero' a "smanettarci" un po :D
-
Tra l'altro c'e' un'altra cosa interessante da notare:il fatto che queste routine non vengano minimamente disturbate dagli interrupt e dalle badlines (e infatti durante l'I/O da disco non c'e' alcun blanking dello schermo).
Il primo fatto è ovvio,perchè durante la trasmissione dei dati i flag I del 6510 e del 6502 sono settati.
Passiamo alle badlines:nel primo caso è il meccanismo di doppio switch del clock a renderle ininfluenti.
Infatti se si verifica una condizione di badline quando ck_out è basso,il 1541 è costretto ad aspettare che ck_out vada alto prima di poter attendere la ricezione del bit successivo;d'altra parte,se la condizione di badline si presenta con ck_out alto il 1541 deve aspettare ck_out basso prima di poter salvare il bit ricevuto in $85.
Nella seconda situazione è il C64 a ricevere e il 1541 non ha alcun modo di verificare se il computer ha ricevuto i dati oppure no;inoltre il C64 deve far fronte a eventuali ritardi dovuti alle badlines.
La soluzione adottata dai programmatori è un "uovo di Colombo":accelerare al massimo le operazioni di lettura da parte del C64 (eliminando i salti a subroutine che costano molti cicli) e rallentare quelle del 1541 con l'introduzione di molte istruzioni di tipo JSR.
In questo modo,sia nel caso di presenza che di assenza di bl il C64 riceve più velocemente di quanto trasmette il drive 1541:questo non è un problema,perchè la
presenza del doppio switch del clock garantisce che il C64 memorizzi un bit solo dopo che gli è stato effettivamente inviato. ;)
Ciao