cc65 e custom hardware platform

[TheKaneB]

• 

A me invece piace molto il 6809, chissà che sistemi c'erano realmente in giro ai tempi.

il 6809 era di una fascia superiore ai processori costruiti da Commodore - MOS Technology, da solo costava quanto l'intero C116 compreso un joystick e un datassette!

[ecalogiuri]

• 

Salve ragazzi,
mi fa piacere aver avuto tutti questi preziosi suggerimenti. Ora devo però chiarire una cosa. Il 6502 non è reale ma emulato tramite microcontrollore (pic o atmel, deciderò tra qualche giorno). Quindi, in realtà, posso manipolare il codice sorgente per far comportare la CPU come voglio (se avete suggerimenti, sono ben accetti). L'emulatore cattura la chiamata all'istruzione JSR e controlla l'indirizzo se è quello per le chiamate hardware, sospende la CPU virtuale, recupera i dati dalla RAM dedicata all'I/O ed esegue i compiti richiesti.

Gli interrupt software potrei anche disattivarli, perchè non necessari.

Si sil compilatore è quello (cc65) e me lo sto studiando bene  bene.

Grazie a tutti,
Enzo.

[ecalogiuri]

• 

A me invece piace molto il 6809, chissà che sistemi c'erano realmente in giro ai tempi.

L'olivetti Prodest PC128 montava uno 6809e a 1.0 MHz. 

[cdimauro]

• 

Il C128 mi è piaciuto particolarmente, tant'è che mi era venuto il pallino di studiarne nel dettaglio gli schemi elettrici. La parte più "stronza" è sicuramente quella che obbliga l'8502 a lavorare a frequenza dimezzata per colpa del VIC-III che altrimenti non gli sta dietro, e per fortuna si poteva mettere il turbo mode disattivando il display a 40 colonne.

Era VIC-II. Non c'è stato un VIC-III, perché il progettista del VIC, come pure quello del SID, andò via dalla Commodore, per cui si trovano nella merda più assoluta.

Infatti per C16 e Plus/4 rispolverarono un vecchio progetto, ma il risultato fu fallimentare (non c'erano nemmeno gli sprite, e l'audio era nettamente più scarso).

Un altro difetto era il clock dello Z80 che era sì da 4,5 MHz (mi pare), ma con parecchi wait state che lo riducevano a lavorare ad un clock equivalente a circa 2,5MHz, per potersi sincronizzare con il chipset Commodore in maniera corretta.

Di questo non ho notizia.

Questi difetti sono sicuramente sintomo di un progetto spinto dal marketing (volevano il supporto CP/M a tutti i costi), ma nonostante questo i ragazzi di Commodore hanno fatto un lavoro mostruoso in brevissimo tempo. Tanto di cappello

Senz'altro, ma erano anche disperati causa mancanza di chip designer. Infatti il 128, per quanto sia una bella macchina, rimane comunque un mostro, un Frankenstein. 2 chip video non avevano senso. Due CPU un po' meno, perché c'era il miraggio del CP/M, che però era un s.o. ormai fallito.

Insomma, di minchiate ne hanno fatte tante, e nemmeno tanto per colpa loro. La mancanza dello staff del C64 è stata micidiale.

[cdimauro]

• 

Salve ragazzi,
mi fa piacere aver avuto tutti questi preziosi suggerimenti. Ora devo però chiarire una cosa. Il 6502 non è reale ma emulato tramite microcontrollore (pic o atmel, deciderò tra qualche giorno). Quindi, in realtà, posso manipolare il codice sorgente per far comportare la CPU come voglio (se avete suggerimenti, sono ben accetti). L'emulatore cattura la chiamata all'istruzione JSR e controlla l'indirizzo se è quello per le chiamate hardware, sospende la CPU virtuale, recupera i dati dalla RAM dedicata all'I/O ed esegue i compiti richiesti.

Gli interrupt software potrei anche disattivarli, perchè non necessari.

Si sil compilatore è quello (cc65) e me lo sto studiando bene  bene.

Grazie a tutti,
Enzo.

Ma scusa, non ti conviene a questo punto inserire una nuova istruzione dedicata? Il 6502 aveva un sacco di opcode liberi. In questo modo ti eviti di confrontare ogni volta i registri: quando quella particolare istruzione viene eseguita, sei sicuro che devi fare qualcosa si speciale.

Ovviamente nel codice assembly 6502 la puoi inserire usando le classiche istruzioni DB.

[ecalogiuri]

• 

Salve ragazzi,
mi fa piacere aver avuto tutti questi preziosi suggerimenti. Ora devo però chiarire una cosa. Il 6502 non è reale ma emulato tramite microcontrollore (pic o atmel, deciderò tra qualche giorno). Quindi, in realtà, posso manipolare il codice sorgente per far comportare la CPU come voglio (se avete suggerimenti, sono ben accetti). L'emulatore cattura la chiamata all'istruzione JSR e controlla l'indirizzo se è quello per le chiamate hardware, sospende la CPU virtuale, recupera i dati dalla RAM dedicata all'I/O ed esegue i compiti richiesti.

Gli interrupt software potrei anche disattivarli, perchè non necessari.

Si sil compilatore è quello (cc65) e me lo sto studiando bene  bene.

Grazie a tutti,
Enzo.

Ma scusa, non ti conviene a questo punto inserire una nuova istruzione dedicata? Il 6502 aveva un sacco di opcode liberi. In questo modo ti eviti di confrontare ogni volta i registri: quando quella particolare istruzione viene eseguita, sei sicuro che devi fare qualcosa si speciale.

Ovviamente nel codice assembly 6502 la puoi inserire usando le classiche istruzioni DB.

Interessante idea... 

[ecalogiuri]

• 

OK, fammi sapere se ti va bene un modello tra quelli a disposizione, p.e. {apple2, apple2enh, … }, se e' così poi lo si può clonare modificando i sorgenti stessi della toolchain, va aggiunto in diversi punti e va fornita una libreria.

la toolchain prevede che il modello venga usato -t modello
p.e.

Codice: [Seleziona]


all: apple2

apple2:
        @echo -n "- building for apple2 ... "
        @cl65 -O -t apple2 hello.c text.s
        @echo "done"

apple2enh:
        @echo -n "- building for apple][ ... "
        @cl65 -O -t apple2enh hello.c text.s
        @echo "done"

my:
        @echo -n "- building for my ... "
        @cc65 -O -t my hello.c
        @cl65 -O -t my hello.c text.s
        @echo "done"

clean:
        @rm -f hello


Io ho aggiunto un finto modello "my", ed ho dovuto modificare

src/common/target.h
src/common/target.c
src/cc65/main.c
src/ca65/main.c
src/ld65/main.c

Pensavo che non fosse necessario modificare il sorgente del cc65. Nella documentazione ho trovato questa pagica (http://oliverschmidt.github.io/cc65/doc/customizing.html) che spiega come creare una piattaforma custom. Pensi che sia utile?

Non che sia un problema smanettare nel codice sorgente, ma preferirei evitarlo, visto tutte le cose che devo fare...

Grazie.

P.s.
Userò un ATMega32, penso a 20 Mhz ed emulatore svincolato dalla simulazione dei wait state per istruzione. La zero page la mapperò direttamente nella memoria del microcontrollore, spero così di guadagnare un pò di velocità...

[cdimauro]

• 

Userò un ATMega32, penso a 20 Mhz ed emulatore svincolato dalla simulazione dei wait state per istruzione. La zero page la mapperò direttamente nella memoria del microcontrollore, spero così di guadagnare un pò di velocità...

Se il 6502 viene emulato alla massima velocità (senza, quindi, rispettare la sua pipeline per l'esecuzione delle istruzioni), allora se migliori l'accesso alla pagina zero migliori sicuramente la velocità d'esecuzione, visto che è LA zona di memoria per eccellenza e usatissima da questo processore. Se ti avanzano altri 256 byte, infilaci anche lo stack, visto che anche quest'area di memoria è molto usata.

[cdimauro]

• 

Raga, non mi torna quello che ci siamo detti, per 6502 trovo l'istruzione TXS Transfer index X to stack pointer quindi posso piazzami lo stack dove mi pare,

No, non funziona così. Con quell'istruzione cambi soltanto il puntatore all'elemento corrente dello stack. Lo stack non si può muovere da $0100-$1FF: è hard-coded su 6502.

semmai c'e' una modalità di accesso alla memoria che e' ristretta SOLO alla page0, ma questo e' opzionale, ovvero puoi aggirarla usando altre modalità.

La zero page è fondamentale, come dicevo. Acceleratene l'accesso, se è possibile, se v'interessano le prestazioni.

[cdimauro]

• 

No, il puntatore allo stack era a 16 bit: poteva coprire tutta la memoria.

[cdimauro]

• 

Vero. Infatti anche il registro X (e Y) è a 8 bit, nel 6502.

Non è un gran fregatura: con 256 byte di stack puoi memorizzarci 128 indirizzi di ritorno. Oppure 256 dati a 8 bit.

Sì, può sembrare una grande limitazione, ma all'atto pratico non si tratta di un limite concreto, col quale ti scontri tutti i giorni.

[cdimauro]

• 

Ma perché cambi i messaggi. Non si capisce nulla così.

[cdimauro]

• 

No, gli offset erano a 16 o 8 bit su 6502, a seconda della modalità d'indirizzamento (ce n'erano diverse; questo era uno dei suoi punti di forza).

[TheKaneB]

• 

@legacy: e cambialo sto cesso di browser, capita solo a te sta cosa

[TheKaneB]

• 

il Motorola 6800 costava $150, il MOS 6502 ne costava $15, e fu progettato da alcuni degli ex progettisti Motorola. Subirono poi una causa legale, che vinsero (il design era stato rifatto da capo, non c'era nulla di sostanzialmente copiato).

Ho risposto ai tuoi dubbi?