Posts by WTE

    Die Idee mit dem C65 kam von den Chip Entwicklern, nicht der Systems-Abteilung.

    Hätten sie es mal bei der ersten Idee belassen, dann hätte es auch ein verkaufbares Produkt gegeben. [Allerdings ohne großes Potential da die Software oft eine 1541 verlangt(e).]


    Ich kann mich ja täuschen, aber mir ist so, als würde ich mich erinnern, dass um 1987/88 ein C64D mit 3,5"-Floppy als "Gerücht" auch mal in einer 64er angesprochen worden war. Und das war vor dem C64DX (aka C65)!

    Das fällt für mich allerdings in die Kategorie 'selbstgemachtes Problem'.

    Alle unsere Probleme hier sind "selbstgemacht". Keiner zwingt uns die alten Kisten zu programmieren. :bgdev
    Und ansonsten ist Rückwärtskompatibilität ja immer ein schönes Thema und hier das schlagende Argument.

    P.S. zu deinem weiteren Beitrag: ja, mit POKE781,X:SYS65478 kann man die Eingabe auf eine Datei umlenken (und mit SYS65484 wieder zurückstellen) aber da gibt es bessere Anwendungsfälle für, als LOAD mit GET nachzubauen.

    Nach diesen anderen Anwendungsfällen hat hier aber keiner gefragt ;) Es war nur die konkrete Antwort auf eine konkrete Frage.


    PS: Danke für den Link. Schöne Beschreibung. Diese Abhandlung kannte ich noch nicht.

    :zzt:

    BIF Das hört sich doch schon mal interessant an. Vielen Dank. Wofür ist das GETA$ in der zweiten Variante? Und wie lese ich die Daten dann ein? Etwa so:

    Code
    1. 10 OPEN1,8,1,"NAME":FORI=1TO100:GET#1,A:POKEL(I),A:NEXT:CLOSE1

    Und wie verwende ich GET ohne #? Das liest ja aus dem Tastaturpuffer. Muss ich dann also irgendwie die geladenen Zeichen in den Tastaturpuffer umlenken?

    Viele gute Fragen.


    Das geta$ sollte vermutlich auch ein print#1 sein, es gibt keinen Grund die beiden Beispielzeilen von BIF an dieser Stelle anders zu behandeln. Andererseits löscht auch ein get die mit CMD erzeugte Umleitung der Standardausgabeeinheit. Falsch ist es somit wohl nicht.


    Tja, wie verwendet man get statt get#?


    Der Umleitung der Ausgabeeinheit mit CMD fehlt im BASIC leider das Pendant zur Umleitung der Eingabeeinheit. Im Kernal ist das jedoch vorhanden.

    Ich bin jetzt kein C64-Experte, aber nach ein bisschen Recherche müsste die Umleitung mit folgender Kombi erreichbar sein (sozusagen ein CMDIN#1):

    POKE781,Filenummer

    SYS65478

    Der Poke überträgt die Dateinummer in die Speicherstelle, mit der beim SYS-Aufruf das X-Register vorbelegt wird.

    Der SYS-Aufruf startet CHKIN und holt sich über das X-Register die Daten zur Filenummer und damit das Gerät und die Sekundäradresse. Danach wird der Eingabekanal auf Lesen von Gerät statt aus dem Tastaturpuffer umgestellt.


    10 N$=CHR$(0):OPEN1,8,1,"NAME":POKE781,1:SYS65478:FORI=1TO100:GETA$:A$=A$+N$:POKE(X+I),ASC(A$):NEXT: :CLOSE1


    Zwischen NEXT und CLOSE muss man den Eingabekanal noch zurücksetzen (entsprechend dem PRINT#). Mal sehen, ob ich das noch irgendwo finde.


    X ist hier einfach der Startwert des Berichs wo das hingepoket werden soll, die Klammern sind nur zur besseren Lesbarkeit.


    Dieses Konstrukt sollte deutlich schneller sein als get#. Bei get# werden jedesmal diverse Metadaten ausgetauscht, ein riesiger Overhead. Beim Umstellen des Kanals erfolgt das nur einmal. Der Geschwindigkeitseffekt sollte enorm sein!


    Edit: ein SYS65484 zwischen NEXT und CLOSE sollte es tun. Das setzt alle I/O Umleitungen zurück.

    Wo ist eigentlich dieses OFF TOPIC Smiley abgebieben? Falles es jemand findet, bitte hier einkleben!

    Nur - die IF ... LOAD Methode ist noch nicht mal das: gut.

    Sie kann aber nützlich sein, wenn man ein Programm schreibt, dass auf mehreren Commodore-Rechner-Typen funktionieren und wo deshalb sparsam mit SYS, PEEK und POKE umgegangen werden soll. Wobei ich zugeben muss, dass ich wohl einfach bisher nur zu faul war, mir die Daten für diese kleine SYS und POKE-Orgie für fünf verschiedene Rechnersysteme herauszusuchen. ;)

    Wenn dem SYS-Befehl ein Argument in Klammern folg, wird dort meist mitten in eine Routine hineingesprungen, die eigenständig Parameter aus dem Basicprogramm entnimmt. Das/die nächste(n) Zeichen nach dem SYS wird/weden also direkt gelesen und ausgewertet. Dass der Wert in Klammern steht, hat nur den Grund um ihn vom SYS anzutrennen, damit der Interpreter weiß, dass es SYS49152 und nicht SYS491525 ist.

    Wenn man die Parameter mit einem Kommata abtrennt, handelt es sich meist um eine selbst programmierte Routine. Hier wird dann im ML-Programm der Reihe nach erst nach einem Komma, und dann nach weiteren Parametern im Basictext gesucht. Das ist aber individuell und abhängig vom Programmierer (es gibt sowohl für Trennzeichen finden als auch für Parameterauswertung passende Subroutinen im Kernal). Man kann auch ein eigenes Programm ohne Kommatrennung programmieren, es sieht nur mit Komma schöner aus und passt besser zur allgemeinen Syntax.


    Die Frage wo die ML-Routine die Parameter findet ist damit also klar: direkt im Basictext hinter dem SYS-Aufruf.


    PS: Beim BASIC 7 des C128 gibt es hinter dem SYS vorgegebene Parameter die als A,X,Y,S in dezidierte Speicherzellen übertragen werden und dem ML-Programm in den entsprechenden Registern übergeben werden. Man kann das dann auch mit RREG wieder gezielt auslesen. Manchmal macht es die Sache leichter, manchmal schwerer. Man hätte da besser die alte Syntax behalten und einen neuen Befehl (CALL ?) mit den neuen Möglichkeiten etablieren sollen, aber das ist Schnee von vorgestern.

    Prima. Noch besser wäre es, wenn man es (als Aufzeichnung) auch ohne Anmeldung irgendwo sehen könnte... bin hartnäckiger Verweigerer wenn es darum geht (speziell den asozialen Medien) meine persönlichen Daten auf dem Silbertablett zu präsentieren...

    Dass es SCART Geräte geben soll bei denen Composite oder S-Video nicht mehr belegt ist wäre mir FREMD.

    SCART beinhaltet all diese Signaleingange ... ist somit genormt meine ich.

    Ja, das wäre seltsam. Was es aber gibt sind Geräte, die zwar einen SCART-Eingang haben, aber nur das (S-Video/)Composite-Signal verarbeiten können, da elektronisch kein RGB-Eingang vorhanden ist. Da ist SCART nur eine andere Version der "normalen" Composite-Stecker. Die RGB-Pins sind nicht verbunden. Hat mich einiges an Nerven gekostet, bis ich das begriffen hatte. ;)

    Seit Skern und NLQ sich nicht mehr auf der Hobby & Elektronik terffen können (weil die Computerclubs seit zwei Jahren da keinen Platz mehr erhalten), fehlt wohl der notwendige Anreiz sich da mal wieder tiefer reinzuknien.


    Ansonsten siehe hier: nlq-hd

    Meine Augen sind auch nicht mehr so toll :-)


    Geplant ist, das verschiedene Systeme damit aufgebaut werden. Aber wann es dann auf den 128er trifft kann ich noch nicht sagen. ZX Spectrum und Apple II ist auf jeden Fall auch schon geplant.


    Tja, die Kombi machts. Meine Lötpunkte waren auch schon vor dem "schlecht Gucken" eher Kuhfladen.

    Jetzt mit Zittern und Nebelblick liegen die auch noch an der falschen Stelle. ;)

    Daher nehme ich nur Fertiggeräte, koste es was es wolle. Falls hier also jemand einen Lötservice anbieten möchte...


    C128 ist ziemlich komplex, wäre tatsächlich die "Krönung" eines solchen Projekts.

    Mal wieder ein Apple II-Einschaltbild zu sehen, wäre allerdings auch was schönes (die hatten wir damals im Informatikunterrichet an der Schule).