-
Wie meinst du das? Gerade die Transitions von einer CPU zu anderen hat Apple besser gemanaged als jede andere Firma. Es wurde immer dafür gesorgt, das Bestandssoftware auch auf der neuen Plattform läuft.
Auf einem aktuellen Windows kann man immer noch 32-Bit-Windows-Binaries aus den 90ern laufen lassen und auf einem 32-Bit-Windows sogar noch DOS-Software aus den 1980ern. Bei Apple wird der Nutzer da im Regen stehen gelassen: Das PPC-Rosetta gabs nur in einer einzigen OSX-Version, die virtualisierte Classic-Umgebung funktionierte ausschliesslich auf PPC-Macs und flog im letzten PPC-OSX-Release auch raus, 32-Bit-OSX-Software wurde mit 10.15 getötet und ich bin skeptisch, dass die ARM-Version noch lange x86-Binaries ausführen kann sobald Apple offiziell keine x86-Macs mehr verkauft.
Als Retro-affiner sollte man solche inkompatibelen Praktiken echt nicht gutheißen.
-
Habe die 6. überarbeitete und erweiterte Auflage hier vorliegen. Ja, die ist von 1987 und enthält aber kein Kapitel 1.10 mit einem Viruskiller.
-
Na ja wenn ich ein Vollzeitprojekt unterstütze dann bleibt es wohl nicht aus das ich die Lebenserhaltungskosten mit finanziere.
Genau da liegt doch das Problem der Backer. Jeder Cent soll in die physische Produktion des Spiels fliessen.
-
... war es nicht so das sie das als Vollzeitprojekt machen wollten? Da wäre der Nachweis wohl sehr einfach in dem man Miete, Strom, Heizung, Auto und Essen der vergangenen Jahre gegenrechnet.
Ich bezweifele, dass die Kritiker deren Lebenshaltungskosten als legitim ansehen würden.
-
Ich kenne den Code vom Amiga OS auch recht gut, da gibt es sicherlich einige Dinge, die nicht wirklich gut umgesetzt sind
Was liegt denn da alles im Argen?
-
Wäre es nicht sinnvoller, den Raspi-Ansatz in einen neuen Thread auszulagern?
Warum? Der beißt sich doch nicht mit meiner Grundidee, die ich anfangs formulierte – und wurde auch immer wieder ins Spiel gebracht. Ich hatte jetzt nur angekündigt, dass ich persönlich nun auch diesem Pfad (also reine Emulation) folgen möchte, weil ich in vielerlei Bereichen dort das größere Potential sehe.
Weil dieser mMn bisher vielversprechendste, weil in einen zeitklich überschaubarem Aufwand auch in Hardware realisierbare Ansatz einen eigenen Thread verdient und ansonsten hier unterzugehen droht.
-
Als Standard-Hardware für den "Homecomputer" schlage ich einen relativ aktuellen Raspberry Pi vor – der ist klein, einigermaßen preiswert und hat alle Schnittstellen, die wir brauchen könnten.
Wäre es nicht sinnvoller, den Raspi-Ansatz in einen neuen Thread auszulagern?
-
Referenz oder informelle Beschreibung
In bezug auf was?
Die ISA.
-
Eine Rückmeldung wäre z. B. eine Frage, welcher Befehlssatz die CPU hat
Hast du vieleicht schon eine Art Referenz oder informelle Beschreibung vorliegen, die du hier posten kannst?
-
Es soll ja auch ein Retrorechner sein und eben keine Spielkonsole mit spezialisierter Hardware für einen bestimmten Typus von Spiel. Daher greife ich in dieser Hinsicht gerne auf das Motto der Archimedes-Entwickler zurück, das sinngemäß lautet: "Alles, was in Software erledigt werden kann, macht die Software, und die Hardware ist so einfach wie möglich zu halten."
Würdest du dann auch soweit gehen und zum Beispiel keine grösseren Playfields anbieten, aus den dann ein ausgewählterAusschnitt angezeigt wird, vieleicht sogar ohne Feinscrolling? Wie rudimänter wäre dann die Soundsystem, etwa nur ein einfacher 8-/16-Bit-DAC-Port ohne DMA?
-
Wäre für Dich anstelle von Sprites auch die Verwendung von Shapes denkbar? Auf größeren Rechnern (ab Amiga/AtariST usw.) geht man so vor, daß man zwei Bitmaps definiert. Die erste Bitmap guckt sich der Benutzer an. Auf der anderen Bitmap wird die Grafik neu gezeichnet. Dabei malt man zuerst den Hintergrund neu und löscht dadurch gleichzeitig alle Figuren. Dann kopiert man die Shapes in die Bitmap. Ist man fertig, werden die beiden Bitmaps vertauscht. Der Benutzer sieht nun die (fertige) zweite Bitmap, und das Programm malt auf der ersten.
Nur hier liegt - wie gesagt - die Gefahr, daß man als Programmierer dann komplett auf den Originalbefehlssatz des 6502 verzichtet und nur noch die erweiterten Befehle verwendet. Wenn es allein darum geht, einen neuen Retrorechner zu haben, der auch C64-kompatibel ist, wäre dies kein Problem. Wenn man das Gerät aber verstehen will als Nachfolger des C64, könnte zu viel Flair vom Brotkasten verloren gehen, als daß es sich dann noch um einen würdigen Nachfolger handelt.
Würdest du, um dieser "Gefahr" zu begegnen, deshalb auch dem Sprites-Charset-Prinzip weiter den Vorzug geben?
-
(es sei denn man beschränkt sich auf einen festen für Apps reservierten Speicherbereich und kann immer nur eine gleichzeitig im RAM haben) -- selbst ohne (simple) Multitasking-Möglichkeiten wird es nicht mehr gehen, denn selbst wenn man sinnvollerweise nur eine Anwendung gleichzeitig nutzen will (einfach der Rechenleistung geschuldet) so hat ein modernes OS doch auch selbst noch Dinge "im Hintergrund" zu tun.
Welche praktischen Einschränkungen hätte denn so ein Simpletasking-System? Oder anders gefragt: Wären dann trotzdem noch so viele Hintergrunddienste notwendig, dass der zusätzliche Implementierungsauswand im Vergleich zu einem vollwertigen Multitaskingsystem vernachlässigbar wäre?
-
Greg hat zu C64 OS einen Vortrag gehalten (inklusive einer kleinen Demo):
-
Ich träume ja seit Ewigkeiten von eine WipeOut Port für den C64. ... Aber bezüglich Grafik bin ich mir nicht sicher wie man das adequat hinbekommen sollte. Spontan fällt mir was isometrisches ein wie Zaxxon.
Wie willst du damit einen Geschwindigkeitsrausch hinbekommem?
Die technische Hauptschwierigkeit von so einem Spiel sehe ich schon in der "Driveengine". Und die ist ja absolut top umgesetzt worden.
Technik (alleine) erzeugt keine Spielspaß.
-
Open Source bedeutet (je nach Open Sourcelizenz) das damit keinerlei kommerzielle Produkte entstehen dürfen und das Ergebnis einer Weiterentwicklung selbst Open Source sein muss.
Genau das bedeutet "Open Source" nicht. Das sehr kommerzielle M$ Windows zum Beispiel hat BSD Netzwerkcode übernommen, ohne den Quellcode offen legen zu müssen. Auch die restriktivere GPL fordert zwar eine Weitergabe des Quellcodes, aber verbietet keinen Verkauf.
-
Ok ich sehe auf der Disk ist dieses "Wraptor" drauf. Mal sehen ob sich daran was erkennen lässt. Ne Doku des Fileformats wäre einfacher gewesen 
aber ok 
Die gibt es hier: https://ist.uwaterloo.ca/~schepers/formats.html
-
Analog meine ich, gibt es auch nicht wirklich viele, die einen völlig nackten C64 ohne gemoddete 1541 heute einsetzen. Da werden, wenn echte Floppies genutzt werden, auch Parallel-DOS Umbauten vorgenommen, Kernal-Patches, externe Module wie EasyFlash, Ultimate 1541 uvm. - ich sehe da keinen großen Unterschied zum Atari 8-Bit (und letztlich auch andere Systeme wie ZX Spectrum usw.).
Der entscheidende Unterschied ist aber, dass 99,99% der C 64 Releases auf einem unveränderten Rechner plus Floppy laufen.
Das mit dem Nachladen stimmt allerdings nicht. Die bekannten Ladegeräusche lassen sich per "Poke" ausschalten und ebenso kann der POKEY Daten von SIO laden, während Sound abgespielt wird. Jedes Original auf Diskette von LucasArts (Rescue On Fractalus, Koronis Rift etc.) beweist das - wie auch diverse Hacker-Intros...
Wieso setzen dann so viele Atari Releases zwindeng eine Speichererweiterung vorraus?
-
Ein kleiner Boulder Dash Klon, vielleicht sogar ohne Scrolling, einfach nur um das Prinzip zu verdeutlichen? Vielleicht gar in BASIC?
Wie man (auf dem Atari) dabei vorgehen kann, zeigt dieser Vortrag:
-
Von daher frage ich mich, warum Du hier implizierst, dass meine Argumentation solch einen Spielinhalt rechtfertigen wuerde.
Nun, die einen assoziieren Nazis mit Hakenkreuzen, andere mit KZs. Wenn man deshalb der Ansicht ist, dass in einem Nazispiel zwingend Hakenkreuze vorkommen müssen, dann warum nicht auch KZs?!
-
... wenn man in Wolfenstein ein KZ-Waerter waere, der Insassen quaelt.
Was spräche nach deiner bisherigen Argumentation gegen so ein Spielinhalt?
