Posts by Mac Bacon

    Das sieht nicht so aus, als ob sich irgend etwas geändert hätte. Entweder hast Du Dich vertippt oder der Rechner führt die Zeile gar nicht oder nicht korrekt aus.

    Lösch bitte mal per SHIFT/HOME den Bildschirm und tipp dann alle Buchstaben von A bis Z.

    Das Grafikzeichen statt des "F" wäre ein Fehler in zwei Bits: Code 86 statt 6, also 64 und 16, d.h. Bits 4 und 6. Aber wenn beim Speichertest nichts auffällt, ist das schon sehr seltsam.

    Ist vielleicht einfach die Spiel-Datei karpott?

    Die "Faber"-Lottogesellschaft wirbt immer mit speziellen computeroptimierten Gewinnchancenberechnungen.

    An den Berechnungen ist auch durchaus was dran, denn dabei geht es nicht darum, welche Zahlen letztendlich gezogen werden, sondern darum, welche Zahlen von möglichst wenigen Spielern getippt werden (so dass eventuelle Gewinne höher ausfallen, da man sie mit weniger Mitspielern teilen muss).

    Das ändert natürlich nichts daran, dass es unter dem Strich für die Spieler ein Verlustgeschäft ist - außer für Herrn Faber. :D

    Ich hatte schon überlegt, den Source auf codebase64 oder sonstwo hochzuladen, aber dazu muss ich ihn erst noch aus meinem Programm herausoperieren und von C128 auf C64 umstricken.

    Ich hab jetzt dem ACME-Repository ein weiteres kleines Beispielprogramm hinzugefügt, welches nur Text-Ein- und Ausgabe demonstriert. Der Source der minimalen Eingabefunktion kann jetzt hier besichtigt werden, die Routine braucht knapp 80 Byte.

    Die längeren Versionen kommen dann auch bald (tm).


    Eigentlich wollte ich das Ding in das Library-Verzeichnis werfen, so dass man es direkt in eigene Programme einbinden kann. Das Problem dabei ist: Wenn man jedes Feature konfigurierbar macht, wird das ein komplett unlesbarer Sourcecode voller If/else-Blöcke. Und wenn man alle optionalen Features abschaltet, wird der übrige Code nicht halb so optimiert sein, als wenn man das Ding manuell schreibt.

    Deshalb jetzt die Ziffer '0' im Dateinamen: Da kann ich später noch weitere Versionen hinzufügen, und dann entscheidet man sich für die Ausbaustufe, die man haben will.


    Zusätzliche Features sind z.B.:

    -Beim Einsprung die Maximalgröße des Strings anzugeben (ist in der Minimalversion fix).

    -Zusätzlich zu RETURN auch STOP zu akzeptieren (was der aufrufende Code als "Abbrechen!" interpretieren sollte), sowie ESC beim C128.

    -LEFT/RIGHT/INSERT zu akzeptieren

    -sowie HOME und CLEAR

    EDIT: - abgelehnte Tastendrücke sollten dem SID ein "mööp" entlocken


    Bei einigen Anwendungsfällen wäre es sicher auch nützlich, beim Einsprung bereits einen String vorgeben zu können (z.B. den von der vorigen Eingabe). Der alte Basic-Trick, den String einfach vorher auf den Bildschirm zu drucken, funktioniert hier natürlich nicht, da ja - im Gegensatz zu INPUT - nicht vom Bildschirm gelesen wird.

    Als nächstes drängt sich dann der Gedanke auf, dass man ja auch gleich einge ganze Page investieren und eine History-Funktion einbauen könnte...


    ...und spätestens dann macht man sich Gedanken über komplexe Eingabemasken, wo man per UP/DOWN zwischen verschiedenen Feldern wechseln kann, und die ganze Datensatz-Struktur beim Einsatz über einen Zeiger übergeben wird, und dann wird einem klar, dass solche Monsterprogramme auf dem C64 nicht mehr wirklich eingesetzt werden. :D

    Files

    • c64input.prg

      (228 Byte, downloaded 2 times, last: )

    Hier unter Debian:

    Danke. "Das Argument ist ungültig" ist vermutlich die deutsche Übersetzung von "invalid argument" (EINVAL). Allerdings kann ein normaler "unlink"-Systemcall diesen Fehler eigentlich (tm) gar nicht zurückgeben. Lass Debian bitte mal einen Dateisystemcheck durchführen (dafür wirst Du die Platte erst unmounten müssen).


    Wenn der Dateisystemcheck nichts zu meckern hat, mach bitte mal das, was Gamepower oben vorgeschlagen hat: Öffne eine Konsole und navigier mit "cd" in das entsprechende Verzeichnis (die Platte wird wohl in /mnt oder /media eingehängt worden sein).

    "ls" listet die Dateien im aktuellen Verzeichnis auf, "ls -la" erzeugt eine detailliertere Ausgabe. "rm DATEINAME" ist das normale Löschkommando, da kommt dann vielleicht eine aussagekräftigere Fehlermeldung.

    und wie hast du das gemacht ?

    Wie gesagt, ich hab das vor X Jahren mal über FFE4 gemacht, mit einer Tabelle verglichen (nur zugelassene Zeichen), den ASCII Code der Taste in Bildschirmcode umgewandelt und entsprechend in die 16 Speicherstellen (Filename) geschrieben.

    Allerdings ohne Curser.

    Ich habe eine winzige Funktion, die mit sichtbarem Cursor auf eine Taste wartet: Also Cursor einschalten, warten bis Tastaturpuffer nicht mehr leer, Cursor wieder ausschalten, ein Zeichen per GETIN lesen und zurückgeben.


    Die Eingabefeld-Routine ruft diese Minimalfunktion für jeden Tastendruck auf. Die Umwandlung in Bildschirmcode braucht man nicht selbst machen, man kann das Zeichen (nach entsprechender Prüfung) ja einfach per CHROUT ausgeben, das positioniert dann auch gleich den Cursor. Falls man auch Gänsefüßchen erlaubt, sollte man natürlich nach jedem Zeichen sicherheitshalber das Quote-Flag in der Zeropage löschen, damit es einem nicht den Tag versaut.

    Festplatte ausgebaut und über "DiskIinternals Linux-Reader" den Zugriff auf ext3 Partitionen ermöglicht. Hier konnte ich die Dateien auch nicht löschen.

    Boote einfach mal ein beliebiges Linux und greif direkt auf die Platte zu (also nicht über SMB), dann sollte entweder das Löschen funktionieren oder eine brauchbare Fehlermeldung zurückkommen.

    Oder doch über JSR$FFE4 und vorher Curser einschalten...

    Rein zufällig hab ich in den letzten Wochen an genau so etwas herumgedoktert: ich hab jetzt eine "einfache" und ein "volle" Eingaberoutine; erstere erlaubt nur DEL, letztere auch LEFT/RIGHT und INST.

    Ich hatte schon überlegt, den Source auf codebase64 oder sonstwo hochzuladen, aber dazu muss ich ihn erst noch aus meinem Programm herausoperieren und von C128 auf C64 umstricken.


    EDIT: Es werden übrigens keine INST/DEL-Codes zum Bildschirmtreiber geschickt, d.h. vordefinierte Bildschirmmasken bleiben erhalten.

    Ist ja auch egal - ich bin dir sehr dankbar, dass du mir auf die Sprünge geholfen hast ^^

    Ich werde in meinem Programm die Curser / Bildschirm Steuerungstasten bei der Eingabe abfangen.

    Mit FFCF geht das aber nicht. Der erste Aufruf von FFCF aktiviert den Cursor und lässt den Benutzer etwas eingeben (quasi wie INPUT). Nach CR wird das erste Zeichen vom Bildschirm gelesen und zurückgegeben. Jeder weitere Aufruf von FFCF gibt dann ein weiteres Zeichen zurück. Bildschirmsteuerzeichen kann man also nicht abfangen, weil die gar nicht zurückgegeben werden.

    Er meint - so wie ich oben - den Text "FREE" in der Einschaltmeldung.

    Nein, ich meinte tatsächlich die fehlenden 8K. :D

    Ich hab wohl übersehen, dass das nur bei eingestecktem Modul auftritt - damit verschiebt sich die Fehlersuche natürlich von "warum fehlen die 8K?" zu "warum startet das Modul nicht?"


    Dass das E mal so und mal so aussieht, schiebe ich vorerst mal auf die Kombination von Kamera, Monitor, Nachleuchtdauer, etc. pp. - wenn da wirklich A2 matschig ist, ist es ja bei jeder CharROM-Abfrage Glücksache, ob das Bitmuster nun aus der unteren oder der oberen Hälfte des Zeichen geholt wird. Zusammen mit den 50 Hz Bildfrequenz ergeben sich da sicher lustige Mischeffekte.

    Ich habe zwei Videos davon gemacht. Da sieht man besser was los ist. Im 128 Modus ist nicht ganz so viel Chaos

    Danke.

    Das Char-ROM scheint immer nur dann Fehler zu produzieren, wenn reverse Zeichen gefragt sind, d.h. wenn A10 high ist. Der Sockel auf dem Board ist 24-polig und für ein 8-KByte-ROM vorgesehen, dabei gilt:

    Pin 21 ist A12

    Pin 20 ist /CS.

    Pin 19 ist A10.

    Pin 18 ist A11.


    Anhand der Symptome gehe ich mal davon aus, dass Pin 20 keinen richtigen Kontakt hat und deswegen vom Nachbarpin 19 beeinflusst wird: Immer wenn A10 high ist, geht ChipSelect nicht richtig Low und dann ist es Glücksache, ob der Chip brauchbare Daten ausspuckt.

    Natürlich kann der andere Nachparpin auch noch Einfluss haben: An A12 hängt über einen Jumper entweder die 128/64-Leitung (bei US-Maschinen) oder CAPSLOCK (bei internationalen Maschinen). Da die Symptome in den beiden Modi unterschiedlich stark sind, vermute ich fast, dass bei Deiner Maschine der Jumper falsch gesetzt ist (wodurch die 128/64-Leitung einen Einfluss bekommt): Kannst Du überhaupt mit der CAPSLOCK/ASCIIDIN-Taste den Zeichensatz umstellen? Bei einem europäischen Gerät sollte das eigentlich der Fall sein.


    Wenn das Problem nicht am Sockel liegt, kann es natürlich auch noch an der Huckepackplatine liegen. Diese war nötig, um statt eines 8-KByte-ROMs ein 8-KByte-EPROM verbauen zu können, welches mehr Pins hat. Allerdings meine ich mich zu erinnern, dass da A11 und A12 vertauscht wurden, um die Platine zu vereinfachen, also Vorsicht!