atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: wfoerster am Mo 12.12.2005, 22:19:45
-
Hallo,
ich schon wieder. Zunächst nochmals: super Community, tausend Dank. Ich habe das Geld für die zwei Protos zusammen. Nun werden diese, falls nichts dazwischenkommt (apropos: bisher habe ich keine negativen Feedbacks bezüglich der Hardware erhalten), ab 25. 7. bestellt. Ab Spätherbst werde ich dann, wenn genügend Interessenten vorhanden sind, eine Serie auflegen (via Inventronik GmbH). Ich würde allerdings in Frage stellen, was alles auf den Boards vorhanden sein soll. Ich möchte hierzu überhaupt keine Meinung äußern und warte einfach auf das Feedback von Euch.
Bis dann
Wolfgang
-
Hehe - wenn Du mir quasi einen Falcon in ein reines FPGA-Notebook verpackst, teste ich Dir Alles. :)
Nee - mal im Ernst:
was gibt es zu testen?
-
Hi,
erst mal vielen Dank für dieses Projekt. Klasse Idee!
Ich bin gerne bereit mitzuarbeiten und kann mit Soft- und Hardwarekenntnissen dienen. Wie Du vielleicht gesehen hast, hab ich auch so ein paar Ideen für Projekte. Habe hier im Board eine Diskussion über ne neue VME Karte angestossen. Leider mangelt es mir aus beruflichen Gründen aktuell an Zeit die Sache weiterzuverfolgen (wie die User sicher schon bemerkt haben). :(
Dennoch möchte ich das Projekt unterstützen wo ich kann.
Aus welcher Gegend kommst Du? Evtl. kann man sich ja mal treffen oder telefonieren?!
Gruß
Wolfgang
-
Momentan ist die Hardware in der Mache. Eckdaten:
8-fach Multilayer fertig platziert und entflochten. Festplatte gibt es keine mehr, dafuer eine CF-Card. Alle Atari typischen Schnittstellen bleiben erhalten. Zusätzlich SCSI, USB, Ethernet. Floppy nur noch extern, dafür eingebauter SD-Card Sockel. Audi-Codec ist eingebaut, DSP ist vorbereitet (wird in VHDL modelliert werden). Cartridge Port und Extension Port bleiben, aber mit veränderten Steckverbindern (die Originalen sind veraltet). PS2 Maus und Tastatur sind hardwaremaessig vorbereitet. Ein Powermanagement soll durch einen PIC Controller übernommen werden. Das Teil hat eine versorgungsspannung, d. h. alle benötigten Spannungen werden on-board erzeugt. Somit is das Din auch mal mit einem externen Akku zu betreiben. Momentan arbeite ich an der Modellierung eines modifizierten LCD-Controllers (STBook dient als Vorlage), so dass gewöhnliche LCDs mit 640x480 (monochrome) angeschlossen werden koennen. Die Masse der Leiterplatte: 240mm x 140mm, also kleiner als ein DIN-A4 Blatt.
People who are interested in an english description - please contact me.
Was gibt's zu tun? Ich habe die Festplatte durch eine CF-Card ersetzt. Hat das irgend jemand schon mal ausprobiert. Fuer die Ataris sind CF -Cards meiner Meinung nach ideal geeignet. Mit grossen Platten hat man sowieso immer Aerger und CF-Cards mit 512MB oder 1GB sind mittlerweile erschwinglich, fuer Ataris ohnehin schnell genug und lassen sich vermutlich auch gut formatieren. Warum also nicht weg mit den mechanischen Bauteilen? Spart im übrigen auch 'ne Menge Energie.
Das Powermanagement wird, wie erwaehnt, von einem PIC uebernommen. Waere dankbar, wenn jemand diese PIC-Programmierung uebernehmen koennte (am liebsten in C).
-
Hallo,
gibt es denn zu dem Projekt bereits Bilder oder Zeichnungen?
Wird das Board in ein ATX, mini ATX oder ITX Gehäuse passen?
Gruss Martin
-
Hi,
ich habe den Entwurf der Leiterplatte als Bild exportiert. Ich hoffe, dass er hier sichtbar wird. Falls nicht. versuche ich es nochmals. Wie Ihr seht, bin ich erst Junior-Mitglied und kenne mich noch nicht so gut aus :)
-
Hallo,
ist einmal daran gedacht, das Board mit einem 68030 oder 68040er Prozessor zu betreiben?
Wenn der DSP doch schon vorgesehen ist, wäre dass doch naheliegend.
Gruss Martin
-
Einen kompletten Falcon mit verbesserter Grafik sowie Netzwerk fände ich definiv gut. :)
Aber das dürfte noch mehr Arbeit sein.
-
fpga rule, how fast can this hardware be emulated ?
Would be cool to have a 1000 Mhz stbook clone 8)
-
I think a 1000Mhz clone is not a matter for the near future. I think it depends on the manpower say contributions to this project. In principle the code could be speed up significantly. But as you know, a lot of software is written for the original clock frequency.
-
Die Clone Hardware auf diesem Bild wird wohl nicht die letzte sein. Prinzipiell ist es mit dieser aber möglich, DSP Funktionalität und 680xx Prozessoren nachzubilden. Der Prozessor links auf dem Bild ist momentan dazu gedacht, die Kiste erst einmal grundlegend in Betrieb zu bekommen. In der Praxis bedeutet eine Inbetriebnahme einer komplexen Hardware wie etwa einem ST oder STe erst einmal nogo. Daher müsen zuerst GLUE, MMU, DMA, FDC, ACIA, SOUND, SHIFTER, MFP mit dem 68000 Prozessor in Betrieb genommen werden. Erst wenn alle diese Bausteine stabil laufen, wird der 68K durch ein in VHDL modelliertes System ersetzt. Der DSP ebenfalls, ab diesem Zeitpunkt ist es unerheblich, ob ein 68K oder ein 68K30 implementiert wird. Ich denke allerdings, dass dies einerseits noch eine ganze Zeit dauern wird und andererseits die bestehende Hardware für einen 68K plus DSP zu klein wird (FPGA). Aber bis dahin (der FPGA Markt explodiert gerade), sollten preisgünstige Chips am arkt sein. Dann wird es ein Hardware-Update geben.
Es gibt übrigens eine Ur-Version dieser Hardware (nicht nur als Design). Ein Bild werde ich demnächst mal reinhängen.
W.
-
Hallo,
ab dem kommenden Montag wird es unter www.experiment-s.de die ersten downloads geben. Ich bin auf ein Feedback gespannt / angewiesen. Hardware ist geplant. Demnächst mehr.
-
Hallo,
die angegebene Webseite wird leider nicht richtig
dargestellt oder defekt.
Ich habe es in der Zwischenzeit mit mehreren
Computern und verschiednen Browsern versucht.
Gruss Martin
-
Hallo,
ich finde das Projekt sehr interessant.
Es ist wohl zur Zeit die realististe Möglichkeit neue
Atari komptible Hardware zu bekommen.
Vor einigen Tagen war auf der www.amiga-news.de
zu lesen, dass der Amiga 500 auf FPGA Basis
bereits recht gut läuft.
Das Konzept mit diesen Chips ist schon faszinierend.
Vor allem die Erweiterbarkeit.
Ich hoffe, die Entwunklung geht weiter gut voran.
Gruss Martin
-
Hallo,
ich arbeite stetig an der Verbesserung. Bin wieder mal zu spät mit den Downloads. Der Stand ist mittlerweile ganz zufriedenstellend. Von den zentralen Chips laufen die meisten (ausser CPU) sehr stabil. Momentan wird der Soundchip in einer sehr einfachen Variante ohne DA-Wandler implementiert. Danach MFP, parallel dazu der Blitter und dann die CPU.
Meiner Meinung nach ist ein IP Core die absolut einzige Möglichkeit Ataris am Leben zu erhalten. Ich habe auch einen Sack voll alte Hardware. Leider wird die auch nicht besser. Und ein Core hat schon seine Vorteile. Bsp: kurz ein Register einprogrammiert und schon läuft der selbergemachte Floppy Controller mit FM, MFM, DD und HD.
Die Hardware wird es dieses Jahr noch geben (Bild s. o.).
Wer weitere Infos braucht: einfach mailen oder www.experiment-s.de (habe ich aufgrund der intensiven Core Entwicklung etwas vernachlässigt). Über Feedbacks freue ich mich immer.
Viele Grüße
Wolfgang
-
Hallo,
ich hab mir mal gerade Deine Homepage angeschaut.
Wow!
Du bist ja schon sehr weit gekommen.
Wenn Die Hardware tatsächlich dieses Jahr noch fertig wird... :) :) :)
Ich bin schon sehr gespannt!
Gruss Martin
-
Hallo,
ich wollte mal Fragen wie den der momentane Stand eines Mainboards ist, das es ein Update der VHDL Beschreibung gab habe ich gelesen aber wie schauts denn mit einem Board aus.
TSchau Ingo
-
Hallo,
die Hardware ist in einer Version III in der Entwurfsphase. Version II ist nicht gebaut worden. Auch Version III, die unter anderem Hardware für ACSI, SCSI, USB20, TCP/IP, CF-Cards und SD-Cards sowie PS/2 Maus und Tastatur unterstützt dürfte nicht umsonst zu produzieren sein. Ich werde mal sammeln, wer Interesse hat. Das Teil wird aber vermutlich 200€ oder mehr kosten, da alleine das Cyclone FPGA 70€ kostet und die Leiterplatte ein 8-fach Layer sein wird.
Ich stelle den Entwurf in Kürze vor.
-
Hallo,
na das klingt ja richtig gut. Ich bin auf jedenfall dabei mal schauen vielleicht würde ich auch mehrere nehmen. Bevor ich aber weitere Fragen stelle, möchte deine Vorstellung abwarten.
Tschau Ingo
Tschau Ingo
-
Bin auch stark interessiert. :)
-
Hört sich sehr interessant an. Also eventuell hätte ich auch Interesse
-
Hallo wfoerster,
ich habe großes Interesse an einem Board.
Gruss Martin
-
Ich auch ;)
-
Hallo,
ich bin auch dabei!!!
Bei 200+ Euro kann ich gleich mal anfangen zu sparen ... also keine Süßigkeiten und kein Bier mehr ... ist eh gesünder :-)
Gruß Heinz Schmidt
-
Hallo,
sehr cooles Projekt! Ich nehme auch ein Board.
Viele Grüße!
-
Hallo,
200 Euro (oder mehr) ist natürlich schon ein kleines Sümmchen. Aber Interesse besteht auf jeden Fall, sofern ich es zum Erscheinungszeitpunkt aufbringen kann.
Gruß,
Dennis
-
Hi!
Gibt es schon Neuigkeiten? :)
-
Keine Hektik, was lange wehrt wehrt Gut :-P
TSchau Ingo
-
Hi,
es gibt folgende Neuigkeiten: Die Leiterplatte für das System - ein 8-fach-Layer ist entworfen. Momentan laufen Tests an der CPU. Diese gestalten sich allerdings aufwändig, da die ca. 100 verschiedenen Befehle mit im Schnitt zehn Parametern sehr viele Möglichkeiten ergeben. Die CPU hat momentan noch viele Fehler. Daher wird diese Phase noch ein Weilchen dauern. Ich werde am 1. 4. auf experiment-s das neue System vorstellen und dann mal überlegen, wie die ersten beiden Prototypen zur Evaluierung hergestellt werden können.
Bis dann
Wolfgang
-
Hallo wfoerster,
- wfoerster ->
dann mal überlegen, wie die ersten beiden Prototypen zur Evaluierung hergestellt werden können ...
---
Vielleicht wäre es eine gute Idee diese Überlegungen auch gleichzeitig hier im Forum unter Hardware zu überlegen ...
Hochachtungsvoll
Frank Lukas
-
Hallo Frank,
er hat eine Firma, die sowas Professional macht!!.
TSchau Ingo
-
Hallo Leute,
ich habe jetzt einige male mit Wolgang hin und her Diskutiert, und der Punkt ist jetzt so das Wolfgang vor einem Prototyp steht. Er würde gern 2 Stück bauen lassen. Dies würde jedoch ca. 1000€ Kosten, jetzt kommt der Appel an die Gemeinde wer möchte Helfen?????
Ich sehe der sache Positiv entgegen. Denn er hat sehr viel Entwicklung darein gesteckt, und das FPGA Projekt denke ich ist die Zukunft. Ich habe mir das Projekt und sein Board angeschaut, und er hat wirklich versucht all das zu Implementieren was viele in Mühevoller Arbeit versuchen per Hand nachzubauen. Selbst VGA möchte er mit in denn FPGA mit Integrieren. Ich denke wenn die Prototypen stehen, kann er auch Optimierungen am Core durchführen und natürlich um Funktionen erweitern.
Wolfgang wird in einigen Tagen sein Projekt hier nocheinmal selbst vorstellen, so das ihr euch selbst ein Bild machen könnt. Ich bitte diejenigen die Wolfgang unterstützen möchte, mit ihm Kontakt aufzunehmen.
Tschau Ingo
-
Mit Paypal kann man Spenden entgegen nehmen. Ich habe das mal bei einem kleinen Projekt von mir gemacht und brauchte eigentlich nur 480 Euro für eine SOftwarelizenz und es kamen fast 2000 Euro zusammen. Der Vorteil ist, dass auch Atarianer aus dem Ausland einfach spenden können. Und auch kleine Beträge bringen einem etwas:)
-
Hi Ihr,
also spendentechnisch beteilige ich mich da auf jedenfall auch.
gruss karsten
-
Gab's schon Klarheit bzgl. Spenden? 100x10€ oder vielleicht auch 50x20€ klingt gut, oder werden sich doch nur etwa 10 Leute beteiligen? Also, bis etwa 25 € wäre ich wohl dabei...
Hehe - wenn Du mir quasi einen Falcon in ein reines FPGA-Notebook verpackst, teste ich Dir Alles. :)
Nee - mal im Ernst:
was gibt es zu testen?
Das war zwar wohl leider nicht Ernst, aber was wäre denn realistisch? Ein Notebook, dass man mal in eine Falcon-Konfiguration und mal in eine beliebige andere Atari-Konfiguration versetzen könnte wäre unglaublich genial. Aber zu den realistischen Varianten, wo kann man sich dazu mal was im Netz ansehen? Wenn ich z.B. auf die Homepage von Altera gehe, dann finde ich zwar tolle Abbildungen von den Chips, aber um ehrlich zu sein will ich die nicht wie wfoerster auf den Bildern seiner Internetseite wild zusammenkabeln. Das war ja wohl auch nur für die Entwicklung, wie aber sähe das fertige Produkt aus??
Auf Wiki habe ich übrigens gelesen, dass diese Chips aktuell so um die 600 MHz hinbekommen. Mit passender Konfiguration, kann das wirklich bedeuten einen 68040er mit 600 MHz, oder geht da irgendwo Overhead verloren, so dass man effektiv nicht mal auf die Original-Performance kommt? In letzterem Fall muss man das ganze dann wohl doch eher als Emulation in einer Mogelpackung ansehen, und nicht als echte Hardware.
An meinen Fragen seht ihr, dass ich hoch interessiert bin, aber keine Ahnung habe. Würde mich freuen, wenn ihr mir bzgl. der Grundlagen einiges klarer machen könntet.
-
Hallo,
ich bin ab und an mit Wolfgang in Kontakt, und er meint das schon die 68000er Emulierte CPU schneller sei als die Originale, man muß sich vor Augen halten das der gesamte STE mit nur einem FPGA zusammen gesetzt ist. Aber Wolfgang will sich in den nächsten Tagen sowieso mal melden und seinen Stand Präsentieren. Denn Entwurf des mainboard habe ich schon gesehen.
TSchau Ingo
-
Also für mich ist das eine klare Sache. An Spenden im erträglichen Bereich beteilige ich mich gerne. Dafür freue ich mich schon auf den Tag, an dem das erste Geräte vorführbereit ist.
Auf jeden Fall muss eine Präsentation vor Publikum stattfinden. Dort stehe ich dann ganz vorne in der ersten Reihe. ;D
Gruß,
Dennis 8)
-
Spenden würde ich für so eine Sache auch. Mit 100 Euro könnte ich jetzt auch schon dienen wenn es die Sache voranbringt. Es bleibt halt aus Erfahrung immer das Gefühl dass vieles mit sehr großer Euphorie angepackt wird und dann leider im Nirwana verschwindet.
Wie gesagt wenn sich bei mir jemand meldet und für dieses Projekt etwas Kleingeld braucht; mit 100 Euro könnte ich jetzt schon dienen.
Muck
-
Guten Morgen an alle,
nun möchte ich mich nach längerer Zeit hier auch mal wieder zu Wort melden. Ich habe die letzten Wochen intensiv an der neuen Configware gearbeitet, insbesondere an dem 68000er-Clone. Der Stand ist nun so, dass ich an dieser Stelle die für den Juni angekündigte Veröffentlichung der Sourcen schon mal ankündigen möchte. Die FPGA Modellierung umfasst gegenüber 2K6B einige Zusätze wie SCSI-ACSI-Bridge und auch Dinge, die für die neue Hardware notwendig sind (Bootloader..). Alles nachzulesen in den Readme Dateien. Ferner habe ich, wie bereits vor längerer Zeit angekündigt, die Hardware so weit, dass sie (bis auf eventuelle Kleinere Änderungen) herstellbar ist. Ich werde das Schaltbild für das Board noch heute auf meinem Server (www.experiment-s.de) ablegen. Der Schaltplan ist mit pre-1 gekennzeichnet und somit noch nicht die endgültige Variante.
Ich sehe ab und an mal die Bemerkung, dass Projekte öfters mit Elan angegangen werden und dann stecken bleiben. Dies wird im Falle dieses Projekts definitiv nicht so sein. Grund: der Core ist bereits so gut wie fertig, die Leiterplatte ist entflechtet, die Bauteile sind modern und verfügbar und - last but not least - habe ich mich bewusst aus Diskussionen heraus gehalten, die sich, verständlicherweise, um viele Wünsche bezüglich der neuen Hardware drehen. Auch hierzu werde ich ein Dokument veröffentlichen, welches meine Sichtweise darlegt. Kurz gesagt: erst mal muss die Erstinbetriebnahme gestemmt werden und wenn die Hardware mit dem Core dann mal läuft, stehen Tür und Tor für jegliche Erweiterungen offen.
Wie gehts nun weiter? Ich werde den Core auf dem Server ablegen, Schaltbild auch und Infos zu allem. Dann werde ich mich um die Realisierung der ersten beiden Prototypen kümmern. Es sind 8-fach Layer in etwa DIN-A4 Größe. Da ich bereits viel Geld und sehr viel Zeit investiert habe, möchte ich diejenigen um Mithilfe bitten, die an dem Projekt interessiert sind. Und zwar auf die folgende Weise:
1. Ich habe eine Paypal-Seite eingerichtet (noch rudimentär), welche die Herstellung der beiden Prototypen ermöglichen soll. Ich freue mich über jeden Cent. Ich rechne mit etwa 1000€ für die beiden Protos.
2. Das Schaltbild soll als Grundlage zu einer Diskussion dienen. Ich würde bis etwa Ende Juli oder falls die Finanzierung bis dahin noch nicht steht auch länger konstruktive Vorschläge entgegennehmen, die ich dann noch einarbeiten werde. Geplant ist ein Update der FPGA-Configware und der Betriebssystem-Firmware via USB-Schnittstelle, so dass jeder das auch selber machen kann. Für die Configware ist momentan noch ein Spezialadapter notwendig.
3. Ich bin auch an Personen interessiert, die in irgend einer Weise helfen können wie z. B. Anregungen die Webseite auszubauen, Dokumentation - die ich nicht allumfänglich selber bereitstellen kann - da ich so weit im Projekt stecke, dass Betriebsblindheit vorherrscht :), FPGA-Tester, die die Möglichkeit haben, an FPGA Evaluation Boards Teile des Cores auszutesten, PIC und ATMEL erfahrene Leute usw.
So ich denke, das war's für's erste. Ich werde mich bei Gelegenheit wieder melden und freu' mich schon auf die ersten Lebenszeichen der neuen Boards.
Ich hoffe, dass ich Euch mit diesem Projekt ein wenig Freude bereiten werde, obwohl momentan natürlich die Hardware erst mal nur zweifach existieren wird.
Bis demnächst und Grüße an Euch alle
Wolfgang
-
Hallo,
zunächst möchte ich mich bei Wolfgang für seine Arbeit bedanken.
Gern würde ich das Projekt aktiv unterstützen, leider mangelt es mir jedoch an der nötigen (Frei)Zeit. Deshalb habe ich soeben 500 EUR gespendet und hoffe, dass dies das Projekt weiterbringt.
Gruß
Wolfgang
-
Hallo Wolfgang,
das sind ja sehr gute Neuigkeiten.
Gruss Martin
-
Das Ganze finde ich klasse und wie versprochen überweise ich 100 Euro.
Günter
-
Hallo zusammen,
zunächst einmal vielen Dank für die prompte Unterstützung. Es sieht so aus, als ob die Hardware ab Ende Juli realisiert werden kann (es fehlt nur noch ein wenig). Ich habe heute Abend die Configware 2K7A auf den Server www.experiment-s.de gelegt. Genauere Infos siehe Readme Files.
Ich freue mich auf Vorschläge und Feedback von Euch.
Einen schönen Abend und viel Spaß beim Stöbern im Code.
Wolfgang
-
Mein unterstützung ist auch an Wolfgang raus.
TSchau Ingo
-
Hi Zusammen,
Ihr seid super. Das Geld für die beiden Protos ist zusammengekommen. Nun werde ich, falls keine ernsthaften Einwände kommen, die Leiterplatten ab 25. 7. 2007 bestellen. Ab Herbst möchte ich eine Serie auflegen (via Inventronik GmbH), wenn genügend Interessenten vorhanden sind. Die beiden Prototypen verfügen über fast alle bisher von Atari verwendeten Schnittstellen. Dies könnte sich aber in Zukunft ändern und in der Serie bereits berücksichtigt werden. Daher habe ich 'ne Umfrage formuliert und würde mich über reges Feedback freuen.
Bis demnächst
Wolfgang
-
Hallo,
na das klingt doch super. Freu mich schon auf erste berichte von der Hardware.
TSchau Ingo
-
Hallo,
dann viel Erfolg für die Prototypen! Bin schon sehr gespannt auf erste Ergebnisse.
Eine Beteiligung der Community in Form einer Umfrage finde ich klasse. Ich hab auch gleich mitgemacht, obwohl die maximal fünf Optionen schon eine Einschränkung sind. Eigentlich wollte ich noch "Mehr Speicher" nehmen, aber da ich sowieso nicht weiß wie viel Speicher aktuell geplant ist, konnte ich das auch streichen. Ethernet habe ich auch nicht angekreuzt, dabei fände ich eigentlich sogar WLAN gut und wichtig!
Meine Auswahl geht jetzt jedenfalls eher in die Richtung, dass man damit ein ordentliches Notebook hat, idealerweise Falcon-kompatibel.
Es stellt sich dabei natürlich allgemein die Frage, wohin man mit dieser Entwicklung gehen will. Es ist ja eine ganz allgemeine Frage in der Atari-Gemeinde, wie man Hardware-mäßig vorgehen soll. Zum einen kann man sich auf den Standpunkt stellen, dass man die alten Ataris nur genauso benutzen sollte, wie sie ursprünglich waren. Alternativ möchte man in irgendeiner Form die Möglichkeiten über die ursprünglichen Grenzen hinweg erweitern. Letztere Variante ist offensichtlich das Ziel des FPGA-Clones. Über die verschiedenen Möglichkeiten zur Erweiterung gibt es einen netten, nicht mehr ganz aktuellen Kommentar auf Atari-Source.org: http://atari-source.org/?q=node/14 (http://atari-source.org/?q=node/14). Dort werden Emulation, Clone und Upgrade-Board als prinzipielle Möglichkeiten miteinander verglichen. Ein Upgrade-Board wird als die beste Möglichkeit angesehen, und zwar mit der Begründung, dass dadurch die größtmögliche Kompatibilität erreicht werden kann. Und das sollte durchaus ein wichtiges Ziel sein. Warum setzen wir dann trotzdem auf einen Clone? Die Atari-Gemeinde ist klein, und wir brauchen keine Zersplitterung. Was also versprechen wir - die vielleicht schon Ende dieses Jahres ein ST-kompatibles Notebook in den Händen halten - uns von diesem Gerät?
Also, mit meinem Atari mache ich zwei Sachen gerne. Zum einen spiele ich gerne mit meinem ST. Von meinen drei Lieblingsspielen Dungeon Master, Elite und Populous sollte es mindestens eins tun, besser natürlich alle. DBug patcht ja z.Z. alle möglichen Spiele auf Falcon-Lauffähigkeit und Festplatten-Installation. Ich habe die Hoffnung, dass zumindest diese Versionen auf dem FPGA-Clone laufen werden. Allerdings frage ich mich noch, welchen Vorteil man davon hat, diese auf dem FPGA-Clone laufen zu lassen. Die Emulatoren für PCs sind inzwischen so gut, dass man auch dort alles in Top-Qualität spielen kann. Ich habe also schon die Möglichkeit, diese Spiele auf einem Laptop zu spielen. Da ich viel auf Dienstreise bin, gibt es für mich keine Alternative zum Laptop, ich kann ja keinen echten Atari mitnehmen ;)
Zum anderen programmiere ich gerne, und am Atari beginne ich gerade damit, vielleicht mal ein kleines Demo hinzubekommen. Mit anderen Worten, eine nette Entwicklungsumgebung würde ich gerne irgendwie zum Laufen kriegen. Aber auch kann man sich fragen, ob es das nicht viel besser entweder durch Emulation oder durch einen entsprechend ausgestatteten Falcon gibt.
Andere Leute werden andere Wünsche an den FPGA-Clone haben. Die Frage bleibt aber, was bietet der FPGA-Clone besser oder mindestens gleich gut zu den anderen Upgrade-Möglichkeiten.
Weswegen ich trotz dieser Zweifel für den FPGA-Clone bin ist, weil ich glaube, dass bei den Upgrade-Boards das Ende der Fahnenstange jetzt oder bald erreicht ist. Auch wenn man mit FPGA sicher nicht annähernd mit einem 100 MHz 68060er (CT63) mithalten kann, auf lange Sicht dürfte die Entwicklung dafür weitergehen. Und außerdem, Upgrade hin oder her, einen ordentlichen Laptop habe ich damit immer noch nicht. Naja, und gegenüber Emulation erhoffe ich mir "mehr Atari-Feeling".
Wobei ich mir noch nicht sicher bin, was man an Leistungsfähigkeit zu welchem Preis von dem FPGA-Clone bekommen kann. Ich hab mir mal diverse VHDL-Tutorials angesehen (quergelesen). Dort steht oftmals, dass man im Vergleich zum herkömmlichen Programmieren den Unterschied sehen müßte, dass eine Erweiterung nicht längere Laufzeit sondern mehr Platz (für Logik-Elemente) bedeutet. Darf ich das jetzt doch so interpretieren, dass wir einen 550 MHz Atari bekommen?? :o Klang bisher eigentlich nicht so...
Und zu dem Preis, was erwarten wir denn für das fertige Gerät, und wieviel würde es z.B. extra kosten, wenn man da WLAN eingebaut haben will?
So, das soll dann erstmal reichen ;) Wäre froh, wenn wir hier eine nette Diskussion über die Zukunft des FPGA-Clones hinbekommen könnten. Das ist ja sicherlich auch von Wolfgang mit seiner Umfrage bezweckt.
Ciao
Claus
-
Hallo TiggyTamal,
ich glaube du hast bei diesem Projekt etwas falsch verstanden. Wolgang Förster hat nie geplant ein neues Rechner System aufzusetzen sondern er möchte vorerst eine STE Hardware vollständig ersetzen. Ich sehe das so das sie alte Hardware in den nächsten jahren die haltbarkeitsgrenzen übersteigen (auf jedenfall der TT). Und Wolfgangs ansatz war einen ersatz auf FPGA Basis zu schaffen. Was ihm ja auch schon mehrere Jahre Arbeit bescherd hat. Er ist jetzt auf dem Punkt wo er einen ersten Prototyp fertigen lassen kann um den IP-Core zu testen. Der vorteil eines IP-Cores liegt darin das er er ohne weiteres Erweitert und erändert werden kann. Er hat woll auch dafür möglichkeiten geschaffen das weitere Schnittstellen die eventuell dafür benötigt werden nachgerüstet werden können.
Wenn man nun einen STE nachbaut macht es natürlich auch Sinn bestimmte erweiterungen die eh jeder an seinem Atari dran hat gleich mit zu Integrieren und das war eigentlich der Hauptpunkt der Umfrage, welche dinge sinn machen jetzt mit zu Integreieren und welche Später.
So ich denke das Wolfgang auch ab und an noch was Schreiben wird.
TSchau ingo
-
Hallo tuxie,
vielen Dank für deine schnelle Antwort. Eigentlich hatte ich gehofft, nichts falsch verstanden zu habe, einfach aus dem Grund, dass ich trotz mehrfachem Lesens der Informationen hier in diesem Thread sowie auf Wolfgangs Homepage immer noch nahezu nichts verstanden hatte. Nach dem x-ten Lesen hatte ich aber tatsächlich auch verstanden, dass es zumindest nicht in erster Linie um ein fertiges System geht, sondern "nur" um das Board. Zu diesem schrieb Wolfgang aber selber folgendes:
Die Leiterplatte ist im Formfaktor und in der Wahl der Bauteile so kompakt wie moeglich gehalten. Somit ist eine Verwendung in Verbindung mit LCDs auch als Notebook denkbar.
Ich befürchte sehr wohl, dass Wolfgang nur das Board zur Verfügung stellen will. Aber prinzipiell kann man (oder irgendjemand für einen) dieses Board in einem Notebook verbauen. Und damit hätte man ein 100% ST(E?) kompatibles Notebook, und somit sehr wohl ein komplettes Rechnersystem. So deute ich jedenfalls diese Aussagen. Es ist aber nur meine Deutung, und nicht mein festes Wissen über das Projekt. Wäre aber schön, wenn wir durch unsere Diskussion die Vermutungen durch Wissen ersetzen könnten. Denn ich glaube, dass bei der Mehrheit der Leser eher Unklarheit über den genauen Inhalt des Projekts besteht. Und Leser gibt es eine ganze Menge, mit fast 3000 Aufrufen wird dieser Thread in Kürze zum zweitmeistgelesenen Thread des ganzen Forums!
Ich habe übrigens durchaus mit Bedacht in der Umfrage für "Mechanik zum Board" und "Farb-TFT" gestimmt, in der Hoffnung, dass das als "ich will ein fertiges Notebook" gewertet wird.
Das manch andere Aussage von mir eher irgendwo zwischen utopisch oder gar unrealistisch anzusehen ist, ist mir schon klar. Auch wenn ich trotzdem gerne einen 550 MHz Falcon Notebook mit WLAN, USB und allem möglichen will ;D Für den Anfang wäre ich sehr zufrieden mit einem anfangs sicher etwas buggy ST Notebook. Mit einem Board hingegen kann ich nicht viel anfangen, dafür bin ich zu sehr Theoretiker. So liegt bei mir zu Hause noch ein Jamma-Board mit Flying Shark und Bubble Bobble, aber zum Laufen bekomme ich das die nächsten 10 Jahre nicht.
Viele Grüße
Ciao
Claus
-
Hallo,
also momentan handelt es sich in der Tat um ein Board, was dann in ein gehäuse gebaut werden kann. Wobei ja nicht ausgeschlossen ist das man dafür noch eins Anfertigt oder Anfertigen läßt. Von der Größe her könnte man das Suska Board schon in ein Notebook verwandeln. LCD Anschluß hat er ja auch mit vor gesehen. Ist nur die Frage wer kann Preisgünstig bzw. bezahlbar ein Gehäuse mit allem drum herrum bauen, auch nicht nur in einzelanfertigungen.
Man kann also sagen das das SUSKA Board ein Atari STE Clone ist mit allen Funktionen des STE´s. Ich denke das man dieses Board auch ohne weiteres in ein STE gehäuse einbauen könnte.
Er nutzt eben halt für die umsetzung der Custom Chips die im ST verbaut sind die FPGA Technik.
Tschau Ingo
-
Nochmal hallo tuxie,
was versprichst du dir persönlich denn von dem Board? So wie du involviert bist macht es den Anschein, als ob du durchaus Interesse hättest, im Herbst eins abzunehmen. Und dann? Würdest du es benutzen, oder nur zur Sicherheit kaufen - falls andere Hardware kaputt geht - und erstmal in den Schrank stellen? Wenn du es benutzen willst, wofür?
Viele Grüße
Ciao
Claus
-
Es wäre definitiv eine zuverlässige Hardware für kommende Jahre, um alte ST-Spiele spielen zu können, um Chiptunes zu hören und um ein wenig zu surfen. ;D
-
Egal wofür, ich würde gerne schon mal eins bestellen. ;)
Gruß,
Dennis 8)
-
Hallo,
ja so ein neues Board mit Ethernet, ET4000 und einer 68040er CPU-Karte
dass wärs! :D :-*
Gruss Martin
-
Hallo,
wie angekündigt, sind nun die beiden Prototypen-Leiterplatten in der Fertigung. Ferienbedingt werden sie allerdings erst in der zweiten Augusthälfte geliefert. Anschließend folgt die Bestückung und dann gibt's hier an dieser Stelle ein Bild eines der beiden rekonfigurierbaren ATA-Clones.
Allen ein schönes Wochenende und einen angenehmen Sommer.
Grüße aus Stuttgart
Wolfgang
-
Hallo Wolfgang,
bin schon gespannt auf das Bild, und vor allem auch auf Aussagen von dir, ob mit den Prototypen alles gut klappt, oder ob es unvorhergesehene Probleme gibt.
In der Hoffnung, dass die beiden Teile viel versprechend funktionieren, so könnte/müßte man anschließend wohl nochmal intensiver in die Diskussion einsteigen, wie es jetzt weitergehen soll. Spätestens dann sollte man also mal drüber nachdenken, wie z.B. die Umfrage interpretiert werden kann. Wie schonmal angesprochen wäre es dafür sicher hilfreich zu wissen, was wir eigentlich mit dem Gerät erreichen wollen (so es denn wirklich ein vollständiges Gerät wird). Und das wiederum mag man unterschiedlich beurteilen, je nach Erfolg der Prototypen. Wenn es da zu größeren Problemen kommt, so wird man hinterher sicher froh sein müssen, überhaupt ein Minimalsystem zum Laufen zu bekommen. Wünschen würden wir uns ansonsten natürlich, dass möglichst viele der diskutierten Erweiterungen (natürlich zu einem möglichst niedrigen Preis) berücksichtigt werden ::)
Wenn durch die Prototypen also etwas mehr Klarheit darüber besteht, wo wir jetzt stehen, so kannst du (Wolfgang) vielleicht auch nochmal etwas zu deinen Vorstellungen über das weitere Vorgehen sagen. Also z.B. auch zu den Themen:
- einzelnes Board vs. vollständiges Gerät (z.B. Laptop)
- was bedeuten eigentlich die einzelnen Punkte der Umfrage? Was bedeutet es, wenn wir z.B. auf die Core-Konfiguration mittels RS232/USB verzichten? Wir sehen natürlich nur die bekannten Themen (z.B. ET4000), aber du hast sicherlich einen besseren Einblick, ob bei einem FPGA-Clone nicht vielleicht etwas ganz anderes von entscheidender Bedeutung ist
Viele Grüße (aber welchen Sommer meinst du ???)
Ciao
Claus
-
Hi Claus,
ich bin selber gespannt. Wir haben in unserer Inventronik GmbH Erfahrungen mit einer derartigen Technik. Daher glaube ich nicht, dass es gravierende Probleme gibt. Es gibt nur wenige Ursachen, die sich fatal auswirken könnten, beispielsweise ein Fehler im Macro des FPGA in der Versorgungsregion. Das könnte einen Kurzschluss der Versorgungen unterhalb des Ball Grids des FPGA verursachen. Andererseits testet man solche Fehlerquellen natürlich zuerst und mittendrin und dann nochmals zuletzt. Ich habe das getan.
Ansonsten mal sehen. Es wird sicherlich eine ganze Zeit dauern, bis das Board ein Lebenszeichen von sich gibt. Dafür haben wir aber dann auch die erste Open Source Implementierung eines 68000 Clone. Das mit der Core Konfiguration ist schlicht die Möglichkeit eines Updates der Configware des FPGAs. Das geht über RS232 (USB ist vermutlich nicht so gut geeignet). Dieses Merkmal ist eingebaut, dass jeder die Configware tauschen kann, ohne sich ein 250€ teures Programmiergerät kaufen zu müssen. Ich starte hier natürlich mit dem Programmiergerät. Also nochmals kurz für alle, damit man sich auf einen gemeinsamen Wortschatz einigigen kann uns somit klar ist wer was meint:
Die Configware beschreibt die Schaltung im FPGA und ist in einem kleinen Boot-Baustein gesichert. Der FPGA wird nicht programmiert sondern konfiguriert.
Die Firmware beinhaltet dann das Betriebssystem und ist entweder im Flash oder auf Platte / SD-Card / CF-Card gesichert.
Die Umfrage sollte noch von viel mehr Personen ausgefüllt werden, damit sie aussagekräftig wird. Zusammenfassend möchte ich an dieser Stelle meine Meinung darlegen:
Die Prototypen sind so ausgerüstet, dass alles mögliche, was mal da war, getestet werden kann (ACSI-Geräte, Extension Plug Hardware, SCSI, Floppy, SM124, SC1224 usw.). In Zukunft werden diese Geräte nicht mehr zur Verfügung stehen (wie lange lebt ein Atari Laser...). Ich könnte mir vorstellen, die Schnittstellen, die nicht mehr gebraucht werden, sinnvoller zu verwenden. Alle alten und neuen Schnittstellen zu implementieren geht mit Aufwand (viele Steckverbinder, ein hochpoliges FPGA mit beispielsweise 800 I/O und dann eben auch einen 12 oder 16 fach Multilayer). Das ist für 2000€ alles machbar :)
Ich habe mir hierzu einen Ansatz überlegt: Die Prototypen werden als Classic-Boards beibehalten. Wer also alte Hardware betreiben möchte oder das ganz originale Look & Feel usw. der kann auf dies Classic-Boards zurückgreifen. Die Folgeversion ist dann das Produkt aus der Umfrage und sinnvollen und auch maßvollen Überlegungen. Auch hierzu habe ich von meiner Seite klare Vorstellungen, die ich an dieser Stelle nicht preisgeben möchte (erst nach der Umfrage).
So, das war's erst mal.
Bis dann
Wolfgang
-
Hallo zusammen,
genau das was Wolfgang hier realisiert hab ich mir schon lange gewünscht. Leider fehlt mikr das nötige Wissen in diese Richtung.
Würde gern helfen, aber leider kann ich nur mit folgendem Wissen dienen:
Programmieren in Delphi/Pascal
Programmieren in Basic (Ja mit Omikron hab ich angefangen, da war ich 11)
Grundwissen in Elektronik(Bin Industrieelektroniker und zuständig für Instandhaltung bei einem großen Elektronikdienstleister)
Tja das wars dann schon, hab leider keine Ahnung in Treiberprogrammierung oder änlichem.
Würd aber auch dann gern ein fertiges Gerät abnehmen wenns denn mal soweit ist.
Gruß Matthias
PS: Wie ich bei der Umfrage teilnehmen kann hab ich net kapiert....
-
Hi,
eigentlich einfach deine Wahl anklicken und absenden !!
Tschau Ingo
-
Hi,
PS: Wie ich bei der Umfrage teilnehmen kann hab ich net kapiert....
kann es leider nicht mehr verifizieren, da ich bereits abgestimmt habe. Das Problem ist glaube ich gewesen, dass man nur abstimmen kann, wenn man auf der ersten Seite des Threads ist. D.h. wenn du dir den aktuellen Eintrag auf Seite 4 ansiehst, dann kannst du nicht abstimmen.
Ganz allgemein, was wäre eigentlich eure Vorstellung, wieviele Leute hier ihre Stimme abgeben sollten? Ich hätte mit mindestens 40 gerechnet, eher mehr. So waren z.B. letzten Monat laut Statistik mal 124 Leute gleichzeitig online. Das Forum ist also schon ganz schön aktiv, so dass ich auch (dann allerdings sehr optimistisch) gut und gerne mit 200 Stimmen hätte rechnen können. Stattdessen haben wir nur 15 Stimmen. Und eine Stimme abzugeben ist sicherlich schneller gemacht, als hinterher irgendein Gerät zu kaufen. Muss man jetzt vermuten, dass Wolfgang erstmal höchstens eine handvoll Einheiten verkaufen kann?
Zugegeben, ich kann nicht wirklich abschätzen, welche Auswirkungen welche Kombination und vor allem nicht-Berücksichtigung bestimmte Punkte haben. Und nach Wolfgangs Erklärung zur Core-Konfiguration würde ich das vielleicht doch nehmen. Ansonsten hat man ja kaum Chancen, wenn Wolfgang oder jemand anders mal Neuerungen oder Bugfixes bereit stellt. Aber trotz dieser Unsicherheiten kann man doch mal aus dem Bauch raus abstimmen. Diskutieren kann man das dann hinterher immernoch.
Naja, vielleicht finden sich im Laufe des nächsten Monats ja doch noch eine ordentliche Menge an Stimmen :D
Viele Grüße
Ciao
Claus
-
Hallo,
also wenn du schon abgestimmt hast, dann geht es natürlich nicht. Jeder kann nur einmal abstimmen.
Zu deinem bedenken muß ich dir jetzt zu bedenken geben das sehr viele momentan im Urlaub sind und daher nicht abstimmen können. Lass noch etwas Zeit verstreichen und du wirst sehen das sich da nochwas tut.
Wobei ich sagen muss, ich habe das Gefühl das du dir nicht sicher bist was Wolfgang überhaupt hier macht!! Ich empfehle dir diesen Thread nochmals Komplett durchzulesen. Kann mich auch irren und das soll auch kein Persönlicher angriff sein. Also nicht auf den Schlips gedrehten fühlen.
Ich denke auf jedenfalls das das was Wolfgang hier zusammen gestellt hat wohl für uns die Zukunft ist. Denn unsere Ataris haben nicht mehr das lange leben das ist nun mal so!!. Wolfgang wird uns dann wenn es soweit ist ein Mainboard anbieten was wir dann nach unseren belieben verwenden können. Und wer es drauf hat kann damit einen Notebook bauen oder in einen Tower oder eventuell in ein Atari Gehäuse.
So denn Tschau Ingo
-
hallo, ich habe die umfrage noch einmal geöffnet. bei dauer war -1 Tage eingetragen, das hat wohl zu verwirrung bei der Forensoftware geführt...
-
Hallo Johannes,
Danke. Hoffentlich ganz im Sinne aller.
Wolfgang
-
wolfgang, meinst du nicht auch, dass mehr als 5 Möglichkeiten ausgewählt werden können sollten?
-
Hallo Johannes,
ich wollte damit vermeiden, dass alle Möglichkeiten gleich stark bewertet werden (zu 100%:). Wenn es nur fünf Möglichkeiten gibt, heißt das so was wie 'Beschränkung auf's Wesentliche'. Vielleicht liege ich da nicht im Trend. Aber ich versuche eben zu vermeiden, dass dieses Projekt, wie so viele, an 'Überfettung' eingeht. Ich bin momentan eben fast alleine, was den Entwurf der Hardware und des Cores angeht und habe natürlich, wie viele, meinen täglichen Job. Momentan unterstützt mich fachlich Tobias beim bugfixing der CPU und Volker, der bestimmte Core-Teile der CPU optimiert. Wenn die Hardware breiter angelegt wird (passiert automatisch durch mehr Auswahlmöglichkeiten), sollten sich noch ein paar Hardwareleute, Treiberschreiber, Core-Modellierer und CPU-Bauer finden.
Bis dann
Wolfgang
-
du hast schon recht, Ressourcen sollte man gezielt verplanen... Und mir fiel es schon ziemlich schwer, mich aufs wesentliche zu beschränken ;)
-
Hallo,
möchte mich auch noch mal zu Wort melden. ;D
Also das mit dem Abstimmen lag wohl nicht an meinem Verstand sondern an der Forensoftware(Puhhh glück gehabt).
Wegen der Beschränkung des wesentlichen:
Es ist klar das sich jeder alles Wünscht, aber es ist wohl für die Zukunft des STs auch wichtig die Schnittstellen Ethernet und USB zu haben. Ich denke der Trend zu diesen Schnittstellen geht weiter. Es ist ja schön das PS2 Maus und Tastatur angeschlossen werden können, aber wie lang werden die Schnittstellen noch von Tastatur und Maushersteller unterstützt. Für den klassischen Mausanschluss gibts ja auch nix mehr im Handel(wer hätte das mitte der neunziger gedacht). Auch Drucker werden nur noch über USB angesprochen - von exoten einmal abgesehen -
Ethernet (Ich schließ mal WLAN mit ein) ist dann ja auch wohl für den DSL-Zugang wichtig und dies ist doch auch eine der Hauptanwendungen von Computer in der heutigen Zeit.
Einer der bei dieser Abstimmung diese zwei Schnittstellen nicht mit ausgewählt hat, den Versteh ich nicht. Selbst wenn durch dieses geniale Projekt die ST-Platform für die nächsten Jahre(Jahrzehnte) gerettet ist, nützt es nix wenn ich in ein paar Jahren keine aktuelle Peripherie dran bekomme und wieder in altertumskisten nach alten Mäusen suchen darf.
Gruß Matthias:
PS: Wie schon erwähnt würd ich gerne auch helfen, aber leider besitz ich keine Fachkentnisse in Treiber, Assembler VHDL programmierung. Wenns ne Aufgabe gibt, bitte bei mir melden.
-
Buona Sera,
nochmal ich. Matthias spricht mir irgendwie aus dem Herzen. Es stimmt. Selbst PS/2 ist mittlereweile in Frage zu stellen und heute habe ich gelesen, dass Seagate die IDE-Schnittstelle nicht mehr weiter unterstützen wird, was folgt ist klar. Da haben wir also als veraltete Schnittstellen bereits ACSI, SCSI, IDE, PS/2, RS232, die LPT, Floppy, vermutlich auch VGA und Atari spezifische wie Floppy extern, Atari Monitor, Atari LAN. Interessanterweise müsste man sich nun überlegen, was dafür kommt. Wer an DSL denkt muss sich im klaren sein, dass kein ST oder Falcon mit der angebotenen Bandbreite fertig werden würde. Da nun die Diskussion in dieser Richtung losgeht (Claus hat sich das gewünscht ...) werde ich wohl doch meine Meinung zunehmend äussern. Das ist insofern ok., da die Umfrage ja nur ein Mittel zum Zweck ist. Ich würde ganz konsequent auf moderne Schnittstellen gehen (SATA, SAS, DVI, USB) und dennoch versuchen die Kompatibilität mit der ehemaligen Maschine zu erhalten. Andererseits ist, wie bereits erwähnt, das 'Classic' Board gut geeignet, die alten Komponenten zu betreiben. Vielleicht entsteht aus diesem Projekt auch so etwas wie Open Hardware, die in Verbindung mit Open Software wie z. B. Mint, XAES und bewährten Entwicklungswerkzeugen wie GCC und !neuen! Treibern zu einem ausgewogenen rekonfigurierbaren System ausgebaut werden. Nur am Rande: der 68K20+ ist bereits in Arbeit und weit fortgeschritten. Und für so ein System würde ich nichts verwenden, was in irgend einer Weise bereits angekündigt abgekündigt ist oder sogar schon nicht mehr Stand der Technik. Damit verlässt man zwar die klassische Atari Welt. Allerdings gebe ich hier auch zu Bedenken, dass die meisten sowieso mittlerweile Systeme haben die oben, unten, links und rechts mit irgendwelchen Treibern, Accessories, Hardwareerweiterungen oder gar anderen Betriebsystemen aufgebohrt sind. Mir würde ein System aus einem Guss besser gefallen. Und das ist eben mit Open Hardware möglich, da die Hardware bekannt ist und sich nicht alle vier Wochen ändert (wie z. B. VME-Bus Komponenten damals). Oder noch besser: Treiberprogrammierer können mit Hardware-Modellierern zusammen optimal angepasste Peripherie-Komponenten zur Verfügung stellen, ohne dass die ganze Gemeinde, ganz individuell und jeder für sich an ihren Maschinen stundenlang versuchen muss, irgendwas in Betrieb zu bekommen, was im Grundsatz nur deshalb nicht funktioniert, weil es 'schlampig' entworfen wurde.
Also so viel mal als Ansatz zu weiteren Diskussionen.
Wolfgang
-
Also,
ich sehe es so.
Bei der Classic Variante wie bei ST ist klar. Und bei der neueren Version, würde ich folgende Schnittstellen einbauen.
Intern:
Floppy
SATA / II für Festplatten und CD-Rom sowie Brenner
Und Extern dann.
USB2.0 Schnittstelle, die mit einem Hub Erweiterbar ist. Daran können viele neue Hardware angeschlossen werden unter anderem auch Tastatur und Maus (wie bei Mac).
VGA oder DVI
Und um eventuell noch etwas ältere Drucker zu betreiben auch noch eine Parallele Schnittstelle
Natürlich müßte man dann sehen wie man die Schnittstellen Softwaretechnisch implementiert.
Ich fande dieses Konzept wie es beim Milan verwendet worden ist sehr gut. Man hatte einen Bootblock der die Grundhardware vorkonfiguriert hat und für das System Nutzbar machte, dieser hat dann das Tos Image aus dem Flash geladen.
Wie weit es natürlich machbar ist, müßte man schauen. Es werden natürlich auch Treiber benötigt.
Tschau Ingo
-
Hallo,
aus meiner Sicht sollten folgende Schnittstellen vorhanden sein:
1 x Diskettenlaufwerk.
Alle wichtigen Programme habe ich auf Diskette.
Netzwerkanschluss für DSL
LPT für Drucker
SCSI für Scanner
USB 2.0 (soviel wie möglich)
SATA Festplatte, DVD-Laufwerk und Brenner
Die üblichen Soundanschluße (ohne MIDI)
Worauf ich gut verzichten kann sind:
ASCI
Atari LAN
ROM-Port
RS232 (hab ja DSL)
VME
Midi
IDE
Ob VGA oder DVI ist mir eigentlich egal.
Wichtig ist mir ein schnellerer Prozessor.
Ein 68040er wäre Ideal.
Orderntlich RAM sollte er auch haben.
Gruss Martin
-
Hallo,
ich meinte natürlich das die Frage nach den Wunschschnittstellen auf den erweiterten Clone sich beziehen. Das ein reiner Klassik-Clone an erster stelle steht ist klar. Wenn R-Type 10x so schnell läuft wie normal komm ich ja nich mehr mit. ;)
Es wäre aus meiner(Anwender) sicht natürlich klasse, wenn sämtliche Basisunterstützungen im ROM wären und nicht wie bei Windoof erst installiert werden müssen. Für die meisten USB-Geräte funktioniert ja auch bei Windows der gleiche Treiber also würde vieleicht(kenne mich mit Treiber ja nicht aus) ein Basis-USB-Treiber im ROM schon sämtliche USB-Peripherie ansteuern können?!
Nötige Treiber für den Bootvorgang in einen Flashspeicher schreiben zu können der unabhängig des Massenspeichers(Platte,CF..) NUR für Treiber genutzt wird und das System dieses dann aus diesem Speicher lädt wäre denke ich eine feine Sache. Das was mich an neuen Wintels und Macs stört sind die langen Bootvorgänge(Da ging es ja schneller ein Game beim C64 zu laden).
Gruß Matthias.
[EDIT]
Ich kenne Mint nicht da ich nur alte ST(STe) Modelle hab. Da dieses Systemimmer wieder genannt wird, interessiert mich ob dieses Compatibel zu TOS/GEM ist. Läuft alte Software auch auf diesem System?
-
Hallo,
oh je, jetzt kommen die ganzen Wünsche, was man doch alles behalten will, da will ich mich gleich mal anschließen ;)
Ich habe massive Probleme, einen Rechner ohne Floppy-Laufwerk als Atari anzusehen. Das dürfte den meisten so gehen. Festplatte hin oder her, viele benutzen noch ein ganz einfaches TOS und legen zum Starten die Diskette ein. Gilt natürlich insbesondere für Spieler.
Wolfgang hat die Floppy zwar in seine Liste der veralteten Sachen aufgenommen, trotzdem hat jeder danach munter die Floppy weiter in die Einbauliste mit aufgenommen. Ohne drüber nachzudenken würde ich die Floppy aus obigen Gründen auch mit aufnehmen. Aber brauchen wir sie wirklich? Mein PC-Laptop hat kein Diskettenlaufwerk, und ich vermisse es auch nicht. Und ob meine PC-Kiste ein Diskettenlaufwerk hat kann ich gar nicht aus dem Kopf sagen. Reicht es daher nicht vielleicht, wenn man eben doch kein Diskettenlaufwerk nimmt, und zur Not für 10€ ein USB-Diskettenlaufwerk nachkauft? Hat jemand eine Ahnung, ob man damit auf Atari-formatierte Disks zugreifen kann?
Oder braucht man die Floppys doch noch, weil beim Booten von Diskette das Betriebssystem eben doch etwas anders geladen wird, weshalb sich insbesondere manche Spiele nur Booten, aber nicht mehr aus dem laufenden System starten lassen. Hier wäre das Gegenargument, dass D-Bug z.Z. daran arbeitet, alle möglichen Spiele so zu fixen, dass sie von Festplatte gestartet werden können.
Ganz entschlossen bin ich nicht, ich könnte aber wohl auf Floppys verzichten :o
Bezüglich alter Drucker muss ich sagen, da kann ich auf alles verzichten. Es wird sich doch eher darüber beklagt, dass man Probleme hat die neuen Drucker am Atari zu nutzen. Drucker über USB wäre für mich absolut ausreichend. Kann ich zugegebenerweise leicht sagen, beide meine Drucker gehen über USB, trotzdem sollte das für jeden akzeptabel sein, immerhin gibt es für 20€ einen Adapter, um parallel an USB anzuschließen.
SATA scheint wohl keine Diskussion zu sein, stellt sich die Frage SATA und SATA II, oder nur eins von beidem?
RS232 und Midi macht mir ja etwas Sorgen. Insbesondere per Nullmodem (das ging doch über RS232?) gab es nette Spiele: Populous, Speedball, Stunt Car Racer, ...
Aber außer diesem Grund spricht wohl nicht viel dafür. Und wer weiß, vielleicht schafft man es ja hier von der Softwareseite aus, dass man einen seriellen Anschluss vorgaukelt. Da hätte ich durchaus Interesse, das selber zu versuchen. Wie auch immer, ich bin aus den genannten, zugegebenerweise dummen Gründen für RS232, bestehe aber natürlich nicht darauf.
Wolfgang, SAS würdest du als Ersatz für SCSI ansehen, d.h. eins von beiden auf jeden Fall, aber halt möglichst entweder oder? Auf der neuesten Technik aufzusetzen ist was nettes, aber setzt die sich wirklich durch? Mit anderen Worten, ich sehe in SAS (ohne es im Detail zu kennen) ein gewisses Risiko. Aber du bist der Hardware-Spezialist und kannst das besser beurteilen.
(Angemerkt sei, dass es sogar SCSI auf USB Adapter gibt, allerdings für 70€ und scheinbar mit Geschwindigkeitsnachteilen, aber für einen Scanner sollte es hoffentlich reichen)
DVI finde ich eine gute Idee. Meine Vermutung wäre aber, dass es dich im Vergleich zu VGA mehrere Monate extra kostet, dass hinzubekommen, oder? Und dann halte ich es mit "lieber den Spatzen in der Hand als die Taube auf dem Dach". Wenn du sagst, dass das mit DVI klappt, dann an dieser Stelle doch lieber die moderne Schnittstelle.
Bleibt noch etwas: das Betriebssystem! Du brachtest MINT ins Gespräch. Ähnlich wie Matthias kenne ich das nicht aus eigenem Gebrauch (hatte außer TOS nur mal MagiC installiert, lief aber nicht rund). Mit MINT meinst du wahrscheinlich die Kombination FreeMINT/XaAES und evtl. noch Thing. Das klingt super, da das das moderne TOS-System der Wahl zu sein scheint, und dabei ziemlich robust und stabil sein soll. Auch scheint es eine ordentliche Anzahl an Entwicklern zu geben. Aber: Wie soll das System starten? Hätten wir gar kein TOS mehr im ROM, und nur noch MINT auf der Platte? Ist ja nicht meine Idealvorstellung, ich würde den Rechner gerne auch ohne Platte starten können. Und mit MINT im ROM nimmt man sich wohl jede Möglichkeit zum Versionswechsel, da MINT für diese Art der Installation nicht ausgelegt ist.
In der Umfrage hast du TOS-Umschaltungen aufgelistet. Wie paßt das denn dazu, dass du MINT gerne als Standard hättest?
Viele Grüße
Ciao
Claus
P.S.: Oh je, wieso werden meine Texte immer so lang? Aber es wird langsam richtig spannend auch für die, die nicht das Know How haben, um aktuell mitzuhelfen. Und da sind sooo viele Fragen ::)
-
[EDIT]
Ich kenne Mint nicht da ich nur alte ST(STe) Modelle hab. Da dieses Systemimmer wieder genannt wird, interessiert mich ob dieses Compatibel zu TOS/GEM ist. Läuft alte Software auch auf diesem System?
Ja die meisten Programme laufen unter Mint. Vom Look und Feel ist ein Mint Dektop ja nix anderes als der normal GEM Desktop nur mit viel mehr möglichkeiten und das wichtigste eben halt Multitasking!!
TSchau Ingo
-
Ciao Belli,
also um das nochmals klarzustellen: Die Liste der Umfrage stimmt überhaupt nicht mit meiner persönlichen Meinung zusammen. Wenn viele TOS-Umschaltungen wollen, dann macht man das eben. Bezüglich VDI denke ich, dass es gehen müsste. Was mir aber jetzt schon klar ist, an USB geht keiner vorbei. Ich habe aus diesem Grunde in der Hardware einen Philips-Chip verbaut, der aktuell ist ISP1582 Rev.4. Wer Lust hat, könnte ja mal recherchieren. Es gibt für die Treiberentwicklung sicherlich irgendwelche Hilfestellungen (Templates, Bibos).
Wolfgang
-
Mich würde interessieren, ob ich auf einer solchen modernen Kiste auch ein MagiC benutzen könnte.
Wahrscheinlich gibt das Probleme, und ich fände es gut, wenn das getestet würde, und wenn evtl. ASH kontaktiert würden, um ggfs. eine Anpassung zu schreiben.
Ich wäre durchaus bereit, eine MagiC Lizenz zu erwerben, die ich dann zur Verfügung stellen würde, damit Tests durchgeführt werden können.
Falls es keine Möglichkeit gäbe, MagiC auf dem Rechner zu booten, würde ich sie dann selber anderweitig verwenden.
Diesbezügliche Rücksprache bitte über PM oder Mail.
-
Was mir aber jetzt schon klar ist, an USB geht keiner vorbei. Ich habe aus diesem Grunde in der Hardware einen Philips-Chip verbaut, der aktuell ist ISP1582 Rev.4. Wer Lust hat, könnte ja mal recherchieren. Es gibt für die Treiberentwicklung sicherlich irgendwelche Hilfestellungen (Templates, Bibos).
Hmm, hat da schon jemand nachgeforscht? NETUS-Bee hat den ISP1160, und auch CTLink hätte den Chip genutzt (wenn es nicht eingestellt worden wäre). Funktionieren die Treiber dafür dann auch für den FPGA-Clone? Leider ist der Treiber nicht fertig geworden (man kann nur USB-Mäuse nutzen, mehr nicht), aber immerhin könnte man darauf aufsetzen. Vielleicht könnte man Jan Thomas auch neu motivieren, nachdem er durch die CTLink-Misere scheinbar doch etwas demotiviert wurde.
Auch wenn der genannte Treiber in keinster Weise nützlich wäre, und man somit einen ganz neuen Treiber schreiben müßte, so könnte man sich selber ein NETUS-Bee kaufen, um schonmal testen zu können. Denn ohne Hardware entwickeln sich Treiber ganz schlecht...
Auf http://www.microusb.org werden diverse USB-Projekte für Homecomputer beschrieben, insbesondere für 8-Bit Ataris. Die nutzen den Cypress SL811, mit der Begründung, dass dieser sowohl als Slave als auch als Master Controller genutzt werden kann. Zwischenzeitlich sollte der wohl auch beim CTLink eingesetzt werden, irgendwie war man damit aber nicht zufrieden und hat sich eben für den ISP1160 entschieden. Trotzdem die Frage, konnte jemand rausfinden, wie das mit Slave und Master beim ISP1582 aussieht? In der offiziellen Doku steht Supports Generic DMA (GDMA) slave mode, aber Master wäre ja viel wichtiger. Ist das klar, das das auch unterstützt wird?
-
Ich habe gerade alle Information bezüglich der ISP1582 auf meinen Website kopiert wo mann das kann downloaden (ung. 10MB):
http://www.atarian.nl/files/ISP1582.zip (http://www.atarian.nl/files/ISP1582.zip)
Ich hoffe das das die Information ist die gesucht würde?
-
Ich hoffe das das die Information ist die gesucht würde?
Hi,
woher kommen denn die Infos? Ich hatte sie von http://www.nxp.com . Evtl. ist der Firmware Programming Guide (AN10039) hilfreich, noch besser wäre aber der Programming Guide (AN10033), den ich leider nicht finden konnte, und der bei dir auch nicht dabei ist. Hat da jemand eine Ahnung, wo man das her bekommen könnte?
Viele Grüße
Ciao
Claus
-
Hallo zusammen,
wollte hier zum Thema FPGA-Clone ne kleine Diskussion beginnen, wies denn mit dem Wunschgehäuse aussieht.
So als zwischendurch-Abstecher bis was neues von den Prototypen gibt.
Zum Thema bauen in Tastaturgehäuse ST-Like hab ich ein paar Adressen durchgeklappert. Meistens gibts leider nur Industriekontakte, da müsste also jemand ran der hier anfragen darf. Bei Privat zu Industrie ist das ja so ne Sache.
http://www2.okw.com/katselect.asp?Ziel=Klasse&Land=D (http://www2.okw.com/katselect.asp?Ziel=Klasse&Land=D)
http://www.pbe-shop.de/shop/657.html (http://www.pbe-shop.de/shop/657.html)
[EDIT] OKOK hab den Link gelöscht
PS: Hat jetzt schon jemand irgendwie Infos (Unterstützung) in Sachen USB-Treiberprogrammierung bekommen???
[EDIT] Links bearbeitet ;DSorry ;D
-
Also ich denke das dieses Thema (@gehäuse) noch lange nicht Spruchreif ist, denn erst wenn ein fertiges Mainboard vorliegt kann man anfangen darüber zu Sprechen.
TSchau Ingo
-
Hallo,
kann mal bitte jemand den Conrad-Link von matashen bearbeiten? Der zieht das ganze Board so in die Läääääääääääääääänge. ;)
Gruß,
Dennis 8)
-
kann mal bitte jemand den Conrad-Link von matashen bearbeiten? Der zieht das ganze Board so in die Läääääääääääääääänge. ;)
Darum möchte ich auch bitten.
Wenn ich mir das Texteingabefeld ansehe, ist der Link allerdings gar nicht lang, dafür scheint aber irgendwas mit den phpBB-Tags durcheinandergekommen zu sein.
Und da kann ich nichts machen, weil ich nicht weiß, wo der Fehler liegt, sonst würde ich da einfach drin rumgekritzelt haben (schließlich macht dieser Falcon gerade nur 768x576 ;D).
-
Hallo MatAschen
wollte hier zum Thema FPGA-Clone ne kleine Diskussion beginnen, wies denn mit dem Wunschgehäuse aussieht.
[...]
Zum Thema bauen in Tastaturgehäuse ST-Like hab ich ein paar Adressen durchgeklappert.
Finde ich sehr gut. Ich gebe Ingo zwar insofern Recht, als dass ich der Fertigstellung des Boards die höchste Prio gebe. Allerdings bin ich sehr wohl der Meinung, dass wir uns über alle weitergehenden Punkte - und somit auch über das Gehäuse - schonmal unterhalten können. Mit der Erstellung der Umfrage hatte Wolfgang uns ja durchaus auch gebeten, unsere Meinung über die weitere Hardwareplanung abzugeben. Inwiefern er unsere Meinungen/Argumente dann nutzt oder verwirft kann er dann immer noch selber entscheiden.
Leider gibt es bei der Umfrage nur vier Stimmen für "Mechanik zum Board/Gehäuse", wobei noch ganz offen gelassen wurde, ob Tastaturgehäuse oder etwas anderes. Mein Favorit wäre ja ein Laptop-Gehäuse. Mir ist allerdings schon klar, dass viele aus der Atari-Historie heraus gerne einen Tastatur-Rechner hätten. Das ist dann schon ein Stück extra-Atari-Feeling.
Nicht klar ist mir in dem Zusammenhang allerdings, was diejenigen wollen, die das Board ohne Gehäuse wollen. Klar, zur Not muss man selber zusehen, wie man das in ein gebrauchtes Gehäuse quetscht. Aber wenn mein Computer eines schönen Tages so aussieht, wie auf den Bildern von Wolfgangs Homepage, dann habe ich da so meine Probleme mit (und meine Frau ganz sicher auch).
PS: Hat jetzt schon jemand irgendwie Infos (Unterstützung) in Sachen USB-Treiberprogrammierung bekommen???
Ich habe mich da etwas umgesehen, hab bei Wolfgang prinzipielles Interesse bekundet, und habe z.B. bei einem Beteiligten von SIO2USB am 8-Bit Atari nachgefragt (steht übrigens in der Retro #4 http://www.retrogames.info/node/566 (http://www.retrogames.info/node/566), die es aktuell im Zeitschriftenladen gibt, ein kurzer Artikel drüber drin). Hab auch eine sehr nette und ordentliche Antwort bekommen, allerdings glaube ich, dass die dort gemachten Erfahrungen für uns am FPGA-Clone nicht so relevant sind, da es dort nur um USB-Speichermedien in einem ganz engen Rahmen geht.
Geholfen hat mir das aber, um mehr über das Thema USB-Treiber zu verstehen. Es gibt wohl verschiedene Geräte-Kategorien (z.B. Speichermedium, Maus, Drucker, ...), und dafür muss ein USB-Treiber einen generischen Treiber bereitstellen. Allerdings kennt man es z.B. von USB-Druckern, dass die eigentlich einen eigenen Treiber brauchen, um in voller Qualität zu drucken. Wenn der installiert ist, erkennt der USB-Treiber anhand Hersteller- und Geräte-Id, dass dafür ein spezieller Treiber verwendet werden kann/soll. Aufgabe wäre also, einen USB-Treiber zu schreiben, der auf einen Interrupt des USB-Controllers wartet, und dann prüft, welche Gerätekategorie angeschlossen wurde. Weiter müßte man die einzelnen generischen Treiber schreiben. Idealerweise kämen dann für ausgewählte Geräte noch spezielle Treiber dran, wobei es da natürlich einige Einschränkungen gibt. Aber vielleicht kann man da von Entwicklungen für Linux profitieren.
Wie man sieht ist die Aufgabe um einiges komplexer als die z.B. hier http://www.janthomas.org.uk/ (http://www.janthomas.org.uk/) angegangene, da dort weder auf den IRQ gehorcht wird (der Anwender muss sicherstellen, dass das Gerät beim Starten des Programms bereits eingestöpselt ist), noch wird der volle Umfang an Gerätekategorien abgedeckt, sondern wohl nur der für die Maus. Trotzdem war es aufwendig genug, mit anderen Worten, ich gehe davon aus, dass das FPGA-Board deutlich vor dem Treiber fertig wird.
Meine Idee wäre an der Stelle dann, dass man den neuen Treiber so schreibt, dass er je nach Gerätekategorie entweder eigene generische Treiber nimmt, oder aber (konfigurierbar) externe Programme. So könnte man dann z.B. (bei angepaßter Schnittstelle) auf den bereits vorhandenen Maustreiber zugreifen.
Weiter hätte dieses Konzept den Vorteil, dass problemlos mehrere Entwickler an dem Thema arbeiten könnten.
Mein Problem ist aktuell, dass ich noch nie MiNT benutzt geschweige denn gesehen habe. MagiC habe ich vor ein paar Jahren auch nur genommen, um mal zu sehen, was der aktuelle Stand ist. Naja, jetzt versuche ich meinen MegaSTE für MiNT flott zu machen. Ab Mitte Oktober (vorher habe ich eigentlich keine Zeit) will ich dann mal sehen, was man prinzipiell unter MiNT für so eine Treiberentwicklung tun muss. Vielleicht hat ja jemand ein paar Dokus oder Hinweise? Gerne würde ich mich dann natürlich auch irgendwo einklinken, falls schon jemand weiter ist. Allerdings habe ich die Befürchtung, dass sich bisher nicht so viele auf das Thema gestürzt haben. ;D
Ich habe auch nochmal mit Wolfgang Kontakt gehabt. Es wird aus verschiedenen Gründen nicht der ISP1582. Wolfgang hatte sich schon gegen den entschieden bevor ich meine Gegenargumente anbrachte. Sicher ist aber, dass es einer von Philips wird. Diese Info sollte ausreichen, um mit der Treiberentwicklung zu beginnen. Welcher USB-Controller es dann wird wird noch abgewartet, da Wolfgang im Idealfall noch auf in Kürze neu auf den Markt kommende wartet.
-
Hi,
Hallo,
kann mal bitte jemand den Conrad-Link von matashen bearbeiten? Der zieht das ganze Board so in die Läääääääääääääääänge. ;)
Gruß,
Dennis 8)
Könnte jemand den Conrad-Link von matashen löschen, da er sowie so nur eine Fehler Seite anzeigt, da ich die Cookies für diese Season nicht besitzte.
matashen wird die Seite bestimmt laden können, oder ?
CU,
Stosser
-
Hi,
Könnte jemand den Conrad-Link von matashen löschen, da er sowie so nur eine Fehler Seite anzeigt, da ich die Cookies für diese Season nicht besitzte.
matashen wird die Seite bestimmt laden können, oder ?
CU,
Stosser
Den Link könnte man wirklich am besten löschen. Allerdings kann man, wenn man ihn im Detail ansieht, erkennen, dass damit auf Artikel-Nr. 541354 verwiesen wird. Also einfach http://www1.conrad.de (http://www1.conrad.de) anwählen, und dann am linken Rand in der Schnellsuche in das linke Feld besagte Nummer eingeben, schon kommt man zum gewünschten Keybord-Gehäuse KEU7-LP.
Viele Grüße
Ciao
Claus
-
(steht übrigens in der Retro #4 http://www.retrogames.info/node/566, die es aktuell im Zeitschriftenladen gibt, ein kurzer Artikel drüber drin).
Oh, ein Link auf die Seiten des Retrogames e.V., wie schön. ;D
Wer hier in der Nähe wohnt, muss da mal Samstag abends hin gehen. Am Besten mir noch vorher eine PM schicken, dann komme ich auch. 8)
Gruß,
Dennis 8)
-
Könnte es sein, daß bei Conrad keine Rücksicht auf Leute genommen wird, die mit Highwire surfen? ;)
-
Könnte es sein, daß bei Conrad keine Rücksicht auf Leute genommen wird, die mit Highwire surfen? ;)
Versuch mal
Edit: Rest gelöscht, der Link tut's auch nicht... :P
-
Haben wir hier nicht jemand der sich mit CAD auskennt?
Derjenige kann doch versuchen ein neues Gehäuse zu Designen, wir haben hier de Firma die Stellen Spitzteile her. Da könnte man dann ja mal ein Angebot machen lassen.
TSchau Ingo
-
Hallo,
ich wollte mit der Diskussion zum Thema Gehäuse nur einen weiteren Punkt zum Clone anstoßen. Mir ist vollkommen klar das der Proto absoluten Vorrang hat, aber irgendwie schien mir die Diskussion wegen Warten auf den Prototypen eingeschlafen, und da hab ich einfach mal in einer Ecke geforscht. Ich hätte auch gern einen Treiber beigsteuert, aber ich kanns nun mal nicht also spuk ich so ein bischen rum.
Zur Idee mit dem Angebot.
Bevor sich jemand die Mühe macht das CAD anzuschmeissen wären doch auch (Hand)skizzen schon nicht schlecht. Was meint Ihr?
Überlegung:
Ein spezielles Gehäuse zu spritzen dürfte nicht ganz billig sein, soweit ich das noch in Erinnerung habe kostet allein das Werkzeug schon 5000(einfach) Aufwärts(unser Fall). Bei Metallgehäusen dürfte eine Kleinserie günstiger zu machen sein. (Blech stanzen und ein paar mal biegen). Ein günstiger Lieferant in dieser Richtung ist so weit ich weis www.technoblech-gmbh.de (http://www.technoblech-gmbh.de) (Diesmal Link einfach ;))
Die Idee mit Modularen USB-Treiber find ich gut!
Gruß Matthias
-
Ich habe noch je ein leeres Falcon und TT Ghäuse. :)
Damit würde ich erstmal rumprobieren. ;)
-
Gibts die noch irgendwo. Wollte schon immer mal ein Facelifting für meinen 520er ;D
-
Ich habe mal von der Leiterplatte, die im Übrigen in Kürze bei mir eintreffem sollte, ein pdf erzeugt. Das lässt sich auf einem DIN-A4 Laser oder so originalgetreu ausdrucken. Es handelt sich hierbei um die ersten beiden Protos. Die Befestigungslöcher für die Leiterplatte (M3) und die Festplatte (M2.5) sind ersichtlich. An und für sich gefällt mir die Größe des Boards. Ich werde versuchen, das Lochbild und die Maße zu lassen, wenn das für alle ok ist. Lediglich technische Details werden noch verändert.
Als erstes, was sich bereits jetzt herauskristallisiert, ist ein USB Host Controller. Ich würde den ISP1760 vorschlagen (9x9mm Ultra Fine Line BGA, 128 Anschlüsse).
Vielleicht könnt Ihr ja das ausgedruckte File mal auf einen Pappendeckel aufkleben und schauen, in welche Ecke der diversen Atari-Gehäuse es am besten reinpasst :-)
Das File ist 2MB groß und daher kann ich es hier nicht hochladen. Aber auf meiner Web-Seite (www.experiment-s.de) liegt es im Downloadbereich bereit.
-
Was mir an dem Bestückplan auffällt ist das Joyport 1 und 2 mit 15pol. beschrieben sind. Ich dachte die sind 9po.?? ???
-
Hallo,
nein der STE und auch der Falcon hat 2 extra Analoge Joystick eingegänge und diese hat Wolfgang mit umgesetzt.
TSchau Ingo
-
Beim Gehäuse kann man doch kreativ sein. Dazu wollte ich mal den folgenden Link posten: http://www.geit.de/eng_efikase.html
Es geht um ein einfaches DIY-Gehäuse für das EFIKA-Board von bplan. (Für 99$ = ~75€ übrigens garnicht so uninteressant ...)
Gruß,
Dennis 8)
-
Ist bei einer größeren menge sicherlich auch noch was am Preis machbar.
TSchau Ingo
-
Hallo Wolfgang, hallo Forum,
Ich habe mir hierzu einen Ansatz überlegt: Die Prototypen werden als Classic-Boards beibehalten. Wer also alte Hardware betreiben möchte oder das ganz originale Look & Feel usw. der kann auf dies Classic-Boards zurückgreifen. Die Folgeversion ist dann das Produkt aus der Umfrage und sinnvollen und auch maßvollen Überlegungen.
wenn ich mir die Prototypen ansehe, so ist da einiges drauf, was aus meiner Sicht über ein ganz klassisches Board rausgeht. CF-Card, USB, PS/2, viele Grafikausgänge (habe ich VGA, ST und LCD entdeckt?), und sicher noch einiges von dem, was ich nicht zuordnen konnte. Mit anderen Worten, mit diesem Prototypen kann man aus meiner Sicht sehr gut leben. Fast habe ich Zweifel, ob jemand, der dieses Board abnimmt, auch noch die Folgeversion abnimmt. Wird man durch SATA, SAS, DVI und vielleicht weitere USB-Anschlüsse soviel mehr bekommen? Sogar Ethernet ist schon drauf, die Steigerung wäre dann wohl wirklich schon WLAN ;D Das soll keine Kritik sein, vielmehr ist es ein Qualitätszeichen des Prototypen.
Welcher FPGA-Chip wird eigentlich genau verwendet? Also Geschwindigkeitsstufe 6, 7 oder 8? (6 war die schnellste, 8 ist je nach Anwendung etwa 25% langsamer, 7 liegt dazwischen) Und wird er durch die Konfiguration (ja, ich habe nicht Programmierung gesagt ;) ) voll gefüllt, oder wäre da noch Platz für reichlich VHDL-Erweiterungen? Mit anderen Worten, hätte es auch der EP2C15 getan, oder sollte man für zukünftige Erweiterungen lieber den EP2C50/70 nehmen (letzterer ist aber zum Vergleich fast $150 teurer, ist also nur eine prinzipielle Frage von mir und auf keinen Fall mein Wunsch).
Und wieviel Speicher ist eigentlich auf dem Prototypen, bzw. wo finde ich den auf dem Layout? Als was für Speicher wird der "vom ST" ansprechbar sein?
An und für sich gefällt mir die Größe des Boards. Ich werde versuchen, das Lochbild und die Maße zu lassen, wenn das für alle ok ist. Lediglich technische Details werden noch verändert.
Die Aussage bezieht sich ausschließlich auf das Classic-Board oder auch auf die Folgeversion?
Viele Grüße
Ciao
Claus
-
Moin,
zu den Fragen, ganz kurz:
1. Es ist ein EP2C35 drauf, der inklusive Prozessor mit etwa 22000 Logic Cells gefüllt ist (zweidrittel). Größere FPGAs sind aufgrund des gewählten Gehäuses möglich (habe ich extra so geplant) sind aber, wie Du bereits bemerkt hast, nicht ganz billig.
2. Das Board ist ein A-Muster und muss sicherlich noch etwas modifiziert werden (USB, TCP/IP). Ich würde aber versuchen das Lochbild auch für künftige Versionen beizubehalten, wenn man bei diesem Formfaktor bleibt. Sollte die Platine allerdings irgendwann mal gähnend leer werden , dann würde ich vorschlagen, einen kleineren Formfaktor zu wählen.
3. Es sind 64MB Speicher drauf, der Prozessor kann aber nur 16MB ansprechen. Der Speicher befindet sich einerseits unmittelbar links vom FPGA (2 Bausteine) und rechts davon ist das FLASH.
4. Der FPGA Speedgrade 6,7 oder 8 ist bei dieser Anwendung völlig belanglos. Ich würde nehmen, was momentan erhältlich ist. Das ist nämlich immer so eine Sache...
5. Der übrige Speicher, der nicht unmittelbar ansprechbar ist, ließe sich vermutlich für einen Video Frame mit einer vernünftigen Auflöung verwenden (selfish:-))
-
Hi zusammen,
die Leiterplatte der Suska-III Prototypen ist nun nach einigen Verzögerungen auf dem Weg. Ich erwarte sie die nächsten Tage, obwohl mir das nichts bringt, da ich nämlich demnächst für 10 Tage im Urlaub bin :)) also erst ab 23. 9. wieder erreichbar. Ich habe mittlerweile an den Upgrades gearbeitet und bin am USB Host Controller angestoßen. Den ursprünglichen Device-Controller wollte ich durch einen ISP1760 ersetzen. Nun ist es so, dass dieser Chip zwar sehr gut geeignet ist (fast schon kanonenmäßig für diese Hardware), allerdings auch recht groß ist und einen 32 Bit Datenbus hat, 18 Adressleitungen, 4 USB-Ports, viele Versorgungsspannungen benötigt usw. Alles in allem würde dieser Chip die akkurate Verlegung der Datenbus- und Adressbus Leitungen auf dem Board stören und es wäre im Bereich dieses Controllers alles wahnsinnig eng. Daher tendiere ich jetzt eher zu einem Maxim-Chip MAX3421E, der sowohl Host- als auch Device Controller sein kann. Der Chip wird mit wenigen Leitungen an den FPGA angeschlossen und hat zudem noch 8 Ausgangs- und 8 Eingangsports für allgemeine Zwecke. Bezüglich des Ethernet-Chip würde ich den DP83848C von National Semiconductors vorschlagen. Der Stack ist dann nicht mehr, wie bisher, im Chip sondern in Software zu erstellen, bringt dafür aber fast beliebige Freiheitsgrade.
Ich denke, dass beide Chips sehr angemessen sind für die hier vorliegende Hardware.
-
Hallo Wolfgang!
Cooles Projekt, an dem Du da arbeitest :D
Zwei Fragen habe ich:
1. Glaubst Du, dass Du eine 100% Kompatibilität zu echten Ataris erreichst?
2. Wie hoch werden die Materialkosten für Deinen Atari-Klon sein?
Viele Grüße aus Hamburg
Stefan
-
Hi Stefan,
zu Deinen Fragen:
1. Ich hoffe eine nahezu 100%ige Kompatibilität zu den STs zu erreichen. Einschränkungen sind Spezialchips, die es nicht mehr gibt wie z. B. den DSP des Falcon oder den Audiochip des STEs. Der DSP ist vermutlich recht gut als VHDL Core zu modellieren, macht allerdings viel Arbeit. Für den Soundchip (LMC1992) habe ich ein alternatives Chip vorgesehen, das allerdings nicht Softwarekompatibel ist. Chips wie die Uhr (RP5C15) habe ich für die Software per Adaptionsmodul geklont aber auch in diesem Fall nicht ganz 100%ig (bis jetzt, oder braucht jemand den ALARM Ausgang?). Ein sehr komplexes Kapitel ist die CPU. Hier kommt es auf die Software an. Verschiedentlich ist die Software auf Taktzyklen genau geschrieben und sogar Fehler in den CPUs werden zuweilen ausgenutzt. Hier kann ich nur bedingt dienen: ich versuche Zyklengenau den CPU Core nachzubilden (Bustiming), Fehler werde ich aber nicht absichtlich eingebaut lassen.
2. Die Kosten für die Bauteile des Prototyps sind recht hoch. So gegen 600€ bis 700€ pro Stück (2 Stück sind ein Minimum, wegen der PCB-Herstellung). Brachial teuer ist natürlich die Leiterplatte (8-fach Layer) mit dem erforderlichen Pastensieb. Aber auch das im Prototyp üppig ausgefallene FPGA schlägt mit ca. 80€ zu Buche. Und dann ist das Ganze noch nicht bestückt. An diesem Preisgefüge wird sich auch nichts ändern, wenn nicht Stückzahlen zustande kommen. Ich habe vor, die Hardware aufzulegen, wenn alles stabil läuft. Aber ich denke 50 Stück (besser 100 Stück) sind ein Minimum, so dass die PCB-Kosten und die Richtkosten für die Bestückung auf ein erträgliches Maß kommen.
Grüße aus S.
Wolfgang
-
100 Bestellungen müssen schon sein. Ich denke, wir sollten auch in den anderen ATARI-Foren für dieses tolle Projekt werben.
So sehr ich das Projekt auch aus unterschiedlichen Gründen toll finde (z.B. da OpenSource, und weil eine ATARI-Entwicklung), möchte ich doch einen etwas kritischen Punkt anstimmen:
Wolfgang geht ja schon einen richtigen Weg, indem er in die Zukunft denkt. So stehen veraltete Schnittstellen (die zweifelsohne ihren Retro-Charme haben ;)) nicht so sehr im Vordergrund wie zeitgemäße Schnittstellen. Diese sorgen dann für Interoperabilität mit der heutigen IT-Welt. Das finde ich sehr gut.
Dennoch bin ich der Meinung, dass sich die ATARI-Platform durch so einen "Clone" nicht genug weiterentwickelt. Schließlich ist die Plattform an sich inzwischen 22 Jahre alt! Und trotzdem wird versucht, die Bus-Struktur ähnlich zu halten und zu einer CPU, welche 1979 entworfen wurde, kompatibel zu bleiben.
Das hat zwar wieder einen gewissen Retro-Charme, bringt die Platform als solches aber nicht weiter. Mit einer solchen Architektur bleiben wir in der Vergangenheit kleben. Und somit bleiben wir eine Nische.
Den Königsweg ist Apple bereits zwei mal gegangen. Die Macintosh-Platform hat sich seit 1983 soweit entwickelt, dass ein heutiger Macintosh nurnoch den Namen mit seinem Urahn gemeinsam hat. Und trotzdem kann man auf einem heutigen Mac noch Software von damals ausführen. Dank Software-Emulation. Diese ist so gut in das System integriert, dass ein Anwender von den großen Änderungen der Hardware-Architektur nur wenig erfährt.
Ähnlich mit Amiga. Amiga ist zwar immernoch eine Nischen-Platform, sie hat aber den Umstieg auf eine modernere Hardware-Architektur auch geschaft. Die Frage ist nur, wie lange sich die PowerPC-Architektur langfristig halten wird. Schließlich ist dieser Umstieg auch schon sehr lange her ...
Langer Rede kurzer Sinn: Das Projekt ist sehr gut und auf jeden Fall unterstützenswert. Wolfgangs Blick in die Zukunft statt in die Vergangenheit finde ich ebenfalls sehr gut. Doch die Idee, dass sich alles um ein 22 Jahre altes Design dreht, gefällt mir nicht so sehr.
Natürlich kann man sagen, es wäre keine ATARI (ST) mehr, wenn man auf eine 68k CPU etc. verzichtet. Doch ich finde, wir müssen die Chance packen, die sich uns bietet und die ST-Platform auf ein neues Level hiefen. Meiner Meinung nach sollte so viel Kompatibilität wie möglich in der Software stecken, nicht in der Hardware. Und dank Projekten wie Aranym, sind die Ressourcen hierfür mehr denn je vorhanden.
Gruß,
Dennis 8)
-
Hi Dennis,
danke für diese Ausführungen. Die sprechen sehr an, was ich so denke. Ich habe natürlich bereits die Upgrades 68030 etc. in der Planung sowie auch die MMU, um vielleicht mal ein Linux oder so, wie ich es bereits in der Unfrage angedeutet habe, aufsetzen zu können. Andererseits bin ich momentan schon wieder auf der Retro Schiene, da heutzutage nichts mehr ohne Hardware mit einem gigantomanischen Softwarestack zu funktionieren scheint. Daher finde ich beispielsweise Mint gar nicht so schlecht. Das ist schlank und schnell. Ich wünsche natürlich allen, die diese Hardware-Platform benutzen, um Retro Software zu erleben einen maximalen Spaß damit. Wenn Du allerdings ansprichst, aus diesem Hardware-Ansatz etwas zu basteln, was zeitgemäß ist, dann möchte ich Dir in drei Punkten antworten:
1. Als 'Einzelkämpfer' bleibt Dir nur, der aktuellen Technologie hinterherzulaufen. Ich denke, dass ein 68K00 Core kein Mist ist und eine gute Basis zur Weiterentwicklung.
2. Wenn wir 22 Jahre Entwicklung aufholen wollen, dann sind etwa 22 mal 1000 Hardwaredesigner, also 22000 (na ja in etwa;) erforderlich, um in der nächsten Zeit Anschluss zu bekommen (an die Mainstream Technik).
3. Da das nicht funktioniert, könnte man sich zusammentun und Details optimieren. Für mich ist nicht das Ziel, einen Abklatsch an PCs oder MACs nachzuentwickeln sondern vielmehr eine schlanke, schnelle und clevere Alternative zu den Mainstreams, die heute verkauft werden.
Momentan hilft Tobias sehr bei der Evaluierung des 68K00 Cores, tausen Dank an dieser Stelle. Ich kann hierzu feststellen: genial. doppelte Manpower. Wer also Lust hat sich irgendwie einzubringen ...
Ich bin jetzt für die nächsten 12 Tage weg.
Grüße Wolfgang
-
Dann wünsche ich schönen Urlaub Wolfgang!! Und erhol dich gut. Hast du dir ja reichlich verdient!!
-
Naja, als Mist sehe ich den 69k ja auch nicht an. Und deine Idee mit der schlanken Alternative zum Mainstream rennt bei mir auch offene Türen ein. Ich bin nur der Meinung, wir sollten nicht zu sehr in der Vergangenheit hängen bleiben, sondern nach Vorne in die Zukunft schauen.
Von mir auch nochmal vielen Dank an dich und Tobias für die Arbeit, die ihr in dieses Projekt stekt.
Gruß,
Dennis 8)
-
Irgendwie häng ich da in den Meinungen zwischen dirn.
Zum einen ist es sicherlich so das eine Veraltete Architektur nich viele hinterm Sofa holt, aber die Usergemeinde die einen Ersatz für nicht mehr funktionierende Computer benötigen, sei es nur zum Zocken, sinds mal schon wert das Projekt mit alten Standards zu starten, zumal die ganzen Bastelprojekte wie Satandisk dann schon Onboard sind.
Wegen dem hochhieven dieser Plattform zu algemeinem Interesse, war eben bei mir mal im Forum die Frage gestellt ob sich der Clone in eine In-CAR-Lösung umbauen liese.... ... naja war halt ne Idee.
Dem Mainstreem hinterher zu rennen muss man nicht. Ideen sind gefragt! siehe Wii und Nintendo DS, das is nich Mainstreem standard aber solides Grundgerüst mit einer besonderen "Idee".
Vieleicht hat ja einer hier eine Idee wie die Plattform weiterleben könnte - in einer etwas größeren nische "
Gruß Matthias
PS: benötige meinen Clone dann zum zocken ;D
-
Hallo Dennis,
wie du aus meiner Antwort #46 sehen kannst, frage ich mich auch, inwiefern so ein FPGA-Clone Atari etwas bringt. Ich finde es daher auch klasse, dass du hier deine Sichtweise dazu zur Diskussion stellst. Ich sehe allerdings einige Sachen anders.
Dennoch bin ich der Meinung, dass sich die ATARI-Platform durch so einen "Clone" nicht genug weiterentwickelt. Schließlich ist die Plattform an sich inzwischen 22 Jahre alt! Und trotzdem wird versucht, die Bus-Struktur ähnlich zu halten und zu einer CPU, welche 1979 entworfen wurde, kompatibel zu bleiben.
Und deswegen ist es der Königsweg auf Intels x86-Architektur umzusteigen? Die ist von 1978 (laut Wikipedia) und somit noch ein Jahr älter. Der Vorteil der x86er ist doch nur, dass sie so massenhaft verkauft werden, und dass dadurch in vielerlei Hinsicht einiges möglich ist (z.B. Anzahl an Entwickler für die CPU, oder Anzahl der verfügbaren Hardware), was für kleinere Prozessoren/Systeme nicht möglich ist. An sich halte ich aber den Weg für genau falsch. Eine heutige CPU hat doch immer noch die alten Befehlssätze, erweitert um bestimmte Neuerungen (z.B. SSE ab Pentium 3/4).
Ich hatte immer auf den PowerPC gehofft, damit man den alten Ballast endlich los wird.
Das hat zwar wieder einen gewissen Retro-Charme, bringt die Platform als solches aber nicht weiter. Mit einer solchen Architektur bleiben wir in der Vergangenheit kleben. Und somit bleiben wir eine Nische.
Ich sehe keine Chance, auch nicht mit utopischen 20 hauptberuflichen Entwicklern (Hard- und Software), jemals aus dieser Nische raus zukommen. Ich würde sagen bei sechsstelliger Nutzerzahl ist man aus der Nische rausgekommen, aber mit dem FPGA werden wir im unteren dreistelligen Bereich bleiben. Du sagst ja selber, selbst für die 100 Bestellungen müssen wir massiv in anderen Foren werben...
Natürlich kann man sagen, es wäre keine ATARI (ST) mehr, wenn man auf eine 68k CPU etc. verzichtet. Doch ich finde, wir müssen die Chance packen, die sich uns bietet und die ST-Platform auf ein neues Level hiefen. Meiner Meinung nach sollte so viel Kompatibilität wie möglich in der Software stecken, nicht in der Hardware. Und dank Projekten wie Aranym, sind die Ressourcen hierfür mehr denn je vorhanden.
Von den drei Optionen Clone, Upgrade-Board oder Emulation sprichst du dich also für Emulation aus. Das ist aus meiner Sicht durchaus eine legitime und gute Möglichkeit, um z.B. alte Spiele aus der Kindheit nochmal zu spielen, oder aber um alte Daten mit dem zugehörigen Programm nochmal bearbeiten zu können.
Ich habe aber bei Emulation immer das ungute Gefühl, dass man sich dadurch schleichend doch zu sehr von dem eigentlichen System entfernt. Stell dir vor du hast ein Problem, dass du durch ein kleines Programm lösen kannst. Vielleicht würdest du das Programm in einer reinen Atari-Umgebung selber schreiben, oder jemanden dazu ermutigen. Aber auf dem PC mußt du nur kurz aus der Emulation raus, und schon steht dir die benötigte Funktionalität zur Verfügung. Dies wird immer öfter passieren, und irgendwann machst du alles nur noch auf dem Wirt-System (also typischerweise Windows oder Linux, vielleicht noch Mac). Emulation sollte daher aus meiner Sicht nur für diejenigen erste Wahl sein, die wirklich nur wieder die alten Spiele spielen wollen, aber nicht daran interessiert sind das eigentliche Atari-System zu nutzen.
Von der Idee her finde ich ja eigentlich Upgrade-Boards am besten. Aber die zielen meistens auf Falcons, und haben weitere Einschränkungen (welchen Laptop von Atari will man upgraden...). Von daher finde ich Clones nur knapp geschlagen als die zweitbeste Lösung. Die Hauptsorge ist bei denen, dass ich dort immer Sorge vor einer Zersplitterung des ohnehin kleinen Atarimarktes habe.
Meine Vorstellung ist übrigens, dass ich es klasse fände, wenn wir mit einem reinen Atari-System einige der Sachen hinbekommen, die man halt heutzutage mit seinem PC macht. Ich habe z.B. einen über USB anzuschließenden PictureMate. Wäre das nicht klasse, wenn man vom Atari aus echte Photos drucken könnte? Oder man spielt und konvertiert mp3s, vielleicht sogar Videos. Dafür reicht die Leistungsfähigkeit nicht, aber was, wenn man die 68k um soetwas wie SSE erweitert? (genau das wird nämlich massiv von MP3-Software eingesetzt, aber z.B. auch von 3D-Engines, wofür SSE ursprünglich gedacht war) Oder ich fände es unglaublich genial, wenn man mit einem Atari-Laptop ins WLAN-Netz gehen könnte. Es wird sich nicht für alle Ideen jemand finden, der das auch umsetzt, aber der FPGA-Clone gibt die Möglichkeit dazu. Zugegeben, man würde das Teil dann eher so nutzen, wie manch anderer gerne an seinem Auto rumschraubt, nämlich als Bastelprojekt. Aber wenn man dann wieder etwas neues damit geschafft hat, und somit zumindest scheinbar wieder in der heutigen IT-Welt angekommen ist, dann ist das doch das, wofür man sich noch damit beschäftigt. Wenn ich hingegen z.B. aus dem Emulator ein Photo drucken kann, dann lockt das niemanden hinterm Ofen hervor, denn PC mit Drucker zu verbinden geht ja sowieso.
Soviel also zu meiner Meinung zu dem Thema. Gut ist aber glaube ich, dass Wolfgang auch sehr genaue, eigene Vorstellungen zu dem Thema hat (wie auch immer die aussehen mögen). Denn nur mit soetwas wie einer Vision kann es gelingen, so ein Mega-Projekt zu stemmen.
Ciao
Claus
-
Hallo Claus,
vielen Dank für deine Antwort. Obwohl wir in manchen Punkten anders denken, entsteht doch eine konstruktive Diskussion.
Und deswegen ist es der Königsweg auf Intels x86-Architektur umzusteigen?
Ich wollte mich nicht explizit für x86 aussprechen. Meiner Meinung nach kann es auch jede andere Architektur sein, welche mehr Ähnlichkeiten zu m68k hat. z.B. PowerPC oder Coldfire. Letzteres ist ein aufgebohrter m68k.
Ich habe aber bei Emulation immer das ungute Gefühl, dass man sich dadurch schleichend doch zu sehr von dem eigentlichen System entfernt. Stell dir vor du hast ein Problem, dass du durch ein kleines Programm lösen kannst. Vielleicht würdest du das Programm in einer reinen Atari-Umgebung selber schreiben, oder jemanden dazu ermutigen. Aber auf dem PC mußt du nur kurz aus der Emulation raus, und schon steht dir die benötigte Funktionalität zur Verfügung. Dies wird immer öfter passieren, und irgendwann machst du alles nur noch auf dem Wirt-System (also typischerweise Windows oder Linux, vielleicht noch Mac). Emulation sollte daher aus meiner Sicht nur für diejenigen erste Wahl sein, die wirklich nur wieder die alten Spiele spielen wollen, aber nicht daran interessiert sind das eigentliche Atari-System zu nutzen.
Das trifft meiner Meinung nach nur zu, wenn du die Emulation als ATARI-Emulation in einem Non-ATARI System siehst. So habe ich das nicht gemeint, das geht ja heute schon alles.
Ich stelle mir ein ATARI-System vor, welches viele Hard- und Software-Eigenschaften von der ST-Serie erbt. Diese an manchen Punkten (z.B. CPU) aber verbessert. Und dort, wo durch die Verbesserungen Inkompatibilitäten entstanden sind, (z.B. CPU ;)) müssten Softwarekomponenten, welche in das Betriebssystem integriert sind, diesen Teil der original ST-Hardware emulieren. Im Idealfall würde der Anwender garnicht merken, was Emulation ist und was nicht.
Dieser Ansatz würde es ermöglichen
- Die ST-Architektur grundsätzlich beizubehalten,
- Sie aber an entscheidenden Stellen zu verbessern,
- Und trotzdem mit bisher veröffentlichter ST-Software kompatibel zu bleiben.
Und das ist ein Königsweg, weil wir uns weiterentwickeln, ohne altes einfach aufzugeben.
Gruß,
Dennis 8)
-
Hallo Dennis,
Ich wollte mich nicht explizit für x86 aussprechen. Meiner Meinung nach kann es auch jede andere Architektur sein, welche mehr Ähnlichkeiten zu m68k hat. z.B. PowerPC oder Coldfire. Letzteres ist ein aufgebohrter m68k.
OK, einen netten Coldfire-Clone hätte ich auch gerne. Wenn der auf einem genauso guten Board wäre, wie Wolfgang es für den FPGA entwickelt hat, dann wäre so ein Gerät wahrscheinlich durch nichts zu toppen, auch nicht durch den FPGA. Aber das Problem ist dann wirklich, dass man das Betriebssystem soweit erweitern müßte, dass dadurch volle Kompatibilität hergestellt wird. Und somit ist es für den Coldfire-Clone zwingend notwendig, dass sowohl Hardware- also auch Software-Entwickler da zusammenarbeiten. Und das ist für Hobby-Entwickler schon eine zusätzliche Hürde.
Stell dir vor, auch der FPGA-Clone wäre zwingend auf eine Änderung des OS angewiesen. Wolfgang hat vor Jahren mit dem Projekt angefangen. Wer hätte dazu die OS-Änderungen vornehmen sollen, ohne je ein Testgerät zu haben. Wolfgangs Weg, der zu nahezu 100%-iger Kompatibilität führt, halte ich daher für den einzig gangbaren Weg. Wenn dieser Clone dann da ist, dann wird es auch Software-Entwickler geben, die gezielt dafür etwas programmieren, aber der FPGA ist nicht darauf angewiesen.
Wenn ich das richtig sehe, dann gibt es zwei Coldfire-Projekte. Aber passiert da noch irgendetwas? Wenn nein, kennt einer die Gründe? Ich würde tippen, dass Probleme zwischen Hardware- und Software-Entwicklern durchaus auch einen Grund gespielt haben.
War das Problem beim Phenix nicht auch so, dass da die Zusammenarbeit nicht klappte? Die Projekte werden dadurch halt wirklich gleich eine Größenordnung größer, so dass das nur noch durch Unternehmen getrieben werden kann, und nicht mehr privat. Klar hat man dann mehr Möglichkeiten, aber es wird einfach zu unrealistisch, dass da wirklich etwas rauskommt. Und die Gefahr halte ich beim FPGA für relativ gering - ganz anders als bei all den anderen Überlegungen...
Viele Grüße
Ciao
Claus
P.S.: Wolfgang, hoffe du bist gut erholt aus dem Urlaub zurück! Wir sind gespannt auf Bilder ;D ;D :) und vielleicht auf erste Tests ;D
-
Hallo,
ich bin (mehr oder minder) zufällig auf das Thema hier gestoßen und beschäftige mich eigentlich eher mit einem anderen bekannten Tastaturcomputer der mit A anfängt. Hier aber meine 3 Cent...
Beim Coldfire (CF) gibt es mehrere Probleme:
Interface 68k/Atari <-> Coldfire müsste designt werden, es gibt allerdings ein Referenzdesign von Motorola um einen V3 coldfire in ein 68030 System einzubinden.
Der CF kann einige 68k Befehle gar nicht, diese müssen über eine Emulationslibrary z.B. die CF68klibrary (von Motorola/Freescale zur Verfügung gestellt) nachgestellt werden. Das macht das ganze langsamer als nativen Coldfire code.
Einige Befehle gibt es sowohl im 68k als auch CF Befehlssatz verhalten sich aber anders, diese Befehle können nicht abgefangen werden und verhalten sich so wie ein CF Befehl und liefern wohlmöglich falsche Ergebnisse.
Es gibt die Möglichkeit die CF68klib so zu konfigurieren das sie einen virtuellen 68k aufsetzt, dieser hat dann aber weder MMU noch FPU.
Es bleibt die Möglichkeit ohne MMU/FPU zu leben (sofern möglich), selber einen 68k Emulator zu schreiben der FPU/MMU unterstützt, einfach auszuprobieren ob irgend etwas passiert wenn man den Coldfire die "doppelten" Befehle unter der CF68klib so ausführen lässt wie er das gerne möchte, oder ein Coldfire natives System anzustreben, das nur z.B. alte Applikationen die nicht re kompiliert werden können und Probleme machen in einer Art 68k Box ausführt.
Weiterhin hat noch niemand so richtig ausprobiert wie schnell der CF denn 68k code ausführen kann...
Das Positive ist das ein V4 Coldfire mit 400MIPS 25€ kostet während ein 68060 (100 MIPS?) mit 300€ zu buche schlägt und nicht mehr weiter entwickelt wird.
Vielleicht ist es besser erst einmal einen 040/060 anzubinden, wenn das klappt und dann noch Lust und Zeit da ist könnte man (mit der gesammelten Erfahrung)probieren sich die Zähne am CF auszubeißen. Anscheinend sind ja alle Bemühungen einen Coldfire als Hauptprozessor für/im Atari oder Amiga zu nutzen bis jetzt nicht über das Prototypen Stadium hinaus gekommen.
-
Hallo zusammen,
ich bin wieder zurück und möchte mich hier gleich noch ein wenig einbringen. Vorweg: zur Leiterplatte gibt's noch nichts neues. Sie ist nochmal zurück zum Hersteller, da der Stoplack nachgearbeitet werden muss (ein Daten-Exportfehler meinerseits). Zu den Ausführungen bezüglich Coldfire und 'where shall we go': ich finde nichts besonderes am Coldfire. Es ist im Prinzip eine um einige (viele) Befehle abgespeckte CISC-CPU. Der einzige Vorteil, den ich sehe ist wohl ihre Geschwindigkeit. Da kommt man mit einer FPGA-CPU nicht mit. Die 1MIPS des 68000 sind kein Problem, vermutlich auch 10MIPS nicht und vielleicht gehen auch 50MIPS mit Optimierungen. Aber die 400 sind nicht zu erreichen. Auf der anderen Seite: braucht man das für diese Art Hardware? Zu Zeiten der Apollo Workstations wurden wissenschaftliche Rechnungen auf den Maschinen durchgeführt. Und heutzutage braucht jede Computermaus schon einen ARM? Ich denke, dass es ein völlig anderer Ansatz ist, eine Coldfire basierte Lösung zu realisieren. Und wenn schon CPU, Leiterplatte, Custom-Chips und Speicher sowie Spezialcontroller etc. verbaut werden, wieso dann nicht gleich eine 64 Bit Lösung? Und Steckplätze für Hardware wären dann vielleicht auch sinnvoll (PCI-Express). Und wenn dann alles fertig ist, ist die ganze Sache schon wieder veraltet und es geht von vorne los. Weshalb ich das so spitz formuliere: nicht weil ich die FPGA-Lösung favorisieren wollte (die gibt's ja demnächst sowieso). Nein, weil ich Erfahrung mit dem Entwurf komplexer Systeme habe. Und ohne ständig Produktpflege zu betreiben (abgekündigte Chips, geänderte Gehäuse, nicht mehr verfügbare Komponenten (siehe Speichertypen) usw.), ist so ein Projekt schon tot, bevor es in vernünftigen Chargen produziert werden kann. Und wenn man genau hinschaut, dann hat man eben doch nur irgendwie ein System entworfen, wie es vielen anderen in etwa entspricht (meiner Meinung nach nicht besonders innovativ). Ich bin daher eher für den kontradiametralen Weg: so viel wie möglich als Soft-Cores zu realisieren, wenn es geht später auch USB-Controller und Ethernet/MAC etc. Dann müsste gegebenenfalls noch gelegentlich das FPGA gegen ein moderneres getauscht werden und das war's. Die Phys kommen allesamt in relativ kompakten Gehäusen und können daher leicht gegen aktuelle gewechselt werden. Das Suska-Board stellt daher meiner Meinung nach einen guten Kompromiss dar. Es sind neben dem FPGA und ein paar gängigen Halbleitern noch wenige spezielle Bauteile (USB, Ethernet, Audio-Codec) verbaut, um die man in einem ersten Ansatz einfach nicht herum kommt. Später könnte man Chip für Chip in's FPGA verlagern. Ich möchte an dieser Stelle auch nochmal darauf hinweisen, dass der 68030 Core in Arbeit ist und vermutlich einiges schneller arbeiten wird, was unter anderem im verkürzten Bustiming und den 32Bit Zugriffen (allerdings nicht auf diesem Board) begründet ist. Vielleicht sollte man klein anfangen, ohne gleich nach den Sternen greifen zu wollen. Und mit klein meine ich ein System, welches noch vor einigen Jahren zigtausendfach seine Dienste geleistet hat. Ich bin Claus' seiner Meinung, das System um Komponenten zu erweitern, die Sinn machen und auch was bringen (vielleicht einen MP3-Decoder in Hardware ... oder Video...). Und last but not least: ich habe nachdem ich irgendwelche Systeme entworfen habe jedesmal ein Gefühl dafür, ob es jetzt ein guter Wurf war oder eher Standard. Über das Suska-Board denke ich, dass es ein guter Wurf war, da genau abgewogen wurde, was nun drauf soll und ich habe auch nicht versucht, hier mit dem Brecheisen irgendwelche Strukturen anzulegen, die vielleicht irgendwann mal gebraucht werden könnten (im Speziellen denke ich da an einen geteilten 16/32 Bit Datenbus). Das System ist 16 Bit, weitgehend kompatibel zur alten Hardware, aber keinesfalls so gestaltet, dass wir 'alten Sachen' nachhängen müssen. Im Gegenteil: ich denke, dass es durch die Vielfalt seiner Schnittstellen geradezu einlädt, Erweiterungen vorzunehmen. Da stünden beispielsweise USB-Maus, USB-Tastatur, Audio-Features, Grafik-Modi, Energiemanagement, SP/DIF Ethernet, Erweiterungsports für Funklösungen usw. und Sachen, die erst dann erfunden werden, wenn man mal sieht, was das System alles kann.
Viele Grüße
Wolfgang
-
Wolfgang, ich bin ganz deiner Meinung und Willkommen zurück!!
Zum Thema Coldfire habe ich was für euch.
Nämlich ein bereits Lauffähiges Coldfirboard von Freescale.
Didierm hat darauf das Tos von der CT60 angepaßt, wenn ich das geld über hätte würde ich mir ein Board bei Farnell bestellen und mal Testen. Aber leider ist das Geld nicht da, daher werde ichs wohl auch nie Testen können :-[
http://perso.orange.fr/didierm/ct60/ctpci-e.htm
-
Hallo Ingo,
mich interessiert auch sehr, wie das Board mit einem
angepassten TOS läuft.
Ich würde mich an den Kosten für die Anschaffung beteiligen.
Unter http://www.produkte24.com/ctp/2240/9/full/
habe ich von einem Preis von 299 Euro gelesen.
Vielleicht gibt es ja noch ein paar, die sich an den Kosten beteiligen.
Gruss Martin
-
Aber die 400 sind nicht zu erreichen. Auf der anderen Seite: braucht man das für diese Art Hardware?
Ich sage es jetzt einmal so:
68060 Beschleuniger sind sehr beliebt und teuer was wohl auch darin begründet liegt das eine der Hauptkomponenten einen Katalogpreis von 300€ mit sich bringt. Stellenweise werden diese Beschleuniger dann von 50MHz auf 100MHz übertaktet, ein gewisser Bedarf an "mehr MIPS" scheint also da zu sein...
Der CF ist (wahrscheinlich/hoffentlich) ein wenig schneller als ein 68060@100 und kostet nur ein zwölftel, das macht ihn für gewisse Überlegungen interessant...
Ich finde den CF interessant weil er leistungsmäßig halbwegs zu den "alten Tastaturcomputern" zu passen scheint. Ein 3 GHz PPC auf dem ein 68k Emulator läuft würde mir "etwas" zu viel Abwärme produzieren und währe wahrscheinlich unverhältnismäßig schnell im Gegensatz zum Rest des Systems.
Vielleicht sollte man klein anfangen, ohne gleich nach den Sternen greifen zu wollen.
Ja das stimmt, sonst verhaspelt man sich wahrscheinlich in der Komplexität des Projektes. Wobei Du ja schon mehr als "kleines" geschafft hast...
Didierm hat darauf das Tos von der CT60 angepaßt
Die Seite habe ich auch schon gefunden, aber die letzten News sind auch schon etwas her, auf jeden Fall interessant...er hat ohne große Probleme ein 68k System darauf zum laufen bekommen...
-
Noch kurz zwei Gedanken,
1. es ist im Prinzip natürlich möglich, x-beliebig viele CPUs durch vier Codezeilen zu configurieren. Das bringt dann x-fache Leistung, wenn die Software mitmacht.
2. Es wurde überhaupt noch nicht diskutiert, dass diese Hardwareplattform rekonfigurierbar ist (zur Laufzeit). Das heißt, dass sie als Toaster oder Computer oder Waffelesien konfiguriert werden kann, also ganz nach persönlichen Bedürfnissen. Das heisst aber auch, dass die Betriebssysteme und die Software nicht den ganzen Ballast (alles können zu müssen) mitschleifen müssen. Das bringt wieder y-fache Lesitung.
Ciao
Wolfgang
-
Guten Morgen,
Wolfgang, also dein Weg ist auf jedenfall der Beste und wohl auch der Kompatibelste!!. Und wohl auch die Zukunft. Also ich denke wir sollten dich Seelisch und Moralisch etwas unterstützen ;D . Ich denke mehrere System sind schon gut, da es warscheinlich ja auch verschiedene Einsatzgebiete und auch Nutzer gibt. Was aus dem ACP wird weiß man ja garnicht.
-
Und wohl auch die Zukunft. Also ich denke wir sollten dich Seelisch und Moralisch etwas unterstützen
Na auf alle fälle Hut ab... so etwas als Hobbyprojekt durchzuziehen. :)
-
Hallo Wolfgang,
willkommen zurück. Hoffe der Urlaub hat für etwas Erholung gerreicht.
Kommen durch den nachzuarbeitenden Stoplack nochmal deutliche Kosten auf dich zu, oder wird das auf Kulanz gemacht? Schon eine Idee, wann mit der korrigierten Version zu rechnen ist?
1. es ist im Prinzip natürlich möglich, x-beliebig viele CPUs durch vier Codezeilen zu configurieren. Das bringt dann x-fache Leistung, wenn die Software mitmacht.
Das klingt super. Weil ich muss dir quasi von Berfuswegen widersprechen, wir brauchen immer mehr Rechenleistung (dass muss ich sagen, habe lange eine Cray mit 512 Alpha-Prozessoren programmiert, teils in Assembler; weiter habe ich eine ApeMille programmiert, aber die kennt wahrscheinlich niemand...)
Insofern ist die Möglichkeit leicht etwas erweitern zu können eine wichtige Option für die Zukunft. Wobei man da nicht in einem Sprung alles schaffen muss, dann strengen sich die Software-Entwickler nicht mehr an ;) Aber wenn wir dann z.B. 2009/2010 einen Multi-Core-Atari bekommen, dann ist das doch ein Ausblick. (wobei ich vermute, du hast mit diesem Gedanken mehr verraten als du eigentlich wolltest; meines Erachtens wäre der Milan 1 besser gelaufen, wenn nicht gleich ein Milan II angekündigt gewesen wäre)
2. Es wurde überhaupt noch nicht diskutiert, dass diese Hardwareplattform rekonfigurierbar ist (zur Laufzeit). Das heißt, dass sie als Toaster oder Computer oder Waffelesien konfiguriert werden kann, also ganz nach persönlichen Bedürfnissen. Das heisst aber auch, dass die Betriebssysteme und die Software nicht den ganzen Ballast (alles können zu müssen) mitschleifen müssen. Das bringt wieder y-fache Lesitung.
Verstehe ich nicht ganz. Soll das Betriebssystem jetzt den FPGA quasi nachkonfigurieren, je nach anstehender Aufgabe? Wenn das so gemeint ist, ist sowas wirklich gut (das ist nicht die Frage, ob das Performance bringt, sondern die Frage, ob soetwas für eine Atari-Plattform wünschenswert ist)?
Viele Grüße
Ciao
Claus
-
@TiggyTamal: Entnehme ich deinen Zeilen richtig das du weist wie man einen (USB)Treiber programmiert ;D
@Wolfgang: Das der Core jederzeit neu konfigueriert werden kann ist eine Super Sache, aber erst sollte man die Basistreiber schreiben. Solche möglichkeiten in ein Betriebssystem oder Anwendung JETZT schon mit einplanen würd ich(nur mein Gedanke) erstmal nich. Denn ohne Basistreiber gibts auch für einen in sich wandelnden Computer von vielen vieleicht nur ein lächeln(Nach dem Motto: ...das kann er aber meine Maus bekomm ich nich zum laufen).
Nachdem ich mich mit solcher Programmierung nich auskenne hier mein Aufruf: An die Tasten fertig los.
Gruß Matthias
PS: Läßt sich eigentlich mit ner NetUsBee auch schon ein bischen Treiberschreibenvorarbeit leisten oder MUSS man auf den Clobe warten um damit beginnen zu können. ???
-
Ich tendiere so vorzugehen, dass von mir das Basissystem den ehemaligen STEs entsprechend bereitgestellt wird. Zusätzlich eine Anbindung an die USB und Ethernet Hardware (via Registermapping). Und erst wenn das Teil am Netz ist und USB Maus und Tastatur evtl. Massenspeicher gehen, würde ich nachschieben und eventuell den 68K+ Core (68020/30/40 kompatibel? - hoffentlich!) oder neue Videomodi nachschieben. Wenn sich niemand für die Treiberentwicklung findet, würde ich vermuten, dass wir uns dann auf der Stelle bewegen werden.
Wolfgang
-
So würde ich das auch, sehen. Erst einmal ein Erreiichbares Ziel setzen, und dann weiter ausbauen. Treiberentwicklung muß man dann schauen, wie, wer wann.
-
Hallo Matthias,
@TiggyTamal: Entnehme ich deinen Zeilen richtig das du weist wie man einen (USB)Treiber programmiert ;D
Oops, ich weiß nicht auf welche meiner Aussagen du dich genau beziehst, aber irgendwo habe ich mich da zu weit aus dem Fenster gelehnt. Ich weiß aktuell (noch) nicht, wie man diesen Treiber schreiben kann.
Ich habe mich in USB eingelesen, und ich habe auf anderen Systemen schonmal etwas systemnäher programmiert (im Wesentlichen OS/2, bei Linux hatte ich anfangs keine Zeit, und hab so irgendwie nie den Dreh gefunden). Auf dem Atari habe ich diesbezüglich keinerlei Erfahrungen. Tatsächlich ist es so, dass ich noch nie ein lauffähiges MiNT-System gesehen habe - geschweige denn dies irgendwo installiert habe (und ja, shame on me, Aratux habe ich runtergeladen, aber noch nicht ausprobiert). Ich habe auf einem Rechner MagiC (6.1?) installiert, und kenne sonst fast nur das reine TOS.
Allerdings habe ich tatsächlich vor, den USB-Treiber zu schreiben. Man kann sich ja auch in etwas Neues einarbeiten :) Wenn ich meine Hardware-Probleme in den Griff bekomme (nachdem der Rest funktioniert, spinnt plötzlich der Monitor), dann habe ich vor, noch dieses Wochenende MagiC runterzuschmeißen und mal MiNT zu installieren. Und dann mal sehen, wie man dafür Treiber schreibt (hat jemand zufällig einen guten Link?). Entweder über andere Treiber als Beispiel oder die Mailingliste wird das schon funktionieren.
Um auch auf Wolfgangs Post zu antworten, mein Ziel wären Maus, Massenspeicher, Tastatur und Drucker, in der Reihenfolge, wobei das mit dem Drucker wahrscheinlich recht aufwändig wird, so dass ich mir dort von Anfang an erstmal nur rudimentäre Unterstützung vornehmen würde. Bevor dann Scanner, Joystick und andere dran kämen, könnte ich mir noch vage vorstellen, danach erstmal diverse Adaptoren zu berücksichtigen, z.B. Parallel-to-USB. Wenn diese Treiberentwicklung dann dazu beitragen sollte, dass anschließend ein neuer FPGA-Clone kommt, so fände ich es gut, wenn ich danach noch HighSpeed (zusätzlich zu FullSpeed) angehen könnte, zumindest für die Massenspeicher. Ob ich Hubs angehen muss, wird dann die Praxis zeigen (an PCs kenne ich niemanden/kaum jemanden, der die nutzt, allerdings bringt ein PC auch genügend Anschlüsse mit...). Und ein persönlicher Favorit von mir wäre ja noch WLAN über USB (mein Vater hat jetzt sowas für seinen alten Laptop, cool...)
Bevor ich aber wieder sagen muss, dass ich mich zu weit aus dem Fenster gelehnt habe, hier nochmal der Hinweis, dass das meine Ideen dazu sind. Mal sehen was wirklich realisierbar ist. Vielleicht bin ich hinterher "nur" über Maus und Tastatur froh.
PS: Läßt sich eigentlich mit ner NetUsBee auch schon ein bischen Treiberschreibenvorarbeit leisten oder MUSS man auf den Clone warten um damit beginnen zu können. ???
Wenn dem nicht so ist, dann haben wir ein Problem (sofern wir auf USB warten). Ich hatte schonmal (allerdings glaube ich in einer privaten Mail an Wolfgang) geschrieben, dass ich mit mindestens einem Jahr Entwicklungszeitraum rechne - wenn nicht mehr. Da ist noch kein vernünftiger Test mit drin. Dieses Jahr ist glaube ich die Untergrenze. Kann man ja abschätzen, indem man sich mal die Entwicklung des bisherigen USB-Treibers für die Maus ansieht. Und die ist halt wirklich nur ein Teil vom Ganzen!
Ursprünglich war ja ein anderer USB-Controller für den FPGA-Clone angedacht. Der wäre von der selben Firma wie der für die NetUSBee, und die beiden Controller hatte ich schonmal verglichen, da gibt es nur minimale Unterschiede in der Erkennung der beiden (bzw. der Erkennung der angeschlossenen Geräte), aber die eigentliche Kommunikation mit dem Gerät wäre exakt identisch gewesen. Somit wären wohl 95% der Treiber identisch gewesen, wobei man allerdings stets mit den 5% Unterschied anfangen müßte.
Wie das jetzt mit dem neu ausgesuchten USB-Controller aussieht, der ja von einer anderen Firma kommt, kann ich noch nicht sagen. Aus abstrakten Überlegungen würde ich allerdings vermuten, dass es ebenso aussehen sollte, auch wenn man vor Überraschungen nie sicher ist.
Wie auch immer, ich hab mich bei Ingo bereits für eine NetUSBee angemeldet, und werde damit dann mal loslegen. Im Idealfall unterstützt der Treiber dann nämlich beides: NetUSBee und FPGA.
Viele Grüße
Ciao
Claus
-
Hallo,
zu dem Problem Treiber.
Nunja vielleicht sollte ich erstmal was zu Mint sagen , für diejenigen die Mint nicht kennen.
Mint ist ein Port des bekannten BSD Unix und daher auch sehr ähnlich, was uns jetzt hier zu gute kommen könnte
http://www.bsd.org/
Als ansatz könnte man versuchen für den USB Chip einen Treiber aus der UNIX/Linux Welt zu bekommen, eventuell sogar im 68k Code. Diesen Treiber müßte man nun nehmen und an Mint anpassen.
Was da gemacht werden muß und welcher Umfang das mit sich führt bin ich momentan überfragt.
Aber es gibt sicherlich Programmierer aus der Mintr Reihe die da Unterstützung und Anleitungen geben können.
Ich denke da an altf4, ozk, .... .
Wenn dann dieser Treiber steht, kann man sich an die ersten Device Treiber für USB machen. Was sehr schwierig werden wird sind Drucker. Wobei ich hier schonmal die Idee hatte den Cups Server zu Portieren, dann müßte man dazu eine GDOS (NVDI) Treiber Schreiben der als Client auf den Cups Server zugreifen kann.
Wie gesagt ich binnicht der Große Programmierer ich kann kleine Sachen machen aber bei größeren Sachen hört es dann auf.
-
@Claus: ich habe bei der Auswahl des Ethernet Chips bereits darauf geachtet, dass es Treiberunterstützung in der BSD Ecke gibt. Es gibt welche. Bei USB glaube ich auch. Da lass ich Jens, meinen Partner, mal recherchieren, er ist da fix drin. Ich werde ihn motivieren, ein paar Infos zusammezustellen. Er könnte sicherlich bei der Treiberentwicklung mithelfen. Er hilft gerade bei den systemnahen Softwareteilen zum Board (Bootloader für Configware und Firmware, System-Microcontroller, der die Netzteile steuert..).
Wolfgang
-
Hab etwas gefunden in dieser Richtung, hoffe das hilft etwas
http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=143&tracker_item_id=2693
http://blackfin.uclinux.org/gf/download/trackeritem/2693/2458/isp1761hc-2.0.0.0-bfin.tar.gz
TSchau Ingo
-
Sieht doch gut aus. Bin allerdings jetzt beim Kunden, werd mir das aber übers Wochenende genauer ansehen!
Hab etwas gefunden in dieser Richtung, hoffe das hilft etwas
Ciao
Claus
-
Sorry, ich habe bereits an der Leiterplatte weitergearbeitet und zusätzlich einen anderen USB-Chip in's Auge gefasst: MAX3421E. Momentan habe ich den Eindruck, dass die ISP176x das Routing-Konzept der Leiterplatte aufbrechen und auch schlichtweg zu groß sind. Kurze Erläuterung: ich habe beim Entflechten der Leiterplatte darauf geachtet, dass keine T-Daten- und Adressbus Strukturen entstehen. Der Datenbus verläuft relativ 'laminar' von links oben über die Mitte der Platine nach rechts oben (etwa bananenförmig). Der ISP1761 würde diese Struktur gänzlich aufbrechen da er 16 Datenleitungen benötigt, 23 Adressleitungen und einige Steuersignale. Ich habe dann mit Jens diskutiert und wir sind übereingekommen, dass wir den Full-Speed Mode auf diesem Board nicht schaffen werden. Daher habe ich nun den MAX3421 in's Auge gefasst, der sehr elegant via high speed peripheral interface an den FPGA angeschlossen werden kann. Ferner ist der 'Footstamp' kleiner und das Chip passt auch vernünftig auf die Leiterplatte. Als Abfallprodukt bleiben sogar ein paar freie FPGA Pins übrig, die man für anderen 'Unfug' verwenden könnte. Meines Erachtens wäre dieser Chip die ausgewogenere Alternative. Der ISP1761 ist halt ein leistungsfähiges Teil, welches am besten in 32Bit Systemen zum Zuge kommt. Sorry nochmals, dass ich versäumt habe diese Info durchzugeben. Ich würde zur Diskussion stellen, ob der MAX ausreicht oder der ISP zwingend erforderlich ist. wenn wir ein High-Speed Teil benötigen, so würde ich das lieber später in einer erweiterten Hardware sehen oder via Extension Slots, da kann wenigstens nichts schief gehen, wenn Leitungsreflexionen auftreten sollten (ausstecken und fertig).
Wolfgang
-
Ist doch kein Problem, denke das ich auf dieser Seite auch Fündig werde.
Ich denke das die Geschwindigkeit keine so große Rolle Spielt.
-
Ist doch kein Problem, denke das ich auf dieser Seite auch Fündig werde.
Meinst du Infos zu dem MAX-Chip? Wolfgang hatte den ja bereits in Antort #99 erwähnt (und es somit nicht vergessen durchzugeben), so dass ich da bereits nachgesehen hatte. Es gibt nicht soviel Infos wie zu dem anderen Chip, aber doch genügend. Komme nur leider aktuell nicht ran, hab die Infos zu Hause...
Ich denke das die Geschwindigkeit keine so große Rolle Spielt.
Anfangs hast du Recht. Aber irgendwann will man mehr. Oder willst du 30 Minuten warten, um die Bilder von deiner Digitalkamera runterzuziehen? Mir (als dummer Anwender) dauert das selbst am PC mit HighSpeed zu lange.
Trotzdem unterstütze ich die Vorgehensweise auch zu 100%. Wir werden HighSpeed sowieso nicht zeitnah realisiert bekommen (vom Treiber her), da steckt nämlich im Vergleich zu FullSpeed eine ziemlich komplizierte Logik hinter. Schrittweise vorzugehen ist auf jeden Fall besser, die zusätzlichen Erfahrungen lassen einen dann vielleicht auch später manches anders machen.
Ich hatte mich bisher übrigens nur etwas in der Linux-Ecke umgesehen. Aber nach den Hinweisen von euch beiden sollte man wohl gezielter auf BSD achten. Keine Ahnung wieviel wir dann wirklich vom Grundgerüst übernehmen können, aber es wäre halt super, wenn wir dann spätestens bei den Geräte-spezifischen Teilen profitieren können, und zwar möglichst nahe am Copy-and-Paste oder automatisierbar. Der Atari-Bereich ist sonst zu klein, um da stets aktuell zu bleiben.
Ciao
Claus
-
Hatte so eine Idee,
jetzte eine frage an Wolfgang. Wie wird der Chip den Hardwaremäßig in das System integriert?
Welcher Adressbereich wird dafür verwendet (welcher wäre den noch Frei dafür).
Man könnte ja versuchen diesen Chip in den Atari zu Integrieren, sollte eigentlich nicht so der Große Aufwand sein oder? Vielleicht kann man das ja aus dem Suska Board übernehmen und für den Atari Anpassen.
Wolfgang, jetzt die Frage an dich, wäre dies Zu Realisieren ? Wenn ja wie, wenn nein dann können wirs ja wieder unter denn Tisch fallen lassen.
-
Hi Ingo,
das mit dem Anbinden des Chips in einen Atari finde ich gar keine schlechte Idee. Dazu ist allerdings eine etwas aufwändigere Logik, die nicht mit GALs zu realisieren ist notwendig. Ich könnte aber zu diesem Zweck eines unserer Sphinx-Boards zur Verfügung stellen. Das ist ein fertiges FPGA-Modul. Die Anbindung könnte ich schreiben. Im oberen Speicherbereich, da wo die Uhrenregister zu finden sind, wäre genügend Platz für die Spiegelregister. Das Ganze läuft dann so, dass die USB-Controller-internen Register in diesen Speicherbereich gespiegelt werden, für den Programmierer quasi transparent.
Wolfgang
-
Guten Morgen zusammen,
die beiden Prototyp Leiterplatten für die Suska-Boards sind nun hergestellt und wieder bei mir im Haus. Heute Abend gibt's ein Bild davon. Wie geht es nun weiter: es wird nun eine Pastenmaske für die Lötpaste hergestellt. Ich habe hierzu gleich die geänderte Prototyp-Version, die nun als 'Series 0001' bezeichnet ist als Grundlage verwendet. Hier sind die Änderungen zu USB und Ethernet bereits eingearbeitet. Auch hierzu werde ich ein Bild bereitstellen. Wenn die Maske fertig ist wird eine Bestückung via Automaten vorgenommen. Damit steht die Hardware. Ich hoffe, dass es im Oktober noch klappt.
Wolfgang
-
Hallo Wolfgang,
na das sind ja neuigkeiten, da freud sich ja des Atarianers Herz ::) .
-
Hallo,
bin wieder sehr spät und meine Kamera taugt nicht viel. Aber hier mal das Bild der Leiterplatte. Die überarbeiteten Schaltbilder lege ich ebenfalls auf den experiment-s Server.
Wolfgang
-
Na das ist doch ne Augenweite ;-) . Jetzt muß sie nur noch bestückt werden. achst du das Per Hand oder hast du dafür ne gerätschaft?
-
Hi,
die Schaltbilder zum Prototyp (Prototype-0001) und zur überarbeiteten Version (Series-0001) liegen auf experiment-s zum Download bereit. Beim Prototyp bleibt es bei den beiden bereits hergestellten Exemplaren, die Series-0001 steht zur Diskussion für eine Nullserie. Ich würde mich über konstruktives Feedback freuen.
Info für Ingo: Die Boards werden teilweise von Hand bestückt (bedrahtet, abgleichbare Teile) und teilweise automatisch (FPGA, Chips mit pitch 0.5 mm usw.).
Viele Grüße
Wolfgang
-
Hallo Wolfgang,
das Board sieht ja sehr gut aus.
Vor allem die enorme Anzahl von Schnittstellen.
2 Fragen haben ich noch dazu:
Es ist ein 15 poliger VGA-Anschluss vorhanden,
welche Auflösungen sind daran möglich?
Welcher Grafikchip ist installiert?
Gibt es für diese Boardvariante eine 68030 oder 040er
CPU zum nachrüsten?
Gruss Martin
-
Guten Morgen,
sorry für die späte Antwort. Ich möchte die Fragen folgendermaßen beantworten. Der 15 polige VGA Anschluss lässt zunächst einmal 4096 vershiedene Farben zu. Das liegt an der einfach angelegten Hardware, wie sie in den STEs vorhanden war. Die Auflösungen sind momentan ebenfalls wie bei den STEs geplant und auch realisiert. Für höhere Auflösungen würde ich irgend eine nicht benutzte Schnittstelle, den Extension Port oder den Extensione Header verwenden und eine DVI Schnittstelle bereitstellen. Die Auflösung und die Anzahl der darstellbaren Farben hängt dann im wesentlichen von der Software ab. Ich werde den Hardwareteil modellieren, nicht aber die Software (Treiber) schreiben.
Ich arbeite momentan an einer 68040 kompatiblen CPU. Allerdings ist diese ein ganz anderes Kaliber als die 68000 und es kann somit noch eine Weile dauern. Erste Tests sind bereits durchgeführt und es sieht so aus, als ob sie grundsätzlich läuft.
Viele Grüße
Wolfgang
Nachtrag: Ich möchte in diesem Zusammenhang nochmals anmerken, dass es sich bei dem Board um eine 16 Bit Architektur handelt, so wie damals bei den STs, STEs, Mega STs, Mega STEs und dem Falcon. Obwohl ein 68030, 68040 bzw. ein mit damals hohem Hardware(gebastel)aufwand eingesetzter 68060 schneller arbeitete (Buszugriffe, Taktfrequenz, Caches) kann die Leistungsfähigkeit dieser Prozessoren aufgrund der 16 Bit Architektur nicht ausgeschöpft werden. Dazu wäre ein anderes Board notwendig:)
-
Gibt es eigentlich irgendwelche News zu diesem tollen Projekt? Auf der HP des Thread-Erstellers ist leider auch nichts zu finden.
-
Wolfgang hat mir geschrieben, das die Boards bestückt sind und demnächst getestet werden.
Gruß Matthias
-
Hallo zusammen,
ppera von Atari-forum.com würde helfen Treiber für das Board zu schreiben.
Gruß Matthias
-
Guten Abend an alle,
die beiden Prototyp-Boards sind jetzt bestückt. Erste (amateurhafte) Bilder gibt es unter www.experiment-s.de im Downloadbereich. Beide Boards haben die ersten kritischen Tests bestanden, die verschiedenen Spannungsversorgungen laufen akkurat und es sind auch keine Kurzschlüsse auf den Versorgungsleitungen vorhanden. Das erste Einschalten war insofern kritisch, da es sich eben um die Prototypen handelt, mit allem was so passieren kann: falsche Bauteile, Bestückungsfehler, Lötfehler, falsche Bauteile-Macros (ganz blöd, wenn das am FPGA passiert). Die Stromaufnahme der (noch unkonfigurierten) Elektronik ist gering. Es gibt bisher auch keine Bestückungsprobleme wie zu enge Abstände oder falsche Bemaßungen. Also bisher toi-toi-toi noch fehlerfrei. Jens ist mit dem Konfigurationsmodul, dem Power-Controller und dem Flash Boot-Loader beschäftigt. Ich plane momentan gerade einige VHDL Testprogramme für all die Hardware. Ich melde mich wieder wenn's klappt.
Und noch was:
ich freue mich auch über Feedback zu den Boards, wenn sich jemand die Mühe macht und die Bilder anschaut.
Viele Grüße
Wolfgang
-
Ähh bin ich zu blöd, oder hab ich tatsächlich keine Berechtigung die Bilder zu sehen ???
Forbidden
You don't have permission to access /Suska-III Classic/Images/Prototype/IMG00679.jpg on this server.
-
Bilder liegen jetzt im Zip-Format zum Download bereit.
-
Wow wow wow, man mein Herzl hüpft förmlich solch Augenweite zu sehen, echt Klasse Arbeit. Wolfgang weiter so, das wird was feines.
-
Wow....da seh ich, dass sich die Spende gelohnt hat.
Freu mich schon das erste Exemplar in meinen Händen zu halten. ;)
Weiter so!
-
Ich will ja nich immer der sein der meckert,
aber ist euch die Leiterplatte im Flussmittel beim Schwall abgesoffen oder habt ihr da so seltsame Paste.
PS: Die Chips haben zu viel Zinn und es kommt sichtlich zur Lotkugelbildung. Anpassung der Schablone bei Serienfertigung ?
PSS: Bin Privat in eurer Gegend am Freitag den 7.12. Darf man das Board auch Live mal sehen :-)
PSSS: Ich find das Projekt und das erste Ergebnis absolut Klasse, hoffe ich bekomm noch eins trotz meines gemkere.... ;D
Gruß Matthias
-
Hallo,
nur kurz zur Erläuterung: FPGA, die TQFP, die QFN, SSOP, Seicher und Flash sind automatisch bestückt. Der Rest wurde von Hand bestückt, da noch einige Bauteile vermessen werden mussten. Daher die Lötpaste en masse und viel Zinn. Die Lötungen sind aber ok. Und gereinigt ist es bisher auch nicht. Das wird erst gemacht, wenn alles funktioniert und kein Lötkolben mehr ran muss.
Wolfgang.
-
Hallo zusammen,
die neue Configware liegt seit eben auf dem experiment-s Server. Die Implementierung auf die Suska-III Hardware läuft gut. Die CPU braucht aber Mithilfe. Siehe die Readme Files im 2K7B Verzeichnis. Wäre nett, wenn Ihr diese Info streuen könntet, um eventuell noch mehr Leute zu finden, die Infos haben / beschaffen können.
Schöne Feiertage
Wolfgang
-
Hallo,
na das sind doch feine Neuigkeiten. Ach ich kann nix von experiment-s.de laden, kommt immer Forbidden.
-
Hi Ingo,
das Downloading sollte funktionieren. Nur mit den Bildern ging das damals nicht.
Wolfgang
-
Sorry, kann gar kein File laden, kommt immer Forbidden!!
-
Das Projekt ist klasse!
Da ich eher zu den Hardwarebastlern gehöre, habe ich enormes Interesse an dem freien Platz im FPGA. Die kombination eines Grafischen OS mit den Fähigkeiten programmierbarer Logik, macht das Board zu etwas wovon mir das Wasser im Mund zusammenläuft. :-)
Zwar habe ich mich bisher nur Oberflächlich mit FPGAs auseinandergesetzt, aber mit einem TOS, das möglicherweise die Programmierung indirekt (oder gar direckt? BIOS Erweiterung?) unterstützt, hätte man ein System zur Hand auf dem man bequem, schnell und komfortabel entwickeln/testen kann. (keine mühevollen Lötereien mehr wie der Einbau eines zweiten MFP im STE :-) )
Genial wäre wirklich eine BIOS/XBIOS Schnittstelle zum einschleusen von weiterem FPGA-Code.
So ein paar Sachen, die man machen könne fallen mir spontan schon ein. z.B.:
- Laufwerk B: als Ramdisk im unbenutzten Berich des RAMs, sammt Umschaltung für mehrere Diskimages.
- Laufwerk c: (ROM-DISK) direckt in das FPGA/RAM gepackt.
- RAM als "Hardware" FestpattenCache, sammt Zurückschreiben beim Ausschalten. (schont die CF-Karte)
- Live-Switch zwischen zwei laufendes TOS-Systemen (Suspend-to-Disk/Ram)
- watchdog
- Stromsparen durch Deaktiviereung/Entfernung von "unwichtigen Hardwarebestandteilen"
-Implementierung von Systemfunktionen im FPGA.
Sicher gäbe es noch andere "Erweiterungen" die auch einfache Anwender interessieren. Das wäre eine völlig neue Art der Systemerweiterung.
Aber ich presche schon zu weit vor.
Erstmal möchte ich ein Lauffähiges Board in ein leeres MegaFile30 Gehäuse verbauen. (Sollte noch genug Platz für ein paar Basteleien... :-)
-
Hallo,
nach längerer Zeit Abstinenz möchte ich mich zurückmelden. Aufgrund meiner Arbeitsbelastung konnte ich das Projekt nicht so schnell wie geplant vorantreiben. Zusammenfassend sei folgendes gesagt: es ist in der Zwischenzeit eine PC Software entstanden, mit deren Hilfe Configware Updates (für das FPGA) sowie Betriebssystem Updates via im FPGA integrierten Bootloader aufgespielt werden können. Letztere landen im Flash Speicher. Das Board ist mit EMUTOS im Test. Alles scheint in Ordnung zu sein. Lediglich die eingesetzten SD-RAMS machten einen Umbau der originalen MCU, welche für D-RAM entworfen wurde notwendig. Dabei habe ich gleich die Möglichkeit für 16 respektive 64MB Speicher eingebaut, muss allerdings die Kompatibilität zu den Originalen STs berücksichtigen. Die Tests der MCU haben letzte Woche begonnen.
Durch die Updatemöglichkeit via PC-Programmen entfällt das notwendige Programmierwerkzeug (USB-Blaster, 300$). Die PC Software wurde von meinem Geschäftspartner Jens Carroll erstellt. Wir haben einigen Aufwand betrieben, um sicherzustellen, dass kein Bit falsch übertragen wird. Das Hauptproblem, hierbei sind gegeneinander laufende Clock Domains des PCs und des Boards.
Weiteres werde ich zu gegebener Zeit berichten.
Schöne Grüße
Wolfgang
-
Hi,
ich möchte kurz berichten, dass ich nicht verschollen bin. Jens Carroll und ich haben zusammen die letzten Wochen damit verbracht, den Suska Prototyp in Betrieb zu nehmen. Wir haben hierzu emutos 0.83 verwendet, da das Debuggen mit vorhandenem Sourcecode einfacher ist. Es sieht nun so aus, dass emutos bis zur Oberfläche durchbootet, alle Menüs geöffnet werden können, Einstellungen verändert und so weiter. Auch die Melodie läuft ab, wenn auf das linke Feld im Desk-Popup geklickt wird. Es war ein mühsamer Weg bis hierher. Vor allem die CPU musste noch in wenigen aber verzwickten Details optimiert werden. Was momentan noch nicht geht, da wir erst jetzt mit dem Debuggen anfangen, sind die Laufwerke. Einerseits werden noch keine Laufwerke von GEMDOS erkannt und andererseits haben wir 12 Laufwerksicons auf dem Desktop (Screenshot folgt). Es sind zwei unabhängige Effekte, wie wir bis jetzt wissen. Die Hardware läuft recht passabel. Einzig das Compilieren und Fitten des doch recht großen Cores macht in Verbindung mit dem Einhalten der erforderlichen Timings etwas Mühe. Es wird demnächst eine neu überarbeitete experiment-S geben und der Core 2K8A wird pünktlich im Juni kommen.
Ciao Ragazzi
Wolfgang
-
Prima Nachrichten, freu mich schon auf die Screenshoots!!
-
Hallo Wolfgang,
vielen Dank für die kurze Info!
Ich wünsche Dir weiterhin gutes gelingen!
Gruss Martin
-
Hi,
habe versucht, Screenshots auf 200kB zu skalieren. Allerdings sieht man dann nicht mehr viel. Daher gibt's die Bilder demnächst auf experiment-s.de
Grüße
Wolfgang
-
Wau, meinen Respekt, Wolfgang. Ich finde es wirklich toll, mit welchem Ehrgeiz du dieses Projekt vorantreibst.
Gruß,
Dennis 8)
-
Ja, auch der "stille" Leser ist begeistert und freut sich auf das was vielleicht mal aus Eurer Hand zu bestaunen gibt.
Vielen Dank für Dein Angagement!
CU
-
Ich hab da gelesen, das die Hardware mit EmuTOS getestet wird.
evtl sollte die Entwicklung aber auch mit dem Original TOS (2.06 z.B.) getestet werden, da ja auch EMUTOS noch nicht als finale 1.0 Version verfügbar ist und Fehler enthalten kann. Vieleicht kennt ja jemand hier einen der EMUTOS-Entwickler. Ich denke Wolfgang könnte hier auch etwas kooperative Unterstützung gebrauchen.
Gruß Matthias
-
Leer
-
Hallo,
danke für die vielen Blumen. Nun könnte ich tatsächlich Hilfe gebrauchen. Wir haben nun den IP-Core soweit, dass emutos das Floppylaufwerk erkennt. Allerdings funktioniert das Lesen nicht, was daran liegt, dass der DMA Mechanismus nicht anspringt. Ich vermute, dass das nicht am IP-Core liegt sondern an emutos (0.8.3).
Das kann man verifizieren, wenn ein emutos auf einem Mega STE in Betrieb genommen wird, also mit realer Hardware und nicht in einem Emulator. Und dann am besten noch als ROM-TOS Version. Gibt es jemanden, der sich das zutraut und einen Mega STE hat?
Grüße
Wolfgang
-
Hi,
muß es ein Mega STE sein? Denn da habe ich nun keinen mehr, wenn auch ein ST gehen würde dann könnte ich das mal Testen.
-
Hallo Wolfgang,
ich kann dir leider nicht helfen, aber vieleicht nochmal mein Gedanke, den IP-Core mal mit nem Original TOS zu füttern. Dann müsste der DMA theoretisch funktionieren
Gruß Matthias
-
Hab grad noch an nen Entwickler von EMUTOS ein Mail geschrieben mit der Bitte zu helfen.
Gruß Matthias
-
Guten Morgen,
ich bin bereits am TOS 2.06 dran. Das gibt momentan noch Bomben aus. Emutos hat offensichtlich noch überhaupt niemend als ROM-Version getestet. Natürlich geht auch ein ST oder Mega ST. Schön wäre später dann eisn STE, um die Erweiterungen zu testen. Emutos hat noch einige Defizite, die man mit Code füllen könnte (STE Erweiterungen, Blitter ...). Es wäre zunächst mal wichtig zu wissen, ob es auf einer realen Hardware in der Version 0.8.3 läuft. Leider fehlt mir die Zeit. Screenshots von der ersten Applikation nehme ich gerne in die bevorstehende Galerie auf der neuen Website von uns auf.
Gute Nacht und schöne Grüße
Wolfgang
-
Ok wenn auch ein ST geht, dann kann ich das Testen. Da werde ich aber ne Tos206 Karte brauchen nich?
Mal sehen was ich zusammen bekomme.
TSchau Ingo
-
Vieleicht sollte noch jemand der das kann (ich leider nicht) das testen. Am besten ein STE.
Gruß Matthias
-
Ich kann das testen, aber vielleicht kann ich kein ROMS brennen. Wenn jemand mir EMUTOS Roms schicken will dann werde ich es machen. Habe hier verschiedene hardware zum testen, auch eine MegaSTE.
-
Ich habe EmuTOS 0.8.3 mal auf meinem damaligen MegaSTE laufen lassen. Der Rechner bootete in die EmuTOS Oberfläche, ich konnte auf die Floppy zwar öffnen, aber das Inhaltsverzeichnis zeigte nur Müll an.
Ich konnte daher auch keine Programme starten.
Im Moment habe ich aber keinen Brenner. Sonst hätte ich gern geholfen.
Gruss,
Beetle
PS: einen Brenner hätte ich, für den ST am ROMport. Hat da jemand die Software zu?
-
Super,
das erste Lebenszeichen auf echter Hardware. Genau mit den Floppys haben wir auch Probleme. Bei mir springt die DMA nicht an. Ich glaube nach wie vor, dass es irgendwie an emutos liegt. Daher wären weitere Tests auf weiteren MEGA STe sehr sinnvoll. Ich habe einen HILO Brenner der alles kann. Wer Bedarf hat...
Bis dann
Wolfgang
-
Hallo Wolfgang,
habt ihr schonmal mit dem 2.06er Tos getestet?
Ich weiß ist ein Lizenzproblem, aber darüber würdeich mir erstmal keine gedanken machen. Dafür findet sich sicher auch noch ein Weg.
-
Hi,
klar haben wir das TOS2.06 unter der Mangel. Es startet momentan bis zur Meldung 'Memory Test Complete'.
Wolfgang
-
Ich habe eine Antwort von einem Progger von EMU-TOS.
Wer das mal an Wolfgang weiterleiten...
Gruß Matthias
-
Hallo zusammen,
ich möchte kurz darüber informieren, dass Version 2K8A auf experiment-s.de zum Download bereit steht. Bitte diese Info weitergeben. Alles weitere in den Readme Files und auf der Page. Bin die nächsten zwei Wochen nicht erreichbar.
Grüße
Wolfgang
-
Hallo Wolfgang,
die neue Seite gefällt mir sehr gut.
Es geht voran :)
Gruss Martin
-
Die Auswahlbox für Suska-C oder T sollte auf Checkboxes abgeändert werden, da es Leute geben soll die beide Boards haben möchten :-)
-
Hallo,
ich benötige Hilfe, da ich momentan nicht so richtig weiterkomme. Da das originale TOS ab Version 1.02 nicht läuft und das Debugging ohne Sourcecode des TOS nahezu unmöglich ist, habe ich nun die fixe Idee, den Sourcecode des TOS 2.06 aufzuspüren. Ich weiss, dass das vermutlich eine verrückte Idee ist aber vielleicht klappt es doch mit Eurer Hilfe. Wer irgendwelche Infos hat oder vielleicht sich mal etwas Zeit nimmt für 'ne Recherche im Web und etwas rausbekommt, den würde ich bitten, dies an dieser Stelle mitzuteilen. Irgendwo müssen die Sourcecodes ja schließlich rumliegen.
Viele Grüße
Wolfgang
-
Hallo Wolfgang,
setz dich doch einmal mit Michael Schwingen
in Verbindung. Er hat das Tos damals an den Milan
angepasst oder war zumindest im Entwicklerteam mit dabei.
Infogrames hat nicht nur die Rechte am Namen Atari
gekauft, sondern auch das TOS Betriebssystem.
Vermutlich hat das Milan-Team damals den Source-Code und eine Menge Doku-Material zum TOS-Betriebssystem
direkt von Infogrames bekommen.
Die Rechte sind aber soweit mir bekannt ist bei
Infogrames geblieben. Das Milan-Team durfte
aber das TOS weiterentwickeln und vertreiben.
Du kannst Dich ja auch mal an Ali Goukassion vom Falke-Verlag wenden. Er kennt alle die damals mit dem
Milan-Projekt zu tun hatten.
www.falkemedia.de
Über Michael Schwingen gibt es nicht soviel im Netz.
Ich habe nur das gefunden:
http://www.ccac.rwth-aachen.de/~michaels/files/milan/
Du kannst dich aber auch einmal an Ingo Schmidt wenden. www.der-ingo.de
Er hatte mit Michael Schwingen Kontakt wegen seiner
"Milan-Hilfe-Seite".
Es bleibt Dir aber auch noch die Möglichkeit, Dich
direkt an Infogrames in Frakreich zu wenden.
Ich wünsche Dir viel Erfolg!
Gruss Martin
-
Da sind schon Teile verfügbar, schau mal hier rein:
http://dev-docs.atariforge.org/
Unter Source Code:
http://dev-docs.atariforge.org/files/atari_src.zip
-
Hallo Wolfgang,
der 68K IP-Core sieht schon sehr vielversprechend aus.
Ich habe gerade mal deinen 68K mit dem Minimigcore für das DE2 Bord kompiliert. Kick 1.3 startet jetzt und ein Demo lief auch schon fast durch. Mit Kick 2.0 startet der AMIGA-Clone jedoch nicht. Es kann kein großer Fehler mehr sein. In dem Demo traten ein paar Grafikfehler auf. Ich würde fast tippen, daß es mit Schiebe- oder Bitbefehlen zu tuen hat. Ich werde mal meinen CPU-Validator, den ich zum Testen meines 68K-Cores nutzte an deinen Core anpassen. Wäre doch gelacht wenn sich der/die Bug/s nicht finden lassen.
Aber bis hierhin muß ich sagen: sehr gut Arbeit!
Viele Grüße
TobiFlex
-
Wäre es nicht einfach möglich deinen Core aus dem Amigaprojekt in das Projekt von Wolfgang einzuginden. Ich meine warum das Rad(den 68000) nochmal neu entwerfen und debuggen. Oder gibt es da zu viele Hürden? Ist eh verrückt nen Prozessor selbst zu designen wo mal ein ganzen Entwicklerteam dran gesessen ist.
Gruß Matthias
PS: Euer Wissen möchte ich haben - sagt mir bescheid wenn es mal nen Gedankentransponder gibt - euch möcht ich gerne anzapfen.
-
Ich hatte es Wolfgang angeboten. Aber er wird seine Gründe haben.
Wolfgang hat auch versucht alle IO-PINs des original 68000 nachzubilden.
In meinen TG68 Core generiere ich keine FC-Signale und ich denke Wolfgang hat auch versucht das Timing exakt zu treffen. Mir war bei meinem Core die Softwarekompatibilität das wichtigste und das Timing stimmt nur so ungefähr. Für den Amiga ist es aber genau genug. Leider kenne ich den ST zu wenig und weiß nicht ob der mit dem Timing penibler ist. Aber ich muß das ja auch nicht wissen weil Wolfgang das weiß.
Viele Grüße
TobiFlex
-
Hallo,
ich finde es sehr genial, dass Tobias sich zu Wort meldet. Der Grund für den 'eigenen' Prozessor liegt darin, dass Tobias und ich diese etwa zur selben Zeit angefangen haben. Der ST benutzt die FC Signale für das Interruptsystem und zur Steuerung des Supervisor und User Modes. Das alles ist in der Glue verschaltet. Die Idee war nun einerseits, alles so kompatibel wie möglich zu halten und andererseits die ganze Sache in Richtung 68030 weiterzutreiben. daher der 'fette' aber modulare Aufbau des Prozessors. Das Bustiming ist (so hoffe ich) kompatibel mit dem originalen Prozessor. Intern arbeitet er schneller als der originale. Dafür stimmt aber das Prefetch-Verhalten nicht überein. Und last but not least ist halt irgendwo noch ein Bug drin (oder 5 oder 99:) Tobias ist wohl mit seinem CPU-Validator einer der wenigen Personen, die hier weiterhelfen können.
Ich bin auf jeden Fall sehr happy, dass er mithilft.
Bis dann
Wolfgang
-
Hallo Martin,
vielen Dank für die ausführliche Info. Ich werde versuchen direkt über Infogrames in Frankreich einzuhaken. D. Gardner ist seit Frühjar der CEO dort. Dann werde ich auch versuchen Michael Schwingen anzutippen. Allerdings glaube ich nicht, dass er die Befugnis hat Software oder Teile davon weiterzugeben.
Viele Grüße
Wolfgang.
-
Hallo Wolfgang,
Mein CPU-Validator zeigt einen Fehler beim OPCODE 0x4239 CLR.B nnnn.l
Da wird nichts geschrieben. Obs noch andere Opcodes betrifft kann ich nicht sagen weil der Validator bei einem Fehler stoppt. Auch ist der Validator noch nicht 100% an deinen Core angepasst. Es ist auch möglich daß der Validator hier einen Fehler anzeigt der keiner ist. Dashalb mal bitte Simulieren!
Noch eine Anmerkung zum CLR.
Beim original 68K und beim TG68 gibt es zuerst einen Lesezyklus auf die angegebene Adresse dannach wird 0x000000 geschrieben. Dein Core schreibt direkt. Bei einem Speicherzugriff spielt das keine Rolle. Aber ich bin mir nicht sicher ob da vielleicht irgendwelche Chipsätze Wert drauf legen.
Viele Grüße
TobiFlex
-
Ach nee vergiss es! Der Validator stoppt weil er den Lesezyklus beim CLR vermisst. Aber das ist ja in dem Sinne Kein Fehler. Jetzt muß ich dem Validator beibringen, daß er es toleriert.
Viele Grüße
TobiFlex
-
Bugreport!
Der Validator hat was gefunden:
Opcode 0x2108 Move.l A0,-(A0)
Beim 68000 wird der Wert weggeschrieben den A0 vor der Ausführung des Befehls hat.
Der WF68K schreibt den Wert den A0 nach der Operation hat.
Viele Grüße
TobiFlex
-
Ich bin von eurem Wissen immer noch begeistert.
Die letzten Beiträgve waren für mich Bahnhof!
Ich hoffe tobiflex ist ein ganz wichtiger Kopf in einer Entwicklungsabteilung. Das wär ja sonst Verschwendung. CPU-Validator - Was Leute in Ihrer Freizeit so alles machen ! Unglaublich ! ;D 8)
Gruß´Matthias
-
Hi Tobias,
Dein Validator ist ein Überding. Echt genial. Nun, ich habe mir den Core in dieser Beziehung schon mehrfach angeschaut und scheiterte immer an unzureichender Info. Das Verhalten gegebenenfalls richtig zu stellen ist eine kleinere Sache. Ich werde mal ein paar Beispiele anführen, die mir nicht klar sind:
Ausgangslage A0 hat einen Wert X.
MOVE A0,A0:
Die CPU schreibt an die Speicherstelle X den Wert X.
MOVE -(A0),A0:
Die CPU schreibt an die Speicherstelle X den Wert X-2. Oder schreibt sie an die Speicherstelle X-2 den Wert X-2?
MOVE A0,-(A0):
Die CPU schreibt an die Speicherstelle X-2 den Wert X. Oder schreibt sie an die Speicherstelle X-2 den Wert X-2?
MOVE -(A0),-(A0):
Die CPU schreibt an die Speicherstelle X-2 den Wert X-2. Oder schreibt sie an die Speicherstelle X-2 den Wert X-4?
Etwas verzwickt die ganze Sache. Wenn ich genaue Infos bekommen könnte, werde ich es richten.
Viele Grüße
Wolfgang
-
@Matthias: Dem kann ich nur zustimmen. Irre.
dj
-
Vor allem:
Ich versteh schon einiges an elektronik. Ich behaupte einfach mal zu wissen wie prinzipiell CPUs funktionieren(und da gibt es heutzutage immer weniger). Proggn kann ich auch ein bischen aber eigentlich Pascalsprachen (Delphi/Lazarus). Und C versuche ich mir gerade anzueignen(was nicht alles wegen einem Lynx auf sich nimmt).
Aber ne CPU selbst zu designen und dann noch nen Validator SELBST dafür zu bauen - hey das trau ich ein Hochkarätigen Entwicklerteam zu, aber das dies Einzelpersonen in der Freizeit(!!!) machen ist für mich das absolute (ein Hauptwort dazu fällt mir gar nicht ein).
oder wie ein HipHoper sagen würde
ECHT FETT RESPEKT
Gruß Matthias
-
Hi,
also irgendwie komme ich mit dem MOVE immer durcheinander. Es ist wie folgt:
Ausgangslage A0 hat einen Wert X (Word Zugriffe).
MOVE A0,A0:
Die CPU schreibt an die Speicherstelle X den Wert X.
MOVE -(A0),A0:
Die CPU schreibt an die Speicherstelle X den Wert (X-2). Oder schreibt sie an die Speicherstelle X-2 den Wert (X-2)?
MOVE A0,-(A0):
Die CPU schreibt an die Speicherstelle X-2 den Wert X. Oder schreibt sie an die Speicherstelle X-2 den Wert X-2?
MOVE -(A0),-(A0):
Die CPU schreibt an die Speicherstelle X-2 den Wert (X-2). Oder schreibt sie an die Speicherstelle X-4 den Wert (X-2)?
Viele Grüße
Wolfgang
-
MOVE A0,A0:
Die CPU schreibt an die Speicherstelle X den Wert X.
Ist das selbe wie NOP. Du meinst sicher MOVE (A0),(A0) und dann liest und schreibt die CPU die Speicherstelle X.
MOVE -(A0),A0:
Die CPU schreibt an die Speicherstelle X den Wert (X-2). Oder schreibt sie an die Speicherstelle X-2 den Wert (X-2)?
Die CPU liest die Speicherstelle (X-2) und lädt den Wert nach A0. Dabei wird ein 16Bit Wert vorzeichenbehaftet auf 32 Bit erweitert. Oder die Cpu liest die Speicherstelle X-4 und der 32Bit Wert gelagt nach A0.
MOVE A0,-(A0):
Die CPU schreibt an die Speicherstelle X-2 den Wert X. Oder schreibt sie an die Speicherstelle X-2 den Wert X-2?
Die CPU schreibt an die Speicherstelle X-2 den Wert X.
Das ist in deinem Core noch ein Bug.
MOVE -(A0),-(A0):
Die CPU schreibt an die Speicherstelle X-2 den Wert (X-2). Oder schreibt sie an die Speicherstelle X-4 den Wert (X-2)?
Weiß ich auch nicht. Krieg ich aber raus.
Aber erstmal sollte es darum gehen alle praxisrelevanten Opcodes zu validieren. Wenn du Move A0,-(A0) gefixt hast kommt mein Validator an der Stelle auch wieder weiter. Und solange benutzte Opcodes Fehler machen wird er was finden. Ob die Opcodes die in der Praxis nie vorkommen genau wie im original 68000 arbeiten sollten wir später untersuchen.
Viele Grüße
TobiFlex
-
Hallo Tobias, hallo an Alle,
Vielen Dank für die Infos weiter unten. Der Bug mit Ax, -(Ax) ist wohl dadurch (hoffentlich) Schnee von gestern. Aber ich habe noch was wo ich ich Infos benötige. Die Frage möchte ich natürlich gerne an alle stellen.
Vielleicht ist das ja der Grund für das Fehlverhalten des 68K00 Cores. Es geht um folgende Operationen:
ADDA.W
SUBA.W
CMPA.W
Es wird hier jeweils der Source Operand Sign-extended verwendet. Was passiert aber beispielsweise bei:
CMPA Ax,Ax.
Das würde ja immer schief gehen, sobald im Bereich Bits 31 bis 16 von Ax etwas drin steht was ungleich 0x0000 oder 0xFFFF ist.
Bei ADDA Ax, Ax und SUBA Ax, Ax kommt mir das auch komisch vor, dass der Source Operand Sign-extended wird und der Destination Operand, welcher de facto der selbe ist nicht.
Noch haariger wird es beispielsweise bei CMPA Ax, -(Ax). wird hier ebenfalls Ax als Operand verwendet und Ax-2 als Adresse? Und wie sieht es denn hier mit der Sign-Extension aus? Wird da Ax Sign extended aber die Adresse nicht? Mittlerweile habe ich den Verdacht, dass es an solchen Spezialfällen liegt.
Infos diesbezüglich würden der Sache bestimmt weiterhelfen.
Viele Grüße
Wolfgang
-
Lass uns Schritt für Schritt vorgehen.
Jetzt ist erstmal folgender BUG dran:
moveq #$4000,d3
add.w d3,d3
Jetzt müßte das Vorzeichenbit gesetzt sein - ist es aber nicht. D.h. OPCODE 0xD643 ist fehlerhaft.
Zu den Spezialfällen versuch ich mal was zu finden.
Viele Grüße
TobiFlex
-
Hallo Tobias,
manchmal bin ich mit Blindheit geschlagen. Ich habe den Bug. Der betrifft alle WORD-weiten Operationen wie ADD, SUB, CMP usw. Ich kann ihn allerdings erst morgen richten, da ich jetzt auf dem Sprung bin. Du bist ein Profi.
Viele Grüße
Wolfgang
-
Wenn ich von Assembler mehr wissen würde, dann würde ich euch gern helfen. Naja ich werds wohl auch noch lernen :-)
-
So der Vorzeichenbug wurde von Wolfgang gefixt aber jetzt wird es richtig kompliziert! Ich sage nur Interrupt! Der Validator hat jetzt einen Fall gefunden der im Amiga auch praxisrelevant ist. Wird beim Atari ST bestimmt auch so sein.
Über IPL wird ein Interrupt ausgelöst. Genau in dem Augenblick in dem die Interruptstatemaschine gestartet wird, wird der Interrupt an den IPL-Eingängen gelöscht - genau nach dem letzten Zyklus des Befehls vor dem Interrupt. Der IPL-Status im Auslösemoment des Interrupts wird nicht gespeichert und somit wird der Interruptvector von $000060 und nicht von der zum Interrupt passenden Adresse geholt. => Absturz!!!
Viele Grüße
TobiFlex
-
So es geht fleißig weiter:
Opcode: 0x486f PEA
Der auf den Stack geschriebene Wert ist genau um 2 zu klein.
Opcode: 0xc5c1 MULS D1,D2 ist erstmal nur suspekt. Kann die Validatordiagramme noch nicht richtig deuten. Es scheint fast so als würde eine Interruptanmeldung über IPL die Multiplikation aus dem Tritt bringen. Bitte Simulieren!
Viele Grüße
TobiFlex
-
Ok,
ich habe Punkt für Punkt durchgesehen.
Interrupts:
genau in dem Moment, in dem ein Intterrupt in Verarbeitung geht wird er in EXCEPTION_Q gespeichert. Das passiert im Prozess STORE_CURRENT_EXCEPTION. Ich habe beim Entwurf des Interrupt-Handlers auf diesen Punkt geachtet. Vielleicht ist er aber noch nicht ganz korrekt umgesetzt. In emutos und in TOS1.00, welche beide die Interrupts intensiv verwenden, funktioniert alles prima. Ich hatte seinerzeit Fehler drin, was sich in einer springenden Maus, in nicht restaurierten Menüs, in Abstürzen usw. wiederspiegelte. Das passiert aber mit der aktuellen Version unter emutos und TOS1.00 nicht mehr. Daher weiss ich nicht genau, ob der Absturz nicht eine Folge eines anderen Fehlers ist. Vielleicht kannst Du, Tobias, sagen ob so etwas möglich wäre. Also kurz zusammengefasst, Sobald ein Interrupt ausgelöst wird und in Verarbeitung geht, wird der Interrupt Vektor quellen-konsistent verwendet.
Zu den Spezialfällen:
ich habe mittlerweile zu den folgenden Fällen die gleiche Meinung wie Tobias. Diese Spezialfälle waren bisher nicht korrekt, sind aber nun richtiggestellt:
ADDA -(Ax), Ax: es wird zum undekrementierten Wert also Ax addiert.
CMPA -(Ax), Ax: es wird mit dem undekrementierten Wert von Ax verglichen.
SUBA -(Ax), Ax: es wird vom undekrementierten Wert also Ax subtrahiert.
MOVE Ax, -(Ax): es wird der undekrementierte Wert, also Ax nach Ax-2 geschrieben.
Opcode: 0xc5c1 MULS D1,D2:
die Multiplikation dauert lange. Daher wird in dem Systemzustandsautomat im Zustand WAIT_OPERATION auf das Ergebnis gewartet und dann nach FETCH_BIW_1 verzweigt. Erst in FETCH_BIW_1 werden Interrupts, registriert. Die Interrupt-Zustandssteuerung wartet also bis nach FETCH_BIW_1 und dann nach IDLE verzweigt wird. Das steuernde Signal ist CTRL_RDY. Ich kann mir daher nicht vorstellen, dass da was schief geht. Ich würde vorschlagen das mit PEA erst zu richten und dann nochmal zu sehen, ob's nicht weitergeht.
PEA:
das ist vermutlich falsch. Ich werde es richten und Tobias ein Update schicken.
Spezialfälle:
ich habe vor ein Dokument zu verfassen, in dem alle Spezialfälle wie beispielsweise oben beschrieben zusammengestellt sind. Es gibt, wie ich gesehen habe, nicht nur bei uns Diskussionen über diese Dinge. Der Prozessor hat meiner Meinung nach etwa 10 bis 20 von diesen. Ferner ist das Prefetch-Verhalten des Prozessors ein Thema, um auch self-modifying Code lauffähig zu bekommen. Auch hier müsste man eventuell etwas machen.
Viele Grüße
Wolfgang
-
Opcode: 0xc5c1 MULS D1,D2:
Scheint in Ordnung zu sein - sah bloß komisch aus weil nach der langen Multiplikation gleich noch der Amigachipsatz auf den Bus zugriff.
PEA:
Das ist aus meiner Sicht auch im Augenblick der entscheidene Bug.
Interrupts:
Da läuft im Augenblick auf jeden Fall nochwas schief. Manchmal wird der Vector auch von $0000300 geholt.
Aber richte erstmal PEA.
Viele Grüße
TobiFlex
-
Ich habe PEA untersucht und kann nichts entdecken. Es ist nun aber gemäß OPCODE 0x486f so, dass der Stack an der Operation beteiligt ist. Also könnte auch der Stack aus irgendeinem Grund verrutscht sein. Ich habe noch einen Bug in der CHK Operation gefunden (ich habe die auch immer LONG behandelt). Vielleicht hilft das weiter. Ich schicke demnächst ein Update durch. Falls es Deiner Meinung nach CHK nicht sein kann (weil zum Beispiel gar nicht verwendet), müsste ich noch etwas aus der Vorgeschichte zu PEA wissen. Ein Hexdump wäre geschickt, ein Disassembly perfekt.
Kannst Du den Stack sehen? Das würde natürlich auch weiterhelfen.
Viele Grüße
Wolfgang
-
Noch einfacher zeigt sich der PEA-Bug mit OPCODE 0X4857 PEA (A7). Wenn A7=0X00001000 ist muß 0X00001000 nach 0X00000FFC geschrieben werden. Es wird aber 0X00000FFE nach 0X00000FFC geschrieben.
Also ist PEA nur falsch wenn der Stack mit in die Berechnung einfließt.
Viele Grüße
TobiFlex
-
Hallo Tobias,
alles wieder im Lot. Ich habe den PEA gefixt. Das mit dem CHK geht noch nicht. Es gibt aber ein erfreuliches Ergebnis. Mit dem berichtigen PEA bootet TOS 1.62 nun bis zum Desktop und es sieht auch grau aus, wie es sein soll. Die Menüs können bedient werden und es stürzt auch nicht mehr ab. Einzig die Schrift der Menüeinträge ist nach wie vor falsch und nicht zu erkennen. Ich bleibe an dem CHK dran. Wenn ich den CHK einhänge, dann bekomme ich beim Booten zwei Bomben. Vielleicht ein Folgefehler. Wenn Du den CHK ausprobieren möchtest: ich habe den falschen CHK in der ALU eingerückt und aktiviert, so dass er läuft wie bisher. Die berichtigten Zeilen sind ebenfalls in der ALU eingerückt aber auskommentiert...
Viele Grüße
Wolfgang
-
Bugreport WF68K00:
MOVEM (An)+,Reglist macht Murks. Wenn n=7 ist - sprich der SP benutzt wird ist alles OK. Aber wenn n=0 ist wirds falsch. Und ich nehme an bei n=1-6 wirds auch nicht besser. Beispielcode:
move.l #$200,A0
movem.l (A0)+,d0
A0 müßte jetzt den Wert $204 haben. Aber auf wundersame Weise steht jetzt $20C in A0.
Mit movem.w sind es nur 4 zuviel.
DIVS:
move.l #$1000000,d3
divs #$200,d3
D3 wird $8000 - also negativ. Die positiven Werte gehen aber blos von $0000 bis $7FFF. Es tritt also ein Overflow auf, der nicht erkannt wird. Wenn dagegen nur der Divisor oder der Divident negativ ist würde das Ergebnis im Wertebereich liegen und keinen Overflow auslösen da das Ergebnis negativ ist.
Viele Grüße
TobiFlex
-
Hallo Tobias,
kannst Du mir bitte mitteilen, ob die Version von gestern gar nicht geht oder der DIVS jetzt komplett daneben liegt oder hast Du die letzten Bugs mit dieser Version herausgefunden?
Viele Grüße
Wolfgang
-
Die letze version ging garnicht. Die Bugs hab ich mit der vorletzen Version gefunden.
Viele Grüße
TobiFlex
-
Bugreport WF68K00:
Opcode 4CDF FEFE movem.l (a7)+,D1-D7/A1-A7
liest nur 13 Werte vom Stack - es müssen aber 14 Werte gelesen werden.
Viele Grüße
TobiFlex
-
Bugreport WF68K00:
Opcode d201 ADD.B D1,D1
Zeroflag fehlerhaft. Bei ADD.W D1,D1 sicher auch.
Es ist der gleiche Effekt wie beim Vorzeichen.
Bei 0X80+0X80 wird das Zeroflag nicht gesetzt.
Viele Grüße
TobiFlex
-
Hallo Tobias,
movem.l (a7)+,D1-D7/A1-A7 ist ein Sonderfall. Gemäß Programmer's Manual von Motorola wird der Stack A7 im Postincrement Adressmodus nicht mit dem vom Bus gelesenen Wert überschrieben. Daher habe ich diesen Buszyklus unterdrückt, da er sinnlos ist. Auszug aus der Originaldoku (s. letzter Satz).
If the effective address is specified by the postincrement mode, only a memory-to-reg-
ister operation is allowed. The registers are loaded starting at the specified address;
the address is incremented by the operand length (2 or 4) following each transfer. The
order of loading is the same as that of control mode addressing. When the instruction
has completed, the incremented address register contains the address of the last oper-
and loaded plus the operand length. If the addressing register is also loaded from
memory, the memory value is ignored and the register is written with the postincre-
mented effective address.
Bis später
Wolfgang
-
Hi Tobias,
ADD.B Dx,Dy ist gefixt.
ADD.W Dx,Dy ist gefixt.
Danke!
Update schicke ich später.
Bis dann
Wolfgang
-
Hallo zusammen,
Tobias hat ein wunderbares Händchen in Bugs finden. Ich leider nicht so in Bugs beseitigen. Momentan habe ich meine CPU vermurxt. Kann also etwas dauern, bis es hier weitergeht. An dieser Stelle möchte ich nochmal die hervorragende Arbeit von Tobias herausstellen. Ohne ihn wäre es mir kaum Möglich, das Projekt in dieser Intensität voranzutreiben.
Bis dann
Wolfgang
-
Also ich muß sagen ihr seit alle Spitze die daran Arbeiten. Man sieht ja es geht mit großen Schritten vorran.
-
Hallo Wolfgang,
also mit der Version vom 26.08. hast du mir eine echte Nuss geschickt, die ich nicht knacken kann. Der Validator stoppt und zeigt Fehler an aber ich komme nicht dahinter wodurch sie ausgelöst werden.
Die Indizien sprechen dafür, daß es was mit DIVU zu tuen hat. Kann es sein, daß ein DIVU das nächste auftretende DIVU beeinflusst - also daß irgendwas vor oder nach einer Division nicht resetet wird?
Viele Grüße
TobiFlex
-
Hallo Tobias,
ich bin jetzt glaube ich wieder auf der Spur. Es handelte sich bei DIVS und DIVU um einen zweifachen Laufzeitfehler. Das war nicht trivial und ich musste in einigen Modulen Änderungen vornehmen. Ich mache, um sicherzugehen, noch einige Tests. Wenn alles klappt, dann schicke ich Dir heute Nacht noch ein Update. Momentan habe ich mein TOS1.62 Desktop wieder und die Simulation hat auch gut funktioniert. Ich hatte nur noch eine Kleinigkeit übersehen und teste daher jetzt nochmals ausführlich. Ich hoffe, dass Dein Validator jetzt wieder was finden kann. Bei mir fehlt jetzt immer noch die Schrift in den Menüs.
Viele Grüße
Wolfgang
-
Hallo Wolfgang,
leider bin ich erst heute zum Testen gekommen. In der Tat laufen jetzt ein paar Demos mit weniger Fehlern. Glückwunsch. Der Validator stopt jetzt immer bei dem schon beschriebenen Interruptbug. Kümmere dich mal bitte auch darum.
Viele Grüße
TobiFlex
-
Bugreport WF68K00:
Opcode 4CB3 0007 0000 MOVEM.W (00,A3,D0),D0-D2
Der erste Wert wird von der richtigen Adresse gelesen. Die folgenden Leseadressen passen nicht mehr. Vermutlich weil sich D0 verändert hat.
Hab grad noch
Opcode 4CB3 0007 1000 MOVEM.W (00,A3,D1),D0-D2
ausprobiert und da sind die ersten beiden Adressen richtig. D1 wird ja etwas später als D0 verändert.
Viele Grüße
TobiFlex
-
Hallo Tobias,
anbei der Bugfix für MOVEM(d8,ax,index). Ich hoffe es hat geklappt. Mein TOS läuft wie gehabt. Das mit dem IRQ habe ich noch nicht richtig verstanden. So wie ich es auf dem Signaltap-Bild sehe, danke hierfür, kommt IRQ_SAVE dann, wenn die IRQs schon wieder gewechselt haben. Nun ist es bei mir aber so, dass der IRQ_SAVE genau am Anfang des Handlers stattfindet. Das heisst, erst wenn der externe Interrupt abgearbeitet wird, wird er auch gespeichert. Das hat dann zur Folge, dass ein IRQ (zum Beispiel Level 3) einen Pending Interrupt auslösen kann. Wenn aber zum Beispiel eine interne Bearbeitung einer Exception gerade läuft, könnte der IRQ-Level auch wechseln nach einem höheren (z.B. Level 5). Dieser würde dann in die Verarbeitung gehen und gespeichert werden. Warum der Level in dem Signaltap-Plot wechseln, bevor der IRQ_SAVE kommt, verstehe ich nicht. Nach meiner Auffassung müssten die externen Interrupts bis zum Interrupt Access Space Cycle stehenbleiben und erst dann wechseln. Hast Du andere Infos oder könnte es sich um einen Minimig-Bug handeln?
Viele Grüße
Wolfgang
-
So,
der Interruptmechanismus ist jetzt auch geändert. Ich hoffe, dass er funktioniert. Ich bin von 6. bis 19 September nicht in Deutschland. Daher hoffe ich, dass vielleicht Tobias vorher noch etwas mit seinem Validator herausbekommt, da die TOS 1.62 immer noch ohne Schrift in den Menüs hochkommt. Und dass die verschiedenen Kickstarts des Amiga laufen, bleibt zu hoffen. Momentan sind keine offenen Punkte im Core. Alles ist gefixt.
Viele Grüße
Wolfgang
-
Bugreport WF68K00:
OPCODE 2058 MOVE.l (A0)+,A0
A0 muß mit dem Wert aus dem Speicher beschrieben werden. Im WF68K00 bleibt aber der incrementierte Wert in A0.
Ansich ist dieser Opcode sinnlos weil ein MOVE.l (A0),A0 den gleichen Effekt hat, aber er wird Tatsache in manchen Programmen verwendet.
Die Interruptbehandlung passt jetzt.
Viele Grüße
TobiFlex
-
Hallo Tobias,
Du bist ein Profi. Das war der Bug, der das TOS hat alt aussehen lassen. Ich mache den Code kurz zurecht und schicke Dir dann das Update. TOS 1.62 läuft nun komplett. Du hast mir hiermit ein echt schönes Geschenk gemacht, bevor ich fahre.
Ich denke, dass ich den heutigen Tag rot anstreichen werde, das Projekt erstreckt sich ja nun schon über 5 Jahre. Vielen Dank für Deinen super Einsatz. Ich werde bis morgen Abend weitere Bugs rausmachen, falls Du noch welche finden solltest.
Viele Grüße
Wolfgang
-
Hallo Wolfgang,
das sind sehr gute Nachrichten. Deinen Urlaub hast du dir wirklich verdient. Die neue Version probier ich gleich aus. Aber auch mit dem Move (Ax)+,Ax Bug laufen schon sehr viele Amigademos fehlerfrei auf dem DE2-Board. Also wenn jetzt noch Bugs drin sind müssen die schon sehr "exotisch" sein. Aber ausschließen möchte ich das nicht.
Viele Grüße
TobiFlex
-
Hallo,
ich bin ab morgen für zwei Wochen unterwegs. Ich habe einige Tests durchführen können mit folgendem Ergebnis:
TOS1.0 läuft, erkennt aber keine Laufwerke.
TOS1.02 läuft nicht. Beim Booten kommen nach einigen Sekunden Bomben (4 Stück). Ich habe diesen Test ohne jegliche Laufwerke durchgeführt. Weiss jemand, warum hier Bomben geworfen werden?
Beim STBook kommen auch Bomben, wenn keine Laufwerke angeschlossen sind.
TOS1.04 läuft, ebenfalls keine Laufwerke. Wenn ich den Blitter einhänge gibt es Abstürze.
TOS1.62 läuft wie TOS1.04.
TOS2.05 läuft, erkennt Laufwerke, kann aber nicht darauf zugreifen. Der Blitter kann eingehängt werden. Sobald er aber über das Extras-Menü eingeschaltet wird, krachts.
Emutos läuft, erkennt Laufwerke und kann manchmal davon Lesen. Emutos hat bisher keine Blitter-Unterstützung.
Fazit:
Die Laufwerkslogik im Core ist irgendwo noch buggy. Das liegt nicht an der CPU.
Das Blitterproblem liegt an der Bus Arbitration Logik der CPU.
Beide Probleme lassen sich vermutlich relativ systematisch beheben, kein vergleich mit der Schwierigkeit die CPU zu fixen, wie Ihr vielleicht in der letzten Zeit diesem Thema entnehmen konntet.
Wenn ich wieder da bin geht's weiter.
Viele Grüße
Wolfgang
-
Hallo an alle,
ich habe schon eine Weile nichts mehr von mir hören lassen. Nun möchte ich kurz berichten. Zum letzten Status siehe meinen letzten Eintrag. Nun sieht es folgendermaßen aus: Der Suska-III Prototyp läuft nun mit dem IP-Core und TOS2.06 zusammen seit einiger Zeit stabil. Der Blitter funktioniert auch, ich kann über ACSI auf Festplatten zugreifen und DD und HD Floppies sieht er auch. Es gibt noch ein paar Inkompatibilitäten, über die ich mich noch schlau machen muss. Ich denke, dass beispielsweise die alten Megafiles, welche mit 5V laufen, nicht 100% mit der neuen 3,3V Technik zurechtkommen... Momentan arbeite ich am SD-Card Slot, sehe aber noch keine Karte. Ich tippe da auf das Timing, da der IDE Adapter Atari's STBook oder auch Pera's nachempfunden ist und das DTACKn für mich nicht ganz logisch erzeugt wird. Insgesamt macht die Maschine einen flotten Eindruck, zumal die CPU, der Blitter, die DMA und auch der Floppy Controller mit 16MHz arbeiten, dementsprechend die MCU mit 32MHz und das SD-RAM mit 64MHz getaktet wird. Wenn der IDE Port hoffentlich demnächst funktioniert, dann sieht es so aus, wie wenn der Suska IP-Core nach nunmehr fünfeinhalb Jahren in einer ersten, vollständigen und stabilen Version zur Verfügung steht. Da ich momentan etwas mit meiner Firma ausgelastet bin und noch einige Tests anstehen, steht die Version 2K8B, wie auch jede zweite vorhergehende Version am 24.12. zum Download bereit. Wann die Boards verfügbar sind, werde ich noch öffentlich machen.
Ich werde die Umfrage demnächst schließen und auch die Umfrage auf www.experiment-s auswerten, um zu sehen, wie wir weitergehen können.
Schöne Grüße aus Stuttgart
Wolfgang
-
Aah, ich werde jetzt sehr entzückt (ist das ein passendes Wört in dieser kontext?), möchte das gern ein mahl prüfen!
Du beweist das es möglich ist als 'Amateur' ein hardwaremäsige Klon zu produzieren statt ein softwaremäsige.
-
Hallo,
ich habe am Suska Core sowohl CF-Card als auch 2,5" IDE Platten betrieben, allerdings mit folgenden Einschränkungen, benutzt habe ich den HDDRIVER 8.20.
Die CF-Karte lässt sich nur als Master ansprechen, das musste ich umverdrahten.
Die Festplatte ging bisher als Master und ist auf dem Prototyp hart als Master verdrahtet.
Folglich laufen beide Platten nicht zusammen. Kennt sich jemand hiermit aus? Wie kann man eine CF-Karte und eine 2,5" Platte zusammen betreiben? Kann der HDDRIVER prinzipiell von einem Slave booten? Wenn beide Platten zusammen laufen würden, gehe ich dann richtig davon aus, dass der Master das Bootlaufwerk stellt? Und wie sieht es aus, wenn zusätzlich ACSI Geräte hinzukommen?
Ferner zeigt die CF-Karte folgendes Problem: Ich kann sie formatieren und auch Partitionieren. Dann kann der Treiber auf C installiert werden und sie funktioniert soweit. Wenn ich dann aber beispielsweise die NEWDESK.INF anlege, ist die Partition geschreddert. Sind das die gleichen Probleme wie bei einigen anderen von Euch? Die Festplatte zeigt dieses Verhalten nicht. Ich kann sagen, dass die Anschlüsse via Platine zur Festplatte und zu CF-Karte nur etwa 2cm lang sind. Aber das DTACKn Timing ist so, dass der gesamte Buszugriff etwa nur 250ns lang dauert. Vielleicht zu kurz?
Viele Grüße und danke vorab für Antworten.
Wolfgang
-
Du beweist das es möglich ist als 'Amateur' ein hardwaremäsige Klon zu produzieren statt ein softwaremäsige.
Also ich möchte Wolfgang nicht gerade als Amateur bezeichnen. Profi würde eher passen => siehe www.inventronik.de (http://www.inventronik.de)
Gruß Matthias
-
Wie kann man eine CF-Karte und eine 2,5" Platte zusammen betreiben?
Die CF-Karte verhält sich wie eine IDE-Festplatte. z.B Festplatte als Master jumpern, die CF-Karte als Slave. Nach einem Reset reden beide miteinander und dann kann man Master und Slave einzeln ansprechen. Vorausgesetzt, beide "verstehen" sich miteinander! Manchmal hilft auch Master/Slave tauschen.
Wenn beide Platten zusammen laufen würden, gehe ich dann richtig davon aus, dass der Master das Bootlaufwerk stellt?
Kann der HDDRIVER prinzipiell von einem Slave booten?
Nach einem Reset liest TOS (zumindest TOS 2.06) den Bootsektor immer zuerst vom Master. Könnte höchstens sein, das HDDRIVER hinterher trickst
Und wie sieht es aus, wenn zusätzlich ACSI Geräte hinzukommen?
Die Bootreihenfolge ist: 1. SCSI 2. ACSI 3. IDE, d.h. die ASCI-Geräte sind schon vor IDE da
Aber das DTACKn Timing ist so, dass der gesamte Buszugriff etwa nur 250ns lang dauert. Vielleicht zu kurz?
Unwahrscheinlich. Ich habe hier bei Read /IOR 250ns und bei Write /IOW 187ns aktiv. Über IORDY könnte die CF-Karte zwar "verlängern", aber das findet zumindest bei 500ns Zykluszeit einfach nicht statt. Zum Testen habe ich eine 32MB "High Speed" Karte von Canon verwendet (FC-32MH, Hersteller Hitachi).
Gruß, Holger
-
Ich schließe mich Matthias Meinung an. Was Wolfgang und z.T. Jens da auf die Beine gestellt haben, in dieser Qualität und Professionalität, kann man nur wenn man es von der Pieke auf gelernt hat. Wenn die Boards das erste Game vom Diskettenlaufwerk geladen haben und gespielt werden kann dann können wir mal eine Flasche Sekt köpfen :D . Oder besser ein Board bestellen.
-
Guten Morgen,
danke für die Blumen. Ich möchte niemand zum Schampus trinken am frühen Morgen animieren. Die Boards laufen bereits so, dass alle möglichen Anwendungen inklusive diverser Spiele funktionieren. Wir benutzen ja bereits die Festplattentools, Das erste was lief war Asteroids, dann Baller, mit Sysinfo holen wir uns Infos, der Datenaustausch mit dem PC geht momentan mit der Floppy. Wenn die SD-Karte als ok abgehakt werden kann, wird noch die serielle Schnittstelle getestet. Danach werden wir alles auflisten, was die Boards drauf haben und eine Checkliste erstellen. Teilweise werden wir verschiedene Dinge nicht testen können, da der Aufwand für unser kleines Team zu hoch ist (Besipiel: USB-Hostcontroller mit Treiberentwicklung oder Ethernet).
Grüße Wolfgang
-
OK, wo treffen wir uns zum Sekt verköstigen, machma a party beim Wolfgang, Sekt nehm ich mit.
Wenn Asteroids läuft ist ja zu Dungeon Master kein weiter Weg mehr ;D
Gruß Matthias
-
So lange kann ich nicht mehr warten ;D Ich genemige mir jetzt mein Piccolo. Und Wolfgang, ein Screenshot von ein oder zwei Games, die mit Joystick oder Maus gespielt werden fehlt, glaube ich, noch auf deiner Seite.
P.S. Nichts gegen Asteroids, ich meine aber so etwas wie Turrican, Nebulus oder Starglider II. Die dürften an die Kombatiblität schon etwas höhere Ansprüche stellen. Trotz alle dem Wolfgang, Du bist weiter als ich es je gedacht hätte.
-
Tja,
leider habe ich Nebulus nicht. Sonst könnte ich's versuchen und ein paar Screenshots bereitstellen :) Das Problem mit der CF-Karte und den ACSI Drives hat sich verflüchtigt. Ich benutze jetzt als Laufwerk C eine 220MB große Partition auf der CF-Karte. Von IDE nach ACSI-Platte kopieren und umgekehrt geht jetzt gut. Ich habe auch versucht, eine 2,5" Platte als Slave zu jumpern und neben der CF-Karte zu betreiben. Leider wird dieses Laufwerk als Slave nicht erkannt. Sind eigentlich CF-Karten immer Master? Die haben ja keinen Jumper zm Auswählen ob Master oder Slave.
Grüße
Wolfgang
-
Hab Wolfgang grad Nebulus übermittelt ;D
wollma doch mal sehen :-)
-
Hallo Wolfgang, es scheint so das sich die CF-Karten extern als Master oder Slave konfigurieren lassen.
In der Bucht werden CF <> IDE Adapter angeboten wo die CF-Karte per Jumper auf dem Adapter als Master oder Slave angesprochen werden können. Siehe CF-Adapter in der Bucht (http://cgi.ebay.de/CF-Compact-Flash-auf-IDE-ATA-Konverter-Adapter-HighTech_W0QQitemZ160287547896QQcmdZViewItem?hash=item160287547896&_trkparms=72%3A1229%7C39%3A1%7C66%3A2%7C65%3A12%7C240%3A1318&_trksid=p3286.c0.m14) Evtl. werden hier nur ein oder zwei Leitungen auf dem IDE-Bus getauscht oder auf Masse gelegt.
-
:D Ich wollte Wolfgang gar nicht bezeichnen als Amateur... (habt ihr die ' ' gesehen?)... ich meinte er macht das in seiner Freizeit und hat keine Gewinnsucht!
-
Hi,
habe noch 'ne Frage: ich habe nun die 512er CF-Karte eingerichtet und sehe zwei gleich große Partitionen. Dort habe ich ein paar Files abgespeichert. Nun würde ich mir das ganze gerne via Cardreader am PC ansehen und diese Daten auch gerne austauschen. Leider kennt der PC natürlich das Atari Format nicht. Gibt es da irgendeine Lösung?
Viele Grüße
Wolfgang
-
entweder mit HDDriver so formatieren, das sowohl TOS wie auch Windows(DOS) drauf zugreifen kann, oder mit nem tool von ppera
http://www.ppest.org/atari/ (http://www.ppest.org/atari/)
Gruß Matthias
-
Dazu braucht man die HDDRIVER Software. Man richtet auf dem Atari dazu die Partition als Windows/TOS&Windows Kombiniert ein. Dieses funktioniert aber nur wenn man pro Medium oder besser Gerät nur eine einzelne Partition einrichtet ...
grüße
Frank
... habe mal eine Mail mit Software geschickt !
-
Bei der Software von ppera wäre ich vorsichtig, der Bericht, daß sein Treiber zu Datenverlust führt, ist leider korrekt.
-
Hallo Wolfgang!
habe noch 'ne Frage: ich habe nun die 512er CF-Karte eingerichtet und sehe zwei gleich große Partitionen. Dort habe ich ein paar Files abgespeichert. Nun würde ich mir das ganze gerne via Cardreader am PC ansehen und diese Daten auch gerne austauschen. Leider kennt der PC natürlich das Atari Format nicht. Gibt es da irgendeine Lösung?
Da gibt es zwei Möglichkeiten:
1) Bis zu vier Partitionen mit max. je 32MB Größe einrichten
2) Das Medium mit HDDRUTIL neuer als 7.8 (oder so) TOS/DOS kompatibel formatieren (genau eine Partition)
Wenn auf dem Atari-Rechner MagiC 6 oder MiNT läuft, kommt auch FAT32 in Frage, und mit MiNT dann auch noch weitere Dateisysteme.
Linux sollte eigentlich auch Treiber für das Atari-Format mitbringen.
Mit freundlichen Grüßen
Ekkehard
-
Nee Fat32 geht net da ja nur 16bit System, das läuft nur auf einem 32Bit system.
-
Hallo, laut Uwe Seimet in der ST-Computer (http://www.stcarchiv.de/stc1998/10_aktuelles.php) (fast ganz unter auf der Seite), gehts wohl doch. Genau wie Ektus es beschrieben hat.
-
Hallo,
ich habe am PC die CF-Karte formatiert und mit HDDRIVER eine DOS/TOS kompatible Partition (488MB) eingerichtet. Damit kann ich nun Daten zwischen PC und Atari austauschen. Der HDDRIVER ließ sich auch auf diese Partition schreiben aber TOS bootet die Platte nicht. Um die Platte anzusprechen, muss ich per Floppy den Treiber nachladen. Gibt es hierzu einen Trick?
Grüße
Wolfgang
-
Hallo Wolfgang, es kommt wohl schon mal vor das bei Bootpartitionen die größer als 256 MB sind Fehler auftauchen. Vielleicht mal die Bootpartition kleiner machen, bei den Folgepartitionen ist die größe dann nebensächlich. Laut Ektus,wenn ich es richtig verstanden habe, sollte das Medium auf dem Atari formatiert werden und nicht auf dem PC.
-
Ich hab den selben Fehler bei einer SD-Karte mit der Satandisk. Einfach mal anderen Hersteller testen. Gute Erfahrungen hab ich mit Transcent gemacht.
Gruß Matthias
-
Hallo,
vielen Dank für die Informationen. Und es geht weiter: ich habe an Suska-III eben die 14MB Speicher aktiviert (kann man jetzt mit RAM-CONFIG Dip-Switch aktivieren). Natürlich erkennt TOS2.06 diesen Speicher nicht und meldet 4MB. Ist mir auch klar, da es nie mehr als 4MB gab.
Verwende ich aber Sysinfo, so zeigt mir dieses Tool ebenfalls nur 4MB an. Weiss jemand, ob Sysinfo einfach das Memory Configuration Register ausliest, wo ja nur 4MB drin stehen oder macht Sysinfo einen eigenen Speichertest?
Grüße
Wolfgang
-
Sysinfo liest nur die register aus, aber ich hatte da mal ein PD-Tool das sich den Speicher so richtig zur Brust nahm, kann mich aber nicht mehr an Namen erinnern. hmmm werd doch bald 30ig, ich kauf doch mal besser Knoblauchkapseln :P
-
Ist mir auch klar, da es nie mehr als 4MB gab ...
Das ist so nicht ganz richtig!
Es gab früher von GE-Soft und von Martin Wevelsiep Erweiterungen um normale Atari ST Maschinen mit maximal 15,5MB echtem ST Ram aus zu rüsten. Zudem noch der Elrad ST mit 14MB ST Ram ...
grüße
Frank
... keine Garantie auf Richtigkeit:
-------------------------------cut-------------------------------
Klein, aber fein!
Rainer Fröhlich
Hardware, Speichererweiterung
ST 5/92, S. 54
Mammut-RAM für den Mega-ST
News, Mega-STE 16MByte, Speichererweiterung
ST 12/91, S. 7
Und es geht doch
16 Megabyte-RAM im ST
Hardware, Speichererweiterung
ST 9/91, S. 161 (cm)
Neue Speichererweiterung von Catch
News
ST 4/91, S. 8
4 MB-Grenze gesprengt
News, Speichererweiterung
ST 7/90, S. 6
Aus zweieinhalb mach drei
Optimale Ausnutzung von Speichererweiterungen
K.-D. Litteck
Projekt, Hardware, RAM, Aufrüstung
ST 3/90, S. 150
siehe 4/90, S. 10
-------------------------------cut-------------------------------
Aus dem STCarchiv ...
Die Firma H. Richter bietet ein Erweiterungssystem an, das bis maximal 14 MByte ausgebaut werden kann. Die erforderliche Basispiatine setzt einem MEGA 4 noch 2 MByte drauf und kostet 1598 DM, von 6 auf 10 MByte wären 998 DM und von 10 auf 14 MByte genau 1798 DM zu bezahlen.
-
Der Speicher über 4MB muss sehr wahrscheinlich entweder durch einen Patch im TOS selber oder über ein kleiner Autoordner Programm beim System angemeldet werden.
grüße
Frank
-
Das kommt auf die Tos Version an, Tos2.06 erkennt denn mehrspeicher selbst und führt auch einen Selbsttest bis dahin aus. Seihe Tests von mega-hz.
-
Alles klar,
nach diesen Ausführungen habe ich den Effekt vermutlich. Ich hatte in einer Zeile des Adressdekoders noch die 4MB Speicher aktiviert und nicht die 14MB. Testen kann ich das aber erst am Montag. Noch 'ne Frage. Eigentlich hat der Core SD-RAMs mit 64MB drauf. Die CPU könnte man auch leicht anpassen, dass der ganze Speicher angesprochen werden kann. Gab es da mal irgendwelche Ansätze mit mehr als 14MB. Es müsste dann wohl so aussehen, dass 0E00000 bis 0FFFFFF frei bleiben müssten für Betriebssystem und Memory Mapped Register. Danach wäre aber dann Platz bis 3E7FFF.
Viele Grüße
Wolfgang
-
Gab es da mal irgendwelche Ansätze mit mehr als 14MB. Es müsste dann wohl so aussehen, dass 0E00000 bis 0FFFFFF frei bleiben müssten für Betriebssystem und Memory Mapped Register. Danach wäre aber dann Platz bis 3E7FFF.
Viele Grüße
Wolfgang
Am besten die übrigen 50MB RAM ab $01000000 einblenden, wie Fast-RAM beim TT. Wird von TOS 2.06 beim Booten zwar nicht erkannt, kann aber nachträglich durch Maddalt() angemeldet werden und ist ab dann für Programme verfügbar.
Kann aber sein, dass Programme darüber stolpern, dass ein vermeintlicher 68000er auf einmal mehr als 16MB adressieren kann...
Gruß, Holger
-
Also,
ich bin mir ziemlich sicher, dass Suska jetzt mit mindestens 14MB Speicher arbeitet. Allerdings werden vom TOS 2.06 beim Booten nur 4MB erkannt. Ist es tatsächlich so, dass TOS 2.06 weitere Speichertests überhalb der 4MB Grenze macht? Und was wird dann in das Memory Configuration Register eingetragen? Da gibt es gemäß Atari Register Listing gar keinen Platz mehr für andere Kombinationen der zwei Speicherbänke als 512K, 1MB, 2MB und 4MB. Kann mir jemand weiterhelfen? Hat jemand TOS 2.06 mit 14MB am Laufen? Wie sieht gegebenenfalls die Speichererkennung aus?
Danke und bis demnächst
Wolfgang
-
Hallo Wolfgang,
die meisten Funktionen hat die Fa. Atari oft mit der heißen Nadel gestrickt (oder vielleicht auch nur ökonomisch gehandelt). Man hat nicht wirklich weit in die Zukunft geplant. Auch einige Andere hatten für den PC bei 640KB das Ende der Fahnenstange gesehen :D .
Die kleinen Ataris können wohl nur zwei Speicherbänke verwalten (die werden beim Systemstart überprüft um zu erkennen vieviel Speicher vorhanden ist) und das geht je nach Chips von ungefähr 256KB bis 4MB hoch. Es gab aber auch von anderen Firmen aufwändige Speichererweiterungen die diese Grenze überwinden konnten, oft mit einer 68020 oder 68030 ausgestattet. Diese hatten dann oft ein neueres TOS damit der Speicher erkannt wurde. Einige hatten ein Programm für den Auto-Ordner.
Siehe z.B. Multiboard (http://wiki.newtosworld.de/Multiboard) oder Magnum St (http://www.stcarchiv.de/stc1997/03_magnumst.php). Der Speicher ist dann meißt als "TT-Ram" eingebunden worden. Das bedeutet das der Prozessor ohne Umwege darauf zugreifen kann aber Peripherie wie der DMA-Chip darauf nicht zugreifen kann.
Das bedeutet in der Erkennungsroutine von ab TOS 2.06 könnte die Lösung liegen.
-
Hallo,
ich möchte den Suska-IP-Core rechtzeitig im Dezember öffentlich machen, hänge aber immer noch an ein paar Problemen. Eines davon ist der Betrieb von CF-Karte und 2,5" Festplatte am IDE Port. Beide Geräte funktionieren einwandfrei, wenn sie einzeln als Master betrieben werden. Aber sobald ich ein Laufwerk auf Slave umstelle, funktioniert zwar der Master weiterhin aber das Slave Laufwerk wird von HDDRIVER nicht erkannt. Hat irgendjemand zwei Laufwerke am IDE in Betrieb und wenn ja welche (Festplatten, CDROM...).
Wenn dieses Thema abgehakt ist, werde ich mich nochmals melden.
Vielen Dank für jegliche Unterstützung.
Wolfgang
-
Hallo,
also ich hatte weder am Multiboard noch am Flacon probs mit 2 IDE Geräden.
Auf Master Slave gehe ich jetzt nicht ein da ich denke das du das korrekt gesetzt hast.
An welche Adressen hast du denn denn IDE Bus gemappt?
-
Ich habe die Adressen wie folgt belegt:
IDE_CS0n (low aktiv, heisst bei Pera's Interface SELPn):
F00000 bis F0001F.
IDE_CS1n (low aktiv, heisst bei Pera's Interface SELSn):
F00020 bis F0003F.
die IORDn und IOWRn Signale gehen dann natürlich von
F00000 bis F0003F.
und DTACKn wird auch von F00000 bis F0003F erzeugt.
Pera's Interface spiegelt diese Adresslagen dann noch in höhere Bereiche, da die Adressleitungen A6 bis A13 nicht berücksichtigt werden (ein Relikt aus der alten GAL-Zeit, wie ich vermute).
Die Hardware auf dem Suska Board ist korrekt, ich habe kein Cable Select eingestellt und die Laufwerke als Master respektive Slave gebrückt.
Grüße
Wolfgang
-
Hallo Wolfgang,
ja ok das ppera interface habe ich auch aufgebaut und hat auch nicht sofort funktioniert. Du hast als Treiber denn SN74LV541 drin. Im pperas Schaltplan ist ein 74HCT245 drin, mit diesem habe ich es aber nicht zum laufen gebracht. Nachdem ich sie getauscht habe gegen einen 74F245 lief es einwandfrei. Also ich würde die Bustreiber nicht ausschliessen. Weiß nicht ob du das Experimental was machen kannst.
Zum Speicher, also wir haben schon mit dem ST in Richtung mehr Speicher Experimentiert und Tos2.06 hat das auch erkannt das da mehr speicher da ist. Weiß jetzt nicht genau wie das war, aber der Glue teilt doch der MMU mit das es sich um die am Bus Anliegenden Adresse um Ram Speicher Bereich handelt. War das nicht über die Ram Leitung ?
Kannst du denn auf denn Speicher oberhalb 4MB zugreifen?
-
Hallo Ingo,
die Hardware ist bezüglich des IDE Interface sehr robust ausgelegt. Ich benutze die Bustreiber als Pegelwandler. Die sollten bezüglich des Bustimings völlig ok sein, da der IDE Anschluss nicht länger als 2cm ist und die Bustakfrequenz 4MHz nicht übersteigt. Das Interface geht ja auch wunderbar mit einem Master. Lediglich der Slave meldet sich nicht. Elektrisch gesehen ist das ja genau das Gleiche.
Zum Speicher: Ich habe keine Software, die auf den hohen Speicher zugreift. Wenn TOS 2.06 das erkennen sollte, wo wird dann das vermerkt (im MemConfig Register? Durch welche Flags?). Die Glue adressiert via der RAMn-Leitung den gesamten 14MB-Bereich, das DTACKn wird hierfür korrekt gesetzt und die MCU kann die 14MB auch adressieren.
Vielleicht hat jemand eine Testsoftware, die unabhängig vom MemConfig-Register testet und den verfügbaren Speicher anzeigt, vielleicht über PHYSTOP, sofern PHYSTOP von TOS 2.06 auf 14MB gesetzt wird.
Viele Grüße
Wolfgang
-
Wenn das IDE Interface von ppera zu 100% Atari Kompatibel ist sollte es mit den Master/Slave Devices keine Probleme geben ...
(http://freenet-homepage.de/68k/bilder/idemem.gif)
grüße
Frank
Hier Dateien zum Download Atari Memory Map (http://freenet-homepage.de/68k/text/AtariMemoryMap), Falcon Memory Map (http://freenet-homepage.de/68k/text/FalconMemoryMap), Hardware Description (http://freenet-homepage.de/68k/text/HardwareDescription), Register Listing (http://freenet-homepage.de/68k/text/RegisterListing) ...
-
Hallo,
es ist in diesem Sinne nicht ganz kompatibel, da die Adressen beim Suska IDE Interface korrekt dekodiert werden und die Spiegelung in höhere Adressbereiche entfällt. Da nun aber der Master geht, verstehe ich nicht, warum es beim Slave nicht funktioniert, da zwischen Master und Slave ein Bit des übertragenen Protokolls entscheidet. Ich habe momentan mit einer CF-Card getestet, die nur als Master läuft und einer Toshiba Festplatte, die als Slave gebrückt ist. Vielleicht ist auch die Festplatte nicht ok. Ich werde mir andere Laufwerke besorgen und nochmals testen. Dennoch würde mich interessieren, wer einen Master/Slave Betrieb in Betrieb hat und mit welchen Laufwerken.
Viele Grüße
Wolfgang
-
Möglicherweise liegt es am Cable select.
Das Device an dem der Pin auf Masse gezogen ist ist automatisch Master. (so habe ich es in Erinnerung...)
Beim 40/44-poligen Stecker ist das Pin 28.
An der CF-Karte sollte das, glaube ich, Pin 9 sein.
Ich hatte schon mal das Phänomen, als ich zufällig eine Festplatte und eine CF-Karte Master gesetzt hatte, nur die CF-Karte ansprechen konnte. Ich vermute dass die CF-Karte einfach schneller reagierte und die Festplatte gar nicht dazu kam dazwischen zu funken.
-
da zwischen Master und Slave ein Bit des übertragenen Protokolls entscheidet
Stimmt, aber Hardware-seitig muss erst einmal unmittelbar nach Freigabe des RESET-Signals ein komplexer Abstimmungsprozess zwischen Master und Slave ERFOLGREICH abgelaufen sein. Es kommt vor, das einige Laufwerke einfach nicht "miteinander können". Machmal hilft es, die Rollen von Master und Slave zu tauschen, manchmal hilft gar nichts. Was immer gehen sollte: 2 Laufwerke gleichen Fabrikats und Typs.
Für Interessierte: Was nach RESET so alles läuft:
4.1 Configuration
This standard defines the ATA interface containing a single host or host adapter and one or two devices. If two devices are connected to the interface, they are connected in a daisy chained configuration. One device is configured as Device 0 and the other device as Device 1.
The designation of a device as Device 0 or Device 1 may be made in a number of ways:
- a switch or a jumper on the device
- use of the Cable Select (CSEL) pin
...
5.2.4 DASP- (Device active, device 1 present)
This is a time-multiplexed signal which indicates that a device is active, or that Device 1 is present.
This signal shall be an open collector output and each device shall have a 10K ohm pull-up resistor.
During power on initialization or after RESET- is negated, DASP- shall be deasserted by both Device 0 and Device 1 within 1 ms, and then Device 1 shall assert DASP- within 400 ms, to indicate that Device 1 is present.
Device 0 shall allow up to 450 ms for Device 1 to assert DASP-.
DASP- shall be negated following acceptance of a command by Device 1 or after 31 s, whichever comes first.
Any time after negation of DASP-, either device may assert DASP- to indicate that a device is active.
If the host connects to the DASP- signal for the illumination of an LED or for any other purpose, the host shall ensure that the signal level seen on the ATA interface for DASP- shall maintain Voh and Vol compatibility, given the Ioh and Iol requirements of the DASP- device drivers.
...
5.2.13 PDIAG- (Passed diagnostics)
This signal shall be asserted by Device 1 to indicate to Device 0 that it has completed diagnostics. A 10K ohm pull-up resistor shall be used on this signal by each device.
Following a power on reset, software reset or RESET-, Device 1 shall negate PDIAG- within 1 ms (to indicate to Device 0 that it is busy). Device 1 shall then assert PDIAG- within 30 seconds to indicate that it is no longer busy, and is able to provide status. If Device 1 is present, then Device 0 shall wait for up to 31 seconds from power-on reset, software reset or RESET- for Device 1 to assert PDIAG-. If Device 1 fails to assert PDIAG-, Device 0 shall set bit 7 to 1 in the Error register to indicate that Device 1 failed. After the assertion of PDIAG-, Device 1 may be unable to accept commands until it has finished its reset procedure and is Ready (the DRDY bit is equal to one).
Following the receipt of a valid EXECUTE DEVICE DIAGNOSTIC command, Device 1 shall negate PDIAG- within 1 ms to indicate to Device 0 that it is busy and has not yet passed its device diagnostics.
Device 1 shall then assert PDIAG- within 5 seconds to indicate that it is no longer busy, and is able to provide status. Device 1 should clear the BSY bit before asserting PDIAG-. If Device 1 is present then Device 0 shall wait for up to 6 seconds from the receipt of a valid EXECUTE DEVICE DIAGNOSTIC command for Device 1 to assert PDIAG-. If Device 1 fails to assert PDIAG-, Device 0 shall set bit 7 to 1 in the Error register to indicate that Device 1 failed.
If DASP- was not asserted by Device 1 during reset initialization, Device 0 shall post its own status immediately after it completes diagnostics, and clear the Device 1 Status register to 00h. Device 0 may be unable to accept commands until it has finished its reset procedure and is Ready (the DRDY bit is equal to one).
It is recommended that the host make no connect to the PDIAG- signal.
...
5.2.15.2 CSEL (Cable select) (optional)
The device is configured as either Device 0 or Device 1 depending upon the value of CSEL:
- If CSEL is negated then the device address is 0
- If CSEL is asserted then the device address is 1
CSEL shall be maintained at a steady level for at least 31 seconds after the negation of
RESET-.
NOTE 7 - Special cabling can be used by the system manufacturer to selectively ground CSEL
e.g., CSEL of Device 0 is connected to the CSEL conductor in the cable, and is grounded, thus
allowing the device to recognize itself as Device 0. CSEL of Device 1 is not connected to
CSEL because the conductor is removed, thus the device can recognize itself as Device 1.
...
9.1 Power on and hardware resets
This clause describes the algorithm and timing relationships for Devices 0 and 1 during the processing of power on and hardware resets.
The timing assumes the following:
a) DASP- is asserted by Device 1 and received by Device 0 at power-on or hardware reset to indicate the presence of Device 1. At all other times it is asserted by Device 0 or Device 1 to indicate when a device is active;
b) PDIAG- is asserted by Device 1 and detected by Device 0. It is used by Device 1 to indicate to Device 0 that it has completed diagnostics without error and is ready to accept commands from the
Host (BSY bit is cleared). This does not indicate that the device is ready, only that it can accept commands.
9.1.1 Power on and hardware resets - device 0
a) Host asserts RESET- for a minimum of 25 usec;
b) Device 0 sets the BSY bit no later than 400 ns after RESET- is negated;
c) Device 0 negates DASP- no later than 1 ms after RESET- is negated;
d) Device 0 samples for at least 450 ms for DASP- to be asserted from Device 1. This sampling starts 1 ms after RESET- is negated;
e) Device 0 performs hardware initialization and diagnostics;
f) Device 0 may revert to its default condition;
g) If Device 0 detected that DASP- was asserted during step d), then Device 0 waits up to 31 seconds for Device 1 to assert PDIAG-. If PDIAG- is asserted within 31 seconds, Device 0 sets bit 7 equal to 0 in the Error Register, else Device 0 sets bit 7 equal to 1 in the Error Register. If DASPassertion was not detected in step d) Device 0 sets bit 7 equal to 0 in the Error Register. In either case the device shall set the Sector Count register to 01h, the Sector Number register to 01h, the Cylinder Low register to 00h, the Cylinder High register to 00h, and the Device/Head register to 00h. Device 0 shall store whether or not Device 1 was detected in step d) because this information is need in order to process any Software reset or EXECUTE DEVICE DIAGNOSTIC command later;
h) Device 0 posts diagnostic results to bits 6-0 of the Error Register;
i) Device 0 clears the BSY bit when ready to accept commands that do not require the DRDY bit to be equal to 1. Device 0 shall clear the BSY bit no later than 31 seconds from the time that RESET- is negated;
j) Device 0 sets the DRDY bit when ready to accept any command.
NOTE 34 - Steps i) and j) may occur at the same time. While no maximum time is specified for the DRDY bit to be set to 1, a host should allow up to 2 minutes for the DRDY bit to become 1. See figure 8.
9.1.1 Power on and hardware resets - device 1
a) Host asserts RESET- for a minimum of 25 us;
b) Device 1 sets the BSY bit no later than 400 ns after RESET- is negated;
c) Device 1 negates DASP- no later than 1 ms after RESET- is negated;
d) Device 1 negates PDIAG- before asserting DASP-;
e) Device 1 asserts DASP- no later than 400 ms after RESET- is negated;
f) Device 1 performs hardware initialization and diagnostics;
g) Device 1 may revert to its default condition;
h) Device 1 posts diagnostic results to the Error Register;
i) Device 1 clears the BSY bit when ready to accept commands that do not require the DRDY bit to be equal to 1;
j) If Device 1 passed its diagnostics without error in step f), Device 1 asserts PDIAG-. If the diagnostics failed, Device 1 does not assert PDIAG- and continues to the next step. Device 1 shall clear the BSY bit, and optionally assert PDIAG-, no later than 30 seconds from the time RESET- is negated. The device shall set the Sector Count register to 01h, the Sector Number register to 01h, the Cylinder Low register to 00h, the Cylinder High register to 00h, and the Device/Head register to 00h;
k) Device 1 sets the DRDY bit when ready to accept any command;
NOTE 35 - Steps i), j) and k) may occur at the same time. While no maximum time is specified for the DRDY bit to be set to 1, a host should allow up to 2 minutes for the DRDY bit to become 1. See figure 8.
l) Device 1 negates DASP- after the first command is received or negates DASP- if no command is received within 31 seconds after RESET- is asserted.
Gruß, Holger
-
Hi Holger,
super Info, Danke. Woher hast Du die denn? Ich habe mich etwas mit IDE befasst und bin mittlerweile der Meinung, dass das Suska IDE-Interface ok sein müsste. Die Inkompatibilitäten würde ich auf die Laufwerke schieben. Habe schon Uwe Seimet angekakt, Fachleute befragt, im Internet recherchiert mit der Erkenntnis, dass IDE wohl schon ein wenig in die Tage gekommen ist und nix so richtig kompatibel funktioniert. Das kann man ja auch an den Falcons mit IDE sehen, ... ewige Diskussionen. Ich lasse das mal jetzt wie es ist und werde lieber SD-Karten via 4 Bit SD-Mode als SCSI-Laufwerke 'tarnen' und somit wieder die ACSI-Schnittstelle mit DMA Mode stärken. Wer Interesse an so etwas hat ... gerne per email an mich. Dieses Teil werde ich nicht quelloffen legen.
Und last but not least: es hat sich hier immer noch niemand geäußert, der einen IDE Master/Slave Betrieb an der Falcon oder IDE-Card Schnittstelle betreibt.
Schöne Grüße
Wolfgang
-
Hi Holger,
super Info, Danke. Woher hast Du die denn?
Aus einer ATA-2 Spezifikation von 1999, die ich mal im Netz aufgetrieben hatte
und bin mittlerweile der Meinung, dass das Suska IDE-Interface ok sein müsste
Wichtig ist noch: Die Daten werden immer mit der Rückflanke von IOR und IOW übergeben.
Also beim Schreiben die Daten nicht zu früh abschalten.
Mit Data Setup 60ns und Data Hold 30ns ist man auf der sicheren Seite.
Kann aber mit Deinen Master/Slave-Problemen nichts zu tun haben.
Zurück zu Deinen 14MB:
Vielleicht hat jemand eine Testsoftware, die unabhängig vom MemConfig-Register testet und den verfügbaren Speicher anzeigt, vielleicht über PHYSTOP, sofern PHYSTOP von TOS 2.06 auf 14MB gesetzt wird.
Hast Du das inzwischen zum Laufen bekommen?
Oder muss ich meinen Assembler anschmeissen?
Gruß, Holger
-
Guten Morgen,
tja das mit den 14MB ist so: eingehängt sind die, es beisst sich auch nichts aber sehen kann ich die eben nicht. Ich hab's mal als 'wahrscheinlich ok' vermerkt.
Die Daten am IDE übernehme ich abhängig vom IORDY Signal. Bei Pera ist die DTACKn-Logik ein 'wired or', was ich nicht ganz korrekt finde. Ich habe das anders modelliert so dass sowohl IDE Adressraumzugriff stattfinden muss aber auch IORDY '1' sein muss, um ein DTACKn = '0' zu erzeugen. Das scheint gut zu funktionieren. Übrigens eventuell ein Problem, das andere auch haben (kurze Leitungen, buggy Datenübernahme...).
Ach ja, fällt mir gerade ein:
ich habe Nebulus ausprobiert. In der Monochrom-Auflösung stürzt es ab. Im Farbmodus startet es durch bis der Startbildschirm erscheint. Wenn ich dann das Spiel starte, erscheinen zwei Bomben (Busfehler). Nun weiss ich nicht, was Nebulus an Hardware erwartet (Falcon?, andere Videomodi? DMA-Sound?). Joystick hatte ich auch nicht angeschlossen. Weiss hierzu jemand was?
Viele Grüße
Wolfgang
-
Hallo Wolfgang,
ich habe am Falcon bereits Master/Slave Betrieb gehabt.
2x Festplatte
1c HD + 1x CD-Rom
Auch an pperas IDE interface habe ich 2 Geräte schon dran gehabt und noch nie Probleme damit. Auch die hier im Forum beschriebenen IDE Probleme habe ich nie an einem Falcon gehabt und ich betreibe auch neue Festplatte so um die 100GB am Falcon.
Wie schonmal gesagt hatte das IDE Interface mit denn 74HCT245 nicht Funktioniert, mit denn F Typen schon. Wir haten mit ppera deswegen auch kontakt und er meinte das es durchaus möglich ist wohl aber nicht am Timing liegt. Ich weiß leider nicht so recht was bei dem HCT anders ist als bei den F typen.
-
Hallo,
Festplatte und CD-ROM scheint ok. Aber eben nicht zwei Festplatten. Das kennt man auch von PCs. Zwei Platten an einem IDE 'zicken' ganz oft rum. Und das mit den HCT245 und F245 könnte auf das zu schnelle DTACKn zurückzuführen sein.
Wolfgang
-
Ach ja, fällt mir gerade ein:
ich habe Nebulus ausprobiert. In der Monochrom-Auflösung stürzt es ab. Im Farbmodus startet es durch bis der Startbildschirm erscheint. Wenn ich dann das Spiel starte, erscheinen zwei Bomben (Busfehler). Nun weiss ich nicht, was Nebulus an Hardware erwartet (Falcon?, andere Videomodi? DMA-Sound?). Joystick hatte ich auch nicht angeschlossen. Weiss hierzu jemand was?
Es braucht ein Farbmonitor, ST-Low auflösung, ist ein 1988 Spiel, so kein Falcon :) und ich glaube schon DMA-Sound. Joystick nicht verpflichtet.
-
Ich habe das anders modelliert so dass sowohl IDE Adressraumzugriff stattfinden muss aber auch IORDY '1' sein muss, um ein DTACKn = '0' zu erzeugen. Das scheint gut zu funktionieren.
So muss das sein!
Viele Laufwerke sind allerdings schnell genug, den ST ohne Waitstates zu bedienen.
Das Interface in Falcon setzt das sogar voraus, weil IORDY gar nicht angeschlossen ist.
tja das mit den 14MB ist so: eingehängt sind die, es beisst sich auch nichts aber sehen kann ich die eben nicht.
Versuch´s mal hiermit:
5.13.1 Maddalt
Name: »Inform Gemdos of alternative memory« - Alternativen Speicher anmelden.
Gemdosnummer: 20
Deklaration: int32_t Maddalt ( void *start, int32_t size );
Beschreibung: Die GEMDOS-Routine Maddalt erlaubt es, einen Block von Alternate-RAM in die Speicherliste des GEMDOS aufzunehmen. Es gilt:
Parameter Bedeutung
start Anfangsadresse des Speichers
size Länge des Speicherbereichs
Hinweis: Der Block bleibt Eigentum von DOS und darf nicht zurückgefordert werden. Wenn hinzugefügte Blöcke nicht hintereinander liegen, ist die Anzahl der hinzufügbaren Blöcke auf ca. 12 beschränkt.
Nützlich könnte diese Funktion etwa beim Einsatz von VME-Bus-Karten im Atari-TT sein, wenn deren Speicher für GEMDOS zugänglich gemacht werden soll.
Ergebnis: Die Funktion liefert den Wert 0, oder eine negative Fehlermeldung.
Verfügbar: Die Funktion ist erst ab GEMDOS 0.19 verfügbar (Ist in TOS 2.06 drin).
C:
int32_t Maddalt ( void *start, int32_t size );
Assembler:
move.l size,-(sp) ; Offset 6
pea start ; Offset 2
move.w #20,-(sp) ; Offset 0
trap #1 ; GEMDOS aufrufen
lea $A(sp),sp ; Stack korrigieren
Danach sollte der Rechner diesen Speicher als TT-RAM eingebunden haben (mal mit dem Kontrollfeld überprüfen).
Programme mit gesetztem Fast-RAM-Bit werden dann im TT_RAM gestartet (wenn da genug Platz ist).
Gruß, Holger
-
Ich habe mir heute mal die Zeit genommen, den ganzen Thread von vorn bis hinten durchzulesen. Ich muß sagen, ich schwanke zwischen völlig sprachlos und total begeistert darüber, was hier schon geleistet wurde! Einfach Wahsinn!!!
-
Jetzt hoffen wir noch das Wolfgang Nebulus zum laufen bekommt und dann kann manns kaufen ;D
Gruß Matthias
-
Noch 'ne Frage: muss eventuell Nebulus von Diskette gestartet werden? Manchmal gab es diese Forderung.
-
Also wenn Nebulus darauf läuft, kaufe ich das Board auf jeden Fall. ;D
@Wolfgang: Ich vermute, dass man Nebulus nur von Diskette starten kann. Zumindest verhällt es sich so bei mir auf dem Falcon. Von CF/HDD bekomme ich zwei Bomben, von Diskette startet es. (Kommt allerdings nicht über den Titelbildschirm hinaus, das liegt wohl aber am Falcon)
Gruß,
Dennis 8)
-
Hallo Dennis,
das ist also das Gleiche wie bei mir. Startbildschirm ok, aber weiter läuft das Spiel nicht. Dann frage ich mal anders herum. Hat jemand das Spiel lauffähig? Von Diskette? Von Platte? Auf welchem Rechner? Es besteht offensichtlich aus zwei Files. Oder fehlt mir was?
Viele Grüße
Wolfgang
-
Ich hab leider grad keinen Farbmonitor da ums zu testen und meine Frau blockiert den Fernseher.
Kann morgen mal gucken. Dann schmeiss ichs auf ne SD-Cart und probier mal obs läuft.
Hoffe deine Dateien haben keine Macke.
Gruß Matthias
-
Schon mal die gepatchte Version von D-Bug probiert? (http://www.dbug-automation.co.uk/patch.asp (http://www.dbug-automation.co.uk/patch.asp))
Die geht auch von Platte.
Und läuft auf meinem Falcon gut....
-
Ach Klasse,
an die hab ich gar nicht mehr gedacht
Dankeschön, Link gespeichert.
Gruß Matthias
-
Hi,
der Link war gut. Nebulus tut. Leider komme ich nicht über das erste Stockwerk hinaus. Ich mache demnächst mal ein paar Screenshots.
Viele Grüße
Wolfgang
-
Hallo Wolfgang, das ist ja allererste Sahne. ;D Die werden bestimmt schon lange erwartet. Suupppeer!
-
Hallo,
ich habe ein Defizit bezüglich der Erweiterungen, die den Falcon von den anderen ST, STE usw. abheben. DSP und 68030 sind mir klar. Nun brauche ich aber dringend Infos über den Videl. Wie funktioniert der genau? Welche Register gibt es? Was machen die einzelnen Register? Wie funktioniert Genlock usw. Leider kann ich über den Videl nicht sehr viel finden.
Und dann noch 'ne Frage: was benutzt Ihr denn für Bildschirme? Der Falcon kann ja wohl modernere Multisyncs auch in den Farbmodi. Wie sieht es aber mit STE und Mega STE und ST und Mega ST aus? Hat dort jemand moderne Bildschirme in den Farbmodi in Betrieb?
Viele Grüße
Wolfgang
-
Hallo Wolfgang,
also der Falcon hat normale VGA Standard auflösung, und die ST Auflösungen noch dazu. Da geht ein einfacher Standard VGA Monitor.
-
http://mikro.umpc.sk/docs/Memory%20Maps/FALREG.TXT (http://mikro.umpc.sk/docs/Memory%20Maps/FALREG.TXT)
-
Ich kenn´ mich ja mit programmieren nix aus, aber kennst Du diese beiden Links schon? Womöglich ist da ja was brauchbares dabei bzgl. Falcon und Videl.
http://mikro.umpc.sk/docs/mikro/videl.html
http://dev-docs.atariforge.org/files/Falcon030_Dev_Doc_1-25-1993.pdf
-
Danke für die Links. Ich schau' mir den Stoff an. ST(e)-Grafik auf Multisync ist in Bearbeitung. Tuxie hat 'nen Falcon an VGA laufen. Aber wie sieht es mit STEs und STs aus?
Viele Grüße
Wolfgang
-
Hallo,
hier mal der seit längerem versprochene Screenshot. So sieht das auf Suska auf dem alten SC1224 aus.
Grüße Wolfgang
-
Na da muss noch einiges getan werden, das sind ja total falsche Farben....
-
Na ja das mit den Farben hab' ich auch nicht geblickt. Wenn ich es vom SC1224 digital abfotografiere habe ich plötzlich Falschfarben auf dem Bild. Also kein Core-Problem. Demnächst, hoffe ich, gibt's einen Screenshot auf dem 16:9 TFT. Vielleicht wird es da besser. Die Bildwiederholfrequenz habe ich in allen drei Modi auf 72Hz hochgeschraubt (goodies for the upcoming hardware).
Bis dann
Wolfgang
-
@Wolfgang,
ich finde es wirklich bemerkenswert. 8) Die Platine ist einfach schick und hat sogar Schnittstellen in Hülle und Fülle und jetzt läuft auch schon mit Nebulus ein recht bekanntes Spiel. Funktionieren die Joysticks schon? Mit welchem Takt arbeitet das System jetzt? Gibt es oder wird es einen Kompatiblelitätsmodus(Takt 8MHz und max. 4MB) geben? Wieviel Speicher hatte das System als Nebulus lief und welche Probleme mußtest Du meistern bis es lief? Oder funktionierte es auf anhieb?
Könntest Du eine Funktion implementieren die anhand der Programme die entsprechende Bildschirmauflösung und Farbtiefe wählt(anhand eine Liste die dem OS vorliegt oder eines gesetzten Bits im Programm ähnlich dem Fastloadbit)?
-
Hallo,
viele Fragen hier kurz die Antworten:
das System hat natürlich viel Arbeit gemacht bis es stabil lief. Jetzt aber läuft auf Anhieb alles, auch Nebulus (in der ST gepatchten Version). Joystick (ich habe nur einen) geht. Es sind 14MB Speicher drin und die CPU läuft mit 16MHz und ist ohnehin etwas schneller als das Original bei vergleichbarer Taktfrequenz. Die neuen Video-Modi sind in das Shift-Mode Register eingehängt also wählbar. Momentan habe ich keine Taktumschaltung drin. Das Board wurde unter anderem in Hinblick auf die Schnittstellen-Kompatibilität entworfen, daher der Zusatz -C für 'Classic'. Zu diskutieren bliebe eventuell eine optionale Bestückung, da beispielsweise der SCSI Stecker und die elektronische Terminierung nicht ganz billig sind. Alleine der 50 polige Stecker ist mit 8€ sehr teuer. Wer da eine gute Quelle weiß ...
Schöne Grüße
Wolfgang
-
Ist Nebeulus mit 16Mhz eigentlich Spielbar. Das muss doch dann irre schnell sein?
Gruß Matthias
-
Nein, das ist sehr gut spielbar. Es ist sauber programmiert und läuft dann halt glatt im VBL. Probier es auf dem Falcon aus :D
-
Dann sollte es aber auf alle Fälle für alle unsauberen Games ne Taktanpassung geben.
Sonst fürchte ich einen meiner geliebten Titel nicht zocken zu können.
Gruß Matthias
-
Hallo,
tja, das mit der Taktanpassung scheint ein korrekter Einwand zu sein. Ich habe nun die Multisync Video Modi eingebaut (gibt's aber nicht in der kommenden Version 2K8B; die ist schon gepackt). Es gibt zu den bekannten Video Modi nun die folgenden:
aus 640x200x4 Farben*50Hz/60Hz wird per Zeilendopplung 640x200Dx4x72Hz.
aus 320x200x16 Farben*50Hz/60Hz wird per Zeilendopplung 320x200Dx16x72Hz.
und ein monochrome Mode auf VGA ausgegeben mit 640x400x2x72Hz.
Damit können die alten Bildschirme durch moderne Multisyncs/TFTs ersetzt werden. Auf experiment-s gibt es neue Bilder hierzu.
Nun habe ich Nebulus getestet, welches offensichtlich die Horizontalfrequenz oder die Vertikalfrequenz oder die entsprechenden Interrupts auswertet und somit um beispielsweise den Faktor 72/50 zu schnell läuft. Das ursprüngliche Timing lässt sich in diesem Fall per Hardware nur unzureichend nachbilden. Das bedeutet, dass Nebulus und Programme, die auf die HSYNCs oder VSYNCs reagieren gepatcht werden müssten. Hat jemand Kontakt zu Personen, die so etwas machen können?
Viele Grüße
Wolfgang
Viele Grüße
Wolfgang
-
Das ist bei der vielzahl der Programme aber ein Sinnloses unterfangen. Kannst du da nicht sowas wie ne Bridge einbauen, damit intern der Junge sich wie ein ST verhält und dann einen zwischenstep zum VGA-Ausgang um dem Monitor nen normalen Takt zu bieten.
Kenn mich da ja nicht aus ob das möglich ist, aber es wär ne Idee für 100% kompatibilität und FPGA kann ja fast alles ;D
Gruß Matthias
-
Hi Matthias,
na ja, ... 'FPGA kann ja fast alles' sehe ich nicht unbedingt so. Es kann das, was man reinstopft. Und wie ich sehe, wachsen mit dem Angebot die Ansprüche :-)
Es sieht so aus:
man kann natürlich den ST, wenn eine 72Hz Vertikalsynchronisation ausgegeben wird damit der Multisync gut läuft, denken lassen, dass eben nur 50Hz VSYNC ausgegeben würde. Wenn aber dann in der entsprechenden Interruptroutine Zeugs erledigt wird wie Mauszeiger aktualisieren etc., dann sieht das vermutlich ziemlich doof aus. Also auch keine nachhaltige Lösung. Das Problem ist im Grunde genommen das mathematisch irrationale Verhältnis von 72/50 bzw. 72/60. Ich lasse das momentan wie es ist, bis jemand 'ne bessere Idee hat. Die neuen Videomodi betrachte ich für zukünftige- oder gepflegte ältere Programme als ok. Schlecht geschriebene Software oder nicht mehr gepflegte Software möchte ich nicht mit einem Hardware-Patch eines Hardware-Patch ... unterstützen. Hierfür kann man immer noch die alten Monitore verwenden.
Viele Grüße
Wolfgang
-
@Wolfgang
sicherlich kann man das ein oder andere Spiel patchen nur bei der Vielzahl von Spielen werden nicht alle gepatcht werden können. Diese Lösung halte ich so nicht für praktikabel. Besser den VBI für das eigentliche Spiel unangetastet lassen (damit das Timing fürs Spiel stimmt) und ihn seperat (als Kopie) für das Monitorsignal verändern. Das eigentliche Bild müßte dann irgendwie Zwischengespeichert und mit eigenen Timing zum Monitor geschickt werden. ::)
Ich hoffe Du findest eine gute Lösung...
-
Hi Wolfgang
Damit bist du jetzt in der zwickmühle.
Für Leute die neuere Hardware mit Atarifeeling wollen mag das ja OK sein, da vermutlich Mint und Arbeitsproggis wunderbar damit klar kommen. Die Spielernaturen wie mich schließt du damit komplett aus.
Wenn ich da dann wieder rumfrickeln muss um das ganze an nem sauberen Bildschirm betreiben zu können ist dies für mich keine Lösung. Da hab ich doch lieber kleine Adapter und ersetz einzelne Chips wenn funktionierende 1040er rar werden sollten, denn der sollte doch auch ursprünglich nachgebaut werden.
Ach ja und wegen deiner Mauszeigerbedenken: Die meisten Games am Atari benutzten keinen Mauszeiger :-)
Gibts da nicht die Möglichkeit dann einen etwas besseren Teiler beim Takt zu nehmen, so 75/50 und 80/60, oder sowas. Das müsste doch jeder Multi auch können. Da kenn ich mich nu wirklich nicht aus, aber ich Tip halt - vieleicht stoß ich ja an der richtigen Ecke an.
Bei den meisten Games dürfte im übrigen die Grafik per Vsync gesteuert werden und der Sound per HSync. (Wenn ich mich nicht irre). Beim Lynx wirds zumindest so gemacht - am ST hab ich kaum noch Erinnerungen an meinen damaligen Aktivitäten.
Das war bei Spieleprogrammierung täglich Brot und ganz normal.
Gruß Matthias
-
Hallo Matthias,
das hört sich jetzt aber kritisch an. Ich habe irgendwann einmal nachgefragt, was für Bildschirme so Verwendung finden und keine so rechte Antwort bekommen. Werden denn überall noch alte Monitore benutzt oder Fernseher oder TFTs mit irgendwelchen Adaptern? Der Core würde damit dann natürlich auch funktionieren.
Ich setze mich heute Abend hin und werde versuchen vier weitere Video-Modi einzubauen: 50/60Hz bei 32kHz HSYNC.
Wolfgang
-
Also zum zocken verwende ich nen 1040er an nem LCD-Fernseher über den HF Eingang. Ich hab zwar nen AV-Adapter, der will aber mit meinem LCD nicht. Für andere Sachen betreib ich ST-High an einem TFT. Funzt aber auch nicht sooo gut. Die neuen Bildschirme gehen alle nicht besonders gut.
Bei mir wird zu 90% mit dem Atari ST gezockt. Ein nachfolgegerät mit direkten Ausgängen für VGA-Bildschirme oder änliches ist für mich daher ein MUST.
Ich wollte dir eigentlich nicht an den Kopf stoßen, sondern nur verdeutlichen das die Bildschirmausgabe und das interne Timing für vermutlich sehr viele Anwender(Spieler) wichtig ist.
Gruß Matthias
-
Mal so ins blaue gedacht... Würden die meisten Spiele auf die Bios bzw. auf die XBios Funktionen zugreifen, um sich in den Blank-Interrupt ein zu klinken, wäre es möglich für die Programme die Zeiger so zu verbiegen, dass sie auf getürkte Interupts reagieren, die 50Hz liefern.
Wird dann noch in einen virtuellen FrameBuffer geschrieben und nicht direkt in den Grafikbereich des RAMs, könnte das Flackerfrei funktionieren. Bei 50 zu 72 müssten alle 2 Bilder eines dazwischen geschoben (dubliziert/gemorphed) werden und alle 50 Bilder müßten 3 weggelassen werden. (wenn ich mich nicht verrechnet habe)
Nutzt ein Spiel direkt die Register um an den Interrupt zu kommen, kann man nicht viel machen, außer den Blank reell herunter zu drehen.
Für mich persönlich wäre das nicht so dringend, immerhin kann man man "Hatari" für Mint kompilieren.
-
Das mit dem virtuellen Framebuffer wär doch ne Idee.
Das war das was ich mit Bridge zwischen ST Core und VGA-Ausgabe gemeint habe.
Also das ganze normal in den Standardframebuffer laufen zu lassen und richtung VGA-Ausgang die Bildseuquenz entsprechend rausjagen. Die Spiele sehen dabei den normalen Ablauf. Der VGA-Monitor ein optimales Bildsignal.
Ich denke die meisten Spiele werden die BIOS und XBIOS Funktionen nicht nutzen, da es damals einfach üblich war direkt an Hardware zu programmieren.
Analysieren kann ich das persönlich leider nicht.
Gruß Matthias
-
Hallo,
es gibt nun die folgenden Video-Modi:
640x400x2, 72Hz monochrome, legacy.
640x200x4, 50/60Hz, colour mid resolution, legacy.
320x200x16, 50/60Hz, colour low resolution, legacy.
640x400x4, 50/60Hz, colour mid resolution, multisync, linedoubling.
320x400x16, 50/60Hz, colour low resolution, multisync, linedoubling.
640x400x4, 72Hz, colour mid resolution, multisync, linedoubling.
320x400x16, 72Hz, colour low resolution, multisync, linedoubling.
Alle Video Modi sind 'seamless' in das shared memory Konzept eingebaut. Das Interruptsystem ist derart modifiziert, dass nun Spiele wie Nebulus etc. korrekt laufen. Ich habe verschiedene TFTs ausprobiert. Manche können keine 50Hz und synchronisieren bei 72Hz nicht korrekt. Die meisten funktionieren aber einwandfrei. Somit lege ich nun meine alten SM124 und SC1224 in's Lager. Die Auswahl welcher Bildschirm angeschlossen ist erfolgt über zwei Kodierschalter. Jens baut gerade den PS/2 Software Stack zusammen, um von der Maus und der alten Tastatur loszukommen.
Ein schönes Wochenende an alle.
Grüße
Wolfgang
P.S.: Ich habe Crystle Castels ausprobiert. Es sieht so aus, als wenn das Spiel von Diskette starten muss, sonst stürtzt es ab. Weiss da jemand etwas drüber? Gibt es eventuell einen Patch?
-
Hallo Wolfgang,
klasse wie Du auch das hin bekommen hast. Wenn ich das richtig verstanden habe, dann hat das Spiel weiterhin einen VBI als wenn ein alter Farbmonitor angeschlossen wär und mit dem "Linedoubling" läufts dann auch auf einem VGA-Monitor. ;D
Kannst Du z.B. am 320x200x16 Timing erläutern wie du das Timing modifiziert hast? Meinst Du mit Seamless das es für die Software transparent eingebunden ist?
Viele Grüße und Danke im vorraus
Arthur
-
Hallo Arthur,
es funktioniert folgendermassen: ich habe die MMU und die CPU sowie Blitter, DMA, GLUE mit 16MHz laufen anstatt mit 8MHz wie bei originalen STs und STEs. Das bedeutet, dass die CPU und der Shifter im Wechsel alle 250ns ein Word aus dem Speicher lesen (schreiben) können. Für den originalen Videomodus habe ich dann jeden zweiten Videomodus deaktiviert, da nicht notwendig für die originalen Auflösungen. Jetzt, mit Linedoubling, werden Videodaten alle 250ns gelesen, was der doppelten Datenmenge wie im Orginal entspricht. Und daher ist eben das Zeilenverdoppeln möglich. Die Umbauten im Interruptsystem sind nicht in Kürze zu beschreiben. Es läuft darauf hinaus, die Interrupts nur jede zweite Zeile auszulösen. Alles in allem nicht sonderlich komplex. Aber es sind Umbauten in der GLUE, MMU, SHIFTER und dem Top Level des Projekts notwendig. Für die Software sieht dann alles so aus, wie wenn es alte Maschinen wären.
Viele Grüße
Wolfgang
-
Wow, ich bin begeistert. :)
Vielen Dank Wolfgang, und vielen Dank allen Beteiligten.
Gruß,
Dennis 8)
-
Hi zusammen,
ich möchte einen Knopf an die Videoverarbeitung machen. Hat jemand irgendwelche brauchbaren Infos, wie der Falcon Videl arbeitet?
Schöne Grüße
Wolfgang
-
Z.B. das hier http://mikro.umpc.sk/docs/mikro/videl.html (http://mikro.umpc.sk/docs/mikro/videl.html)
bzw das Textfile im Anhang...
-
Hi,
super Link. Ich habe jetzt Infos um alle Videl Register zu implementieren und auch über das Umschalten zwischen ST Video- und Falcon Video Modi. Nun gibt es offensichtlich die folgenden neuen Modi:
1. True colour mode
2. Overlay mode
3. Monochrome 2-colour (es ist wohl ein Falcon monochrome Mode).
4. 8 Bitplane mode
5. 16 Colour bank Falcon mode.
Hierzu könnte ich Infos jeglicher Art gebrauchen. Sind alle Modi sinnvoll? Welche Auflösung benutzt beispielsweise MINT?
Viele Grüße
Wolfgang
-
Hallo,
wer es vielleicht noch nicht direkt per email erhalten hat: der Suska Core 2K8B ist fertig und seit heute auf www.experiment-s.de zu finden. Wir planen nun im nächsten Schritt die Hardware. Informationen hierzu folgen in Kürze.
Viele Grüße und schöne Feiertage
Wolfgang
-
Hallo,
letztes Lebenszeichen von mir in diesem Jahr: kann mir jemand helfen, Infos über den TT Funnel Chip zu finden? Ansonsten einen guten Rutsch an alle, die diesen Thread vor dem Jahreswechsel noch lesen.
Beste Grüße
Wolfgang
-
Leer
-
Wie ist denn eigentlich der Stand momentan?
-
Hi Ingo,
ich habe mich in letzter Zeit wohl etwas rar gemacht. Das liegt in meiner Arbeitsbelastung. Der IP-Core zu Suska ist im vergleich zu 2K8B etwas erweitert. Es sind nun die TFT-Modi drin, mit denen man die verschiedenen STE Auflösungen an TFTs betreiben kann. Wir haben die Fertigung der ersten zehn Boards eingeleitet, nachdem wir alle uns bekannten Hardware-Bugs beheben konnten. Die neue Hardware sieht fast gleich aus wie der Prototyp, hat aber einen vernünftigen Video DAC, einen kleinen USB Hostcontroller, ein größeres Flash und etliche Kleinigkeiten mehr. Wir rechnen noch im März mit den Boards. Danach wird der Core an die neue Hardware angepasst (kleinere Kosmetik) und dann werden wir weitersehen. Ich gebe Infos durch, wenn es was relevantes gibt.
Viele Grüße
Wolfgang
-
Hallo Wolfgang, schön wieder mal was von dir und "dem Projekt" zu hören. ;D
Ab und zu schau ich mir auch deine Seite an um mich zu informieren. Ich weis das du alles neben deinem eigentlichen Job machst und würde trotzdem gerne wissen wer voher den Job des DAC und des USB-Hostcontrollers gemacht hat. Wenn ich das richtig gelesen habe dann hast du auch einige Atari-Schnittstellen gegen gängigere Anschlüsse tauschen müssen weil die nur schwer erhältlich waren. Kannst du noch etwas dazu schreiben?
Gruß Arthur
Oh Gott, was hab ich da nur zusammengebrabbelt ;)
-
Hallo Arthur,
Der Umbau mit dem Video-DAC ist nichts besonderes. Ich habe einfach die diskrete Elektronik gegen den DAC getauscht. Der USB Hostcontroller hat zunächst auch nichts mit dem Core zu tun, ausser die Anbindung an den Mikroprozessorbus. Der Controller ist ein Chip von Maxim: MAX3421E. Das heisst in der Praxis, dass USB zwar vorhanden ist, wir aber nicht darum herumkommen Treiber dafür zu schreiben. Ich habe den ROM-Port-Stecker des Atari gegen einen 2mm Industriestecker getauscht, da es den Originalstecker nicht mehr gibt. Alle Signale sind aber aufgelegt und man kann sich bei Bedarf einen Adapter anfertigen. Die Maus und Joystick-Schnittstelle ist in der externen Tastatur vorgesehen. Dann habe ich die runde 14 polige Floppy Buchse gegen einen D-SUB Stecker getauscht. Auch hier hilft ein spezielles Anschlusskabel. Diese Entscheidung habe ich getroffen, da die 14 poligen Buchsen Auslaufmodelle sind und kaum noch erhältlich, wohingegen D-SUB an jeder Ecke zu bekommen sind.Genauso bin ich bei ACSI verfahren; die 19 poligen sind groß und schwer zu beschaffen und kommen wenn überhaupt nur in einer Uraltausführung daher. Abhilfe: 26 polige D-SUB high density Buchse. Dann ist der Extension Stecker, der im Mega ST zu finden war vorhanden aber mit anderem Steckertyp. Last but not least habe ich zur 13 poligen Monitorbuchse noch eine Standard-VGA Buchse spendiert und das Monochromsignal via Core auf die Farben gemischt, so dass sowohl alte als auch neue Bildschirme zu betreiben sind. Ich verfüge noch über etwa 65 Stück 13 polige Rund-Printbuchsen. Danach ist vermutlich Schluss und die Boards werden dann ohne diesen Buchsen ausgeliefert; es sei denn, dass sich noch eine Lieferquelle auftut oder ich einen Tip bekomme, wo es diese noch gibt.
Ich hoffe, dass diese Ausführungen Dir weiterhelfen. Die Boards sind generell im Hinblick darauf entwickelt worden, dass man mit nicht allzu komplizierten Bastelmethoden das gewünschte Ergebnis erreicht und Steckverbinder (abgesehen von den genannten) auch noch in einiger Zeit leicht beziehen kann.
Viele Grüße
Wolfgang
-
Hallo Wolfgang,
das klingt wirklich sehr viel versprechend. Ich greife mal das Thema USB und Netzwerk auf. Prinzipiell sollte es doch möglich sein die Schaltung so zu modifizieren das man sie in einem ST/TT/F030 nutzen könnte. So macht eine Treiberentwicklung für Mint doppelt sinn.
-
@Wolfgang, vielen Dank für deine ausführliche Zusammenfassung.
Gruß Arthur
-
Hallo zusammen,
nachdem ich mich schon lange nicht mehr gemeldet habe eine kurze Info, was wie gerade läuft. Die beiden Prototypen von Suska-III-C sind nun durch 10 Vorserienmodelle ergänzt worden. Hiermit haben wir die Fertigungsüberführung erledigt und testen nun die Reproduzierbarkeit der Hardware und des IP-Cores. Die Bildqualität ist durch das Ersetzen der ursprünglichen Hardware der STs durch einen modernen Video-DAC so gut, wie man es für Ataris nicht für möglich halten könnte. Screenshots demnächst. Ergänzungen gibt es in der kommenden Version des IP-Cores 2K9A in Bezug auf TFT-Tauglichkeit. Wir werden in Kürze Informationen zu den neuen Boards veröffentlichen.
Viele Grüße
Wolfgang
-
Immer wieder klasse, zu diesem Thread zurückzukehren. Ich hoffe inständig, dieser Rechner wird irgendwann in Serie gehen und zu erwerben sein.
Bis dahin weiter so und viel Erfolg!
-
Ich kann mich meinem Vor
rednerschreiber ;D nur anschließen.
Schönen Gruß
Arthur
-
Vielen Dank für die aktuellen Informationen. Ein gutes Bild am TFT ist natürlich ein Traum. Ich freue mich auf die Screenshots.
Gruß Heinz
-
Du kannst Dir sicher sein, dass ich all meine Kohle zusammen kratze um das Ding zu kaufen wenn es fertig ist
-
Hallo zusammen,
wir sind gerade bei den integralen Tests der neuen Boards und mir ist noch etwas aufgefallen, was wohl noch nicht richtig funktioniert. Es handelt sich um das Nebulus-Spiel. Der Effekt ist der folgende: das Spiel funktioniert im Prinzip. Man kann den Frosch bewegen, Kugeln abschießen. Aufzüge hoch runter geht alles. Ab und zu kommt dann dieses drehende Rad vorbei (ich kenne leider den Terminus dieses Spiels nicht, ich bezeichne das Ding als drehendes Rad). Dieses läuft von links in's Bild und wenn es den Frosch trifft, dann fällt er in's Wasser. Bei Suska-III-C ist es so, dass der Frosch sofort in's Wasser fällt, wenn dieses drehende Rad den linken Bildschirmrand betritt.
Offensichtlich wird hier eine Kollision von Rad und Frosch falsch erkannt. Hat jemand eine Ahnung, wie das in Software programmiert wird? Kennt jemand Entwickler dieses Spiels? Kann diesbezüglich jemand recherchieren? Wir können mit Suska-III-C eine ganze Menge Anwendungen starten und die laufen alle. Aber bei diesem Effekt habe ich gar keine Ahnung, wo wie oder was im Core falsch läuft.
Viele Grüße
Wolfgang
-
Cool das genau mein vorgeschlagenes Game der FPGA nicht packt.
Je nachdem wie man s sieht genau das richtige bzw genau das falsche raus gesucht.
Also geproggt hats John M. Phillips der auch Eliminator geschrieben hat. beides bei Hewson in den 80ern.
Obs den programmierer noch gibt keine Ahnung.
http://www.c64-wiki.de/index.php/Nebulus
Gruß Matthias
-
Na ja,
ich wäre mal vorsichtig mit FPGA nicht packt und so. Ich hatte nämlich schon eine gepatchte Version, die ging gar nicht. Das lag einfach an der Software. Was mir noch aufgefallen ist sind die bunten Türme bei mir. Das ist in der Wiki Beschreibung anders dargestellt. Wie sieht es denn bei Euch auf dem Bildschirm aus? Einfarbige oder bunte Türme. Das könnte schon ein Hinweis sein.
Viele Grüße
Wolfgang
-
Die sind Bunt.
Gruß Arthur
(http://dinomicro.online.fr/Test/Atari/Nebulus/Nebulus5.gif)
Bin mir nicht ganz sicher aber so ungefähr sieht es doch im ersten Level aus. Das müßte auch vom Atari sein.
Sonst mal Sunnyboy fragen. ;)
-
Wird es denn mit diesem Projekt auch weitergehen? Trotz Coldfire?
-
Ich könnte mir vorstellen das die vorhandene 68K Emulation in das FPGA des Coldfire mit einfließt. Es soll ja in beide ne Falcon-DSP implementierung rein, was auch beiden Projekten zugute kommt.
Also die Parellelen sind meiner Meinung da, nur die endplattform ist unterschiedlich
Coldfire= neue TOS Plattform
SUSKA = 99% STE kompatibel
(ich denke 1% restprobleme dürften OK/ zu erwarten sein)
Gruß Matthias
-
Ich gehe mal davon aus dass das Suska-Projekt einen großen Vorsprung gegenüber dem Coldari hat. Allerings braucht man noch für das Debuggen Zeit.
Das hat Mr.Medusa ja fast alles noch vor sich. Auf der anderen Seite hat Mr.Medus aber auch viel Erfahrungen mit Atari, TOS und so. Wenn er aber nicht schon etwas im stillen vorgearbeitet hat, dann rechne ich mit min. 2 Jahren.
Das Suka schätze ich braucht noch vielleicht ein 3/4 Jahr bis man es anbieten kann evtl. sogar weniger.
Das Debugging wird ja, wie bei jedem System, eigentlich nie zu ende sein. Dadurch das man den Core aber Programmieren kann ist man hier sehr fllexible.
Gruß Arthur
-
Hi,
also man sollte sich mal zwei dinge vor Augen halten.
Er hat denn T40 gebaut und denn Hades gebaut und damit schon Entwicklungsarbeit die er mit einfliessen lassen kann. Sprich er hat ein System was er nur noch Modifizieren muß.
Von daher denke ich das er vieles bereits fertig hat, kann mich aber auch irren. Und egal wie und was, er hat Großartige Leistung erbracht und das muß man ihm hoch Anrechnen.
-
Hallo,
ich möchte hier mal einiges klarstellen. Fredie und ich sind in intensivem Kontakt. Der Coldari beruht in Bezug auf die Custom Chips auf dem Suska Projekt. Ich möchte hier nur kurz darauf hinweisen, dass es sich um zwei völlig unabhängige Ansätze handelt. Ich bin diesbezüglich völlig Arthur's Meinung. Es wird kein dreiviertel Jahr dauern, bis es Nesws bezüglich Suska-III-C bzw. Suska-III-T gibt.
Bis demnächst
Wolfgang
-
Guten Morgen,
ich benötige wieder einmal Infos. Kann mir bitte jemand sagen, ob TOS1.0 TOS1.02 und TOS1.04 auf 16MHz getakteten STE oder Mega STE Maschinen laufen? Grund: TOS1.0 läuft aber erkennt kein Floppydrive. TOS1.02 wirft beim Booten Bomben. TOS1.04 läuft aber erkennt kein Floppydrive. TOS1.62 läuft gut. TOS 2.05 läuft gut. TOS2.06 läuft gut. Emutos läuft gut. Hat jemand diesbezüglich irgendwelche Ideen?
Danke und viele Grüße
Wolfgang
-
War da nicht was mit HD-Floppys bei denn alten Tose?
-
Mir war auch so, wie wenn es da Probleme gab. Ich weiss es eben nicht mehr und finde auch nichts so richtig hierzu. Das TOS1.02 überschreibt sich übrigens seinen eigenen Stack. Vielleicht zu schnelle Interruptfolgen infolge der 16MHz.
-
Kannst du nicht Testweise denn HD-Mod ausschalten? Oder wäre das zu viel Aufwand?
-
Der HD Mode wird automatisch ausgeschaltet, wenn eine DD Floppy eingelegt wird. Geht aber trotzdem nicht.
-
Die ct hatte doch mal einen 16Mhz Beschleuniger gebaut, mir war so als hätten die da was darüber geschrieben. Ich muß denn Artikel auch irgendwo haben. Ich werde mal suchen ob ich ihn finde.
-
Hallo Wolfgang, ab mindestens TOS 2.0x hat Atari doch auch ins Betriebsystem die Funktion zum formatieren von HD-Disketten rein gepackt. Probleme gab es auch im HD-Betrieb wegen der Steprate die ja 3ms nicht unterschreiten sollte was aber im HD-Betrieb mit einigen Modulen ohne automatische Stepratenanpassung passierte so das durch den am Floppykontroller anliegenden Takt von 16MHz im HD-Betrieb die Steprate mit 1,5ms zu kurz war. Ich weiß jetzt aber nicht wie Atari das Problem gelöst hat. Entweder haben sie eine Schaltung eingebaut die für 3ms im HD-Betrieb sorgte oder sie haben es über das Betriebsystem geregelt und im HD-Betrieb die Steprate verdoppelt so das im Endeffekt weiterhin 3ms gewährleistet waren.
Hier ein kleines Programm von Claus Brod das in den Autoordner der Festplatte kommt.
step66.prg (http://mcp.ignorelist.com/typo3/step66.prg)
Das Programm verdoppelt die Steprate so das unter alten TOS-Versionen wo HD-Module ohne Stepratenanpassung eingebaut wurden im HD-Betrieb auch 3ms geliefert bekommen. Die Komplette Diskette Scheibenkleister gibt es hier Kleisterscheibe (http://www.clausbrod.de/download/atari/kleisterscheibe_v233.zip)
Es kann natürlich auch andere Ursachen haben aber das ist die, die mir spontan einfiel.
Gruß Arthur
P.S. Auf der Kleisterscheibe sind viele Informationen rund um Massenspeicher am ST inkl. Quellcode's.
Das Programm muß nicht unbedingt in den Autoordner und kann auch so gestartet werden. Die erst Zahl ist für Laufwerk a: und die zweite Zahl für Laufwerk b: .
-
Hallo Arthur,
vielen Dank für diese Infos. Das klingt plausibel. Ich habe natürlich die Steprate je nach HD und DD automatisch angepasst. Das stimmt in meinem Controller. Aber die ganze Datenverarbeitung geht schneller. Das liegt daran, dass ich synchron modelliere und den Floppycontroller immer mit 16MHz betreibe. Umgeschaltete Taktsysteme, wie man das früher gemacht hat sind in modernen Digitalchips Harakiri und führen in der Regel zu Nichtfunktionieren. Ich denke, dass ich diesbezüglich einfach Informationen zusammenschreiben werde. Schließlich kann es ja auch sein, dass die alten TOS-Varianten in einigen Punkten schlampig programmiert sind und solche Systemverbesserungen nicht vertragen. Ich würde das System aber nicht deswegen schlechter machen sondern auf TOS1.62 up verweisen. Ich muss momentan noch eine etwas kniffelige Sache im Zusammenhang mit dem Booten des Systems lösen und dann ist der Core soweit auf die Serienhardware angepasst und läuft stabil.
In Kürze mehr.
Viele Grüße
Wolfgang
-
Hallo Wolfgang, vergiss was ich da geschrieben habe. Du hast ja das Problem das die "Tosen" Bomben schmeissen oder keine Laufwerke erkennen. Das muß was anderes sein. Ich kenne aber niemanden der in einen STe TOS 1.xx drin hat.
Ich weis nicht, war da nicht irgendwas mit dem Cookiejar der ab 1.4 oder 1.6 dazu gekommen ist und wo das Betriebsystem nachschaut was es für Hardware hat?
Gruß Arthur
P.S. Man bist du schnell. ;)
-
Hallo Wolfgang,
Ich würde das System aber nicht deswegen schlechter machen sondern auf TOS1.62 up verweisen.
Ich würde in das Thema nicht zu viel Zeit investieren. Es dürfte nicht sehr viele Programme geben, die ein TOS kleiner 1.62 zwingend benötigen und heute intensiv/produktiv verwendet werden. Daher finde ich TOS 1.62 als Mindestversion vollkommen in Ordnung.
Gruß Heinz
-
TOS kleiner als 1.62 ist glaube ich nur benötigt für Spiele.
-
Ich habe gerade bei CaSTaway gelesen, das TOS 1.02 die beste Wahl für Spiele sein soll, da weniger buggy als 1.0 aber am kompatibelsten für ST Spiele.
Ich kann nicht beurteilen, ob das wirklich so ist. In meinem 520 ST+ hatte ich jedenfalls mit TOS 1.0x einige Probleme mit Spielen und habe mich damals richtig gärgert, wenn ich wiedermal das schmale Taschengeld in ein Spiel investiert habe, das dann nicht ordentlich lief (z.B. M1 Tank Platoon und Imperium).
Ich finde wie gesagt TOS 1.62 als Minimum in Ordnung. Sollte sich später größerer Bedarf für TOS 1.00 oder 1.02 zeigen, kann man das ja ggf. nochmal mit vereinten Kräften angehen. Wenn die HW dann verfügbar ist, können auch mehr Leute beim Testen mithelfen (wenn auch vielleicht nicht beim Programmieren der HW).
Gurß Heinz
-
Hallo Martin,
ich sehe das absolut genauso. Es wird wohl davon abhängen, wieviele Personen bei der ganzen Sache mitmachen. Ich verwende momentan sehr viel Energie, die Hardware in Kürze zur Verfügung stellen zu können (wie oft blieben Projekte im Prototypenstadium stecken). Das Umsetzen in eine Serie erfordert Erfahrung, Durchhaltevermögen und Last but not Least auch einen hohen finanziellen Einsatz. Wir haben das getan. Nun hoffe ich, dass das auch mitgertagen wird. Wir werden sehen. Wenn die Boards verbreitet sind, der Source ist ja sowieso offen, wird das Ganze eine Fahrt aufnehmen, die ich nicht abzuschätzen vermag. Auf jeden Fall wird's dann super.
Viele Grüße
Wolfgang
-
Hallo Wolfgang, ich weis ja nicht wieviele Prototypen schon vorhanden sind aber wenn du Tester suchst, die dich unterstützen, dann werden wir dir gerne dabei behilflich sein und die Prototypen durch die Mangel drehen um Fehler aufzudecken. Auch ich würde mich dafür selbstlos zu Verfügung stellen. Verschiedene Mäuse, Tastaturen, Monitore und Festplatten (SCSI, IDE und ACSI) sind noch vorhanden ;)
Gruß Arthur
-
Hallo Arthur,
danke für's Angebot. Ich habe bezüglich weiterer Planungen heute ein Treffen und werde das mal diskutieren. Wir haben neben unseren Entwicklungsboards sieben weitere funktionierende Serienmodelle hier auf dem Tisch.
Ich habe aber vielleicht schon mal was für diejenigen, die ein Oszilloskop zur Verfügung haben oder für diejenigen, die gerne am Internet oder wo auch immer recherchieren.
Es geht um TOS 1.00 und TOS 1.04 und das Nichterkennen des Floppy Laufwerks. Nach meiner Info wird das so durchgeführt: Es wird ein Restore Kommando an das Floppy abgesetzt und nach einem Interrupt vom Floppy Controller das Status Register gelesen. Welche Info ausgewertet wird weiss ich nicht. Auf jeden Fall kann ich den 1772 Interrupt sehen und die Betriebssysteme ab 1.62 erkennen auch das Floppy korrekt. Mir ist überhaupt nicht klar, was bei TOS 1.00 oder TOS 1.04 anders sein soll, so dass diese das Laufwerk nicht sehen? Vielleicht kann jemand mehr dazu sagen oder einfach durch Messen an originaler Hardware irgendwas herausbekommen. Ich gehe davon aus, dass der 1772 Floppy Controller Core gut arbeitet, da er unter beispielsweise TOS 2.06 keinerlei Probleme bereitet. Allerdings ist eben der Prozessor, der DMA Core und der 1772 Core mit 16MHz getaktet anstatt mit 8.
Viele Grüße
Wolfgang
-
Hallo Wolfgang,
ich habe da noch einen ST rumstehen und könnte da auch mal denn Analyzer ran papen und das ganze mal aufzeichnen. Würde aber erst kommende Woche gehen. Müsstest mir nur mal sagen welche Signale dafür relevant sind wären.
-
Ich habe hier Bücher, die sich mit dem 1772 beschäftigen. Wenn Interesse besteht kann ich die Entsprechenden Seiten Einscannen und zur Verfügung stellen.
Die Bücher sind:
ATARI Profibuch ST-STE-TT (Jankowski/Rabich/Reschke)
ATARI ST PROGRAMMIER-HANDBUCH (Möllmann)
Das endgültige Atari ST Handbuch (Liesert)
Das neue Hardware-Handbuch zum Atari ST (Reimann)
Ich habe die entsprechenden Stellen überflogen, kann aber nicht sagen ob wirklich relevante Informationen darin zu finden sind.
-
Hallo ToPeG,
entschluldige das ich hier was sage! Aber diese Bücher hat wohl jeder in der Hand der an Hardware bastelt. Ich meine Wolfgang hat alle IC´s des ST´s in VHDL nachgebildet daher bin ich mir 200%ig sicher das er weiß wie er funktioniert. (Nicht böse gemeint)
-
Hallo,
danke für's Angebot die Infos aus dem Profibuch zu scannen. Ich habe dieses Buch und es ist bereits total zerfleddert. Neue Bücher gibt's auch nicht mehr. Daher fände ich einen Scan als pdf eine super Idee. Am besten das komplette Buch inklusive der STE und TT Erweiterungen :)
Viele Grüße
Wolfgang
-
Leer
-
Hallo,
der 1772 kompatible Core wird mit 16MHz getaktet und passt automatisch alle Timings an. Aber das mit den Zeitschleifen ist ein guter Hinweis. Das könnte natürlich der Grund sein. Das Problem, welches sich bei der FPGA Implementierung ergibt: die internen PLLs laufen nicht unter 10MHz. Daher habe ich 16MHz als Grundfrequenz gewählt. Aber ich werde es mal auf 10MHz umstellen und ausprobieren. Ich melde mich dann.
Viele Grüße
Wolfgang
-
Hallo,
danke für's Angebot die Infos aus dem Profibuch zu scannen. Ich habe dieses Buch und es ist bereits total zerfleddert. Neue Bücher gibt's auch nicht mehr. Daher fände ich einen Scan als pdf eine super Idee. Am besten das komplette Buch inklusive der STE und TT Erweiterungen :)
Ich habe es gerade an getestet, wie lange es dauern würde. Wenn es mit der Geschwindigkeit weiter geht, werde ich alleine für das Scannen 30 Stunden brauchen und ich denke nochmal 10 Stunden für das Nachbearbeiten.
Ich könnte in einem Monat fertig sein. :-)
Das Lohnt sich also wirklich nur, wenn sich wirklich jemand für die Scans interessiert. Wenn sich ein paar Leute finden, die das Buch haben wollen, mache ich es gerne.
Ich habe dazu auch eine neues Thema aufgemacht: http://forum.atari-home.de/index.php?topic=5827.0 (http://forum.atari-home.de/index.php?topic=5827.0)
-
Hallo,
bin gerade noch per Zufall online. Ich fände es genial, würde es aber nicht zu breit treten (Lizenzrechte und so). Angemessen and en etwa 10.000 Stunden der Core-Entwicklung fände ich das ok - Gott bin ich arogant! - sorry.
Viele Grüße
Wolfgang
-
Hier der Link (http://forum.atari-home.de/index.php?topic=5827.0) zum Thema Profibuch als PDF.
Gruß Arthur
-
Trotz allem,
ein pdf wäre auch ohne Suchfunktion gut. Die Aufteilung des Buchs ist so logisch, dass man eigentlich auch ohne Suche schnell findet, was man will.
Schöne Grüße
Wolfgang
-
Hallo an alle,
das mit der CPU Taktfrequenz von Gerhard war ein goldener Tip. Ich habe den Core provisorisch hingefrickelt. Kann man nicht so lassen aber nun laufen auch TOS1.00, TOS1.02 und TOS1.04. Die Bildausgabe ist sehr dürftig mit der provisorischen Erweiterung. Wenn ich es gerichtet habe werde ich dann den letzten mir bekannten Effekt untersuchen; ob Nebulus dann soweit ok läuft.
Schöne Grüße
Wolfgang
-
Hallo Wolfgang
Soweit ich mich richtig erinnere, beinhaltet die BIOS-Zeitverzögerungsschleife für den 1772 einen festen Wert von 32 Taktzyklen, (move.w #$20,d7) dieser Wert müsste bei 16MHz einfach verdoppelt werden.
Wie steht es denn um die Lauffähigkeit von GfA-Basic?
-
Unglaublich, was Ihr alle wisst. Ich könnte das natürlich in TOS patchen oder im Core dynamisch kontrollieren. Ich nehme aber an, dass es öfters einmal 'unsauber' geschriebene Software gibt. Somit denke ich, dass das mit der CPU-Taktumschaltung sinnvoll gelöst werden kann. Ich habe GFA Basic noch nicht getestet (hab' sogar 'ne ofizielle Lizenz). Ich werde es mal rauskramen und testen.
Grüße
Wolfgang
-
Angemessen and en etwa 10.000 Stunden der Core-Entwicklung fände ich das ok
Da ist das Scannen wirklich nur ein kleiner Aufwand und Nachbearbeiten.
Gott bin ich arogant! - sorry.
Hast alles Recht dazu, ist ja auch eine gigantische Leistung.
-
Ich fnde das Thema Profibuch sollte hier jetzt nicht weiter breit getreten werden da ToPeG dafür einen eigenen Thread auf gemacht hat.
Hier der Link (http://forum.atari-home.de/index.php?topic=5827.0) zum Thema Profibuch als PDF.
Gruß Arthur
-
Hallo,
also der Stand ist nun so: der Core ist umgebaut auf langsamere CPU-Geschwindigkeit; via Konfigurationsschalter wählbar. Ich habe es nicht mit Gated-Clocks gelöst, da zu instabil. Der Trick: bei Zugriffen auf das Betriebssystemflash wird das Data Acknowledge verzögert. Damit wird's langsamer. Nun gehen TOS1.00 und TOS1.04. TOS1.02 geht nicht, was auch nichts ausmacht, wie ich finde.Dieses läuft tatsächlich nur, wenn der ganze Core langsamer getaktet wird, was aber mit dem verschränkten Speicherzugriff, DMA, Video-Timing für Multisync-Monitore usw. Schwierigkeiten bereitet. Daher habe ich nun diesen Kompromiss gewählt. Soweit ich beurteilen kann, läuft GFA-Basic gut. Leider funktioniert Nebulus immer noch nicht. Ich werde den Stand des Cores demnächst einfrieren, und mehr Zeit auf die Doku verwenden, da im Juni Version 2K9A ansteht.
Viele Grüße
Wolfgang
-
Hallo Wolfgang,
danke für die aktuellen Infos. Schön, das nun auch zwei gaaanz alte TOS Versionen laufen. Ich brauch das zwar nicht, an Kompatibilität ist das so aber wohl nicht mehr zu übertreffen ;-)
Gruß & Dank Heinz
-
Hallo Arthur,
danke für's Angebot. Ich habe bezüglich weiterer Planungen heute ein Treffen und werde das mal diskutieren. Wir haben neben unseren Entwicklungsboards sieben weitere funktionierende Serienmodelle hier auf dem Tisch.
Hallo Wolfgang, was hatte denn euer Treffen bezüglich der "Tester" ergeben? Ich finde das wirklich wichtig denn ausser GFA-Basic und Nebulus gibt es ja noch unmengen von Software. Es ist sicherlich nicht möglich und notwendig das jede Software laufen muß, allerdings werden viele Progamme wegen der selben Ursache auf dem SUSKA nicht laufen und solche Bugs werdet ihr dann schneller finden. Ich möchte jetzt nicht zu weit vorgreifen aber ich bin natürlich sehr neugierig.
Viele Grüße Arthur
-
Hallo Arthur,
das Ganze hat jetzt Aussmasse angenommen, die ich/wir nicht mehr selber bewältigen können. Wir werden daher wie folgt vorgehen: die Suska-III-C wird es im Juni als verfügbar geben. Dann hängt es davon ab, wie viele Personen mitmachen. Die Testergebnisse können wir, wenn präzise formuliert, recht schnell umsetzen. Das liegt daran, dass ich den Core ganz genau kenne :) Ich würde mir wünschen, dass das Ganze eine Eigendynamik entwickelt, die uns einen rechten Stress verpasst. Dann wird's was. Wir werden sehen.
Bis bald
Wolfgang
-
Also Software durchtesten kann ich auch. Ich kann auch Codesequencen programmieren, falls das hilft.
Zwar nicht Assembler aber Pascaltext und zur not Pure-C. Für irgendwelche Testschleifen dürfte das aber reichen.
Gibts eigentlich nen ST-Benchmarktool ???
Gruß Matthias
-
Klammheimlich hat Wolfgang den Shop ins Netz gestellt! D.h. dass das Suska-C Board jetzt bestellt werden kann! Ich muss allerdings zugeben, dass ich vom Preis etwas irritiert bin. In der Umfrage war noch von ca. 390 EUR für Suska-C die Rede, jetzt sind es 619 EUR geworden. :-\
-
Tja, bei dem Preis leider noch uninteressanter geworden als zum alten Preis. Zumal wohl auch hier wieder der Formfaktor zum Einau in gängige Gehäuse völlig außer acht gelassen wurde. Verstehe wer will.
-
Also ich möchte sagen das der Core immer noch Hocjinteressant ist, aber bei derzeitigem Stand meiner Finanzen waren 350,- schon hart... aber über 600 das geht nicht, nichtmal wenn ich mich von ganz vielen Dingen trenne.
Ich weis durchaus die Arbeit zu schätzen, sowie die Zeit und Geld die du in das Projekt gesteckt hast, aber für ein STE-Design sind 600 Flocken zu viel für mich...
Sorry ich bin erstmal von der Liste. Das kann ich mir nicht leisten.
Gruß Matthias
-
Der Coldfire Atari ist interessanter und sogar die günstigere variante....
-
Was mich zu der Frage bringt was am SUSKA den Preis fast verdoppelte, kann ja maximal das Board sein, und das müsste mit anderem Lieferanten doch zu korrigieren sein.
Auf Wunsch von Wolfgang kann ich mich "umhören", bräuchte aber dann wohl ne PM wer der derzeitige Lieferant ist.
Gruß Matthias
-
Hallo,
es ist unbestritten, in diesem Projekt steckt sehr viel.
Arbeit .
Schade, dass dieses tolle Board durch den neuen
Preis von 619,00 Euro wohl nur wenigen zugänglich
sein wird.
:-[ :-[ :-[
Gruss Martin
-
Der Coldfire Atari ist interessanter und sogar die günstigere variante....
Das stimmt so nicht Frederick. Der Suska ist ein 1:1 Nachbau eines 1040STE mit einigern Optimierten Features. Der Coldari ist ein neu entwickelter Computer der Kompatibel ist. Aber für Classic Computing anhänger ist der coldari nichts da wohl sehr viele Spiele und Demos nicht darauf laufen werden oder nur bedingt.
-
Hallo zusammen,
wie Ihr gesehen habt, haben wir nun die Suska-III-C Boards in unserem Produktportfolio. Ich sehe die Diskussionen um den Preis und habe das schon im Vorfeld vermutet. Wir haben uns entschlossen das Suska-III-C Board in seiner vollbestückten Variante (abgesehen von der limitierten Anzahl verbleibender Atari Videobuchsen) anzubieten. Ferner muss berücksichtigt werden, dass Vater Staat mit etwa 100€ zugreift. Wer Lust hat die Bauteile einmal zusammenzurechnen wird dann schnell feststellen, dass bei diesen sehr speziellen Kleinserien nicht mehr allzuviel übrig bleibt für Bestückung, Nebenkosten, Netzteil und schließlich Gewinn. Ich habe über Jahre den Suska-III-C IP-Core gepflegt. Er liegt ab heute in seiner Version 2K9A zum Download bereit. Diese Arbeit ist ehrenamtlich. Mittlerweile stecken aber im Bereich Prototyping und Vorserie etc. zwischen 10.000€ und 20.000€ Entwicklungskosten. Daher werdet Ihr sicherlich verstehen, dass wir einen Gewinn machen müssen, um diese Kosten wieder einzuspielen. Wir gehen davon aus, dass diese Boards im privaten Bereich nicht mehrere hundert mal verkauft werden. Schließlich müssen wir noch Rückläufer etc. berücksichtigen. Daher ist unser Entschluss gefallen, dieses Board als professionelles Entwicklerboard und als Schulungsboard zu verkaufen. Ich möchte damit auch Abstand von dem sehr schnellebigen Embedded Markt nehmen, in dem Produkte eine Halbwertszeit von wenigen Monaten haben. Wir werden die Verfügbarkeit dieses Boards ähnlich handhaben wie beispielsweise die Viplax Produktlinie von Inventronik, die seit 2003 lieferbar ist und sich weiterhin einer großen Beliebtheit erfreut, letztendlich weil die Kunden mittlerweile wissen, welche Qualität sie mit diesen Produkten erhalten.
Wir von Inventronik haben Erfahrung im Bereich dieser Kleinserien und Spezialgerätschaften und daher möchte ich noch anmerken, dass ich es für unwahrscheinlich halte, dass ähnliche Hardware, die vielleicht in der Zukunft verfügbar sein wird, viel günstiger zu haben ist, wenn eine vernünftige betriebswirtschaftliche Kalkilation zugrunde liegt.
Ich wünsche auf jeden Fall allen viel Spaß mit dem neuen Core, der nun auch TFTs ansteuern kann und fehlerbereinigt ist. Ein Handbuch und das Schaltbild zu Suska-III-C finden sich im Verzeichnis Documentation.
Viele Grüße
Wolfgang
-
Der Coldfire Atari ist interessanter und sogar die günstigere variante....
Ich möchte dazu jetzt auch einiges anmerken.
Wir haben von Beginn an beim ACP versucht solche Konkurrenz nicht entstehen zu lassen. Dem Suska liegt, wie bereits öfter ausgeführt, ein anderes Konzept zu Grunde. Wir waren verdammt froh, als Wolfgang sich bereiterklärte beim ACP mitzumachen, und sowohl sein herausragendes Wissen in Bezug auf Hardware, als auch seinen Core zur Verfügung zu stellen.
Die Atari-Szenerie ist nicht mehr groß genug um gegeneinander zu arbeiten. Ganz im Gegenteil, der Schlüssel liegt in Zusammenarbeit sowie Erkennung und Ausnutzung von Synergieeffekten. Insofern muß euch auch klar sein, daß das ACP niemals so weit wäre, wenn Wolfgang nicht seit über fünf Jahren Unmengen an Zeit und Energie in das Suska gesteckt hätte! Das ACP-Board beruht zu guten Teilen direkt auf Wolfgangs Core sowie seinem Können!
Zum ersten mal seit einer Dekade ist nun ein neuer Atari-kompatibler Rechner – das Suska – verfügbar. Eigentlich ein Grund zu höchster Freude. Besonders toll ist, daß wir somit ein Board haben, daß sehr langfristig erhältlich sein wird, und eine noch nie dagewesene Kompatibilität aufweist.
Für spezielle Anforderungen ist das Suska sicherlich geeigneter als das ACP-Board. Ich würd euch bitten die Unterschiede wahrzunehmen, und sinnvoll für euch zu entscheiden was ihr benötigt. Die Projekte gegeneinander auszuspielen ist sicherlich das Letzte was irgendwie sinnvoll ist. Zumal Wolfgang auch beim garantiert nichtkommerziellen ACP eine wichtige Rolle spielt.
In Zukunft werden wir zwei lieferbare (!) Atari-Rechner für unterschiedliche Anforderungen haben. Es geht also bergauf mit unserer Plattform. Von euch würde ich mir wünschen, daß hier keine Konkurrenz kostruiert wird, da sie von Entwicklerseite definitiv nicht besteht.
-
Wow, besser hätte ich es nicht sagen können. Und wenn es mir möglich ist, werde ich mir beide Systeme ins Haus holen das ist so sicher wie das Ahmen in der Kirche. Beide Systeme sind in meinen Augen zwei getrennte Systeme für unterschiedliche Einsatzzwecke und somit sehe ich von meiner Seite aus garkeine Konkurrenz.
Also ist so wie ich die Sache sehe das Suska bereits erhältlich?
NA dann schnell Auto Verkaufen, Fernseher Verkaufen, VDR-Verkaufen.
Nee Joke, na muß mal sehen wie ich das Geld zusammen Kratze. Mhh nen XL weider pimpen und Verkaufen ja das geht.
-
Ein bemerkenswerter Beitrag! Hut ab!
Matthias, Du hast den Nagel voll auf den Kopf getroffen.
Der Coldfire Atari ist interessanter und sogar die günstigere variante....
Ich möchte dazu jetzt auch einiges anmerken.
Wir haben von Beginn an beim ACP versucht solche Konkurrenz nicht entstehen zu lassen. Dem Suska liegt, wie bereits öfter ausgeführt, ein anderes Konzept zu Grunde. Wir waren verdammt froh, als Wolfgang sich bereiterklärte beim ACP mitzumachen, und sowohl sein herausragendes Wissen in Bezug auf Hardware, als auch seinen Core zur Verfügung zu stellen.
Die Atari-Szenerie ist nicht mehr groß genug um gegeneinander zu arbeiten. Ganz im Gegenteil, der Schlüssel liegt in Zusammenarbeit sowie Erkennung und Ausnutzung von Synergieeffekten. Insofern muß euch auch klar sein, daß das ACP niemals so weit wäre, wenn Wolfgang nicht seit über fünf Jahren Unmengen an Zeit und Energie in das Suska gesteckt hätte! Das ACP-Board beruht zu guten Teilen direkt auf Wolfgangs Core sowie seinem Können!
Zum ersten mal seit einer Dekade ist nun ein neuer Atari-kompatibler Rechner – das Suska – verfügbar. Eigentlich ein Grund zu höchster Freude. Besonders toll ist, daß wir somit ein Board haben, daß sehr langfristig erhältlich sein wird, und eine noch nie dagewesene Kompatibilität aufweist.
Für spezielle Anforderungen ist das Suska sicherlich geeigneter als das ACP-Board. Ich würd euch bitten die Unterschiede wahrzunehmen, und sinnvoll für euch zu entscheiden was ihr benötigt. Die Projekte gegeneinander auszuspielen ist sicherlich das Letzte was irgendwie sinnvoll ist. Zumal Wolfgang auch beim garantiert nichtkommerziellen ACP eine wichtige Rolle spielt.
In Zukunft werden wir zwei lieferbare (!) Atari-Rechner für unterschiedliche Anforderungen haben. Es geht also bergauf mit unserer Plattform. Von euch würde ich mir wünschen, daß hier keine Konkurrenz kostruiert wird, da sie von Entwicklerseite definitiv nicht besteht.
-
wischen 10.000€ und 20.000€ Entwicklungskosten
WOW, ich wundere mich das nicht nochmal ein spendenaufruf war. Das du durchaus Kosten selbst geschultert hast war klar, aber im 5-Stelligen Bereich ist ja wahnsinn.
Insofern muß euch auch klar sein, daß das ACP niemals so weit wäre, wenn Wolfgang nicht seit über fünf Jahren Unmengen an Zeit und Energie in das Suska gesteckt hätte!
Das ist nicht zu bestreiten. Und verdient auch großen Respekt.
Zum ersten mal seit einer Dekade ist nun ein neuer Atari-kompatibler Rechner – das Suska – verfügbar. Eigentlich ein Grund zu höchster Freude
Grundsätzlich ja, aber ich kann mir ihn nicht leisten - ich kann halt Geld nicht ausgeben das ich nicht habe. Um so mehr beruhigt mich das es für einen größeren Zeitraum verfügbar sein wird. Vieleicht hab ich ja in ein/zwei Jahren genug Kohle.
Von euch würde ich mir wünschen, daß hier keine Konkurrenz kostruiert wird, da sie von Entwicklerseite definitiv nicht besteht.
Ich seh da keine Konkurenz nur ein Geldproblem meinerseits.
Anmerkung zu meiner finanziellen Lage
Wenn die CDU tatsächlich an die Regierung kommt im September unden Mehrwertsteuersatz von 7 auf 19% anhebt, dann wird sogar zukünftig meine Frau wieder arbeiten müssen, sonst langts eh gar nicht mehr, wie wir das dann mit den Kids machen ist mir rätselhaft. Für Atari bleibt mir wohl dann gar kein Geld mehr, und das ist jetzt schon mager.
-
Anmerkung zu meiner finanziellen Lage
Wenn die CDU tatsächlich an die Regierung kommt im September unden Mehrwertsteuersatz von 7 auf 19% anhebt, dann wird sogar zukünftig meine Frau wieder arbeiten müssen, sonst langts eh gar nicht mehr, wie wir das dann mit den Kids machen ist mir rätselhaft. Für Atari bleibt mir wohl dann gar kein Geld mehr, und das ist jetzt schon mager.
Ich glaube nicht, daß man die anstehende Mehrwertsteuererhöhung an einer bestimmten Partei oder Koalition wird festmachen können.
Angesichts der extremen Staatsverschuldung wäre es ein wahres Wunder, wenn die Mehrwertsteuer nicht in absehbarer Zeit erhöht wird - egal, wer "dran" kommt.
Politiker, die, aus welchen Gründen auch immer, heute eine nach der Wahl anstehende Erhöhung der Mehrwertsteuer verneinen, sind LÜGNER oder IDIOTEN.
-
Ich glaube nicht, daß man die anstehende Mehrwertsteuererhöhung an einer bestimmten Partei oder Koalition wird festmachen können.
Oh doch, das kann man, auch wurde immer bei den schwarzen die meiste Kohle raus gehauen. Und wenn dann alles im argen war dann kamen die roten und durften die versalzene Suppe auslöffeln. Die Rentenrücklagen hat Kohl als "Portokasse" bezeichnet um die Wiedervereinigung und das Begrüßungsgeld zu finanzieren. Dafür dürfen wir dann bis 67 und was weis ich.....oh doch das kann mann festmachen. Die schwarzen holens immer von denen dies spüren. Und Steuererhöhung für Nahrungsmittel spürt auch ein Herz-4ler, dem die schwarzen sicher nicht dann 12% mehr geben um das auszugleichen. In der Branche für Erneuerbare Energien arbeiten derzeit 4Mio in Deutschland. Die Jobs sind in den letzten 5 Jahren entstanden. Betreffen nicht die aktuelle Krise und es boomt immer noch. Das ist dem erneuerbaren Energiengesetz zu verdanken, das bei schwarz in 10 Jahren noch nicht kommen würde, die wollen nur weiter EON/RWE & Co weiter das Geld in den Arsch schieben, obs dann 4 Mio Arbeitslose mehr oder weniger gibt juckt die ja nicht. Oder unsere Scheinheilig CSU...warumw ollen die nicht das die Agrarsubventionen offengelegt werden ?? ach Datenschutz wars...genau ...Datenschutz... das kommt der Partei die die ersten waren mit Überwachung von Inetrnet, einschleusung von Trojanern und aushebelung jeder Privatsphäre....pfui da kotz ich doch.... das kann man ALLES an einer Partei fest machen. Und wer gleubt alles wird besser für die allgemeinheit wenn Gelb/Schwarz den großen Konzernen/Banken noch mehr Millionen in den Arsch schiebt der ist ein IDIOT. Für den Ottonormalverbraucher haben die noch nie was übrig gehabt ausser das letzte Geld aus der Tasche ziehen.
Wie wärs denn mal mit ein paar Steuern auf Zertifikate/Aktien, oder der einen Million die jeden Tag jedes KKW erwirtschaftet - das erhalten die Stromkonzerne kostenlos. Mit kompletter übernahme aller Risiken durch den Staat. Sogar jährlich 7 Milliarden für entsorgen zahlt der Staat.... Die Stromkonzerne zahlen da nix. Würden die ganzen Kosten nicht durch den Staat gedeckt würde 1KW7h KKW ca. 2,-Euro kosten... dann wär auch das abschalten der KKW kein Thema mehr. Ach ja 40km von mir weg entsteht in den nächsten Jahren ein Endlager...wird aber nicht so genannt, da es nur ein paar Hallen sind wo die Kastoren abgestellt werden... juhuu dann können auch meine Kinder mal strahlen - selbst ohne Geld.
Müssten die Strommultis die Entsorgung des Atommülls selber tragen, hätte man das Geld für was man die Steuer anheben will.
Thema Familie.
Oh Frau von der Laien schön das es Eltermgeld gibt.
Beim alten Erziehungsgeld hat mein immer weniger bekommen, je mehr man verdient. Jetzt bekommt mann mehr je mehr mann verdient...geile sache... wir hatten nur mindestsatz von 300,- Monat - och Steuerfrei, ich muss nur den prograssionsvorbehalt berücksichtigen der mich...zu einer nachzahlung von 300,- Steuern veranlasst. Voll Sozial - aber jemand mit 2000,- NETTO der bekommt den höchstsatz...weg von den armen - hin zu den Reichen... Ach und früher warens 24 Monate jetzt sind 12 naja langt halt sonst nicht für alle Besserverdiener... die umstellung macht bei mir Vegrleich Kind1 zu Kind 2 einen Verlust von 3000,- Euro aus auf 2 Jahre- Danke CDU!
Ach und schön das die Steuerfreibeträge angehoben wurden... nützt natürlich nur denen was die viel verdienen... Ich komm erst gar nicht an die alten grenzen...von den neuen ganz zu schweigen.
Tschuldigung aber ich musste mich da mal auskotzen. Den über schwarz-gelb kann ich kein gutes Haar lassen, die machen mich nur ärmer. Und das ist ein merkmal dieser Parteien.
-
Und jetzt wieder zum schönen Teil des Lebens:
Suska!!!
;D
-
Wow, ich bin schwer beeindruckt, das nun ein neues Atari-Board verfübgar ist. Vielen Dank!!!
Die Aufwände und Kosten rund um die Entwicklung rechtfertigen die Kosten für das Board mit Sicherheit und ich gehe davon aus, das auch bei diesem Preis eine erhebliche Zahl von Boards verkauft werden muß, damit zunächst die Entwicklungskosten wieder drin sind und tatsächlich Gewinn (und nicht nur ein Deckungsbeitrag) erzielt wird.
Um nun ein Suska als Spontankauf zu erstehen ist es allerdings klar zu teuer für mich. Gut is jedoch, das das Board langfirstig verfügbar sein soll und sein Fortbestehen nicht vom kurzfristigen Erfolg abhängt. Ich denke nachdem der Preis raus ist müssen - so wie ich - erstmal einige durchatmen und das Sparen intensivieren.
Für mich heißt das ganz klar noch ein paar Sachen mehr verkaufen und dann einen schönen neuen Atari kaufen :-) In letzter Zeit habe ich immer weniger Spaß an dem ewigen Hardwaregebastel. Ich möchte lieber mal wieder den Atari einfach einschalten und Spaß damit haben. Meine hochgerüsteten Kisten sind da leider viel zu zickig. Deshalb ist auch mein CT63 Falcon schon sehr nah an der Abschußliste zugunsten eines der neuen Boards.
Also nochmal DANKE für die unermütliche, konsquente und zu Ende gebrachte Entwicklungs und Herstellungsarbeit. Jetzt liegt es an uns Usern prakisches Leben in so ein System zu bringen.
Gruß Heinz
-
ähm, und was heist jetzt SUSKA, da bin ich immer rnoch nicht drauf gekommen
-
Meinen größten Respekt diesem Projekt!
Da komm ich mir mit meiner FlashCard echt klein und unbedeutend vor.
Ich würde auch gerne so gut FPGAs programmieren können.
Bei mir würde allerdings ein Lynx III draus werden. ;)
Leider fehlt mir die Anwendung für solch einen neuen Atari.
Aber ich finde das wirklich Super!
Ich weis wie viel Zeit man Ruck-Zuck mit Hardware verbraten kann. Da kommt dann ein Problem, das man nach Datenbuch gelöst zu haben scheint und dann merkt man das die Datenbücher etwas verschweigen, ungenau sind oder sehr schlecht verständlich und dann geht nichts. Bei mir sind da teilweise schon Wochen drauf gegangen. Habe leider keinen Oszi etc.
Von daher zieh ich meinen Hut! Bei solchen Projekten ist das wichtigste sich bis zum Schluß durchzubeißen.
Gruß Bernd
-
ähm, und was heist jetzt SUSKA, da bin ich immer rnoch nicht drauf gekommen
Interpretiert es mal so: Suska steht für eine angenehme Erscheinung im Leben. Geht auf die Sommerszeit in 2002 am Hochrhein zurück. Also kein Akronym oder irgendeine Abkürzung für einen technischen Begriff.
Schöne Grüße
Wolfgang
-
Der Coldfire Atari ist interessanter und sogar die günstigere variante....
Mathias, danke für dieses Posting.
Liebe Grüße
Wolfgang
Ich möchte dazu jetzt auch einiges anmerken.
Wir haben von Beginn an beim ACP versucht solche Konkurrenz nicht entstehen zu lassen. Dem Suska liegt, wie bereits öfter ausgeführt, ein anderes Konzept zu Grunde. Wir waren verdammt froh, als Wolfgang sich bereiterklärte beim ACP mitzumachen, und sowohl sein herausragendes Wissen in Bezug auf Hardware, als auch seinen Core zur Verfügung zu stellen.
Die Atari-Szenerie ist nicht mehr groß genug um gegeneinander zu arbeiten. Ganz im Gegenteil, der Schlüssel liegt in Zusammenarbeit sowie Erkennung und Ausnutzung von Synergieeffekten. Insofern muß euch auch klar sein, daß das ACP niemals so weit wäre, wenn Wolfgang nicht seit über fünf Jahren Unmengen an Zeit und Energie in das Suska gesteckt hätte! Das ACP-Board beruht zu guten Teilen direkt auf Wolfgangs Core sowie seinem Können!
Zum ersten mal seit einer Dekade ist nun ein neuer Atari-kompatibler Rechner – das Suska – verfügbar. Eigentlich ein Grund zu höchster Freude. Besonders toll ist, daß wir somit ein Board haben, daß sehr langfristig erhältlich sein wird, und eine noch nie dagewesene Kompatibilität aufweist.
Für spezielle Anforderungen ist das Suska sicherlich geeigneter als das ACP-Board. Ich würd euch bitten die Unterschiede wahrzunehmen, und sinnvoll für euch zu entscheiden was ihr benötigt. Die Projekte gegeneinander auszuspielen ist sicherlich das Letzte was irgendwie sinnvoll ist. Zumal Wolfgang auch beim garantiert nichtkommerziellen ACP eine wichtige Rolle spielt.
In Zukunft werden wir zwei lieferbare (!) Atari-Rechner für unterschiedliche Anforderungen haben. Es geht also bergauf mit unserer Plattform. Von euch würde ich mir wünschen, daß hier keine Konkurrenz kostruiert wird, da sie von Entwicklerseite definitiv nicht besteht.
-
Wow, ich bin schwer beeindruckt, das nun ein neues Atari-Board verfübgar ist. Vielen Dank!!!
Wir werden daran arbeiten, dass es in Zukunft wieder Plattformen für TOS, Mint, Magic etc. Gibt. Suska-III-T lässt demnächst grüßen
Bis dann
Wolfgang
Die Aufwände und Kosten rund um die Entwicklung rechtfertigen die Kosten für das Board mit Sicherheit und ich gehe davon aus, das auch bei diesem Preis eine erhebliche Zahl von Boards verkauft werden muß, damit zunächst die Entwicklungskosten wieder drin sind und tatsächlich Gewinn (und nicht nur ein Deckungsbeitrag) erzielt wird.
Um nun ein Suska als Spontankauf zu erstehen ist es allerdings klar zu teuer für mich. Gut is jedoch, das das Board langfirstig verfügbar sein soll und sein Fortbestehen nicht vom kurzfristigen Erfolg abhängt. Ich denke nachdem der Preis raus ist müssen - so wie ich - erstmal einige durchatmen und das Sparen intensivieren.
Für mich heißt das ganz klar noch ein paar Sachen mehr verkaufen und dann einen schönen neuen Atari kaufen :-) In letzter Zeit habe ich immer weniger Spaß an dem ewigen Hardwaregebastel. Ich möchte lieber mal wieder den Atari einfach einschalten und Spaß damit haben. Meine hochgerüsteten Kisten sind da leider viel zu zickig. Deshalb ist auch mein CT63 Falcon schon sehr nah an der Abschußliste zugunsten eines der neuen Boards.
Also nochmal DANKE für die unermütliche, konsquente und zu Ende gebrachte Entwicklungs und Herstellungsarbeit. Jetzt liegt es an uns Usern prakisches Leben in so ein System zu bringen.
Gruß Heinz
-
Hallo Wolfgang,
könntest Du ein wenig zu den Extra-Interfaces sagen?
Welches benötige ich wofür? Kann ich auf das MC-UART verzichten, wenn ich eine RS232 habe?
Danke und Gruß
Wolfgang
-
Deshalb ist auch mein CT63 Falcon schon sehr nah an der Abschußliste zugunsten eines der neuen Boards.
Wenn es soweit ist, ich hätte durchaus interesse an der CT63. ;D
-
...und ich sowie vermutlich viele andere Interesse am Falcon selbst. ;D
-
Hallo Wolfgang,
könntest Du ein wenig zu den Extra-Interfaces sagen?
Welches benötige ich wofür? Kann ich auf das MC-UART verzichten, wenn ich eine RS232 habe?
Danke und Gruß
Wolfgang
Hallo Wolfgang,
Die MC-UART wird benötigt, um Betriebssystem-Images in's Flash zu schreiben. Allerdings arbeiten wir an einer Lösung, um von der SD-Karte solche Images in's Flash zu schreiben. Ebenso wird es möglich sein, von der SD-Karte Configware Updates für's FPGA einzuspielen. Ich persönlich habe alle Betriebsystemvarianten im Flash und kann via DIP-Schalter auswählen. Somit benötige ich zum Beispiel keine MC-UART. Wir haben es so vorgesehen, dass die Systeme offiziell mit emuTos ausgeliefert werden. TOS ist eben nicht frei. Aber es ließe sich bestimmt eine Lösung finden, um im Auslieferungszustand etwas anderes als emuTos im Flash zu haben :)
Genau beschrieben ist das Ganze im Handbuch, welches im Downloadbereich von experiment-s (bisher nur) auf Deutsch zur Verfügung steht.
Ich bin natürlich auch bereit, den Suska IP-Core in Richtungen zu erweitern, die gewünscht werden (ok ich weiss ja dass es später ein Falcon sein soll und arbeite daran). Kleinere Erweiterungen lassen sich kurzfristig umsetzen. Was mir beispielsweise spontan einfällt ist das Umschalten der Videomodi via Accessory, wenn dieses von irgend jemandem programmiert wird. Oder das Laden des Festplattentreibers aus dem EEPROM, welches auf dem Board bestückt ist, so dass die CF-Karte Windows-kompatibel ist und dennoch beim Booten gesehen wird. Das ist dann eine superelegante Lösung, da man dann einfach mit einem Cardreader unter Windows die Platte beschreiben kann. Der Core an sich kann ja jetzt schon viel mehr als die originalen Maschinen und ist dennoch kompatibel geblieben. Aber ich denke es ist der Phantasie keine Grenze gesetzt, was da noch alles an Funktionalität hinzukommen kann. Und so sind auch die zusätzlichen Schnittstellen zu sehen, die vorhanden sind und beliebig Verwendung finden können, wenn der IP-Core entsprechend erweitert wird.
Viele Grüße
Wolfgang
-
Ich weiß nicht wie schwierig es wäre, aber könntest du eine "Bidge" einzubauen, die es ermöglicht, sonst nicht erreichbare Systemkomponenten wie den I2C erreichbar zu machen? Es wäre doch möglich ein Adressregister und ein Datenregister an zwei nicht verwendeten Adressen ein zu blenden. Darüber könnte man dann die neue Hardware adressieren und abfragen/schreiben. Das würde auch das originale System nur minimal verändern, oder gibt es schon Möglichkeiten? Ich weiß leider nicht wie "vollgestopft" der Adressraum seit dem STE-VME und Erweiterungen ist, und was es da schon alles "klassisch" gibt.
-
aber könntest du eine "Bidge" einzubauen
Meinst du Bridge oder Bitch ???
-
Hallo,
eine Bitch kann ich leider nicht einbauen :) Aber eine I2C-Bridge ohne Probleme; das ist ein VHDL-Zweizeiler oder man baut eine etwas intelligentere State-Machine (I2C-Master). Das mache ich, wenn genügend Interesse besteht.
Viele Grüße
Wolfgang
-
Suska-III-T lässt demnächst grüßen
Kannst du dazu auch schon näheres sagen? Neben den offensichtlichen Fragen (wann, wie teuer?) würde mich interessieren, ob es die Tiny-Variante ebenfalls "nur" als Karte zu kaufen geben wird, oder ob es sie auch direkt betriebsbereit in einem Laptop-Gehäuse geben wird (u.a. dafür war es doch gedacht, oder?)
-
Suska-III-T lässt demnächst grüßen
Kannst du dazu auch schon näheres sagen? Neben den offensichtlichen Fragen (wann, wie teuer?) würde mich interessieren, ob es die Tiny-Variante ebenfalls "nur" als Karte zu kaufen geben wird, oder ob es sie auch direkt betriebsbereit in einem Laptop-Gehäuse geben wird (u.a. dafür war es doch gedacht, oder?)
Hallo TiggyT, unter Inventronik Shop (http://shop.inventronik.de/store) findest du unter anderem auch den aktuellen Preis vom SUSKA III-C nicht Tiny. Ich glaube nicht das Wolfgang sich das Lager mit Gehäusen voll packt zumal bei den kleinen Stückzahlen der Einkaufspreis hoch ist. DIe Tiny-Variante jetzt schon anzubieten macht auch keinen Sinn oder nur wenn du in der Lage bist USB-Treiber selbst zu schreiben.
Gruß Arthur
-
@wfoerster
Danke, ich hoffe es werden sich noch ein paar melden :-)
(und ja ich meinte "Bridge")
Hast du schon mal die Leistungsaufnahme der Systeme gemessen? Es währe ganz interessant zu wissen, ob und wie gut man die Dinger über Akku betreiben kann.
-
Hallo zusammen,
zu den letzten Postings möchte ich folgendes anmerken:
wir werden sowohl für C als auch für T ein Gehäuse oder demnächst auch Suska-III-C Fertiggeräte anbieten. Das Gehäuse wird qualitativ hochwertig sein. Suska-III-T wird von uns angeboten, wenn es so gut und stabil läuft wie Suska-III-C. Die Leistungsaufnahme von Suska-III-C im monochrome Video-Mode und mit angeschlossenem TFT, (Diskettenlaufwerk läuft nicht) beträgt 3,4W (sehr sparsam).
Suska-III-T wird einen anderen Ansatz als Suska-III-C verfolgen:
Suska-III-C ist derzeit die einzige ST/STE/MegaST/MegaSTE evtl. auch Falcon relevante neue Hardware, die am Markt verfügbar ist und wird es in Bezug auf die Kompatibilität zu den originalen Maschinen vermutlich auch bleiben.
Suska-III-T wird ein kompaktes Modul sein, welches aber aufgrund der eingeschränkten Schnittstellenvielfalt den Betrieb etlicher Peripheriegeräte nicht zulässt; dafür aber neue Merkmale aufweisen wird.
Viele Grüße
Wolfgang
-
Hallo zusammen.
Wann bekommt man eigentlich die Zahlungsinfos zugesandt wenn man ein Suska III-C bestellt hat?
Oder wartet ihr damit, bis es genügend Bestellungen gibt und ihr die Bords produziert habt?
-
Hallo,
wir haben bereits die zweite Charge Suska-III-C in Produktion. Daher sind die Boards momentan nicht ab Lager verfügbar. Wir senden die Zahlungsinfos, wenn die Ware versandbereit gemacht wird.
Viele Grüße
Wolfgang
-
Ach eine Charge ist schon weg?! Coole Sache.
Wie groß ist denn ein Los?
-
Hallo,
nach längerer Pause möchte ich mich an dieser Stelle wieder zurückmelden. Über den Sommer gab's Pflege des Cores und eine ACSI-Festplatte im EEPROM, so dass nun mit den CF-Karten ein problemloser Datenaustausch zwischen Suska-III-C und PCs stattfinden kann. Ferner haben wir wieder Boards verfügbar gemacht; s. Suska-Shop. Ein Sonderheft bezüglich Suska wird es auch geben, in welchem ein ausführlicher Testbericht zu finden ist. Ich gebe Euch die Info, wo man dieses Heft beziehen kann in Kürze. Nun habe ich aber ein kleines Anliegen: kann mir jemand eine Information geben, welche Register genau in den ST-Maschinen nur im Supervisormodus schreibbar sind und welche nicht? Ich habe da keine vollständige Info im Moment. Es geht mir speziell um die ACIA der Midi-Schnittstelle.
Schöne Grüße
Wolfgang
-
Hi Wolfgang
Jeder Zugriff im I/O-Bereich muss im SupervisorMode erfolgen!
Was ist das Problem?
Gruss Peter
P.S. Wann kommt der Suska-Tiny? und zu welchem Preis?
-
Hi Peter,
das Problem ist, dass Programme, die auf Midi zugreifen wollen mit zwei Bomben also Busfehler hängen bleiben. Allerdings laufen eine Unmenge anderer Programme ohne Probleme. Nur eben Midi nicht. Dabei hängt ja eigentlich nur die Midi ACIA als spezielle Hardware am Datenbus. Und der Core für die ACIA ist getestet, sonst würde ja Maus und Tastatur nicht funktionieren ??? Woodoo.
Viele Grüße
Wolfgang
-
Ja da kann ich nur raten, da der Tastatur-ACIA ja funzt
Vielleicht sind es ja Zugriffe auf den ROMport die Probs bereiten (gab mal so ne berühmte Midibox am RomPo!)
Da der 6850 nur 2 Register hat ($FFFC00 = Control, $FFFC02 = Data) sollte ein PEEK &HFFFC02 oder ein INPAUX$ Klarheit schaffen.
P.S Hast meine Frage nicht beantwortet
-
Hallo,
so geht's mir momentan auch. Ich kann nur raten. Ich vermute irgendein Kleinkram, der nicht dokumentiert ist. Bezüglich Deiner Frage: Die T's wird's geben, wenn 1. die C's etabliert sind und wenn ein DDR Speichercontroller existiert, der notwendig ist, um das System an's Laufen zu bekommen. Geradeaus: nicht vor 2010. Fünf Exemplare sind allerdings jetzt schon an den entsprechenden Stellen.
Viele Grüße
Wolfgang
-
Leer
-
Hallo Gerhard,
zwischenzeitlich denke ich, dass es nicht an der ACIA liegt. Es geht um den MIDI_COM Treiber in Verbindung mit dem MIDI_COM Accessory. Der Treiber installiert sich offensichtlich aber beim Laden des Accessories tritt dann der Busfehler auf. Eine neuere Demo von MIDI_COM lädt ebenfalls den Treiber, das Accessory startet und dann bleibt der Rechner ohne Bomben hängen. Vielleicht hat jemand Erfahrung mit MIDI_COM...
Viele Grüße
Wolfgang
-
Leer
-
Hast Du mal Midi Musiksoftware so wie Cubase und Konsorten getestet?
-
Hallo,
ja habe ich. Cubase startet und ich kann die Menüs bedienen. Ich habe aber kein MIDI-fähiges Gerät zum testen. Ich habe auch die Inkompatibilitäten beseitigt, so dass jetzt MIDI wohl funktioniert.
Grüße
Wolfgang
-
Hallo,
ich möchte an dieser Stelle noch den versprochenen Link angeben, wo das Ready-Magazin zu finden ist und wo es auch möglich ist, das Sonderheft, welches demnächst über Suska-III-C erscheint vorzubestellen. Dort wird dann ein aktueller Testbericht und, wenn es noch in die Redaktion reicht, ein Bericht über die Möglichkeiten, die Suska-III-C bereits hat und die sich über die ST Funktionen hinaus realisieren lassen abgedruckt sein.
Links:
http://www.webmart.de/wmshop.cfm?ID=41677&CID=85578&SubDo=open
http://www.ready-magazin.de/
http://www.art-transfair.de/
Viele Grüße
Wolfgang
-
Leer
-
Hi,
Midi wird demnächst von einigen Spielern mit MidiMaze getestet. Nun suche ich jemanden, der mir mit einer lauffähigen Version von Asteroids aushelfen kann...
Übrigens haben wir hier einige Testboards, die wir verleihen würden, wenn sich jemand die Arbeit macht zu testen und hinterher auch die Ergebnisse in angemessener Form öffentlich macht.
Schöne Grüße
Wolfgang
-
Hallo,
gibt es denn einen Testplan / "use cases" / Testfälle, die abgearbeitet werden sollen? Oder geht es um freies testen typischer Nutzungszenarien?
Welche Ausstattung braucht man zum testen? Ich habe nur die typische Computerausstattung aber keine Löt- oder Messtechnik. Kann also nur als dummer User testen.
Gibt es einen Zeitplan was bis wann getestet werden soll? Oder geht das auch mit ein paar Stunden am Abend?
Gruß Heinz
-
Hallo,
nein, ich habe keinen Testplan erarbeitet. Ich weiss ja gar nicht wieviel Tonnen Software für diese Maschinen so rumfliegen. Ich denke, dass man auch keine besonderen Vorkenntnisse braucht - außer - wie die Ataris damals zu bedienen waren. Und einen Lötkolben braucht hoffentlich (um Himmels Willen) auch niemand:)
Ich könnte es mir so vorstellen, dass bestimmte 'Software-Genres' getestet werden; beispielsweise Editoren, Packer, Festplattentools, Textverarbeitungen, Datenbanken, Grafikprogramme, Systemtools, Spiele usw. Falls Software nicht läuft, muss das nicht mit dem Lötkolben erledigt werden sondern mit einem Update der FPGA-Konfiguration.
Einen Zeitplan gibt's nicht. Die begrenzte Anzahl an Geräten könnte ich so für zwei Wochen zur Verfügung stellen. Ich würde dann auch vorschlagen, dass man die Ergebnisse in ein Excel-Sheet einträgt, damit klar ist welche Software in welcher Version wie getestet wurde und ob und wie sie läuft. Da würde ich dann was vorbereiten, damit alle das gleiche Dokument haben.
Viele Grüße
Wolfgang
-
Hallo Wolfgang,
das klingt gut und vielversprechend (hu, nicht löten und messen, nur benutzen ... ).
Bei der Testmatrix würde ich aber eine generischere Lösung bevorzugen. Excel muss es nicht gerade sein (siehe mein Forum-Profil). Ich würde eine Sektion/Tabelle im Wiki (z.B. von newtosworld.de) vorschlagen, die ähnlich wie in diesem Thread (http://forum.atari-home.de/index.php?topic=5636.0) besprochen die Kompatibilität mit dem Rechner/OS und ggf. nötige Konfigurationen dokumentiert. Bei der Einteilung der Programme würde ich mich an der Sortierung in der Atari Up to date Liste orientieren.
Das Wiki hätte den Vorteil, das der Fortschritt direkt allen zugänglich ist.
Bei einer der zwei Wochen Testphasen würde ich gerne mitmachen.
Gruß Heinz
-
Hallo Wolfgang
Ich würde mich in der Kategorie GfA-Basic, Profimat, NVDI, Gfa-Draft bewerben.
Gruss Peter
-
Hallo Wolfgang,
als "Atari-Musiker" könnte ich mich um Audio- und MIDI Software kümmern. In meiner diesbezüglichen Sammlung dürfte so gut wie alles vorhanden sein, was es jemals an Audio- und MIDI-Software für den Atari gab - Kommerzielles, wie auch Free- oder Shareware.
Grüße,
dbsys
-
Ich hab jede menge Spiele, und auch nen haufen PD-Ware
Würde da alles durchtesten, was in dem knappen Zeitrahmen möglich ist - vor allem Klassiker und ein paar exoten/Demos.
Gruß Matthias
-
Hallo,
danke für die große Resonanz. Damit das alles gut zusammenläuft würde ich über's Wochenende eine Excel-Liste verfassen, die verschiedene Reiter für die verschiedenen Tests hat. Die würde ich auf den experiment-s-Server in den Downloadbereich legen und mich dann wieder hier melden. Bis dahin ein schönes Wochenende.
Grüße
Wolfgang
-
Hallo,
da ich immer nur ein paar Wochen im Jahr in Deutschland bin, kann ich mit Tests leider nicht dienen. Aber in der Up-to.Date-Liste (www.atariuptodate.de) werde ich die Ergebnisse gerne berücksichtigen, wenn's ok ist.
Grüße,
Matthias
-
Hallo,
sorry für das Delay. Wir basteln gerade an einer Online-Datenbank. Dauert noch ein wenig. Nun habe ich ein kleines Problem: ich habe den COMBEL nahezu fertiggestellt. Nun sind da ein paar Pins, die mir selbst mit viel Phantasie nichts sagen. Da wäre zum einen Signal KHz500 und eines KHz500W (oder V, das Schaltbils ist sehr schlecht). Die beiden Signale sind zum Beispiel mit der Tastatur ACIA verbunden. Das KHz500 taktet den Empfängerteil, das Signal KHz500W den Senderteil. Weiss jemand den Unterschied? Kann jemanmd an einer Originalmaschine nachmessen, ob da bei DMA Betrieb oder so etwas passiert?
Dann hat die Falcon Tastatur neben den RxD und TxD eine Reihe weiterer Leitungen. Speziell zwei Signale (völlig unleserlich im Schaltbild) sind an den COMBEL angeschlossen. Weiss hier jemand irgendwas? Gehen normale ST-Tastaturen auch an den Falcons? Und last but not least (vorläufig:-) gibt es das Register FF8007. Dort kann offensichtlich eine STE Bus Emulation eingestellt werden (Bit5). Ist das sinnvoll? Benutzt jemand dieses Merkmal? Wenn ja, was ist der Unterschied zum Falcon Betrieb?
Viele Fragen und einen herzlichen Dank für jede Info.
Viele Grüße
Wolfgang
-
Hallo Wolfgang, zur Tastatur....vielleicht hilft dir das.
Die Belegung des Tastatursteckers am 1040ST und Falcon
1 Ground
2 Not Connected
3 Floppy Led
4 +5V DC
5 Receive Data
6 Transmit Data
7 Reset
8 Ground
9 Not Connected
10 Not Connected
Quelle: CnC von Michael Ruge
Pin 3 und 4 der beiden ACIAS werden zum Beispiel beim Einbau einer Speed Resolution Card gebrückt und mit einem gemeinsamen 500KHz Takt versorgt. Beide ACIAS hängen dann am selben Takt. Das läuft problemlos.
Gruß Arthur
-
Gehen normale ST-Tastaturen auch an den Falcons?
Ja, wie oben schon zu sehen.
Und last but not least (vorläufig:-) gibt es das Register FF8007. Dort kann offensichtlich eine STE Bus Emulation eingestellt werden (Bit5). Ist das sinnvoll? Benutzt jemand dieses Merkmal? Wenn ja, was ist der Unterschied zum Falcon Betrieb?
Hierzu kann ich nur sagen das der Falcon und auch der Atari TT mit ein paar Tricks sehr kompatibel zu den normalen ST's gemacht werden können und dann auch viele Spiele auf Falcon und TT wieder laufen.
Dazu wird ind der Regel der Cache der CPU deaktiviert und über die MMU der Speicher konfiguriert oder beschnitten. Des weiterein Läßt sich im Falcon der Prozessor durch diverse Software auch mit 8MHz betreiben.
FALCONF Falconfig version 1.06 by Christoph Wissing is a CPPX module that
allows you to control various options available in the Falcon030
including: Toggle CPU between 8 Mhz and 16 Mhz, Toggle Blitter
between 8 Mhz and 16 Mhz, Turn the CPU cache on and off, Set
internal IDE hard drive, Toggle between 78 Hz / 60 Hz (this feature
is only available when "Super 78" is installed). All docs are in
German.
FBOOT Falcon Boot version 1.2 by Mike Watson. This program installs a boot
sector on the disk in drive A. Simply reboot with that disk in the
drive and you will be presented with the following options: Disable
the 68030's INSTRUCTION cache, Disable the 68030's DATA cache,
Disable the 68030's MMU, Turn down volume of Falcons internal
speaker, Quit and run a bootsector, Quit and bypass hard drive, Quit
and continue as normal.
Am bekanntesten ist wohl Backward für den Falcon. Näheres dazu findes du hier:
Backward (http://cd.textfiles.com/crawlycrypt2/falcon/utility/backwd28/)
und
Backward Readme (http://cd.textfiles.com/crawlycrypt2/falcon/utility/backwd28/read_me.txt)
Gruß Arthur
-
Hallo Wolfgang, das Register scheint für solche Software geschaffen oder umgekehrt. Es könnte also sinnvoll zu sein die STE Bus Emulation mit zu emulieren.
(http://forum.atari-home.de/index.php?action=dlattach;topic=2536.0;attach=1306)
Gruß Arthur
-
ich weiss nicht, ob es stimmt: der falcon hat doch einen 32bit bus nach aussen. hat der ste nicht nur 24bit?
edit: oder hat es was mit dem adressierbaren speicher zu tun?
...man ist das spät :o
-
Soweit ich weiß erlaubt der ST(e) das Schreiben/Lesen in/von Adress-Bereiche/n, die es gar nicht gibt, ohne dass es zu einem Bus-Error (oder war es ein Address-Error?) kommt. Beim Falcon ist das nicht mehr der Fall. Wenn man das dort versucht gibt es Bomben. Mit diesem Flag kann man das Verhalten von ST(e)s wieder herstellen, soweit ich weiß.
Ich hab allerdings keine Ahnung, wozu das in Spielen oder Demos ausgenutzt wurde. Vielleicht um die RAM-Größe festzustellen?!
Bei solchen Detail-Fragen lohnt es sich übrigens auch im Coding-Forum von dhs.nu nachzufragen. Dort sind die absoluten Experten für solche Fragen.
Matthias
-
...der falcon hat doch einen 32bit bus nach aussen. hat der ste nicht nur 24bit?
16 bit Datenbus / 24 bit Adressbus (deshalb ist die Kiste ja auch so vermurkst) ;)
-
Der Falcon hat ein 32Bit CPU mit 32 Daten- und Adress-Leitungen, aber...D0-D15 sowie A24-A31 sind auf dem Falcon Mainboard nicht angeschlossen. Es ist also wie Idek es geschrieben hat.
16 bit Datenbus / 24 bit Adressbus (deshalb ist die Kiste ja auch so vermurkst) ;)
Gruß Arthur
-
Die Belegung des Tastatursteckers am 1040ST und Falcon
1 Ground
2 Not Connected
3 Floppy Led
4 +5V DC
5 Receive Data
6 Transmit Data
7 Reset
8 Ground
9 Not Connected
10 Not Connected
Hallo,
danke für die vielen Tips und Infos. Das mit der Tastatur beschäftigt mich. Genau um die Pins 9 und 10 geht es mir da. Gemäß Falcon Schaltbild sind da zwei Leitungen des COMBEL angeschlossen. Was machen diese?
Grüße
Wolfgang
-
Hallo Wolfgang, am Tastaturstecker sind die Signale Pin 9 und 10 nicht enthalten. Der Stecker geht nur bis Pin 8.
Lies mal hier http://www.atari-forum.com/viewtopic.php?f=27&t=10414 evtl. hilft Dir das.
Gruß Arthur
-
Hallo Arthur,
der Link hat mir weitergeholfen. Nun brauche ich noch die Info bezüglich den Signalen KHz500 und KHz500W. Das erstere ist eigentlichh klar. aber wieso wird die Keyboard ACIA im Transmitter mit KHz500W belegt? Dann fehlt mir nich eine Information, wozu das Signal BMODE verwendet wird. Ich vermute stark, dass dieses Signal auf '0' geht, wenn irgend ein DMA Transfer stattfindet... Damit hätte ich dann den COMBEL fertig.
Ach ja und noch was bezüglich der Anmerkung von Matthias Alles: Es wäre mir neu, dass der STE das schreiben auf nicht erlaubte Adressbereiche zulässt ohne einen Buserror zu erzeugen. Hat diesbezüglich jemand konkretere Angaben (welche Adressen...)?
Viele Grüße
Wolfgang
-
Leer
-
Hallo Wolfgang, im Atari Falcon Hardware Referenz Guide vom 10/1/92 (http://dev-docs.atariforge.org/files/Falcon030_Dev_Doc_10-1-1992.pdf) (Ab Seite 22 im PDF) wird genau erklärt wozu das BMode-Signal verwendet wird.
Weshalb gerade der Keyboard ACIA einmal das (Transmitter)KHz500W- und einmal KHz500-Signal bekommt darüber konnte ich nichts finden. Im ATARI TT,MEGA ST,STE und ST bekommen beide ACIA's ja das selbe Signal an PIN 3 und 4 zugeführt.
-
Hallo Wolfgang, da das 500KHz Signal vom Combel mit mehr als 4 TTL Anschlüssen schon stark belastet ist und im Falcon auch noch am Internen Expansionsbus auf Pin 23 des 30 poligen Anschlusses liegt, könnte ich mir vorstellen das Atari vorrausschauend für mehr Stabilität gesorgt hat, für den Fall das eine interne Erweiterung eingebaut wird.
Siehe auch Seite 21 im Hardware Referenz Guide "Clock Signals".
Gruß Arthur
-
Hallo Wolfgang,
eine Diskussion zu dem Thema findest du hier:
http://www.atari-forum.com/viewtopic.php?f=16&t=4607
dort steht z.B.
- allow access to inexistent memory area, for example when a sprite go behond the screen low border or sometime to read random numbers.
- ignore access to shadow registers, for example ym optimisations
- ...
Ich hab jetzt leider auch keine genauere Dokumentation dazu. Deswegen nochmal mein Hinweis auf www.dhs.nu -> Atari Coding. Da weiß 100%ig jemand ganz genau was das Flag macht.
Vielleicht ist das Thema für den STE-Suska-Core noch von Interesse?
-
Hallo zusammen,
zunächst vielen Dank für all' die Infos. Ich habe jetzt hiermir den COMBEL fertiggestellt. Dieser wird zunächst als Netzliste für den Suska-III-C voraussichtlich in der kommenden Version bereitgestellt. Die Arbeiten am Videl haben begonnen. Ich werde hier noch ein paar Video-Modi mehr spendieren als der Falcon das bisher kann. Danach modelliere ich den Falcon DMA Baustein. Das Ganze werde ich, wenn nichts unvorhergesehenes eintritt auf dem Suska-III-C lauffähig machen. Da ich den 68030 ebenfalls habe (muss noch fehlerbereinigt werden), sollte dann auf Suska-III-C TOS 4.x und Mint laufen.
Ein schönes Wochenende
Wolfgang
-
Sehe ich das richtig, aus dem Suska wird ein Falcon kompatibler Rechner werden?
-
Hallo,
Suska ist eine rekonfigurierbare digitale Hardware. Das ist viel mehr als 'nur' ein Computer. So, wie durch unterschiedliche Betriebssysteme ganz andere Eigenschaften erzeugt werden können, so kann durch die Modellierung des IP-Cores die unterschiedlichste Hardware realisiert werden. Wenn Du so fragst: ja, ich werde mein Möglichstes tun, um die Falcon-Compatibilität und mehr zu erreichen - und - es sieht gar nicht schlecht aus :-)
-
Hallo,
Suska ist eine rekonfigurierbare digitale Hardware. Das ist viel mehr als 'nur' ein Computer. So, wie durch unterschiedliche Betriebssysteme ganz andere Eigenschaften erzeugt werden können, so kann durch die Modellierung des IP-Cores die unterschiedlichste Hardware realisiert werden. Wenn Du so fragst: ja, ich werde mein Möglichstes tun, um die Falcon-Compatibilität und mehr zu erreichen - und - es sieht gar nicht schlecht aus :-)
Na einen "echten" Falcon - das wär ja der Hammer :)
-
Hammer!
Moment a): ein cooles STE Game wird auf dem suska gezockt.
News per eMail: Neue Falcon-Demo erschienen! Also schnell Falcon Core in den Suska geladen
Moment b): Falcon Demo angucken
So oder so ähnlich? Geil.
-
Hallo,
brauche Hilfe: kann mir jemand einen Tip geben, wo ich eine Signalbeschreibung aller Signale der 19 poligen Falcon Monitorbuchse herbekomme? Und dann gibt's am Videl noch die Pins 10 (Name unleserlich) und 119 (EXT, nicht belegt). Weiß hierzu jemand etwas?
Vielen Dank
Wolfgang
-
Hier die Belegung der Falcon Monitorbuchse lt Chips&Chips:
Die Pinbelegung der Falcon030 Monitorbuchse
1 Farbe Rot 11 Ground
2 Farbe Grün 12 Composite Sync
3 Farbe Blau 13 Horizontal Sync
4 Monochrom Video 14 Vertikal Sync
5 Ground 15 Extern Clock
6 Farbe Rot Ground 16 Even ODD
7 Farbe Grün Ground 17 +12V für Scart
8 Farbe Blau Ground 18 Videomode 1
9 Audio Out 19 Videomode 2
10 Ground
Toni
-
Hab ich vergessen:
Der PIN 10 des VIDEL is lt Chips&Chips mit: DOTCK beschriftet.
Toni
-
Hi,
mir sind die Funktionen der folgenden Signale nicht klar:
Pin 16 EVEN_ODD
Pin 18 Videomode 1
Pin 19 Videomode2
den Pin 10 des Videl 'DOTCK' habe ich jetzt: ist der Takt für den Video DAC.
-
Leer
-
Hallo Wolfgang, über Pin18 und Pin19 der Atari Falcon Monitorbuchse wird der Monitor erkannt und dementsprechend das Signal bereitgestellt.
Siehe hier:
M1 (pin 18) M0 (pin 19) Monitor
0 0 ST Mono
0 1 ST Farb
1 0 VGA
1 1 TV
Das Standardsignal ist TV und je nach Monitor wird Pin18 und/oder 19 auf Null gezogen oder eben nicht. In den CnC steht auch Monitor select ich hätte eher Monitor detect dazu gesagt. ;)
Gruß Arthur
-
Hallo,
habe mal kurz eine Frage, die hier nicht genau hingehört - aber egal: Ich möchte unter meinem Linux-System das chips.hyp ansehen. Also den Chips 'n Chips Hypertext. Weiss jemand, ob das geht?
Vielen Dank
Wolfgang
-
Hallo Wolfgang, habe lange nichts mehr mit Linux gemacht aber WinGuide sollte unter Linux bei aktiver Wine-Emulation problemlos funktionieren. Wenn Microsoft Office 2003 unter Wine problemlos läuft dann sollte WinGuide erst recht damit laufen. Wine stellt die MS-Windows-Funktionsaufrufe unter Linux bereit.
Gruß Arthur
-
Eine andere Möglichkeit funktioniert über folgende Webseite:
Atari Hypertexte im Browser betrachten. (http://phoenix.inf.upol.cz/~opichals/libhyp/) Das ist unabhängik vom verwendetem OS.
(http://forum.atari-home.de/index.php?action=dlattach;topic=2536.0;attach=1345)
Gruß Arthur
-
Hallo Arthur,
Du bist ein prima Infobeschaffer. Ich habe WinGuide am Laufen. Geht unter meiner Ubuntu problemlos.
Viele Grüße und herzlichen Dank
Wolfgang
-
Hallo Wolfgang, das hör ich doch gern. ;) Die Community hier ist doch auch was feines.
Gruß Arthur
-
Einen wunderschönen guten Abend zusammen,
ich möchte mal wieder ein Lebenszeichen von mir geben. Im Dezember werde ich die Version 2K9B des Suska-Cores zum Download frei geben. Diese entspricht dem STE - wie gehabt, ist aber an vielen Stellen aufgrund der Rückmeldungen der Besitzer von Suska-III-C-Boards verbessert / optimiert und somit optimal an diese angepasst. Ferner gibt es demnächst einen 'Fork' dieses Cores, welcher auf unseren etwa bierdeckelgroßen Suska-III-B lauffähig ist (B steht für Basic). Wir werden für diese Hardware Interessenten sammeln und bei Bedarf eine Charge auflegen (ca. 100 Stück). Da wir für das Suska-III-C Board seinerzeit entschieden haben, einen höheren Preis anzusetzen, um Folgeentwicklungen zu finanzieren, möchten wir uns an dieser Stelle noch nicht definitiv festlegen; allerdings wird das Board für unter 200€ zu haben sein.
Viele Grüße
Wolfgang
-
Das hört sich ja gut an.
Verstehe ich das richtig das ein Suska-B nur ein Teilbestückter Suska-c ist,
also ein fachkundiger Anwender wie ich Teil für Teil bei Bedarf nachbestücken und somit brachliegende Teile erwecken kann??
Gruß Matthias
-
Nachdem Wolfgang geschrieben hat "bierdeckelgroßen Suska-III-B", denke ich daß es sich um ein komplett neues Teil handelt. Jedenfalls scheint der Preis und die Idee eines dritten Boards sehr interessant. Mal sehen was da genau kommt.
Das Suska III-C das ich immer noch zuhause habe ist schon ein sehr geniales Teil! Kennt eigentlich wer die Auflagengröße vom Minimig?
-
Das hört sich aber dann an Suska-T an, das Tinyboard das er schon angekündigt hat - jetzt bin ich verwirrt.
-
Hi,
nein, Suska-T ist das zweite Board in dem Reigen. Siska-III-B ist ein drittes.
Aber weshalb ich mich heute hier einklinke: Ich habe den Core etwas modifiziert und die 14MB Speicher TOS-kompatibel freigeschaltet. Nun habe ich folgenden Effekt: Unter TOS 2.06 wird beim Booten der Speichertest ausgeführt. Dieser zeigt 8MB Speicher an, obwohl 14MB freigeschaltet sein sollten. Weiss jemand, ob TOS2.06 korrekte Werte für >8MB anzeigt oder habe ich da eventuell noch etwas falsch?
Viele Grüße
Wolfgang
P.S. Der Core 2K9B kommt am Donnerstag.
-
Hallo Wolfgang, das wäre mir neu.
Siehe hier:
(http://forum.atari-home.de/index.php?action=dlattach;topic=2536.0;attach=1406)
Gruß Arthur
-
Hast Du auch mal hier nachgeschaut?
(http://forum.atari-home.de/index.php?action=dlattach;topic=2536.0;attach=1408)
Arthur
-
Hallo Arthur,
danke, hab's gefunden und berichtigt. Morgen teste ich und dann sollten die 14MB gehen.
Viele Grüße
Wolfgang
-
Hi all,
i want to inform you, that the Suska IP Core in it's version 2K9B is out now. It features improved stability a bunch of improvements resulting from the feedback of the Suska-III-C boards and significant changes to prepare the core concerning Falcon functionality and upgrade capability. See the readme file for more information. You can download the stuff from www.experiment-s.de.
The goal for the next release in June 2010 (version 2K10A) will be a 68K30 and improvements concerning the core timing and 64MB memory access on the Suska-III-C boards.
enjoy
season's greatings
Wolfgang
-
Hallo an alle,
nach längerer Zeit möchte ich mich wieder einmal melden. Ich hatte die letzten zwei Monate einiges um die Ohren und habe daher am Suska IP Core nur Bugfixing betrieben. Mathias Wittau hat sehr viel Arbeit investiert und viele Dinge ausgetestet. Ich habe mit ihm vereinbart, dass ich diese Testergebnisse hier einstelle - Danke Mathias! Anmerken möchte ich noch, dass von den getesteten Programmen / Betriebssystem nicht alle Funktionen zu 100% durchgetestet wurden. Aber ich denke, dass diese Tests einen guten Überblick über den momentanen Stand der Suska-Boards vermitteln sollten.
Viele Grüße
Wolfgang
--- Im Folgenden die Testergebnisse ---
Testumgebung:
- Ich habe alle alle Programme in der ST-Hoch Auflösung auf einem TFT
getestet. Leider ist dies nur auf einem TFT, nicht am CRT möglich. Farbe
funktioniert wie gesagt am CRT auch bereits, jedoch mit einer sehr
niedrigen Bildwiederholrate, die das Arbeiten recht anstrengend macht auf
Dauer. Dafür ist das Bild gestochen scharf. Auf dem TFT ist 640 x 400 auch
nicht ganz sauber.
- Alle Tests habe ich mit 8MHz durchgeführt.
- Ebenfalls sind alle Tests mit 4MB Ram gemacht worden, sofern nicht
anders beschrieben.
- Bei keinem Programm habe ich irgendwelche Peripherie getestet - bisher.
Das bedeutet, keine MIDI-Ports, Keine Drucker, Kein Netzwerk, keinen Sound
usw. Ich habe die Applikationen lediglich auf ihre Startfähigkeit und auf
ihre Grundfunktionen (Dateine laden, erstellen, sichern, Basiswerkzeuge
usw.) getestet.
- Genutzt habe ich Dein Diskettenlaufwerk, Eine MegaST-Tastatur (Die von
den Bildern auf der Retrobörse), eine Atari STM1 Maus und einen
angeschlossenen Competition pro Joystick.
Programme:
Atari MegaSTE Language Disk Deutsch:
------------------------------------
Die original Language Disk funktioniert. Lediglich das CPX "SOUND.CPX"
bringt den Rechner zum Aufhängen. Eine "Dauerbiene" ist das Ergebnis, wenn
dieses CPX beim Booten ausgeführt wird. Alle anderen 7 CPXe funktionieren.
K-Spread 4
----------
Diese Tabellenkalkulation scheint perfekt zu funktionieren.
Pixart 3
--------
Dieses Graphikprogramm funktioniert auch fehlerfrei bei mir.
Oxyd
----
Skurriler Weise funktioniert Oxyd wie auch Oxyd 2 nicht, und bringt den
Rechner zum Absturz (3 Bomben). Oxyd Magnum jedoch das, letzte Spiel der
Serie, funktioniert problemlos.
Time Watch
----------
Ein ACC zum Zeit- und Mausklicksmessen funktioniert.
Arkus
-----
Das Fonttool funktioniert.
XBoot
-----
Der bekannte Bootmanager funktioniert.
Chagall
-------
Graphikprogramm funktioniert.
Cubase
------
Stürzt leider mit extrem vielen Bomben ab.
Themadat
--------
Die Datenbank stürzt auch ab, ...
TKC Haushalts Expert
--------------------
Funktioniert
Happy Music
-----------
Das Atari Midi Studio von Steinberg (!) ist ein Art Minimal-Cubase. Die
Oberfläche ist 1:1 jene von Cubase. Das Programm funktioniert, und die
Basiswerkzeuge gehen ebenfalls. Achtung: MIDI hab´ ich wie oben gesagt
nicht getestet.
QFax Pro
--------
Die Fax-Software scheint auch zu funktionieren. Gefaxt habe ich damit
nicht, aber die Oberfläche läßt sich problemlos bedienen.
Artworx
-------
Diese Graphikprogramm funktioniert ebenfalls
Texel
-----
Diese Tabellenkalkulation funktioniert prolemlos. sowohl in der Version
1.1 von 1996 als auch in der 2.2 von 1999
WDialog
-------
Funktioniert soweit ich das bisher getestet habe
MegaPaint
---------
Dises ältere (1993) jedoch umfangreiche Vektorgraphikprogramm scheint
problemlos zu laufen.
Papillon
--------
Dieses sehr bekannte Graphikprogramm funktioniert in der Version 2 sehr
gut. In der Version 3.03 stürzt es beim Starten mit 3 Bomben ab.
Chessmaster 2000
----------------
Der Schachcomputer läuft sehr gut.
Und der größte Punkt:
MagiC
-----
Das Multitaskingbetriebssystem läuft in der Version 6.0 problemlos!
Genial! Magic-Desk der Desctop der mit MagiC mitgeliefert wird, läuft auch
sehr gut. Multitasking ist problemlos möglich auch unter 4MB.
Ich werde noch die letzte verfügbare Version 6.2 testen, sobald ich einen
Ersatz für meine kaputten Disketten habe.
Jinnee
------
Der Desktop funktioniert leider momenatan nicht. Beim Starten von MagiC
hängt sich Magic irgendwann auf. Anscheinend sobald Jinnee geladen werden
soll. Ich habe mit der Version 1.1 begonnen (Update auf 2.5 teste ich dann
auch noch). Das Skurrile ist, daß ich beim Halten der "Alt-Taste" (umgehen
vom Startlaufwerk) bei installiertem Jinnee (und MagiC 6) nicht
weitergekommen bin. Die Festplatte (CF) wurde immer wieder zum Booten
herangezogen, ... Oftmals hat das Suska daraufhin beim Reboot mit einem
schwarzen Bildschirm reagiert, ... Ausstecken und 5 Minuten warten hat das
Problem jeweils behoben.
Einmal hatte ich die Fehlermeldung:
"Offscreentreiber nicht gefunden.
MCMD wird gestartet ...
System wird angehalten"
Wie gesagt beim Drücken der "Alt Taste" während dem Starten. Keine Ahnung
ob das ein Jinnee, MagiC oder Suska-"Problem" ist.
Ich werde nun mal weiterversuchen wieder ins TOS zu starten und Jinnee zu
deinstallieren. Weitere Infos folgen.
-
Wie an Wolfgang geschrieben, bin ich ganz begeistert daß MagiC funktioniert! Ganz wichtig noch; ich habe auch NVDI 5 in der Zwischenzeit erfolgreich im Einsatz.
Ich werde mir weiterhin einmal wöchentlich Zeit nehmen und weitere Programme testen. Verzeiht mir dabei aber bitte, falls manche Probleme Bedienfehler sind und gar nichts mit dem Suska zu tun haben. ;)
Das Board ist jedenfalls wunderbar! Danke Wolfgang nochmals für die jahrelange Arbeit!
-
Hi.
>"Offscreentreiber nicht gefunden.
Könnte mit fehlendem NVDI zusammenhängen. Die Fehlermedlung hatte ich auch früher mal, ist aber schon lange her :)
>ich habe auch NVDI 5 in der Zwischenzeit erfolgreich im >Einsatz.
Wie sieht es dann mit obiger Meldung aus? Läuft Papillon jetzt auch in der neueren Version?
Viele ASH-Prg haben NVDI vorausgesetzt.
Gruß
Wolfgang
-
Könnte mit fehlendem NVDI zusammenhängen.
Stimmt. Werde ich testen, ob die ASH-Sachen jetzt funktionieren!
-
Ich habe eine Anmerkung zum 'SOUND.CPX':
ich nehme an, dass dieses den Falcon steuert und nicht den STE. Der Unterschied in der Hardware zwischen STE und Falcon ist der folgende:
Der STE hat den LMC1992 Volume Controller, der über Microwire angeschlossen ist. Hierfür gibt's Register bei 0xFFFF8922 und 0xFFFF8924. Der Falcon hat einen Audio-Codec der andere Adresslagen besitzt. Momentan gibt es die Microwire-Schnittstelle im Suska IP-Core aber nicht die Codec-Steuerung. Das würde dann heißen, dass SOUND.CPX mit Busfehler (2 Bomben) abstürzt.
Viele Grüße
Wolfgang
-
Hallo Wolfgang, das ist ein interessantes Thema. In der Zeit wo ich mich mit Ataris beschäftigt habe, hab ich allerdings bei der Benutzung des SOUND.CPX auf Falcon, TT und STE noch keinen Busfehler bekommen. Das würde ja bedeuten das direkt die Hardware programmiert wird anstatt die entsprechenden Betriebsystemaufrufe oder XBIOS-Funktionen zu verwenden. Weis da jemand etwas genaueres drüber?
Gruß Arthur
-
Tja Arthur,
es wäre sehr hilfreich zu erfahren, wie diese Steuerung gemacht ist. Momentan denke ich nämlich darüber nach den Audio-Codec auf dem Suska-Board in Betrieb zu nehmen. Das wäre meiner Meinung nach am besten derart durchgeführt, dass diese Codec-Steuerung dann kompatibel wäre zu dem Hardwareteil des Falcon (ich nehme an, dass dieser im Falcon-DMA Baustein implementiert ist). Damit wäre dann eine Kompatibilität zu eventuell vorhandenen Treibern hergestellt. Nun wüsste ich auch gerne, ob das Sound.cpx so etwas wie einen Treiber darstellt oder ob irgendwelche BIOS- oder XBIOS Routinen des Falcon-TOS die Treiberschicht bilden (wie würde es aber dann im STE aussehen?). Na ja - mal abwarten, ob sich hier noch jemand mit Infos einbringt.
Viele Grüße
Wolfgang
-
Leer
-
Papillon 3.03 funktioniert auch mit NVDI 5 nicht.
Dafür habe ich folgendes gestern noch erfolgreich getestet:
• Calamus SL
• Twilight
• Private Architekt
• TippEx
Wobei die letzten beiden mit Multitasking (MagiC) nicht fehlerfrei funktioniert haben, und erst unter TOS problemlos gelaufen sind.
-
Tja Arthur,
es wäre sehr hilfreich zu erfahren, wie diese Steuerung gemacht ist. Momentan denke ich nämlich darüber nach den Audio-Codec auf dem Suska-Board in Betrieb zu nehmen. Das wäre meiner Meinung nach am besten derart durchgeführt, dass diese Codec-Steuerung dann kompatibel wäre zu dem Hardwareteil des Falcon (ich nehme an, dass dieser im Falcon-DMA Baustein implementiert ist). Damit wäre dann eine Kompatibilität zu eventuell vorhandenen Treibern hergestellt. Nun wüsste ich auch gerne, ob das Sound.cpx so etwas wie einen Treiber darstellt oder ob irgendwelche BIOS- oder XBIOS Routinen des Falcon-TOS die Treiberschicht bilden (wie würde es aber dann im STE aussehen?). Na ja - mal abwarten, ob sich hier noch jemand mit Infos einbringt.
Viele Grüße
Wolfgang
In der ST-Computer März 95 ist ein Artikel der für dich interessant sein dürfte.
Das scheint zu bestätigen (meine interpretation) das das Kontrollfeld die XBIOS-Funktion (Falcon) mit der Nr. 130 benutzt. Also soundcmd (RTATTEN, x) bzw. soundcmd (LTATTEN, x) kann die Dämpfung oder Lautstärke des rechten und linken Kanals eingestellt werden. Der Parameter x ist 16Bit groß, allerdings werden nur die Bits 4-7 berücksichtigt so daß effektiv lediglich Dämpfungswerte von 0-240 in 16'er Schritten möglich sind (dies ergibt genau die 16 Lautstärkestufen des Sound-CPX, wobei 15 der Dämpfung 0 entspricht).
-
Jetzt wird mir das alles klar,
die XBIOS130 gibt's beim Falcon nicht aber bei den kleineren ST(E)s. Das bedeutet, wie ich vermutete, dass das SOUND.CPX auf nicht vorhandene Register des Suska-IP-Cores zugreifen möchte. Daher gibt's dann Bomben durch Bus Error. Es wäre nun ein leichtes, diese Register einzuhängen. Nur macht das in meinen Augen wenig Sinn, da die neuen Audio-Codecs, wie es sie heute gibt, viel mehr Funktionen haben. Ich würde in diesem Fall nicht gerne Erweiterungen am Suska IP-Core vornehmen, die auf alten und nicht mehr verfügbaren Chips aufsetzen. Besser fände ich es eine neue XBIOS Funktion XBIOS130A oder so zu schreiben, die die neuen Chips via einem SPI-Interface, welches ich bereitstellen würde, bedient. Somit wäre man dann up to date bezüglich Multimedia. Die Frage ist halt nur, wer so eine XBIOS Funktion schreiben könnte oder eventuell ein neues SOUND.CPX, welches direkt auf die Hardware zugreift.
-
Leer
-
Hi,
ich wollte mich mal wieder zurückmelden. Hatte leider sehr viel zu tun die letzten Monate. Der Atari IP-Core ist nun in Version 2K10A erschienen und steht in Kürze auf experiment-s zum Download bereit (liegt schon oben ist aber noch nicht sichtbar). Hinweise gibt's dann in den 'releasenotes' im Verzeichnis Configware. Wir werden im Spätsommer und Herbst wieder mehr Gas geben, damit's was wird. Für die Suaka-III-C Betreiber: Configware Files liegen fertig compiliert vor.
Allen einen schönen Sommer und für diejenigen, die den Core in Betrieb nehmen wollen viel Spaß.
Grüße
Wolfgang
-
Hallo Wolfgang, Du must ja ordentlich was zu tun haben...schön mal wieder was von dir zu hören. Der Sommer scheint nun endlich angekommen zu sein, das einzige was noch fehlt ist, das wir Weltmeister werden. ;D Obwohl wir, wenn wir jetzt abtreten auch schon stolz sein könnten, da die Jungs eine klasse Leistung geboten haben. Schauen wir mal...
Gruß Arthur
-
Wurde eigentlich ein geheimes Abkommen getroffen oder warum gibt es nahezu keinerlei Informationen über SUSKA-User und ihren Erfahrungen damit? Hat denn schon wer aus diesem Forum ein SUSKA-Board erstanden um damit wie mit einem Atari zu arbeiten und zu zocken? Klar das noch nicht alle Treiber für die neuen Schnittstellen verfügbar sind (werden aber teilweise später von der Firebee angepasst) aber zumindest mit den Legacy Schnittstellen sollte sich doch schon jetzt auch arbeiten lassen. Ich hoffe das das SUSKA mehr als nur eine Entwicklungsplattform für "Hardwaregurus" wird. Ich finde die kleinen Platinen einfach schnuckelig. :D
Viele Grüße
Arthur
-
Hallo Arthur und alle die dies lesen,
ich habe derzeit in Stuttgart einiges zu tun. Für diejenigen, die es noch nicht mitbekommen haben: hier finden derzeit die größten Demos statt, die Stuttgart je gesehen hat (S21). Beruflich bin ich gerade anderweitig als mit Suska & Co. beschäftigt (strategische Planungen). Ich habe beschlossen, die Arbeiten am Core etwas auszusetzen, um einerseits etwas Abstand zu gewinnen und andererseits mich Dingen zu widmen, die mir momentan genauso wichtig sind. Aber keine Sorge, ich mache mir bereits Gedanken wie es weitergehen wird. In diesem Zusammenhang möchte ich Euch ferner mitteilen, dass es kein Abkommen gibt, SUSKA-Erfahrungen geheim zu halten. Das was bisher an 'Fehlern' hochkam war eher gering und wurde per email-Direktkontakt an mich herangetragen. Soweit ich weiss, hat noch niemand aus dem Forum ein Board erstanden. Ich nehme an, dass der Preis das Thema ist. Leider sind es nun einmal Kleinstserien mit großen FPGAs drauf, die in der Herstellung schon recht teuer sind. Das wird sich vermutlich mit dem 'Classic' Board auch nicht ändern. Und ich denke, bis die Anwender von Suska-Boards sich über's Forum austauschen wäre ein Zeitpunkt, den ich sehr begrüßen würde, da es dann vermutlich mal so richtig vorwärtsgehen würde. Fehler muss ich bisher alle selber nachvollziehen, was nicht ganz leicht und zeitaufwändig ist; öfters sind es dann gar keine. Ich denke, dass es im Oktober wieder regelmäßig weitergehen wird. Wir (Inventronik) besprechen gerade ob und wie wir diese Embedded-Schiene ausbauen wollen / werden. Ideen habe ich diesbezüglich genügend - Unterstützung (noch) zu wenig. Also bis dahin - falls ich mich zwischenzeitlich nicht mehr melde - mir geht's auf jeden Fall blendend, ich hoffe Euch allen auch.
Viele Grüße
Wolfgang
-
Hallo Wolfgang, danke für deine Infos.
Viele Grüße
Arthur
-
Ich hätte da mal ne Frage,
da ich nicht so viel Geld über hab, kann ich leider kein Suska C kaufen, kommt eigentlich noch die Tiny oder ist das gecanceld.
Gruß Matthias
-
Hallo,
es ist der 1. Oktober und ich hatte angekündigt, mich ab heute wieder zu melden. Ich werde morgen und am Sonntag auf der Classic Computing die verschiedenen Suskas ausstellen. Danach möchte ich mit möglichst vielen interessierten Personen erörtern, wie es weitergehen wird. Ich möchte schon einmal vorab anmerken, dass neben dem klassischen Board Suska-III-C auch das Tiny-Board Suska-III-T swie das Basismodul Suska-III-B weiterverfolgt werden. Während das Basismodul schon weitgehend fertig ist (inklusive Gehäuse und IP-Core) gibt es am Tiny nch einiges zu tun (DDR, 68K30, Falcon-Chipsatz). Das Tiny wird es wohl mit TFT oder TFT-Touchscreen geben und ist definitiv kein Lowcost-Produkt, wenn man bei Kleinstserien überhaupt von Lowcost reden kann. Das Basic Board soll zu einem attraktiven Preis als Fertiggerät angeboten werden.
Viele Grüße
Wolfgang
-
Hallo Wolfgang,
gibt es denn schon Bilder vom Suska-III-B ?
Gruss Martin
-
Also ich hatte da noch die Umfrage im hinterkopf, wo es Preislich doch einen Unterschied zwischen den Varianten gab. Und das Tiny würde sich auch gut in eine Tastatur oder Monitor einbauen lassen.
Das es billig PC Kisten von der Stange für weniger gibt ist mir durchaus bewusst, aber 600+ für eine Hobbyanschaffung ist ne Hausecke...
Gruß Matthias
-
Hallo,
ich werde demnächst Informationen zu Suska-III-B bereitstellen. Derzeit erweitere ich den Core von Suska-III-C um einige Funktionen, so auch den DMA-Sound. Hierzu habe ich folgendes Anliegen (Auszug aus einem email) :
Ich habe mir nun die Sache mit dem Audio-Codec angeschaut. Während im STE ein LMC1992 mit Microwire-Schnittstelle verbaut ist, befindet sich im Falcon ein Audio-Codec vom Typ ? Ich denke, dass der CS4299 Codec auf dem Suska-Board eher dem Falcon-Chip näher kommt. Daher würde ich die Falcon-Kompatibilität bezüglich des Codecs anstreben. Ich vermute, dass der Falcon den Codec aus dem Hauptspeicher via DMA (Direct Memory Access) bedient und hierzu 256 Byte im Speicher belegt. Allerdings fehlen mir hierzu jegliche Informationen. Ich werde den Core erweitern, wenn ich genügend Infos beisammen habe. Der Sound, der jetzt bereits über DMA im Suska funktionieren sollte, wird momentan auf den DAC AD5302 ausgegeben. Tests diesbezüglich habe ich noch nicht durchgeführt. Vielleicht könnte man das erst einmal austesten, um den DMA-Teil zu verifizieren und anschließend den Codec in Betrieb nehmen.
Bezüglich der Tests halte ich mich an Besitzer von Suska-Boards aber für Infos bezüglich des Falcon-Codecs wäre ich dankbar.
Grüße
Wolfgang
-
Hallo an alle im Forum,
leider gab's wohl bisher kein Feedback auf meine Anfrage. Das interpretiere ich mal so, dass es entweder keiner beantworten kann oder das Interesse nicht vorhanden ist. Ich würde nun folgenden Vorschlag machen. Wir (Inventronik) haben ca. 10 Suskas für Testzwecke herumliegen. Ich würde diese zur Verfügung stellen, wenn es Personen gibt, die sich für eine Fehlersuche (Debugging) oder für IP-Core Erweiterungen 'erwärmen' könnten. Leider ist der Core mittlerweile so umfangreich geworden, dass ein Team sinnvoll wäre, diesen weiterzupflegen. Ich bin momentan in Richtung 68030 und Falcon unterwegs, würde es aber sehr begrüßen, wenn sich verschiedene Personen um Detailtests kümmern könnten. Den Core kann ich mittlerweile noch alleine 'handlen', so dass Tester die Sache weiterbringen könnten; VHDL oder VERILOG Entwickler wären natürlich toll. Was meint Ihr?
Viele Grüße
Wolfgang
-
Hallo wfoerster,
ich beobachte Deine SUSKA Projekte schon seit einem Jahr und bin davon begeistert! Es war der Grund mich nach ca.20 Jahren wieder mit Atari ST(e) zu beschaeftigen.Nun habe ich mir mit ST MegaST und STE einige Geraete wieder gekauft und versuche mich da etwas in Hard und Software.Mehr am Wochenende und leider viel zu langsam.Zu Weinachten wollte ich mir eigentlich ein SUSKA III C goennen,aber der Zahnarzt hat mir einen Strich durch die Rechnung gemacht.Ich warte da auf das III B erstmal.Welcher Preis ist da angedacht ?
Als Tester wuerde ich leider weniger in Frage kommen.Ich habe mal durch den 2K10A Core mal geschaut,besonders den SHIFTER aber meine VHDL Kentnisse sind noch nicht so gut.Ich bastle mehr mit CPLDs an den 8 bit ataris.Ich kenne da nur die Grundlagen.Am core selber koennte ich nichts erweitern.Als Tester fehlen mir die ganzen Programme und besonders die Uebung mit den image tools,HD emulatoren u.s.w.Habt ihr eine Test-Roadmap an die man sich orientieren kann,oder bleibt es einem ueberlassen was er wie testet ?
Deine Frage kann/werde ich nicht beantworten koennen.Falcon und TT sind bei mir erstmal nicht drin! Nur bis zum STE.
Ich will nicht dass mir etwas fuer umsonst bereitgestellt wird und ich dann keine Gegenleistung erbringen kann.Ich verfolge aber gespannt und hoffe mir ein III B kaufen zu koennen wenn sie vermarktet werden.
Viele Gruesse,
Vassilis
-
Wolfgang, ich schick Dir ein Mail, womöglich können wir die Kräfte und Informationen noch ein wenig mehr bündeln. Generell finde ich es sehr gut, hier klarzumachen, was an Fragen und erwünschter Hilfestellung notwendig ist.
-
Ich mache auch sehr viele Hardwaresachen und denke mit Logic komme ich schon ganz gut zurecht. Aber VHDL ist mir noch ein buch mit sieben siegeln.
-
Hallo Wolfgang,
das sich bei dir keiner meldet, ist denke ich mal, weniger das "ich mag nicht" als viel mehr "Ich versteh bei VHDL nur (im Kopf)Bahnhof". 8)
Wenn es was zu testen gibt, oder auch sich anderweitig einzubringen, kein Thema solange es meine Fachkentnisse erlauben . Aber VHDL kann ich nicht, obwohl ich doch einige Hardwaregrundkentnisse habe. Und bis ich auf dem Stand bin, das ich da was anfangen kann - ach herje.
Gruß Matthias
-
Sehe ich genau so wie die Jungs weiter oben. Ich könnte nur testen welche Software und Funktionen gut funktionieren... aber nicht wo der Fehler in VHDL (very hard language ;D, kleiner Scherz) sitzt.
-
Hallo,
ich glaube, da habe ich mich wohl etwas ungenau ausgedrückt. Mir geht es um folgende Vorgehensweise: ich weiß, welche Module im Core noch nicht getestet sind und welche noch fehlerhaft arbeiten. Das kann ich auch alleine beheben, wenn mir jemand mit Anwendersoftware eine brauchbare Fehlerbeschreibung zukommen lassen kann. Leider bin ich das ganze Jahr schon sehr beschäftigt, so dass ich leider keine Zeit finde die Suska-III-C mit geeigneter Software aufzusetzen und dann so lange herumzutesten, bis sich ein eindeutiges Fehlerbild ergibt. Als Beispiel möchte ich einmal den DMA-Sound nennen. Der ist nicht getestet und das Microwire Interface für den LMC1992 geht noch nicht richtig. Nun ist Sascha dabei und testet das Zeug mit irgendeiner geeigneten Software durch und gibt mir Hinweise, was wie oder wie nicht funktioniert.
Auf diese Weise würde ich gerne einige andere Punkte angehen, um somit den Core immer besser hinzubekommen.
Grüße
Wolfgang
-
Hallo Wolfgang,
dann schreibe doch bitte kurz, welche Software getestet werden soll.
Freiwillige werden sich so bestimmt finden.
Ich verstehe Deine Aussagen so:
Es ist besser die Testboards zum Testen abzugeben, als diese weiter ungenutzt liegen zu lassen.
Zumal Dir selber die nötige Zeit dazu fehlt.
Gruss
Jürgen
-
Hallo,
ok. ich werde zusammenstellen, was alles getestet werden soll. Die Testboards sind aus unserer Nullserie. Die laufen alle korrekt und sind für Core-Entwicklung vorgesehen. Leider hat sich herausgestellt, wie hier schon angemerkt wurde, dass sich nur wenige Leute zutrauen am Core selber Hand anzulegen. Daher liegen sie jetzt in der Tat herum.
Ich werde mich bis Donnerstag zurückmelden.
w.
-
Hallo,
wenn es um das Testen bestimmter Anwendungsszenarien geht, bin ich gerne dabei. Im Dezember beginne ich frühzeitig mit dem Weihnachtsurlaub und finde da auch Zeit zum probieren und dokumentieren.
Für die Mitarbeit am Core bin ich leider vollkommen ungeeignet, da mir das nötige HW&VHDL Wissen sowie die nötige Ausrüstung fehlt.
Gruß Heinz
-
Hallo an alle im Forum,
leider gab's wohl bisher kein Feedback auf meine Anfrage.
Ich hatte Dir nichts geschrieben, weil ich keine Information habe die über das hinausgehen, was in der Entwicklerdoku drin ist. Ich gehe mal davon aus, daß Du die gelesen hast.
In der ST-Computer habe ich zwar einen Bericht gelesen, aber ich empfand nicht, daß das was besonders drin steht. Ich kann ihn trotzdem bei Bedarf scannen.
Ob im ST-Magazin was steht weiß ich nicht, da ich Artikel nicht komplet erfasst habe.
Gerhard
-
Hallo Wolfgang
Liegt die Liste der zu testenden einheiten schon vor?
würde mich ebenfalls um ein Testboard bewerben, zumal ich mittelfristig auch an einem kauf eines suska boards interessiert wäre. Kenne mich mit 68k assembler, avr assembler und hardware des ST aus.
Gruss Peter
-
Hallo Wolgang,
gibt es was Neues zur Basic-Version des SUSKA?
Gibt es Bilder?
Gruß Martin
-
Hallo Peter, Martin,
ich kann zur Zeit kaum Zeit für das Suska-Projekt aufwenden. Die Liste habe ich noch nicht zusammengestellt, aber dafür ist Suska-III-B fertig (allerdings erst seit kurzem). Bilder gibt's in Kürze und dann auch wieder mehr von meiner Seite.
Grüße
Wolfgang
-
Hallo zusammen,
anbei mein Eintrag in den experiment-s Blog. Das erklärt auch ein wenig, warum es um mich zur Zeit etwas still geworden ist.
Grüße
Wolfgang
Stand Februar 2011: die Entwicklung am Suska IP-Core geht unvermindert weiter. Durch die Verfügbarkeit der unterschiedlichen Geräte Suska-III-C, Suska-III-B und Suska-III-T ist auch die Entwicklung an der Firmware der Mikrocontroller und an den entsprechenden digitalen Modellierungen der FPGAs mannigfaltig angelegt.
Suska-III-B: Wir arbeiten an der Fertigstellung der Firm- und Configware der neuen Suska-III-B Geräte. Während die Configware (digitale Modellierung) des FPGAs abgeschlossen ist, wird die Fertigstellung der Firmware des Atmel Mikrocontrollers, der die Systemsteuerung, das PS/2 Handling von Maus und Tastatur und das SD-Karten Management übernimmt, noch etwas andauern.
Suska-III-C: Der seit Jahren gepflegte Suska-III-C IP-Core wird momentan auf Inkompatibilitäten untersucht und verbessert. Kleinere Fehlerberichtigungen flossen in der letzten Zeit ein (DMA Sound, Uhr). Es gibt einige Programme, die auf den Suska-III-C Boards nicht lauffähig sind. Wir untersuchen momentan, ob die 68K00 CPU hierfür verantwortlich sein kann. Die Firmware für zwei der drei Mikrocontroller (PS/2 und Systemkontrolle) ist abgeschlossen. Der dritte Microcontroller, der das SD-Karten Management und das Konfigurieren des FPGAs / Bootdevices über die SD-Karte ermöglichen soll, wird im Zuge der Arbeiten zu Suka-III-B weiterentwickelt. Derzeit gibt es noch keine öffentlich verfügbare SD-Firmware.
Suska-III-T: Die Arbeiten am IP-Core des kleinsten aber leistungsfähigsten Suska-Geräts gestalten sich am komplexesten. Da es sich bei dieser Hardware um eine durchgängig in 32 Bit Technologie entworfene Schaltung handelt, ist hierzu ein 68K30 Prozessor unerlässlich. Daher fokussieren sich die Arbeiten zur digitalen Modellierung dieser Schaltung derzeit auf die Entwicklung eines 68K30 IP-Cores, der die Funktionskompatibilität zum 68030 herstellen soll. Der Stand ist momentan so, dass der Buscontroller in Verbindung mit den internen Daten- und Opcode Caches, der Cache-Steuerung und der in diese Funktionsgruppen eingreifende Memory Management Unit (MMU) fertiggestellt und im Test sind. Die Arbeiten zum 68K30 werden noch eine längere Zeit andauern.
wf
-
Hallo Wolfgang,
gibt es was Neues zu den SUSKA-Projekten?
Gruss Martin
-
Hallo,
ja und nein, der Core ist heute morgen auf die Downloadseite von experiment-S gestellt worden. Genaueres kann man im in den releasenotes nachlesen. Ich hatte das letzte halbe Jahr wenig Zeit und werde in der zweiten Jahreshälfte wieder verstärkt daran arbeiten.
Grüße
Wolfgang
-
Hallo Wolfgang,
im IRC (http://www.atari-home.de/chat/chat.php) kam grade eine Idee auf die du evtl. als nächstes Projekt in Angriff nehmen könntest. Und zwar eine Erweiterung für ST(e)'s wie die PAK die die Pak selber, die Frak und einen IDE Port auf einer Platine vereint. Also 68'er raus, Sockel rein und Platine rein. Das müsste doch in VHDL möglich sein oder?
Gruß
Bernd
-
Hallo Bernd,
das ist sicherlich möglich. Ich finde die Idee einer Erweiterung in verschiedenen Richtungen gut; allerdings macht man das heute nicht mehr mit Sockel und Platine sondern mit VHDL oder VERILOG. Das hat den Vorteil, dass die Hardware nicht modifiziert werden muss aber auch den Nachteil, dass es nicht so viele Personen gibt, die das bewerkstelligen können. Andererseits ist auch klar, dass beispielsweise ein in VHDL modellierter Prozessor niemals so schnell sein kann, wie ein in Silizium 'gegossener' ASIC. Ich möchte für diejenigen, die in die Richtung Taktfrequenz erhöhen und alles viel schneller machen tendieren an dieser Stelle auf das Atari Coldfire Projekt verweisen, welches genau diesen Ansatz, allerdings mit Einschränkungen bezüglich der Kompatibilität zu originalen Ataris verfolgt.
Grüße
Wolfgang
-
Das hat den Vorteil, dass die Hardware nicht modifiziert werden muss aber auch den Nachteil, dass es nicht so viele Personen gibt, die das bewerkstelligen können.
Im Prinzip hast du ja schon alles was man dafür braucht, deswegen war das ja an dich gerichtet ;D
Andererseits ist auch klar, dass beispielsweise ein in VHDL modellierter Prozessor niemals so schnell sein kann, wie ein in Silizium 'gegossener' ASIC.
Die Geschwindigkeit eines 25 Mhz 68030 sollte doch drin sein oder? Der brauch ja dem Hades/Milan, der Firebee oder sonstigen Highend-Geschossen keine Geschwindigkeitsrekorde abnehmen sondern nur eine Möglichkeit darstellen eine etwas zeitgemäßere CPU sowie ST/TT-Ram und IDE ( evtl. auch mit SD/CF Karte ) zur Verfügung stellen. Natürlich gibt es das alles schon einzeln, es war ja auch nur eine fixe Idee die im IRC so entstand. Schön währe es trotzdem wenn es sowas geben würde.
Drüber reden kann man ja mal 8)
-
Huhu!
Wenn ich mich mal einmischen darf...(?)
a) habe ich mir ein SUSKA III-C gegönnt
b) bin ich noch im Anfangsstadium, Regelbetrieb liegt nicht vor... :-[
Also, stand heute Hardware: Suska III-C, Core: 2K9B, ist es schon möglich "mehr" RAM per DIP-Schalter zuzuschalten. Bedeutet beim Memory Test werden 8 MB ST-RAM hier bei mir angezeigt. Schalter aus: 4 MB.
IDE Schnittstelle ist auf dem Board vorhanden. :-) Leider habe ich zur Zeit kein 2,5" IDE Kabel und keine (ungenutzte) Festplatte zum Test. HD Driver ist aber installiert! :-) Grundsätzlich sollte davon gebootet werden können.
Mein Board startet mit der von Herrn Förster vorbereiteten CompactFlash Card. Die im aufgelöteten CF-Halter steckt.
Sauber, gut das Du das schreibst, gerade erst entdeckt... ::) Die Secure Digital Memory Card kann auf der Unterseite des Boards eingesteckt werden, habe ich aber in Ermangelung einer SD Karte nicht getestet. Wenn ich es korrekt verstanden habe, wird die SD-Karte genutzt für Softwareupdates des Boards/ IP Cores. Das Handbuch (Rev. 1.1) gibt darüber Auskunft auf den Seiten Seite 26 und 36.
Schnittstellen satt und genug, Fehlen die Softwaretreiber und Menschen die diese Programmieren. Na, und vielleicht Leute/ Käufer die mit dem SUSKA Board etwas anfangen können.
Strom, Tastatur/ Maus und Monitor dran, huch, da isser der ATARI! :-) Ich hoffe das klappt auch bald bei mir...
-
Strom, Tastatur/ Maus und Monitor dran, huch, da isser der ATARI! :-) Ich hoffe das klappt auch bald bei mir...
Na, sah doch am Sonntag ganz gut aus. Quasi genau wie oben beschrieben. Schade nur, daß es nur richtig mit dem SM124 funktionieren wollte.
Bis die Tage,
patjomki
-
Hallo,
ich hab da mal 2 Fragen:
1. Wird auch das SUSKA III-C mit der 68030er CPU laufen?
Wenn ja, kann man dann zwischen den beiden Prozessoren umschalten?
2. Wird es eine Möglichkeit geben das SUSKA III-C mit mehr als 14 MB zu betreiben? (TT-RAM?)
MfG Martin
-
Hi zusammen,
Suska-III-C kann prinzipiell mit dem 68030 laufen, wenn er fertig ist. Schwierig bei der ST-Architektur ist die 'Verzahnung' von CPU- und Video-Speicherzugriffen. Da ist der Falcon schon etwas besser aufgestellt. Da aber auch diese Chips in Arbeit sind (mir fehlen da noch einige Infos zum DMA-Baustein), könnte man dann auch den Falcon in angepasster Form auf dem Suska-III-C lauffähig machen. Wer also Infos zum DMA recherchieren kann, das würde sehr helfen.
Grüße
Wolfgang
-
Wenn der Falcon 'fertig' ist, wird das Suska auch für mich interessant werden. 'Aktuelle' Hardware für Crown of Creation wäre fein.
-
Hi zusammen,
Suska-III-C kann prinzipiell mit dem 68030 laufen, wenn er fertig ist. Schwierig bei der ST-Architektur ist die 'Verzahnung' von CPU- und Video-Speicherzugriffen. Da ist der Falcon schon etwas besser aufgestellt. Da aber auch diese Chips in Arbeit sind (mir fehlen da noch einige Infos zum DMA-Baustein), könnte man dann auch den Falcon in angepasster Form auf dem Suska-III-C lauffähig machen. Wer also Infos zum DMA recherchieren kann, das würde sehr helfen.
Grüße
Wolfgang
Hallo Wolfgang,
schön mal wieder was von dir zu hören. Kaum zu glauben was in programmierbarer Logic alles machbar ist. Ist der 68030er denn wesentlich komplexer nachzubilden als ein 68000er und wieviel Prozent des Cyclone ist für solche experimente eigentlich noch übrig bzw. gibt es Cyclones die mehr ermöglichen und pinkompatibel zum SUSKA Layout sind?
Gruß Arthur
-
Hallo Arthur,
der 68030 ist wesentlich komplexer, da dort Cache, Buscontroller und MMU ineinanderverzahnt arbeiten. Die Buszugriffe sind flexibler (dynamic bus sizing oder burst mode), was die Sache umfangreicher macht. Ferner kommen noch ein paar Befehle dazu, die der 68000 nicht hat. Und last but not least das Pipelining in der CPU. Da habe ich mir was vorgenommen :-)
Insgesamt wird der Prozessor deutlich größer, sollte aber in das FPGA des Suska-III-C reinpassen. Der Rest des Falcon wäre vergleichsweise wenig Aufwand.
Grüße
Wolfgang
-
Hallo liebe Leute im Forum.
Nachdem ich nun Monate nur selten hier im Forum war, möchte ich mich wieder zurückmelden. Ich werde vermutlich im Dezember nur ein Mini-Update des Suska-Core bereitstellen können. Aber danach geht's wieder weiter. Benötige immer noch jegliche Informationen zum Falcon-DMA Baustein. Wer etwas weiß... gerne an mich.
Herzliche Grüße
Wolfgang
-
Was hat denn ein FPGA in der Classic-Rubrik zu suchen. Das ist doch etwas sehr modernes. O.o
-
nachdems der Nachbau der STEs ist und keine Neuwntwicklung wie die Firebee => klassisch
-
Hallo,
das SUSKA hat eine 68000er CPU, gehört auf keinen Fall
in Hardware (High End).
Gruss Martin
-
Hallo liebe Community,
zunächst einmal ein frohes neues Jahr Euch allen und alles gute für 2012.
Ich habe die Arbeiten am Suska wieder intensiver aufgenommen und über Weihnachten die Anbindung des CS4299 Audio-Codec erledigt. Das geht soweit ganz gut. Nun würde ich gerne die Kompatibilität als erstes in Richtung des Falcon Soundsystems herstellen (also so gut wie möglich halt). Daher habe ich zunächst drei Fragen:
1. Gibt es Accessories, die den Audio-Codec des Falcon einstellen können (Lautstärke, Kanalwahl usw) - oder eine geeignete überschaubare Software?
2. Kennt sich jemand mit den Adressen der Sound-DMAs aus? Ich habe im Atari Registerlisting und nirgenwo eine Info finden können, wo die DMAs ihre Daten abholen oder hinschreiben.
3. Im Atari Registerlisting ist eine Einstellmöglichkeit zu entnehmen, die wie folgt lautet: 'Play 1 Track', 'Play 2 Tracks'... Was hat es mit diesen Tracks auf sich? Sind das dedizierte Speicherbereiche?
Danke für jeden Hinweis.
Herzliche Grüße
Wolfgang
-
zu 2.
Ich hoffe ich habe dich richtig verstanden. Es gibt keine Feste Speicherstelle, wo der DMA ließt oder schreibt. Er verhält sich ähnlich die Der ACSI/Floppy DMA
Die Bytes von &hFF8903 bis &hFF8907 werden mit der Startadresse eines Frames gefüllt.
Die Bytes von &hFF890F bis &hFF8913 werden mit der Endadresse gefüllt
Die Bytes von &hFF8909 bis &hFF890D enthalten während der Wiedergabe/Aufnahme die aktuelle Speicherstelle.
Schau dazu mal in dmaSnd.c (STE-Sound-Emulation) von hatari
zu 3.
Du beziehst dich auf das Register &hFF8920?
Ich habe mir die Falcon Emulation in hatari kurz angeschaut (falcon/crossbar.c), kann aber nur Vermutungen äußern.
Tracks scheinen die selektieren Audiokanäle zu sein (rechts ,links, DSP? ??). So kann jedes Frame aus bis zu 4 Tracks bestehen (die Organisation erkenne ich nicht)
Aber schau besser selber mal in Sourcen von Hatari.
-
Hallo Wolfgang auch dir ein frohes neues Jahr. Das FSOUND.CPX im CPX Ordner der Falcon Systemdisk kann zumindest die Lautstärke und die Stereobalance einstellen soweit mir bekannt.
Download z.B. hier:
http://www.atariworld.org/download.php?id=11
-
Es kann Eingangspegel rechts, Eingangspegel links, Summe und Panorama.
Vermutlich gibt es eine Menge Tracker, die mehr einstellen können.
-
Danke Euch für die Infos. Damit kann ich etwas anfangen. Die DMA Register für Framestart, Frameend usw. sind die gleichen wie im STE. Das ist im Atari Hardware Register Listing nicht korrekt vermerkt. Ich werde mal ein berichtigtes Registerlisting verfassen und dann zur Verfügung stellen. Dort sind dann auch die zusätzlichen Register drin, die nur bei Suska zu finden sind (CS4299-Anbindung zum Beispiel). Da es den Falcon Codec schon lange nicht mehr gibt, muss ich hier den besten Kompromiss finden, den neuen CS4299 so gut wie möglich kompatibel zu machen ohne Funktionalität zu verlieren. Aus den Arbeiten zu Suska kann ich dann bereits den DMA Baustein des Falcon entwerfen. Ich weiß nun in etwa, wie's geht. Das mit den Hatari-Sourcen war übrigens ein guter Hinweis. Ich habe mir die neuesten von Januar 2012 geholt.
Grüße
Wolfgang
-
Hallo,
ich habe den Falcon DMA-Baustein weitgehend fertig. Nun tauchen noch ein paar Fragen auf. Vielleicht könnt Ihr dabei helfen, so dass ich die Hardware komplettieren kann:
in den DMA Baustein gehen einige Floppy Disk Interface Leitungen hinein und heraus. Wer hat Infos über:
DISKCHNG
MODE1
MODE2
MDET1
MDET2
und dann gibt es noch ein CLKZ oder CLK2 Signal (rechts unten am DMA Baustein im Schaltbild).
Wäre prima, wenn ich hierzu Infos bekommen könnte. Die Floppy-Leitungen müssten eigentlich über Register gesteuert werden. Ich weiß aber nicht welche.
Grüße
Wolfgang
-
Das sind alles Floppysignale die im ST nicht verbunden sind.
Ich denke Die Floppy Signale werden am MFP auf Leitungen gelegt, die nur im ST benutzt werden. Der Serielle Port im ST würde sich dazu anbieten. Der hängt am MFP und ist im Falcon nicht mehr vorhanden. Die Leitungen sind also frei. Das wären schon mal drei Leitungen. Dann ist auch noch das Monochrom Detect Signal und auch das Bitter-Interrupt Signal frei. Das wäre dann fünf Leitungen. Das würde also passen.
Aber ich hänge mich da weit aus dem Fenster.
Man müsste jemanden Fragen der einen Falcon hat und ein paar Tests machen kann.
-
Halllo,
ich denke, dass es sich bei den hier genannten Leitungen um irgendwelche Signale handelt, die nicht Standard sind. an der Belegung des Floppy Steckers (Shugart-Bus) sind das die Pins 2, 6 29 und 31 oder so. Mich würde einfach interessieren, wie diese Leitungen angesteuert werden können beziehungsweise wie sie gelesen werden können. Ich denke das DISKCHNG ist ein Eingang MODE1 und MODE2 sind Ausgänge und MDET1 und MDET2 sind Eingänge.
Grüße
Wolfgang
-
Moin,
wenn man das auf den Atari-Alltag runterbricht,
dann interessieren ja nur zwei Modes:
DD-Floppy
HD-Floppy
DISKCHNG wird normal doch garnicht ausgewertet oder?
Das kenne ich nur vom Amiga.
Gruss
Jürgen
-
gerade hier http://mikro.naprvyraz.sk/docs/Memory%20Maps/FALREG.TXT gefunden:
$FFFF860F [R/_] W ________76543210 Floppy Controll-Register
||||||||
|||||||+- Vorteiler 1
||||||+-- Mode Select 1
|||||+--- Media Detect 1
||||+---- wird bei DMA-Zugriffen
|||| abgefragt
|||+----- Vorteiler 2
||+------ Mode Select 2
|+------- Media Detect 2
+-------- Disk Changed
-
Hi,
prima, das war's. Schon umgesetzt. Nun noch ein letztes:
Der DSP ist mit dem DMA Baustein verbunden; unter anderem mit den Leitungen SC2, SC1 und SC0. Gemäß DSP-Datenblatt sind das Ein- oder Ausgänge. Ich kann nirgendwo eine Info finden, die beschreibt, wie diese Leitungen vom DMA Baustein aus gesteuert werden?
Grüße
Wolfgang
-
Einen schönen guten Abend zusammen,
in der letzten Zeit ist einiges zusammengekommen, über das ich kurz berichten möchte:
1. Die Arbeiten am Falcon kompatiblen DMA Baustein sind grundstzlich abgeschlossen. Wenn der 68030 kompatible Prozessor soweit ist, kann das Debugging beginnen (kann den nicht jemand mal kurz modellieren :-)?
(Der COMBEL ist ebenfalls fertig und der VIDEL in Arbeit.)
2. Ich habe eine lauffähige Modellierung einer ACSI kompatiblen Festplatte, die ein EEPROM als solche erscheinen lässt - ganze 64kB groß; vermutlich die kleinste SCSI-Festplatte der Welt.
3. Aus dieser Vorarbeit existiert mittlerweile ein ACSI-Festplattencontroller, der SCSI Kompatibilität aufweist. Das Projekt wird darauf hinauslaufen, dass wir in Zukunft am ACSI-Port SD-Karten betreiben können, die als SCSI-Festplatten erkannt werden. Eine Hardware gibts dazu - demnächst mehr.
4. Ich bin in letzter Zeit häufig in Kontakt mit Uwe Seimet, der den HDDRIVER sorgfältig pfegt und weiterentwickelt. Wir haben aus seinen und meinen Arbeiten einen Link-97 kompatiblen Adapter entworfen. Ein Bild hängt unten an. Damit lassen sich in Verbindung mit HDDRIVER (hoffentlich) nahezu alle parallelen SCSI-Geräte am ACSI-Port betreiben. Der Adapter ist für EInbau gedacht, da es die 19-poligen SUB-D-Stecker nicht mehr gibt.
In diesem Zusammenhang wollte ich mal erfragen, ob diese Hardware gebraucht wird. Ich würde bei Bedarf von 30 Stück oder mehr eine Serie auflegen. Der Preis im Bundle mit der neuesten HDDRIVER Version würde sich auf 79,-€ zzgl. Versand belaufen und ohne HDDRIVER auf 61,-€. zzgl. Versand. Ich wusste nicht, wohin mit dieser Info in diesem Forum, daher hacke ich's mal hier rein. Vielleicht sieht das jemand und kann ein eigenes Thema aufmachen oder auch helfen, in anderen Foren diese Info zu streuen und die Feedbacks an mich weiterleiten. Mir fehlt schlichtweg die Zeit hierfür.
So, das war's für's Erste. Würde mich freuen, wenn sich jemand, der meine Inventronik-email hat und helfen kann die Infos zu streuen, bei mir meldet.
Bis demnächst und herzliche Grüße
Wolfgang
-
Hallo Wolfgang, schön wieder mal von Dir zu hören. Mit dem ACSI-SCSI-Adapter/Bridge/Kontoller al a Link97 tust Du vielen einen großen Gefallen. Mir ist aufgefallen das gerade vom VHDL-Majestro ;D so eine feine Platine mit rein standardisierten TTL-Chips gefertigt wird ohne einen hauch VHDL einzusetzen. Ich vermute dass das JPG nur der Illustration dient und lasse mich gern überraschen wie das fertige Produkt aussehen wird. Es wird sich bestimmt sehr schnell herumsprechen das sich hier etwas interessantes für viele Atarianer anbahnt. Btw. ACSI-Kabel sind mittlerweile kaum zu bekommen.
-
Ich würd ein Adapterbundle nehmen.
Gruß Matthias
-
Hallo Arthur, Matthias,
das Bild, welches ich geschickt habe ist genau das Produkt. Auf der Platinenunterseite ist ein Altera-CPLD (MAX-V) verbaut, der mit einer VHDL-Modellierung aus meiner Feder versehen ist. Ich habe doppelseitige Bestückung gewählt, um den Adapter kompakt zu halten.
Grüße
Wolfgang
-
Hallo Wolfgang!
Der neue SCSI-Adapter ist eine Super Idee. Ich würde allerdings versuchen nicht zu kleckern und gleich 100 anstreben und dafür den Preis auf 49,- bringen. Dann kommt die Anzahl auch zusammen. Das Board schaut jedenfalls genial aus! Falls Du doch noch eine Variante im externen Gehäuse machen willst, ich bilde mir eine ein Hardwaremensch von uns hat unlängst die 19-poligen lieferbar gefunden, ich werde das mal evaluieren.
Ich schick Dir sowieso ein Mail ;)
Bzgl. Videl, kannst Du nicht was von der FireBee nutzen? Schau mal hier rein, bevor Arbeit doppelt und dreifach gemacht wird: http://www.atariforge.org/gf/project/firebee/scmsvn/?action=browse&path=%2Ftrunk%2FFPGA_quartus%2FVideo%2FDDR_CTR.tdf&revision=12&view=markup
Und die Ultra-Satan hast Du auf dem Schirm? Die Quellen sind ja auch Open Source! Wird auch immer wieder verlangt und ist nirgens lieferbar.
Mathias
-
Guten Morgen Mathias,
ich bin mal bescheiden und würde 30 Stück anstreben. Wenn es mehr werden auch gut. Aber ein Abschlag von 61,- auf 49,- ist einfach nicht drin. Ich warte jetzt ab, was da so kommt; mal sehen. Über eine Quelle für die 19-poligen würde ich mich freuen (Printbuchse, gewinkelt; keine offene Bauweise).
Die SD-Card-Disk hat gar nichts mit Satan zu tun und es ist auch keinerlei Software da drin. Es handelt sich vielmehr um eine in Hardware gegossene State-Machine (Zustandsautomat), die die SCSI Spezifikation nachbildet und gleichzeitig die SD-Card Spezifikation bedient.
Bezüglich VIDEL habe ich seit langer Zeit schon so viel an VHDL-Modellierung rumliegen, dass ich nichts mehr benötige. Ich muss es halt nur nochmal durchgehen und 'fertig' schreiben. Der VIDEL soll auch ein VIDEL bleiben, also ohne übermäßig aufgepfropfte Erweiterungen. Somit ist er, wie alle Chips die ich entwerfe, 100% kompatibel zur 'Vintage' Hardware.
Grüße
Wolfgang
-
Morgen Wolfgang!
Alles klar soweit! Ein Mail hast Du auch schon. Und das mit der Die "SD-Card-Disk" klingt ja noch interessanter als gestern! Ich bin gepannt.
-
Hallo, macht mal Werbung für den neuen LINK97 Adapter auf atari-forum.com dann kommen die 30 Stück ganz schnell zusammen.
-
Hi Wolfgang
Cool wäre wenn diese Adapter an jedem SCSI-Controller ohne Treiberänderung funzen würde, d.h. SCSI-Platte raus, Adapter samt SD-Card rein!
Was soll er ungefähr kosten?
-
Hallo,
das ist in einer ersten Version nicht so gedacht. Ich versuche natürlich auch die ganze Geschichte zu berücksichtigen. Und da war es bisher so, dass wir die LINK97 am ACSI Port gebraucht haben, da es an großen Platten für den ACSI Port mangelte, oder schlichtweg es diese nicht gab. Also hat man eben einen Adapter dazwischengebastelt und dann SCSI Platten verwendet. In absehbarer Zeit wird es aber keine parallelen SCSI Komponenten mehr geben und somit haben wir dann die Situation, dass wir einen ACSI zu SCSI Adapter reinbauen, dann wieder einen SCSI zu SD-Card Adapter. Das macht in meinen Augen zumindest für den ACSI Port gar keinen Sinn. In Zukunft wird's einfach große Speichermedien für den ACSI Port geben, die in Form von SD-Karten daherkommen.
Ich kann auf der anderen Seite natürlich auch diejenigen verstehen, die beispielsweise TTs mit echter SCSI-Schnittstelle haben. Da muss ich überlegen, ob ich eine weitere Version auflegen werde.
Der Vorteil an der ACSI-SD-Disk ist der kompakte Aufbau (50mmx40mm). Das geht, indem ich einen 26 poligen HD Steckverbinder vorgesehen habe (man muss also eien Adapter von 19 nach 26 basteln). Auf die Suska-III-C Boards passt dieses Laufwerk direkt, ohne Kabel.
Für die interessierten hänge ich hiervon ebenfalls ein Bild an. Eine Charge von 8 Stück für Evaluierungszwecke ist in Fertigung und in ca. zwei Wochen einsatzbereit für Tests der umfangreichen VHDL-Modellierung.
Das angehängte Bild zeigt die Oberseite der Leiterplatte. Auf der Unterseite ist die SD-Karte im Halter aufgebracht.
Grüße
Wolfgang
-
Ist der 26polige Anschluss zu irgendwas kompatibel?
z.B. zum 24poligen internen ASCI-Anschluss des MegaST?
-
Der Anschluss ist zum Suska-III-C kompatibel. Wie gesagt muss man sonst ein Adapterkabel löten (wenn Du an Flachbandkabel gedacht hast geht das nicht; HD-Stecker und Flachband sind eh irgendwie kompliziert).
Grüße
Wolfgang
-
Klasse Sache!
an so einem Bundle hätte ich auch großes Interesse.
-
Hallo zusammen,
also ich muss hier etwas korrigieren, ist schon peinlich, aber mir ist ein Fehler bei der Kalkulation unterlaufen, ich habe die falschen Listen verwendet. Ich würde produzieren lassen, sobald sich 30 Interessenten finden.
dann wäre der Endpreis inklusive dem HDDRIVER, also das Bundle 84,-€
und der ACSI-SCSI-Adapter alleine 56,-€
und wenn sich 100 Interessenten finden:
dann wäre der Endpreis inklusive dem HDDRIVER, also das Bundle 79,-€
und der ACSI-SCSI-Adapter alleine 51,-€
Ich hoffe, mir nimmt's keiner krumm. Ist ein Projekt, dass ich neben meinem Büroalltag pflege und in der Hektik ist's dann halt passiert. Ich werde den ACSI-SCSI-Adapter auf meine Homepage stellen und dort werden die Preise dann auch nochmals zu lesen sein. Dort gibt's dann auch 'nen Link für Interessierte. So wie sich's angeht sollten auf jeden Fall 30 Stück zusammenkommen.
Schöne Grüße
Wolfgang
-
Hallo Wolfgang!
schönes Sideprojekt!
Wäre es möglich diesen Adapter irgendwie so zu designen, dass er auch kompatibel zu Steinbergs DMA (ASCI)-SCSI II Adapterinterface wird?
- Bin immer noch nach der Suche nach sowas...
Grüße
raphael
-
Das ist sicher möglich, wenn genügend Informationen vorhanden sind, wie dieser Adapter funktioniert. Wenn es heißt Steinberg ACSI-SCSI II Adapter, dann steht auf der einen Seite ACSI. Wie diese Schnittstelle funktioniert ist bekannt. Und auf der anderen Seite steht SCSI-II. Der hier vorgestellte ACSI-SCSI-Adapter ist SCSI-II tauglich wegen Initiator Identifikation und Parity Generierung und wird durch ein spezielles Kommando von SCSI Class 0 (was die ACSI Schnittstelle zulässt) auf andere SCSI Classes umgeschaltet. Allein diese Umschaltung könnte einen Unterschied machen. Die Änderung wäre vermutlich eher gering, wenn überhaupt ein Unterschied besteht.
Also um's kurz zu fassen: es ist gut möglich, dass der ACSI-SCSI-Adapter bereits für Steinberg geht.
Grüße
Wolfgang
-
alles was ich über den Steinberg ACSI-SCSI II Adapter weiß ist, das er nur die nötigsten Befehle zum booten emuliert, und danach über den Treiber einen SCSI-IC direkt Anspricht. Das unterscheidet ihn Grundlegend von anderen Adaptern. Es werden keine ACSI-Kommandos in SCSI Kommandos gewandelt, sondern ein SCSI-Interface-IC programmiert. Der Chip heißt: WD33C9A-PL
Ich fürchte, das das nicht so einfach umzusetzen ist.
-
Na ja,
ein SCSI-IC heißt für mich einen SCSI-II kompatiblen Controller zu entwerfen, der entsprechende Peripherie-Geräte ansprechen kann. Hab' ich ebenfalls in petto (SD-Karte als SCSI-Festplatte). Andere Peripheriegeräte-Typen müsste man dann anpassen. Allerdings lohnt sich das nicht, wenn es sich bei Steinberg um seltene, exotische Hardware handelt.
Grüße
Wolfgang
-
Hallo Wolfgang!
schönes Sideprojekt!
Wäre es möglich diesen Adapter irgendwie so zu designen, dass er auch kompatibel zu Steinbergs DMA (ASCI)-SCSI II Adapterinterface wird?
- Bin immer noch nach der Suche nach sowas...
Grüße
raphael
Hallo raphael, wozu wird denn das Steinbergs DMA (ASCI)-SCSI II Adapterinterface benötigt? Für Festplatten oder für spezielle Studiogeräte? Gibt es denn Hinweise das es mit bestimmten anderen Adaptern inkompatiblitäten gibt?
-
Das SCSI-Interface von Steinberg kam recht früh und hatte eine Zeit lang die einzige vollständige SCSI-Implementation. Das war nötig, um einen direkten DMA zwischen SCSI Audiorecorder/synthesizer und SCSI Festplatte zu ermöglichen.
Wenn ich mich richtig erinnere gibt es Programme von Steinberg, die das Interface direkt ansprechen und steuern.
-
Ich kann auf der anderen Seite natürlich auch diejenigen verstehen, die beispielsweise TTs mit echter SCSI-Schnittstelle haben. Da muss ich überlegen, ob ich eine weitere Version auflegen werde.
Hallo Wolfgang, da der TT ja auch noch eine ACSI-Schnittstelle hat könnte man das evtl. noch verschmerzen... für den Falcon hast Du allerdings recht.. da dieser ja keinen ACSI mehr besitzt.
Hallo ToPeG, danke für die Info. Gibt es Hinweise über die Nutzung anderer SCSI-Adapter mit der Software und Hardware von Steinberg?
-
Soweit ich mich erinnere ignoriert einige Steinberg Software andere SCSI-Adaptoren. Ich meine, die Begründung waren Probleme in der Echtzeitgenauigkeit. Später gab es wohl noch Unterstützungen für die SCSI-Interfaces von TT und Falcon, aber genaues kann ich nicht sagen.
Die Informationen habe ich vor über 15 Jahren in Musiker-Zeitschriften von einem Freund gelesen. Ich meine die Zeitschrift hieß MIDI.
Ich berichtige mich. Die Zeitschrift hieß "KEYS"
-
... wozu wird denn das Steinbergs DMA (ASCI)-SCSI II Adapterinterface benötigt? Für Festplatten oder für spezielle Studiogeräte? Gibt es denn Hinweise das es mit bestimmten anderen Adaptern inkompatiblitäten gibt?
Das Interface wird benötigt für Cubase Audio CBX und dem Yamaha CBX-D5 Digital Recorder ...
http://www.manualowl.com/m/Yamaha/CBX-D5/Manual/152238?page=3
-
Nebst CBX-D5 kann auch AVALON mit dem Steinberg Interface auf externe SCSI -Sampler zugreifen.
Falls eine zusätzliche Implementierung der Steinberg SCSI Vorgaben möglich wäre, wäre das der Hammer 8)
Grüße
raphael
-
Nebst CBX-D5 kann auch AVALON mit dem Steinberg Interface auf externe SCSI -Sampler zugreifen.
Falls eine zusätzliche Implementierung der Steinberg SCSI Vorgaben möglich wäre, wäre das der Hammer 8)
Grüße
raphael
-
Tja,
wie geht man nun mit so einer Diskussion um? Ich könnte anbieten, ein ACSI-SCSI-Interface an Tester auszuleihen. Dann wird man schon sehen ob's geht. Und wenn nicht gibt's hoffentlich eine konstruktive Zusammenarbeit mit den Testern und danach wird's dann vermutlich gehen. Lasst mal hören...
Grüße
Wolfgang
-
Hallo Wolfgang, das könntest Du machen so dass festgestellt wird ob es geht oder nicht (mehr wird nicht dabei heraus kommen... das kann also später auch getestet werden)... Ob die Tester allerdings dein Know-how haben um um dir bei der Entwicklung zu helfen das bezweifle ich. Besser wäre es wenn dir jemand zum Testen sein Cubase Audio CBX mit dem Yamaha CBX-D5 Digital Recorder zur Verfügung stellen könnte. Dies könnte ein erheblicher Mehraufwand für dich sein der sich kaum rentiert... Ausserdem weis ich gar nicht ob Du noch einen echten Atari zum testen hast.... ;D
-
Guten Morgen,
man müsste mal sehen, wie viele Cubase mit CBX-D5 überhaupt noch im Umlauf sind. Ich glaube, dass das eher wenig sind, die dann auch noch so einen Adapter benötigen würden. Mit Cubase und CBX-D5 möchte ich mich lieber nicht auseinandersetzen, da ich dafür nicht die Zeit aufbringen kann. Wenn der Adapter nicht funktionieren sollte, dann verwendet Cubase vermutlich ein proprietäres, das heißt nicht SCSI-konformes Protokoll. Sollte sich diese Vermutung bestätigen, dann wär's das auch schon, da ich dann überhaupt keinen Sinn darin sehen würde, proprietäre Hardware nachzubauen.
Viele Grüße
Wolfgang
-
Der Steinberg Adapter unterstützt auf der SCSI Seite das SCSI2 Protokoll vollständig der verbaute SCSI-Baustein handhabt das fast alleine, soweit ich das sehe. Auf der ACSI Seite wird etwas Eigenes gemacht. Nach dem Verbindungsaufbau mit den Adapter wird etwas ganz eigenes gesprochen. Ich habe mal kurz einen selbstgebauten ACSI-Sniffer angeschlossen und die Kommunkation ähnelt dem was ich mit meinem MultiIO gemacht habe. In der Command-Phase werden eifrig Daten in beide Richtungen verschickt. Keine Ahnung was da im einzelnen abläuft.
Wenn man versucht mit dem HDDriver 7 an das Gerät zu gehen spielt es völlig verrückt.
Der Yamaha CBX-D5 nutzt HFS als Dateisystem, und ich weiß nicht wie es da mit der Unterstützung für Atari aussieht. HFS wurde von Apple bis MacOS 7 verwendet danach kam nur noch HFS+ zum Einsatz.
Auch wenn noch CBX-D5 im Umlauf sind (ich habe mehrere Verkäufer gefunden und auf Ebay wird auch gerade eines angeboten), so dürften nicht mehr viele an Ataris speziell STs und STEs benutzt werden. Für jeden Interessierten dürfte es einfacher sein sich einen TT oder Falcon anzuschaffen.
-
Mit dem Atari TT scheint die Cubase Audio CBX Version nicht zu laufen siehe hier ...
http://forum.atari-home.de/index.php?topic=9404.msg66480#msg66480
Oder die Datei auf dem Steinberg FTP Server ist einfach nur defekt.
ftp://ftp.steinberg.net/Archives/Atari/cubase (ftp://ftp.steinberg.net/Archives/Atari/cubase)
-
Cubase Audio CBX-D5 soll doch laufen mit dem Atari TT!!! Ich habe Scans des Handbuch auf meine Seite hochgeladen wo man die Installation lesen kann.
http://www.atarian.nl/files/Cubase_Audio_CBX-D5_Installation_manual.pdf (http://www.atarian.nl/files/Cubase_Audio_CBX-D5_Installation_manual.pdf)
-
Hallo Ihr Lieben,
eine Frage, um sicher zu gehen: Wenn ich mir einen solchen Adapter kaufe, kann ich intern eine CF-Card am Atari betreiben über den ACSI-Anschluss und auf eine Festplatte faktisch verzichten?
Dann wäre ich sofort dabei. :=)
-
Wenn ich mir einen solchen Adapter kaufe, kann ich intern eine CF-Card am Atari betreiben über den ACSI-Anschluss und auf eine Festplatte faktisch verzichten?
Du meinst sicher die ACSI-SD-Disk oder doch den ACSI-SCSI-Adapter?
Wenn du die ACSI-SD-Disk meinst so läuft das zum Teil so wie du vermutest. In MegaST und MegaSTE ist der ACSI-Bus intern herausgeführt, sodass man dort die ACSI-SD-Disk anschließen könnte. Dafür würde aber eine kleiner Adapter gebraucht, da die Pin-Belegungen nicht alle gleich sind. (Soweit ich es verstanden habe passt die Pinbelegung zu einem Stecker auf dem Suska-III-C-Board) Bei STs und STEs hast du weniger Glück, da ist kein interner Einbau vorgesehen ist. Da wärst du gezwungen ein externe Lösung zusammen zu stellen, oder dir intern ein Anschluss an zulöten.
-
ToPeG hat's schon erläutert. Prinzipiell ist die ACSI-SD-Card-Disk dafür vorgesehen, Festplatten zu ersetzen. In Verbindung mit dem HDDRIVER sollte sogar ein Datenaustausch (zum Beispiel für Backupzwecke) mittels Cardreader oder direkt am SD-Slot modernerer Rechner mit PCs möglich sein. Ich denke, dass ich zunächst SDHC Karten unterstützen werde, später SDXC und dann die gewöhnlichen SD-Karten, die es eigentlich ja schon gar nicht mehr gibt.
Grüße
Wolfgang
-
Vielen Dank für die antworten. Im/am Atari TT könnte ich die Karte also auch betreiben und bräuchte keine SCSI HD mehr? Das wäre ziemlich genial.
-
Ich denke, dass ich zunächst SDHC Karten unterstützen werde, später SDXC und dann die gewöhnlichen SD-Karten, die es eigentlich ja schon gar nicht mehr gibt.
Es ist schon eine Weile her das ich mir die Spezifikation angesehen habe. Jedoch meine ich, dass die Basisbefehle bei allen SD-Versionen gleich sind. Erst wenn mehr als 1Gb (2Gb bei SD-1.1) adressiert werden soll muss man auf andere Befehle umsteigen. Wenn ich mich nicht irre, dann wirst du die SD-1.0 Spezifikation, und damit die alten SD-Karten, immer unterstützen müssen.
-
Stimmt soweit,
dennoch werde ich zur Inbetriebnahme SDHC Karten verwenden und dieise lauffähig machen. Wenn's dann mit herkömmlichen funktioniert dann muss ich nichts mehr machen. Wenn nicht kommen erst die SDXC dran. Der Teufel steckt immer im Detail :-)
-
Hallo zusammen,
zur Info: die ACSI-SCSI Adapter-Prototypen (4 Stück) sind aufgebaut und es sieht so aus, wie wenn sie funktionieren. Nun habe ich aber generell eine Frage: Bei Tests mit meinem Mega STE ist mir folgendes aufgefallen: ich habe HDDRIVER (neueste Version) auf verschiedene SCSI-Platten installiert und am eingebauten SCSI-Bus des Mega STE betrieben. TOS konnte von den einen Platten booten, von den anderen nicht. Ähnlich verhält es sich bei dem von mir entworfenen ACSI-SCSI Adapter. Hat dazu jemand eine Idee oder sogar schon Erfahrung?
Hier der Link zu den Anleitungen des ACSI-SCSI-Adapters:
http://download.experiment-s.de/Accessories/ACSI-SCSI-Adapter/
Dürft Ihr auch gerne weitererzählen.
Danke für jegliche Hinweise
Grüße
Wolfgang
-
Hallo Wolfgang,
das geht ja fix bei Dir. Am internen Adapter werden Platten die SCSI Initiatoridentifikation benötigen nicht unterstützt. Es wird standartmäßig nur ID 0 unterstützt und ich glaube auch nur eine Platte wenn die SCSI Karte nicht modifiziert wurde. Die Größe der Partitionen ist zu beachten und mehr als 1GB (oder waren es 2GB) läßt sich ohne modifikation des SCSI Kontrollers auch nicht ausnutzen.. wenn man sich auf 1GB beschränk gehts aber zumindest damit.. der Rest liegt dann halt brach.
Ich habe übrigens keinen Mega STE... alles irgendwo mal aufgeschnappt.
Mit deinem Adapter ASCI auf SCSI sollte das doch gehen...oder? ;)
-
Hallo Arthur,
alle Platten laufen, wenn ich den HDDRIVER via Autoordner und Diskette starte. Also nehme ich an, dass Initiator Identifikation und Parity ok sind. Nur TOS will nicht booten. Da ist mir halt nicht klar, wieso. Ich habe zum Beispiel eine Quantum Platte, die am SCSI-Port des Mega STE nicht booten will, an meinem ACSI-SCSI Adapter aber funktioniert sie einwandfrei, also auch bootet, wenn ich das Ganze an meinem Mega STE anschließe und wenn ich den ACSI-SCSI-Adapter mit der Quantum an Suska anschließe geht's wieder nicht - das soll mal jemand kapieren.
Weiterhin habe ich ja noch ein EEPROM als ACSI-Festplatte gebastelt und die bootet überall ?? Kennt man sich da jetzt aus?
Grüße
Wolfgang
-
Es könnte damit zusammenhängen wie das TOS nach Festplatten sucht.
Wenn ich mich richtig erinnere, dann geht das TOS die IDs durch und sendet den "Inquiry" Befehl. Bei jder ID wartet es eine (oder waren es drei?) Sekunde auf Antwort. Zuerst wird versucht diese über DMA zu transferieren Also ein Block von 512 Byte alles mehr als 16byte mit 0 gefüllt. Gibt das ein Error wird versucht diese per Commad-Zyklus zu übertragen. Gibt das ein Error wird angenommen das es sich um eine Megafile handelt. (soweit ich das ein Erinnerung habe)
Bei der ersten gefunden Platte wird ein "seek" nach 0 durchgeführt und 512Byte per DMA gelesen.
Ich würde vermuten, das aus irgend einem Grund das "Inquiry" nicht klappt oder das "seek" fehlschlägt. Wenn der Hddriver funktioniert, dann würde ich auf das "Inquiry" tippen, das etwas zurück liefert, welches das TOS nicht verarbeiten kann.
-
Einen schönen guten Abend,
ich plane gerade etwas an Suska-IV und wollte mal nachfragen, ob jemand weiß, ob es für die Retro-Rechner irgendwelche Ansätze mit WLAN gibt.
Danke im Voraus und Grüße
Wolfgang
-
Das einzige in der Richtung was mir einfällt ist eine Lan-Wlan-Bridge, die über ein Webinterface konfiguriert wird. So was habe ich schon mal benutzt.
Von einer direkten Einbindung habe ich noch nie gehört. Damit würdest du absolutes Neuland betreten.
-
Tja, dann muss man mal sehen, was da machbar ist. Schick fände ich's schon, wenn man via WLAN in's Netz könnte. Das Problem ist die Manpower. Ich mache, was ich so schaffe in Richtung Core-Development, in letzter Zeit auch verstärkt für Firebee. Aber die Treiberentwicklung für TOS oder MINT kann ich nicht zusätzlich stemmen. Man kann sich da aber sicher in der Linuxecke bedienen und Treiber anpassen.
Grüße
Wolfgang
-
IMHO müssten bestehende Treiber funktionieren. Im Endeffekt ist es egal ob ein Kabel angeschlossen wird oder ob die Packete durch die Luft wandern
-
Bei Wlan werden Frequenzen und Filter über die Firmware eingestellt, die beim Start in das Gerät geschrieben werden muss. Die Übertragung ist zudem verschlüsselt und der Verbindungsaufbau mit einer Gegenstelle ist auch ganz anders als beim Kabel. Vieles von dem muss im Treiber oder Wlan-Subsystem passieren.
Es müsste das gesamte Wlan-Subsystem von Linux oder *BSD portiert werden. Bei mintnet könnte ich es mir noch vorstellen, aber Stik/Sting ist so absolut unterschiedlich, dass es auf eine völlige Neuimplementierung hinaus liefe.
-
Hallo Wolfgang
Gibt es news bez. des ASCI/SD-Adapters?
Würde auch einen nehmen!
-
Hallo,
die ACSI-SCSI Adapter sind prinzipiell fertig und immer noch im Test. Ich melde mich diesbezüglich demnächst wieder (hab's auf meiner Liste ziemlich weit oben).
Grüße
Wolfgang
-
Was mich interessiert. Hast du das Problem mit der Erkennung gelöst und wenn ja was war das Problem? Ich bin einfach neugierig. :-)
-
Also wenn Du die Erkennung als Bootlaufwerk für TOS meinst, so habe ich getestet, nichts plausibles gefunden und auch nicht weiter gesucht. Ich habe den Verdacht, dass auch die TOS2.06 nicht astrein programmiert zu sein scheint, so dass Laufzeiteffekte (Race-Conditions) verantwortlich dafür sein könnten. Die verschiedenen TOS-Versionen haben zum Beispiel mehr oder weniger Probleme beim Floppy-Zugriff.
Grüße
Wolfgang
-
Wenn das Timing das Problem sein könnte so würde ich raten, das der DMA ein Tacken zu schnell oder zu langsam gegenüber der CPU reagiert. Die GLUE wäre dabei auch ein Ort wo man schauen könnte.
Solche Laufzeitprobleme Beträfen nur den Command- und den Status-Zyklus, da im anderen Fall alles Hardwareseitig läuft, was ja funktioniert. Das würde auch erklären warum es mit machen TOS Versionen funktioniert und mit anderen nicht. Beim TOS 2.06 wurden mache Timings geändert. Zudem wurden die verschiedenen TOS-Versionen mit unterschiedlichen Compilerversionen erstellt. Das kann zu Unterschieden führen.
Da es mit anderen Treibern Funktioniert würde ich raten, das das TOS zu schnell mit dem Lesen ist. Was natürlich auch an der GLUE liegen kann, die den DMA-IC nicht schnell genug selektiert.
Es kann aber auch sein das die GLUE zu schnell ist. Der DMA könne noch nicht fertig sein, wenn die Daten gelesen werden sollen.
Aber das ganze ist mehr oder weniger geraten. Ich habe mit zwar mal die SUSKA-Sourcen angeschaut, aber genaues habe ich nicht mehr im Kopf.
Braucht man erst anzugehen wenn alles andere fertig ist.
-
Nachdem ich mich gerade etwas mehr mit IDE Beschäftige habe ich mir die Beiträge hier auch mal durchgelesen. Du hast geschrieben, das du IORDY und das positive DMACK per UND miteinander verknüpfst hast. Dadurch wird das ausgehende /DMACK verzögert bis die Platte fertig ist.
Das funktioniert wenn die Festplatten schnell genug sind. Kommen sie gerade aus einem Ruhezustand oder sind anderweitig beschäftigt kommt es zu einem Bus-Timeout.
Die Lazy-OR Lösung verlängert das /DMACK bis die Platte fertig ist. Das ist auch nicht perfekt. Zu einem Timeout sollte es jedoch nicht so schnell kommen. Aber ich habe nicht herausfinden wie der 68000 auf ein verlängertes /DMACK reagiert.
Idealer weise sollte der Prozessor einen Wartezyklus einlegen und etwas anderes machen, solange IORDY LOW ist. Wie sich das realisieren lässt wüste ich nicht.
-
Klingt sehr interessant,
ich werde mir das ansehen. Nun habe ich noch eine kleine Bitte: könntest Du mir sagen, was Du mit Lazy-OR meinst? Ich kenne nur WIRED-OR, was natürlich im FPGA nur im Toplevel in den I/O-Zellen zu realisieren ist (FPGA-intern gibt es keine hochohmigen Leitungen).
Grüße
Wolfgang
-
Ja ich meine WIRED-OR.
-
Hallo,
so, ich hab' mir das jetzt angesehen. Es stimmt, dass ich die DTACKn-Logik über die UND-Verknüpfung mit IORDY mache. Das lässt sich natürlich ändern. Die Frage ist nur, was passiert, wenn IORDY signalisiert, dass die Platte eben nicht fertig ist. Dann würde eventuell der Buszugriff auf die platteninternen Register schief gehen.
Hat denn irgendjemand Probleme mit Timeouts durchj langsame IDE-Devices? Ich habe bereits -zig verschiedene ausgetestet und die funktionieren alle prima. Man darf dabei nicht vergessen, dass ein Bus-Timeout (Bus-Error) erst sehr spät durch die GLUE erzeugt wird.
Das einzige Problem, welches ich immer wieder habe besteht darin, dass zwei beliebige IDE-Geräte nicht immer zusammen funktionieren.
Die IDE-Schnittstelle des Atari ist ohnehin nicht sehr leistungsfähig und ich gehe gerade in die Richtung SD-Karten (ich berichtete bereits) am ACSI-Bus lauffähig zu machen. Das hat den Vorteil von DMA-Betrieb und busfähigkeit.
Grüße aus Stuttgart
Wolfgang
-
Wenn ich mir die anderen Interfaces anschaue, komme ich zu Folgendem:
IORDY wird per Wired-OR mit dem DTACKn verknüpft. Das resultierende DTACKn bleibt damit aktiv, bis das Gerät Bereit ist, selbst wenn der 68000 ASn zurück nähme.
Die Schaltungen arbeiten also so, als würden jene Daten vom Bus genommen, die zum Ende des DATCKn aktuell sind. Aber ich finde keinerlei Informationen die bestätigen oder widerlegen würden, das der 68000 so arbeitet.
-
die Daten bleiben bis zum Eintreffen des DTACKn am Bus anliegen. Siehe 68K00 Businterface. Allerdings finde ich die Lösung mit dem Wired-Or genauso suboptimal wie die mit der Verundung. Im Falle von Wired-Or gibt's dann halt keinen Bus-Timeout dafür bekommt aber das angeschlossene Gerät nichts mit und man wundert sich doppelt. Also ich denke, das ich es so lassen würde wie es ist.
Grüße
Wolfgang
-
Hallo Ihr Lieben,
ich habe in den Letzten Wochen die Modellierung der SD-Karten als ACSI Laufwerke fertiggestellt. Funktioniert prima, 64GB SDXC am Atari :-) Nun habe ich vor, diese Hardware in drei Versionen verfügbar zu machen: 1. Für die Suska-Boards, ist bereits fertig. 2. als SCSI-Laufwerke und 3. als ACSI Laufwerke. Für die drei Varianten wird es unterschiedliche Hardware geben. Nun stellt sich die Frage bezüglich der Anbindung der ACSI Laufwerke. Fakt ist, dass es keine 19-poligen SUB-D Stecker mehr gibt; oder präziser formuliert: es gibt noch alte Lagerware in begrenzter Stückzahl und keine Stecker mit Lötkelch mehr für die Fertigung der Kabel. Dann wäre die nächste Frage, ob man durch die geräte einen durchgeschleiften ACSI-Bus braucht (macht das Sinn oder kann man die SD-Karten Laufwerke als letztes Gerät einstecken?). Wie soll die Verbindung aussehen, wenn es keine Kabel mehr gibt? Gibt es jemanden, der Adapterkabel macht? Alles Punkte, die ich gerne ansprechen würde, bevor ich die Hardware fertigen lasse. Vielleicht hat jemand Ideen oder Anregungen?
Grüße
Wolfgang
-
Ich persönlich wäre an dem ACSI-Laufwerk interessiert. Wenn ein Pfostenstcker (20 Polig) drauf wäre der auch Strom führt wäre das für mich Ausreichend. Ein Platine zum Durchschleifen der Signale kann ich mir zusammen löten, das ist nicht kompliziert. Wenn du das auf der Platine schon machen willst wäre das großartig.
Von einem Flachbandkabel kann man auf alle möglichen Stecker gehen.
Wenn man die Masse auf die Abschirmung legt, kann man einen 15-Poligen Stecker benutzen. Nur vor konfektionierte Kabel bekommt man nicht so leicht.
Man kann auch auf 25 polige Stecker ausweichen. Das habe ich für meine Basteleien am ACSI-Port gemacht.
Da kann man Pins 1-13 mit D0-D7, CS, IRQ, DRQ, R/W, ACK verbinden, Pins 14-22,24 mit Masse, Pin 23 mit A1 und Pin 25 mit /RESET. Damit ist man nahe genug am Parallel-Port Pinout, dass man (nahezu) alle Druckerkabel benutzen kann. Nur die Kabellängen könnten ein Problem werden. Bei mir machten schon Kabel über 70cm Probleme, gerade zwischen Geräten von Atari selber (DMA-Fehler).
Wichtig wäre es ein "allgemein gültiges" neues Pinout für ACSI zu spezifizieren und öffentlich zu machen, um einem Windwuchs entgegen zu wirken. Wenn jeder sein persönliches Pinout entwirft, gibt es nur Chaos.
-
Hallo,
Für 19p DSUB siehe:
http://www.alibaba.com/product-free/111538080/D_sub_Machined_Pin_9P_15P.html
Gruß Milan
-
Sicher kann man sie sich produzieren lasen, doch die Mindestabnahme sind 1000 Stück. Selbst wenn sie nur 10Cent pro Stück kosten würden (ich denke eher 50-70Cent), wie soll man 1000 Buchsen los werden? Wenn er 500 Geräte Produziert und überall zwei Stecker verbaut. Die müssen dann auch verkauft werden.
-
Dort gibt es die Stecker für 1,- Euro pro Stück ...
http://www.netzgeraet.de/steckverbinder/sub-d/d-sub-stecker-loet/12179/sub-d-19pol-stecker-loetkelch-2-reihig.html
-
Hallo Wolfgang
19p sub-d stecker (und hauben) scheint es noch genügend im markt zu geben. Im extremfall könnte man sich mit einzelstiften auf einer kleinen sub-d platine aushelfen.
Schön wäre platinenseitig eine 24p stiftleiste, die pinkompatibel zum mega-st anschluss ist, so wäre zumindest da der anschluss mittels konfektioniertem flachbandkabel möglich!
-
Dazu fällt mir noch was ein. Man kann, wenn die Platine dick genug ist, diese zwischen die obere und untere Leiste des SubD Steckers stecken. Wenn die Platine passend Geätzt ist, geht das recht gut, und ist auch ziemlich stabil.
Man muss ja nicht alles schon bestücken, es reicht ja wenn es möglich ist.
-
Also ich mache jetzt mal einen Vorschlag: Die SD-Karten Festplatte (sie heißt Suska GigaFile Slim) ist ja bereits fertig und kann direkt auf die Suska-Boards hinten aufgesteckt werden. Ich habe sowohl bei den Suska-III-C Boards als auch bei der Festplatte einen 26 poligen High Density Sub-D verwendet, der auch Spannung führt. Somit braucht man keine eigenen Netzteile. Der Stecker baut kompakt und ist gut verfügbar. Auf den Suska-III-C Boards ist es ein weiblicher Stecker, die Gigafile ist mit einem männlichen Stecker bestückt (somit passt das auch ohne Kabel zusammen). Die Pinbelegung ist daher seit einigen Jahren, was Suska betrifft, festgelegt. Ich habe natürlich vor, diese aus Kompatibilitätsgründen beizubehalten. Die Pinbelegung ist übrigens im Suska-III-C Schaltbild zu finden.
Dadurch, dass auf der GigaFile ein FPGA verbaut ist muss die Leiterplatte 4 Lagen haben. Somit wirkt sich die Platinenfläche stark auf die Herstellungskosten aus.
Mein Vorschlag ist es nun, die GigaFile so zu produzieren, wie sie es jetzt bereits gibt (4x5cm² groß) und dafür zweilagige Adapterplatinen zu bauen, wie man die auch immer braucht. Ich denke an ACSI und auch an SCSI, die dann auch die Stromversorgung bereitstellen.
Ich werde am 29. und 30. September auf der Classic Computing in Lorsch sein und die ganze Hardware ausstellen. Ich bringe den ACSI-SCSI Adapter, die Gigafile, Suska-III-B, Suska-III-C und verschiedene Testhardware mit. Wer Lust hat könnte ja kommen damit man mal drüber diskutiert.
Von der Verwendung der 19 poligen Stecker bin ich nicht überzeugt, da das nur noch alte Lagerware ist. Für Suska-III-C habe ich Erweiterungen bezüglich Notebookfähigkeit geplant. Wenn ich es fertig bekomme, werde ich auch hier etwas vorführen.
Grüße
Wolfgang
-
Ich bin damit absolut einverstanden. Einen Adapter mit ACSI-IN ACSI-OUT und Stromversorgung bekomme ich auch noch zusammen gelötet. Den kann ich dann auch so gestalten dass er in eines meiner Gehäuse passt. :-)
Welche Kosten sind denn angepeilt?
-
Ist das Pinout so Richtig, oder habe ich da etwas verdreht?
(http://forum.atari-home.de/index.php?action=dlattach;topic=2536.0;attach=3800)
-
Ich würde mich bereit erklären für die, dies brauchen auch Adapterkabel zu bauen, oder auch Platinen, die einmal nen 19pol Stecker für die alten Ataris hat, einen Stromanschluss, sowie die neuen HD Stecker/Buchsen.
Wenn schon ein Layout oder ein anderer Vorschlag existier und es nur noch um die umsetzung geht bin ich dabei.
19pol Stecker kann ich noch auftreiben. Die Auch bereits 20pol Flachband leitungen genutzt wurden würde ich gern auch einen solchen Abgriff oder wenigstens ne Anschlussbuchse dafür vorsehen.
Ich hab zwar aktuell so gut wie keine Zeit, aber ich denke Oktober, November komm ich wieder zu was.
Gruß Matthias
-
Hallo,
ich hätte gerne eine ASCI-Verison mit 19poligem Stecker!
Gruß Martin
-
Ist das Pinout so Richtig, oder habe ich da etwas verdreht?
(http://forum.atari-home.de/index.php?action=dlattach;topic=2536.0;attach=3800)
Ja genau so sieht das Pinout aus. Eine Version mit 19 poligem Stecker kann einfach durch ein Adapterkabel realisiert werden. Leider dann mit externer Spannungsversorgung, da die ACSI-Schnittstelle der Ataris keine 5 Volt führt.
Kannst Du mir bitte dieses Bild schicken, ist ideal für Dokuzwecke.
Grüße
Wolfgang
-
Kannst Du mir bitte dieses Bild schicken, ist ideal für Dokuzwecke.
Darum habe ich es gemacht. :) Meine E-Mail ist unterwegs.
Eine Frage zu IOVCC und VCC.
Sehe ich es richtig, das IOVCC theoretisch deaktivierbar ist VCC dagegen immer Strom liefert? Oder Laufen die nur über verschiedenen Spannungsregler/Sicherungen?
-
VCC und VCCIO sind Spannungen, die an Suska-III-C zur Verfügung stehen. Die Gigafile benutzt aus Kompatibilitätsgründen nur 5V. Somit müssten Adapterboards nur mit einem 5V-Regler ausgestattet sein.
Grüße
Wolfgang
-
Somit müssten Adapterboards nur mit einem 5V-Regler ausgestattet sein.
Wozu noch der 5V Regler? Ist die Spannung nicht direkt nutzbar?
-
Diejenigen die die GigaFile am Suska-III-C Board betreiben müssen gar nichts basteln. Die GigaFile benötigt halt nun mal 5V Versorgungsspannung wo auch immer die her kommen. Also im Zweifelsfall aus einem 5V Regler eines Adapterboards.
-
VCC und VCCIO sind Spannungen, die an Suska-III-C zur Verfügung stehen.
Meine Frage Zielt eher in die Richtung: Wenn ich Hardware für den SUSKA-ACSI-Port baue (mein ACSIIO z.B.) und ich die 5V nutzen möchte, ist es egal welches VCC ich nutze oder gibt es da etwas zu beachten?
-
Suska-III-C liefert folgende Spannungen:
VCC = 5,0V
VCCIO = 3,3V
Grüße
Wolfgang
-
Danke
-
Vielleicht kann mir jemand helfen:
ich suche SUB-D Steckverbinder 26 polig, High Density, Printversion, 90 Grad gewinkelt, männlich. Die gibt's bei Reichelt (HD 26MW PGK) mit gedrehten Kontakten für 5,60€! Ich hätte gerne die Standardversion, die vermutlich preisgünstiger zu bekommen ist.
Leider kann ich keine finden, aber wie ich's schon erlebt habe weiß hier immer irgendjemand Bezugsquellen.
Grüße und Danke
Wolfgang
-
http://www.digikey.de/product-detail/en/10090926-P264XLF/609-4024-ND/2350309
Passt das?
-
sorry der eintrag war mist ::)
-
Hallo zusammen,
die CC 2012 ist vorbei und ich habe auf diesen Termin hingearbeitet, sowohl den ACSI-SCSI Adapter als auch die GigaFile Festplatte produktionsreif zu haben. Das ist nun auch der Fall. Ich habe vor beide Geräte anzubieten. Ich kann aber nicht alles leisten und frage als erstes einmal in diesem Forum an. Was es von mir gibt ist die Hardware für den ACSI-SCSI-Adapter und auch für die GigaFile Platte sowie die Dokumentation. Nach reiflichen Überlegungen habe ich beschlossen, die GigaFile als Fertiggerät, also mit Gehäuse anzubieten. Das Teil spricht ACSI und SCSI-II. Was es bei mir nicht gibt sind die Kabel, die notwendig sind, um die GigaFile an Atari ST, Mega STE, Falcon, TT oder auch Amigas anzuschließen. Hierfür suche ich jemanden, der das übernehmen kann. Anleitungen zur Kabelkonfektion gibt es natürlich auch von mir.
Wenn dieser Punkt gelöst ist gibt es dann ein Online-Bestellformular für die Teile. Ich muss aufgrund von Einrichtkosten von Maschinen usw. aber abwarten, bis genügend Bestellungen beisammen sind.
Der Preis für die Komponenten steht dann, wenn alle Details geklärt sind.
Ich hoffe, dass meine Vorgehensweise in Ordnung geht und warte jetzt auf ein Feedback von Euch. Wer eines der ersten Geräte haben möchte, die am ACSI-Port aber nicht am SCSI-Port funktionieren, der kann gerne bei mir anfragen (ich habe momentan 8 Stück). Die Prototypen sind identisch zu den kommenden Serienprodukten, 'fressen' alle Typen von SD-Karten und sind nativ für den ACSI-Bus ausgelegt. Die Platten haben somit eine Größe bis zu zwei TeraByte (wenn es dann die SD-Karten dazu gibt).
Die nächsten Tage werde ich die Doku zur GigaFile fertigstellen und online verfügbar machen.
Grüße aus S
Wolfgang
-
Hallo Wolfgang,
vielen Dank für Deine andauernde hervorragende Arbeit. Mangels entsprechender Fähigkeiten kann ich bei der Herstellung der Anschlusskabel leider nicht helfen, hoffe aber das sich hier im Forum andre Unterstützer melden.
An einem funktionierenden Exemplar/Prototypen der ACSI-SD-Card-Festplatte bin ich interessiert.
Schönen Gruß,
Heinz Schmidt
-
Konfektionieren und zusammen löten kann ich machen, wenn es nicht zu viele werden. 5-10 Stück kann ich an einem Abend wohl zusammen löten, wenn ich mir eine Lehre mache. Einen Kabeltester sollte ich mir dann auch noch zusammen setzen. Ist alles machbar.
Nur würde ich die Teile ungern privat einkaufen.
-
Funktionieren die auch zuverlässig extern am MSTE, wenn intern schon eine Festplatte mit dem Link96-Adapter angeschlossen ist?
Ich frage extra nochmal nach, weil die anderen SD-Kartenlösungen auch nicht so wirklich funktionieren. Deshalb schiebe ich Daten immer noch per CD-Laufwerk auf den MSTE.
Lässt sich die ASCII/SCSII-ID einstellen?
-
Ich habe das noch nicht ausprobiert, gehe aber davon aus. Gerne schicke ich eine GigaFile zum testen.
Die Laufwerke funktionieren wie externe MegaFile Festplatten, nur viel schneller (1MByte/s am ST oder STE, 1,7MByte/s am Suska Board und noch ein wenig schneller am TT).
Grüße
Wolfgang
-
Also Kabel kann ich fertig konfektioniert für nen obolus machen (schließlich muss auch Zinn und Strom bezahlt werden).
Also 19pol Atari zu 26pol. HD
Brauch nur nen Lieferant für die Stecker
-
Das hört sich ja gut an. Ich habe momentan noch zwei GigaFiles (ACSI-Version). Wenn ich jemanden habe, der interessiert ist, dürfte ich den dann an Dich verweisen?
Lieferant für die 26 poligen HD-Stecker ist beispielsweise Reichelt.
19 polige Stecker liefert Kessler Elektronik (es sind die geraden Print-Ausführungen). Diese Stecker sind hervorragend geeignet, wenn die geraden Pins mit Schrumpfschläuchen versehen werden.
Grüße
Wolfgang
-
Hallo Wolfgang, bitte PM mir mal was du für einen ACSI SD-Kartenadapter haben willst, Kabelinteressierte darfst du an mich weiterleiten, aber ich hätte gern selbst ein Gerät damit ich das Kabel testen kann.
26pol. Stecker muss ich auch erst noch besorgen. 19pol hab ich noch.
Gruß Matthias
-
ich möchte an dem WE Stecker bestellen, wer möchte aller ein Kabel? Bitte per PM melden.
Preis vermutlich so um die 10,-€ bei ACSI muss ich noch gucken, da kanns ein paar Euronen mehr sein weil man noch eine Spannungsversorgung braucht, die will ich per Durchschleifadapter vom Druckerport abzapfen, oder wahlweise per Stabilisatorschaltung vom externen Netzteil. externes Netzteil kostet halt nochmal und noch ne Steckdose die mann braucht....
Gruß Matthias
-
Hallo, also ich wäre eventuell an einer Giga-File ASCI interessiert. Da aber bis jetzt kein Preis dafür feststeht, kann ich keine feste Abnahme-Garantie für 1 entsprechendes Kabel machen. Ich möchte lieber nicht den Druckerport für die Stromversorgung in Anspruch nehmen (Steckernetzteile habe ich genug).
Es stellt sich also noch für mich die Fragen: Als Ultra-Satandisk Anwender -> welche Vorteile ergeben sich - außer dem Einsatz größerer SD-Karten - gegenüber der Satandisk. Die Kosten sollten sich für die Giga-File im Rahmen so maximal 60,- EUR bewegen (aber ich komme da schon ins Grübeln...)
Grüße, Retroram.
-
Ich schliesse mich Retroram an - ich wäre wenn es soweit ist auch an einem Laufwerk interessiert!
Grüße Jungsi
-
dito
-
Einen schönen guten Abend,
sorry, dass ich mich erst jetzt melde aber irgendwie funktioniert die Benachrichtigungsfunktion bei mir nicht mehr.
Also: die Laufwerke sind verfügbar. Siehe shop.inventronik.de. Diverse Adapter gibt es auch - (diese müssen aber zuerst noch gefertigt werden). Das englische Handbuch ist in Arbeit.
Grüße
Wolfgang
-
Dies ist mein erster Beitrag hier, und ich steige gleich mal mit einer Frage
ein. Ich habe einen Mega ST 4 mit Deicke 286 Bridge Board. Was genau brauche
ich noch ausser einem externen Gigafile? Und kann ich das ganze auch mit meinem
1040STFM verwenden?
Vg, Baert
-
Hallo Baert, dies ist der "Suska-III und Atari neue ACSI Laufwerke" Thread. Es wär besser für dein neues Problem einen eigenen neuen Thread aufzumachen... und herzlich willkommen hier im Forum.
-
Die eigentliche Frage bezog sich auf die Gigafile.
Zum Betrieb der Gigafile braucht es noch ein Anschlusskabel und ein Harddisktreiber, bevorzugt HDDriver.
-
Hallo Baert, dies ist der "Suska-III und Atari neue ACSI Laufwerke" Thread. Es wär besser für dein neues Problem einen eigenen neuen Thread aufzumachen... und herzlich willkommen hier im Forum.
Hallo Arthur,
im Normalfall klappt es bei mir mit dem Lesen noch ganz gut.
Hast Du meinen Beitrag auch gelesen?
Vielen Dank für die nette Begrüßung!
Vg, Baert
-
Die eigentliche Frage bezog sich auf die Gigafile.
Zum Betrieb der Gigafile braucht es noch ein Anschlusskabel und ein Harddisktreiber, bevorzugt HDDriver.
Hallo!
Welches Kabel brauche ich denn? ein ACSI-Kabel (was vorher meine SH205 mit dem ST verbunden hat)? Und dann gibt es ja auch Adapter zum Mitbestellen. Wofür sind die denn?
Vg, Baert
-
Welches Kabel brauche ich denn? ein ACSI-Kabel (was vorher meine SH205 mit dem ST verbunden hat)? Und dann gibt es ja auch Adapter zum Mitbestellen. Wofür sind die denn?
Genau diese Frage stellt sich mir auch, denn aus dem Shop ist nicht zu ersehen (oder beschrieben), was zum Betrieb des Gigafile an einem Classic-Atari noch gebraucht wird. @Baert: ein Adapter vom Gigafile(Spezial Sushka-Port) wird auf jeden Fall benötigt, es sei denn du baust dir ein Kabel, welches diesen speziellen Anschluss auf den 19pol. ACSI Port adaptiert.
Soweit habe ich das auch verstanden, jedoch will mir nicht klar werden, wozu die im Shop zusätzlich angebotenen Adapter sein sollen, oder besser gefragt: Ob der 19pol. Anschluss des Adapters eine Buchse oder ein Stecker verwendet wird.
Demnach entscheidet sich, ob man dann zusätzlich zu diesem Adapter noch ein ACSI-Standard-Kabel braucht, oder mit Hilfe des Adapters die Gigafile direkt hinten am ACSI Port angeschlossen wird.
Aber solch ein Adapter hat wohl niemand, oder?
Gruß HW
-
Hallo,
ich denke, dass ich im Shop mal ein paar Bemerkungen dazu schreiben werde :-)
Grüße
Wolfgang
-
Hallo zusammen,
weil es mit dem Foto noch etwas Zeit brauchte kam Wolfgang meiner Antwort schon zuvor. ;D - Vielleicht wäre es wie von Arthur angeregt inzwischen tatsächlich ratsam einen eigenen GigaFile-Thread zu starten und alles ab etwa Antwort #611 dort rein zu packen!? -
Die GigaFile-Platine hat einen 26poligen Sub-D HD Stecker. Dieses Layout gab's zu Atari-Zeiten wohl noch nicht und ist dreireihig. - 19polige Sub-D Steckverbinder sind inzwischen auch nur noch schwer erhältlich. -
- Zum externen Anschließen an den ACSI-Anschluss eines STs bedarf es deshalb also eines Adapters 19pol Sub-D Stecker auf 26pol Sub-D HD Buchse.
Diesen Adapter könnte man aus einem alten ACSI-Festplattenkabel fertigen. Im http://shop.inventronik.de/store (http://shop.inventronik.de/store) entspricht das dem "GigaFile - ACSI Adapter extern", der dann direkt an die ACSI-Buchse des ST angesteckt wird und seinerseits den Steckplatz für die GigaFile zur Verfügung stellt. - Mega-STE und Stacy haben einen internen, gesteckten ACSI-Host-Adapter, an dem die interne SCSI-HDD angeschlossen ist.
Anstatt dieses Host-Adapters kann auf die Pfostensteckerleiste des Mainboards der "GigaFile - ACSI Adapter intern" gesteckt werden. Die GigaFile steckt dann intern und liegt (bei meinem MSTE) über dem WD1772-Floppy-Controller (siehe Foto); Sie ist wesentlich schneller, kleiner und stromsparender als die olle Festplatte, auf die man getrost verzichten kann!
(http://img5.fotos-hochladen.net/uploads/gigafileintern62q8gjtiew.jpg) (http://www.fotos-hochladen.net)
- Weiterhin benötigt man HDDriver von Uwe Seimet und
- eine SD- oder SDHC-Karte.
Gruß soldermaSTer
-
Klasse Bebilderung und super Erklärung !
-
Hey Leute,
super, jetzt bin ich im Bilde :-)
Vielen Dank!
Vg, Baert
-
Hier noch ein Bild eines Kabels zum Anschluss des GigaFile an den ACSI-Port des 1040STE mit dem extra Stromkabel.
(http://www.jungsi.de/blog/wp-content/uploads/2012/12/GigaFile-Kabel.jpg)
-
Also brauche ich für die interne MSTE - Lösung das hier:
GigaFile - ACSI internal Adapter
http://shop.inventronik.de/store/16 (http://shop.inventronik.de/store/16)
und die PCB-Version
http://shop.inventronik.de/store/11 (http://shop.inventronik.de/store/11)
richtig?
Kapazitäten von über einem Gbyte funktionieren dann auch?
Muss ich dann noch Strom anschliessen, wenn ja geht das einfach mit dem serienmässig vorhandene Kabel von der Festplatte oder brauch man noch einen Adapter?
-
Ich denke das sind genau die Sachen die Du benötigst - auf dem Bild oben sehe ich keinen extra Stromanschluss und in der Beschreibung im Shop steht bei dem Adapter auch nichts dabei.
Ich habe gerade noch eine 16GB SDHC-Karte getestet - HDDRIVER erkennt diese ohne Probleme ;)
-
Der zweireihige, insgesamt 30polige ACSI-Host-Pfostenstecker (J402) auf dem Mega-STE-Mainboard führt an den Pins 26,28,30 VCC (+5V). Die Pins 25, 27, 29 sind GND (Masse). Siehe >Chips 'n Chips von Michael Ruge< (http://phoenix.inf.upol.cz/~opichals/libhyp/hypview.cgi?url=atmarita.de/startseite/images/chips/CHIPS_X.HYP&index=297)
Bei Nutzung des "GigaFile - ACSI Adapter intern" wird also keine zusätzliche Spannungsversorgung für die GigaFile benötigt.
P.S.: Gleiches gilt auch für die Stacy - Der Pfostenstecker hat hier allerdings die Bezeichnung >J11< (http://phoenix.inf.upol.cz/~opichals/libhyp/hypview.cgi?url=atmarita.de/startseite/images/chips/CHIPS_X.HYP&index=49).
-
Gibts eigentlich auch eine Adapterversion für den internen DMA-Port von Mega-STs? Gesehen habe ich keine im Shop.
-
Hallo oneSTone o2o,
ich musste erst mal in das Service-Manual des Mega-ST rein schauen, weil ich garnicht wusste, dass es dort auch einen internen ACSI-Port gibt. - Hast recht: Direkt vor der 19poligen ACSI-Buchse liegt die Pfostenleiste J17 und stellt die Signale zur Verfügung!
Im Inventronik-Shop gibt's keinen Adapter dafür; Dies liegt sicherlich auch an der blöden Positionierung von J17: Schaut man sich bei Bernd Mädicke (http://www.maedicke.de/atari/hardware/megast.htm) die Layouts der einzelnen Megas an, so müsste weil das "Schutzblech" vom ROM-Port um einiges höher sein dürfte der GigaFile-Adapter wohl seitlich oder im 45Grad-Winkel nach rechts verschwenken (siehe linke obere Ecke in den Fotos). -
Für eine "Hochkonstruktion" erforderliche Buchsenleisten mit langen Pins habe ich noch nicht gesehen. - Und dann wäre da ja auch noch das Batteriefach für die RTC. :(
-
Ich habe einen internen SCSI-Hostadapter für den Mega-ST rumfliegen, leider ist das GAL kaputt (wird sauheiß), der an diesem Anschluss angeschlossen wird. Der Hostadapter selbst sitzt auf einem Alublech was in dem Mega-ST platziert werden kann, und darauf ist auch Platz für eine 3,5-Zoll-Platte, eigentlich genial, leider aber kaputt und ich weiß nicht mal wer das Ding hergestellt hat. Schade. Aber der Hostadapter wird an der Stiftleiste per Flachbandkabel angebunden, das könntest du ja auch machen. Wäre sowieso dann schön, wenn man das Gigafile in so einen Rechner einbaut, dass das Gehäuse des Rechners einen Schlitz hätte, über den man die SD-Karte wechseln kann. Rein intern finde ich bei so einer Lösung doof.
-
Ich habe einen internen SCSI-Hostadapter für den Mega-ST rumfliegen, leider ist das GAL kaputt (wird sauheiß), der an diesem Anschluss angeschlossen wird. Der Hostadapter selbst sitzt auf einem Alublech was in dem Mega-ST platziert werden kann, und darauf ist auch Platz für eine 3,5-Zoll-Platte, eigentlich genial, leider aber kaputt und ich weiß nicht mal wer das Ding hergestellt hat. Schade. Aber der Hostadapter wird an der Stiftleiste per Flachbandkabel angebunden, das könntest du ja auch machen. Wäre sowieso dann schön, wenn man das Gigafile in so einen Rechner einbaut, dass das Gehäuse des Rechners einen Schlitz hätte, über den man die SD-Karte wechseln kann. Rein intern finde ich bei so einer Lösung doof. Direkt da hinten an der Stiftleiste würde ich das Teil nicht platzieren, auch bei einem Mega-STE oder TT nicht.
-
Hallo oneSTone o2o,
für mich persönlich kommt die mit SD-Karte bestückte GigaFile im Mega-STE rein funktionell gesehen einem heutigen mit SSD-Flashdisk versehenen PC gleich. -
Welchen Grund außer zu geringer Kapazität bei mehreren abwechselnd genutzten Betriebssystemen gäbe es dort für einen häufigen Wechsel der SSD?
-
Kann man die SD-Karte nicht so partitionieren/formatieren, dass man sie auch noch im PC lesen und schreiben kann?
Dann wäre das doch für den Datenaustausch geradezu genial.
-
Wenn man beim Partitionieren mit HDDriver die Partitionen mit TOS/WIN-Kompatibilität eingerichtet, dann wird unter Windows nur die erste dieser Partitionen erkannt. - Laut Dokumentation liegt die Ursache dafür bei Windows.
Ein Datenaustausch zwischen den Welten ist somit problemlos möglich, man muss die Daten Atari-seitig evtl. erst auf Partition C: bereitstellen bzw. neue Daten evtl. auf andere ST-Partitionen verschieben.
-
Das hatte ich schon so vermutet, gerade deswegen macht es ja Sinn, das Laufwerk so einzubauen, dass man ohne Gehäuse zu öffnen die SD-Karte wechseln kann.
-
Das hatte ich schon so vermutet, gerade deswegen macht es ja Sinn, das Laufwerk so einzubauen, dass man ohne Gehäuse zu öffnen die SD-Karte wechseln kann.
-
Zum externen Anschließen an den ACSI-Anschluss eines STs bedarf es deshalb also eines Adapters 19pol Sub-D Stecker auf 26pol Sub-D HD Buchse.
Diesen Adapter könnte man aus einem alten ACSI-Festplattenkabel fertigen. Im http://shop.inventronik.de/store (http://shop.inventronik.de/store) entspricht das dem "GigaFile - ACSI Adapter extern", der dann direkt an die ACSI-Buchse des ST angesteckt wird und seinerseits den Steckplatz für die GigaFile zur Verfügung stellt.
Nein, ich muss das korrigieren. Da die Teile gerade gekommen sind, kann ich definitiv sagen, das der ACSI Adapter nicht direkt hinten auf den Port des Rechners gesteckt werden kann, da auf der Platine eine Buchse, wie auch am Rechner vorhanden ist. Es Bedarf also zwingend zusätzlich noch einem DMA Kabel!
Gruß HW
-
Sorry hanswurst4711,
da bin ich wohl einer falschen Vorstellungen aufgesessen: Im Shop ist die Grafik einer unbestückten Platine zu sehen und weil 19polige Sub-Ds ziemlich rar sind hatte ich angenommen, dass wegen der besseren Verfügbarkeit schon direkt hinter dem Atari auf 26pol HD-Sub-D adaptiert wird.
Frage: Käme man mit dem Adapter zu "tief", wenn man anstatt der "von Oben" eingelöteten gewinkelten 19pol Sub-D-Buchse einen gewinkelten 19pol Sub-D-Stecker "von Unten" in die Adapterplatine einlötet? Pin-1 wäre wieder rechts und das Pinout sollte stimmen.
Gruß soldermaSTer
-
Die Frage kapier ich nicht wie du das meinst
90° gewinkelte 19pol. Stecker/Buchsen kann ich auftreiben
-
@soldermaSTer:
Nein, natùrlich ginge das, der gesamte Adapter steht dann aber ziemlich weit nach hinten ab. Außerdem ist die Karte dann auch noch unterhalb der Platine...
Da ich kein Kabel auf die schnelle heute auftreiben konnte, habe ich etwas gebastelt... Erstmal ein 19pol. Stecker mit Lötkelchen basteln, hab dazu 2 15pol. zersägt, und zwar Vorder und Hinterteil versetzt zueinander um es hinterher zu verlöten... Die Pins + Kunststoffträger sind gekürzt aus einem 25pol. Stecker. Das ganze zusammengebaut und verlötet. Nun habe ich auf die Schnelle einen 19pol. Stecker. Diesen habe ich dann auf der lötseite mit Abstandsbolzen verschraubt und verlötet. Nun steht das Gigafile hochkant und rangt etwa 1 cm über das Gehäuse und geht dabei nicht mehr in die Tiefe. So lässt sich das ganze auch gut wechseln. Positiver Nebeneffekt: die gewinkelte Originale Buchsenleiste liegt nun auf dem Tisch auf und kann nicht weiter nach unten gedrückt werden. So wird die Kraft vom einsetzen der SD Karte abgefangen.
So schnell noch einen Stromadadapter aus einem 9pol. Buchse und Stecker gebaut und die 5V/GND vom Joystickport geklaut... Fertig.
Funzt prima...
Allerdings wird meine 2GB nur als 1024MB angezeigt... Da war doch was mit einem Limit, oder? Irgendwas war da...
@wfoerster:
Danke für die Lieferung, ich dachte ich poste mein Problem mal hier:
hab ja auch den SCSI Adapter bestellt, und die Gigafile am Falcon betreiben zu können. Allerdings läuft das überhaupt nicht. Ist der Adapter ohne SD Karte am Bus wird dieser zwar nicht erkannt (soll wohl so sein) jedoch alle anderen Geräte... stecke ich eine SD Karte ein hängt der komplette Bus, keine Geräte werden erkannt, außer den Host (Falcon). Getestet mit HDDriver 8.44. An der Kette usw. kann es nicht liegen, richtig terminiert ist alles...Hmm. Kann mir nicht erklären, warum der Bus komplett gelockt ist. Irgendeine Idee?
Gruß HW
-
Einen wunderschönen guten Abend.
Das mit dem 1GB Limit ist so:
der HDDRIVER unterstützt ICD Kompatibilität. In diesem Modus können SD-Karten mit mehr als 1GB erkannt werden. Das kann man in HDRUTIL einstellen. Danach geht alles prima.
Zum ACSI-SCSI ADapter kann ich folgendes feststellen:
ähnlich wie bei der GigaFile Rev01 Version gibt es mit dem ACSI-SCSI Adapter Timing-Schwierigkeiten mit verschiedenen DMA-Chips (Artur aus Polen hat mir das auch berichtet). Ich bitte hier um Entschuldigung, da ich nicht über diverse Hardware zum Testen verfüge. Dennoch habe ich nachgelegt und eine neue Revision für den Adapter erstellt. Artur schickt mir eine nicht funktionierende Hardware. Ich bin mir sicher, dass es das gleiche Phänomen ist wie bei GigaFile Rev01.
Ich würde daher bitten, mich gegebenenfalls per email zu kontaktieren.
Herzliche Grüße
Wolfgang
-
Ach verflixt vom Joyport 5V klauen, daran hab ich gar nicht gedacht. Ich hab immer nur an der Rückseite geguckt wo ich die vermaledeiten 5V Sicher herbekomme *omanoman*
-
Hallo zusammen,
weil es mit dem Foto noch etwas Zeit brauchte kam Wolfgang meiner Antwort schon zuvor. ;D - Vielleicht wäre es wie von Arthur angeregt inzwischen tatsächlich ratsam einen eigenen GigaFile-Thread zu starten und alles ab etwa Antwort #611 dort rein zu packen!? -
Die GigaFile-Platine hat einen 26poligen Sub-D HD Stecker. Dieses Layout gab's zu Atari-Zeiten wohl noch nicht und ist dreireihig. - 19polige Sub-D Steckverbinder sind inzwischen auch nur noch schwer erhältlich. -
- Zum externen Anschließen an den ACSI-Anschluss eines STs bedarf es deshalb also eines Adapters 19pol Sub-D Stecker auf 26pol Sub-D HD Buchse.
Diesen Adapter könnte man aus einem alten ACSI-Festplattenkabel fertigen. Im http://shop.inventronik.de/store (http://shop.inventronik.de/store) entspricht das dem "GigaFile - ACSI Adapter extern", der dann direkt an die ACSI-Buchse des ST angesteckt wird und seinerseits den Steckplatz für die GigaFile zur Verfügung stellt. - Mega-STE und Stacy haben einen internen, gesteckten ACSI-Host-Adapter, an dem die interne SCSI-HDD angeschlossen ist.
Anstatt dieses Host-Adapters kann auf die Pfostensteckerleiste des Mainboards der "GigaFile - ACSI Adapter intern" gesteckt werden. Die GigaFile steckt dann intern und liegt (bei meinem MSTE) über dem WD1772-Floppy-Controller (siehe Foto); Sie ist wesentlich schneller, kleiner und stromsparender als die olle Festplatte, auf die man getrost verzichten kann!
(http://img5.fotos-hochladen.net/uploads/gigafileintern62q8gjtiew.jpg) (http://www.fotos-hochladen.net)
- Weiterhin benötigt man HDDriver von Uwe Seimet und
- eine SD- oder SDHC-Karte.
Gruß soldermaSTer
Hallo nochmal, meine Gigafile mit dem internen Adapter ist gerade angekommen.
Jetzt hätte ich aber gerne mal gewusst, was dieses Plexiglas-ähnliche Gebilde auf dem Bild ist. (Genau über dem Schriftzug "Karte". Dieses ist nämlich beim zusammenstecken abgefallen und jetzt kann ich es gerade nicht mehr wiederfinden.
Das war doch hoffentlich nichts wichtiges, oder?
-
... für die Funktion unwichtig, es ist nur für die beiden LED´s !
-
Wenn mich nicht alles täuscht wird das Licht der LED's gezielt umgelenkt damit es zum Beispiel in einem Gehäuse an die Frontblende geführt wird.
-
Die Frage kapier ich nicht wie du das meinst
90° gewinkelte 19pol. Stecker/Buchsen kann ich auftreiben
Hallo matashen,
ich hab' diesen Adapter nicht und deshalb zur Verdeutlichung gerade eine Fotosession mit einem 25er Sub-D-Pärchen gemacht:
- Die 19pol. Sub-D Buchse ist auf der Adapter-Platine eingelötet; Nennen wir diese Seite jetzt mal "Bestückungsseite". - Blickt man in die Buchse, dann ist Pin 1 rechts. -
- Würde man nun anstatt dessen einen 19pol. Sub-D Stecker von der "Lötseite" stecken und auf der Bestückungsseite verlöten, dann wäre Pin1 bei der gleichen Lage des Adapters (BS oben) auch wieder rechts und die elektrischen Verbindungen wären richtig. -
- Natürlich müsste der Adapter nun 'über Kopf' (LS oben) am ACSI des ST stecken und läge damit wohl zu tief (Drückt sich auf den Tisch).
(http://img4.fotos-hochladen.net/uploads/subdjbnicr586l.jpg)
Gruß soldermaSTer
-
... Erstmal ein 19pol. Stecker mit Lötkelchen basteln, hab dazu 2 15pol. zersägt, und zwar Vorder und Hinterteil versetzt zueinander um es hinterher zu verlöten...
Hallo hanswurst4711und ;D Hihi:
Hier ist ein Foto meines experimentellen Extern-Adapter-Steckers: Dazu habe ich einen 37pol. Stecker mittig 2x geschnitten u. die Seitenteile wieder miteinander verlötet. - Nicht schön aber sehr passgenau! ;D
Gleiches Problem, ähnliche Lösung!
(http://img4.fotos-hochladen.net/uploads/subd1937nge91q64r8.jpg)
-
Hallo hanswurst4711und Hihi:
Hier ist ein Foto meines experimentellen Extern-Adapter-Steckers: Dazu habe ich einen 37pol. Stecker mittig 2x geschnitten u. die Seitenteile wieder miteinander verlötet. - Nicht schön aber sehr passgenau!
Gleiches Problem, ähnliche Lösung!
Coole Lösung, vor allem weil der Zinnklecks aussen absolut egal ist. ich denke mal Stecker in die Buchse zum zusammenlöten und es past wirklich perfekt.
Muss ich mir unbedingt merken
-
(http://img4.fotos-hochladen.net/uploads/subd1937nge91q64r8.jpg)
Gute Idee.
-
Bei mir funktioniert es noch nicht. Ich habe eine 8 GB-Karte mit 4 256(C-F) Mbyte und und dann noch 6 Laufwerke mit 512 Mbyte (bis L) partitioniert. Ausserdem ist TOS 1.04-Kompatibiltät im Treiber aktiviert.
HDDriver partitioniert die Karte auch, aber beim neustart blinken die LEDs abwechselt und der Rechner bleibt hängen.
Die SD-Karte lässt sich anschliessend mit dem Festplattendienstprogramm auf dem Mac wieder reaktivieren und am MSTE wieder partitionieren, jedoch mit dem gleichen Ergebniss.
Was bedeutet das Blinken der LEDs?
-
Welche Revision hast Du denn? Die Rev.01 kam mit manchen DMA-Timings nicht zurecht. Mir wurde dann Rev.02 aufgespielt dann war ein ähnliches Verhalten weg. :)
-
Da gibts ne Anleitung zum Download da ist das Blinken erklärt.
http://download.experiment-s.de/Accessories/GigaFile/GigaFile-Bedienungsanleitung_1.0.pdf (http://download.experiment-s.de/Accessories/GigaFile/GigaFile-Bedienungsanleitung_1.0.pdf)
-
Der neuste Stand der Dinge:
Ich habe noch eine 2Gb SD-Karte von Kingston gefunden, die jetzt funktioniert. Allerdings nur wenn mein externes Festplatten-CD-Kombilaufwerk nicht eingeschaltet ist. Wenn es eingeschaltet ist wird das Gigafile nicht mehr erkannt. Auf das externe Laufwerk habe ich normalen Zugriff. Die ACSI-IDs überschneiden sich nicht.
Ohne dieses externe Laufwerk kann ich jetzt natürlich meine alten Daten nicht mehr zurück kopieren und auch keine neuen Daten mit Hilfe des CD-ROMs mehr aufspielen. Somit ist Das Gigafile für mich erstmal nutzlos.
-
nochmal zu meinem Verständnis: Man kann den internen ACSI-SCSI-Adapter des MegaSTE durch den Adapter für die GIGFile ersetzen und dann, richtige Einstellung im HDDriver vorausgesetzt, auch SD-Karten >1GB mit der GiGAFile voll nutzen?
Toni
-
Ja, zumindest solange du nichts an den externen ACSI-Bus anschliesst. Zumindest ist es bei mir so.
-
Hallo zusammen,
ich möchte generell was anmerken:
toll, dass die GigaFile in Verbindung mit allen möglichen Geräten getestet wird. Und danke an alle, die sich Zeit nehmen. Es ist nicht leicht, die SCSI-II Spezifikation und die ACSI-Schnittstelle fehlerfrei an allen möglichen Geräten abzubilden. Speziell die billigen SCSI Adapter und auch manche Atari DMAs bereiten manchmal Schwierigkeiten.
Daher hilft es mir / Euch, wenn Ihr mir über definitiv nicht funktionierende Geräte berichtet. Und wie Jungsi anmerkt am besten auch, welche Revision der GigaFile Ihr habt. Ein Configware Update hilft zuweilen weiter.
Die GigaFile ist nun seit zwei Monaten verfügbar und demnächst wird es eine Rev03 geben, die noch mehr als die REV02 auf schlechte Bustimings optimiert ist und auch einen Bug im Message System behebt. Dieser wirkt sich aber nur aus, wenn die GigaFile an einem echten SCSI Adapter benutzt wird und der Treiber auch das Message System benutzt (Beispiel: am Falcon mit HDDRIVER).
Ferner möchte ich noch mit weiteren Adaptern unterstützen... näheres demnächst im Shop.
Grüße
Wolfgang
-
Hallo an alle, die dies lesen möchten,
gerade habe in's Englische Atari Forum folgendes gepostet:
-------------------
i just want to give you the most recent informations on the GigaFile.
The Configware is since a few month in Rev03 and seems to be stable so far (no needs for upgrades in the moment). The GigaFile is reported to work on all Atari ST machines, the Falcon, the TT, on MACs i drive one under my Ubuntu Linux (just for test purposes), and also on AKAI S950 music samplers with ACSI interface card installed.
We figured out a good solution to reduce the shipping costs to international customers. In the meantime there are all possible adaptors available as also the cables of matashen and power supplies for this device.
Have a look at
http://shop.inventronik.de/store
for more information. By the way, the Gigafile documentation in English, French and German cen be found here:
http://www.experiment-s.de/de/download
Enjoy
Wolfgang
---------------------
Da ich nun schon eine Weile offline war dies zur Info über den Status dieser Suska-Peripheriekomponente.
-
Vielen Dank für dieses Update. :)
-
Hallo an alle, die dies lesen,
ich möchte mal wieder etwas von mir hören lassen, da ich mich in diesem Jahr etwas rar gemacht habe. Nachdem nun die GigaFiles letzten Herbst und im Frühjahr auf den Weg gebracht wurde, und diese stabil läuft, gibt es für mich an diesem Teil keine Arbeit mehr. Daher habe ich mich daran gemacht endlich (nach vier Jahren 68000 IP-Core) die 68030 kompatible CPU voranzutreiben, die Falcon Custom Chips nachzubauen, die Hardware für einen Falcon kompatiblen zu entwerfen und den DSP anzugehen. Einen genauen Stand der Arbeiten findet ihr auf www.experiment-s.de. Die Hardware ist entworfen, muss noch bestellt und bestückt werden. Das werde ich angehen, wenn alle digitalen Module soweit fertiggestellt sind. Momentan fehlen noch einige Teile wie folgt:
An der CPU: die Floating Point Unit, das Coprozessor Interface und der Exception Handler. Fertig sind hingegen der Buscontroller, Adressregister, Datenregister, Cache, MMU, ALU mit Barrelshifter und Multiplikation (in 1 Takt) und der Befehlsdecoder sowie die Ablaufsteuerung. Die CPU läuft mit Pipelining und kann derzeit mit etwa 45MHz getaktet werden.
Der DSP fehlt noch komplett.
Natürlich ist vermutlich an der CPU (das ist ein komplexes Teil geworden) auch noch viel Debugging notwendig. Ich werde eventuell noch nach Verstärkung fragen, wenn es soweit ist.
Das Ziel ist es dann, den kompletten Falcon in einem Chip zu realisieren. Die Hardware dazu ist 100x160mm groß und hat nur noch SD-Karten als Laufwerke (3 Stück).
Demnächst mehr.
Herzliche Grüße
Wolfgang
-
Moin, moin,
ich hätte da mal 'ne dämliche Frage, aber was ist eigentlich aus den Suska III-B und Suska III-T Boards geworden? Ist eine Veröffentlichung dieser Boards noch geplant oder sind die Board mehr oder weniger "tot"? Für mich ist z. B. das Suska III-C Board viel zu überdimensioniert, aber die kleinen Boards haben schon ihre Reize.
Das Suska-Projekt ist echt klasse und ich finde es irre, was in dieser Hinsicht alles geleistet wurde! Da muss man echt den Hut vor ziehen. 8)
Andreas
-
Hallo,
das Suska-III-T Board hat einen ernsthaften Designfehler und wird nicht mehr aktualisiert. Davon gibt es nur 5 Stück. Dessen Nachfolger ist das Suska-III-N.
Das Suska-III-B schlummert in einem Dornröschenschlaf. Suska-III-B wird nur als Fertiggerät kommen. Es fehlt im Prinzip nur an der Inbetriebnahme. Bilder habe ich hochgestellt auf www.experiment-s.de. Anmerkung: momentan habe ich noch das gleiche Vorschaubild für alle Ansichten. Einfach auf's Bild klicken.
Suska-III-C hat mittlerweile auch ein Gehäuse bekommen, da bin ich aber noch nicht so weit mit Bildern.
-
Suska-III-C hat mittlerweile auch ein Gehäuse bekommen, da bin ich aber noch nicht so weit mit Bildern.
Das ist ja mal 'ne geile Nachricht! 8) Danach wollte ich auch noch fragen, aber ich hatte mich nicht getraut. ;) Für mich persönlich ist so ein Gehäuse immer wichtig. Ich mag so nackte Elektronik gar nicht gerne.
das Suska-III-T Board hat einen ernsthaften Designfehler und wird nicht mehr aktualisiert. Davon gibt es nur 5 Stück. Dessen Nachfolger ist das Suska-III-N.
Also wird das Suska-III-N Board wesentlich kleiner ausfallen? Im Gunde wäre so ein ST zum in die Tasche stecken nicht schlecht. Den man einfach mal zu Freunden mitnehmen kann und dort an einen Monitor klemmen kann sowie über USB Tastatur und Maus dran und dann ein paar Spiele zusammen zocken. Das hätte was. Genau sowas würde ich gerne haben. ;D
Andreas
-
Bilder habe ich hochgestellt auf www.experiment-s.de. Anmerkung: momentan habe ich noch das gleiche Vorschaubild für alle Ansichten. Einfach auf's Bild klicken.
Ich habe mir die Bilder des Suska-III-B eben mal angeschaut. Genau sowas brauche ich! Das Teil ist echt klasse und das Gehäue finde ich auch überaus gelungen. Wenn das Suska-III-B mal fertig wird, dann möchte ich das auf jeden Fall haben. Echt saubere Arbeit!
Andreas
-
Hallo wfoerster,
ich habe auch noch ein paar technische Fragen:
- Wird das Susca-III-B Board auch für die Portierung anderer cores geöffnet, z.B für das Minimig oder
wird es nur Falcon closed source ? Wird es einen öffentlich zugänglichen Schaltplan geben ?
- Ist es beim Susca-III-C board tatsächlich so wie im Schaltplan angegeben, dass der Takt für
das SDRAM und für den tripple VGA DAC der gleiche ist , oder ist der Schaltplan nicht aktuell ?
Ich habe das Taktsignal CLK8 für den 64 pol. cpu Erweiterungssteckplatz nicht gefunden !?
( Ich würde gerne auch eine externe reale 68SEC000 cpu anschliessen können . )
Viele Grüsse,
Vassilis
-
Klasse, das es weiter voran geht. Das Suska-N klingt wieder sehr spannend. Ich hoffe es läßt sich günstiger herstellen, als das Suska-C.
Gibt es eigentlich wirgendwelche Kontakte oder Zusammenarbeit mit den Machern des MiST (http://www.harbaum.org/till/mist/index.shtml) Gerätes?
Schönen Gruß,
Heinz Schmidt
-
Hallo Heinz,
danke für die Blumen. Das MIST kam viel später als Suska. Es steht meines Wissens eine andere Philosophie wie beim Suska Projekt dahinter. Während Suska die Kompatibilität und auch die Leistungsfähigkeit der originalen Maschinen abdeckt und noch einiges mehr kann, ist MIST zu einem stattlichen Teil auf AVR Software basierend (SD-Karte, Maus, Tastatur etc. werden über den Microcontroller organisiert). Der Atari-Teil von Suska ist 100% native Hardware. Daher ergeben sich wenig Berührungspunkte zwischen MIST und Suska.
Grüße
Wolfgang
-
Status zu Suska-III-N
ich möchte im Januar oder Februar 2014 Suska-III-N auflegen. Zunächst sollen 10 Prototypen gebaut werden. Im Prinzip kann die Hardware den Falcon abbilden. Es ist ein Board von 160x100mm. Alllerdings kann ich bisher sicher die Funktionalität von Suska-III-C garantieren. Zum Falcon fehlen vor allem der 68030 - habe ich jetzt zu 100% implementiert aber bisher nicht getestet - das kann dauern. Und der DSP. den habe ich noch nicht. Wurde aber im ACP Projekt begonnen - leider bisher nicht vollendet.
Da Suska-III-C mittlerweile sehr stabil läuft und Suska-III-B derzeit gut weiterentwickelt wird, kann ich mich nun auf Suska-III-N konzentrieren. Ich sehe den Weg zum Falcon so: Suska-III-N produzieren, den Chipsatz des Falcon mit dem 68K00 Core und TOS 2.06 in Betrieb nehmen und dann den 68K30 nachschieben mit dem TOS 4.xx und dann den DSP implementieren. Insgesamt ein ehrgeiziges Projekt, was auch an meine Grenzen geht.
Ich habe seinerzeit die drei Suska-III-C Prototypen mit Donations finanziert - wofür ich heute noch dankbar bin. Ich würde es diesmal anders versuchen: Suska-III-N würde ich zehn mal Produzieren lassen. Wer hat Interesse an so einem Teil? Wer das Suska-Projekt schon länger verfolgt wird sich ein Bild über die Erfolgsaussichten eines neuen Boards machen können. Ich möchte mir aber nicht meine Programmierfinger abhacken lassen, wenn es nicht funktioniert. Es geht hier um ca. einen Einsatz von der Hälfte des Suska-III-C Boards.
Ich schreibe das jetzt hier mal rein um ein Stimmungsbild abzufragen.
Grüße
Wolfgang
-
Hallo Wolfgang,
ich habe bisher nur original Hardware in Verwendung und kenne das SUKA Projekt nur aus diesem Forum und von deiner Seite.
Ich hätte allerdings grosses Interesse an deinem Prototypen - also ich wäre dabei. Ich kann auch gerne Software / Hardware darauf testen, allerdings bin ich reiner Anwender und kann dir in technischer Hinsicht wenig bis gar nicht helfen.
Christian
-
Hallo Christian,
danke für die Rückmeldung. Ich denke, dass ich die Hardware in den Griff bekomme. Aber gerade auf der Softwareseite würde eine Unterstützung echt weiterhelfen. Im Prinzip ist ja Suska-III-C schon USB und Ethernet fähig. Die kommende Version 2K13B wird auch eine native SCSI Unterstützung mitbringen - Treiber fehlen bisher allerdings. Ich sehe also konkreten Handlungsbedarf so:
1. Hardware entwerfen - das kann ich leisten.
2. Software testen - es ist momentan so, dass auf Suska zwar sehr viel läuft aber eben nicht alles. Jeder Hinweis könnte mir helfen, den Core zu verbessern.
3. Treiber schreiben oder anpassen, um die bisher ungenutzen Hardware-Module zu beleben.
Das SUska-III-N ist natürlich das komplexeste Board und da wird es vermutlich einiges zu testen / anzupassen geben. Beispiel: es ist eine durchgängig 32 bittige Hardware - besser also als der Falcon. Auch in Bezug auf Videoauflösungen und Peripherieausstattung bringt der IP-Core einiges mit, was im Original nicht vorhanden war. Und alle diese Erweiterungen wollen getestet / angepasst werden.
Ich habe mir aus diesem Grund die 680xx Cross Compiler (Vincent Rivière) Umgebung mit Cygwin eingerichtet, so dass es möglich ist, Software und Betriebssysteme (z. B. emuTos) zu compilieren / anzupassen.
Wer hat Lust :-)
Herzliche Grüße
Wolfgang
-
Frage zu SCSI, warum braucht es dafür einen speziellen Treiber? Wird nicht der LSI SCSI-Chip aus dem TT bzw. Falcon nachgebildet, sondern ein anderer?
-
Wie gesagt würde ich das Suska-III-N Projekt gerne unterstützen. Wenn ich es richtig verstanden habe, suchst du Abnehmer für deine 10 Prototypen. Ich wäre gerne bereit dazu beizutragen. Ich habe mittlerweile eine brauchbare Software Sammlung, was noch käuflich ist - habe ich auch käuflich erworben um all die Entwickler zu unterstützen, die heute noch für den Atari programmieren. An Hardware verfüge ich vor allem über Audio Hardware (für deine DSP Programmierung) - Soundpool SPDIF, Analog 8, Syncbox + all die Soundpool Software von AudioMaster bis Audiotracker und der DSP Mastering Suite weiters Log 3, Steinberg MIdex +, Steinberg FDI... - an SCSI Devices habe ich ZIP 250, Jaz, Syquest, Mo Drive und diverse externe HDs und CD-Rom / DVD / BD Laufwerke...
Aber - ich bin reiner Anwender, habe bisher keine Erfahrungen mit emuTos und kann bloss Programme starten, herum probieren und dir einfache Mitteilungen darüber senden ob etwas funktioniert oder nicht...
Der technische Background fehlt mir allerdings vollständig - es ist bei dir, ob dir diese Art von Hilfe reichen würde ;-)
-
... MIST zu einem stattlichen Teil auf AVR Software basierend ...
Das MIST enthält überhaupt keinen AVR.
Laut http://shop.inventronik.de/store/1 (http://shop.inventronik.de/store/1) enthält Suska aber gleich drei AVRs.
???
-
Das MIST kam viel später als Suska. Es steht meines Wissens eine andere Philosophie wie beim Suska Projekt dahinter.
Die "Philosophie" hinter dem MIST ist schnell erklärt:
Das MIST ist der Versuch, das für den ST zu sein, was der Minimig (http://en.wikipedia.org/wiki/Minimig) (http://(http://en.wikipedia.org/wiki/Minimig))für den Amiga ist: Ein moderner Nachbau, einfach zu bedienen, klein, robust und in erster Linie zum Spielen.
Im FPGA (und nur dort!) läuft dabei der eigentliche Atari ST. Das Ziel ist maximale Kompatibilität mit der alten Originalsoftware, zugleich aber der möglichst einfache Einsatz moderner Peripherie (SD-Karten, USB-Joysticks/Mäuse/Tastaturen, VGA-Bildschirme, ...). Daher sitzt auf der Platine ein ARM-Prozessor, der zwischen den modernen Peripheriebausteinen und dem Atari ST im FPGA übersetzt. Er sorgt dafür, dass SD-Karten dem Atari im FPGA wie Festplatte und Disketten erscheinen, er sorgt dafür, dass USB-Geräte wie echte Atari-Perpherie erscheint. Außerdem steuert der ARM-Prozessor das ganze System indem er eine Bedienoberfläche über das Atari-Bild blendet. Dort kann man das Gerät bequem steuern, Diskettenimages auswählen, den ST-Typ festlegen (ST, STE, MegaSTE, STEroids), dort kann man festlegen, wie die Atari-Schnittstellen (RS232, Printer, ...) auf die USB-Schnittstellen umgeleitet werden usw usw. Lediglich für Joystick und MIDI kann man auf kompatible Anschlüsse zurück greifen. Und nichtmal das muss man. USB-Joysticks oder MIDI-über-USB geht genauso gut.
Und letztlich sorgt der ARM-Prozessor für das Initialisieren des ganzen Systems, denn es gibt auf dem MIST keine Flash-Speicher, keine weiteren Microcontroller (AVRs), keine Bootproms für das FPGA, keine Jumper, ...). Alles kommt direkt von der SD-Karte: FPGA-Konfiguration, TOS-Images, Disk-Images, Firmware-Updates. Einfach SD-Karte einlegen, Schalter umlegen und Spass haben. 99% der Spiele laufen ...
Diese Einfachheit erlaubt es dann auch durch einfachen Wechsel der SD-Karte einen Amiga oder einen Atari XL zu machen.
Ein Falcon soll das MIST definitiv nicht werden. Die Entwicklung soll eher in Richtung kleiner und billiger gehen ... aber so ganz kann ich's mir dann manchmal doch nicht verkneifen und es gibt den "STEroids-Modus" mit TT-Speed, 14MB ST-RAM, demnächst 16MB-Fastram, erweiterten TT-Videomodes, Ethernet etc ... das FPGA ist schließlich erst zur Hälfte benutzt ...
-
Dieser STEroids-Modus macht das Teil aber erst richtig Sexy... Und die Möglichkeit, auch einen Amiga damit zu emulieren. Wenn echte Original-Hardware nicht noch attraktiver wäre, könnte das Teil eine Menge Platz in meinem Hobbyraum sparen... Ist evtl. geplant, neben der A500-Emulation auch einen A1200/4000-Modus zu machen?
-
Ist evtl. geplant, neben der A500-Emulation auch einen A1200/4000-Modus zu machen?
Ich habe den Thread hier nur "gekapert", weil der OP auf das MiST eingegangen ist. Ich denke das hier sollte ein Suska-Thread bleiben. Weitere Diskussionen daher bitte in:
http://forum.atari-home.de/index.php?topic=10668.0
-
Hi zusammen,
ich bin wieder da. Kurz zur Info: ich hatte viel um die Ohren und war mit der Modellierung des 68K30 ausgelastet. Wen es interessiert: das war auf dem VCFe 15.0
https://speakerdeck.com/wfoerster/entwurf-einer-68030-compatiblen-cpu
Im Sommer und Herbst möchte ich wieder verstärkt an Suska arbeiten. Da das Projekt mittlerweile schon 10 Jahre alt ist und die Suska Boards nun bald 5. Geburtstag feiern, werde ich mir bis dahin was ausdenken :-)
Weitere Infos demnächst.
Grüße
Wolfgang
-
Einen schönen guten Morgen zusammen,
ich poste in dieses Forum immer als erstes News, wenn ich welche habe; gerne könnt ihr das weiter streuen. Also: ich habe die Arbeiten an dem 68K30 Core soweit abgeschlossen. Das Projekt hat sich über fünf Jahre hinweggezogen - sorry dafür. Wenn dieser Prozessor fehlerfrei läuft, dann steht dem Falcon-kompatiblen IP-Core wohl bald nichts mehr im Weg. Den COMBEL habe ich bereits, der VIDEL ist so gut wie abgeschlossen und am Falcon DMA mit DDR-Interface muss noch Arbeit investiert werden.
Der 68K30 Core ist so komplex, dass es wohl erfahrene 'Nerds' geben muss, um diesen IP-Core zu debuggen. Ich alleine schaffe das definitiv nicht, zumal die Mannschaften, die ihn designen und debuggen unterschiedlich besetzt sein sollten.
Für den Falcon-DMA bräuchte ich noch jegliche Infos, die irgendwer von euch da draußen hat. Das hilft bei der Implementierung.
Also wer Lust, Muße, Zeit, Durchhaltevermögen, den erforderlichen Biss hat, der kann helfen, das alles voran zu bringen.
Herzliche Grüße
Wolfgang
-
Hallo Wolfgang, da hast Du ja eine frühen Beitrag gepostet. :)
wie bist Du bei der Entwicklung des 68k30 Cores vorgegangen? Konntest Du den 68K Core weiter entwickeln oder mußtest Du eine anderen Ansatz wählen? Könnte man den 68k30 auch aufbohren im Core? Also z.B. größere Caches oder wär das zu komplex bzw. bringt das bei DDR Speicher nicht so viel? Ich hoffe das sich genügend Debugger einfinden damit die Entwicklung schnell voran geht..
Bei der Entwicklung hast Du bei dem ST damals IC für IC im ST durch Piggy-Back Adapter ersetzt... machst Du das im Falcon genauso?
Auf jeden Fall eine klasse Leistung von Dir.
-
Hallo Arthur,
der 68K30 Core ist eine komplette Neuentwicklung, weil er strukturell ganz anders aufgebaut ist. Er nutzt Pipelining, so dass er deutlich schneller ist als der 68K00. Momentan liegt die maximale Taktfrequenz je nach Baustein für Cyclone FPGAs zwischen 32MHz und 35MHz. Der 68K30 hat momentan 4096 Byte Caches implementiert. Das bringt im Vergleich zu originalen Chips, die 512 Byte haben, einen Geschwindigkeitsvorteil. Ich habe auf der VCFe in München im Frühjahr darüber einen Vortrag gehalten. Den findest Du hier:
https://speakerdeck.com/wfoerster/entwurf-einer-68030-compatiblen-cpu
Der Entwurf des Falcon geht anders als beim ST. Im Prinzip ist der Falcon eine Weiterentwicklung des Mega STE. Das sieht man ganz gut an dem 16 Bit Datenbus und den Signalnamen. Die Baugruppen sind anders auf ICs aufgeteilt und 'nicht so gute' Hardware wurde optimiert. Das kannst Du als Entwickler regelrecht vor Deinem geistigen Auge sehen. So war es nicht sonderlich schwierig, aus dem Suska Projekt den Combel zu bauen. Auch der Videl und die DMA sind nicht sehr kompliziert. Eine Schwierigkeit besteht nun aber dennoch in der Implementierung des Speicherinterface. Ich denke, dass es keinen Sinn macht, auf irgendetwas anderes als DDR zu gehen. Und das muss dann superschnell sein. Dazu gibt es zwei Ansätze: 1. Hard-IPs verwenden, das bedeutet fertige DDR Schnittstellen in FPGAs benutzen, womit man auf den Baustein festgelegt ist oder eine sehr performante VHDL-Modellierung zu schreiben, so dass auch das Speicherinterface quelloffen liegt und damit keine Abhängigkeit auf bestimmte Bausteine besteht. Ich verfolge momentan den zweiten Ansatz.
Ich hatte angekündigt, dass ich zu 10 Jahre Suska etwas bringen möchte und werde daher einige Teile für die kommende 2K14B Configware Version freigeben, so dass interessierte Personen über den Quellcode schauen oder sogar daran weiterbasteln können.
Grüße
Wolfgang
-
Danke für die interessanten News
-
Hallo Wolfgang,
wird die 030er CPU auch auf einem SUSKA III-C laufen?
Gibt es in der Zwischenzeit Bilder vom SUSKA III-C Gehäuse?
Gruß Martin
-
Ich habe auf der VCFe in München im Frühjahr darüber einen Vortrag gehalten. Den findest Du hier:
https://speakerdeck.com/wfoerster/entwurf-einer-68030-compatiblen-cpu
Wirklich sehr lesenswert und interessant. Könnte dich jetzt so mit Fragen löchern. >:D Das lass ich aber besser bleiben sonst must Du jemanden einstellen der solange deinen Job macht. ;D
-
Hallo Wolfgang,
wird die 030er CPU auch auf einem SUSKA III-C laufen?
Gibt es in der Zwischenzeit Bilder vom SUSKA III-C Gehäuse?
Gruß Martin
Hallo Martin,
ich habe noch ein wenig auf die Ergebnisse meiner Arbeiten am Falcon gewartet. Jetzt kann ich Dir genau antworten. Also es sieht jetzt so aus: für den Falcon habe ich den COMBEL, den VIDEL und den Falcon DMA Baustein fertig gestellt (Implementierung abgeschlossen, Funktionstests folgen, wenn ich die Suska-III-T2 Hardware fertig habe). Das sind die drei wichtigsten Bausteine neben der CPU. Kurz zur Erklärung über den Resourcenverbrauch in FPGAs: alle vier genannten Bausteine sind als mehr oder weniger komplexe digitale Schaltungen zu verstehen. Grundelemente dieser Schaltungen sind heutzutage in modernen FPGAs D-Flip-Flops und Look-Up Tables, das sind kleine Speicher, mit denen Gatterlogik, also boolsche Algebra abgebildet wird. In Altera Cyclone-IV FPGAs, die zum Einsatz kommen werden und in den Cyclone-II FPGAs von Suska-III-C ist diese Logik in Logikelementen (LEs) vorhanden. Der Cyclone-II des Suska-III-C Boards verfügt über 35000 LEs. Die momentane Implementierung von Suska-III-C mit dem 68K00 benötigt etwa 20000 LEs. Beim Falcon sieht das nun anders aus. Die vier Bausteine benötigen wie folgt: 68K30 - 27000 LEs, COMBEL - 2890 LEs, VIDEL - 2759 LEs, Falcon DMA - 4601 LEs und das DDR Interface nochmal 300 LEs. Zusammen geht das so in die Richtung 40000 LEs. Diese digitale Modellierung wäre für Suska-III-C zu groß. Daher bestünde nur die Möglichkeit den Core abzuspecken. Da bietet sich der 68K30 an. Dort werden nämlich für den Falcon die Coprozessorschnittstelle und die MMU nicht benötigt. Zusätzlich könnte man die Bitfield Befehle weglassen und den Barrelshifter durch einen gesteuerten Shifter ersetzen. Dann sollte es möglich sein. Allerdings sind das Arbeiten, die momentan keine Priorität haben. Ich denke, dass es zunächst einmal wichtig ist, 68K30, COMBEL, VIDEL und den Falcon DMA Baustein möglichst fehlerfrei in Betrieb zu nehmen. Wie gesagt ist dazu momentan eine Luxushardware in Vorbereitung - fragt lieber nicht, was diese kostet. Die gibt's daher zunächst auch nur zweimal. Dort wird ein Cyclone-IV FPGA mit 55000 LEs werkeln, der alleine schon etwa 150,-€ kostet.
Grüße
Wolfgang
-
Wie sieht es denn mit dem DSP MC56K aus dem Falcon aus, wird der auch eines Tages in VHDL modelliert? Ohne den wäre ein Falcon-Clone nicht komplett.
Und noch ein Gedanke: Für einen Falcon-Nachfolger gab es bei Atari kurz vor Ende die Idee, ich weiß nicht, ob seinerzeit auch schon ernsthaft daran gearbeitet wurde, die 32/64-Bit-Chips aud der Jaguar-Konsole in einem TOS-Computer zu verweden. Soweit ich weiß, wurde ja die gesamte Jaguar-Konsole zuletzt als 'Opensource' veröffentlicht, also kommt man ja an die genauen Spezifikationen usw. heran. Wäre es in einem nächsten Schritt evtl. möglich, diesen Schritt zu gehen, sprich den Falcon um eine Modellierung dieser Chips zu erweitern? Was die Softwareunterstützung für diese Variante betrifft, fragt ST-Oldie hier aus dem Forum. Der ist bereits dabei, Emu-TOS auf den Jaguar zum Laufen zu bekommen. Derzeit arbeitet er an der Anpassung des VDI an die Grafikhardware des Jaguar und ist dabei schon ziemlich weit fortgeschritten, er steht scheinbar kurz vor dem Schritt, den GEM-Desktop auf dem Jaguar starten zu können...
-
Hallo Wolfgang,
vielen Dank fuer Deine ausführliche Antwort.
Gruß Martin
-
Schönen guten Abend an alle,
an den DSP habe /hatte ich auch schon gedacht (s. Firebee). Wer sich die Infos / Datenblätter dazu mal ansieht wird schnell feststellen, das das ein größeres Projekt ist. Daher kurz meine Ansage: DSP und Floating Point Unit sind im Fokus für irgendwann, Jaguar überlasse ich gerne ambitionierten Personen, die Lust haben mitzumachen. Weitere Erweiterungen sind bisher nicht geplant.
Grüße
Wolfgang
Wie sieht es denn mit dem DSP MC56K aus dem Falcon aus, wird der auch eines Tages in VHDL modelliert? Ohne den wäre ein Falcon-Clone nicht komplett.
Und noch ein Gedanke: Für einen Falcon-Nachfolger gab es bei Atari kurz vor Ende die Idee, ich weiß nicht, ob seinerzeit auch schon ernsthaft daran gearbeitet wurde, die 32/64-Bit-Chips aud der Jaguar-Konsole in einem TOS-Computer zu verweden. Soweit ich weiß, wurde ja die gesamte Jaguar-Konsole zuletzt als 'Opensource' veröffentlicht, also kommt man ja an die genauen Spezifikationen usw. heran. Wäre es in einem nächsten Schritt evtl. möglich, diesen Schritt zu gehen, sprich den Falcon um eine Modellierung dieser Chips zu erweitern? Was die Softwareunterstützung für diese Variante betrifft, fragt ST-Oldie hier aus dem Forum. Der ist bereits dabei, Emu-TOS auf den Jaguar zum Laufen zu bekommen. Derzeit arbeitet er an der Anpassung des VDI an die Grafikhardware des Jaguar und ist dabei schon ziemlich weit fortgeschritten, er steht scheinbar kurz vor dem Schritt, den GEM-Desktop auf dem Jaguar starten zu können...
-
Einen schönen guten Abend an alle, die dies hier lesen,
ich möchte an dieser Stelle kurz informieren, dass die Suska Configware in Version 2k14B nun auf experiment-s zur Verfügung steht. Dieses Jahr war von viel Arbeit geprägt. Neben der Pflege der aktuellen Sourcecodes sind der 68K30 Prozessor, der kleinere 68K30L (siehe release notes der Configware) nun fertiggestellt und so weit wie möglich via Hardware-Simulationen getestet. Ferner sind die drei Hauptbestandteile des Falcon (Videl, Combel und DMA) fertig im 2K14B Release enthalten.
Um all die neuen Dinge zu testen wurde die Suska-III-N Hardware entwickelt. Diese ist allerdings bezüglich der FPGA Ressourcen etwas zu knapp bemessen weil der 68K30 ohne FPU bereits 27.000 Logikelemente benötigt. Aus diesem Grund ist nun eine weitere Hardware am Start, die eine Nachfolge der Suska-III-T Boards darstellt. Diese Suska-III-T2 Module werde ich genau zweimal produzieren. Sie sind hochpreisig, kommen aber mit FPGA mit 55.000 Logik Elementen, WLAN, Bluetooth, GPS, Gyrometer, Accelerometer, Hygrometer, Thermometer, Anschlüssen für moderne LCD-Displays und DVI-Monitore, Erweiterungs-Steckverbindern und sind zudem noch klein (89x60mm²). Das sollte ausreichen um den, im Vergleich zum Suska-III-C Board, komplexen IP-Core in Betrieb zu nehmen.
Wenn das dann soweit ist (das kann schon mal einige Monate dauern), denke ich an die Floating Point Unit (Berechnungseinheit für Gleitkommazahlen) und an den digitalen Signalprozessor.
Ich wünsche euch allen ein paar entspannte Feiertage und einen guten Rutsch mit einem noch besseren Start in 2015.
Viele Grüße
Wolfgang
-
Wie sieht's denn mit der Suska III-B aus? Ist dort in nächster Zeit mit einer Veröffentlichung zu rechnen? Die Suska III-B würde mich noch am meisten interessieren. ;)
-
Suska-III-B mache ich momentan zusammen mit Udo fertig. Das Teil liegt ja echt schon lange herum. Daher ist es auf der Prioliste hochgerutscht. Ich werde es ankündigen, wenn es soweit ist.
Grüße
-
Hallo Wolfgang,
gibt es zum SUSKA-III-B und zum SUSKA-III-T2 was Neues?
Gruß Martin
-
Hallo Martin,
wir planen momentan wie es mit der Suska-Linie weitergehen wird. Sobald es Neuigkeiten geben sollte werde ich mich auf diesem Kanal wieder melden. Im Fokus steht Suska-III-B. Suska-III-T2 gibt es zweimal bisher.
Grüße
Wolfgang
-
Hi
An dem SuskaIII habe ich intresse wenn orginal tastur und SM daran gehen speicherung auf CF Karte finde ich sehr gut und ein gutes gehaüse sollten sein und ST programme sollten laufen ohne einschränkung.
Der Mist ist zwar auch nicht schlecht oder auch Firebee aber der suska III gefällt mir besser
Bitte per Mail bescheid sagen wenn es soweit ist
Gruss Franz
-
Also die original Tastatur klappt auf jeden Fall (MEGA-ST Tastatur an meinem Suska Board) ebenso wie ein SM144.
Speichern auf CF Karte? Puh, das habe ich nicht ausprobiert. Ein paar von mir getestete Disketten, per USB Diskettenlaufwerk, verrichteten Ihren Dienst.
Denke das Suska könnte zu Dir passen... :-) Viel erfolg!
-
Schön mal ein Feedback :-) CF-Karten beschreiben geht natürlich auch.
-
Einen schönen guten Abend euch allen,
ich möchte kurz informieren, dass heute Nacht der Suska-IP Core in der Version 2K15A auf experiment-s.de gelegt wird. Mit dabei sind nun die diversen CPUs inklusive einer 68030 relevanten Variante. Wer mithelfen mag beim Testen oder Debuggen - sehr gerne. Über die Jahre sind so viele Module entstanden, dass ich nicht in der Lage bin die alle zu pflegen und intensiv zu testen. Ich suche hierzu kompetente Nerds. Viel Spaß mit dem Zeug und einen schönen Sommer. Mit den Cores ist nun das Tor zum Falcon offen.
Schöne Grüße
Wolfgang
-
Wäre dieser neue 680x0 auch eine Option für einen neuen Suska-Clone?
http://www.heise.de/forum/heise-online/News-Kommentare/30-Jahre-Amiga-Wir-gratulieren/neuer-680x0-Prozessor-fuer-den-Amiga-in-Entwicklung/posting-21026478/show/
-
Wäre dieser neue 680x0 auch eine Option für einen neuen Suska-Clone?
http://www.heise.de/forum/heise-online/News-Kommentare/30-Jahre-Amiga-Wir-gratulieren/neuer-680x0-Prozessor-fuer-den-Amiga-in-Entwicklung/posting-21026478/show/
Vermutlich nicht. Ich glaubs nämlich erst wenn ich ein reales Produkt sehe. Das Projekt "APOLLO CORE" sind nämlich irgendwie die Überbleibsel oder Abspaltungen vom Natami (so genau kenne ich mich da nicht aus), und das ist leider die letzte Dekade auch nichts geworden. Im Team bei uns hat auch wer gemeint, daß es sich beim Vampire lediglich um ein eingeschränktes 020er Instruktionsset handelt, mal abgesehen davon daß MMU und FPU fehlen, ...
Im Gegensatz dazu kommen von Wolfgang dauern tatsächlich auf existierender Hardware und in Freier Wildbahn lauffähige Cores und realistische Einschätzungen des Machbaren.
EDIT: es ist also eigentlich anders rum wenn ich mir das so überlege; Wolfgangs Cores wären was für deren Projekt ;)
-
Einen schönen guten Abend,
meistens ist es so wie im wirklichen Leben. Es gibt bezüglich allen möglichen Dingen Enschätzungen, Hoffnungen oder Erwartungen und Ankündigungen wie was wann wird. So auch in bezug auf diverse CPU Cores, die gerne von ganz vielen gesehen aber in der Regel von ganz wenigen entwickelt werden. Fakt ist, dass kein noch so guter Entwickler etwas über's Knie brechen und sich auch nicht über die physikalischen Gesetzmäßigkeiten hinwegsetzen kann. So betrachtet sehe ich das in etwa wie Mathias. Es ist schön, wenn was kommt. Das bedarf meines Erachtens keinen Ankündigungen, wenn es gut ist.
Der Sommer ist fortgeschritten, in sechs Wochen ist es Herbst und dann geht die Jahreszeit für IP-Cores wieder los. Und dann mal sehen wer was wann macht :-)
Grüße
Wolfgang
-
Ich kenne mich mit der FPGA-Thematik und alle dem, was dahinter steckt nicht wirklich aus. Ich bin insofern natürlich auch nur ein Anwender, der sich über das fertige Produkt freut, wenn's gut funktioniert.
Ich war nur insofern verwundert über diesen Kommentar bei heise, weil wir hier im Forum schon mal kurz darüber geschrieben hatten, was mit einem FPGA überhaupt möglich ist und ich meine, dass jemand mal meinte, dass mit dem 68030 erstmal das Ende der Fahnenstange erreicht sei, wenn man nicht einen enorm höheren Preis für ein FPGA-Board ausgeben wollte. Infolgedessen hatte mich diese Meldung, dass ein gepimpter 68060 in einem FPGA verwirklicht werden soll, schon überrascht. Das wäre dann sowas wie ein etwas besserer Milan II nach 20 Jahren. :D
Moderator-Info: Diskussion über Formfaktoren ausgelagert. Bitte hier weiterdiskutieren: http://forum.atari-home.de/index.php?topic=12147.0
-
Das MIST enthält überhaupt keinen AVR.
Hmmm. ich habe den MIST, er enthält einen AVR um die Kommunikation mit der Systemsoftware nach außen zu ermöglichen über MIniUSB.
Ich spiele mit dem MIST und dem ST-Core.
Die Hardware des ST/STE usw werden zu 99,9 % dort beschrieben durch VHDL
Für 200 Euro eine tolle Leistung.
Gruss
-
Da ist kein AVR drauf sonderrn ein Arm. Glaub's mir, ich habe das Gerät gebaut :-P
-
Also mit dem Sam-ba spiele ich die bin auf einem ARM?
Danke.
Gruss
-
Der Mist ist zwar auch nicht schlecht ....
Beim MIST musst du halt alle Geräte die nicht auf der SD-Karte dargestellt werden am USB anschließen, außer VGA-Monitor.
Ich habe dort dran:
- Tastatur
- Funkmaus (Trust)
- WLAN (DIGITUS) am D-Link DUB E-100, mit dem Programm Litchi habe ich dann Verbindung zum Notebook (FileZillaServer) und hole mir die Programme auf dem MIST vom Notebook
Wenn ich am Router gehe mit einem Netzwerkkabel, kann ich über Troll 1.8 meine Mails verwalten und bearbeiten.
- serielle Schnittstelle RS232 , mit GFA-Basic-Befehlen funktioniert der Datenaustausch sehr einfach.
Folgende Beschreibung vom ST habe ich bei mir drauf:
MegaSTE, 8 MB Speicher, 16 MHz, 2 Disklaufwerke 2,88 MB , 1x Harddisk-IMG 64 MB, 1x Harddisk-IMG 500 MB
Gruss
-
@Peter: Kannst du bitte mal versuchen, nicht alle Threads wo es um ganz andere Sachen geht, für den MiST zu kanibalisieren?
-
Einen schönen guten Abend zusammen,
ich habe schon länger nichts mehr von mir hören lassen. Das lag ganz einfach daran, dass ich sehr beschäftigt war. Nun, heute ist der Termin im Jahr, an dem ich üblicherweise meine IP-Cores veröffentliche und - so mache ich das heute auch wieder. Interessierte finden auf experiment-s wie gewohnt die Infos.
Ich wünsche euch ein schönes Fest, geruhsame Feiertage und einen guten Rutsch und noch besseren Start in 2016.
Grüße
Wolfgang
-
Super!
-
Hallo,
da mein Falcon gerade mal wieder zickt (ja, selbst Schuld, was löte ich auch rum, obwohl es läuft),
kam mir dieser Thread wieder in den Sinn.
Zur "Suska III-T2 Luxushardware" wurde erwähnt das dort "Erweiterungspins" dabei wären.
Vielleicht könnte ja eine zukünftige Platine einen Falcon-kompatiblen Erweiterungsbus bekommen,
auf die man seine ct63 samt SuperVidel und EtherNat aufstecken kann.
Also ich fände das recht sexy. Vielleicht stehe ich damit aber auch alleine da.
Ich freue mich schon auf die nächsten News zum Suska, ein sehr spannendes Projekt!
Danke!
Stefan
-
Hi Beetle,
also Deine Anregung finde ich ganz nett. Allerdings besteht der Ansatz in FPGA basierten Lösungen ja gerade darin, dass man in die Jahre gekommene Hardware einfach durch neue im Chip ersetzen kann. Ferner bedenke die Pegelproblematik. 5V TTL gibt es heute so nicht mehr. Und gerade bei schnellen Signalübertragungen würde ich Schwierigkeiten erwarten. Also ist zwar in Deinen Augen Sexy - wird's aber von meiner Seite aus nicht geben - sorry.
Grüße
Wolfgang
-
Schönen guten Abend an alle. Ich möchte heute zurückmelden bei euch. Hatte viel zu tun und daher ist die Suska etwas hintendran geblieben. Geplant sind nun:
1. GigaFile-FDD: die GigaFile mit Floppy Funktion.
Suska-III-B: nach wirklich langer Verzögerung nun in Fertigung.
Suska-III-S: das STBook-Pendant
und wenn es klappt: Suska-III-S: das Falcon-Book.
Beste Grüße
Wolfgang
-
Hallo Wolfgang,
vielen Dank für die guten Nachrichten.
Dann warte ich mal bis die III-B im Shop auftaucht.
Gibt es schon eine Preisvorstellung?
Viele Grüße
Martin
-
Hallo Wolfgang,
das sind ja spannende Neuigkeiten! Mich würden vor allem die beiden Suska-III-S-Modelle interessieren. Gibt es zu den neuen Sachen schon konkrete Informationen?
Viele Grüße,
Christian
-
Hallo Wolfgang, ich finde es toll, daß Du immer weiter machst und immer wieder mit Neuigkeiten daherkommst.
Die beiden Suska-III-S-Modelle sind für mich hochspannend und ich freue mich daher über weitere Details, wenn diese zur Verfügung stehen.
Weiter so!
-
Einen schönen guten Abend zusammen,
ich möchte mich an dieser Stelle wieder zurückmelden. 2017 war ein arbeitsreiches Jahr, dass ich so gut wie nichts an den Cores machen konnte. Das soll sich aber wieder ändern. Daher wäre die erste Aktion dieses Jahr Suska-III-B. Das Board ist schon länger fertig entwickelt und könnte produziert werden, wenn sich 10 Personen finden die Interesse haben. Das Board wird in der Form, wie auf experiment-S gezeigt, insgesamt 25 mal produziert - mehr nicht. Für mich ist immer die Schwierigkeit bei solchen Projekten, dass ich sie gerne der Öffentlichkeit zugänglich mache, allerdings keine Planungssicherheit habe. Bestimmte Teile müssen alle auf einmal beschafft werden, um die Kosten im Rahmen zu halten; das bindet aber auch Kapital. Daher gebe ich diese Info nun einmal an euch weiter. Realistisch kalkuliert strebe ich einen Bruttopreis von 222,-€ an. Als Zubehör kommt das passende Netzteil mit. Gedacht ist es natürlich als sehr kompatiber STE ohne legacy-Schnittstellen dafür mit eingebauter GigaFile.
Viele Grüße
Wolfgang
-
Hallo liebe Atari Gemeinde,
der letzte Eintrag datiert hier ja von 2018. Ich war heute bei Wolfgang Förster, danke auch für die Einladung! Die gute Nachricht: auch wenn es weder hier, noch auf der Webseite Neuigkeiten gibt, geht es weiter voran. Ich konnte mir selber ein Bild davon machen (und habe für euch auch Bilder machen dürfen).
Die Implementation des Falcon nimmt Gestalt an, im experimentellen Stadium habe ich mit auf einem Suska III C Board ein Bild davon machen können. Allerdings ist bei diesem die Hardware nicht leistungsfähig genug für eine komplette Falcon Implementierung, so laufen höhere Auflösungen mit mehr Farben nicht, da die Bandbreite nicht ausreicht.
Es befindet sich aber ein Board in Arbeit, womit die Falcon Implementierung möglich ist, in etwa so groß wie ein Bierdeckel und mit modernen Schnittstellen (PS/2 für Maus/Tastatur, USB (Treiber dafür wird es geben), HDMI
Jetzt die schlechte Nachricht:
Der Chip Mangel macht auch vor diesem Projekt nicht halt, es kann leider noch Monate dauern, bis die Hardware dann tatsächlich hergestellt werden kann. Wenn ich es richtig sehe sollte es dann aber, dank der Vorarbeit, recht schnell gehen können.
Auf der Webseite soll es bald auch ein großes Update geben, es lohnt sich also, da hin und wieder drauf zu schauen.
Grüße, Andreas
-
Und noch ein Foto mit Desktop, hat irgendwie nicht geklappt das an einen Beitrag anzuhängen
-
Sehr beeindruckend! (Und natürlich freut es mich, dass das "einzig wahre" ;) Betriebssystem darauf zu sehen ist.)
-
Das sind ja schöne News. Es wäre ja wirklich schön, wenn irdendwann etwas tolles dabei herauskommt. Es klingt jedenfalls schonmal vielversprechend.
-
Ein Auszug aus Sysinfo und ein Benchmarkergebnis wäre auch nett.
-
Das würde bei dem abgebildeten Board nicht wirklich Sinn machen, da es nicht Leistungsfähig genug ist, den Falcon voller Geschwindigkeit abzubilden, es war auch nicht dafür entwickelt, in so fern war das nur eine Demonstration, dass die Hardware so weit abgebildet ist, dass Emutos sie als Falcon erkennt.
Das neue Suska Board soll dann aber schneller sein wie das Original und auch FPU und höhere Auflösungen sind dann möglich.
-
Hi,
ich habe hier einen Prototypen von einem Vorläufer des Falcon Boards :-) und auch ein Suska-C Board.
Der erwähnte Falcon Core ist natürlich noch sehr experimentell. Emutos erkennt ihn als Falcon, d.h. er hat einen Videl. Aber TOS4 bootet leider noch nicht und auch einen DSP hat er nicht.
Auf dem Suska-C läuft ein WF68K30L (ohne Cache/MMU) - viel mehr wird mit dem Suska-C vermutlich
auch nicht mehr gehen.
Auf dem Suska-BF läuft ein WF68K30 (4K Data und 4K Instruction Cache), damit kommt es momentan fast an die Geschwindigkeit eines Falcons hin (laut GEMBENCH). Siehe das angehängte Bild
Links (Samsung) ist das BF-Board und rechts (Sun) ist das Suska-C-Board.
ciao ciao
Udo
-
Nebenbemerkung: Ich verstehe nicht, warum so viele Leute auf Gembench 6 setzen, welches der derzeitig Maintainer bekanntermaßen zurückgezogen hat:
So I have decided to no longer publicity host or offer updates to GB6. I do not want my work associated with idiots and really don't want to deal with idiots full stop.
Es gibt geeignetere Benchmarks, um die Performance eines Falcons (bzw. Falcon-Clones) zu ermitteln. Spontan fallen mir ein: Kronos. Oder CoreMark (für von CPU und RAM bestimmte "Arbeitsgeschwindigkeit") Oder NEMBENCH (wenn es sehr detailliert und technisch werden soll).
Schön hingegen finde ich, wie gut das läuft, insbesondere beim BF-Board. Die "Display"-Zahlen von GEMBENCH sind ja bedeutungslos, wenn die Referenz mit einem anderen VDI (TOS 4.04) und einer anderen Auflösung gemessen wurden. Also kann man sowieso nur auf "Integer Division", "RAM Access" und "ROM Access" gucken.
-
Ja das stimmt schon, daß die GEMBENCH Ergebnisse nicht so wertvoll sind.
Ich nehme das gerne, weil es ein rechter Härtetest ist - hat ganz schön
gedauert, bis der Wolfgang alle Problemchen entfernt hatte, damit es auf der 68k30
CPU durch gelaufen ist.
Die unterschiedliche Auflösung macht bei gleicher Farbtiefe (zumindest am Suska-Board) kaum einen Unterschied und die Falcon-Referenz ist leider mit ST-Mittel erzeugt - das sieht halt nicht so gut aus :-).
Der Coremark mit dem BF-Board -Falcon in 640x480x4:
2K performance run parameters for coremark.
CoreMark Size : 666
Total ticks : 3300
Total time (secs): 16.500000
Iterations/Sec : 6.666666
Iterations : 110
Compiler version : GCC8.2.1 20181017
Compiler flags : -O2 -mcpu=68000 -fomit-frame-pointer -DPERFORMANCE_RUN=1
Memory location : Code and data in RAM
seedcrc : 0xe9f5
- crclist : 0xe714
[0]crcmatrix : 0x1fd7
- crcstate : 0x8e3a
[0]crcfinal : 0x0134
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 6.666666 / GCC8.2.1 20181017 -O2 -mcpu=68000 -fomit-frame-pointer -DPERFORMANCE_RUN=1 / Code and data in RAM
-
Inzwischen wurden die Cores auch veröffentlicht und können unter https://download.experiment-s.de/Configware/2K21A/ runtergeladen werden. Ein Releasnot gibt es hier zu finden: https://download.experiment-s.de/Configware/releasenotes.txt
-
@mcknopf und @udo, danke fürs posten. Die Desktop's sehen schon atarilike aus... und natürlich auch vielen vielen Dank an @wfoerster für die viele Arbeit an den Core's.
-
Einen schönen guten Abend an alle,
ich war schon ein paar Jahre nicht mehr hier und wollte kurz informieren: Udo und ich arbeiten seit vielen Jahren zusammen und heraus gekommen ist das, was ihr auf experiment-S im Downloadbereich findet. Mittlerweile ist der Falcon Core recht stabil und auch die 68K30 läuft soweit schon ganz gut. Allerdings hat sich über die Jahre einiges an der Peripherie verändert. Die originalen Atari Festplatten sterben so langsam aus, PS/2 Mäuse und Tastaturen sind obsolet und auch die gute alte VGA-Schnittstelle ist nicht mehr aktuell. Daher geht es nun in der Richtung weiter, dass wir an unsere Testsysteme USB Maus und - Tastatur anschließen können und auch Displayport oder HDMI ist angedacht (am liebsten gleich über USB-C). Udo und ich haben jeweils die gleiche Ausrüstung. Wir testen auf Suska-III-C und es gibt auch zwei Suska-III-BF. Letzteres Board ist ungefähr so groß wie ein Biedeckel kommt aber mit einem sehr üppig ausgestatteten FPGA. Darin passen neben dem Falcon auch die 68030 und auch der DSP und der Floating Point Coprozessor. Letztere beiden sind allerdings noch in einem frühen Entwicklungsstadium. Suska-III-BF hat allerdings immer noch PS/2 und VGA. Deshalb ist auch die Entwicklung weiterer Boards in Arbeit. Ein Suska-III-F welches noch etwas leistungsfähiger ist und dann USB und eine moderne Video-Schnittstelle mitbringt. Leider haben wir gerade eine dicke Chipkrise und es ist nicht möglich diese Boards momentan zu realisieren (es gibt am Markt keine FPGAs). Wenn sich das mal wieder ändern sollte - ich gehe von 2023 aus - dann werden die Cores wohl auch soweit sein. Der Falcon-Core auf experiment-S ist übrigens durchweg mit 32 Bit Datenbus ausgestattet (auch der Blitter) und verfügt über ALTRAM (momentan 48MB auf unserer Hardware). Es geht also voran...
Herzliche Grüße
Wolfgang
-
@wfoerster ganz lieben Dank für das ausführliche Update. Das sind ja tolle Aussichten!
-
@wfoerster, das hört sich wirklich sehr spannend an und gerade einen modernen Monitoranschluss halte ich für sehr sinnvoll da ich mich langsam von meinen alten Röhren SMxxx, soweit möglich, verabschieden möchte. Die Chipkrise ist natürlich zum Teil hausgemacht... doch das ist ein eigenes Thema. Bin gespannt wann der kraftstrotzende USB-Falcon zu seinem ersten Flug abheben wird. :)
-
Danke @wfoerster für die Information! Das klingt durchaus sehr spannend, v.a. die 32 Bit Busbreite und AltRAM :)
Aber immer wenn sich ein Entwickler aus der Deckung wagt kommen wieder die Anwender – ginge nicht noch … eine Crypto-Engine o.ä. um TLS „in Hardware“ zu machen, damit man mit dem Atari auch nach draußen sprechen kann (IMAPS/POPS/SMTPS/IRCS/HTTPS …). Idealerweise so, dass man es mit anderer Hardware aber gleicher Schnittstelle auch nutzen kann, die Kolleg*innen nebenan am RaSCSI-Projekt (Ethernet via SCSI am Mac & Atari, durch einen Raspberry Pi) überlegen ob man das nicht dem Raspi aufbürden kann, der dann als "externer Krypto-Chip" angesprochen wird.
-
Ob's vor Weihnachten noch News gibt? :D
-
Einen schönen guten Abend in die Runde,
also um es momentan auf den Punkt zu bringen: Intel, Lattice, Xilinx und Microsemi haben offensichtlich gerade Lieferprobleme. Deshalb gibt's momentan im Shop bei un eigentlich nix und wir verharren der Dinge. Heißt aber nicht, dass wir nicht aktiv sind. Nur: wenn Anwenderwünsche kommen verstopft das gerne den 'Workflow'. Wir arbeiten gerade an DSP und FPU. Und die anderen Codes sind weitgehend open source für Anwender, die sich was wünschen :-)
Herzliche Grüße
Wolfgang