Ok in maniera "normale" non ci si arriva...
E quindi? Ci arrendiamo così?
Naaa 
Proviamo (troviamo) qualche compromesso...
E' già un buon compromesso usare una cartuccia o un prg scaricato da internet. Sono compromessi semplici e che funzionano. Per contro non sono il file originale, ma il file originale, qualora non lo avessi capito, non è così facilmente convertibile. Per farlo o ti crei un sistema specifico per quel gioco (e non loader, GIOCO, perché il loader sarà pure lo stesso, ma le locazioni di memoria NO) oppure ti tieni il file sul suo supporto o meglio sul suo equivalente per emulatore, o per "sistema moderno di gestione file" (quindi DC2N, 1541U, EasyFlash e via dicendo).
Abbiamo a disposizione un Vice (un commodore 64 con processore i7).
Possiamo emulare una espansione di memoria?
Certo che possiamo. Ma la gestione del bank switching resta legata a quella del C64, altrimenti non sarebbe un C64 e non farebbe girare il software per C64.
E' possibile allora lasciar perdere il C64 e fare tutto fuori dal C64 emulato, come fa in effetti WAV-PRG (che da come ho capito non emula un C64 ma lavora al livello PC). Ma ci sono comunque dei limiti tecnici dovuti al formato dei file PRG, che devono essere di byte CONTIGUI (e quello non lo puoi cambiare, perché se no come lo fai a far digerire al C64? dovresti creare un loader apposito, e allora fai prima a lasciare più PRG separati che diventa anche meglio gestibile).
Mi spiego meglio con un esempio semplice: prendiamo un programma in BASIC che oltre alla parte normale in BASIC utilizza anche una routine in L/M a partire da $C000 (la classica SYS49152). Come saprai infatti esiste un blocco di 4KB da $C000 a $CFFF che è visibile direttamente da BASIC ma non è utilizzabile per il listato o le variabili. Diciamo quindi di non volerci complicare la vita e sfruttare quindi la memoria utente da BASIC per il programma BASIC (e cioè i famosi 38911 bytes free, cioè da 2049 a 40960, magari non arrivando fino alla fine e lasciando lo spazio per le variabili) con in più una routine in L/M da 49152 a 53247.
Noterai che in questo c'è un "buco" da 40961 a 49151, e infatti sono gli 8 KB dove risiede l'interprete BASIC (e sotto i quali c'è della RAM libera che però non è accessibile da BASIC, per riportarla a galla devi "scaricare" l'interprete BASIC e lavorare esclusivamente in L/M).
Come fai a caricare un programma con queste caratteristiche? Le possibilità sono di solito tre:
1) crei due PRG uno con la routine in L/M e uno con il programma in BASIC, il programma BASIC carica la routine in L/M e poi continua la sua esecuzione
2) crei un loader, che carica prima la routine in L/M e poi il programma in BASIC (o eventualmente viceversa) usando la nota tecnica del buffer di tastiera (o una routine in L/M scritta apposta), quindi dà il RUN al programma BASIC (o da L/M fa un salto alla routine di RUN)
3) fai in modo che sia il programma BASIC stesso a creare la routine in L/M con un ciclo FOR...NEXT e il classico READ...DATA...POKE, con un caricatore che poi non ti servirà più durante l'esecuzione e di fatto per una routine di 4K ne usi mediamente 10 o 12 (+ i 4K da $C000) cioè per avere una routine che usa un sedicesimo di tutta la memoria del C64 ne devi occupare un quarto. Dire che è uno spreco di spazio è dir poco. E ovviamente quei 10-12 KB sono tolti al resto del programma BASIC. Ah, ciliegina sulla torta non dimentichiamoci che il ciclo FOR...NEXT non è istantaneo, anzi credo che per POKare tutti i valori in 4 KB di memoria ci voglia un bel po'.
Possiamo far si che il c64 emulato qualunque cosa carichi la metta nella espansione di memoria e non nella memoria tradizionale?(credo che smanettando con le impostazioni avanzate del vice si possa fare)
Ni. Ammesso si riesca a farlo, è comunque presumibile che molti dei loader si piantino perché si aspetta di trovare delle cose che non ci sono. Inoltre non risolveresti il problema dell'autostart, se un programma è fatto per partire dopo aver caricato tutte le parti come fai a impedirlo? Ci sono vari modi ma nessuno è universale e comunque, tornando all'oggetto e parlando di Ocean loader, non credo funzionino, visto com'è strutturato.
E poi come risolvi l'idea di salvare i pezzi man mano che li carichi? Mi spiego, hai presente la schermata che si carica man mano con l'Ocean Loader? Quella in genere poi stesso durante il caricamento scompare: essendo una schermata in alta risoluzione e che quindi occuperà tanto spazio, è facilmente comprensibile che essa viene eliminata dalla memoria quando vengono caricati gli ultimi pezzi del gioco, che magari si vanno ad allocare proprio lì.
Possiamo dumpare i dati dalle aree di memoria dell'espansione , comprimerle e iniettarle nelle aree "convenzionali"?(in modo che poi possa partire sia su un emulatore che su un vero c64)?
Sempre ammesso si riesca, non cambierebbe nulla rispetto all'usare una cartuccia, perché non puoi eliminare l'autostart e devi quindi per forza agire a programma iniziato. Se poi parliamo di Ocean loader, per i motivi che ho detto adesso sulla schermata grafica (e probabilmente anche la musica stessa del loader...) è facile immaginare che non sia modo di salvarla. Insomma non puoi recuperare qualcosa che passa soltanto per la memoria e non ci resta, a meno che non la intercetti mentre passa, e questo puoi farlo solo se ti recuperi pezzo per pezzo, cioè esattamente quello che ha spiegato Fab nell'ultimo suo intervento.
Possiamo eseguire il prg ottenuto agiungendo una riga basic tipo 10 sys"indirizzo di partenza"?
Presumibilmente no: la maggioranza dei giochi in L/M occupa l'inizio dell'area BASIC proprio per evitare questo. Una riga BASIC anche semplice come questa occupa comunque almeno una decina di byte (devi aggiungerci i tre 00). E potrebbero essere fatali già di loro.
Inoltre, come ho già avuto modo di spiegare, è molto probabile (anzi pressoché certo) che gran parte del gioco si vada a caricare nell'area di memoria situata sotto l'interprete BASIC, e che il bank switching venga effettuato dal loader stesso. E' vero che in scrittura non ci sono problemi a scrivere in quella parte di RAM, ma nel momento in cui dai la SYS il programma in L/M deve potervi accedere in lettura: e se questo, com'è probabile, non è stato fatto perché in origine lo faceva il loader che ora non c'è più perché tu ti ritrovi i prg singoli che hai estratto, la conseguenza sarà che invece di accedere alla RAM accederà alla ROM dell'interprete BASIC, trovandosi tutt'altro. Il risultato sarà un bell'"inchiodamento" del sistema, o, in qualche caso, dei risultati inaspettati, tipicamente messaggi di errore perché il povero interprete BASIC andrà nel pallone.
Per riassumere il concetto a chi non è avvezzo a come funziona la memoria del C64: il C64 ha 64 KB di RAM (in realtà utilizzabili realmente, se proprio si vuole usarla tutta, sono circa 61): tuttavia, poiché il 6510 può indirizzare solo 64KB per volta, alcuni di questi 64KB non sono direttamente utilizzabili, ma si trovano "sotto" altro, tipicamente delle ROM (ci sono aree di RAM che si trovano sotto ben due cose). In scrittura il sistema dà comunque accesso alla RAM, anche perché nelle ROM non è possibile scrivere e non avrebbe avuto senso: ma in lettura il sistema dà accesso a ciò che è attivo; e se è attivo il BASIC, darà accesso alla ROM del BASIC. Per avere accesso in lettura alla RAM situata sotto il BASIC, bisogna fare a meno dell'interprete e lavorare in L/M: il risultato, altrimenti, sarebbe inchiodare il sistema perché una volta data la POKE che riporta a galla la RAM, l'interprete BASIC (che ci darebbe un rassicurante READY.) non ci sarebbe più, e quindi il sistema si bloccherebbe.
I computer successivi, come il Plus/4 o il C128, hanno un bank switching dinamico (il C128 poi ha pure un comando BANK da BASIC) che risolve il problema (tant'è che il +4 e il C128 hanno quasi tutta la RAM utilizzabile direttamente dal BASIC). Il C64 invece no, ma pur di avere 64KB di RAM i progettisti della Commodore si inventarono questo sistema che permette all'utente e ai programmatori di "vedere" alternativamente la RAM o le ROM a seconda delle esigenze.
Possiamo salvare sto prg comprensivo di questa riga di comando?
Per salvare puoi salvare qualunque cosa, il problema è che quasi certamente poi non funziona
Spero di non averle sparate troppo grosse 
Diciamo che forse (non ti conosco e non mi permetto) ti manca qualche base, ho cercato di spiegarmi meglio sopra.
Ovviamente tutto ciò che ho detto non sono in grado di farlo da solo , ma andando un po a intuito mi son venute queste idee.
Il fatto è che usare il C64 non è come usare Windows su PC anche se in entrambi i casi usi un computer, ci sono delle differenze sostanziali: diciamo che è come se tu volessi scrivere un driver ma non sai di che tipo di periferica ti serve questo driver.
Per adesso mettiamo da parte "la purezza" e concentriamoci sulla "fattibilità" di un prg che funzioni da capo e che possiamo metterlo dove ci pare disco , cassetta crt.
Ma allora la soluzione è semplice, action replay/captain miky o quello che ti pare e via.
Funziona perfettamente, non è un sistema puro, ma funziona: se lo scopo è giocarci, l'ho detto, non fatevi problemi a usarlo.
Discorso diverso se lo scopo è creare dump per la comunità, un prg generato in questo modo non sarà mai "pulito".
Ps un prg è un corridoio a senso unico , ma non è un corridoio che segue un cerchio e a un certo punto si ripete da capo?
Un prg nell'intestazione ha l'indirizzo di partenza e basta. L'indirizzo di fine è calcolato cominciando dall'indirizzo di partenza e caricando tutto in sequenza fino alla fine del programma. Puoi verificare con qualunque utility che da disco permetta di visualizzare le locazioni di inizio e fine programma di un PRG presente sul floppy.
Quindi un prg è contiguo, è uno degli standard dei prg delle macchine Commodore. Su computer moderni puoi fare quello che ti pare anche prg non contigui ma poi sul C64 (reale o emulato che sia) non funzionerebbero. Per salvare più aree di memoria diverse in un unico prg o li crunchi insieme (come fa una cartuccia) cioè racchiudendo il tutto in una sorta di contenitore (è come quando sul PC usi winrar) che poi lanciato all'inizio si occuperà di rimettere tutto al suo posto, oppure carichi le singole parti da più prg, oppure usi un caricatore (basic o l/m) che si occupa di scrivere la routine da zero o ancora usi un rilocatore, cioè metti una routine in L/M che si occupa di spostare parte del programma caricato in un'area di memoria diversa.
Massi se tu avessi il tuo prg preferito , che per forza di cose si trovasse in un tap , il quale non fosse possibile estrarlo per vari motivi (plugin ,loader , segmentazione ecc) come opereresti?
Dipende dall'uso che voglio fare. Se è per uso personale userei una cartuccia (emulata perché farei prima).
Convertire le cassette/dischi e effettuare il processo inverso + Programmi e Utility