Alles anzeigenich hatte vor einiger Zeit hier im Thread ja schon einmal angedeutet, dass ich einen eigenen Weg zur Datenübertragung vom PC zum Junior Computer II gehe, indem ich ein XLink-Modul mit dem Junior Computer II verbinde.
... habe ich heute geschnitten und auf Youtube hochgeladen. Ich denke, mittels des Videos lassen sich die Möglichkeiten der XLink-Anbindung an den Junior Computer II wesentlich besser darstellen.
Die Präsentation findet ihr hier: https://youtu.be/zsFNaxA6yTI
Was haltet ihr davon? Kommentare sind willkommen...
Das sieht doch schon richtig gut aus. Insbesondere, wenn das so gedacht ist, daß es als Extra wirklich "plug&play" funktionieren soll und die kleine neue Platine dann direkt auf dem I/O Board aufgesteckt wird (oder eben wahlweise mit AdapterChip wie hier).
Das Video ist für sowas doch auch OK geworden. Mein einziger "Kritikpunkt" wäre, daß man, wenn man eine Videobearbeitung nutzt oder wenigstens was Überlagern kann, evtl. noch ein großer grüner Pfeil auf den Wechsel von F5 auf 4C im Display hinweisen könnte, indem er von z.B. min 4:00 bis 4:10 auf das DATA Display zeigt. (Das ist sowas, was nur jemand sieht, der erwartet und weiß, wo er jetzt eine Veränderung sehen müßte. Viele andere Leute werden da gar keine Veränderung sehen, weil sie rechts im Bild schauen. Das angesprochenes Publikum sollte aber eigentlich wissen, was gemeint ist. Es ist halt nur, wenn Du z.B. willst, daß Zufallsgucker nicht sofort abgeschreckt werden.)
Das Tempo ist sicherlich ein wichtiger Punkt - 10 kByte/Sekunde (min 9:20) ist natürlich erschreckend nach heutigen Maßstäben.
Vielleicht geht da ja noch was. 6 Sekunden für einen Volltransfer ist für reines Laden sicher OK, für andere Sachen aber vielleicht noch optimierbar (s.u.).
Beim "jump" Befehl könnte amn evtl. über die Namensgebung nachdenken. "run" oder "go" z.B.
Bei "peek" und "poke" werden die Adressen direkt hinter dem Befehl angenommen, was schön so ist (wie man es allgemein erwarten würde (müßte ja nicht so sein)). Allerdings ist es dann ein wenig inkonsequent / inkonsistent, daß man bei "load" die Adresse explizit mit "-a" einleiten muß. Vielleicht wäre es hier auch schöner, wenn da die Adresse einfach als zweiter Parameter erwartet wird. Alle anderen Sachen, etwa load Befehle mit fixer Ladeadresse, lassen sich dann daraus einfach ableiten, prinzipiell sogar als Shell Kommando, aber natürlich auch Programmintern, indem der Fixpunkt dann mit dazu gesetzt wird - etwa als "loadfix" = "load 0x4000")
Generell könnte man darüber sinnieren, ob es evtl. Sinn machen könnte, die Adressen generell als Hexadressen zu erwarten. Da müßte man evtl. mal eine Umfrage starten, was wahrscheinlich erst mit echten Usern brauchbare Ergebnisse bringt. "poke 4000 23" macht sich besser als "poke 0x4000 0x23" zu tippen - auch wenn es aus Programmierersicht wahrscheinlich sehr gut und definiert aussieht. Evtl. ist auch besser, daß so wie hier zu lassen, also dezimal als Standard und 0x für Hex, dafür aber noch "heek" und "hoke" für Hex als Extrakommandos einzuführen.
Weiteres interessantes Extrakommando wäre evtl. "poke+" und "peek+", was einen Counter beginnend vom letzten "poke" / "peek" Befehl benutzt und diesen jeweils um einen Wert hochzählt. Analog dazu "poke-" und "peek-".
Was ich als sehr interessant erachten würde, wäre sowas wie ein "Block-poke", z.B. als "poke256". Analog dazu ein "peek256". Die sollten genauso wie die normalen poke/peek funktionieren, aber gleich an einem Stück 256 Byte auf einmal holen/schicken.
Ich weiß nicht, ob jemand dann sowas nutzt, aber es würde sehr einfach die Möglichkeit eröffnen den RAM "seitenweise" ein/auszulesen. Damit ließen sich so Sachen machen, wie Stacks auslagern etc. - das ist dann aber schon der Punkt, wo der Speed auch bißchen höher sein muß.
Na, war viel "Fantasy" dabei. Ich will Dir da nicht reinreden, aber nimms evtl. als Anregung.