68K30L, Falcon und Suska-III-T2

[1ST1]

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?

[atari-inside]

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]

... MIST zu einem stattlichen Teil auf AVR Software basierend ...

Das MIST enthält überhaupt keinen AVR.

Laut http://shop.inventronik.de/store/1 enthält Suska aber gleich drei AVRs.

[MiST]

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)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 ...

[1ST1]

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?

[MiST]

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

[wfoerster]

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

[wfoerster]

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

[Arthur]

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. 

[wfoerster]

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

[Arthur]

Danke für die interessanten News

[tost40]

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

[Arthur]

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.  Das lass ich aber besser bleiben sonst must Du jemanden einstellen der solange deinen Job macht.

[wfoerster]

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

[1ST1]

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...

[tost40]

Hallo Wolfgang,

vielen Dank fuer Deine ausführliche Antwort.

Gruß Martin

[wfoerster]

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...

[wfoerster]

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

[Nervengift]

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.

[wfoerster]

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