fVDI + FireBee

[mfro]

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

[goetz @ 3rz]

Großartig, danke! (und auch für richtige Screenshots, und nicht dieses Handyge****el)!

[Arthur]

Finde ich auch sehr interessant auch wenn ich keine Firebee besitze. Hat sich dadurch auch die Geschwindigkeit erhöht?

[mfro]

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.

[Arthur]

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?

[mfro]

Aber immer noch reichlich aufwändig, oder?

Wie gesagt, ohne Corona würde es das nicht (oder zumindest noch nicht) geben.

[tuxie]

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 ?

[Thorsten Otto]

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

[m0n0]

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.

[Thorsten Otto]

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

[mfro]

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.

[goetz @ 3rz]

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

[Thorsten Otto]

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.

[Thorsten Otto]

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

[goetz @ 3rz]

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.

[Thorsten Otto]

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.

[goetz @ 3rz]

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 …

[Thorsten Otto]

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.

[goetz @ 3rz]

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.

[tuxie]

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 ?