Kleiner Hinweis zur Zahl in der oberen linke Ecke: Das sind nicht die Frames/Second. Das sind die Anzahl der 1/50-Bruchteile einer Sekunde, die ein Frame benötigt. Also quasi ein Frametimer, d.h. je niedriger desto flutsch. Außer man lässt das auch einem Amiga laufen, der eine 68000er-basierte Turbokarte hat (wie die ACA-Karten). Dann misst das Ding das Quatsch, weil KK nicht davon ausging, dass sowas existiert und er da einen Überlauf im Zähler vermutet, wo keiner ist. Mit einem 68020+ ist die Zählung dann wieder ok.
Posts by EgonOlsen71
-
-
... war der Cevie dem 800XL doch in jedem anderen Punkt unterlegen
Nee. Der Atari war fantastisch, wenn man bedenkt, wann der rausgekommen ist. Da war er seiner Zeit weit voraus. Er hat auch mehr Farben als der C64, 256 statt 16. Da gewinnt er ebenfalls. Er kann auch sehr flexibel mit seinen Grafikmodi umgehen (Stichwort Displaylists) und hat auch eine ganze Menge davon. Das ist alles cool am Atari. Er ist etwas schneller als der C64 (die MHz-Zahl von 1,79 kann man nicht direkt vergleichen, weil der Videochip die CPU ausbremst. Effektiv ist er selten schneller als 30% mehr...aber immerhin!). Er krankt meiner Ansicht nach aber an drei Dingen:
- Fehlendes Attributram: Der C64 kann seinen Zeichensatzbildschirm (und auch den für Grafik) viel bunter gestalten, weil er 1000*4 Bit Attributram hat. Damit kann er jedem 8*8 (bzw 4*8 in Multicolor)-Pixel-Quadrat neue Farben zuweisen. Sowas hat der Atari nicht. Dort gilt die Palette für den gesamten Bildschirm. Will man mehr Farben haben, muss man mit Displaylist-Interrupts arbeiten, die funktionieren dann aber nur pro Zeile. In der Konsequenz sind viele Atarispiele eher farblos.
- Hardware-Scrolling: Hat der Atari, aber der C64 scrollt immer (auch in Multicolor) in 320*200. Der Atari scrollt in der gewählten Auflösung. Dadurch ist das Scrolling nicht so weich, sofern das Spiel nicht gerade in Hires läuft, was eher nicht der Fall ist.
- Sprites: Der C64 hat 8 Sprites mit 24*21 Pixels in Hires (2 Farben inkl. Hintergrund), bzw. 12*21 in Multicolor (4 Farben inkl. Hintergrund). Der Atari hat 4 Player und 4 Missiles. Beide haben 2 Farben inkl. Hintergrund, die Player sind 8 Pixel breit, die Missiles 2(!). Dabei sind die Pixel aber immer doppelt so breit wie ein Hires-Pixel. D.h. die Atarisprites haben dieselbe Auflösung wie die C64-Multicolorsprites, sind aber schmaler und weniger bunt. Dafür sind sie so hoch wie der Bildschirm. Allerdings kann der Videochip sie nur in der Horizontalen verschieben, eine vertikale Verschiebung erfordert Umkopieren im Speicher.
Das alles führt dazu, das Atarispiele selten besser aber oft schlechter aussehen als ihre Entsprechungen auf dem C64. Ich mag meine Ataris, aber man merkt, dass sie nicht ganz mithalten können. Dafür waren sie aber natürlich auch 3 Jahre früher (in Form des Atari 400 und 800) auf dem Markt, das darf man nicht vergessen.
-
Die Steuerung ist wirklich etwas hakelig. Vor allem wenn man in der Mitte die Punkte alle "aufessen" will, oder in einen schmalen Seitenzweig abbiegen moechte.
Ja, aber man gewöhnt sich dran. Besser habe ich es nicht hinbekommen, weil ich nicht alle neu schreiben wollte. Aber das war ja nicht das Ziel der Übung.
-
Moin,
ich habe mir mal (warum auch immer...) ein paar der "Spiele" angeschaut, die sich auf Cascade's Cassette 50 finden lassen. Eine "berühmte" Spielesammlung mit 50 in BASIC programmierten Spielen, die allesamt komplette Grütze sind. Das Aushängeschild der Sammlung ist Maze Eater. Jedenfalls sollte es das sein, denn es ist das erste Spiel auf der Kassette bzw. Diskette. Es ist ein verunglückter Pac-Man-Klon, schnarchlahm und voller Fehler. Immerhin hat es eine eigene Idee, aber die ist blödsinnig (siehe unten).
Im ersten Schritt dachte ich, dass das Spiel vielleicht spielbarer wird, wenn man es kompiliert. Ein bisschen stimmt das auch, aber es ist dann immer noch Grütze. Nur eben schnellere Grütze.
Dann habe ich mir Spiel und Quellcode mal genauer angeschaut, um zu sehen, was man tun müsste, damit es nicht mehr ganz so furchtbar ist. Erstmal natürlich die Fehler beheben, die da wären:
- Im Introscreen soll die Spielfigur das Logo des Spiels auffressen, vergisst aber die letzen beiden Zeilen.
- Im zweiten Spieldurchlauf werden im Introscreen Teile des Bildes von einem schwarzen Spriteblock überlagert.
- Im Spiel sind die Sprites der Länge nach gestreckt und passen dadurch überhaupt nicht ins Labyrinth. Steuern wird zur Glücksache.
- Die Sprites des Geistes sind, durch einen Tippfehler in den DATA-Zeilen (. statt ,), kaputt. Deswegen wird die eigentlich vorhandene Augenanimation gar nicht benutzt, ist im Code aber in Fragmenten noch sichtbar.
- Die Kollisionsabfrage schlägt manchmal fehl.
- Die Früchte sitzen so im Level, dass man die eigentlich nicht aufsammeln kann.
- Wenn der Geist blinkt und gefressen werden kann, flieht er nicht, sondern bewegt sich weiter auf den Spieler zu.
- Das Fressen von Geistern zählt wie das Sammeln eines Punktes, d.h. je mehr Geister man frisst, desto weniger Punkte muss man sammeln, um den Level zu beenden (das könnte auch ein Feature sein, wer weiß...).
- Der Aufruf der Spielschleife ist je nach Kontext mal mit GOTO, mal mit GOSUB, so dass nach mehreren Durchläufen (gut, die macht ja niemand, aber naja...) der Stack einige Leichen enthält, die nie mehr abgeräumt werden.
Als eigene Idee bringt das Spiel mit, dass das Labyrinth quasi in drei Stufen durchlaufen wird:
- ganz normal
- wie 1., aber man sieht nur noch die Pillen. Wände und Hintergrund sind schwarz (das könnte man noch als Feature durchgehen lassen...)
- wie 2., aber die Kollisionabfrage mit den Wänden ist abgeschaltet. Man stirbt hier dann, wenn man aus dem Bildschirm läuft (das ist nun wirklich Blödsinn).
Weiterhin hat das Spiel Komfortprobleme wie die zuppelige Steuerung und die Tatsache, dass man die Introanimation nicht abbrechen kann.
Die Idee war jetzt, ob ich an einem verlängerten Nachmittag daraus irgendwas spielbares basteln kann, ohne den Orginalcode zu sehr zu verändern. Also quasi: Hätte Cascade das mit etwas Aufwand und einem BASIC-Compiler so verbessern können, dass es nicht mehr komplette Grütze ist, sondern nur noch ein bisschen Grütze.
Das Ergebnis ist Maze Eater HD. Ich habe den Quellcode in seiner unnachahmlichen Wurstigkeit nicht groß verändert, sondern nur an den Stellen meine Änderungen reingehackt, wo es nötig war und versucht, die gröbsten Fehler zu korrigieren.
Primär heißt das:
- Introscreen korrigiert und überspringbar gemacht
- die Geistersprites korrigiert und für den Introscreen wiederbelebt
- die Animationen des Geistes im Spiel reaktivert
- die Spriteskalierung im Spiel korrigiert
- das Aufsammeln der Früchte korrigiert
- die Kollisionsabfrage korrigiert
- das Verhalten des Geistes korrigiert
- Punktezählung angepasst
- die Steuerung verbessert (immer noch nicht perfekt, aber für mich gut genug)
- die blödsinnige Idee mit dem Verdunkeln und der abgeschalteten Kollision ersatzlos gestrichen
- kleinere Änderungen, um das Spiel etwas besser spielbar zu machen
- Ergänzungen wie eine Game-Over-Anzeige und eine Anzeige für das Levelende
- Farbanpassungen
Das alles reingehackt in den bestehenden
KotCode...weil's so schön ist.Das zeigt aber, finde ich zumindest, dass man bei Cascade mit nur etwas mehr Aufwand eine etwas bessere Compilation hätte zusammenstellen können. Aber naja, hat sich wohl auch so gelohnt.
Anmerkung: Es gibt anscheinend eine neuere Version von Cascades Maze Eater, die einige der hier genannten Punkte ebenfalls behebt...immerhin... Die habe ich aber nicht. Ich habe die erste als Basis verwendet.
Auf dem angehängten Diskettenimage ist die kompilierte Version meines angepassten Spiels (Maze Eater HD). Weiterhin eine kompilierte Version des Orginals (++Maze Eater) und das Orginal (Maze Eater) zum Vergleich.
Happy Eating (oder auch nicht...)!
-
Obwohl es faszinierend ist, was man doch noch aus einem A500 rausholen kann, würde ich davon in kürzester Zeit furchtbare Kopfschmerzen bekommen. Die später gezeigte A1200-Version sind dagegen nochmal deutlich flüssiger aus.
Geht eigentlich. Ich habe es mit einem normalen 500er und mit einem gepimpten mit 42MHz 68000er ausprobiert. Klar ist letzterer schneller, aber so schlimm ist der normale 500er nicht. Immer noch besser als Cyberpunk auf Konsole...
-
Das ist ein Doomclone, der auf einem A500 (und dem ST) läuft. Video und Downloadlink hier: https://www.youtube.com/watch?v=ZxhO1ZCOZ-M
-
Ja, das finde ich auch ein bisschen schade, dass der Pi400 so "unschoen" aussieht. So toll das Konzept auch ist, das Ding sieht halt aus wie ne 0815-Mini-Tastatur (was es ja auch urspruenglich war). Ein bisschen mehr "Charakter" haette dem Teil nicht geschadet, dazu muesste es nicht mal sonderlich "retro" sein. Aber gut, das ist jetzt offtopic...
Aber das Problem lässt sich doch einfach lösen...
-
kein Z80. 
Wäre aber kein Problem, habe ein paar davon rumliegen. Die sind aber, soweit ich weiß, NOCH nicht kaputt...
-
Vielleicht könnte man so einen Käfer auch in Kunstharz eingießen, um einen Anhänger daraus zu basteln.
Das ist eine coole Idee. Leider habe ich kein Material und auch keine Ahnung, wie man sowas schön und blasenfrei hinbekommt. Aber vielleicht jemand anders...
-
und rechts unten hängt an dem "Gebamsel" ja auch noch ein C64 oder MEGA65
Ja, gut erkannt! Das ist ein TheC64-Schlüsselanhänger.
-
Einen neuen Schlüsselanhänger. Bisher hatte ich einen SID daran hängen, aber der ist zerbrochen. Jetzt also eine 8501-CPU.
-
Zwei der Kernal-ROM-Pins (mittleres ROM) sehen aus, als ob sie gar nicht im Sockel stecken würden.
-
Inzwischen ist Python auf dem TIOBE-Index auf Platz 2: https://www.tiobe.com/tiobe-index/
Ja, dürfte primär dem Umstand geschuldet sein, dass das ganze Machine Learning/AI-Gedönse da gut mit Tools und Bibliotheken vertreten ist.
-
Wie sieht den das Gehäuse bzw. die Tastatur aus? Hat das Gehäuse den normalen C=-"Aufkleber" oder ist das C=-Logo gegossener Gehäusebestandteil? Hat die Tastatur zwei Amiga-Tasten oder ist die linke Amiga-Taste eine Commodore-Taste?
-
Es gibt jetzt ein Video: https://youtu.be/YeKVkhQPqs4
-
Display More
Bis etwa 97 Blocks scheint es zu gehen, danach wird abgeschnitten. Das Orginalprogramm, das nur mit einem Laufwerk arbeitete, kopiert noch korrekt. Also irgendwas anderes ist da noch schief, unabhängig von der Ablage des Maschinenprogramms.
Dann muss es an der Auswertung der Rückmeldung vom Assemblerteil liegen, der Code ließt ja bis Dateiende oder bis High-Byte Puffer = 255.
97 Blocks wäre in etwa der Bereich von $A000-$FFFF, das könnte damit zusammenpassen, wenn der Start des Pufferspeichers immer erst ab $A000 beginnt (ich habs nicht mehr im Kopf, aber war glaube ich der Wert in 55/56 der Zeropage der ausgelesen wird).
Müsste man in dem Bereich wo "SYS mr" (2290?) verwendet wird mal mit dem Original vergleichen.
Der Code sieht mir identisch aus. Aber: Er liest als Pufferstart den Wert in 56 aus und setzt ihn in AH%(0). Von dort wird er an das Maschinenprogramm übergeben. Im Original steht der da zu diesem Zeitpunkt am Ende des BASIC-Programms, weil er gleich am Anfang darauf umgesetzt wird. Von daher hat man da den ganzen Puffer vom Ende des Programms bis $FFFF verfügbar. Die Version von alke01 setzt den Wert zwar auch um, aber viel zu spät (erst beim Aufruf des Kopierens). Der Pufferanfang ist da schon lange in AH%(0) festgelegt und liegt auf dem Initialwert von 56, also 160. Der Puffer reicht dort also immer nur von $A000-$FFFF (wie du schon gesagt hast!). Ich kann im Code auch nicht erkennen, wie das Kopieren in mehreren Durchläufen von Erfolg gekrönt sein sollte. Wenn ich im Original den Puffer bei $A000 starten lasse (indem ich 56 einfach nicht umsetze), dann kopiert das Ding auch nur 97 Blocks.
-
Habe das mit dem Kassettenpuffer mal probiert, geht soweit (siehe Anhang). Allerdings kopiert sowohl diese Version als auch die von darkvision oben hochgeladene Fix-Fassung große Dateien nicht mehr vollständig. Bis etwa 97 Blocks scheint es zu gehen, danach wird abgeschnitten. Das Orginalprogramm, das nur mit einem Laufwerk arbeitete, kopiert noch korrekt. Also irgendwas anderes ist da noch schief, unabhängig von der Ablage des Maschinenprogramms.
-
Ja, Kassettenpuffer hätte ich jetzt auch gesagt...
-
Wäre es nicht sinnvoller, das Assemblerprogramm an einer anderen, fixen Stelle im Speicher abzulegen (für die 135 Bytes wird sich ja irgendwo ein Platz finden lassen...) und sich damit das Gefummel bei jeder Änderung zu ersparen? Wenn man das Nachladen verhindern will und nur eine Datei haben möchte, dann kann man das doch auch einfach in DATAs im BASIC ablegen und kurz einlesen. So lang ist es ja nicht. Dann entfällt dieser komische Hack mit dem Ende des Basicspeichers. Oder übersehe ich da was?
-
Die "lokale Interpretation", die der C128 daraus je nach Ländereinstellung macht ist ja wieder ganz was anderes und kommt MMN "obendrauf".
(Alt-Gr + 8 ist auf der PC-Tastatur das "[". Das "[" ist beim C64 über dem ":", WIMRE. -> "symbolic" )
Schon klar. Ich habe ja auch nicht mit den Layouts angefangen...
Es ging mir eigentlich nur darum, dass das Verhalten des Emulators unter CP/M fehlerhaft ist, was die Tastaturabfrage angeht. Wenn ich SHIFT+. tippe, dann sollte das Ergebnis immer dasselbe sein (was es im C64- und C128-Modus auch ist) und nicht mal : und mal [. Und den Doppelpunkt bekomme ich nur verlässlich, wenn ich die Tastenkombi drücke, die mir eigentlich ein [ liefern sollte. Da ist einfach was schief.
