Inzwischen weiss ich nicht mehr ob man "ich" oder "AI" sagen muss wenn man mit AI arbeitet aber jedenfalls habe ich die Richtung vorgegeben: https://l8hdl.de/proj_cpu/ Eine Implementation der grösseren ISAs . Der "Höhepunkt" in dieser Übung war vielleicht Win98 auf einem FPGA zu booten.
Da könnte man noch etwas mehr zu schreiben. Was z.B. geht mit Win98? Cool finde ich, dass es auf dem ARTY zu laufen scheint, weil ich das auch nutze. Ich weiß aber um dessen Leistungsfähigkeit und frage mich, ob man da auch was Ernsthaftes drauf laufen lassen kann.
Konkret hätte ich da nämlich einige alte Audio-Driver und VSTs, sowie die alten Steinberg-Audioprogramme.
Man könnte / müsste nun eruieren, inwieweit man das z.B. auf eine allgemeine PC-ähnliche Plattform portieren kann, um die Peripherie zu nutzen. Dann würde das ernsthaft verwendbar sein. CPU-Emulationen haben wir ja ansonsten mehr als Sand am Meer.
Interessant wäre z.B. der MEGA65. Der hat einen 200er Artix drin, in dem man eine CPU wrappen könnte. Dann stünden auch Festplatte, IO-Controller und vieles mehr zur Verfügung.
:
Bearbeitet durch User
So richtig verwendbar ist es leider nicht. Der Mauszeiger ruckelt mit 1 FPS umher... obwohl man vielleicht noch optimieren koennte und es vielleicht ein bischen fluessiger hinbeköme. z.b. iexplorer und command.exe starten. Auserdem hast du einen kleinen Softice client (wenn du ctrl-D drueckst erscheint ein Debuggerfenster) Abes es reicht mir soweit, Mit vollständigem wim98 boot glaube ich kann ich sagen ich implementiere den 80386 Befehlsatz. Komisch dass VST erwähnt wird. Ein nächstes Experiment will ich in der Richtung machen... ich poste es dann auf der Seite
Schon irgendwie krass, vor paar Jahren wäre das noch absolut SciFi gewesen.
Einzig die AI kennt noch nicht die Tricks vom Intel/AMD um x86/64 zu RISCen, bzw für den Speed-Boost von 20 MHz auf paar GHz, bzw der FPGA ist zu klein dafür
Schon irgendwie krass, vor paar Jahren wäre das noch absolut SciFi gewesen.
Nö, diese verschiedenen CPU-Implementierungen auf FPGA gibt es schon seit Jahren, man musste sich nur über den aktuellen Stand der Archive auf opencores.org resp. der einzelnen FPGA-Hersteller informieren. Die KI implemetiert dir das nicht wirklich, die tüdelt lediglich zusammen was sie im Internet findet (und dabei ist ihr wohl egal ob "Open source" oder restricted by licence).
Die KI "bastelt" dem User auch eine auf eine doom version für oscilloscope - weil das vor Jahren ein gelangweilter Programmierer veröffentlichte.
So richtig verwendbar ist es leider nicht. Der Mauszeiger ruckelt mit 1 FPS umher... obwohl man vielleicht noch > optimieren koennte und es vielleicht ein bischen fluessiger hinbeköme.
Naja, welches Potential hat den die benutzte platform, kann man das realistisch abschätzen ? Das board hat einen Artix-100 und 256MB lowpower DDR3, der Monitor ist über ein VGA-PMOD angeschlossen (max. resolution ist deshalb eher geringe 768x1024 oder ?).
Welcher Aufwand ist es das ganze für einen üblichen Monitor an Displayport mit 2k resolution (bspw 1920x1080) hinzuschneidern ? Interessanter ware eine Implementierung auf einem zeitgenössischen board mit ZYNQ US+ und >1GB DDR. Sowas gibt es im selben Preisbereich wie das Arty, bspw als TE0802 .
:
Bearbeitet durch User
Nö, diese verschiedenen CPU-Implementierungen auf FPGA gibt es schon seit Jahren, man musste sich nur über den aktuellen Stand der Archive auf opencores.org resp. der einzelnen FPGA-Hersteller informieren. Die KI implemetiert dir das nicht wirklich, die tüdelt lediglich zusammen was sie im Internet findet (und dabei ist ihr wohl egal ob "Open source" oder restricted by licence).
Zustimmung zu letzterem, OpenSource ist schon eine Weile ad absurdum, ersteres: eher nein, denn clevere microcoded-Ansaetze findet man seltenst in freier Wildbahn, und schon gar nicht bei OpenCores. Und was die Hersteller so anbieten hinkt deutlich dem Stand der Innovation hinterher (das glaube ich kann der TE ganz gut einschaetzen). Manche Modelle sind da schon sehr innovativ, wenn man sie gut trainiert. Interessant waere bei dem Projekt noch, ob Claude mal eben eine optimierte CXXRTL-Variante davon baut, und wie schnell sie laeuft. Plus, wie es dann mit den Regressions-Tests (GCC et al) aussieht.
Ich bekomme bald ein Enclustra KX2 board. Mit dem kann ich vielleicht die "Tricks" von Intel/AMD implementieren, aka, Superscalar und auf 64 bit erweitern :-) und die pipeleine zerstueckeln. .
Artix-100 und 256MB lowpower DDR3 ... ... max. resolution ist deshalb eher geringe 768x1024 oder ?
Man kann durchaus 1920x1080 p60 machen. Das hier ist sogar das Arty: https://www.mikrocontroller.net/articles/Projekt_VGA_Core_in_VHDL#Eingebautes_virtuelles_Oszilloskop
Es belegt, so wie ich es dort verwende, etwa 1/6 des FPGAs, besonders die Blockrams. Das kann man noch etwas reduzieren, aber eine vollwertige VGA-Grafik wird den Speicher vollmachen, sodaß kaum was über bleibt.
Einen PC-Prozessor im FPGA zu emulieren, ist reichlich müßig - schon die MM-Extensions der 1990er Jahre auf einem 166MHz AMD sind kaum hinzubekommen. Ich hatte mich damals mit den AMD-spezifischen Optimierungen befasst. Deshalb stutze ich auch, als da nun plötzlich Win98 bootet.
Wenn man realistisch ist, kann man einen DX66 mit Win31 in einen FPGA packen, sammt COPRO-Funktionen und den entsprechenden Speicher. OB sich das rechnet, ist eine andere Frage.
Ich hatte das vor etwa 15 Jahren mal diskutiert, weil ein Kunde von mir etliche Maschinensteuerungen noch auf Win3.1 hatte und auf XP umstellen wollte und man sich die Frage stellte, ob und wie man das in HW gießen könnte. Der Vorschlag war Xilinx + Power PC. Es war ihnen dann aber zu heiß und es lief auf wxWidgets mit einen CE hinaus, das am Ende auf Linux ging. Inzwischen ist es embedded Linux. Gfs sollte man mal wieder anfragen, ob sie einen Zynq haben mögen. :-) Oder man fragt die deutsche Bahn: Da geht ja noch Vieles mit Win3.1 wie man kürzlich erfahrnen konnte. :D.
Ich glaube, dass man mit einem Win98 Emulator auf PC-Basis mehr Chancen hat.
Sowas gibt es im selben Preisbereich wie das Arty, bspw als TE0802 .
Wundersamerweise ist das richtig - das TE0802 ist aktuell kaum teuer, als das ARTY, obwohl technisch besser und hat ja obendrein noch die ARM Cores. Allerdings bekommt man auch mit denen nicht die Performance eines PCs der 2000er Jahre. 1GHz@PC-CPU != 1GHz beim ARM.
Was so richtig gut brummt, ist die C64-Architektur auf dem Artix 200 im MEGA.
Artix-100 und 256MB lowpower DDR3 ... ... max. resolution ist deshalb eher geringe >>768x1024 oder ?
Man kann durchaus 1920x1080 p60 machen. Das hier ist sogar das Arty: https://www.mikrocontroller.net/articles /Projekt_VGA_Core_in_VHDL#Eingebautes_virtuelles_Oszilloskop
Die Frage ist, welche Auflösung derjenige hat, der hier von Mauszeiger 1 fps berichtet. Bei dem Scope-beispiel wäre interessant die Größe/Organisation des Bildspeichers zu kennen, bei dem Sonderfall Oszilloskop (einzelne Linie pro Kanal) kommt man u.U. ohne groß Bildspeicher für das Pixel-array aus.
aber eine vollwertige VGA-Grafik wird den Speicher vollmachen, sodaß kaum was über bleibt.
Sehe ich auch so, da braucht man externen RAM und dann ist die Frage, ob die Bandbreite für alle Memory-ports reicht. VGA wären lediglich 320x200x8bit als 64 kbyte aber schon das ist für internen BRAM schon ein Brocken, bei einigen modernen FPGA Familien wie Spartan US+ hat man größere URAM-Blöcke neben den BRAM eingeführt, die könnte man sich mal anschauen.
Gfs sollte man mal wieder anfragen, ob sie einen Zynq haben mögen. :-)
Nicht nur "fragen" sondern unbeirrt "empfehlen", auch wenn man dann ARM-binaries braucht, was dann IMHO die Migration von Windows zur Linux "erzwingt." Oder ist "Windows auf ARM" inzwischen einsatzbereite Realität geworden?
Die Auflösung in Win98 ist: 640x480 mit 16 Farben. Pixelclk ist 27.08 MHz.
Die 1 fps haben nichts mit VGA zu tun, ich meinte damit 1 fps Mausbewegung. Der VGA Screen läuft mit 64.5 Hz Hz. Die CPU läuft zu langsam für Win98.
Auch wenn ich schreibe "unbrauchbar" kann man trotzdem navigieren wenn man
Geduld hat.
Wenn du ein Arty T100 Board hast einfach ausprobieren...
Sdcard und VGA pmod Erweiterungen sind optional.
Das Win98 System hat einen HW basierten Ethernet
UDP debug port. Damit kann man die internet Busfabrik erreichen.
Die SDcard Bloecke (als PCI IDE device) werden, wenn man es beim Start
so angibt, vom Host aus zum Target gestreamt (so-simulation, wenn man keine sdcard
PMod Erweiterung hat).
Beim Start wird sowieso ein Ascii Art Bildschirm gestartet (ctrl-g startet
die PixelGui im Browser). Ich lese den Framebuffer (blockram) kontinuierlich
vom Host aus und zeige ihn auf der Hostseite an. Ein VGA Monitor oder die PMod Erweiterungskarte brauchst du deshalb nicht. Maus und Keyboard sind auch
co-simuliert (man verwendet die Maus und Keyboard vom Host).
:
Bearbeitet durch User
Grösse der RAMs ... Bei dem Sonderfall Oszilloskop (einzelne Linie pro Kanal) kommt man u.U. ohne groß Bildspeicher für das Pixel-array aus.
Richtig, meine OSC-APP nutzt keinen Bildspeicher, sondern zeichnet beim Bildaufbau. Das BRAM ist an der Videoaufzeichnung orientiert und hat folglich 1920 speicherstellen von 2048 in 18 Bit, in die die eingehenden Daten direkt eingesampelt werden.
Mein Hinweis diente mithin auch nur dazu, zu verdeutlichen, dass man in der Tat mit dem genannten Arty die gewünschen 1920 packt- zumindest die Signalqualität als solche. Großer Bildschirmspeicher ist halt nicht. Von daher wird es problematisch, da mehr abzubilden, als Heimcomputer-Anwendungen, oder proprietäre Ausgaben. Einen Text- und Grafikspeicher habe ich allerdings auch (siehe die Bilder auf der Seite weiter oben) und einen Texteditor mit Grafik für eine GUI bekäme man locker hin. Aufwändige Sachen mit Speicherung sind halt umständlich und platzfressend, ohne zumindest einen Microblaze. Von daher bin ich ganz klar bei einem käuflichen System, also einer Plattform, die sich jeder besorgen kann und die verfügbar und gut einsetzbar ist, wie dem MEGA 65 - wenn da was gemacht werden soll.
Das Videotiming als Solches ist mit kleinen FPGAs aber kein Problem: Da ist sogar mit einem Spartan 6 gemacht. Ist auch eines von Trenz. Taktfrequenz Videobereich des FPGA 148.5 MHz.
VGA wären lediglich 320x200x8bit als 64 kbyte aber schon das ist für internen BRAM schon ein Brocken,
Man könnte die 8 bit in 32 verpacken und hätte dann 16 BRAMs. Kein Problem. Ist aber eben nur C64 :-) Wenn man PC-ähnlich arbeiten will sind 1024x768 Plicht. Das sind 192 BRAM, also 2/3 eines 200er Artix. Da dann eher DDR3.
:
Bearbeitet durch User
Die Auflösung in Win98 ist: 640x480 mit 16 Farben. Pixelclk ist 27.08 MHz. Die 1 fps haben nichts mit VGA zu tun, ich meinte damit 1 fps Mausbewegung. Der VGA Screen läuft mit 64.5 Hz Hz.
Danke für die nachgereichten Details, damit kann man besser "den Flaschenhals" erkennen. Wenn es nur das Refresh der Mouseposition ist, liegt es wohl eher an der Emulation der Mouseroutinen. Heutzutage will man ja Mäuse mit Polling rate 8000 Hz verkaufen, hab da Testberichte gelesen ... IMHO reicht bei der Position eine Abtastrate zwischen 10 und 100 Hz völlig, auch bei CAD.
Wenn du ein Arty T100 Board hast einfach ausprobieren...
Ich wollt mir schon vor 6 Jahren ein Artix-Board zulegen, hab mich dann doch für Zynq-s entschieden (Zybo, Red, Pittaya, ...) weil in der Industriepraxis gerne eingesetzt. Was an reinem FPGA-Teil anzutesten ist, muss dann eben in den PL-Teil passen oder wird auf einem Spartan-Board getestet, von dem "hier" mehrere rumliegen. x86 auf FPGA interessiert mich nicht wirklich, eher schon die Prozessoren die man heute kaum noch kaufen kann (68k etc.) .
mehrere rumliegen. x86 auf FPGA interessiert mich nicht wirklich, eher schon die Prozessoren die man heute kaum noch kaufen kann (68k etc.) .
Versuche es doch auch mal mit AI. Ich glaube wenn du eine Referenzplatform für 68k, z.B. einen Simulator, angeben kannst ist das eine Sache von wenigen Stunden. Wuerde mich eigentlich interessieren ob es nun meine Vorgehensweise ist die besonders ist oder ob absolut alle dasselbe erreichen. Selber habe ich 68k schon ausprobiert. Dann habe ich aber gemerkt dass ich dass nur aus Amiga Nostalgie mache und es da sehr viele gibt die das gleiche schon mal gemacht haben. Man könnte den Paula chip nachbauen aber die Wahrheit ist, dass der Amiga-sound furchtbar war :-) .
:
Bearbeitet durch User
Man könnte den Paula chip nachbauen aber die Wahrheit ist, dass der Amiga-sound furchtbar war :-) .
Kommt drauf an, wie man ihn programmiert und nutzt. Und Paula wurde bereits nachgebaut - jedenfalls, was die Tonausausgabe angeht. :-)
hab mich dann doch für Zynq-s entschieden
Das ist was für Leichtbau-FPGA-Entwickler. ARMs verleiten nur dazu, in C zu arbeiten. Das ist was für Weicheier :-)
Und Paula wurde bereits nachgebaut - jedenfalls, was die Tonausausgabe angeht. :-)
Auch hinsichtlich des digitalen Interfaces wurde "Paula" resp. MOSTEK MOS 8364R7 bereits 2005 in einem Xilinx Spartan 3 implementiert. Aber das ist wohl eher etwas für einen anderen thread.
Das ist was für Leichtbau-FPGA-Entwickler. ARMs verleiten nur dazu, in C zu arbeiten. Das ist was für Weicheier > :-)
Hehe, das trifft hier nicht zu, bei mir liegt eher der C-programmierbare Teil brach. Und Leichtbau wird's auch bei Artix wenn man die fertigen AXI-Module aus der IP-Lib nur zusammenstöpselt.
Und Paula wurde bereits nachgebaut - jedenfalls, was die
Tonausausgabe
angeht. :-)
Jetzt gibt eine zusätzliche Version: https://l8hdl.de/proj_soundtracker/ Als ROM gespeicherte Soundtracker mod. Kommt als 22.05k 2ch 16le am uart port heraus.Abgespielt mit Protracker HSync Interruptroutine so wie es sich gehört :-) . "btst #6,$BFE001" habe ich noch im Muskelgedächtnis.
:
Bearbeitet durch User
Konkret hätte ich da nämlich einige alte Audio-Driver und VSTs, sowie die alten Steinberg-Audioprogramme.
Hier habe ich https://l8hdl.de/proj_soundtracker/ aufgeladen. Soundtracker auf dem ArtyT100 mit quasi-Steinberg Effekten.
Auch hinsichtlich des digitalen Interfaces wurde "Paula" resp. MOSTEK MOS 8364R7 bereits 2005 in einem Xilinx Spartan 3 implementiert.
Ja, nur gelingt die Emulation eines digitalen Teils meistens perfekt, während der Analogteil (und diese Chips haben praktisch immer viel davon) meistens kaum gut getroffen ist.
Ich wollte mithin auch nur der Position entgegentreten, dass die Musik damit "grauenhaft" sei: Hier die Paula in Aktion: https://www.facebook.com/reel/1856116858963597
während der Analogteil (und diese Chips haben praktisch immer viel davon) meistens kaum gut getroffen ist.
Also meines Wissens hat Paula im Vergleich zum SID kaum/keine Analog-Anteile. Aber Analoges wie ein (abschaltbares) TP-Filter aus OPA war auf dem AMIGA-motherboard, das muss man halt so analog nachbauen. Wobei man sich da nicht an CDTV orientieren sollte, weil der mehr Schaltungstechnik enthält als der A500 von dem er abstammt, weil das CDTV auch noch Audio-CD's abspielen sollte.
:
Bearbeitet durch User
Naja, jeder DAC hat seine eigene Characteristik und solange die mit einer genügend geringen = unzureichend hohen Frequenz betrieben werden, ist der äußerst relevant. Da spielen die Überschwinger im Grenzbereich eine wesentliche Rolle. Das ist das erste, was man modellieren muss. Das machen z.B. die meisten Emulatoren und Nachbauten von Analog-Equiment nicht.
:
Bearbeitet durch User
Inzwischen weiss ich nicht mehr ob man "ich" oder "AI" sagen muss wenn man mit AI arbeitet aber jedenfalls habe ich die Richtung vorgegeben: https://l8hdl.de/proj_cpu/
warum gzip und nicht in GitHub?
warum gzip und nicht in GitHub?
weil alle aud github sind.