Posts by LogicDeLuxe

    Es sind im Englischen nun so einige Anspielungen bei den Farben 16 bis 31 dabei, die man so nicht 1:1 übersetzen kann. Zum Beispiel bei 16 die "Guru Meditation" vom Amiga

    Gerade bei "Guru Meditation" sehe ich das Problem nicht. Wollte man das übersetzen, könnte man es einfach mit Bindestrich schreiben. Allerdings sehe ich gerade hier keine Notwendigkeit zum Übersetzen, weil es eben ein Zitat einer Amigafehlermeldung ist, die es nicht übersetzt gibt.

    Um die Farbtabelle umzurechnen, muss man also die Werte um 4 Bits nach links schieben,

    aus GURU MEDITATION (14,0,0) = 0E 00 00 wirdd dann #E00000

    Wenn man es richtig macht, werden beim Hochkonvertieren die zusätzlichen Bits aufgefüllt, indem die oberen Bits wiederholt werden. In diesem Fall wäre das #EE0000.

    die neue CPU sitzt dann aber bestenfalls samt RAM-Ersatz auf einer riesigen internen piggy-back-PCB

    So wie ich das sehe, war die Idee hier eher nur die CPU zu ersetzen, ohne daß weitere Umbauten erforderlich sind.


    Andererseits darf man am C64 den DMA nicht vergessen. Es ist schließlich möglich, das RAM von außen zu beschreiben, wie es mindestens die REU macht. Den Bus permanent überwachen, könnte der FPGA natürlich auch dann, wenn aus VIC-Sicht gerade kein CPU-Zyklus dran ist, aber um Schreibzugriffe zu erkennen, müßte es zusätzlich wohl auch noch das Schreibsignal vom RAM abgreifen.

    Es schaltet doch der Prozessor um, also weiss er auch welche Bank aktiv ist...

    Der Prozessor könnte sich schon merken, welche Bank aktiv ist. Bringt aber nichts, denn er kann nicht wissen, ob und wann in die anderen Bänke umgeschaltet wird, also darf er dem VIC auch nichts vorenthalten.

    Die fehlenden 8 KB sind die jeweils 4 KB CharROM ab $1000 und $9000 aus Sicht des VIC-II? Würde man der Einfachheit halber dann nicht doch die kompletten 64 KB rausschreiben?

    Ich bin kein FPGA-Experte, aber ich denke mal nicht, daß das so viel spart. Eine Entscheidungslogik ist ohnehin vorhanden, um zwischen RAM, ROM und I/O zu unterscheiden, und ein paar Extrabits für die Entscheidung dürften doch höchstens ein paar Logikzellen ausmachen.

    Sicher könnte man da die SCPU als Vorbild nehmen und das konfigurierbar machen, damit angepasste Software Spiegelungen für nichtbenötigte Bereiche deaktivieren kann.

    Außerdem wären "8kb Plug&Play FastRAM" doch bestimmt werbewirksam. ;)

    Stichwort "Illegale Opcodes" - die dürften also nicht unterstützt werden.

    Steht auch auf der Seite, daß die nicht unterstützt werden. Sollte aber doch grundsätzlich möglich sein, das Teil auch 6502-kompatibel zu machen.

    Das Problem ist, egal wie schnell die 6510-CPU kann, den Takt gibt erstmal das VIC vor.

    Für sowas wurde der Cache erfunden. Auf der Seite wird erklärt, daß beim Start der gesamte Adressraum ins interne CPU-RAM kopiert wird. Das würde sich allerdings durchaus am C64 etwas kompliziert gestalten. Man müßte RAM, ROM und I/O separat behandeln und die jeweilige Speicherkonfiguration intern buchhalten.

    ja, allerdings musst Du buchhalten, auf welchen Speicherbereich der VIC zugreift bzw. wenn die Bank verändert wird, ob Du noch Änderungen nur intern hast und die dann rausschreiben!

    Genau da muß man eigentlich nicht buchhalten. Im Prinzip müßte man die gesamten 56kb, auf die der VIC Zugriff hat, immer rausschreiben, weil man die Bank jederzeit umschalten kann. Möchte man das bedingungslose rausschreiben unterbinden, sind spezielle Konfigurationen denkbar, wie sie die SCPU bietet, aber davon kann natürlich nur speziell für diese Hardware angepasste Software profitieren.

    Man muss die Geräusche generieren, anstatt vorgefertigte WAV's zu verwenden.

    Das ist sicher auch ein machbarer Ansatz. Mododrum hat gezeigt, daß umfangreiche Schallsimulation heutzutage machbar sind. Das erzeugt sehr realistische Schlagzeugtöne, ohne auf Samples zurück zu greifen. So eine Floppymechanik müßte sich doch auf die gleiche Weise simulieren lassen.

    Man kann doch das Rom auch so Programmieren, daß irgendeine Spur gelesen wird (wird doch auf jeden Block geschrieben, wo der Block ist), dann braucht man nur noch zur richtigen Spur zu fahren.

    Genau so wird das auch gemacht. Mal abgesehen von der unnötigen Fahrerei in der Resetroutine beim Lichtschranke-ROM wird der Kopf lediglich dann stumpfsinnig an den Anschlag gefahren, wenn Lesefehler auftreten, oder eben Formatiert wird. Die Lichtschranke dient dazu, um genau in diesen beiden Fällen die mechanische Belastung zu reduzieren.

    Wenn man es perfekt machen will, muß man auch berücksichtigen, daß unterschiedliche Schrittgeschwindigkeiten sich auf das Resonanzverhalten auswirken.

    Und nicht zu vergessen, die Geräusche, die entstehen, wenn man es mit der Geschwindigkeit übertreibt, und die Mechanik nicht mehr mit kommt. Da gibt es zudem sicher einen großen Toleranzbereich, wo dieser Punkt erreicht ist.

    Und dann gibt es natürlich auch noch so schrottige Disketten, die besonders unruhig und laut laufen.

    Klingt so, als hätte das potentiell unnötige Kundenreklamationen nach sich gezogen. :nixwiss:

    Ich könnte mir vorstellen, daß man das auch als Universal-ROM umsetzen könnte. Wenn das Lichtschrankensignal zum ersten Mal anspricht, einfach wieder einen Schritt vor machen und prüfen, ob es immer noch anspricht. Ist das der Fall, kann so ein Universal-ROM fortan das Signal ignorieren, weil es jetzt weiß, daß es nicht das anzeigt, was man von einer Lichtschranke erwartet.

    Und für den Fall, daß das Lichtschrankesignal nie anspricht, würde sich die Floppy ganz von selbst so verhalten, wie gehabt.

    Das unnötige Anfahren von Spur 1 beim Reset kann natürlich in jedem Fall draußen bleiben.



    Den Fall, daß das Lichtschrankesignal permanent anspricht, hab ich mal vor langer Zeit in VICE beobachtet. Dort weigerte sich das Lichtschranke-ROM hartnäckig Schritte in Richtung Spur 1 auszuführen. So würde sich das wohl auch bei einer defekten Lichtschranke verhalten, vorausgesetzt, sie ist überhaupt richtig gejumpert. Für so ein Universal-ROM wäre auch dieser Fall kein Problem.

    Und wenn man ein Jiffy drin hat kann man sich das alles sparen, dem Jiffy ist die Lichtschranke nämlich Wumpe.

    Einerseits vereinfacht es die Sache natürlich. Andererseits aber auch schade, daß von JiffyDOS keine Variante angeboten wurde, welche die Lichtschranke auswertet.

    Nein, ist kein Lotto-Spiel. :)

    Ein Lottospiel ist es allerdings, ob Commodore den Jumper richtig gesetzt hat. Aber zum Glück ist das auch kein Hochsicherheitsstudio und Zinken ist erlaubt. :)


    Allerdings wäre es nicht notwendig gewesen, daß Commodore das ROM so verändert hat, daß beim Reset Spur 1 angefahren wird. Die 1571 macht das auch nicht. Zum einen wird aller Wahrscheinlichkeit nach als nächstes Spur 18 angefahren, sodaß der Kopf wieder zurück muß. Schlimmer noch, ist es eine Quelle für Inkompatibilität, weil die Resetroutine etwas länger braucht und die 1541 die blöde Angewohnheit hat, sich aufzuhängen, wenn man weitere Befehle sendet, bevor sie fertig resettet hat.

    Am ehesten wäre es wohl sinnvoll gewesen, beim Reset sowie auch beim Erreichen eines Dateiendes automatisch Spur 18 anzufahren.

    Da scheint aber 2021 nochmal dran gearbeitet worden zu sein? Darauf deutet der Link zu archive.org hin.

    Die Glitches, die in der selbstlaufenden Demo nicht da waren, wären wohl das erste, was man nachbessern würde. Allein deshalb bin ich schon davon ausgegangen, daß da nicht mehr dran gearbeitet wurde.


    So unpassend finde ich die Bezeichnung gar nicht, da das Level auch entsprechend komplex ist. Es gibt Treppen, unterschiedlich hohe Ebenen, Fenster usw.

    Dennoch ist es sicher sinnvoller, es nach den technischen Eigenschaften zu benennen, was in solchen Demos auch nicht unüblich ist.

    Waere es simpler als das, waere es ein "Wolfenstein"-Part ;)

    So wie MOOD: https://csdb.dk/release/?id=40255

    Ist bestimmt nur Zufall, daß es sich rückwärts nicht "Wolfenstein" liest.

    Aber ist diese C128-Engine denn eine "richtige" 3D-Engine? Ich hab keine Ahnung was die kann, aber mir kam das jetzt so vor als waere das auch eher eine Art Raycaster.

    Ohne die Engine analysiert zu haben, sieht es mir schon nach etwas aus, was man in der Doom-Engine so bauen könnte. Eine Ähnlichkeit zur Doom-Engine läßt sich durchaus erahnen. Charakteristisch sind jedenfalls auch die stets perfekt vertikal laufenden Kanten ohne daß die Perspektive mal nach oben oder unten rotiert wird.

    Wobei "DOOM"-Part schon sehr übertrieben ist. Trotzdem ein beeindruckender Part!

    Seit Doom heißt doch alles Doom-Clone, was in Echtzeit eine Ego-Perspektive rendert. Als Doom noch neu war, war das sogar am PC ein geläufiger Begriff, bis sich der Ego-Shooter als Gattung durchsetzen konnte.

    Offenbar schafften es überwiegend Spiele in die Auswahl, über die sich leicht billige Witze reißen lassen; schäbbiger C64; von Schnelladern nie etwas gehört; auch nicht davon, dass gerade die Lizenz-Spiele meist Mist sind; der steht doch auf der Gehaltsliste von Atari.

    Da waren einige Spiele dabei, die ich nichtmal kannte. Die kaputten Titel dürften zu einem großen Teil entweder schlechte Cracks oder inkompatible Fernsehnorm sein. Ich wette, daß man auf jedem System so einen Haufen Murks zusammen stellen kann, wenn man vor hätte, so ein Video zu machen.


    Aber ich schätze, der findet einfach gefallen an schlechten Videospielen:

    Ist zwar kein C64-Spiel, aber in dem Video sieht man auch, daß er den C64 durchaus schon länger am Start hat, also dem nicht unbedingt abgeneigt ist.

    Gab es da nicht irgendwas mit einer Gabellichtschranke für Spur 0, oder verwechsele ich da jetzt was?

    Gab es häufig bei der 1541C und immer bei der 1571.


    Falls man eine 1541C hat, die bei jedem Einschalten und Reset anfängt zu rattern, sollte man mal nachsehen, ob eine Lichtschranke vorhanden ist, und diese ggf. per Jumper aktivieren. Hat das Laufwerk keine Lichtschranke, ist es sinnvoll, das ROM zu aktualisieren.

    Hat man eine 1541-II, die bei jedem Einschalten und Reset anfängt zu rattern, sollte man ebenfalls das ROM aktualisieren.

    Ein Lehrbuch für Musikeinsteiger ist sicher nicht verkehrt. Blockflöte ist allerdings schon recht spezifisch. Ich würde eher zu Keyboard raten. Das ist allgemeiner, weil es auf zahlreiche Tasteninstrumente anwendbar ist, wozu behelfsweise auch Computertastaturen gehören, und es beherrscht auch alle Halbtöne. Das dürfte in der Sache hilfreicher sein.

    ...also? - wer lässt seinen Rechner mal freiwillig 2 Monate laufen?

    Offenbar noch niemand, der sich auf dieser Seite gemeldet hätte. Wobei das aber auch nicht so ungewöhnlich ist, daß Rechner so lange laufen. Zwar eher selten bei einem C64, aber bei einem Server völlig normal. Oder auch so Sachen wie ein Router, was auch kleine Rechner sind, die typischerweise im Dauereinsatz laufen.

    Dann schaut doch mal auf http://boulder-dash.nl/forum/index.php. Und ich glaub, keiner kennt Boulder Dash so gut wie das Mitglied hier LogicDeluxe.

    Ich hab zwar so einiges dokumentiert, aber beim Ergründen und Dokumentieren der Engine haben dort auch einige andere Mitglieder große Arbeit geleistet. Z.B. die überaus ergiebige Analyse, was die Eigenschaften der suboptimalen Pseudo-Zufallsroutine angeht, ist schon beachtlich, sowie auch die "Dancing Fly Formations". Da derartige Studien durchzuführen, wäre mir gar nicht eingefallen. Einfach mal dort im Forum stöbern. Da steht schon ein enormes Wissen drin. Auch bei den GDash-Quellen befinden sich einige Dokumente, die den Original-Code analysieren.

    Ich habe bereits Boulder Dash 30th Anniversary Deluxe Edition in meiner Steam Sammlung. Was genau bekommt man mit dem neuen Boulder Dash deluxe, was da noch nicht dabei war? Eine Übersicht wäre hilfreich.


    Laut unseren Marken/Patentanwälten müssen wir gegen Clones (von denen wir Kenntnis haben) rechtlich vorgehen, ansonsten könnten wir Rechte verlieren.

    Deswegen solltet ihr das ja klären, wie man am besten eine generelle Lizenz für nicht kommerzielle Fanspiele gestaltet. Dann ist das doch rechtlich geklärt, ohne das solche Spiele gefährdet werden, und man kann euch nicht vorhalten, die Rechte nicht zu verteidigen. Das ist eine sinnvolle Lösung, wird aber viel zu selten gemacht. Wenn ihr euch positiv in der Fangemeinde bemerkbar macht, sind auch sicher mehr Leute bereit, euch mit dem Kauf aktueller Titel zu unterstützen.

    Kommerzielle Clones sind natürlich eine andere Sache. Das sollte man natürlich immer gesondert rechtlich klären. Mir geht es vor allem um den Bestandschutz der vielen Scene-Releases auf alter Hardware, ohne die es wohl nie so eine große Fangemeinde gegeben hätte.


    Bei den Doom Utilities sah die Lizenz z.B. so aus: https://www.gamers.org/dEngine/license/dul.txt

    Die passt natürlich nicht 1:1 auf Boulder Dash, aber id software ging es damals auch hauptsächlich um die Rechtsicherheit, damit hinterher niemand sagen kann, daß sie ihre Rechte nicht verteidigen würden. Ein paar Jahre später haben die sogar die Engine quelloffen gemacht. Id software war damals vorbildlich, wie man eine Fangemeinde unterstützt.

    Auf Arnos Webseite sind noch andere Levels von "firefox", "Don Pedro", "Marek Roth", "No One", "Ron van Schaik" gelistet. Weiss jemand, wer sich hinter den Namen verbirgt und wie man die kontaktieren kann?

    Marek Roth bin ich.

    Don Pedro war einer der ersten, die gemoddete Versionen am C64 gebastelt hatten. Der hatte sich mal im Forum gemeldet, ist aber schon eine ganze Weile her: http://www.boulder-dash.nl/forum/index.php

    No One hat auch etliche Fanversionen am C64 erstellt gehabt, ist aber recht früh komplett in die Emerald Mine-Scene am Amiga übergewechselt. Kontakte scheint da schon lange niemand mehr zu haben.

    Firefox ist hauptsächlich auf https://www.lemon64.com/ aktiv.