klingt gut, aber wie wäre es denn, dafür das EEPROM zu nutzen? Da liegt doch im Moment kaum was drin, und der FB würde da doch reinpassen, zumindest im 1284P.
Hmm, die Idee hat was.
Es gibt 75 Antworten in diesem Thema, welches 11.177 mal aufgerufen wurde. Der letzte Beitrag (
klingt gut, aber wie wäre es denn, dafür das EEPROM zu nutzen? Da liegt doch im Moment kaum was drin, und der FB würde da doch reinpassen, zumindest im 1284P.
Hmm, die Idee hat was.
Die Idee ist nicht neu, wird beim SIO2SD bzw. SDRIVE auch so gemacht.
EDIT: Da bietet es sich natürlich auch an, da der Atari ja automatisch davon booten kann, solange noch kein Diskimage eingelegt ist.
Ein Blick ins Datenblatt sagt das P für 20MHz steht, also willst du P und nicht V.
"P" steht nicht für 20 MHz, sondern für "pico power". 20MHz können alle ATMEGA1284, solange die Versorgungsspannung hoch genug ist, siehe SOA.
Cheers!
Wolfgang
Hmm, die Idee hat was.
Fänd ich super!
Nur eine kleine Idee, die nicht ansatzweise zuende gedacht wurde:
Wäre es möglich/sinnvoll, wenn man außerhalb von Images mit LOAD"*",8,1 immer den FB aus dem EEPROM laden würde? Vielleicht optional einstellbar?!
Bei gemountetem Image würde ich jetzt nicht vom normalen Verhalten abweichen aber im FAT-FS habe ich früher das "*" sowieso nur benutzt, um den Filebrowser zu laden, den ich dafür extra als erstes auf die Karte kopiert habe (Jetzt heißt er "GO" und ist fast genau so schnell geladen
).
Wäre es möglich/sinnvoll, wenn man außerhalb von Images mit LOAD"*",8,1 immer den FB aus dem EEPROM laden würde? Vielleicht optional einstellbar?!
Finde ich nicht besonders sinnvoll, weil es die "lade die letzte Datei nochmal"-Bedeutung von * kaputtmacht. Ausserdem ist "ausserhalb von Images" nicht mehr eindeutig sobald es mehr als eine Partition gibt.
Ist LOAD"2:*",8,1 so viel schlimmer?
Nein, ist es nicht! Zumindest nicht viel! ![]()
War eh nur so eine Idee, die mir spontan durch den Kopf ging, als ich überlegt habe, wie der Zugriff laufen könnte.
Was meinst du mit außerhalb von Images nicht eindeutig, wenn es mehr als eine Partition gibt? Werden weitere Partitionen wie Images behandelt oder wieso? Wie man sieht hab ich noch nie mit mehr als einer Partition beim SD2IEC gearbeitet (das hab ich nur im Handy). Innherhaln von Disk-Images hatte ich nur ausgeschlossen, weil man da wohl so dicht am Original wie möglich bleiben möchte und da würde ich auch bei "*" für die letzte Datei nicht abweichen wollen. Im FAT-FS bin ich nicht so streng. Ja, man kann nicht davon ausgehen, dass das jeder so sieht ... ich glaube, es war keine so dolle Idee von mir.
Wenn es dir nur um die "lade die letzte Datei nochmal"-Funktion geht, könnte man ja ":*" für den FB benutzen ;). Nur Spaß!!!
Was meinst du mit außerhalb von Images nicht eindeutig, wenn es mehr als eine Partition gibt?
Jede Partition (eine Liste der aktuell vorhandenen kann man via LOAD"$=P",8 bekommen) hat erstmal ein eigenständiges FAT-Filesystem und auf jeder davon kann ein Image gemountet sein. Wenn man mehrere Partitionen hat kann es deswegen z.B. vorkommen, dass auf einer davon kein Image aktiv ist, auf einer anderen ein D64 und auf einer dritten ein DNP. Das ist auch einer der Gründe, wieso sd2iec nicht automatisch nach einem zum Imagetyp passenden Floppy-ROM sucht um M-R-Befehle zu beantworten - es kann mehr als einen Kandidaten geben.
Jösses!
Ich sollte Dokumentationen doch besser lesen! Diese Möglichkeiten waren mir gar nicht bewusst! Hammer!
Danke für die Erklärung. Ohne die hätte ich auch in Zukunft die Abschnitte zu "mehrere partitionen" weiterhin überlesen. ![]()
Ist LOAD"2:*",8,1 so viel schlimmer?
Das war auch mein erster Gedanke, einfach so behandeln, als wäre es eine weitere Laufwerkseinheit, daher kommt die Syntax doch ursprünglich. Ich würde aber eine höhere Zahl nehmen, falls es doch mal noch mehr Partitionen gibt, 9 z. B.
Das war auch mein erster Gedanke, einfach so behandeln, als wäre es eine weitere Laufwerkseinheit, daher kommt die Syntax doch ursprünglich. Ich würde aber eine höhere Zahl nehmen, falls es doch mal noch mehr Partitionen gibt, 9 z. B.
2 war nur ein Beispiel. Wie oben schon erläutert: Entweder wirds ans Ende gehangen oder bekommt eine feste Nummer (wahrscheinlich >9), letzteres wäre aber leicht CMD-inkompatibel und braucht aber deutlich mehr Frickelei im sd2iec-Code.
Bei meiner eigenen PC-Anbindung "Slave2CBM" benutze ich das Präfix ",:" um spezielle Tools laden zu können - und zwar deshalb, weil dieses Präfix auf keinem echten Laufwerk funktionieren wird. ![]()
Bei meiner eigenen PC-Anbindung "Slave2CBM" benutze ich das Präfix ",:" um spezielle Tools laden zu können - und zwar deshalb, weil dieses Präfix auf keinem echten Laufwerk funktionieren wird.
Das könnte ich evtl. als Alias vorsehen - das EEPROM-Laufwerk wird auf jeden Fall keine Unterverzeichnisse unterstützen und auf den ersten Blick scheint ",:" als Partitionsnummer an keiner Stelle ein Problem zu verursachen. Gut, dass intern alles immer über die gleichen Parserfunktionen läuft. ![]()
Schön, daß ich zu einer tollen Weiterentwicklung hier anregen konnte ![]()
Würde mich evtl. auch gern ein bischen daran beteiligen, sofern es meine Zeit erlaubt. Muß mich allerdings wieder erst ganz schön einarbeiten, mein letztes AVR-Projekt ist schon paar Jahre her...
Ich habs inzwischen auch geschafft, den Code auf meinem Debian wheezy zu kompilieren, es fehlt nur noch das crcgen-new Tool. Dazu waren ein paar Anpassungen notwendig, kannst ja mal drüberschauen...
Ich habs inzwischen auch geschafft, den Code auf meinem Debian wheezy zu kompilieren, es fehlt nur noch das crcgen-new Tool. Dazu waren ein paar Anpassungen notwendig, kannst ja mal drüberschauen...
Du könntest auch eine aktuelle Version nehmen, die compiliert dann auch mit gcc 4.8. Dein Patch entfernt zwei Lesezugriffe auf SPI-Register, die sind im Code drin damit die SPI-Einheit im AVR in einem definierten Zustand ist, egal was der Bootloader vorher veranstaltet hat.
Ok, muß ich mir dann nochmal näher anschauen, ich hab aber eigentlich nur entfernt, wo der Compiler gemeckert hat, daß es unused wäre. In dem Fall würde er den Code ja sowieso rausoptimieren...
In dem Fall würde er den Code ja sowieso rausoptimieren...
Der Compiler würde zwar die Zuweisung rausoptimieren, aber er darf den Lesezugriff auf das Register nicht entfernen weil das in den Headern der avr-libc als volatile deklariert ist.