Cpu 1541 E Successivi

[Fabbroz75]

 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.
 

[Cbm]

 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.  
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

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.

[Fabbroz75]

 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.
 

[iAN CooG]

 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 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.

[RedPanda]

 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?

[Cbm]

 Che effetti Panta Rei!!!  
Chissà la resa visiva su postazione e schermo Pal reale.
 

[Alberto]

 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

Codice: [Seleziona]

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
...                            


Codice: [Seleziona]

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).

Codice: [Seleziona]

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
...


Codice: [Seleziona]

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

[Cbm]

 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

...per me lo è di certo  

[Fabbroz75]

 Grazie Alberto!
Provero' a "smanettarci" un po :D
 

[Alberto]

 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