Projekt C500?

Hallo,

ich habe jetzt mal einige 68HC001 bekommen, das sind 68000er, die man auch in den 8-bit-Modus schalten kann, also ein optionaler 68008.

Allerdings hat der 68HC001 den vollen Adressraum. Ich finde es ja nicht gut, daß Retro-Hardware so teuer ist. Jetzt stellt sich mal die Frage:

Könnte man aus einem A500 mit 68HC001 vielleicht eine Art Low-Cost-C65 basteln? Das wäre ein gutes Recycling für A500 Rev.3 und Rev.5-

Boards mit 512K Chip-RAM-Agnus 8371. Für ein 8 bit-System würde das allemal reichen, während es bei einem Amiga recht knapp wird.

Also es soll ein typischer Commodore-Rechner draus werden, mit BASIC direkt nach dem Einschalten. So wie es eben der C65 geworden wäre.

Die Daten zwischen C65 und 8 bit-A500 sind erstaunlich ähnlich. Ein 68008 soll etwa doppelt so viele Taktzyklen benötigen. Ein PAL Amiga hat

einen Takt von 7.09 MHz, das wären 3.545 MHz, was den 3.54 MHz des C65 entspricht. Allerdings läßt sich der 68HC001 bis 20 MHz takten.

Ich habe die gesamte Liste der Unterschiede mal in einem PDF angehängt.

Preislich hat es natürlich enorme Vorteile, da man nur den 68HC001, einen PLCC-to-DIP-Adapter und ein Eprom benötigt. Zudem könnte man

das ganze hardwaremäßig schaltbar machen, da der 68HC001 auch 16bit-fähig ist. Das würde sich dann auch in andere A500 einbauen lassen,

es muß dann per Schalter gleichzeitig das ROM und Prozessormodus umgeschaltet werden. Das geht über Pin 18 des 68HC001.

Klar, wenn man an so etwas denkt, könnte man das auch auf Basis eines normalen 68000ers machen, aber wäre das bei einem C65-ähnlichen

System notwendig? Zudem gibt es kuriose andere Möglichkeiten: Es sind ja 16 Datenleitungen vom 68000 auf dem A500-Board vorhanden.

Im 8 bit-Modus werden die übrigen Datenleitungen ignoriert. Also hätte man nochmal 8 Datenleitungen für einen weiteren 8 bit-Prozessor

übrig. Die könnte man vielleicht für einen zweiten 68HC001 verwenden oder für einen 65C816. Dann wären auch 6502-Programmierer glücklich.

In dem Fall sollte man die unteren 64K natürlich unbenutzt lassen, um dort ein C64-ähnliches System einzubauen, inklusive Nachbauten des

SID, der dann natürlich höhere Taktfrequenzen abkönnen muß. Auch der serielle CBM-Bus muß dann unterstützt werden.

Ein 68K-Retro-System von Grund auf neu zu programmieren wäre natürlich eine Herausforderung, aber möglich. Und es würde keine Probleme mit

einem Software-Copyright geben. Bei der Programmierung des BASIC kann man sich am Sinclair QL oder am Kiwi Homebrew Computer orientieren.

Also, es ist einfach mal eine Überlegung, ob man auf diese Weise nicht mit geringen Kosten ein interessantes System auf die Beine stellen kann.

Vielleicht funktionieren die Amiga Custom Chips mit 8 bit ja gar nicht. Für alle, denen ein MEGA65 zu teuer ist, wäre das sicher eine interessante

Sache. Der Projektname wäre dann C500. Der Name ginge auch ganz gut bei der Internetsuche, denn da findet man hauptsächlich eine Canon EOS

mit diesem Namen.

Grüße von TeSoto.

Naja gut, dann funktioniert das wohl nicht.

Also die 68HC001 habe ich mir mal besorgt um wieder ein paar schöne Abstürze zu testen ;--)

Ich mag ja so herumgefrickel mit unsicheren Testversionen, habe mich auch lange mit Kickstart 1.4 alpha 15 beschäftigt.

Kickstart 0.7 auf dem A1000 hatte ich auch. Falls jemand fragt warum: Einfach nur so, aus Spaß am Kuriosen.

Allerdings hätte ich mal etwas, mit dem man so viel Spaß am Programmieren haben kann wie damals am C64.

Ich hatte mir mal den Color Maximite 2 gekauft. Hört sich ja ganz gut an, 400 oder 480 MHz ARM-Prozessor in BASIC

programmierbar. Aber effektiv war das ein Reinfall. Keine 9 Pin-Gameports, dafür drei Nunchuk-Anschlüsse der Wii.

PS/2-Tastatur nur englisch, kein ASCII oder PETSCII, keine Maus, VGA im Zeitalter von HDMI 16:9 und total bescheuerte

Auflösungen bis maximal 800x600. Diverse Auflösungen waren nicht mal im 4:3-Format. Floppy-Support gibt es natürlich

nicht. Ich habe die 480 MHz-Version bestellt und eine 400 MHz-Version bekommen. Damit lief die Demo von dem in BASIC

programmierten Wolfenstein 3D gleich ruckelig. Ich glaube ich habe 125 Euro bezahlt, das hat ganz schön gedauert, bis ich

das Geld zurückbekommen hatte. Und dann mußte ich das Teil noch nach England zurücksenden. Also nur Verlust gemacht,

womit hat sich meine Abneigung gegen teures FPGA-Krams weiter gefestigt hat. Der BASIC-Editor war im Vergleich zu den

Commodore-Editoren zu ungewohnt.

Der MEGA65 ist keine Option, denn er ist viel zu teuer und wird deshalb höchstwahrscheinlich das gleiche Schicksal erwarten

wie die SuperCPU: Es wird kaum Programmierer für den nativen Modus geben. Ich habe das Ding zwar lange im Auge gehabt,

aber mit einem 8-bit-Rechner ohne Software für 793,33 Euro wird sich das Ding nicht weiträumig verbreiten. Dazu kommt, daß

es Alternativen wie den Commander X16 und ähnliche gibt, die aber - wie früher - alle untereinander inkompatibel sind.

Wenn man ein Retro-System aufbauen will, daß sich weit verbreitet, muß man auf folgende Punkte achten:

- verbreitete Hardware

- einfache Reperaturmöglichkeiten

- geringe Hardwareanforderungen

- Retro-kompatibler Videoausgang, falls kein 16:9 HDMI

- Assembler-Programmierer vorhanden

- einfache Erstellung nativer Software in Assembler und BASIC

Und da kommt nur eine Grundlage in Frage: Der Amiga 500.

Es gibt ihn massenhaft, kompakt als A600 und groß als A2000. Dann noch das CDTV.

Beim C64 ist es ja gerade das Spannende, das das Ding so viele Fehler hat und man aus so geringer Hardware so viel heraus-

holen kann. Heutzutage wird alles Mögliche nachgebastelt, es muß doch möglich sein, aus der Hardware eines Amiga 500 einen

Commodore 128/65-ähnlichen Computer zu entwickeln, der sowohl in Assembler als auch in BASIC zu programmieren ist.

Klar, das System muß komplett von vorne angefangen werden. Aber es wurde genug Zeug von vorne angefangen oder optimiert.

Jetzt kennt man natürlich die Fehler der Commodore 8 bit-Betriebssysteme. Die kann man bei einem Neustart natürlich umgehen.

Das ROM hat 512 KByte, man muß sehen, was man einbaut. Kernal, BASIC, Monitor, Assembler. Etwas wie eine integrierte Action

Replay wäre natürlich klasse. Der C128 hat einen Sprite-Editor, weiß nicht ob sowas notwendig ist, dafür hat man ja DPaint.

Da müßte es dann direkten Support für .animbrush-Dateien geben. Diverse Retro-Dateiformate, auch vom C64, Koala-Pictures

etc. müssen direkt verwendet werden können. Support für Protracker-Module natürlich auch, das kann ja sogar der Color Maximite 2.

Der unterstützt auch andere MOD-Formate direkt von BASIC.

Hardwaremäßig stelle ich mir natürlich weitere bekannte Sachen vor. Zwei oder vier Nachbau-SID's, die auch höhere Taktfrequenzen

vertragen. Ein serieller IEC-CBM-Bus, damit man C64-Laufwerke anschließen und die Dateien übertragen kann. Die interne Floppy

muß natürlich auch die nötigen Formate können. Ein paar Sachen aus der heutigen Zeit wären natürlich nicht schlecht. Ein Hardware-

MP3-Decoder ähnlich wie der MAS-Player beispielsweise. Dann braucht man natürlich ein SD-Karten-Laufwerk. Wie man Laufwerke

einbinden sollte ist noch nicht ganz sicher. Wir kennen alle die Methode mit den Laufwerksnummern; nicht besonders benutzer-

freundlich, aber es funktioniert. Ein DOS oder ein GUI verbraucht viel Platz im ROM oder es belegt Speicherplatz auf Disk. Dadurch

würde die ganze Angelegenheit dann wieder langsam werden. Wenn der IEC-Bus implementiert wird und Laufwerke ab 8 anfangen,

könnten die vier Amiga-Floppies 4 bis 7 sein. 0 ist wieder der Bildschirm und 1 bis 3 andere Laufwerke wie SD oder CD (A570).

Auf einer Amiga-Tastatur LOAD"GFX-DEMO",4 einzugeben und dann dem Knarzen der Floppy zu lauschen ist eine tolle Vorstellung

Das Wichtigste ist aber, daß man den Computer einschaltet und sofort loslegen kann. Kein Warten auf Booten oder sonstwas. Beim

C128 habe ich mir im Kernal auch das Booten deaktiviert, das spart jede Menge Zeit, weil die 1571 nicht lange herumrappelt.

Zum Booten, Monitor, Action Replay oder BIOS wird wie beim C128 oder beim Mac beim Reset eine Taste gehalten.

Falls jemand mal so ein Ding programmieren will bekommt das ROM einen alternativen Schreibfehler: KARNEL.

Wenn man es nach Commodore-Standard Kernal nennen würde, findet man bei einer Suche im Internet nur C64-Zeugs.

Ja, das habe ich auch gedacht. Kiwi Homebrew Computer

Aber der ist ein weiteres Beispiel für Ansätze eines neuen Systems, daß keine Chance auf Verbreitung hat.

Was ich so gelesen habe ist schon ganz richtig. Also vergeßt den 68HC001, der ist nur für Experimente gedacht.

Genau wie der 68012 den ich hier liegen habe, ein 68010 mit 2 GB Adressraum. Gibt es als 68pin-PGA.

Den Mix aus 68HC001 und 65C816 hatte ich mal angebracht, um gleich zwei Gruppen von Codern ansprechen zu

können. Gemischte Architekturen haben ja nie richtig funktioniert, siehe C128, diverse CBM-Bürorechner mit 6809

und zusätzlichem Z80 oder 8080 oder den Power Macintosh 6100/66 mit zusätzlichem 486er. Einen anderen

Prozessor in einen C64 zu verpflanzen bringt auch nichts, da das nicht funktioniert und man weiterhin die Limita-

tionen in Grafik, Sound und Disk hat. Der Ärger mit dem Bankswitching hat den C128 im BASIC äußerst langsam

gemacht und es hat Programmierer abgeschreckt. Der C65 war wieder anders zu programmieren und dazu zum

C64 nicht kompatibel genug. Und eine Konkurrenz zum Amiga.

Ja, es müßte also ein Kickstart Replacement rein. Da müßten sich dann halt Leute dransetzen, die Amiga und die

8 bit Commodore's gut kennen - und die Fehler davon. Der Amiga ist ja im Vergleich zu den 8-Bittern relativ fehler-

frei. Der Karnel müßte dann gut geplant programmiert werden. Nicht alles zusammenquetschen, sondern Disk,

I/O, Grafik, Sound usw. sind getrennt und erweiterbar. Es müssen viele Grafikroutinen vorhanden sein, da müssen

die Leute aus der Demoszene ran. Fraktale Routinen zur automatisierten Erstellung von Landschaften wäre etwas,

was man für Spiele wie 'The Eidolon' oder 'Rescue on Fractalus' verwenden kann. Alle Grafikmodi müssen unterstützt

werden, inklusive HAM und EHB. Sprite's und BOB's ebenfalls, Copper und Blitter. Alles muß von BASIC aus verfügbar

sein, denn am BASIC V2 des C64 haben ja alle kritisiert, daß es die neue Hardware gar nicht nutzt. Es müssen auch

Routinen für die Anpassung von PAL und NTSC vorhanden sein, damit es da keine Probleme gibt.

Das System soll auch die Möglichkeiten der Demo-Competitions nutzen, wo sich die Menschen live treffen. Ich bin nicht

mobil und habe nie an irgendwelchen Demo-Parties teilgenommen, aber ich finde es wichtig, daß sich die Leute auch

nicht nur im Internet treffen. Das Betriebssystem sollte also für Mehrbenutzerbetrieb vorbereitet werden. Es sollten

vielleicht von Beginn an vier Gameports vorhanden sein. Das Betriebssystem soll auch zwei Mäuse unterstützen und

die alten seriellen Wacom-Grafiktabletts. Die sind nämlich äußerst günstig, erlauben aber neue Ideen zur Steuerung

von Spielen oder Software. Denkbar wäre auch eine Art Netzwerk, daß vielleicht 4096 User zuläßt und ebenfalls von

aus BASIC nutzbar ist. Der Sinclair QL hatte auch ein eigenes Netzwerk.

Hardware-Addons könnte man durch Plugin-Boards umsetzen, die in die DIP-Sockel kommen. Die müssen dann

natürlich selbst lötbar sein, damit sie günstig bleiben. Höchstens die Varianten für den A600 müßten vorgefertigt

sein, weil die ja auf die PLCC-Sockel gesteckt werden.

Als ich mir in den 90ern Bei Conrad Electronic die Action Replay MK III für den Amiga gekauft habe, war ich zuerst

total frustriert, weil ich von der C64-Version eine grafische Steuerung gewöhnt war. Aber es hat sich schnell heraus-

gestellt, daß die textbasierte Bedienung der MK III äußerst fllott vonstatten geht und sehr flexibel ist. Ich habe so

viel mit dem Teil gemacht, ich habe nur gute Erinnerungen an die Karte. Ich habe sie natürlich noch.

Das C64 AR MK6 konnte man nach dem Freezen doch mit Menüseiten und einfachen Tastendrücken steuern. Beim Amiga AR MK3

war ja nur ein blinkender Cursor da. Da mußte man erst help eingeben oder ins Handbuch schauen, um festzustellen, daß es noch

Menüs auf den F-Tasten gibt.

Quote from next_i

Frage zum C500: Sollen die Amiga Custom-Chips verwendet werden? Die finde ich nämlich auch nicht so leicht zu programmieren (wie auch das Amiga-System insgesamt).

Also, ich hatte damals tolle Zeiten mit meinem Amiga. Aber wenn ich mich heute manchmal dransetze und versuche, das Amiga-System programmieren zu lernen (Part 1 of n), verliere ich immer schnell die Lust und denke mir "Muß das noch sein?". Es ist halt ziemlich komplex und heute endgültig obsolet, in dem Sinne, daß es so nicht mehr wiederkommt.

Ja, natürlich sollen die Custom-Chips verwendet werden. Heutzutage könnte man zwar vielleicht FPGA-basierte Custom-Chips herstellen,

die in die Sockel von Agnus, Denise, Paula und Gary passen, aber dadurch wird die ganze Sache wieder teuer.

Und falls die Custom Chips schwer zu programmieren sind, soll ja eben eine richtig umfangreiche Sammlung an Routinen existieren, um

die gut nutzen zu können. Das macht die Nutzung eines solchen Systems gleich einfacher und standardisierter. Und man kann auch ein

BASIC darauf bauen. Ist jemandem bekannt, daß es für das SEGA Saturn ein BASIC gab? Das GAME BASIC. Das konnte die Hardware des

Saturn voll ausnutzen, hat alle Grafikmodi unterstützt und konnte auch umfangreiche Polygon-Funktionen. Aber es gab es nur in Japan,

deshalb hat es sich nicht durchgesetzt. Eric Chahi hat sich die Editoren für Another Wold auch in GFA-Basic geschrieben, und Another World

ist nun mal ein Meisterwerk. Also man kann mit ROM-Routinen und BASIC viel machen. Aber wenn man dann erst ewig lange laden muß,

bis man zum BASIC-Prompt kommt, macht das keinen Spaß. Die Editoren der anderen Amiga BASIC-Varianten haben auch keinen Direkt-

modus. Deshalb habe ich immer in einer Kombination aus AmigaDOS und ARexx programmiert.

Menügesteuertes BASIC war mir immer suspekt. Ich habe zwar brennend auf geoBASIC gewartet, aber kaum etwas damit gemacht. Heute

macht Programmieren gar keinen Spaß mehr. Ich habe mal mit RealBASIC auf dem Mac herumexperimentiert, aber man muß erst ein GUI

entwickeln, Variablen deklarieren, dann kann man irgendwann mal anfangen zu programmieren, dann wird man beim ersten Start vom

Debugger angemotzt, dann muß das Ganze durch den Compiler und nach Ewigkeiten kann man vielleicht mal etwas testen. Näh. Ich be-

nötige nicht viele Hilfsmittel. Einen ?UNDEF'D STATEMENT ERROR IN 472 manuell zu korrigieren ist für mich weniger frustrierend als auf

einen Debugger zu warten.

Als ich mir 1989 meinen C64 gebraucht gekauft habe, hatte ich zwei Diskettenboxen, zwei Joysticks und das Buch von Commodore. Einen

Assembler hatte ich nicht, auch keine Freunde die ebenfalls Interesse am Programmieren hätten. Also habe ich mich halt sehr intensiv mit

BASIC V2 beschäftigt und versucht, so gut wie möglich damit auszukommen. Wenn man Systemroutinen nutzt, kann man ja schon mehr

damit machen. Ich habe mir dann Stück für Stück jede GEOS-Software gekauft, aber mit einer 1541 kommt man nicht sehr weit. Eine 1581

habe ich bei uns im Dorf für 70 Mark bekommen, dann mußte eine geoRAM her. Mitte der 90er kam dann eine CMD HD dazu und dann noch

die Flash 8. Grafische Betriebssysteme haben immer hohe Ansprüche an die Hardware.

Wenn der MEGA65 zwischen 100 und 200 Euro kosten würde, wäre es kein Problem. Aber keine 800 Euro, das geht nicht. Und das wird Vielen

so gehen. Ich habe viele Ideen und kann gut planen. Und diese Planungen sind auch umsetzbar, denn meine Grundlage ist immer schnelle Ver-

breitung, Kompatibilität und niedrige Kosten. Ich habe nur nie jemanden gefunden, der ebenfalls so denkt und dann die nötigen Kenntnisse in

Hardware und Software hat. Es gäbe genügend Leute mit den notwendigen Kenntnissen, das ist keine Frage, aber irgendwie scheint niemand

Interesse daran haben, bestehende Hardware zu erweitern, ohne daß es viel kostet.

Die Flash 8 ist so ein Beispiel. Ich habe keine Möglichkeit gefunden, den MACH130 auszulesen. Ich habe sogar bei der Polizei in der KTU gefragt.

Es wäre kein Problem, den Chip irgendwie nachzugestalten. Dann bräuchte man im einfachsten Fall nur das Board nachbauen, und alle C64-

Benutzer hätten eine Beschleunigerkarte, die man sich selbst zusammenlöten kann. Es ist noch nicht mal ein neues Netzteil notwendig, das

alte reicht. Das Gerücht der Instabilität ist inzwischen erledigt, denn meine Flash 8 läuft jetzt mit 9.67 MHz. Eine 4000er-FOR...NEXT-Schleife

benötigt bei 1 MHz 252 TI-Cyclen, mit 9.67 MHz nur 25. Das ist eine zehnfache Beschleunigung. Die Flash 8 blendet die ersten 32K ihres ROMs

in Bank 31 des 65C816 ein. Ich hatte mal mit Arndt Dettke Kontakt aufgenommen, er könnte sich durchaus vorstellen, sein Tuned Simons' BASIC

dafür anzupassen. Wenn man es dann noch schaffen würde, den BASIC-Speicher in den hohen Bereich zu verschieben, hätte man knapp 1 MB

für BASIC frei. Aber nein, es sind nur die Nachteile der Flash 8 im Kopf geblieben und deshalb macht sich da niemand ran. Aber diese Leute haben

nie jahrelang damit gearbeitet. Ich schon, und ich kann nichts Negatives über die Karte sagen. Ich habe sogar in dem anderen Thread angeboten,

für knapp 30 Euro die Flash 8 zu überprüfen und mit aktuellen Komponenten auszustatten. Die habe ich bereits da. Selbst da hat sich niemand

gemeldet. Ich habe übrigens mal ein VDC-Board für den 65C816-Sockel vorgeplant. Das dürfte sehr einfach gehen, und man benötigt nur 5 ICs.

Den VDC 8563 gibt es sehr häuftig. Was noch fehlt, ist die Einbindung bei $D600/$D601 und daß er mit dem I/O-Bereich ausgeblendet werden

kann. Ich habe mich zwar am C128-Schaltplan orientiert, aber da fehlt halt noch was. Ich finde aber wieder niemanden, der mir dabei helfen

möchte.

Daß für den C64 optimierten Spiele und Demos mit der Flash 8 nicht laufen, ist ja klar. Aber ein BASIC, das zehn Mal so schnell ist wie das vom

C64 und die Inkompatibilitäten der Flash 8 einigermaßen ausbügelt, wäre schon viel wert. Und sie ist günstig. Die IC's sind so um die 40 Euro,

der teuerste ist der 65C816 mit knapp 15 Euro. Beim Board hängen die Kosten von der Anzahl ab. Die Idee mit der C65-Variante auf dem Amiga

500 hat den gleichen Ansatz, nur ein neues ROM und ein paar Hardware-Plugin-Boards zum selbst löten. Das macht die Sache günstig. Aber

die Leute wollen lieber alles mit FPGA, oder bauen ein C64-Board mit Röhren für den SID, was dann wieder mächtig teuer wird, aber effektiv

nichts Neues zu bieten hat.

Und damit haben wir genau das Problem. Erst neues Betriebssystem-ROM, dann mehr Speicher, dann Festplatte, dann gleich neuer Computer.

Bei welchem typischen 80'er-Jahre 8 bit-Homecomputer mit 6502 oder Z80 würde man genauso reden, wenn man schnell programmieren will?