Posts by Mac Bacon

    das ist eine gute idee. würde das auch vom c64 mode aus funktionieren ?

    letztendlich wäre die routine recht kurz.

    Im C64-Modus kann man nicht auf U36 zugreifen, aber man kann das Problem anders herum lösen: Im 128er-Modus ein U36-Programm starten, welches sich ins RAM kopiert, dann den C64-Modus anspringt und anschließend dort weiterläuft.


    Der Bereich von $0AA0 - $0AFF wird im C128 Mode nicht genutzt. Ebenso der Bereich von $FF40 - $FFFF

    Teste sowas doch mal, bevor Du es ins Forum schreibst (kleiner Tip: es ist mal wieder falsch).

    Die Zahlen bei "incbin" passen nicht zueinander. Falls die "2" die Ladeadresse überspringt (ich kenne die Syntax des Assemblers nicht), müsste in den anderen Zeilen auch 8002, 9002 und 10002 stehen.


    ...und das "jmp main" am Ende wird später zu Verwirrung führen.

    Aber ich kriege es nicht hin, dass die Überschrift stehen bleibt, wenn sich die Scrollschrift unten bewegt. Dabei dachte ich,ich hätte mit den Rasterinterupts quasi 4 Bildschirme auf einem. Was mache ich falsch ??

    Im vierten Handler wird das Scrollregister verändert, um die Laufschrift laufen zu lassen. Aber unter der Laufschrift wird es nicht auf den Defaultwert zurückgesetzt, also wird im nächsten Frame der ganze Screen mit der neuen X-Position dargestellt.

    Du könntest gleich im ersten Handler das Scrollregister mit dem Defaultwert beschreiben, das würde das Problem lösen.


    ...und noch eine andere Sache: Die CMP-Vergleiche mit der gewünschten Rasterzeile könnten fehlschlagen, schließlich hat man - je nachdem, ob badline oder nicht - nur 23 oder 63 Zyklen Zeit zwischen dem Auslösen des Interrupts und dem Vergleich der Werte. Statt "gleich" wäre also "größer oder gleich" sinnvoll.

    Mac Bacon wie weit ist dein textadventureerstellungsprogramm wenn es um ascii grafiken geht?

    Dafür wären alte Versionen besser als neue, denn inzwischen ist da ein eigener Zeichensatz drin: Damit kann man dann auch die Zeichen "áàãâÄäçÇéèëêíìïîñóòõôÖöùøûúÜüÿß" benutzen, aber Grafikzeichen gibt es nicht mehr.

    Sämtliche sleep()-Funktionen garantieren immer nur, dass mindestens die angegebene Zeit gewartet wird, mit sowas lässt sich Drift also gar nicht verhindern.

    Nimm stattdessen sowas wie next_alarm_time = previous_alarm_time + cycle_time, dann gleichen sich die Fehler mit der Zeit aus. Problematisch wird es allerdings, wenn die Maschine wirklich zu langsam ist, das muss man extra abfangen: Wenn beim Setzen der nächsten Alarmzeit diese bereits in der Vergangenheit liegt, kann man eigentlich nur noch per Debug-Ausgaben dem Benutzer Bescheid sagen und einen Alarm ausfallen lassen...

    Spur 18, Sektor 0


    Vorsicht! Sektor 0 enthält die BAM. Das Directory geht in 18/1 los. Zweiter Block ist 18/4 usw...

    Aber nur wenn ein Speeder (z.B. Jiffy) Eingebaut ist. Sonst ist es bei der 1541 18/1 - 18/11 - 18/21 - 18/10 usw. also Interlave 10, die 1571 hat ein Interlave von 6.

    Die Werte 10 und 6 gelten für Dateien, nicht für das Inhaltsverzeichnis. Dort ist der Wert nun mal 3.

    Vielleicht macht auch die Tatsache Probleme. das, das ich bislang im Vorfeld kein Inquiry sende - es heißt zumindest im Floppyhandbuch, das dieses Kommando Voraussetzung dafür sei, damit die Floppy wisse, mit welchem Diskettenformat sie es zu tun habe - vielleicht ist das aber auch nur nötig, wenn man auf GCR und MFM-Disketten zugeifen will . Allerdings, dieser C64 Umbau der sich am Userport bedient, sendet auch kein Inquiry, sondern sendet nur $55,30,$1F für Fastload.

    Der nimmt aber eben auch "Burst-Fastload" und nicht "Burst-Read". "Burst-Read" funktioniert erst nach "Inquire Disk" oder "Query Disk", ja. Dann dürfte das hier das Problem sein.

    Die Zusatzinfos von "Query" sind eigentlich nur bei MFM-Disks interessant, daher nimm lieber "Inquire".

    Ich habe aufgeschnappt, dass einige Programme zum Editieren des Directories später Schnellkopierer aus dem Tritt bringen und man dann unvollständige Kopien erhält.

    Das ergibt keinen Sinn. "Unvollständige Kopien" weil "Schnellkopierer aus dem Tritt" gebracht werden kann eigentlich nur heißen, dass die Informationen in der BAM falsch sind. An der BAM fummelt ein Directory-Editor aber gar nicht herum. Wenn ein Programm tatsächlich so einen dicken Bug enthält, könnte man auf die Disk danach nicht einmal mehr sicher Dateien abspeichern (denn vorhandene Dateien könnten überschrieben werden).

    Oder meinst Du das Füllstands-Byte im letzten Directory-Sektor?

    Wann wird denn eine gelöschte Datei wieder sichtbar?

    Wenn man das entsprechende Byte im Directory ändert, was auf Lesen, Editieren und Schreiben des Directory-Sektors hinausläuft. Einen offiziellen DOS-Befehl dafür gab und gibt es nicht.

    Wovon hängt es ab an welcher Position sie steht?

    Beim Löschen eines Eintrags wird dieser vom DOS als frei markiert, beim Neu-Anlegen eines Eintrags benutzt das DOS den ersten freien Eintrag. Da es keinen offiziellen DOS-Befehl zum Erzeugen von Trennstrichen (bzw. dieser DEL-Dateien) gibt und das alles per direkter Sektormanipulation gemacht wird, ist das aber egal.

    Und wie läuft das in Basic?

    Ob die Sektor-Lese- und Sektor-Schreibe-Kommandos von einem Basic- oder einem Assemblerprogramm kommen, ist dem Laufwerks-DOS egal, das merkt da gar keinen Unterschied.

    Vielleicht suche ich nichtz gut genug, aber so richtig viel konnte ich bislang dazu nicht finden.

    Im Laufwerkshandbuch sollte sowohl der Directory-Aufbau als auch die Kommandos U1 und U2 beschrieben sein. Alles Weitere muss man manuell machen.

    Ein C128 ist leider auch nicht vorhanden.

    Hast Du einen C64? Mit zwei Strippen am Userport kann man ihn entsprechend aufrüsten. Das ist natürlich nur die Hardwareseite - wenn Dich das Verhalten des 128er-ROMs interessiert, bringt das nichts.

    Faktisch reinitialisiere ich erst einmal die Floppy zurück auf den 1571 Mode und zwar direkt über eine Befehlskette. Klappt bis dahin (anstelle dessen erst einmal 8*[4/7 Mikrosekunden lange Impulse] auf SRQ rauzuschicken brachte bislang kein Erfolg.

    Woran siehst Du, welche Methode funktioniert hat und welche nicht?

    bei der 1571 nur die ersten zwei Bytes Ascii, Rest "rohe" Bytes bis auf Return

    Ja, von dem ASCII-Gehampel hat man sich beim Burst-Protokoll glücklicherweise verabschiedet. Wie kommst Du auf Return am Ende? Ich weiß nicht, ob das hier das Problem ist, aber es geht definitiv ohne.

    - Vertauscht sich ,wie im 1541-Mode die Standard-CLK-Leitung, die Rolle der SRQ-Leitung, d.h. wenn die Floppy senden will, taktet sie dann die SRQ-Leitung? Bislang gehe ich davon aus.

    Ja. Das passiert direkt durch die Schieberegister-Hardware der CIAs: Die sendende Seite gibt den Takt vor.

    - muß für den schlussendlichen Fast Transfer Richtung Computer grundsätzlich vor -jedem- ATN die 8 Impulse über SRQ gesendet werden, auch wenn die nachfolgenden Kommandos im "Standardmode" gesendet werden?

    Diese Impulse dienen nur dazu, der anderen Seite mitzuteilen, dass das Gerät Burst-Mode-fähig ist. Wenn Du ein Burst-Kommando schickst, sollte(tm) eine 1571 dieses Kommando auch ausführen, egal ob vorher diese Impulse gesendet/empfangen wurden oder nicht. Im 1571-Modus sollte das Laufwerk natürlich schon sein...

    - muß vor der Datenübertragung Richtung Computer bei ATN HIGH ebenfalls nochmals 8 mal gepulst werden?

    Siehe oben, ich wüsste nicht, welchen Zweck das erfüllen sollte.

    - muß für einen Fast Transfer überhaupt ein separater Datenkanal geöffnet werden

    Nein. Im Gegensatz zum restlichen Strubbelcode des Laufwerks-DOS sind die Burstbefehle relativ klar und einfach (inklusive einer Ausnahme, die die Regel bestätigt, nämlich der Zählung der Ladeadresse beim Burst-Fastload...)

    - als Command im Befehlsstring "U0" wird für den Fast Serial Read eine GCR-Diskette "0" angegeben. Passt das?

    Ich weiß den korrekten Wert nicht auswendig, aber mit dem im deutschen 1571-Handbuch angegebenen Wert habe ich entsprechende Programme hinbekommen. Mein Sourcecode sagt 0x40, da ist aber wohl noch ein Bit gesetzt für "bei Fehlern nicht abbrechen", das ist nützlich bei Übertragung mehrerer Sektoren in einem Rutsch.


    Wenn Du die Übertragung hinbekommst:

    Achtung, mehrere Sektoren hintereinander kommen standardmäßig mit dem Sektorversatz fünf. Man kann den Wert ändern, muss das aber an die Spurlänge anpassen: Auf einer Spur mit 18 Sektoren sorgt der Interleave sechs z.B. dafür, dass die gleichen drei Sektoren mehrmals übertragen werden und nicht die komplette Spur.

    EDIT: Der Interleave-Wert eins behebt das Problem der Reihenfolge, macht das ganze Unterfangen aber merklich langsamer, da pro Umdrehung nur ein Sektor gelesen wird. Aber für erste Tests kann das nützlich sein.

    Der kann per Knopf kurz oder per Schalter lange den Pin 4 vom Expansionport auf Pin 1 kurz schließen

    Was macht man damit eigentlich? Laut Schaltplan zieht der ja IRQ auf GND

    Das ist eine (Spiele-)Bremse. Legt man IRQ auf Ground, springt der Prozessor immer wieder in die Interrupt-Behandlungsroutine und hat so weniger Zeit übrig, um das eigentliche Programm auszuführen. Dafür tickt aber die Software-Uhr schneller, was bei Spielen mit Zeitbegrenzung leider wieder kontraproduktiv ist.

    Es hängt also stark von der laufenden Software ab, ob so eine Pause-Taste sinnvoll einsetzbar ist.

    Da die Quersumme vom verwendeten Zahlensystem abhängt, gibt es da keine einfache mathematische Formel, die sofort den richtigen Wert ausspuckt. Die einzelnen Ziffern aus dem String der Dezimaldarstellung zu lesen, ist da schon relativ elegant - denn jeder Versuch, das manuell mit /10, INT() etc. nachzubauen, dürfte deutlich langsamer und unlesbarer sein.

    Sprites funktionieren.

    D.h. der VIC kann problemslos auf das RAM zugreifen, was ja mit gemultiplextem Adressbus passiert.

    die letzen acht Zeichen haben verschiedene Farben.

    VIC-Zugriffe aufs Char-ROM und Farb-RAM sind aber problematisch, also wird der Fehler beim Demultiplexing der Adressbits liegen.

    Ich setz meine Quatloos auf A3 und/oder A4.

    Anführungszeichen statt Space kann nicht nur von falschen Screencodes kommen (Datenbusleitung D1 verdächtig), sondern auch von falsch angesteuertem Char-ROM (Adressbusleitung A4 verdächtig).

    Jedes 2. Zeichen ist fehlerhaft und alle 8 Zeichen springt das von ungerade auf gerade bzw. zurück

    Das wären wiederum A1 bzw. A3. Seltsam.

    Vielleicht mal Widerstandsmessungen zwischen den Adressleitungen machen?


    Und mach bitte mal einen Screenshot von "for i = 0 to 255:poke 1024+i,i:next", vielleicht fällt dann noch was auf.


    EDIT: Unten rechts im Bild, ist das Cyan statt Hellblau? Falls das aus den letzten 24 Speicherstellen des Farb-RAMs kommt, deutet das auch auf Adressierungsfehler hin.

    Die Windowing-Fähigkeiten der 264er-Reihe und des 128ers sind Kernal- oder vielmehr Editor-Erweiterungen und haben mit den Basic-Versionen eigentlich nichts zu tun. Um sowas zu unterstützen, müsstest Du also große Teile des C64-"Bildschirmtreibers" neu schreiben.

    Aber... was versprichst Du Dir davon? Windowing ist nützlich

    a) im Direktmodus (Verzeichnislistings nebeneinander darstellen, bei Arbeiten mit dem TedMon Hexdumps "fixieren", etc.), was bei einer Basic-Erweiterung eher nicht zutrifft.

    b) um das Eingabefeld von INPUT zu begrenzen (und da sollte eine Basic-Erweiterung eher eine Alternative zu INPUT bieten)

    c) um Teilbereiche des Bildschirms zu löschen (da wäre es nützlicher, wenn eine Basic-Erweiterung generelle Rechteck-Füll- und Kopier-Anweisungen hätte)


    Wenn Du was anderes meinst, gib mal bitte ein konkretes Beispiel.

    Leider exportiert dieser das Bild mit Listschutz. Das ist ärgerlich.

    Das ist kein Listschutz, der Anzeigecode ist einfach nur in Assembler geschrieben. Mit x128 und Tedmon disassembliert:

    Die Screencodes und Farben liegen dann direkt dahinter. Wenn man den Code-Header überspringt, kann man also direkt auf die Daten zugreifen.