Newsgroup: it.comp.software.emulatori
Titolo: Domanda tecnica sulla RAM del C64

Ho visto ora che nel nuovo Vice 1.19 c'è questo:
** C64 changes
--------------
- Fixed an opcode execute problem with the +60k expansion.
- New c64 256k expansion support.
Il C64 aveva 64 Kb, di cui però una parte era dedicata all'OS e al
kernal, ma in ogni caso ci si riferiva ad un intervallo tra $0000 e
$FFFF.
Come funziona una espansione? In che modo sono indirizzate le
locazioni? Come si fa ad andare oltre $FFFF?
E poi con queste espansioni cosa si poteva fare? Caricare tutti i
livelli di un gioco in RAM e accedervi al volo?
E' mai stata usata ufficialmente da qualche gioco tale espansione?
-- 
Paradoxally,
Jan AxHell

 $FFFF.
Credo che utilizzi il BANK SWITCHING: ovverosia dividi il banco di
memoria in questo o quell'indirizzo, metti un flag da una parte (non
ricordo dove, forse in un registro) e poi fai l'accesso al banco di
memoria: in questo modo puoi avere una sorta di estensione della ram o
rom accessibile.
Considera che questo é anche il sistema utilizzato per accedere a
tutta la memoria contenuta nelle cartucce: infatti il C64 può accedere
solo a 8 kb per volta.
http://www.mrsci.com/Computer-Memory/Bank_switching.php
de:Bank Switching Bank switching (also known as paging, but only
loosely related to the ordinary meaning of this term in computing) was
a technique common in 8-bit microcomputer systems, to increase the
amount of addressable RAM and ROM without extending the address bus.
Since 8-bit CPUs such as the Zilog Z80 and the MOS Technology 6502
series, with their 16-bit address registers, could only address a
maximum of 64 KB of memory, 8-bit systems containing more than 64 KB of
memory addressed the memory in 64 KB banks (or "pages") - in other
words, although the system may have contained 128 KB or more, only 64
KB was ever addressed directly at one time. This scheme offered access
to more memory at the cost of more complicated programming and somewhat
poorer performance.
While bank switching was less efficient than switching to a processor
with a wider address bus would have been, it was an inexpensive way to
increase the shelf life of several computer lines of the 1980s and it
provided a high degree of backward compatibility with earlier systems:
for example, the Apple //e, //c, and Apple /// could run software
written for the Apple II+, and the Commodore 128 could run all the
software of its much more prevalent predecessor, the C64 (which had
already employed bank switching to allow for 64KB of RAM and still
provide for ROM as well). Accessing the lower 64 KB part of memory was
as simple as addressing the first (lowest) bank.

poorer performance.
Temo che la risposta sia già questa...
-- 
Paradoxally,
Jan AxHell

 Saltello tra due banchi con uguali indirizzi?
si setta prima in genere il banco (il meccanismo varia di parecchio, da
macchina a macchina poi si fa il JSR o JMP alla locazione fisica che
contiene il banco che si e' reso disponibile col precedente settaggio.
Ovviamente e' una disperazione per chi deve scrivere assemblers, linkers,
o in generale tools per l' ASM della macchina in bankswitching.
Difatti molti problemi nell' homebrewing di console 8 bit (e anche 16 bit)
sono connessi alla mancanza di tools adeguati per creare i binari in
bankswitching.
Saluti,
Dott. Piergiorgio.

o in generale tools per l' ASM della macchina in bankswitching.
Perfetto, è esattamente come pensavo, e si capisce anche perchè questo
tipo di espansioni non abbia avuto nessun successo.
-- 
Paradoxally,
Jan AxHell

 Saltello tra due banchi con uguali indirizzi?
Non si fa perche' non si puo', il 6510 indirizza solo 64kb.
Il bank switching (con le cartucce >16kb, con la REU, la +60k, la 256k,
georam, etcetcetc) funziona sempre copiando/scambiando i dati dalla memoria
"esterna" con quella "interna".
Ogni tipo di espansione e' diversa dall'altra dal punto di vista della
gestione, ma generalmente si scrive un byte in un indirizzo a $DExxx o $DFxx
(zone riservate appunto alle espansioni, normalmente non c'e' nulla) per
impartire comandi, scanbiare i banchi etc.
Un po' di dox a riguardo.
256kb expansion
http://www.zimmers.net/anonftp/pub/cbm/documents/projects/memory/c64/256kB/256kB.html
REU Programming
http://www.hut.fi/Misc/cbm/docs/reu.programming.html
http://www.hut.fi/Misc/cbm/docs/reu.registers.html
CRT formats
http://ist.uwaterloo.ca/~schepers/formats/CRT.TXT
-- 
-=[]=--- iAN CooG/HokutoForce ---=[]=-
Un impegno concreto: piu' pleistescion per tutti

 Difatti molti problemi nell' homebrewing di console 8 bit (e anche 16
Non capisco perche' tirare in ballo le console a 8 bit quando si parla di
C64.
-- 
-=[]=--- iAN CooG/HokutoForce ---=[]=-
L'universo e' un gran giramento di palle

 - New c64 256k expansion support.
Ah! dimenticavo:
||||||||VENDO 256K ESPANSION ECSTERNAL FAILS!1|||||||||
lmao
-- 
-=[]=--- iAN CooG/HokutoForce ---=[]=-
Smith & Wesson...the original point and click interface

 lmao
Rotfl, che lamer :*

 wrote:

AHAH! puoi dirlo forte ;D
-- 
-=[]=--- iAN CooG/HokutoForce ---=[]=-
No honey, it's only a computer, PLEASE put down the gun..

 C64.
Generalizzavo il discorso.... Il bankswitching era diffusissimo su quasi
tutte le macchine, consoles, e anche qualche arcade. Del resto, il 64  non
aveva pure esso il bankswitching ? ;)
Per il resto concordo sui crossasembler, forse sono rimasto indietro
utilizzando il DASM su Linux... In questo periodo sto concentrandomi ad
individuare il modo per mettere almeno una versione del MAME <0.06 in
grado di accettare qualunque file binario su almeno una delle architetture
emulate.
Salmoria penso non abbia molto a prendersi se dico che l' errore
strutturale di base del MAME e' la rigidità nella gestione delle immagini
binarie.... ma sto divagando....
Saluti,
Dott. Piergiorgio.

 tipo di espansioni non abbia avuto nessun successo.
Principalmente perche' non c' era uno standard definito per le varie
espansioni; dai links che "Ian CooG" ha passato sono evidentissime le
incompatibilita' tra i vari meccanismi di bankswitching.
Scusate se torno ancora sulle console, ma penso sia importante
sottolineare che la natura stessa delle console rende applicabile il
bankswitching, in quanto i vari differenti meccanismi HW e SW erano
interni alle carts e relative ROM.
Saluti,
Dott. Piergiorgio.

"esterna" con quella "interna".
Io ho capito due cose, ma non so quale/se è quella giusta: 
- quando si ha l'espansione, si usa SOLO quella e non la memoria
bassa.
- quando si ha l'espansione, la si usa solo per dati, ma le routine
restano nella memoria bassa. 
-- 
Paradoxally,
Jan AxHell

 restano nella memoria bassa.
Non del tutto vero, si puo' tenere anche del codice nella memoria esterna,
codice e dati alla fine sono la stessa cosa, sono sempre bytes ;)
I N0stalgia ad esempio nei loro crack che sfruttano la REU (nsd, nsd)
caricano tutti i files del gioco, codice e dati, che verranno ricopiati
nella ram normale alla necessita.
Altro esempio, TurboAssembler+60k, modificato appunto per la +60k,
normalmente si usa caricandolo nella ram aggiuntiva, facendo una poke
$d100,$80 prima del load per far vedere i 60k aggiuntivi nello stesso
address space, come se fosse sovrapposta, quindi lo carica sempre da $9000
in poi; in effetti in questo momento stai caricando nella ram aggiuntiva del
codice, anche se per il processore e' all'indirizzo $9000, come se fosse la
vera ram interna.
Quando si compila il proprio listato, il codice oggetto viene scritto nella
vera ram del c64 (non so se ogni scrittura viene effettuata un byte alla
volta switchando i 2 banchi ($80 e $00 in $D100) o piu' byte alla volta
tramite un buffer) lasciando la normale ram del c64 completamente
utilizzabile da $1000 a $FFFF, mentre senza quest'espansione bisogna sempre
ricordarsi di non generare MAI codice che finisca da $9000 a $CFFF, pena
sovrascrittura del turboassembler stesso.
-- 
-=[]=--- iAN CooG/HokutoForce ---=[]=-
Fallo agli altri, prima che gli altri lo facciano a te.

sovrascrittura del turboassembler stesso.
Mi hai fatto sorgere (e risposto) la domanda che mi posi taaaanti anni
fa, quando mi chiedevo dove si trovasse il monitor LM della cartuccia
Fastdisk. Sinceramente non ricordo se ho indagato piů a fondo, ma
ricordo che azzerando tutta la RAM (tranne $0000-$0800), non lo
trovavo da nessuna parte (se non agivo su $0001, Basic e VIC/SID erano
perfetttamente visibili, ma se li "spegnevo", potevo vedere tutta la
RAM azzerata "sotto" le loro aree di memoria.)
O *forse* si trovava a $8000, ma č un iceberghino di ricordo che č
emerso un attimo, e cmq non capivo come fosse possibile che si
trovasse lě e io potessi cmq scrivere in quell'area.
-- 
Paradoxally,
Jan AxHell

 trovasse lě e io potessi cmq scrivere in quell'area.
La cartuccia, quando e' attiva e' a $8000, mentre quando e' in attesa di
disattiva e a $8000 il processore vede la ram normale. L'unica cosa che non
cambia praticamente mai e' l'area di controllo per espansioni ($DExx/DFxx)
che sono delle copie degli ultimi 256 byte della rom, normalmente si
troverebbero a $9e00/$9f00. Questa copia e' effettuato da un circuito nella
cartuccia che devia le address line di solo quella fettina, cosi' da poter
avere sempre un minimo di codice e di byte di controllo.
-- 
-=[]=--- iAN CooG/HokutoForce ---=[]=-
"Buongiorno, sono il maestro".
"Anch'io" rispose Gesu'.
"Cominciamo bene"

 banchi... ma e' solo una mia congettura.
Bha' io personalmente trovo elegante il metodo usato nelle cart delle
console, in cui un' area di 2,4 o 8K era sempre fissa e conteneva un
kernel (diciamo cosi') che si occupava di gestire tutte le chiamate alle
vare routine e subroutine nei vari banchi; se (per esempio e restando nel
65XX) $E000-$FFFF sono sempre le stesse qualunque sia la configurazione
dei banchi, una routine nel banco $A in diciamo, $7D00 puo' passare il
controllo a una routine nel banco $4 mappata anch' essa in $7D00 puo'
storare banco e locazione in un area della RAM (che non e' bankswitching)
e poi saltare alla routine di indirizzamento nell' area fissa, diciamo
$E700, che si occupa di settare i banchi e passare il controllo alla nuova
routine.
Forse come descrizione e' un "filino" confusa, ma spero che sia
comprensibile.
Saluti,
Dott. Piergiorgio.