letzter Beitrag von Retrofan am
Für meine Programme habe ich Routinen geschrieben, die erkennen, ob TC64, SCPU, DTV oder C128 vorliegen, und den Rasterinterrupt entsprechend einrichten. Das mußte ich aber alles selber schreiben. Wo findet man hierfür vorgefertigten Code?
Hast du die Routinen vorliegen und magst die beschreiben oder vieleicht sogar posten?
Hast du die Routinen vorliegen und magst die beschreiben oder vieleicht sogar posten?
LIegen irgendwo auf der Festplatte (des alten Rechners). Posten? Nicht in diesem Thread.
Es war ein Gedankengang, wenn es besser ist mit einem dedizierten Grafikspeicher, ist doch OK...
Ich habe nie etwas von einer Workstation geschrieben?!
Ich habe nie etwas von einer Workstation geschrieben?!
Sorry, hatte ich auch gerade gemerkt und schon gestrichen.
Kleines update: ich habe den Befehlssatz meiner ausgedachten CPU nochmal verändert (und das wird bestimmt noch ein paar mal passieren 
Und ich habe den x64 (vice) gepatcht: fast alle addressierungs-modi, ein paar befehle und der disassembler funktionieren schon. Ich werden den eingebauten assembler nicht umbauen. Werde euch was zeigen, wenn's wirklich was zu zeigen gibt.
(P.S.: Is ein übler hack der grosse teil des 6502/6510 Zeugs ersetzt.)
Alles ab der Ebene des Taktzyklus sollte identisch ablaufen mit einer Ausnahme: Die Adreßleitungen des IO-Bereichs von $d000..$dfff werden anders dekodiert. Programme, die darauf vertrauen, daß man bei einem "STA $d095" tatsächlich nach "$d015" schreibt, werden nicht funktionieren.
Was ist der Hintergrund für diese Ausnahme? Würden durch eine C 64-konforme Adressdekodierung einfach zu viele FPGA-Ressourcen belegt?
ich habe den Befehlssatz meiner ausgedachten CPU nochmal verändert (und das wird bestimmt noch ein paar mal passieren
Macht nichts. Ist völlig normal. (Kenn ich aus eigener Erfahrung. 
)
Und ich habe den x64 (vice) gepatcht:
Wow! Das ist natürlich eine tolle Sache, wenn man gleich eine gute, alte, bekannte "Hardware" hat, an der man ISA und Programme austesten kann. Viel Arbeit, aber das dürfte sich bezahlt machen.
Werde euch was zeigen, wenn's wirklich was zu zeigen gibt.
Sehr gerne. Bin gespannt. 
Was ist der Hintergrund für diese Ausnahme? Würden durch eine C 64-konforme Adressdekodierung einfach zu viele FPGA-Ressourcen belegt?
Nein, was den FPGA anbelangt, so wäre der Verbrauch minimal. Es geht eher darum, daß der IO-Bereich neue Hardwareregister enthält wie z. B. den zweiten SID. Wenn ein Programm nun teilweise in den zweiten SID schreibt in der Annahme, daß die Adressen irgendwie gleich sind, und dann den Ton im Original-SID bei $d400 einschaltet, erklingt halt nichts. Ähnlich ist es mit den Videoregistern. Noch ist nicht definiert, an welcher Adresse die Zusatzregister des VICIIx2 eingeblendet werden. Es könnte also sein, daß ein Programm denkt, $d095 wäre $d015, aber tatsächlich befindet sich unter dieser Adresse ein neues Register des VICIIx2 zum Anzünden des Bildschirms (Halt and catch fire). Da dürfte dann der Benutzer des Programms sein blaues Wunder erleben.
Und nun wünsche ich noch allen Mitdiskutanten hier Frohe Ostern!
Dieser Thread ha ja eine ganz schöne Wendung genommen. Von "NEUER (Wunsch)Rechner im Retrosytle der kein weiterer C64 Clon sein sollte" zu "muss aber auf jeden Fall C64 kompatibel sein".
Ganz ehrlich. Einen C64 Klon finde ich persönlich ziemlich uninteressant. Warum sollte man den nehmen und nicht den 64er? Wenn man mehr Power will, gibts genug Systeme die das können, und mehr Power wofür? Für ernsthafte Anwendungen wird so ein System nicht mehr verwendet, dafür gibts den PC. Und für Spiele kommts in erster Linie auf die Inhalte an und nicht auf die Technik.
Ganz ehrlich. Einen C64 Klon finde ich persönlich ziemlich uninteressant. Warum sollte man den nehmen und nicht den 64er? Wenn man mehr Power will, gibts genug Systeme die das können, und mehr Power wofür? Für ernsthafte Anwendungen wird so ein System nicht mehr verwendet, dafür gibts den PC. Und für Spiele kommts in erster Linie auf die Inhalte an und nicht auf die Technik.
Das sehe ich auch so. Die Richtung, die der Thread genommen hat, kommt mir persönlich als Sackgasse vor.
Man will unbedingt zum leichteren Fahren ein Navigationsgerät in den Oldie bauen und damit das halbwegs funktioniert, braucht man "mehr Power".
Das Problem dabei ist nur, dass jedes aktuelle Auto ein Vielfaches an Power hat und man beim Neubau des Oldies vom Komfort nie dieses Niveau erreichen kann.
Gleichzeitig wird vergessen, dass man einen Oldie auch deshalb fahren will, weil er gerade ein Auto ohne Navi ist, weil man ganz bewusst "mit Karte" fahren will.
Man will unbedingt zum leichteren Fahren ein Navigationsgerät in den Oldie bauen und damit das halbwegs funktioniert, braucht man "mehr Power".
Das sehe ich nicht so. Der Thread hat meines Erachtens gar keine "Richtung" angenommen, sondern es werden zu unterschiedlichen Zeiten unterschiedliche Konzepte diskutiert. Da gibt es keine zwingende Richtung. Morgen kann auch wieder ein Konzept diskutiert werden, dessen Rechner mit 6 Bit und 0,7 MHz Taktfrequenz läuft.
Es gab halt irgendwann das Konzept, einen eher "schwachen" Retro-Rechner zu konzipieren (wenn man eine Range annimmt, bei der der C64 die unterster Schwelle darstellt und ein Amiga 1200 vielleicht die Obergrenze markiert). Und genauso gab es hier Konzepte mit 32-Bit CPUs oder auch RISC-Prozessoren.
"Gleichzeitig" wurde im Bereich der Software-Konzepte und Usecases der Wunsch geäußert, man solle direkt auf der Maschinen komfortabel programmieren können. Komfortabel meint hier: Besserer Code-Editor als in den 80er-Jahre-Homecomputern üblich, Unterstützung von Zusatz-Editoren im Bereich Grafik und Sound, Hochsprache mit Game-relevanten Befehlen, kurze Turn-Around-Zeiten, ausreichende Performance für einfache Action-Spiele. Das könnte halt eine Zielgruppe (Casual-Coder) anlocken, die von den gerade entstehenden Retro-Rechnern nicht wirklich gut bedient wird.
Jetzt war halt die Frage, ab welcher Performance bei den vorgestellten Hardware-Ideen die IDE-on-machine Idee machbar wäre. Es zeigt sich, dass man das ganz nah an der C64-Performance wohl knicken kann aber ab Amiga 500-Power (CPU-Bauart plus Taktfrequenz plus RAM) in den Bereich des Möglichen rückt.
Von der Power her wäre das für mich persönlich gerade noch OK – da gehen Retro-Rechner, wie der Mega65 mit seinen 50 MHz, deutlich drüber. Auch grafisch gehen die anderen Rechner deutlich weiter als das bei den meisten Konzepten hier der Fall ist. Zumindest war es eine meiner Prämissen, dass die Grafik-Auflösung und die Farbanzahl unter denen der frühen 16-Bitter bleiben müsste (egal, wieviel Power denn der Rechner drumherum haben würde), damit der Spaß beim Pixeln erhalten bleibt.
Also, es wird hier erstmal nur diskutiert, ob man so eine IDE haben möchte und wieviel Power sie benötigen würde. Also kurz, ob IDE und Retro-Maschine noch zusammenpassen oder einfach 2 unabhängige Ideen sind, die man notfalls getrennt von einander weiterentwickeln müsste. Was du also kritisierst, ist nur eine Diskussion darum, ob das als Kombination möglich wäre.
Einen C64 Klon finde ich persönlich ziemlich uninteressant. Warum sollte man den nehmen und nicht den 64er?
Dann hast du die Beiträge zu dem Thema aber nicht richtig gelesen. Es ging nicht darum, einen C64 nachzubauen – das haben andere schon gemacht (Ultimate 64). Es ging bei dem einen Konzept darum, wie man AUSGEHEND vom C64 eine leistungsfähigere Maschine bauen könnte. Und zwar anders als bei C128 nicht als zwei mehr oder weniger unabhängige Rechner, sondern integriert. Dabei, so denke ich, lag der Focus nicht auf dem Argument der Software-Versorgung, sondern einfach darin, einen eleganten Weg zu beschreiben, wie man es damals auch hätte machen können, statt einen Hybriden zu bauen, den der C128 ja darstellt (und den auch der C65 dargestellt hätte).
Ich faende einen ARM (single core?) mit geringem Takt ideal. Der Befehlssatz ist ueberschaubau auch fuer Assembler, welches man benoetigt um alles rauszuholen.
Gleichzeitig lernt man zumindest im Prinzip eine Architektur kennen die brandaktuell ist.
Quasi ein Archimedes in klein und erschwinglich 
Specs angelehnt an pico aber 256x256 pixel. Wovon 256x128 gleichzeitig zu sehen sind.
Wovon 256x128 gleichzeitig zu sehen sind.
Zum Pixeln fände ich das OK. Aber für einen Code-Editor wäre das den Meisten wohl zu wenig. Du willst also eher einen Rechner (bzw. eine Konsole), den man (ausschließlich) mittels externer IDE auf dem PC programmiert, oder?
Zum debuggen reicht es locker.
Und haben sich hier schon ueberhaupt Leute geaeussert die Dinge fuer System programmiert haben, dass sie das auf dem System selbst machen wollen?
Retrostyle & Devmaschine schliesst sich meiner Meinung nach aus uebrigens
Ich faende einen ARM (single core?) mit geringem Takt ideal. Der Befehlssatz ist ueberschaubau auch fuer Assembler, welches man benoetigt um alles rauszuholen.
Gleichzeitig lernt man zumindest im Prinzip eine Architektur kennen die brandaktuell ist.
Quasi ein Archimedes in klein und erschwinglich
Specs angelehnt an pico aber 256x256 pixel. Wovon 256x128 gleichzeitig zu sehen sind.
Deshalb habe ich bei meinem Konzept auch den PI Zero als Basis genommen. Habe nur dummerweise zu wenig Zeit, so dass es da nur im Schneckentempo weitergeht.
Ich faende einen ARM (single core?) mit geringem Takt ideal. Der Befehlssatz ist ueberschaubau auch fuer Assembler, welches man benoetigt um alles rauszuholen.
Gleichzeitig lernt man zumindest im Prinzip eine Architektur kennen die brandaktuell ist.
Quasi ein Archimedes in klein und erschwinglich
An ARM2 (1986) hatte ich hier wohl schon gedacht. Hatte mich mit der CPU seinerzeit bereits befasst und gestaunt, 4 MIPS @ 8MHz.
Ich wagte es nur nicht zu äußern, weil es eine 32bit-CPU ist und somit nicht dem Thread-Titel nachkommt. Interessant wäre es aber.
Es gibt ja auch eine freie FPGA implementierung
https://en.wikipedia.org/wiki/Amber_(processor_core)
Das Thema gab es in diesem Thread schon kurz
Wenn jemand dazu eine einfache Grafikausgabe und das ganze Gedoens baut (was sicher enorm viel Aufwand waere), hielte ich
das fuer das perfekte Design. ~8 MHz faende ich ebenfalls super. Man kann 3D Sachen machen, sie werden einem aber auch nicht geschenkt
Ob man dann ueberhaupt Hardwaresprites moechte oder nicht waere dann offen.
Und haben sich hier schon ueberhaupt Leute geaeussert die Dinge fuer System programmiert haben, dass sie das auf dem System selbst machen wollen?
Bei der (nicht von mir gemachten) Umfrage außerhalb des Threads kam zutage, dass neben dem Zocken das Programmieren (auf der, nicht nur für die, Maschine) ganz weit oben auf der Wunsch-Liste stand. Und auch beim Projekt vom 8-Bit-Guy (ich denke, das ist der kommende Retro-Rechner mit der potentiell größten "Reichweite") stand ganz weit vorne der Ansatz, dass man AUF der Maschine sehr einfach programmieren können soll – das war fast schon der Auslöser, das Projekt überhaupt zu starten. Nur hat er es meines Erachtens in den Sand gesetzt mit der Idee, die Sprache und den Editor extrem nah am C64 zu orientieren.
Edit: ich glaube, du gehst bei der Software-Entwicklung zu sehr von DEINEM Status aus. Natürlich würden alle Programmierer, die bisher auch schon mit PC-IDEs arbeiten, das auch für einen neuen Retro-Rechner auf die gleiche Art und Weise tun. Wir gehen hier aber bei der IDE-auf-der-Maschine von einem zusätzlichen, ganz anderen Typus von Nutzer/Programmierer aus, den ich als Casual-Coder beschrieb. Das ist jemand, der vielleicht noch BASIC-Grundkenntnisse aus den 80/90er-Jahren hat und damals auch schon mal einen Bildschirm mit Code vollgeschrieben hat. Jemand, der sich gerne mal wieder mit so einem einfachen und in sich geschlossenen System befassen möchte und die Kiste sofort nach dem Einschalten programmieren möchte. Jemand, der sich nicht erst eine Entwicklungsumgebung auf seinem PC installieren will (wenn er dazu Lust hätte, würde er den PC programmieren), sondern nach dem Prinzip Spaß haben möchte: Einschalten, coden, starten, gucken was passiert. Und im Gegensatz zum Rechner vom 8-Bit-Guy, wollen wir diesen User-Coder nicht gleich wieder enttäuschen, weil entweder der Code (selbst bei einfachsten Games) zu langsam läuft oder weil der Editor (bei den doch über die Jahre gestiegenen Erwartungen) einfach zu unkomfortabel ist, um damit Spaß zu haben.
Wie gesagt: Es wäre ein 2. Zugang zum Rechner – neben dem für "Profis".
Retrostyle & Devmaschine schliesst sich meiner Meinung nach aus uebrigens
Ich sehe da weiterhin eine kleine Chance. Auf dem von dir vorgeschlagenen "Archimedes für Arme" sollte es (abgesehen von der bei dir geplanten Grafikauflösung) eigentlich möglich sein, direkt zu programmieren. Der hatte ja schon ein wenig (vielleicht schon zuviel) Power unter der Haube.
Es ist so weit, dass man was sehen kann: das erste Programm entpackt ein Bild und zeigt es an
... nicht gleich wieder enttäuschen, weil entweder der Code (selbst bei einfachsten Games) zu langsam läuft oder weil der Editor (bei den doch über die Jahre gestiegenen Erwartungen) einfach zu unkomfortabel ist, um damit Spaß zu hhaben.
Wer davon enttäuscht ist und keinen Spaß hat, der ist schlichtweg die falsche Zielgruppe für einen 8bit-Rechner. Die sind nämlich naturbedingt langsam und weniger komfortabel in der Benutzung als aktuelle Rechner.
