Habe nichts hier, was ich so einfach posten könnte. Zudem war das doch
alles recht kompliziert (vor allem rauszufinden, welche ATA-Specs +
Commands wichtig sind, welche man weglassen kann und welche vom PC-Bios
Hersteller, bzw ATA-Bridge-Hersteller falsch benutzt werden).
War ca. 1 Jahr Arbeit und mündete in meiner Studienarbeit.
Ohne FPGA macht das aber wohl absolut keinen Sinn, da die Adressier-,
Lese-Schreiboperationen schon "in Hardware" dekodiert und ausgeführt
werden müssen, damit das Sinn macht, ansonsten wird das langsamer als
alles andere und man kann sich die Arbeit sparen.
Ich habe ATA, Plattenplatz, und Inhalte simuliert damals, mit
virtuellen Dateien usw. Man konnte sogar davon DOS booten und dann
einfach eine Textdatei öffnen, einen Befehl reinschreiben, speichern
und das FPGA hat dann z.B. eine LED geschaltet - das war aber eher
Spass. Lustig war auch, mit einem Tastendruck den Inhalt einer Datei zu
verändern. Also erst steht in input.txt drin "No Button" und bei
Tastendruck am FPGA liest man anschliessend plötzlich "Button 1
pressed" in der selben Textdatei.
Schön war auch dass aufgrund von ATA und Massstorage, das ganze direkt
ohne Bridge-Adapter unter DOS, mit Firewire oder USB-Bridge unter Mac,
Windows und Linux sofort ging, ohne Treiber zu installieren.
Die Datenübertragung muß man schon richtig über Winapi Dateioperationen
machen, da Windows ansonsten alles cached und gar nicht erst neue Daten
von der virtuellen Festplatte anfordert.
Heute würde ich das aber evtl. anders machen. Ich würde wohl einen
USB2.0-Flashdrive nehmen und dann nur den Flash-Chip simulieren mit
einem FPGA. Ein Flashdrive mit 64MB bekommt man heute ja eigentlich
geschenkt - dann vielleicht Flash runterschneiden/löten oder zumindest
so einen Chip nehmen und eine kleine Platine selber machen.
Also ein Interface bauen, dass so einen Flashchip simuliert.
Dann von "hinten" Daten reinschieben in den virtuellen Flash.
Microcontroller kann aber sowas sicherlich nicht, da die Timing dann
noch kürzer sind, als bei z.B. PIO ATA.
Das würde aber vermutlich schneller sein, da man weniger Aufwand damit
verbrät Dateisystem usw. zu simulieren.
Wenn es ganz ganz einfach (und nicht extrem schnell) sein soll, dann
würde ich vielleicht auch einen einfachen CPLD nehmen, der nur als
Schnittstelle zwischen einem DSP/Controller und einer ATA-USB-Bridge
fungiert. Also Adressdekodieren und Abbilden alleinig der 14
ATA-Register. Dann würde zumindest dieses Timing-kritische Zeugs "in
Hardware ablaufen". Filesystem muß man nicht simulieren, man kann ja
auch von WIndows problemlos z.B. die Daten immer von einem ganz
bestimmten Festplattensektor lesen und beim Senden in einem anderen
Sektor schreiben - auch auf einer "unformatierten virtuellen
Festplatte". Die wichtigsten Befehle "identify drive, read sectors,
..." muß man aber natürlich in jedem Fall 100% OK implementieren, da
ansonsten gar keine Festplatte unter Windows erkannt wird.
Ob das evtl. sogar 100% (langsam) auf einem AVR passieren könnte? Ich
bin mir gar nicht so sicher damit derzeit... Mmm mal nachsehen... Also
nach dem setzen der Adressleitungen, gibts ne kurze Pause und dann
"muß der PC (die Bridge) mindestens 80ns Read oder Write anlegen" -
das ist zu kurz für einen AVR, um die Adresse zu dekodieren und die
Daten einzulesen oder auszugeben - also doch keine Chance ohne
CPLD/FPGA.
jörn
