cc65 e custom hardware platform

[ecalogiuri]

• 

Salve ragazzi,
vorrei utilizzare questo compilatore c per 6502 su un mio hardware custom da realizzare. Qualcuno conosce tale compilatore? E potrebbe darmi una mano su come creare una configurazione personalizzata per il mio hardware? Se qualcuno è in grado di aiutarmi poi fornisco i dettagli precisi dell'hardware.

Ciao a tutti.

[ecalogiuri]

• 

Quale C compiler usi  per 6502 ? SDCC ?

A prescindere anticipo che ti serve nell'ordine
- fare un memory layout dettagliato
- con cui confezionare un linker script adeguato
- scriverti una BSP anche minimale (p.e. dove implementi almento la putc/getc verso seriale, polling)

Che hw e' ?

No, uso il cc65. L'SDCC non supporta la CPU 6502. L'hardware lo sto sviluppando. La memoria massima sarà di 32Kb e dovrebbe essere divisa in tale modo:

• Zero page
• Gestione IO
• User ram

 

[TheKaneB]

• 

se usi la pagina $0100-$01FF come stack, puoi riciclare buona parte del codice del KERNAL commodore, o comunque puoi scopiazzare il suo memory layout per semplificarti la vita con il linker.

[ecalogiuri]

• 

se usi la pagina $0100-$01FF come stack, puoi riciclare buona parte del codice del KERNAL commodore, o comunque puoi scopiazzare il suo memory layout per semplificarti la vita con il linker.

Interessante!!! Infatti pensavo di piazzare proprio lì lo stack, dopo la zero page. Quindi:

• Zero Page (0$..100$)
• Stack ($100..$1FF)
• Gestione IO (mi bastano sei byte)
• User ram

Così dovrebbe andare bene... 

[TheKaneB]

• 

il 6502 non ha memoria interna, è la CPU del Commodore VIC-20 e parente stretto di quella del C64.

[TheKaneB]

• 

non conosco il 6811, non saprei farti un confronto.

Mappare della memoria più veloce sulle prime due pagine non cambierebbe nulla, perchè la CPU non implementa wait state, quindi ha bisogno di Ram con lo stesso tempo di accesso su tutto lo spazio di indirizzi.

Se la memoria mi assiste, nelle macchine Commodore era il chip video (il VIC ed il VIC-II) che si occupava di gestire il refresh della DRAM e, durante tale fase, staccava proprio il clock alla CPU. Quindi se vuoi replicare un design simile ti serve un circuito esterno che ascolta sull'Address Bus e tramite un oscillatore PLL ti fornisce un clock "manipolato" alla CPU per implementare allo stesso modo i wait state.

Comunque, considera che la variante più veloce che abbia mai visto in commercio ha un clock di 4MHz (1 MHz sul VIC-20), quindi fai presto a usare 32KB di static ram su tutto lo spazio degli indirizzi e buona notte. Così ti togli tante rogne anche per il refresh.

[TheKaneB]

• 

dovrei riprendere in mano alcuni manuali, perchè non ricordo tutti questi dettagli :\

Comunque non farei una cosa così complessa, puoi sbattere tutto su un solo chip di Ram statica e via. Meno componenti e meno sbattimenti. La NVRAM non so quanto sia utile su un coso che non è nato per fare da microcontroller (ci sono le versioni embeddate in MCU apposta per questo). Alla fine mi pare di capire che il progetto in questione sia una sorta di design "replica home computer" stile anni '80.

[TheKaneB]

• 

ho capito, quindi risulta comodo in fase di sviluppo, pensavo che ti riferissi ad una soluzione per la macchina "fatta e finita".

[Z80Fan]

• 

Il 6502 non ha lo stack spostabile, il suo stack pointer è a 8 bit e gli 8 bit più significativi sono hard-coded a $01 (per questo $0100-$01FF è lo stack). Ciò vuol dire anche che hai solo 256 byte massimi di stack.

La pagina zero ($0000-$00FF) è particolare nei 6502 e famiglia perchè prima di tutto ci sono modalità di indirizzamento che possono assumere come $00 la parte alta degli indirizzi, perciò accedere alla pagina zero richiede un byte in meno per l'istruzione che esegue l'accesso; in più, quello spazio viene praticamente usato come "estensione" del set di registri (il 6502 ne ha solo 3 utili all'utente: A,X,Y e tutti a 8 bit), ad esempio per avere puntatori a 16 bit per indirizzamenti indiretti.
La pagina zero è quindi fondamentale per un 6502 (e derivati).

Bisogna anche stare attenti che i vettori di interrupt mascherabile, non mascherabile e reset sono hard-coded come le ultime 3 word a 16bit dello spazio di indirizzi (quindi $FFFA-$FFFB, $FFFC-$FFFD, $FFFE-$FFFF), quindi è ESSENZIALE che in quello spazio ci sia della ROM o qualcosa di preinizializzato.

[cdimauro]

• 

Esattamente. Purtroppo quando sono a lavoro non posso intervenire, ma hai ampiamente spiegato tutto.

Per cui è fondamentale mappare memoria nei primi 512 byte, e qualcosa alla fine dei 64KB, come hai sottolineato. Quindi l'idea di legacy per la suddivisione dello spazio d'indirizzamento è ottima.

[TheKaneB]

• 

Si questo è chiaro, ma durante il reset puoi sempre forzare alcune linee di indirizzi per manipolare l'indirizzo fisico, andando a "taroccare" i segnali di chip enable. Non dico roba stile MMU, ma molto più rudimentale. Il C64 ed il C128 usavano questa tecnica per varie operazioni con il VIC e per il bank switching.

[cdimauro]

• 

E l'Amiga per il reset, visto che la ROM era mappata a $FC0000, ma i vettori a $0, per cui al reset la ROM veniva riconfigurata a $0, in modo che il 68000 potesse prelevare l'indirizzo della routine di reset, e poi veniva fatta sparire da $0.

EDIT: il 128, però, aveva un'MMU.

[TheKaneB]

• 

Sì lo so, Bil Herd l'aveva chiamata MMU, ma rispetto a quelle che chiamiamo "modernamente" MMU è una cosa molto più rudimentale. Il C128 resta comunque una macchina affascinante, specie per l'uso molto particolare che faceva dello Z80 (era la CPU principale durante il Boot, prima di svegliare il chippetto 8502).

[cdimauro]

• 

Esattamente. Ho finito di leggere proprio questa storia giusto qualche giorno fa, per cui sono gasatissimo. Il mio adorato 128!!!

[TheKaneB]

• 

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. 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. 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