Certo che puoi. Per favore vai al forum di AROS-Exec
e leggi i thread e chiedi ciò che vuoi. Questa FAQ verrà aggiornata con
le domande degli utenti, ma il forum rimane sempre più recente.
La legge europea dice che è legale applicare le tecniche di reverse
engineering al fine dell'interoperabilità. Dice anche che è illegale
distribuire la conoscenza acquisita tramite queste tecniche.
Sostanzialmente significa che sei autorizzato a disassemblare qualunque
software per scrivere qualcosa di compatibile (per esempio, sarebbe
legale disassemblare Word per scrivere un programma che converte i
documenti di Word in testo ASCII).
Ci sono ovviamente delle limitazioni: non sei autorizzato a
disassemblare il software se l'informazione che vuoi ottenere così
facendo può essere ottenuta in altri modi. Inoltre non puoi comunicare
ad altri ciò che hai imparato. Un libro come "Windows Inside" è quindi
illegale o al limite della legalità.
Poichè noi evitiamo le tecniche di disassemblaggio e al loro posto
usiamo conoscenze liberamente disponibili (che includono i manuali di
programmazione) che non sono sotto nessun NDA, quanto detto non si
applica direttamente ad AROS. Quello che conta qui è l'intento della
legge: è legale scrivere software che è compatibile con qualche altro
software. Quindi crediamo che AROS è protetto dalla legge.
Brevetti e file header sono un altro problema. Possiamo usare degli
algoritmi brevettati in Europa poichè la legge Europea non ammette
brevetti sugli algoritmi. Comunque, il codice che usa questi algoritmi
che sono brevettati negli USA non possono essere importati negli USA.
Esempi di algoritmi brevettati in AmigaOS includono lo spostamento degli
schermi e il modo particolare con cui funzionano i menu. Quindi evitiamo
di implementare queste caratteristiche nello stesso esatto modo. I file
header, d'altra parte, devono essere compatibili ma il più possibile
diversi dagli originali.
Per evitare ogni problema ci siamo mossi per ottenere un OK ufficiale da
Amiga Inc. Loro vedono positivamente il nostro sforzo, ma sono molto
incerti sulle implicazioni legali. Ti suggeriamo di prendere atto che
Amiga Inc non ci ha mandato alcuna lettera di Cease and Desist come
segno positivo. Sfortunatamente, nessun contratto legale è stato fatto
finora, a prescindere dalle buone intenzioni di entrambe le parti.
Ci sono state discussioni sullo scrivere un OS avanzato con le
caratteristiche di AmigaOS. Ciò è stato abbandonato per una buona
ragione. Primo, tutti sono d'accordo che l'attuale AmigaOS andrebbe
migliorato, ma nessuno sa come fare e nemmeno cosa va migliorato o cosa
è importante. Per esempio, alcuni vogliono la protezione della memoria,
ma non vogliono pagarne il prezzo (grossa riscrittura del software
disponibile e perdita di velocità).
Alla fine, le discussioni finirono in flame o in reiterazione degli
stessi vecchi argomenti ancora e ancora. Così abbiamo deciso di iniziare
con qualcosa che sapevamo come gestire. A quel punto, quando abbiamo
l'esperienza per vedere cosa è possibile e cosa no, decidiamo i
miglioramenti.
Vogliamo anche ottenere la compatibilità binaria con l'AmigaOS originale
dell'Amiga. La ragione di questo è che un nuovo OS senza nessun programma
che ci gira sopra non ha possibilità di sopravvivvere. Quindi tentiamo
di rendere la migrazione dall' OS originale al nostro la più indolore
possibile (ma senza impedirci di migliorarlo). Come al solito, tutto ha
il suo prezzo e noi proviamo a decidere con cautela quale possa essere e
se noi e chiunque altro sia disponibile a pagarlo.
No, per le seguenti ragioni:
- Se era veramente importante, sarebbe già nell'OS originale. :-)
- Potresti implementarla tu e mandarci una patch!
La ragione di questo punto di vista è che ci sono un sacco di persone in
giro che pensano che quella caratteristica è la più importante e che AROS
non ha futuro se non viene implementata nel modo giusto. La nostra
posizione è che AmigaOS, che AROS aspira a implementare, può fare
qualunque cosa che un moderno OS può fare. Vediamo che ci sono aree in
cui AmigaOS potrebbe essere migliorato, ma se lo facciamo, chi
scriverebbe il resto dell'OS? Alla fine, avremmo ottenuto un sacco di
simpatici miglioramenti all'AmigaOS originale che non farebbero più
funzionare il software disponibile e non varebbero nulla, perchè il
resto dell'OS sarebbe mancante.
Quindi, abbiamo deciso di bloccare ogni tentativo di implementare nuove
caratteristiche di rilievo nell'OS fino a quando non sarà più o meno
completato. Ci stiamo quasi avvicinando al traguardo adesso, e ci sono
un paio di innovazioni implementate in AROS che non sono disponibili in
AmigaOS.
Molto compatibile. Crediamo che AROS farà girare il software esistente
su Amiga senza problemi. Su altro hardware, il software esistente deve
essere ricompilato. Offriremo un preprocessore che potrete usare sul
vostro codice che modificherà ogni codice che potrebbe non andare su
AROS e/o vi avviserà di quel codice.
Portare programmi da AmigaOS ad AROS è attualmente per la maggior parte
un lavoro di semplice ricompilazione, con qualche occasionale ritocco
qua e la. Ci sono ovviamente dei programmi per cui non è così, ma
funziona per la maggior parte di quelli moderni.
Attualmente AROS è disponibile in uno stato abbastanza usabile come
nativo o hosted (sotto Linux e FreeBSD) per l'architettura i386 (es.
cloni IBM PC AT compatibili). Ci sono dei porting a vari livelli di
completezza per SUN SPARC (ospitato sotto Solaris) e palmari Palm
compatibili (nativo).
C'è attualmente in atto un tentativo di portare AROS su PPC,
inizialmente ospitato su Linux.
Usiamo Linux e X11 per velocizzare lo sviluppo. Per esempio, se
implementi una nuova funzione per aprire una finestra puoi
semplicemente scrivere quella singola funzione e non aver da
scrivere centinaia di altre funzioni in layers.library,
graphics.library, un sacco di device driver e tutto il resto di cui la
funzione ha bisogno.
L'obiettivo di AROS è certamente di essere indipendente da Linux e X11
(ma restando capace di girarci sopra se la gente lo vuole veramente), e
ciò sta lentamente diventando una realtà con le versioni native di AROS.
Comunque abbiamo ancora bisogno di Linux per lo sviluppo, poichè alcuni
tool di sviluppo non sono stati ancora portati su AROS.
Una delle maggiori nuove caratteristiche di AROS a confronto con AmigaOS
è il sistema HIDD (Hardware Independent Device Drivers), che ci
permetterà di portare AROS su hardware differente abbastanza facilmente.
Sostanzialmente, le librerie di base dell'OS non toccano l'hardware
direttamente, ma passano invece attraverso gli HIDD, che sono programmati
usando un sistema orientato agli oggetti che rende semplice sostituire
gli HIDD e riusare il codice.
Sentiamo ogni giorno da un sacco di gente che AROS non ci riuscirà. Molti
di loro non sanno quello che stiamo facendo o pensano che Amiga è già
morto. Dopo aver spiegato ai primi quello che facciamo, molti concordano
che è possibile. I secondi fanno più problemi. Bene, Amiga è morto al
momento? Quelli che stanno ancora usando i loro Amiga vi diranno
probabilmente che non è così. I vostri A500 o A4000 sono esplosi quando
la Commodore andò in bancarotta? Sono esplosi quando lo ha fatto Amiga
Technologies?
Il fatto è che c'è poco software nuovo sviluppato per l'Amiga (sebbene
Aminet vada ancora avanti simpaticamente) e l'hardware è sviluppato a una
velocità inferiore (ma gli aggeggi più sbalorditivi sembrano apparire
ora). La comunità Amiga (che è ancora viva) sembra essere seduta in
attesa. E se qualcuno rilascia un prodotto che è un minimo simile a
quello che era l'Amiga nel 1984, allora quella macchina avrà di nuovo
successo. E chi lo sa, può essere che con quella macchina troverai un CD
con su scritto "AROS". :-)
Per favore, invia un messaggio con i dettagli (ad esempio, il messaggio
di errore che ottieni) sul forum di aiuto di AROS-Exec o diventa uno
sviluppatore e iscriviti alla lista di sviluppatori AROS e invia il
messaggio lì, e qualcuno proverà ad aiutarti.
Diverse centinaia di esperti Amiga (questo è quantomeno quello che loro
pensano di essere) hanno provato per tre anni a trovare un modo di
implementare la protezione della memoria (MP) su AmigaOS. Non ce l'hanno
fatta. Dovreste considerare questo come il fatto che il normale AmigaOS
non avrà mai MP come Unix o Windows NT.
Ma non tutto è perduto. Ci sono piani per integrare una variante della
MP in AROS che permetterà la protezione almeno nei nuovi programmi che
ne saranno a conoscenza. Alcuni sforzi in questo campo sembrano
promettenti. Inoltre, è davvero un problema se la vostra macchina va in
crash? Lasciatemi spiegare prima di inchiodarmi a un albero. :-) Il
problema non è che la macchina crasha, ma piuttosto:
- Non avete alcuna idea del perchè sia crashata.
- Perdete il vostro lavoro. Riavviare la macchina non è un vero
problema.
Quello che possiamo provare a costruire è un sistema che almeno avverte
se qualcosa di strano sta succedendo e che possa dirvi in gran dettaglio
cosa stava succedendo quando la macchina è andata crash e che vi
permetta di salvare il vostro lavoro e prima di crashare. Ci sarà
anche un mezzo per controllare cosa è stato salvato così che possiate
essere sicuri di non continuare con dati corrotti.
La stessa cosa è per SVM (swappable virtual memory), RT (resource
tracking) e SMP (symmetric multiprocessing). Stiamo attualmente
pianificando come implementarli, assicurandoci che aggiungere queste
caratteristiche sarà indolore. Comunque, queste non hanno la massima
priorità al momento. Una RT molto elementare è stata aggiunta, comunque.
Certo, nessun problema. Infatti, noi vogliamo più beta tester possibili,
per cui ognuno è il benvenuto! Comunuque non teniamo una lista di beta
tester, quindi tutto quello che dovete fare è scaricare AROS, testare
ciò che volete e inviarci un report.
UAE è un emulatore Amiga, e come tale ha degli obiettivi in qualche modo
diversi da AROS. UAE punta alla compatibilità binaria sia per i giochi e
il codice che accede direttamente all'hardware, mentre AROS vuole avere
applicazioni native. Quindi AROS è molto più veloce di UAE, ma puoi far
girare molto più software sotto UAE.
Siamo in contatto con l'autore di UAE e c'è una buona possibilità che il
codice di UAE apparirà in AROS e vice versa. Per esempio, gli
sviluppatori di UAE sono interessati al sorgente dell'OS perchè UAE
potrebbe far girare alcune applicazioni più velocemente se alcune o
tutte le funzioni dell' OS fossero sostituite con codice nativo.
Dall'altro lato, AROS potrebbe beneficiare dell'avere un'emulazione
Amiga integrata.
Siccome molti programmi non saranno disponibili su AROS all'inizio,
Fabio Alemagna ha portato UAE su AROS così puoi usare i vecchi
programmi almeno in un box di emulazione.
Haage & Parner ha usato parti di AROS in AmigaOS 3.5 e AmigaOS 3.9, per
esempio la ruota dei colori e il gadget gradientslider e il comando
SetENV. Questo significa che in qualche modo, AROS è diventato parte
dell' AmigaOS ufficiale. Questo non implica che c'è qualche relazione
formale tra AROS e Haage & Partner. AROS è un progetto open source, e
chiunque può usare il nostro codice nei loro progetti a patto che
seguano la licenza.
La relazione tra AROS e MorphOS è sostanzialmente la stessa che c'è tra
AROS e la Haage & Partner. MorphOS usa parti di AROS per velocizzare il
loro sforzo di sviluppo; sotto i termini della nostra licenza. Come con
Haage & Partner, questo è bene per entrambi i team, in quanto il team di
MorphOS riceve una spinta al loro sviluppo da AROS e AROS ottiene buoni
miglioramenti al nostro codice sorgente dal team di MorphOS. Non c'è
alcuna relazione formale tra AROS e MorphOS; questo è semplicemente come
funziona lo sviluppo di software open source.
La maggior parte dello sviluppo per AROS è fatto usando ANSI C
crosscompilando i sorgenti sotto un OS diverso, es. Linux o FreeBSD.
Fabio Alemagna ha completato un port iniziale di GCC a i386 nativo.
Comunque, non è attualmente nella ISO o integrato nel build system.
I linguaggi attualmente disponibili nativamente sono Python, Regina e
False:
- Python è un linguaggio di scripting che è divenuto abbastanza popolare,
grazie alla sua buona progettazione e caratteristiche (programmazione
orientata agli oggetti, systema a moduli, molti moduli utili inclusi,
sintassi pulita, ...). Un progetto separato è stato iniziato per il
porting su AROS e può essere trovato qui:
http://pyaros.sourceforge.net/.
- Regina è un interprete REXX portabile e ANSI compliant. L'obiettivo
per il porting su AROS è quello di essere compatibile con l'interprete
ARexx per l'AmigaOS classico.
- False può essere classificato come un linguaggio esotico, quindi
probabilmente non sarà usato per sviluppo serio, sebbene può essere
molto divertente. :-)
Per far funzionare i vecchi programmi Amiga su AROS, abbiamo portato UAE
su AROS. La versione AROS di UAE sarà probabilmente un po' più veloce di
altre versioni di UAE poichè AROS richiede meno risorse di altri sistemi
operativi (che significa che UAE otterrà più tempo macchina), e proveremo
a patchare la ROM Kickstart in UAE in modo da chiamare le funzioni AROS
che porteranno un altro piccolo miglioramento. Ovviamente, questo si
applica solo ad AROS nativo e non hosted.
Ma perchè non abbiamo implementato semplicemente una CPU virtuale m68k
per far funzionare il software direttamente su AROS? Bene, il problema è
che il software m68k si aspetta che i dati siano in formato big endian,
mentre AROS gira in CPU little endian. Il problema è che le routine
little endian nel core di AROS dovrebbero lavorare con dati big endian
in emulazione. La conversione automatica sembra essere impossibile
(giusto un esempio: c'è un campo in una struttura in AmigaOS che a volte
contiene ULONG e a volte due WORD) perchè non possiamo dire come sono
codificati una coppia di byte in RAM.
Ci potrebbe essere, se qualcuno crea un porting nativo di AROS e fa
tutto il resto del lavoro necessario per creare una ROM Kickstart.
Attualmente, nessuno si è dedicato a questo lavoro.
Le immagini dei floppy possono essere montate come hardfile e usate
come harddisk da 1.4 Mb all'interno di UAE. Dopo aver messo i file che
vuoi nell'immagine dell'hardfile (o qualunque altra cosa tu voglia
fare), puoi scriverle su un floppy.
La geometria dell'hardfile è quella che segue:
Sectors = 32
Surfaces = 1
Reserved = 2
Block Size = 90
Copia l'immagine della directory DiskImages di AROS (SYS:DIskImages, es:
bin/linux-i386/AROS/DiskImages) e rinominala in "Unit0". Dopo aver
avviato AROS, puoi montare l'immagine del disco con:
> mount AFD0:
Nel caso tu abbia letto di Zune su questo sito, è semplicemente una
reimplementazione open source di MUI, che è un potente (oltre che user e
developer-friendly) toolkit GUI shareware e orientato agli oggetti e lo
standard di fatto su AmigaOS. Zune è il toolkit GUI preferito per
sviluppare applicazioni AROS native. Come dice il nome stesso, non
significa nulla, ma suona bene.
In AROS, apri una shell CLI, vai su Envarc: e cancella i file delle
preferenze che vuoi riportare ai valori di default.
Questa divisione della memoria è principalmente un cimelio dal passato
dell'Amiga, dove la memoria grafica era la memoria per le applicazioni
prima che se ne aggiungesse dell'altra, chiamata FAST RAM, dove andavano
a finire le applicazioni, mentre la grafica i suoni e alcune strutture
di sistema rimanevano nella memoria grafica.
In AROS-hosted, non c'è questo tipo di memoria "Altra" (FAST), ma solo
GFX, mentre su AROS nativo, GFX ha un massimo di 16MB, sebbene non
rifletta lo stato della memoria della scheda grafica... Non ha alcun
tipo di relazione con l'ammontare della memoria sulla tua scheda
grafica.
La risposta prolissa
Memoria grafica nel i386-nativo indica i primi 16MB della memoria del
sistema. I primi 16MB sono l'area in cui le schede ISA possono usare il
DMA. Allocando la memoria con MEMF_DMA o MEMF_CHIP andremo a impegnare
quella memoria, tutto il resto va nell'altra (fast) memoria.
Usate il comando: C:Avail HUMAN per informazioni sulla memoria.
Questo comando memorizza la posizione delle icone per tutte (o una)
finestra.
Al momento l'unico modo di cambiare lo screensaver è scriverti il tuo.
La commodity Blanker può essere configurata con Exchange, ma è in grado
solo di visualizzare un "campo di stelle" con un dato numero di stelle.
Lo sfondo di Wanderer si può settare con il tool pref Prefs/Wanderer. Lo
sfondo delle finestre Zune si setta con Prefs/Zune. Puoi anche settare
le preferenze della tua applicazione preferita usando il comando Zune
<applicazione>.
Questo problema può probabilmente essere sistemato creando una directory
WBStartup nella directory di AROS. Se sei root e AROS crasha all'avvio,
prova con "xhost +" prima "sudo && ./aros -m 20". Devi anche specificare
un po' di memoria con l'opzione -m come mostrato. Non dimenticare,
inoltre, l'opzione BackingStore nella sezione Device del tuo file
xorg.conf.
Puoi avere una lista di queste opzioni lanciando il comando ./aros -h
Devi inserire la seguente stringa (così com'è!) nel tuo file
/etc/X11/xorg.conf (o XFree.conf)::
Option "BackingStore"
Eccone alcune:
floppy=<disabled/nomount> - definisce le opzioni di trackdisc.device
disabled - disabilita completamente l'inizializzazione di trackdisk.device
nomount - initialise trackdisk.device but do not create DOS devices
ATA=32bit - Abilita l' I/O a 32 bit nel driver hdd (sicuro)
forcedma - Forza l'attivazione del DMA nel driver hdd (dovrebbe
essere sicuro, ma potrebbe non esserlo)
gfx=<nome hidd> - Usa l'hidd specificato come driver grafico
lib=<nome> - Carica e inizializza la libreria/hidd specificata.
E alcune più vecchie se stai usando una build non recente (dalla r28786):
nofdc - Disabilita completamente il lettore floppy.
noclick - Disabilita il controllo del cambio floppy (e il relativo
click)
Nota che tutto è case-sensitive.
La prima soluzione e la più semplice è inserire dei file in una immagine
ISO e collegarla alla VM. Ci sono un sacco di programmi per
creare/modificare ISO, come UltraISO, WinImage o mkisofs. La seconda,
puoi abilitare la rete in AROS e un server FTP sulla tua macchina ospite.
Quindi puoi usare un client FTP per AROS per trasferire i file (dai
un'occhiata al MarranoFTP). Fermiamoci qui come complessità. La
documentazione utente contiene un capitolo sul nerworking, guarda lì.
- D: HO compilato AROS con gcc4 ma ho visto che ho compilato segfaults opsitati da AROS
- con -m > 20 e se compilo nativo con AROS non parte e fa schermo nero
R: Aggiungi -fno-strict-aliasing a scripts/aros-gcc.in e riprova a compilare.
Lo script dovrebbefare alcune assegnazioni e aggiungere una stringa alla variabile PATH.
- Crea una sottodirectory S e aggiungi un file col nome 'Package-Startup' con i
comandi DOS
- Creat una variable nel file envarc:sys/packages che contenga la path per la cartella S
del tuo pacchetto.
Esempio di layout delle directory:
sys:Extras/myappdir
sys:Extras/myappdir/S
sys:Extras/myappdir/S/Package-Startup
La variabile in envarc:sys/packages può avere il nome 'myapp' (il nome non importa),
il contenuto sarebbe poi 'sys:extras/myappdir'
Lo script Package-Startup sarà poi chiamato dalla sequenza di startup.
Scrivi questo comando nella shell:
Echo "*E[0;0H*E[J* "
Puoi modificare il tuo S:Shell-Startup e inserire la linea da qualche parte, così
avrai un nuovo comando "Cls":
Alias Cls "Echo *"*E[0;0H*E[J*" "
BTW: ecco la mia nuova S:Shell-Startup modificata per far partire la shell in nero e
con un prompt modificato:
Alias Edit SYS:Tools/Editor
Alias Cls "Echo *"*E[0;0H*E[J*" "
Echo "*e[>1m*e[32;41m*e[0;0H*e[J"
Prompt "*n*e[>1m*e[33;41m*e[1m%N/%R - *e[30;41m%S>*e[0m*e[32;41m "
date
Più sulle stampe di sequenze di escape:
Esc[0m
Standard Set
Esc[1m and Esc[22m
Bold
Esc[3m and Esc[23m
Italics
Esc[4m and Esc[24m
Underline
Esc[30m to Esc[39m
Set Front Color
Esc[40m to Esc[49m
Set Background Color
Significati dei valori:
30 grigio char -- 40 grigio cell -- >0 grigio sfondo ---- 0 tutti attributi spenti
31 nero char - 41 nero cell - >1 nero sfondo --- 1 boldface
32 bianco char - 42 bianco cell - >2 bianco sfondo --- 2 faint
33 blu char -- 43 blu cell -- >3 blu sfondo ---- 3 italic
34 grigio char -- 44 grigio cell -- >4 grigio sfondo ---- 4 underscore
35 nero char - 45 nero cell - >5 nero sfondo --- 7 reverse video
36 bianco char - 46 bianco cell - >6 bianco sfondo --- 8 invisible
37 blu char -- 47 blu cell -- >7 blu sfondo
I codici possono essere combinati separandoli con un semicolon. ??
Chiama "export AROS_X11_FULLSCREEN=1" in una shell. Fai partire AROS e cambia la risoluzione
dello schermo nelle preferenze schermo. Riavvia AROS.
Le icone per AROS sono attualmente files PNG rinominate. Ma se vuoi icone per AROS
in due stati (normale/selezionato) usa questo comando:
join img_1.png img_2.png TO img.info
Metti l'ISO dentro AROS (con wget o altri modi)
Copia l'ISO in sys:DiskImages (Drawer deve essere creato se non esiste).
Rinomina l'ISO in Unit0 in quella directory.
Devi aggiungere questo nel tuo Devs:Mountlist
ISO:
FileSystem = cdrom.handler
Device = fdsk.device
Unit = 0
L'ISO è montato:
Puoi copiare qualunque cosa dall'ISO:. In più puoi creare uno script per
aggiornare la nightly build come questo:
copy ISO:boot/aros-pc-i386.gz sys:boot/
copy ISO:C sys:C all quiet
copy ISO:Classes sys:Classes all quiet
copy ISO:Demos sys:Demos all quiet
E così via tutte le directory (tranne le preferenze), Extras:Networking/Stacks, e lo stesso
devs:mountlist. Le preferenze devono essere mantenute se ne hai bisogno. Inoltre puoi settare
AROSTcp per tenerne le configurazioni in una cartella separata.
Se vuoi solo riscrivere tutto, fai solo:
copy ISO:C sys:C all quiet newer
Lancia queszti due commandi da CLI:
assign DOSVOLUME: dismount
assign DOSVOLUME: remove
dove DOSVOLUME è DH0:, DF0:, ecc...
Correntemente i volumi FAT sono automaticamente trovati e montati,
ma si possono anche montare manualmente.
Creat un mountfile (text file) con tre linee magiche:
device = trackdisk.device
filesystem = fat.handler
unit = 0
- Chiamalo in qualche maniera, PC0 per esempio. Definisci questo file lo strumento predefinito
in c:mount nelle proprietà (o metti il mountfile in devs:dosdrivers o sys:storage/dosdrivers)
- Fai doppio click su esso.
- Inserisci un floppy formattato FAT.
- Guarda l'icona apparire del desktop di Wanderer.
Correntemente i volumi FAT sono autorilevati e automontati, ma c'è una amniera
per montarli manualmente.
Per prima cosa hai bisogno di leggere la geometria del drive e scrivere alcuni valori.
Puoi usare HDToolbox o Linux fdisk per questo lavoro. Il valore BlocksPerTrack è preso
dal valore settori/traccia. Nota che non ha assolutamente niente a che fare con la
geometria fisica del disco - FAT la usa solo con moltiplicatore.
Se trovi i cilindri per esempio da HDToolbox o usando fdisk di Linux come questo:
sudo fdisk -u -l /dev/hda,
Quindi hai bisogno di mettere BlocksPerTrack=63.
Assicurati di avere numeri nella vista dei cilindri per Units=Cylinders nell'output. Se
hai l'output da fdisk in settori (Unità=settori), setta BlocksPerTrack=1.
LowCyl e HighCyl sono cilindri della partizione come:
mark@ubuntu:~$ sudo fdisk -l -u /dev/hda
...
/dev/hda1 * 63 20980889 10490413+ c W95 FAT32 (LBA)
Quindi, LowCyl is 63, and HighCyl is 20980889, blockspertrack=1
Crea un mountfile (file di testo) con queste linee:
device = ata.device
filesystem = fat.handler,
Unit = 0
BlocksPerTrack = 1
LowCyl = 63
HighCyl = 20980889
Blocksize=512
- Chiamalo n qualche maniera, FAT0 per esempio
- Definisci lo strumento predefinito c:mount in proprietà
(o metti il mountfile in devs:dosdrivers o sys:storage/dosdrivers)
- Doppio click su di esso
- Guarda l'icona comparire sul Wanderer
Nota: Formula per contare questi blocchi:
block = ((highcyl - lowcyl) x surfaces + head) x blockspertrack + sec