Allegati: 1
Guida all'emulatore amiga360
http://s10.postimg.org/awi1x11qx/000...1712435046.png
Vorrei cominciare la stesura di questo piccolo approfondimento sull'emulatore AMIGA, evitando seppur doverosi cenni storici alle alterne vicende della fù "Hi-Toro" poi "Amiga Corporation" migrata in "Commodore" fino ad arrivare ai giorni nostri nella reincarnata e fantasmagorica (in tutti i sensi) "Amiga Inc".
Credetemi, non basterebbe un forum intero per rendere esaustivo l'argomento!
Tuttavia, per comprendere a pieno le opzioni dell'emulatore in questione, non possiamo sottrarci "dall'infarinatura" di alcuni concetti tecnici di base legati alla architettura AMIGA.
Probabilmente la schermata più "importante" dell'emulatore AMIGA360 è riassunta nel campo "Options":
http://s10.postimg.org/4wuatdgyh/FFF...7124248749.png
Qui possiamo scegliere tra varie tipologie di CPU, CHIPSETS, CHIP MEMORY, Slow Memory, Fast Memory, Z3 Fast Memory, RTG Memory, Controllers, CHE SONO TUTTE OPZIONI LEGATE ALL'HARDWARE AMIGA ESISTENTE, OVVERO ALLA PARTICOLARE DOTAZIONE ONBOARD CHE VOGLIAMO CREARCI (un pò come avviene oggi per i moderni PC), mentre le opzioni sul lato in alto a destra dello schermo potremmo relegarle più ad opzioni "cosmetiche", ovvero artifizi emulativi che potranno arricchire e/o abbellire la nostra esperienza AMIGA in base a ciò che vorremmo fargli eseguire (Videogames piuttosto che Internet Browsing o programmi di vario genere in ambiente Workbench)
Un'Amiga500 (forse il più diffuso tra gli ex pischelli degli anni 80 come il sottoscritto) era dotato di una CPU MC68000, con una ROM da 256kb ed una RAM da 512kb (espandibile ad 1Mb), Un Floppy Drive incorporato (Fd0) da 3,5" ed un Sistema Operativo Workbench 1.2 od 1.3. Doveroso introdurre il concetto di Kickstart, ovvero un bootable floppy disk utilizzato per caricare funzionalità basiche necessarie poi al boot del sistema operativo (Amiga WorkBench) che avveniva generalmente anch'esso tramite floppy disks.
Come i più arguti avranno dedotto, il sistema operativo era dunque interamente precaricato ed utilizzato in memoria (perlomeno nel caso dell'Amiga500).Potremmo paragonare un simile meccanismo a quello di una distribuzione Linux in LiveCD, ovvero senza installare nulla in HardDisk.
Possedere un'hard disk era infatti "pura utopia" e cmq appannaggio esclusivo dei soli modelli superiori di Amiga, oltreche degli utenti "più ricchi" (moooolto più ricchi n.d.r.).
Per semplicità potremmo definire il kickstart una sorta di PC BIOS dei giorni nostri.
Normalmente, tale Kickstart era storato all'interno della ROM di sistema di cui però non era previsto upgrade flashing da parte dell'utente finale, che poteva dunque ovviare a tale "limite", (ad esempio in caso di utilizzo di una determinata versione di workbench che richiedeva necessariamente una determinata versione di Kickstart) utilizzando la metodologia di booting con il "kickstart floppy disk" all'interno del drive (mica bau bau micio micio n.d.r.).
Ai fini dell'utilizzo di AMiga360, vi basti sapere che per un ottima compatibilità con i VideoGames è opportuno utilizzare il "Kickstart 1.3".
http://s10.postimg.org/4ez5dirdl/FFF...7124113658.png
Tale utilizzo è assolutamente VITALE al funzionamento dell'emulatore, il quale però, per motivi di copyright Amiga tutt'ora vigenti, non lo fornisce "direttamente"; pertanto dovrete reperire il file "kick.rom" di vostro interesse ed andarlo a posizionare nella cartella "KickStarts", pena l'inevitabile NON FUNZIONAMENTO dell'emulatore.
Aggiungerei questa piccola nota di sarcasmo: Interessante notare come Lantus sia più rispettoso del copyright di un kickstart AMiga risalente alla metà degli anni 80 (che non fornisce direttamente), che dell'XDK Microsoft tramite il quale compila e distribuisce l'emulatore per console JTAG.... (mumble...mumble...sono forse troppo polemico!..?! n.d.r.).
Il rovescio della medaglia è forse un innegabile rispetto verso la Commodore che tutt'oggi aleggia in molti ambienti Underground....e che difficilmente la Microsoft riuscirà ad eguagliare anche nel prossimo futuro...(..cosa volete che sia un xdx leaked..!!..)
Per quanto riguarda la scelta delle opzioni di chipset date un'occhio a questo piccolo vademecum:
OCS = Original CHip-Set chiamato poi Old Chip-Set con l'avvento di ECS ed AGA
Era costituito da tre chip: Agnus (accesso alla memoria), Denise (Gestione della Grafica) e PAula (Gestione del SOnoro)
ECS= Enhanced Chip-Set, costituito anch'esso da tre chip: Super Agnus, SUper Denise e Paula
AGA (Nome in codice PAndora)= Advanced Graphics Architecture: Costituito da Alice (Accesso alla memoria), Lisa (Gestione della Grafica), Paula (Gestione del Sonoro).
L'emulatore ci dà la possibilità di emulare DUE situazioni NON ESISTENTI NELLA REALTA', ovvero ECS AGNUS ed ECS DENISE a fini esclusivamente di compatibilità e miglior resa emulativa. In pratica possiamo emulare un ECS con Super Agnus ma Denise "liscia" piuttosto che un ECS con Super Denise ma Agnus "liscia".
La scelta di questa opzione dipende sempre dal particolare software o videogames che vogliamo startare...generalmente utilizzando OCS e/o ECS non avremo problemi.
La CHip Memory è il quantitativo di Memoria Ram gestito da Agnus od Alice.
Teniamo conto di questo specchietto per la nostra scelta:
Amiga 1000 = Max Chip Ram 256kb
Amiga 500, Amiga 2000 = Max Chip Ram 1Mb
Amiga 500plus, Amiga600= Max Chip Ram 2Mb
Amiga 1200, Amiga 4000= Max Chip Ram 2Mb
Noterete che l'emulatore ci dà la possibilità di selezionare anche 4mb ed 8Mb di Chip Memory: si tratta anche questa volta di una SITUAZIONE NON ESISTENTE NELLA REALTA' poichè preclusa da un limite fisico di AGNUS/ALICE, ma che a livello emulativo può tranquillamente essere realizzata andando ad aumentare le performance con determinati software che si vogliono startare.
Personalmente, per la miglior compatibilità videogames, consiglio l'utilizzo di 1Mb di Chip Memory
Amiga era poi dotata di Fast Memory, ovvero una particolare memoria ad accesso esclusivo della sola CPU, che migliorava le performance quando CPU e Chipset devono accedere simultaneamente alla CHIP MEMORY. Il suo utilizzo migliora sensibilmente le performance e ne consiglio generalmente l'utilizzo ad 1Mb.
La SLow Memory è invece utilizzata solo per mantenere la compatibilità con alcuni software
La Z3 Fast Memory simula invece la memoria che era utilizzata attraverso un'apposito slot di espansione sui modelli Desktop di Amiga (Generalmente potete lasciare disabilitata questa opzione).
La RTG Memory (Real Time Graphics Memory) è invece utilizzata nella emulazione di una particolare scheda (Picasso) utilizzata esclusivamente in ambiente Workbench unitamente ad alcuni programmi di Grafica. Generalmente potete lasciare disabilitata questa opzione, o perlomeno fintanto chè non flaggate anche l'apposita opzione Picasso96 (andando poi ad installare in ambiente workbench anche appositi driver che ne abilitano la funzionalità).
La funzionalità di Drive Click andrà ad emulare la capacità che aveva AMIGA di detectare automaticamente l'inserimento di un floppy disk nel drive
La funzionalità di Cycle Exact può risultare utile nel caso l'emulazione sia troppo velocizzata e/o troppo rallentata
La funzionalità di Show Leds risulta invece molto utile, poichè genera a schermo un piccolo riquadro che simula i led di stato della nostra amiga virtuale.
Nel Campo Controllers è opportuno lasciare invariata l'opzione di default "Mouse & Joystick (Port2)" per avere entrambe le funzionalità a portata di PAD
Nelle console JTAG non è infatto supportato l'utilizzo di un MOUSE USB REALE diversamente dalle sorelle DEVKIT dove invece è possibile farlo, ma su entrambe è cmq possibile (aggiungerei necessario nei casi in cui ci si ritrova a dover digitare ESC in alcuni caricamenti videogames) l'utilizzo di una TASTIERA USB come quella che utilizza il sottroscritto:
http://s10.postimg.org/4g936xt7d/FFF...7124127685.png
TENETE A MENTE CHE L'EMULATORE VIENE FORNITO CON DUE ESEGUIBILI
Amiga360.xex (Specifico per JTAG)
Amiga360-Dev.xex (Specifico per DEVKIT)
NON SONO OVVIAMENTE INTERSCAMBIABILI
Le immagini dei nostri floppy disk Amiga (che hanno estensione .adf ovvero Amiga Disk File) le andremo a posizionare nella cartella ROMS
Eventuali Immagini di HardDisk ( che hanno estensione .hdf ovvero Harddisk Disk File) le posizioneremo nella cartella Hardfiles
Il caricamento dei nostri floppy disks lo effettuiamo dal menu Disks andando a selezionare il nostro Floppy Drive Onboard (DF0) con il tasto LB ed il caricamente dell'imagine .adf con il tasto X
Potremmo eventualmente simulare la presenza di altri 3 Floppy Drive (PER UN TOTALE DI 4) in cui potremmo inserire altre immagini facenti parte della suite software dello specifico gioco. Eviteremmo così un antipatico e continuo SWAP delle nostre immagini .adf.
Purtroppo però tale modalità non è sempre supportata dal software, che a volte richiede inevitabilmente di essere sempre e cmq startato da DF0....
Allegato 936
Come cambiano i tempi....da questa CRACK INTRO i Paradox pubblicizzavano il loro indirizzo!
Allegato 939
Bene, di sicuro l'argomento non è esaurito...diciamo che avete uno spunto da cui partire per essere autonomi nell'utilizzo di questo "gran pezzo di software"...eventuali dubbi e/o perplessità potremmo affrontarli di volta in volta.
Vorrei però lasciarvi con una piccola "chicca"...una chiacchierata fatta direttamente con l'autore (Lantus) del software Amiga360 riguardo alcuni aspetti "poco chiari" sul mondo JTAG FREEBOOT VS RGH IPOTETICO E FUTURO LOADER BOOTER..
Sembra che un Emulatore Commodore64 sia alle porte...e viene lasciato intendere su un contesto Freeboot vs LibXenon che "RGH IS THE FUTURE"...pertanto..se mi è lecito interpretare...credo che un booter arriverà quanto prima...
Buona lettura:
http://img20.imageshack.us/img20/4549/interviewoi.jpg
L'emulatore (protetto da Copyright XDK n.d.r.) scaricabile da [url=http://www.homebrew-connection.org/files/xbox/Emulators/]Directory index · styled with h5ai[/url], mentre il suo codice sorgente è prelevabile da qui [url]https://github.com/Pa0l0ne/Amiga360[/url]
Vi lascio con un video dimostrativo
http://youtu.be/p0poX7xkkFQ
Guida all'emulatore amiga360
Diatriba?
Diciamo che e' come se volessi convincere un Richard Stallman ad usare un Iphone.
Generalmente chi programma in libxenon non vede di buon occhio chi programma in XDK. Con Libxenon hai il totale controllo della consolle e non ti affidi ad API (di cui devi fidarti...). Ovvio che il totale controllo di libxenon e' pur prestazionalmente limitato rispetto alle API native, non tanto perche' sia "qualcos'altro" ma piuttosto perche' nato da un inmenso lavoro di retroingegnerizzazione in continua evoluzione: anzi in questo senso si puo' dire non sia ancora mai nato...
Prova ora a pensare ad un Mupen64.elf...non tanto il codice in se' (che e' pur di provenienza di qualcun'altro di diverso da Gligli), ma alla sua compilazione che va' a buon fine e comunica poi allo stato dell'arte con l'hardware...
E' come se tu riuscissi a far lavare i panni al tuo frigorifero!
Questa e' arte ed io mi ci emoziono ancora quasi quanto ammirare una "Gioconda di Leonardo"...
