Ready64 Forum
Commodore 64 => Segnalazione News => Topic aperto da: Raffox - 16 Maggio 2012, 10:27:59
-
Abbiamo parlato tanto della ULTIMATE 1541, sia nel forum che pubblicando articoli, aggiornamenti e recensioni. Il grosso (oggi ancor di più) e, secondo me, unico problema di questo apparecchio è il costo che, bisogna ammeterlo, non è proprio alla portata di tutte le tasche.
Retro Innovations (http://store.go4retro.com/), forse conosciuta ai più per il noto ZoomFloppy, offre ormai da tempo anche la uIEC/SD (http://store.go4retro.com/products/uIEC_SD.html#reviews): un mini lettore di card SD e micro SD, direttamente collegato via cavo alla porta seriale del C64. Il costo non è elevato, siamo nell'ordine dei $60+shipping (circa €47+spese di spedizione). Le prestazioni, leggendo le recensioni e i commenti disponibili in rete, sembrerebbero di tutto rispetto sia in termini di compatibilità che di velocità operativa. Per molti aspetti si tratta quindi di un'ottima alternativa alla più costosa U1541 di Gideon.
(http://s7.postimage.org/o8fs2uw07/u_IEC.jpg) (http://postimage.org/image/o8fs2uw07/)
Ok, fatta questa lunga premessa... ecco il vero motivo glorioso di questo post :lol:
Volevo infatti segnalare, soprattutto per i più ambiziosi e disinvolti modder, un accattivante case protettivo (https://www.commodoreserver.com/BlogEntryView.asp?BID=D31E7915D4204192A741061BD5C7C99D&EID=0B55CA414691476BBDCFE6A995A1E0CB), somigliante a un super mini dirve 1541... con tanto di led ed etichetta a campeggiare frontalmente, in bella vista. È visivamente accattivante e non di difficilissima realizzazione, a patto di saper lavorare con lime, stucco, colla e carta vetrata.
Lo considero un vero bijoux per (noi) fanatici :lol:
(http://s17.postimage.org/uxetyb77v/case1.jpg) (http://postimage.org/image/uxetyb77v/)
(http://s17.postimage.org/s4lmea6vf/case2.jpg) (http://postimage.org/image/s4lmea6vf/)
-
Assolutamente bellissimo... oggi pomeriggio inizio con l'acquisto della lima ... ehehe è una figata pazzesca ! BRAVO ! :metal:
-
AHAH! Magari!
Ma non è opera mia... bensì di Rik Magers (aka daytona400f) ;)
Ha scelto un involucro di plastica, l'Ademco 5816, utilizzato nei sistemi di allarme per porte e finestre effettivamente molto somigliante al case del disk drive 1541.
Con un po' di modifiche è riuscito a far alloggiare la scheda al suo interno.
(http://s11.postimage.org/rufauzdn3/box.jpg) (http://postimage.org/image/rufauzdn3/)
-
L'avevo gia visto un po' di tempo fa'.
E' sicuramente un'ottima realizzazione, pero' tutto sta nel trovare il case adatto (quello utilizzato non mi sembra di facile reperibilita').
Forse la soluzione migliore rimane quella di montare la uiec o sd2iec dentro il case del c64, oppure in un 1541.
Questi aggeggi lasciati da soli piu' sono leggeri e piu' tendono a cadere dalla scrivania, magari trascinati dal cavo dell'alimentatore. :)
ciao
-
Da una ricerca spicciola mi pare che la reperibilità dell'involucro di plastica sia ragionevole. Ad esempio ce ne sono tanti in vendita su eBay. Tra l'altro è disponibile anche una versione marrone oltre a quella bianca. Ma il colore sarebbe l'ultimo dei problemi... una scartavetrata superficiale, una passata di primer e poi della vernice acrilica e lo si colora in mille modi :)
Però anche il tuo suggerimento, di alloggiare la scheda direttamente nel C64, è interessante specialmente per chi non vuole avere troppi aggeggi sulla scrivania. Incidendo la superficie del case con delle frese per modellismo si otterrebbe facilmente una fessura per inserire comodamente le card. Soluzione elegante e poco invasiva. Anche il fissaggio della scheda all'interno del computer non rappresenta, a mio avviso, un problema complicato: un supporto di balsa, facile da lavorare, e un po' di silicone come adesivo potrebbero già bastare. Si eviterebbe di aver in giro un'altra scatoletta, l'impiccio del cavetto e, soprattutto, il rischio di far volare la periferica giù dalla scrivania... Ma considerando le dimensioni veramente minimal e il look accattivante, il problema dello spazio non sussiste.
-
è semplicemente fantastico!
-
Abbiamo parlato tanto della ULTIMATE 1541, sia nel forum che pubblicando articoli, aggiornamenti e recensioni. Il grosso (oggi ancor di più) e, secondo me, unico problema di questo apparecchio è il costo che, bisogna ammeterlo, non è proprio alla portata di tutte le tasche.
Le prestazioni, leggendo le recensioni e i commenti disponibili in rete, sembrerebbero di tutto rispetto sia in termini di compatibilità che di velocità operativa. Per molti aspetti si tratta quindi di un'ottima alternativa alla più costosa U1541 di Gideon.
Ottima alternativa quanto?
Raffox, il vantaggio dell'ultimate rispetto agli altri lettori (almeno fino ad oggi) é la migliore compatibilità con i diversi formati:l'ultimate legge tutto, anche i *.T64. Invece la Sd2iec non legge quest'ultimo formato e non sempre é compatibile con i d64 (dipende dal crack) e spesso risulta macchinosa la gestione del change disk.
E' vero ci sono al posto dei d64 gli *.m2i, ma sono limitati a pochi giochi.
Questa nuova uiec ha risolto tutti questi problemi?
Se sì, allora certamente converrà prenderla al posto della ultimate!
saluti
A.
-
No, s'intende. I dispositivi tipo SD2IEC, uIEC ecc. non reimplementano l'hardware del 1541 e quindi hanno una compatibilità parziale. Tuttavia rappresentano un'alternativa interessantissima visto il costo contenuto e la relativa semplicità con cui si possono realizzare in casa.
Per quanto riguarda gli M2I, da un po' di tempo il ReadMe del firmware SD2IEC contiene un avviso che sconsiglia di usare tale formato, poiché in futuro non sarà più supportato.
-
Quindi si prospetta un nuvo formato che sostituirà gli m2i o rsteremo con i d64?
-
http://www.c64-wiki.com/index.php/sd2iec_%28firmware%29 (http://www.c64-wiki.com/index.php/sd2iec_%28firmware%29) dice
The M2I format exists mostly for historical reasons. The original MMC2IEC firmware was not able to write to D64 files, but a container format capable of handling PETSCII filenames and large capacities was needed. Instead of adding D64 or D81 write support, the M2I format was invented [...] M2I is file-based and in contrast to D64 does not support sector access
-
Fab allora é ipotizzabile che i futuri firmware neanche riconosceranno più gli m2i, ma solo i d64.
Io continuo a preferire gli m2i, perché con i giochi in multiload mi fa il change disk in automatico.
saluti
A.
-
Per evitare di dover cambiare disco ci sono altri modi:
- Trasferire tutti i file in immagini più grandi, come D71 e D81
- Laddove possibile (tutti i file sono di tipo PRG e non hanno caratteri strani nei nomi) inserire i file in una directory con i loro veri nomi
- Utilizzare il formato PC64 (quello con estensioni tipo P00 ecc.); Su sd2iec file dump (http://www.sd2iec.de/) c'è un'utility chiamata m2itopc64.c che converte automaticamente da M2I a PC64
-
Carmine come faccio a trasformare un d64 in d71 o d81?
ciao
A.
-
Carmine come faccio a trasformare un d64 in d71 o d81?
Non lo trasformi, ma puoi copiare i file da un'immagine D64 a D71 o D81. Puoi farlo ad esempio con VICE o con 64Copy.
-
Carmine come faccio a trasformare un d64 in d71 o d81?
Non lo trasformi, ma puoi copiare i file da un'immagine D64 a D71 o D81. Puoi farlo ad esempio con VICE o con 64Copy.
Grazie. Ho scaricato il file m2itopc64.c. Sai come si usa? Devo copiarlo sulla sd2iec?
saluti
A.
-
Grazie. Ho scaricato il file m2itopc64.c. Sai come si usa? Devo copiarlo sulla sd2iec?
È un sorgente da compilare. Ottenuto il file eseguibile, lo si usa su PC. Se vuoi provare la versione compilata da me, vai qui (http://www.sendspace.com/file/s5n1hr) e clicca su "Click here to start download from sendspace". Occhio che si tratta di un tool a linea di comando. Per usarlo digita:
m2itopc64
-
Carmine sei un genio :metal: fortuna che sono cresciuto con il dos e con
-zip c:\* e bla bla bla. Funziona tutto bene. Toglimi una curiosità: a che cosa servono le utility newboot e tapplay per la sd2iec (contenuti sempre su sd2iec file dump)?
saluti
A.
-
Newboot è un bootloader migliorato. Il bootloader è quel programmino che si inserisce nel microcontrollore tramite un'apposita interfaccia chiamata programmatore e si occupa di leggere il firmware dalla scheda SD e caricarlo a sua volta nel microcontrollore.
I miglioramenti rispetto al bootloader usato precedentemente riguardano soprattutto l'algoritmo che stabilisce se caricare o meno un firmware eventualmente trovato sulla scheda.
Tapplay è un firmware alternativo, che trasforma la SD2IEC in qualcosa di diverso, credo per caricare i file TAP simulando un registratore, ma forse sbaglio, dato che non esiste documentazione a riguardo.
-
Per aggiornare il 'newboot' ovviamente bisogna programmare il microcontrollore e quindi servirà un programmatore atmel con relativo programma (tipo ponyprog) ...almeno credo sia così.
saluti
A.
-
@Antiriad, si puoi usare ponyprog.
Dai un'occhiata qui: http://www.circuitvalley.com/2011/04/avr-s...programmer.html (http://www.circuitvalley.com/2011/04/avr-serial-port-programmer.html)
In ogni caso lo standard de facto e' avrdude da utilizzare con un programmatore (parallelo, seriale, usbasp, ftdi in bb, etc.).
ciao
-
@Antiriad, si puoi usare ponyprog.
Dai un'occhiata qui: http://www.circuitvalley.com/2011/04/avr-s...programmer.html (http://www.circuitvalley.com/2011/04/avr-serial-port-programmer.html)
In ogni caso lo standard de facto e' avrdude da utilizzare con un programmatore (parallelo, seriale, usbasp, ftdi in bb, etc.).
ciao
Quel programmatore l'ho costruito non funziona, o meglio funziona se non devi modificare i fuse bits altrimenti :headshake: ti blocca il micro.
Per questo ne ho acquistato uno serio. Devo vedere se sulla sd2iec sono stati lasciati i pin per programmarlo....certamente non posso dissadarlo é montarlo su uno zoccolo.
saluti
A.
-
Se ti sei trovato il microcontrollore bloccato per settaggio errato dei fusebits, ma inizialmente riuscivi a leggere e scrivere correttamente i dati, penso che il programmatore funzionasse. Il problema dovrebbe essere altrove.
-
@Antiriad: io utilizzo avrdude con patch ftdi e arduino 2009 oppure l'avrdude liscio se utilizzo usbasp. Ma per comodita' uso quasi sempre il primo.
Per il resto il seriale non l'ho provato, ma chi l'ha realizzato lo trova lento perche' devi impostare una velocita' bassa della seriale, mentre con i metodi citati puoi impostare 115200 come velocita' di programmazione, anche se la scrittura dei fuses e' sempre consigliabile farla a velocita' basse.
Comunque a volte quando scrivi i fuses perdi il micro semplicemente perche uno si sbaglia ed attiva l'oscillatore esterno.
In quel caso se usi una BB per i collegamenti, basta connettere un quarzo al micro per farlo "resuscitare".
ciao
-
Più di un utente si é lamentato del programmatore in questione linkato da 4e1541. Poi può essere che tanti di noi non avevamo capito come settare la porta com. Certo é che da quando sono passato ad un programmatore su porta parallela non ho più avuto problemi. Ho diversi chip atmel bloccati da quel maledetto programmatore, e mi piacerebbe riutilizzarli (anche perché per riacquistarli devi fare il solito ordine all rs components visto che dalle mie parti non si trovano). Però mi hanno sempre detto che per sbloccarli c'era bisogno di costruire/acquistare un programmatore a parte che fa solo quello.
4e1541 ci colleghi ai piedini un quarzo e poi? Si riattiva da solo e puoi riportalo allo stato di default?
saluti
A.
-
Se hai impostato erroneamente i fusebit selezionando come sorgente di clock un segnale esterno, ti basta fornire un segnale adeguato affinché il microcontrollore funzioni e torni a dialogare con il programmatore.
Io ci sono riuscito costruendo una piccola parte del circuito presente in questa pagina (http://www.nexusuk.org/projects/rgb2svid/circuit), quella situata più in basso (ho usato un 74HCU04 e un cristallo a 4 MHz). Si alimenta opportunamente il circuito e si collega il segnale che esce all'ingresso clock del microcontrollore. In questo modo ho recuperato due ATMega32 che avevo bloccato con PonyProg. Ho anche letto che alcuni hanno semplicemente programmato un altro microcontrollore facendogli emettere un segnale oscillante, che hanno usato come sorgente di clock per il chip da recuperare.
Oppure ci sono programmatori più complessi che supportano la programmazione "high voltage" o tramite Jtag, ma non li ho mai usati. Io uso questo (http://www.pitsch.de/stuff/mmc2iec/avrisp.htm).
-
@Antiriad: ho segnalato il link, ma non ho mai detto che sia consigliato utilizzare un hardware di quel tipo, ne tantomeno ponyprog, dal momento che praticamente tutto il mondo che gira intorno alle mcu atmel utilizza avrdude (che fra l'altro e' multipiattaforma).
Se uno vuole stare tranquillo, come dicevi, deve utilizzare un programmatore meno critico.
Per il momento non ho dovuto realizzare soluzioni esoteriche (come quelle citate da tsm_carmine) per recuperare dei chip, al massimo m'e' capitato di collegare un clock esterno alla mcu per poterla riprogrammare.
In ogni caso ho l'impressione che con avrdude sia piu' difficile fare casino coi fuse.
In rete si leggono diversi thread sul problema della mcu bloccate, ma nel 99% si tratta solo di problemi di clock.
ciao
-
Per evitare di dover cambiare disco ci sono altri modi:
- Trasferire tutti i file in immagini più grandi, come D71 e D81
- Laddove possibile (tutti i file sono di tipo PRG e non hanno caratteri strani nei nomi) inserire i file in una directory con i loro veri nomi
- Utilizzare il formato PC64 (quello con estensioni tipo P00 ecc.); Su sd2iec file dump (http://www.sd2iec.de/) c'è un'utility chiamata m2itopc64.c che converte automaticamente da M2I a PC64
Carmine sto usando l'ultima versione di 64copy (la 4.44) ma continua a non farmi il change disk. Come "cavia" sto usando un capolavoro della Microprose : Gunship.
Prima apro il d64 poi seleziono con select group tutti i files prg e infine faccio o f5 (copy files) o f11 (convert) e seleziono il formato PC64. Una volta ottenuti i p00 (per gunship sono 89) li metto tutti nella stessa directory. Il gioco parte ma quando arrivo al change disk non me lo fa :doh:
Ho provato anche con il formato D71 e D81, ho selezionato i precedenti p00 e li ho copiati o convertiti ( a me sembra che f5 e f11 facciano la stessa cosa) nel singolo file D71 e D81(quando li apro i file ovviamente vengono visualizzati come prg e non come p00). Ma il risultato é lo stesso: si blocca al change disk.
Forse devo selezionare una delle seguenti opzioni nel menù del copy/convert files?
- create separate files
- Auto-convert filesnames
- keep DOS filename case
- Add c64 type to name
- remove dos extension
- Extend disk directory
saluti
A.
-
Se hai impostato erroneamente i fusebit selezionando come sorgente di clock un segnale esterno
Scusa Carmine (e vale anche per 4e1541) ma aiutatemi a capire se sbagliavo o no le impostazioni.
Dovevo costruire un circuito con atmega8 con quarzo esterno da 12 mhz da saldare ai piedini xtal1 e xtal2.
Io per calcolare i fusebits uso questa pagina :
http://www.engbedded.com/fusecalc/ (http://www.engbedded.com/fusecalc/)
Ho selezionato Atmega8 e in features l'ultima voce, ovvero :
Ext. Crystal/resonator high freq. startup time: 16k ck + 64 ms: cksel= 1111 e sut=11 lasciando tutte le altre voci invariate.
Con Ponyprog nei fusebits configuration ho settato cksel3 e sut1 e mi si é bloccato il micro (senza toccare i fusebits flashavo senza problemi)
Con avrdude scrissi:
avrdude.exe -p m8 -c ponyser -P com1 -u lfuse:w:0xff:m -u hfuse:w:0xd9:m flash:w:nomefile.hex
e lo stesso si é bloccato.
Avrdude mi diceva:
avrdude.exe: AVR device not responding
avrdude.exe: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
Sbagliavo io o era un problema di programmatore? :popcorn:
saluti
A.
-
@Antiriad: uso anch'io quel calcolatore.
L'unica accortezza quando si fanno i calcoli a mano e che i fusebit sono impostati dal calcolatore quando non hanno il check (=0).
Per il resto ho sempre impostato la mcu in base a progetti gia realizzati.
Direi che per il clock manca il set di CKOPT (almeno da quanto impostano tanti progetti, uno fra tutti v-usb).
Chiaramente una volta impostati in quella maniera i fusebit devi collegare un oscillatore ai pin osc1 e osc2 della mcu. altrimenti non riesci piu' a programmarla via spi.
ciao
-
@4e1541
Purtroppo é facile sbagliare con i fusebits :dotto:
Infatti con il senno di poi mi sono accorto di aver sbagliato anche il settaggio e di conseguenza la riga di avr dude...non dovevo settare cksel 3 ma cksel 0 1 e 2 e ckopt e infatti mi esce:
-U lfuse:w:0xe8:m -U hfuse:w:0xcf:m = ext. rc. osc. 8.0 12.0 mhz e io dovevo montare un quarzo appunto da 12 mhz.
Invece quello che scrissi all'epoca (che ho riportato nel precedente post) é diverso.
All'epoca ero agli inizi e facilmente sbagliavo...d'altronde, ripeto é facile confondersi. Ad esempio spuntare RSTDISBL significa disattivarlo non abilitarlo....é facile andare in confusione con i fuse bits.
Adesso quello che mi preme é recuperare questi atmega8...ma non ho un un circuito elettronico che genera forme d'onda di frequenza.
Per questo l'unica via che mi resta é quella suggerita da tsm_carmine, ma la vedo dura...
saluti
A.
-
Carmine sto usando l'ultima versione di 64copy (la 4.44) ma continua a non farmi il change disk. Come "cavia" sto usando un capolavoro della Microprose : Gunship.
Se ci fosse un errore nella maniera in cui copi i file, il gioco non dovrebbe nemmeno partire, invece riscontri un problema al cambio del disco. Ho provato un paio di crack ed effettivamente non "riconoscono" il secondo disco, non so perché.
Su GB64 comunque, c'è una versione one-side (l'altra immagine presente nell'archivio contiene il manuale in formato testo). L'ho provata e sembra funzionare bene. Devi solo ricordarti di selezionare sempre il primo elemento (T-74) nello schermo di protezione.
Per quanto riguarda i fusebit mi astengo, non ricordo più molto del loro funzionamento.
-
Me lo linki che non riesco a trovarlo? Speriamo che sia compatibile con la sd2iec.
ciao
A.
-
Link (http://gamebase64.hardabasht.com/games/g/GUNSHIP0_03350_01.zip)
-
Ok funziona anche sulla SDiec :metal: almeno nei primi caricamenti
E' difficile fidarsi dei d64, P00, etc. quando sono multiload, mi é capitato files che si bloccano sulla sd2iec anche dopo il terzo o il quarto caricamento, gli stessi files caricati sull'emulatore invece non danno nessun problema .
Pertanto nonostante i firmware io continuo a tenermi stretto gli m2i, visto che ad oggi nessuno di quelli che ho provato si é mai bloccato.
saluti
A.
-
gli stessi files caricati sull'emulatore invece non danno nessun problema .
Ovviamente testati con "true drive emulation" disattivata e "virtual device traps" attivate, giusto? Lo ripetiamo per chi si fosse collegato solo ora. ;)
Comunque nessuno dei 3 sistemi è di per sé più affidabile degli altri: se si sceglie un crack incompatibile si può realizzare tranquillamente un M2I che non funzionerà mai, quindi tutto dipende da chi crea questi M2I e dalla cura con cui sceglie le versioni dei giochi da usare.
Ne consegue che, più degli M2I in sé, devi tenerti stretto il tizio che li ha messi a disposizione!
-
Carmine ho detto le ultime parole famose!
Ho trovato un M2i che non funziona! E' midnight resistance...almeno sulla mia sd2iec non gira, appena lo carico mi dà syntax error!
Chissà forse é stato convertito male!
Devo riconoscere che fra i miei giochi preferiti sul 64 (oltre 100) solo per due titoli non sono riuscito a trovare una versione compatibile con la sd2iec: hot wheels e project firestart. Ho provato tutte le versioni presenti su nonamec64.org ma nessuno di queste gira...non é detto però che in qualche oscuro angolo di questo mondo non ci sia qualche versione crakkata che vada bene...uscita magari nelle edicole nostrane!
saluti
A.