Testi Commodore 64 BASIC Linguaggio Macchina Hw

[Pier Aisa]

Visto che è circolato nei commenti di qualche video riporto qualche testo che secondo me vale la pena di leggere:

Linguaggio Macchina

• Abc_del_linguaggio_macchina_sul_commodore_64 di Danny Davis

• How_To_Program_Your_Commodore_64_in_6502-10_Machine_Language di Sam D. Roberts

• Machine Language for the Commodore

• The.comple]te.Commodore.64.ROM.disassembly di P.Gerrard e K.Bergin

BASIC

• C64 Programmer's Reference Guide

• Commodore_64_-_La_grande_guida di Rita Bonelli Jacksons

• The_Commodore_64_Music_Boo

HARDWARE REPAIR

• C64-C64C_Service_Manual_314001-03_(1992_Mar)

• Commodore_64_Troubleshooting_and_Repair_Guide_robert.Brenner

• C64_Diagnostic_Instruction_and_Troubleshooting_Manual_(326070-01)

[scossa]

Aggiungo:

Commodore 64 - Guida di riferimento per il programmatore

[Guido]

Io ho avuto un solo libro per il linguaggio macchina del C64, dopodiche' non ho sentito il bisogno di avere altro :
"Commodore 64- I segreti del Linguaggio Macchina" di Mark Greenshields

[scossa]

Ciao Guido,

quella che ho indicato l'ho suggerita perché è la guida "ufficiale" del Commodore 64, pubblicata da Commodore Italiana nel 1984, con tanto di schemi elettrici (ho anche il cartaceo originale):

[Guido]

Ciao Guido,

quella che ho indicato l'ho suggerita perché è la guida "ufficiale" del Commodore 64, pubblicata da Commodore Italiana nel 1984, con tanto di schemi elettrici (ho anche il cartaceo originale):

Avevo capito che era la guida ufficiale (bella forza) ma che fosse completa e scaricabile proprio non me lo aspettavo !!
Grande !
Eppoi e' in italiano !
Grazie

[blue3121]

Il 6510 è fondamentalmente un 6502 con "due me(mo)nate HW" in più.
Qualsiasi testo di programmazione del 6502 va benissimo, non c'è nulla da aggiungere: per il C64 c'è sono da considerare, in più eventualmente, la mappatura indirizzi (se non ricordo male) sul VIC e SID ed eventuali chiamate alla ROM di sistema. (In BASIC ...oddio... i POKE & C. che tristezza...).
Il resto è pura... Libertà !
Consiglio (nel mio piccolo) per chi si vuol divertire con l'assembler: mai dimenticare la frequenza di clock (stiamo parlando di processori a clock "fisso") se volete ottenere qualcosa che faccia ciò che volete, come volete, nei tempi che volete.

[Guido]

Consiglio (nel mio piccolo) per chi si vuol divertire con l'assembler: mai dimenticare la frequenza di clock (stiamo parlando di processori a clock "fisso") se volete ottenere qualcosa che faccia ciò che volete, come volete, nei tempi che volete.

Eppure quando mi sono messo a fare un engine di database in assembly per ovviare agli inconvenienti del basic nel trattamento delle stringhe, tipo il problema del "garbage collection", pur con i floppy da 5 pollici+1/4 la velocita' ottenuta era spaventosa. Poi ho dovuto mollare perche' dovevo dedicarmi al lavoro, ma ogni volta che mi capitano nel lavoro programmi gestionali che richiedono processori+ram+hd mostruosi mi chiedo come siamo riusciti a farci impollare cosi' dai produttori di HW e SW.

[blue3121]

... mi chiedo come siamo riusciti a farci impollare cosi' dai produttori di HW e SW.

Tieni conto di una cosa: ci sono linguaggi "interpretati" (come il BASIC del C64) e linguaggi "compilati" (come il C, il C++, ecc).
Tra le due categorie c'è un abisso come velocità di esecuzione.
Inoltre i compilatori moderni generano codice eseguibile (macchina) estremamente ottimizzato, difficilmente superabile, ormai, da codice ASM scritto "a mano".
Come se non bastasse, con moltissimi compilatori (ad esempio il gcc) puoi scegliere anche la famiglia del processore target per ottenere codice "customizzato" sul processore utilizzato.
Meglio di così...

Riguardo il tuo riferimento ai "programmi gestionali", cerco di interpretare ciò che intendi, pur non avendolo compreso appieno: spesso tali programmi (dove lavoro io, senza far nomi, è installato un sistema con tempi di risposta pari ad ere geologiche... pur girando su server HP Xeon gonfiati di RAM su LAN a 10Gb) sono basati su una tecnologia simile (alla lontana, ma non troppo) a quella usata nel web.
Devi mettere in conto tutta una serie di fattori, quali la generazione e l' aggiornamento in tempo reale dei dati sia lato client che server, (purtroppo) l' utilizzo di framework basati su codice interpretato e non compilato, utilizzo di scheduler tutt' altro che ottimizzati, anzi spesso dotati di ritardi di risposta volutamene inseriti, ecc ecc
Spesso si sceglie, in tal caso, la versatilità (puoi fare tutto di tutto "quasi" senza scrivere codice) a scapito dell' efficienza e quindi dell' ergonomia, con costi di manutenzione bassi, ma costi di utilizzo elevati.
De gustibus.

[Guido]

Per programmi gestionali intendo quelli dedicati all'utilizzo di database molto capienti, e sui quali mi sono fatto le ossa per motivi professionali anche legati alla programmazione. Per farla breve vedo che programmi scritti con linguaggi semplici, quali l'assembly oppure anche in dos e compilati erano dei fulmini, invece i classici programmi windows che in modo o l'altro ci hanno obbligato ad usare richiedono macchine sempre piu' potenti per ottenere le stesse cose.

[blue3121]

Per programmi gestionali intendo quelli dedicati all'utilizzo di database molto capienti, e sui quali mi sono fatto le ossa per motivi professionali anche legati alla programmazione. Per farla breve vedo che programmi scritti con linguaggi semplici, quali l'assembly oppure anche in dos e compilati erano dei fulmini, invece i classici programmi windows che in modo o l'altro ci hanno obbligato ad usare richiedono macchine sempre piu' potenti per ottenere le stesse cose.

[OFF-TOPIC}
Rischiando di uscire fuori argomento... anzi ci siamo già... (chiedo scusa a tutti), prova la tecnologia LAMP (acronimo che sta per Linux/Apache/Mysql/Php) che puoi installare molto semplicemente su una macchina con qualsiasi distro, in "locale" e collegandoti con un qualsiasi altro PC tramite router/switch.
Sul mio vecchio Pentium4 e 2 Gb RAM avevo tempi di risposta dell'ordine di frazioni di milli(!)secondi su DB con oltre 100.000 record e circa 30 macchine connesse (durante le sessioni demo del LUG che tenevamo nei nostri LinuxDay) e browser non certo performanti come quelli di oggi.
MS non mi sembra la soluzione più adatta... una delle ragioni per cui l'ho abbandonato nel 2002/03.