Commodore C128D

[ecalogiuri]

• 

Uno dei problemi di SQLite è che le scritture sono incredibilmente lente, e rallenta più che linearmente con l'aumentare della dimensione del DB, non va bene per un FS.

Quanto hai ragione... 
Ne so qualcosa quando ho dovuto convertire un db da un vecchio applicativo dos, e il cliente lo voleva per forza in SQLite.

[ecalogiuri]

• 

Legacy... tu mi spaventi!!! 

[TheKaneB]

• 

spaventa un po' tutti... specialmente quando parte per la tangente in un thread che non c'entra una fava con XFS 

[TheKaneB]

• 

quello che faccio con il C128 normale, solo occupando meno spazio sulla scrivania.
Considera che il modello a tastiera occupa i seguenti kilometri quadri:
ComputerTastiera + Alimentatore1 + Floppy drive + Alimentatore 2 + relativi cavi e cavetti = millemila virgola trentasette km^2

Mentre con il C128D hai questi componenti in un unico box bello solido e "stackable", con tastiera che a riposo viene immagazzinata in un apposito scomparto sotto il pizzabox, eliminando quindi ulteriore spazio dalla scrivania.

Potrei farci un Commodore Amiga 4128D Tower (so che qualcuno coglierà la citazione)

L'idea è quella di studiarne l'hardware sperimentare qualcosina lato giochi/demo, ma il tutto a tempo perso ovviamente. Non credo che avrò mai la voglia e il tempo di fare un gioco completo.

[lucommodore]

• 

Non credo che avrò mai la voglia e il tempo di fare un gioco completo.

sarabbe doveroso invece... Lo devi al mondo, all'universo...

[paolone]

• 

- 2) La compatibilita' con il Commodore 64 non era totale, diversi giochi del Commodore 64 spesso accadeva che su C128 si bloccavano... se non ricordo male uno di questi era R-type che ad un tratto del caricamento non andava piu' avanti. Questo era dovuto al fatto che il C128 non montava una CPU 6510, ma una leggermente differente con indirizzamenti alla memoria impercettibilmente diversi dall'originale C64.

Eh no. Il problema era un altro, e cioè che alcune "feature" del 128 erano accessibili anche in modo 64, con risultati che i giochi per C64 non avevano previsto. Sulla locazione 53296, per esempio, era possibile attivare la modalità FAST (2 MHz invece di 1) impostando a 1 il bit 0 (POKE 53296,1), per cui chiunque avesse usato quella locazione per altri motivi, finiva col sbiancare lo schermo e perdere la visibilità di quanto accadesse sul monitor (il chip VIC-II non era in grado di funzionare a 2 MHz e veniva disattivato anche in modalità 128).

Se non rammento male, cambiando alcuni bit nella locazione 53295 era invece possibile attivare la tastiera estesa, anche se quando ci provai - questo lo rammento benissimo - i tasti agiuntivi producevano lettere apparentemente a caso.

Ricordo comunque che queste piccole differenze furono oggetto di grande interesse sulle riviste dell'epoca. Qualcuno pubblicò listati appositi per usare correttamente la tastiera del C128 anche in modalità 64 e nacquero anche delle tecniche per mantenere visibile lo schermo in "quasi modalità FAST", mandando il computer a 2 MHz quando il pennello del raster usciva dall'area visualizzabile e riportandolo a 1 MHz quando ci rientrava. In questo modo si otteneva un 20% circa di velocità in più. Vedi http://www.lemon64.com/forum/viewtopic.php?t=37663&sid=37ad598fa5bd7f98e2543c7d7d761a09

[TheKaneB]

• 

@paolone: colpito e affondato 

ripeto, devo mettere un "quoto @paolone" direttamente in firma

[lucommodore]

• 

Ma non c'è l'opzione "Karma + 1000" per il Paolone?

[Nonefonow]

• 

oppure, vado ad affittare un garage, ci stavo pensando
(cambiare la polla e' possibile, ma non fino a che paga lei i 3/4 di affitto buahahahaha)

Anche se tu pagassi 100% dell'affitto la signora e' sempre la regina della casa.  Per cui garage. 
 
Io ho fatto cosi'.

[Nonefonow]

• 

Mi riferivo a una procedura sul mio WXP home computer.
 
Scarico lo .ZIP, lo espando e poi per copiare gli archivi sul dischetto da inserire nel C128 come?
C'ho bisogno di un 5 1/4 o un 3 1/2.?

Sinceramente proprio non so; devi vedere quale formato supporta il C128...

Ho sperimentato ieri sera. 
 
1- Il C128D si avvia il CP/M infilando il dischetto prima di accenderlo.  CP/M si avvia solo dal lettore A> (il 1571 incorporato) poi riconosce B>   - Qui non capisco perche?  Il mio B> e un C1581.
 
2- Sull DELL WXP ho scaricato un .ZIP l'ho espanso e inserito gli archivi dentro un .D81.  Masterizzato il .D81 su un dischetto da 3 1/2 e ho provato avviare il gioco sotto CP/M.
 
3- CP/M riconosce il dischetto B> ma non legge il DIR.   
 
4- Adesso vado in ricerca.
 
 

[Z80Fan]

• 

Uno dei problemi di SQLite è che le scritture sono incredibilmente lente, e rallenta più che linearmente con l'aumentare della dimensione del DB, non va bene per un FS.

SQLite può essere anche molto veloce, ottimizzando query e configurazione in base all'uso che si deve fare:
http://blog.quibb.org/2010/08/fast-bulk-inserts-into-sqlite/

Ad esempio, considerando di memorizzare solo i metadati e tenendo i dati effettivi fuori dal DB, si potrebbe creare un DB sul disco e uno in memoria, usando il secondo come cache su cui fare tutte le operazioni di query e modifica, e periodicamente salvare in bulk le modifiche sul disco.

Ovviamente SQLite non è adatto a workload pesantissimi con molte scritture contemporanee, ma considerando l'uso che pensa di farne Legacy, che parla di dischi da pochi gigabyte e a singolo utente, potrebbe essere un interessante esperimento.

[TheKaneB]

• 

da provare, ma su un altro thread

[cdimauro]

• 

- 2) La compatibilita' con il Commodore 64 non era totale, diversi giochi del Commodore 64 spesso accadeva che su C128 si bloccavano... se non ricordo male uno di questi era R-type che ad un tratto del caricamento non andava piu' avanti. Questo era dovuto al fatto che il C128 non montava una CPU 6510, ma una leggermente differente con indirizzamenti alla memoria impercettibilmente diversi dall'originale C64.

Eh no. Il problema era un altro, e cioè che alcune "feature" del 128 erano accessibili anche in modo 64, con risultati che i giochi per C64 non avevano previsto. Sulla locazione 53296, per esempio, era possibile attivare la modalità FAST (2 MHz invece di 1) impostando a 1 il bit 0 (POKE 53296,1), per cui chiunque avesse usato quella locazione per altri motivi, finiva col sbiancare lo schermo e perdere la visibilità di quanto accadesse sul monitor (il chip VIC-II non era in grado di funzionare a 2 MHz e veniva disattivato anche in modalità 128).

Se non rammento male, cambiando alcuni bit nella locazione 53295 era invece possibile attivare la tastiera estesa, anche se quando ci provai - questo lo rammento benissimo - i tasti agiuntivi producevano lettere apparentemente a caso.

Ricordo comunque che queste piccole differenze furono oggetto di grande interesse sulle riviste dell'epoca. Qualcuno pubblicò listati appositi per usare correttamente la tastiera del C128 anche in modalità 64 e nacquero anche delle tecniche per mantenere visibile lo schermo in "quasi modalità FAST", mandando il computer a 2 MHz quando il pennello del raster usciva dall'area visualizzabile e riportandolo a 1 MHz quando ci rientrava. In questo modo si otteneva un 20% circa di velocità in più. Vedi http://www.lemon64.com/forum/viewtopic.php?t=37663&sid=37ad598fa5bd7f98e2543c7d7d761a09

In realtà quello che i giochi provavano a fare con quei registri addizionali era del tutto illecito, visto che non erano disponibili col VIC-II del Commodore 64, ma sono stati introdotti soltanto con quello del 128. I registri dello spazio indirizzamento del VIC-II che non erano usati dal chip non andavano, dunque, toccati assolutamente. Anche perché erano del tutto inutili: restituivano sempre #$FF (255). Quindi, oltre che illecito, per un videogioco non aveva proprio alcun senso accedervi, tanto meno in scrittura, visto che non era possibile conservarvi alcunché (non c'era memoria mappata nello spazio d'I/O, fatta eccezione per il banco usato per la mappa caratteri e colori, ma quella stava soltanto in un'apposita area). Puro non senso, insomma.

Se gli ingegneri Commodore devono essere crocifissi, la giusta causa sarebbe rappresentata dal fatto che alle locazioni $FF00-$FF04 avevano mappato 5 registri dell'MMU, qualunque fosse le configurazione di memoria. Questo è SICURAMENTE fonte d'incompatibilità col Commodore 64, visto che in quell'area poteva essere mappata sia ROM (il Kernal) sia RAM, a seconda della configurazione selezionata.

Avrebbero potuto scegliere una soluzione più furba, come ad esempio utilizzare uno dei bit inutilizzati nella porta 1, in modo da abilitare o disabilitare il mapping di questi registri in quella zona di memoria. Questo avrebbe garantito una compatibilità al 100% in modalità 64.

[cdimauro]

• 

da provare, ma su un altro thread

In effetti mi sono astenuto sull'argomento proprio per non inquinare più il thread.

[schiumacal]

• 

Facendo riferimento a quello che hanno detto: Paolone e CdMauro...

appunto come ho gia' detto, la compatibilita' con il Commodore64 biscottone non era al 100%.

E comunque, uscirono fuori poi altri piccoli problemi dovuti agli ultimi tipi di gioco per Commodore64 che erano diventati ormai dei supergames perche' si potevano caricare da floppy e mentre il gioco si caricava, partiva pure la musica e la grafica su video, cosa che fare con un commodore64 sembrava impossibile... eppure...

Ora, questo tipo particolare di caricamento, ogni tanto mandava in tilt il Commodore128 in modalita' 64. Francamente non ho mai approfondito il motivo per cui accadesse, probabilmente come gia' detto, si accedeva a locazioni di memoria che nel C64 andavano bene mentre nel C128 no.

Se alcuni di voi ricordano, il caricamento ridotto da registratore a cassette che permetteva il TurboLoad, quello che produceva le famose strisce colorate sullo schermo, ebbene ogni tanto in questa modalita' di caricamento mi sembrava che il C128 andasse in tilt... boh!!!