Fettes Projekt: 50 Mhz im ST(E), 8 MB RAM, IDE in einer Erweiterung

[1ST1]

Mal sehen, was daraus wird: http://www.atari-forum.com/viewtopic.php?f=15&t=23657

Übrigens baugleich soll es auch für den Amiga erhältlich sein.

[Omikronman]

Früher brauchte man die Leistung, wollte man nicht Stunden oder Tage auf RayStart, Calamus oder eine Join-Operation in CAD 3D 2.0 warten, aber heute? Es gibt so viele Möglichkeiten, so viel viel viel schneller zu sein. Aber wer es braucht: Ich hatte mal ein ACC für den ST gemacht, das den Mauszeigerinterrupt (IPL 4) abschaltet. Das macht den ST 2 % schneller. RayStart braucht dann für ein Bild, das vorher 24 Stunden rechnete 20 Minuten weniger.

[Lynxman]

aber heute?

Retro Computer braucht man heute gar nicht mehr, wozu auch? Moderne Rechner können tatsächlich alles besser. 

Aber man macht es weil es geht. Oder man sich einen alten Traum verwirklichen will. etc pp 

Ich finde es gut das es solche Projekte gibt. Einen 8MHz ST geniesen, Dumm vor dem Fernseher hocken, Komasaufen und Leute an der S-Bahn-Haltestelle zusammenschlagen tun doch schon genug andere. 

[simonsunnyboy]

Solch ein Entwicklungsaufwand sollte eher in die Fireebee gehen. Denn kompatibeler als die Firebee wird solch ein Beschleuniger sicherlich nicht.

Sobald die Timingabhängigkeiten mit dem Systemtakt aufgebrochen werden, funktionieren viele reine ST Programme schon nnicht mehr, und der "sauber" Kram läuft auch auf GEM-kompatibelen wie der Firebee oder mit Aranym.

Bündelt lieber die Resourcen statt immer nur zu zersplittern.

[Omikronman]

Früher dachte ich, daß so Spiele mit 3D Grafik flüssiger laufen würden, aber in Wirklichkeit wurde die Grafik nicht flüssiger, sondern einfach insgesamt alles schneller, um nicht zu sagen unspielbar, falls das Spiel mit dem Beschleuniger überhaupt lief.

[1ST1]

Es ist wahrscheinlich kaum Aufwand, diese Beschleunigerkarte für den ST anzupassen, denn für den Amiga gibt es ja bereits einen Prototypen, also nur wenig Aufwand. Und wer lieber seinen originalen ST beschleunigen will, statt eine Firebee zu haben, der soll nur, finde ich jedenfalls.

Letztendlich könnte man so genauso gegen Firebee argumentieren, lieber alle Energie in Hatari stecken, schneller als Hatari auf einem aktuellen Core i7 Prozessor wird der Coldfire-Prozessor sicher nicht sein. Hatari kann gleichzeitig 100% (99,999999...%) kompatibel zu einem normalen ST/STE/TT/Falcon sein, und man könnte dem Hatari ganz neue interessante Fähigkeiten mit geben, z.B. eine NetUSBee-Emulation, die auf die LAN-Karte des Hosts bridget, so wie das VMware oder VirtualBox auch macht, Midi-over-LAN um Hataris auf verschiedenen PCs für Midicom oder Midimaze miteinander zu vernetzen, virtuelle Grafikkarte, die DirectX zur Darstellung nutzt, 68060 mit hunderten von MHz, usw. Hatari gibts ja auch für Linux, man könnte es wahrscheinlich auch auf einem 700 MHz ARM Ardiuno-Platinchen für 35 Euros laufen lassen...

[Lynxman]

Solch ein Entwicklungsaufwand sollte eher in die Fireebee gehen.

Wieso? Die Leute die die Firebee bauen verwirklichen das was sie wollen.
Die Jungs die das 50MHz Projekt durchziehen haben heir eben ihre Vorstellungen umgesetzt.
Ich finde es wesentlich besser das es mehr Auswahl gibt.
Mich reizt Firebee überhaupts nicht.
Aber einen ST aufrüsten finde ich sehr Reizvoll.
Bin gespannt wie das Projekt weitergeht.

[tost40]

Hallo,

ich habe die News-Meldung bereits auf www.amiga-news.de gelesen.

Ich bin schon lange auf der Suche nach einem
HBS 640 T 28.
Die 28 MHz sind deutlich spürbar.

Zeus68k könnte ein guter Nachfolger für die HBS sein.

Gruß Martin

[Omikronman]

Es braucht nicht immer eine schnellere CPU. Probiert mal Spacola bei 100 hz Flimmerfequenz, das rennt wie Sau. :-)

[1ST1]

Andererseits hast auch du recht, viele Software ist eben nur für einen 68000er mit 8 Mhz und max 512 MB ausgelegt, und läuft auf wesentlich schnellerer Hardware nicht mehr gescheit.

Deswegen sollten wir es mit den Kölnern halten. Dem eine singe Ühl ess dem andre singe Nachtijall.

[ToPeG]

Meinst du nicht 512Kb :-)

Die Speicherverwaltung ist beim Amiga etwas anderes. Dort laufen die Refeshzyklen über den Prozessor, gekoppelt an den Pageblank des Monitors. Im Atari gibt es dafür eine MCU. Das bedeutet sollte das Teil im ST funktionieren, braucht man einen Treiber, der das Refresh macht.
Alles was ich weiß kommt nur das TOS206 mit mehr als 4MB klar.
Ich habe mir schon einen heißen gesucht nach Informationen darüber wie man mehr als 4MB vernünftig anmeldet. (DMA Zugriffe darauf funktionieren ja nicht, der VideoSpeicher darf dort nicht sein, etc.)

[1ST1]

Richtig, ich meinte KB, aber wenn man tagtäglich mit Terrabytes zu tun hat, dann vertut man sich bei so kleinen Beträgen da schonmal... *grins*

Ja, für mehr als 4 MB braucht man TOS 2.04, und auf normaler 68000er Hardware gehen dann maximal 14 MB, weil da ohben drüber Memory mapped IO die ganze ST-Hardware liegt. Und der  Shifter kann nur auf die ersten 4 MB zugreifen.

Der zusätzliche Speicher dieser Erweiterung müsste eine eigene MMU haben, die den Speicher-Refresh durchführt. Dann wärs kein Problem.

[ToPeG]

Eine MCU ist nicht zwingend. Wie ich schon sagte mit dem Richtigen Treiber der sich in den V-Blank Vektor einhängt funktioniert das auch so. Viele FastRAM Erweiterungen für den Atari funktionieren so.

und auf normaler 68000er Hardware gehen dann maximal 14 MB, weil da ohben drüber Memory mapped IO die ganze ST-Hardware liegt. Und der  Shifter kann nur auf die ersten 4 MB zugreifen.

Das weiß ich alles. Ich weiß das man die Systemvariable "PHYSTOP" setzen muss, Aber wie verhindert man Das das TOS versucht DMA-Zugriffe darauf zu machen. Wie stellt man Löcher im RAM ein, z.B 1MB ST-Ram 8MB FastRAM, oder muss man dann die Startadresse richtig setzen? Wie verhindert man dass Der Shifter versucht aus dem FastRAM zu lesen zu lesen versucht? Usw. Möglicherweise stelle ich mir das ganze viel zu kompliziert vor und man muss wirklich nur "PHYSTOP" setzen. (und das System um den Refreshhandler erweitern.)