17.Aug.2021
|
Turbokartenprojekt: Rücksendung der Buffees zur Überarbeitung
Mitte Juni berichteten die Entwickler, dass eine zweite eine zweite Charge von 60 Buffees des Betastatus geordert wurden. Diese sind nun eingetroffen und konnten auch in Betrieb genommen werden.
Allerdings wurden dabei neue Probleme festgestellt, wie die Entwickler weiter berichten:
"Wir haben es zwar geschafft, sie hochzufahren und zu überprüfen, ob einige der Probleme, die wir mit der Alpha-Version hatten, behoben wurden, aber wir haben auch ein paar neue Probleme eingeführt. Und ein drittes Problem, das uns zwar nicht allzu sehr schmerzt, aber sehr ärgerlich ist:
- 1. Das GreenPAK wurde falsch montiert; in ihrer unendlichen Weisheit hatte Dialog beschlossen, die Pinbelegung zwischen den Paketen umzukehren. Gleiche Anzahl von Pins. Völlig andere Reihenfolge. Eines ist im Uhrzeigersinn. Eines ist gegen den Uhrzeigersinn. Oh mein Gott! Das ist meine Schuld, ich hätte nachsehen sollen, aber ich hatte noch nie ein Teil, bei dem die Pins vertauscht waren, also ist das etwas Neues für mich. Nun gut.
- 2. Es gibt drei Stromschienen am PMIC: AC, USB und BAT. USB und AC können beide sehr hohe Spannungen aufnehmen, haben aber ein Minimum von 4,5 V, was mich beunruhigte, da diese alten 68000er-Maschinen nicht jünger werden und ihre Netzteile auch nicht. Solide 5V sind selten, also entschied ich mich, stattdessen die BAT-Schiene zu verwenden, die bis zu etwa 2,7V gut funktioniert. Nur hat TI diese Schiene nicht "standardmäßig eingeschaltet" und benötigt einen Druckknopf. Wieso das denn? Jedenfalls ist die Lösung einfacher als #1, man muss nur PB_IN mit PGOOD kurzschließen.
- 3. Teile verschwinden und eines davon war der 16MB Flash. Wir mussten uns für einen 8MB Flash entscheiden oder "gar nicht". Also ... das wird interessant werden.
Sie sind also zur Überarbeitung unterwegs und werden hoffentlich Ende nächster Woche zurückgebracht. Ich muss sagen, dass diese Lieferverzögerungen und Teilemängel neben dem Umgang mit COVID und einer neuen vierten Welle sehr stressig sind. Aber ich schweife ab. Wenigstens liegen wir noch unter dem Budget.
Wir haben trotz all dieser Rückschläge hervorragende Fortschritte bei Buffee gemacht und eine neue Methode entwickelt, um die seltsame Welt der 68000-Befehle mit variabler Länge und den erweiterten Adressierungsmodus in den Griff zu bekommen. Dies war das letzte Problem mit PJIT, das ich noch nicht gelöst hatte.
Die derzeitige Methode bestand darin, die komplexe Dekodierlogik in jede Anweisung einzubauen, die sie verwendet - und für einen Adressierungsmodus, der nicht annähernd so häufig verwendet wird wie z. B. direkte Register oder einfache Lade-/Speicheroperationen, verschlang dies einen großen Teil der Codebasis, da die "Inline"-Natur von PJIT bedeutete, dass für jeden Opcode dieselben 20-30 ARM-Anweisungen kopiert wurden. Nicht effizient! Und schnell war es auch nicht, denn der Befehl musste regelmäßig in den 68K-Speicher zurückgreifen, und um das zu tun, musste der 68K-Programmcode berechnet werden, da wir ihn nicht immer nachverfolgen, und ... nun, es war ein Chaos.
Die Antwort starrte mir natürlich die ganze Zeit ins Gesicht. Unser altes Modell zeigt all diese NOPs, die die Operandenlücken zwischen den Opcodes füllen - warum also nicht einfach umschichten und alle Literale und erweiterten Adressierungsmodi behandeln lassen, BEVOR wir den eigentlichen Befehl ausführen. Die meisten 68000-Opcodes bestehen aus einem einzigen Wort, und PJIT muß diese entweder zu einem einzigen Inline-ARM-Befehl kompilieren oder in ein Unterprogramm verzweigen, um komplexere Operationen zu verarbeiten. Es gibt jedoch viele 68000-Opcodes, die wesentlich länger als ein Wort dauern, und PJIT kann diese behandeln, indem es für jedes Wort innerhalb des gesamten Befehls spezielle Operatoren hat." (dr)
[Meldung: 17. Aug. 2021, 08:07] [Kommentare: 7 - 22. Aug. 2021, 15:05]
[Per E-Mail versenden] [Druck-Version] [ASCII-Version]
|
