Posts by dmantione

HIROM an, MIDROM und LOROM aus ist in der Tat eine sehr nützliche Speicherkonfiguration für Maschinensprachprogramme, und ein C64-Programmierer wird sich in dieser Konfiguration sofort zu Hause fühlen, aber weniger wahrscheinlich an die Grenzen der Maschine stoßen, da der zusätzliche Speicher immer noch relativ leicht zugänglich ist.

Quote from Retrofan

Ich wüsste nichts, mit dem eine C128-Version gegenüber der vom C64 auftrumpfen könnte. Die letzte/aktuelle Version der Grafik ist aus meiner Sicht die Beste (und gleichzeitig Speicherplatz-sparendste).

Allein die Tatsache, dass der Commodore 128 mehr Speicher hat, bedeutet, dass er mehr mit Bitmaps machen kann, eine Bitmap fresst ja doch 9KB Speicher und das säbelt in die 64K, die der C64 zur Verfügung hat. Wenn man Bitmaps modifizieren müsst, damit sie in den Speicher des C64 passen, ist der C128 bereits im Vorteil, weil mehr Bitmaps in den Speicher passen.

Aber es geht weiter: Der Commodore 128 hat auch mehr Möglichkeiten für Bitmap-Animationen. Die zusätzlichen 64 KB Speicher bieten 4 VIC-II-Pages. Wenn man also auf jeder Seite eine Bitmap unterbringen (mehr is möglich), hat man 4 Frames zur Verfügung, und das bietet die Möglichkeit, z. B. Wasser zu animieren, ohne große Mengen an Prozessorleistung zu benötigen.

Schließlich verfügt der Commodore 128 über zwei Seiten Farbspeicher. Dies bietet Möglichkeiten zur doppelten Pufferung oder durch die Verwendung von Rasterinterrupts zur Verbesserung der Auflösung des Farbspeichers von 8x8 auf 4x8, wodurch detaillierte Grafiken möglich werden.

Ich verstehe den Wunsch, es als One-Filer zu veröffentlichen, aber es gibt Grenzen, wie weit man gehen sollte. Wenn die Grafik dadurch negativ beeinflusst wird, kann der Zeitpunkt kommen, an dem der Onfiler aufgegeben werden sollte. Es gibt Methoden, um die Ladezeiten zu verbergen, z.B. durch die Verwendung von irq-loaders, um im Voraus zu laden, oder n eine Cartridge ze verwenden oder eine Commodore 128-Version erstellen.

Nochmals, ich verstehe das Problem sehr gut und es ist sicherlich lobenswert, dass man sich bemüht, es in einen Onefiler zu verwandeln, aber was ich jetzt sehe, ist, dass das Spiel grafisch heruntergefahren und endlos verzögert wird. Und wenn nur 200 Bytes für die Implementierung der verbleibenden Funktionalität frei geworden sind... dann kann man fragen stellen ich, ob das ausreicht,um das Finish zu erreichen.

Quote from andi6510

Ganz besonders interessant finde ich Plus/4 bzw C16. Können die das???? Sind ja immerhin nach dem 128er raus gekommen. Hatten aber die eigene 1551 Floppy, die ja sogar ohne IEC auskommt.

Hat da jemand Infos?

Diese Computer verfügen nicht über ein CIA mit Schieberegister, was den Burst-Modus erst möglich macht. Ohne zusätzliche Hardware wird es nicht funktionieren.

+ Commodore 65 und Mega65

Da der VDC in erster Linie für Textanwendungen gedacht ist und schnelle zugang nicht notwendig ist, kann man erwägen, nur die KERNAL-API zu verwenden und alle Bildschirmausgaben über BSOUT und alle Tastatureingaben über BASIN zu tätigen. Deine Programm wird dann automatisch sowohl auf dem VDC als auch auf dem VIC-II funktionieren.

Was der 128 Intern auf jedem Fall nicht richtig erklärt, ist die Verwendung der FAR-Routinen, dem Programmierer wird erklärt, die JSRFAR/JMPFAR/FETCH/STASH über den Kernal aufzurufen. Das ist alles schön und gut, funktioniert aber nur, wenn der KERNAL sichtbar ist.

Das Schöne daran ist, dass diese Routinen im shared RAM in der Page $0200 zur Verfügung stehen, so dass man von jeder Bank aus auf jede andere Bank zugreifen kannst. Der Aufruf des KERNAL aus RAM, wo er nicht sichtbar ist, ist eine der Hauptanwendungen dieser Routinen! Doch der 128 Intern schweigt in alle Sprachen über die Existenz der $0200-Anrufpunkten...

Ganz genau... die MMU-register sind im C64-Modus unzugänglich und die PLA implementiert die C64-Speicherverwaltung, aber die MMU selbst ist voll aktiv! Er bestimmt immer noch, welche RAM-Bank verwendet wird, das "shared RAM" ist aktiv und er schreibt die Adressen der Zeropage und Stack um wie im C128 Mode.

"C128 Intern" von Data Becker ist lesenswert. Ich kann auch "Mapping the C128" und Commodore's "C128 Programmers Reference Guide" empfehlen.

VDC kann Interlacing... 80x50. Nur das Betriebsystem des C128 kann das nicht.... spezielle Software erforderlich.

Quote from will

Snoopy, stimme dir absolut zu. Ich entwickle Spiele für den C64 und verwende dazu leistungsstarke PC-Tools wie cc65, ca65, exomizer, multipaint, charpad, spritepad, make, etc. Diese Tools würde man auch auf dem C128 so nicht hinkriegen (allein schon meine Assemblermalrdefinitionen würden den Speicher füllen), darum sind Spieleentwicklungstools heutzutage keine Killeranwendung mehr.

Bleiben Games...

Ich stimme dir prinzipiell zu, aber obwohl ich den größten Teil meiner Software-Entwicklung auf dem PC mit VICE mache, schließe ich den C128 normalerweise zum Testen und Debuggen auf der eigentlichen Hardware an. Wenn auch nur wegen der besseren Tastatur oder der Tatsache, dass ein 1571 dank seiner 340KB Doppelseitigkeit etwas weniger Ellbogenarbeit erfordert. Auch kleine Vorteile sind Vorteile.

Quote from Retrofan

Wenn ich über spezielle C128-Programme nachdenken würde, würde ich mich wahrscheinlich vor allem auf das Feature mit den zwei gleichzeitig zu nutzenden Bildschirmen konzentrieren. Das ist etwas, dass der C64 nicht einmal mit Turbo hinbekommt.

Ich denke, der C128 eignet sich auch für Spiele mit vielen Runtimedaten. Wenn man zum Beispiel ein Spiel wie Master of Orion portieren möchtet, wäre der zusätzliche Speicher ein Geschenk des Himmels, um den Zustand jedes Sterns, die Konfiguration der Schiffdesigns und so weiter zu können speichern. Wenn man so etwas auf dem C64 machen würde, müsste man wahrscheinlich das Gameplay vereinfachen und/oder Grafik entfernen, um Platz für die Runtimedaten zu schaffen. Grafik kann on-demand geladen werden, Code kann direkt von Cartridge-ROM ausgefürht werden, aber Runtimedaten mussen immer im RAM gespeichert werden.

(Und dann denke ich, dass ein C128 mit, sagen wir, 512KB Cartridge, nicht so viel schlechter ist in möglichkeiten als ein PC XT, immerhin 128KB RAM + 512KB Cartridge ROM = 640KB insgesamt.)

Quote from awsm

Hatte vermutet, dass ich es missverständlich formuliert hatte... Ghost Town hat auch nur eine Codebase für C16 und C64 und kompiliert je nach Target Platform ein dediziertes PRG. Meine Frage war, ob es möglich ist, wirklich nur ein einziges Binary File zu kompilieren, welches durch interne Codeweichen erkennt, auf welcher Plattform es läuft?

Der C128 kann über die extra VIC-II-Register detectiert werden durch C64-Programme. Im C64-Modus können dann die zusätzlichen Tasten, der 2MHz-Modus und VDC verwendet werden.

Für den C128-Modus ist es theoretisch möglich, ein Programm zu laden, das zur Laufzeit erkennt, auf welchem Computer es läuft. Das Programm muss dann mit load "x",8 anstelle von ,8,1 geladen werden. Wegen der großen Unterschiede zwischen den Computern ist dies hauptsächlich eine theoretische Möglichkeit, man würden eine Menge plattformabhängiger IF's in der Code verwenden. Eine Neukompilierung auf Basis desselben Quellcodes ist eine bessere Idee.

Ein weiteres Beispielchen: Cartridge-Initialisierungscode auf dem C128 ist viel einfacher als auf dem C64:

Quote from m6502

Quote from dmantione

dass C128-Code oft kürzer ist als C64-Code

Erkläre das bitte mal genauer. MMn ist dem nicht so.

Es gibt viele kleinere Beispiele, ich gebe dir eines: Versuche es zum Beispiel eine Datei an der Adresse $D000 in Code zu laden, der an der Adresse $F000 läuft.

Auf dem C128 ist das ein Kinderspiel: JSRFAR auf LOAD in Bank 15.

Auf dem C64 hat man das Problem, daß man von $F000 aus nicht das KERNAL aufrufen kann und dann das Problem, daß die LOAD-Routine nicht nach $D000 schreiben kann. Man muß auf dem C64 ein Trampolin schreiben, das die KERNAL sichtbar macht, dann LOAD aufrufen und die Datei in einen temporären Puffer laden und dann nach $D000 kopieren.

Es ist nicht sehr schwierig, ein C64-Programm auf den 128er-Modus zu portieren. Allerdings muss man sich fragen, was das bringen soll. Im C128-Modus steht viel mehr Speicher zur Verfügung, die Floppy ist viel schneller. Das sind zwei konkrete Vorteile. Aber man braucht sowieso einen Fastloader für den C64, und wenn man sowieso einen Fastloader für den C64 schreiben muß, ist dieser Vorteil für den C128 verloren. Überreste, mehr Speicher. Das kann durchaus nützlich sein, zum Beispiel kann man mehr mit Bitmaps machen oder ein größeres Spielfeld in ein Spiel einbauen. Aber das erfordert harte Arbeit, und das ist die eigentliche Aufgabe der Unterstützung der C128.

Es ist viel einfacher, ein C64-Spiel mit C128-Fähigkeiten zu verbessern, der 2MHz-Modus, die Tastatur und der VDC sind alle im C64-Modus verfügbar und erforderen daher keine Portierung.

Meiner Meinung nach gibt es noch einen weiteren Vorteil des C128 und zwar, dass C128-Code oft kürzer ist als C64-Code, und für die C128-Entwicklen daher Zeit spart. Aber... Auch hier ist es keine Option, den C64 nicht zu unterstützen, also kann man nicht ausschließlich für den C128-Modus entwickeln.

Du hattest noch Platinen, AndroSID? Startet einen Preiskampf mit pazuzu72!

Der PLA16V8 passt in einen C116. Auf dem Foto benutze ich einen meiner Prototypen:

Inklusiv Sockel in der Hauptplatine und PLA ist die Höhe ungefähr so groß wie der Cartridgeanschluss. Das Gehäuse kann problemlos geschlossen werden:

Es gibt jedoch ein mechanischen Konflikt wenn man das originale Funkabschirmungsblech verwerdet:

Da ein C116 einen hohen Sammlerwert hat (ein Plus/4 ist viel praktischer) und zu einem hohen Preis verkauft wird, würde ich es so weit wie möglich in seinem Originalzustand belassen. Ich wäre daher geneigt, eine PLA aus einer C16 oder Plus/4 zu nehmen und die PLA16V8 darin zu verwenden und die C116 mit original PLA und Funkabschirmungsblech auszustatten.

Bei der Verwendung von EPROMs als PLA gibt es drei Herausforderungen:

• Zeitplan
• Logiklevels
• Schaltgeräusche

Ich habe genug Beweise dafür gesehen, dass bestimte EPROMs stabil wie eine PLA funktionieren können, aber alle drei Punkte mit einem EPROM richtig zu machen, ist fast unmöglich.

Da PLA-Leitungen am Cartridge-Port vorhanden sind und C64-Cartridges alles tun, was Gott verboten hat, führt dies zwangsläufig zu Inkompatibilität. Der Epyx-Fstload verwendet z.B. eine PLA-Leitung, um einen Kondensator zu laden, und man erhaltet ein anderes Timing, wenn man unterschiedliche Spannungen an der PLA verwendet.

Quote from Bubblebobble

As i can see the gamedude just delivers to Australia and i am not registered to amibay...is there another way to order?

Ähm ... du hast Probleme mit einem Plankton in einem 407-platine und nachdem jemand bestätigt hat, dass sich elektronisch nichts geändert hat, kauft du denselben Plankton noch einmal? Natürlich kann es sein, dass es eine gewisse Toleranz zwischen den einzelnen Exemplaren gibt, aber ich würde es mit einer ganz anderen PLA versuchen. Wenn du Erfolgschancen maximieren willst, versuchen es mit einer PLA20V8,NeatPLA oder PLAdvanced.