atari-home.de - Foren
Hardware => Firebee => Thema gestartet von: mfro am Mo 04.05.2020, 21:46:25
-
nur mal so: fVDI "Coldfire native" auf der FireBee (EmuTOS + MiNT), also ohne Emulation/cf68klib.
Sozusagen ein "Corona-Produkt".
Und ein XaAES-Snapshot-Programm gab's auch gleich (habe kein Coldfire-native Programm gefunden, also hab' ich selbst eins geschrieben).
-
Großartig, danke! (und auch für richtige Screenshots, und nicht dieses Handyge****el)!
-
Finde ich auch sehr interessant auch wenn ich keine Firebee besitze. Hat sich dadurch auch die Geschwindigkeit erhöht?
-
Finde ich auch sehr interessant auch wenn ich keine Firebee besitze. Hat sich dadurch auch die Geschwindigkeit erhöht?
Das hat erstmal dazu geführt, dass fVDI in der (dieser meiner bevorzugten) Kombination überhaupt lauffähig ist ;). Sicherlich wird fVDI dadurch auch schneller, aber das kann niemand wirklich messen (die fVDI-Konfiguration von FireTOS ist bezüglich Farbtiefe und Auflösung nicht vergleichbar). Ich würde aber schätzen, dass die Geschwindigkeit dadurch deutlich zugenommen haben müsste, weil in der cf68klib sämtliche inkompatiblen Befehle auf "langsame" Exceptions auflaufen.
"Gefühlt" läuft es jedenfalls ziemlich flott (was bei 640x480x4 für einen 233 MHz-Coldfire aber auch kein Problem sein sollte).
fVDI besteht zum grössten Teil aus Assembler-Quellen. Dazu kommt, dass fVDI an vielen Stellen durch Wort-Operationen praktisch die Anzahl der Datenregister verdoppelt (indem es beide Registerhälften wortweise verwendet und bei Bedarf swap-ped). Beim ColdFire gehen viele arithmetische Operationen nur langwortweise (und würden "die andere Registerhälfte" potentiell zerstören).
Ohne PortAsm (das m68k Assembler-Quellcode in Coldfire-Assembler-Quellcode übersetzt) wäre eine solche Übersetzung praktisch auf Neuschreiben (= unrealistisch) hinausgelaufen.
-
Das
Ich würde aber schätzen, dass die Geschwindigkeit dadurch deutlich zugenommen haben müsste, weil in der cf68klib sämtliche inkompatiblen Befehle auf "langsame" Exceptions auflaufen.
"Gefühlt" läuft es jedenfalls ziemlich flott (was bei 640x480x4 für einen 233 MHz-Coldfire aber auch kein Problem sein sollte).
fVDI besteht zum grössten Teil aus Assembler-Quellen. Dazu kommt, dass fVDI an vielen Stellen durch Wort-Operationen praktisch die Anzahl der Datenregister verdoppelt (indem es beide Registerhälften wortweise verwendet und bei Bedarf swap-ped). Beim ColdFire gehen viele arithmetische Operationen nur langwortweise (und würden "die andere Registerhälfte" potentiell zerstören).
Danke für den Einblick.
Ohne PortAsm (das m68k Assembler-Quellcode in Coldfire-Assembler-Quellcode übersetzt) wäre eine solche Übersetzung praktisch auf Neuschreiben (= unrealistisch) hinausgelaufen.
Aber immer noch reichlich aufwändig, oder?
-
Aber immer noch reichlich aufwändig, oder?
Wie gesagt, ohne Corona würde es das nicht (oder zumindest noch nicht) geben.
-
Du kannst dich ja mit @Thorsten Otto austauschen, er hat in fVDI schonmal einiges an Zeit für die Vampire Investiert, vielleicht kann die Firebee davon Profitieren ?
-
weiss er ;) Bin gerade dabei das alles wieder zusammen zu schrauben.
BTW: hab ihn auch darauf aufmerksam gemacht, daß es schon ein snapshot-programm für die FireBee gibt, falls jemand sowas sucht: http://tho-otto.de/sharedlibs.php
-
Das klingt doch nach einem echt super Fortschritt.
Das original VDI der FireBee scheint ja closed source zu sein und bietet die Basis, aber hiermit ist der Weg frei für erweiterte Features.
Bringt EmuTOS nicht auch ein eigenes, open source VDI mit?
Die Veröffentlichung von Magic hat noch ein weiteres open source VDI mit sich gebracht.
Leider haben offscreen Bitmaps mit fVDI innerhalb von Aranym bei mir nie funktioniert. Ein blit auf den screen hat immer garbage oder mindestens Fehlfarben erzeugt. Es wäre interessant zu wissen, ob so Etwas, mit einem Tool wie Enhancer, nun auf der FireBee reibungslos funktionieren.
-
Das original VDI der FireBee scheint ja closed source zu sein
Bringt EmuTOS nicht auch ein eigenes, open source VDI mit?
Ja schon, das beinhaltet aber kein GDOS.
Die Veröffentlichung von Magic hat noch ein weiteres open source VDI mit sich gebracht.
Theoretisch schon. Praktisch lässt sich davon aber für andere Projekte nur wenig gebrauchen.
Leider haben offscreen Bitmaps mit fVDI innerhalb von Aranym bei mir nie funktioniert.
Ich hab's glaube ich noch nie verwendet. Hast du da Beispiel oder Testprogamme? Ein Problem könnte sein, daß fVDI monochrome bitmap nicht korrekt unterstützt, was eigentlich nach der Spezifikation eigentlich immer gehen sollte.
mit einem Tool wie Enhancer, nun auf der FireBee reibungslos funktionieren.
Da sowohl Enhancer als auch fVDI v_opnbm() unterstützen, würde das vermutlich Chaos geben. Enhancer macht auch nichts, wenn schon ein _FSM cookie vorhanden ist. Und beide würden einen EdDI Cookie anlegen, das gibt noch mehr Chaos. Besser wäre es also, v_opnbm() in fVDI funktionsfähig zu machen ;)
-
Das klingt doch nach einem echt super Fortschritt.
Das original VDI der FireBee scheint ja closed source zu sein und bietet die Basis, aber hiermit ist der Weg frei für erweiterte Features.
Das "original VDI" der FireBee ist fVDI. Allerdings eine andere (wohl neuere) Version als die, die JK als OpenSource freigegeben hat, mit Treibern, die dort nicht dabei sind und mit etlichen Erweiterungen von Didier Méquignon.
Bislang läuft - mit dem "neuen, alten fVDI" auf der FireBee lediglich der bitplane.sys Treiber (also bis zu 256 Farben). Ein Treiber, der die erweiterten FPGA Modi nutzen soll, ist in Arbeit (aber erzeugt bislang nur Pixelmüll und Abstürze), da ist noch ein weiter Weg zu gehen.
Bringt EmuTOS nicht auch ein eigenes, open source VDI mit?
Tatsächlich ist in fVDI schon einiges drin, was ursprünglich aus EmuTOS (bzw. den Caldera-Quellen) stammt.
Leider haben offscreen Bitmaps mit fVDI innerhalb von Aranym bei mir nie funktioniert. Ein blit auf den screen hat immer garbage oder mindestens Fehlfarben erzeugt. Es wäre interessant zu wissen, ob so Etwas, mit einem Tool wie Enhancer, nun auf der FireBee reibungslos funktionieren.
Ich muss gestehen, ich habe nicht die leiseste Ahnung, op v_opnbm() und Konsorten auf "unserem" fVDI überhaupt funktionieren. Muss ich bei Gelegenheit mal ausprobieren.
-
Das "original VDI" der FireBee ist fVDI. Allerdings eine andere (wohl neuere) Version als die, die JK als OpenSource freigegeben hat, mit Treibern, die dort nicht dabei sind und mit etlichen Erweiterungen von Didier Méquignon.
Unter welcher Lizenz steht denn fVDI? Das, das ich auf Sourceforge finde, sagt "GPLv2".
-
Please, note that not everything in this repository is necessarily
GPLed at the moment. Most notably, the RageII stuff, which still
relies on some files from ATI which are not under the GPL (unless you
have been given a priviledged user name, you will not be able to
access the RageII files, anyway). In general, consider anything that
does not have an explicit GPL notice to _not_ be GPLed.
In many cases, even things without the notice should really have one.
Until you have checked with me, consider them to be under a normal
copyright, however, and thus not to be modified, used or distributed
without permission.
Im wesentlichen dürfte das wohl heissen, daß die meisten Sachen PD sind seitdem er sie öffentlich gemacht hat. Dh. daß Didier damit machen konnte, was er wollte, und auch nicht verpflichtet ist die veränderten Sachen wieder zu veröffentlichen. Ich gehe auch mal davon aus, daß er sich die entsprechende Erlaubnis zur Verwendung geholt hat.
-
Ich muss gestehen, ich habe nicht die leiseste Ahnung, op v_opnbm() und Konsorten auf "unserem" fVDI überhaupt funktionieren. Muss ich bei Gelegenheit mal ausprobieren.
Wenn ich mir https://github.com/freemint/fvdi/blob/823bc66f0a609934b66cd1b2d3372f61bfc411cc/fvdi/engine/workstn.c#L321 anschaue kann das eigentlich noch nie funktioniert haben. Da werden die gerade mühselig gemachten Einstellungen der bitmap mit Default-Werten vom Bildschirm überschrieben, inklusive der bitmap-Addresse.
Denke da ist noch einiges zu tuen...
-
Please, note that not everything in this repository is necessarily
GPLed at the moment. Most notably, the RageII stuff, which still
relies on some files from ATI which are not under the GPL (unless you
have been given a priviledged user name, you will not be able to
access the RageII files, anyway). In general, consider anything that
does not have an explicit GPL notice to _not_ be GPLed.
In many cases, even things without the notice should really have one.
Until you have checked with me, consider them to be under a normal
copyright, however, and thus not to be modified, used or distributed
without permission.
Im wesentlichen dürfte das wohl heissen, daß die meisten Sachen PD sind seitdem er sie öffentlich gemacht hat. Dh. daß Didier damit machen konnte, was er wollte, und auch nicht verpflichtet ist die veränderten Sachen wieder zu veröffentlichen. Ich gehe auch mal davon aus, daß er sich die entsprechende Erlaubnis zur Verwendung geholt hat.
Wenn letzteres, dann ist ja alles gut.
Von „Public Domain“ steht oben nichts, im Gegenteil, sondern von Nutzungsrecht/Urheberschaft (je nach Rechtsraum auch „Copyright“) und vorher fragen.
-
So wie ich das verstanden habe, bezogen sich die Kommentare auf die Version bevor es überhaupt öffentlich gemacht wurde. Ansonsten dürften wir fVDI ja überhaupt nicht verbreiten und/oder benutzen.
-
So wie ich das verstanden habe, bezogen sich die Kommentare auf die Version bevor es überhaupt öffentlich gemacht wurde. Ansonsten dürften wir fVDI ja überhaupt nicht verbreiten und/oder benutzen.
Ich guck da jetzt nicht genauer hin …
-
Ich guck da jetzt nicht genauer hin …
Denke zwar nicht, daß es da wirklich ein Problem gibt, aber vlt. sollte man das wirklich mal klären. Wo findest du denn Hinweise zu GPLv2? Sehe da weder auf SF noch auf github was.
-
Denke zwar nicht, daß es da wirklich ein Problem gibt, aber vlt. sollte man das wirklich mal klären. Wo findest du denn Hinweise zu GPLv2? Sehe da weder auf SF noch auf github was.
https://sourceforge.net/projects/fvdi/ --> "License: GNU General Public License version 2.0 (GPLv2)"
https://sourceforge.net/p/fvdi/code/HEAD/tree/trunk/fvdi/readme.now ->
IMPORTANT
=========
Please, note that not everything in this repository is necessarily
GPLed at the moment. Most notably, the RageII stuff, which still
relies on some files from ATI which are not under the GPL (unless you
have been given a priviledged user name, you will not be able to
access the RageII files, anyway). In general, consider anything that
does not have an explicit GPL notice to _not_ be GPLed.
In many cases, even things without the notice should really have one.
Until you have checked with me, consider them to be under a normal
copyright, however, and thus not to be modified, used or distributed
without permission.
I will get all the appropriate copyright notices in there eventually.
Somit bräuchte es eine Erklärung vom Originalautor, da er ja größtenteils keine gegeben hat, und sagt dass es unter Copryright, außer man fragt an.
-
Das ist eigentlich relativ einfach erklärt, der ATI Treiber wurde für die Eclipse Grafikkarte für den Falcon ausgelierfert und dieser war Closed source soweit ich das in Erinnerung habe, deswegen gibt es für diesen Treiber auch nirgends die Sourcen. Dann kommt noch der Teil der Truetype fonts hinzu, die muss man sich ja auch explizit laden und einbauen. Oder hab ich irgendwas komplett durcheinander gebracht ?
-
In many cases, even things without the notice should really have one.
Until you have checked with me, consider them to be under a normal
copyright, however, and thus not to be modified, used or distributed
without permission.
I will get all the appropriate copyright notices in there eventually.
Somit bräuchte es eine Erklärung vom Originalautor, da er ja größtenteils keine gegeben hat, und sagt dass es unter Copryright, außer man fragt an.
Der Text stammt (wie man sich mit Hilfe anderer READMEs zusammenreimen kann) von Johan Klockars' originalem cvs-Archiv, das einen öffentlichen sowie anscheinend mehrere private Zugänge hatte.
So, wie ich das interpretiere, war der "öffentliche" Teil der Open Source Teil und der Text ist als Warnung an diejenigen mit "privatem" Zugang zu verstehen, die öffentlich nicht sichtbaren Teile (namentlich wohl den ATI-Treiber) nicht zu verbreiten, weil mit Copyright bzw. NDA versehen. Die Quellen, die jetzt vorliegen, enthalten vom "privaten" Umfang nichts.
Daraus jetzt das Verständnis abzuleiten, dass alles mit Copyright belegt wäre, funktioniert schon deshalb nicht, weil etliche VDI-Teile der Engine ursprünglich aus dem damals bereits verGPL'ten EmuTOS stammen, folglich das "Drumrum" auch der GPL unterliegt.
Der TrueType-Teil ist Freetype2 (also auch GPL).
-
Ich interpretiere das eigentlich ähnlich wie Markus.
Am besten sollte man mal das readme.now in github updaten (oder möglicherweise ganz löschen, da es sich offenbar auf nicht vorhandene Sourcen bezieht), um Missverständnissen vorzubeugen.
-
Daraus jetzt das Verständnis abzuleiten, dass alles mit Copyright belegt wäre, funktioniert schon deshalb nicht, weil etliche VDI-Teile der Engine ursprünglich aus dem damals bereits verGPL'ten EmuTOS stammen, folglich das "Drumrum" auch der GPL unterliegt.
Der TrueType-Teil ist Freetype2 (also auch GPL).
Okay, also wäre fVDI dann GPLv2, habe ich das richtig verstanden? Wenn ja, dann komme ich auf meinen ursprünglichen Trigger zurück :-)
Das "original VDI" der FireBee ist fVDI. Allerdings eine andere (wohl neuere) Version als die, die JK als OpenSource freigegeben hat, mit Treibern, die dort nicht dabei sind und mit etlichen Erweiterungen von Didier Méquignon.
… denn dann müßten doch diese FireBee-Änderungen/Erweiterungen doch auch GPLv2 sein – nur die Treiber ggfs. nicht, zwangsläufig, wenn sie sauber binary-separiert sind im GPL-Sinne.
-
Daraus jetzt das Verständnis abzuleiten, dass alles mit Copyright belegt wäre, funktioniert schon deshalb nicht, weil etliche VDI-Teile der Engine ursprünglich aus dem damals bereits verGPL'ten EmuTOS stammen, folglich das "Drumrum" auch der GPL unterliegt.
Der TrueType-Teil ist Freetype2 (also auch GPL).
Okay, also wäre fVDI dann GPLv2, habe ich das richtig verstanden? Wenn ja, dann komme ich auf meinen ursprünglichen Trigger zurück :-)
Das "original VDI" der FireBee ist fVDI. Allerdings eine andere (wohl neuere) Version als die, die JK als OpenSource freigegeben hat, mit Treibern, die dort nicht dabei sind und mit etlichen Erweiterungen von Didier Méquignon.
… denn dann müßten doch diese FireBee-Änderungen/Erweiterungen doch auch GPLv2 sein – nur die Treiber ggfs. nicht, zwangsläufig, wenn sie sauber binary-separiert sind im GPL-Sinne.
exakt.
Die gab's auch (bis zur Einäscherung von Atariforge).
-
dann müßten doch diese FireBee-Änderungen/Erweiterungen doch auch GPLv2 sein
Vermutlich nicht, denn sie haben die Sourcen ja schon gehabt, bevor sie öffentlich freigegeben wurden.
nur die Treiber ggfs. nicht, zwangsläufig, wenn sie sauber binary-separiert sind im GPL-Sinne.
Ja, sind sie... leider, muss man sagen, denn ansonsten wären deren Sourcen auch verfügbar.
-
wie ist egtl. der aktuelle Stand? Ist es mittlerweile mit fVDI möglich, z.B. 1920x1080 60Hz (32 bit), aus der Biene zu quetschen?