Autor Thema: fVDI + FireBee  (Gelesen 13987 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline mfro

  • Benutzer
  • Beiträge: 1.637
fVDI + FireBee
« 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).
« Letzte Änderung: Mo 04.05.2020, 21:49:32 von mfro »
And remember: Beethoven wrote his first symphony in C

Offline gh-baden

  • Benutzer
  • Beiträge: 1.967
Re: fVDI + FireBee
« Antwort #1 am: Mo 04.05.2020, 22:13:17 »
Großartig, danke! (und auch für richtige Screenshots, und nicht dieses Handyge****el)!
Wider dem Signaturspam!

Offline Arthur

  • Benutzer
  • Beiträge: 10.302
  • Mein Atari erinnert mich an die gute alte Zeit..
Re: fVDI + FireBee
« Antwort #2 am: Di 05.05.2020, 11:58:46 »
Finde ich auch sehr interessant auch wenn ich keine Firebee besitze. Hat sich dadurch auch die Geschwindigkeit erhöht?

Offline mfro

  • Benutzer
  • Beiträge: 1.637
Re: fVDI + FireBee
« Antwort #3 am: Di 05.05.2020, 12:26:45 »
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.
And remember: Beethoven wrote his first symphony in C

Offline Arthur

  • Benutzer
  • Beiträge: 10.302
  • Mein Atari erinnert mich an die gute alte Zeit..
Re: fVDI + FireBee
« Antwort #4 am: Di 05.05.2020, 12:46:00 »
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?

Offline mfro

  • Benutzer
  • Beiträge: 1.637
Re: fVDI + FireBee
« Antwort #5 am: Di 05.05.2020, 14:06:24 »
Aber immer noch reichlich aufwändig, oder?

Wie gesagt, ohne Corona würde es das nicht (oder zumindest noch nicht) geben.
And remember: Beethoven wrote his first symphony in C

Offline tuxie

  • Benutzer
  • Beiträge: 6.830
  • Falcon! Milan! Schuetzt die Raubvoegel!
Re: fVDI + FireBee
« Antwort #6 am: Do 07.05.2020, 10:02:09 »
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 ?
Tschau Ingo

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.248
Re: fVDI + FireBee
« Antwort #7 am: Do 07.05.2020, 12:15:16 »
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

Offline m0n0

  • Benutzer
  • Beiträge: 984
Re: fVDI + FireBee
« Antwort #8 am: Mi 20.05.2020, 22:31:54 »
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.
« Letzte Änderung: Do 21.05.2020, 00:53:00 von m0n0 »

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.248
Re: fVDI + FireBee
« Antwort #9 am: Do 21.05.2020, 08:10:07 »
Das original VDI der FireBee scheint ja closed source zu sein

Zitat
Bringt EmuTOS nicht auch ein eigenes, open source VDI mit?

Ja schon, das beinhaltet aber kein GDOS.

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

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

Zitat
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 ;)

Offline mfro

  • Benutzer
  • Beiträge: 1.637
Re: fVDI + FireBee
« Antwort #10 am: Do 21.05.2020, 08:41:43 »
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.
And remember: Beethoven wrote his first symphony in C

Offline gh-baden

  • Benutzer
  • Beiträge: 1.967
Re: fVDI + FireBee
« Antwort #11 am: Do 21.05.2020, 09:56:59 »
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".
Wider dem Signaturspam!

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.248
Re: fVDI + FireBee
« Antwort #12 am: Do 21.05.2020, 10:13:45 »
Zitat von: Johan Klockars
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.


Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.248
Re: fVDI + FireBee
« Antwort #13 am: Do 21.05.2020, 15:32:07 »
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...

Offline gh-baden

  • Benutzer
  • Beiträge: 1.967
Re: fVDI + FireBee
« Antwort #14 am: Do 21.05.2020, 18:12:00 »
Zitat von: Johan Klockars
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.
Wider dem Signaturspam!

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.248
Re: fVDI + FireBee
« Antwort #15 am: Do 21.05.2020, 18:57:41 »
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.


Offline gh-baden

  • Benutzer
  • Beiträge: 1.967
Re: fVDI + FireBee
« Antwort #16 am: Fr 22.05.2020, 02:52:26 »
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 …
Wider dem Signaturspam!

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.248
Re: fVDI + FireBee
« Antwort #17 am: Fr 22.05.2020, 16:00:45 »
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.

Offline gh-baden

  • Benutzer
  • Beiträge: 1.967
Re: fVDI + FireBee
« Antwort #18 am: Sa 23.05.2020, 21:03:16 »
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 ->

Zitat
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.
Wider dem Signaturspam!

Offline tuxie

  • Benutzer
  • Beiträge: 6.830
  • Falcon! Milan! Schuetzt die Raubvoegel!
Re: fVDI + FireBee
« Antwort #19 am: Mo 25.05.2020, 12:10:58 »
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 ?
Tschau Ingo