Beiträge von Mac Bacon

    Ich halte den besagten Mythos zwar auch für Quatsch, aber es gibt tatsächlich eine halbwegs logische Begründung dafür: Sobald man eine Diskette umdreht, dreht sich die Scheibe aus Sicht ihrer Hülle in die andere Richtung. Der Staub, der vorher durch die Drehung in das Vlies auf der Innenseite der Hülle befördert wurde, wird dann also wieder in Richtung Schreib/Lesekopf transportiert.

    Es könnte also wirklich einen Effekt geben, aber ich glaube nicht, dass er praktisch messbar ist.

    von denen ihr wisst, dass sie auf einem C128 DCR (im 64er Modus natürlich) laufen

    Da wäre noch wichtig zu erwähnen, dass man für solche Tests den Rechner tunlichst mit gedrückter Commodore-Taste starten sollte. Wenn man sich z.B. im 128er-Modus per F3 das Verzeichnis der Disk anzeigen lässt und dann mit GO64 in den 64er-Modus wechselt, bleibt das Laufwerk im 1571-Modus und dann funktionieren diverse C64-Speeder/-Loader nicht, obwohl sie es nach einem Start mit gedrückter Commodore-Taste problemlos täten.

    Was stimmt nicht mit diesem Laufwerk?

    Welcher Chip könnte defekt sein?

    Startet das Spiel nach dem Laden automatisch oder musst Du "RUN" eingeben? Falls ersteres, ist das Laufwerk möglicherweise komplett in Ordnung und der Autostart-Loader funktioniert nur nicht mit Laufwerk 9.

    Für einen ersten einfachen Test des Laufwerks einfach im 128er-Modus eine Disk formatieren. Wenn das klappt, ist das bereits ein gutes Zeichen.

    (im 128er-Modus, damit doppelseitig formatiert wird)

    Funktioniert die Maus im Joystickmodus? In allen vier Richtungen?

    Die "2" erscheint, wenn an PortBitte melde dich an, um diesen Link zu sehen. Pin 4 auf Ground gezogen wird, bei einem Joystick entspricht das der Richtung "rechts".

    Sollte die 1351 derart defekt sein, dass sie grundsätzlich Pin 4 auf Ground zieht, kannst Du Dir einen Zwischenstecker basteln, bei dem Pin 4 unterbrochen ist. Dann funktioniert im Joystickmodus zwar nicht mehr die Richtung "rechts", aber dem Proportionalmodus ist das egal, der braucht den Pin nicht.

    per CTRL-F zwischen "none", "BASIC" und "Default" umgestellt werden kann. Nur was wird da umgestellt ?

    evtl. der "optimization mode" der SuperCPU? Es gibt da doch verschiedene Möglichkeiten, welche RAM-Bereiche mit dem echten C64-RAM synchronisiert werden und welche nicht:

    Wird zuviel synchronisiert, bremst das die SuperCPU aus. Wird zuwenig synchronisiert, zeigt der VIC falsche Daten an.

    Eine Version für den Plus/4 gibt es jetzt Bitte melde dich an, um diesen Link zu sehen..

    Gibt's eigentlich auch eine Version für den VC-20?

    :winke: :zaunpfahl::biggrin:

    Nein. Ich hatte mal drüber nachgedacht, aber der Speicher besteht dort meines Wissens aus diversen SRAMs mit 4 Bit Breite. Die simple Anzeige "Fehler in Datenbits 2 und 7" bringt dort also nichts, da würde man eher sowas wie "Fehler in Low-Nibble von Block 3" haben wollen.

    Und hinzu kommt natürlich noch, dass es etliche verschiedene Möglichkeiten des Speicherausbaus gibt.

    Falls das Problem erneut auftritt: Ist der VIC noch in der Verlosung drin?

    Das erste Bild im Thread zeigt zwar eine Menge Fehlzeichen und deutet somit auf RAM-Probleme hin; andererseits zeigt es aber auch die üblichen "38911 basic bytes free": Dass jede Menge RAM-Fehler in dem einen K Bildschirmspeicher vorliegen und gleichzeitig überhaupt keine in den 38 K Basic-Speicher, klingt ein bisschen unwahrscheinlich. Vielleicht hat der VIC Kontaktprobleme und liest daher falsche Screencodes aus dem RAM?

    Das wären 98 Zeilen zu 42 Spalten, pro Level.

    Warum denn "pro Level"? Nur der aktuell gespielte Level muss in diesem Format vorliegen, der Rest kann ja "normal" (oder sogar gepackt) im Speicher liegen.

    ..und der eigentliche Grund, warum ich diese Antwort schreibe: Mir ist noch eingefallen, dass eine Breite von 41 Zeichen ausreicht, denn die rechte Begrenzungsmauer kann ja gleichzeitig die linke Mauer für die nächste Zeile sein. :D

    Ja, um die Level eine Barriere für die Erkennung zu bauen ist eine Lösung. Verbreitert den Level um 2 Bytes pro Zeile und oben und unten die Bytes natürlich auch, 276 Byte mehr pro Level. Die geplanten 40 Level der Spielumsetzung sind vorhanden von der Amigaversion. ohne Umrandung. Ich möchte nicht alles umstricken.

    Eine weitere Alternative: Den Bildschirm nur für die Anzeige nutzen und für die Spiel-Logik einen separaten Bereich mit 27 Zeilen zu 42 Spalten im Speicher halten.

    1. Kein "void" in "int main(void) {}": Na gut, habe "void" jeweils eingefügt. gcc meckert aber auch nicht, wenn es fehlt.

    Du willst gcc immer mindestens mit "-Wall -Wstrict-prototypes" aufrufen.

    EDIT:

    Zitat

    Dieser Beitrag wurde von Bitte melde dich an, um diesen Link zu sehen. aus folgendem Grund gelöscht: Ist zwar witzig gemeint, bringt aber nichts Sinnvolles in diese Diskussion.

    Wenn "bringt nichts Sinnvolles in die Diskussion" ein Löschgrund ist, würde ich es sehr begrüßen, wenn diese Regel auf alle Forumsbeiträge angewendet wird.

    Ja genau, das ist die #metadata-Zeile. Hab schon Csaba, dem Entwickler gesprochen und er möchte das nicht hinzufügen (ich glaube, das ist das erste Mal, das er ein Feature-Request ablehnt), da er der Meinung ist, dass Editoren die Sprache unterstützen sollen, nicht umgekehrt. Kann ich nachvollziehen. Vielleicht kannst du da ja was machen.

    Der übliche Weg für sowas ist, dass die Kennung (hier vermutlich "#metadata") nicht am Anfang der Zeile stehen muss, sondern irgendwo in den ersten paar Zeilen. So kann man diesen String immer mit den Zeichen auskommentieren, die die verwendete Programmiersprache haben will.