Autor Thema: Atari Coldfire Project Reloaded  (Gelesen 879436 mal)

0 Mitglieder und 3 Gäste betrachten dieses Thema.

Offline michschmi

  • Benutzer
  • Beiträge: 642
  • Ich liebe dieses Forum!
Re: Atari Coldfire Project Reloaded
« Antwort #820 am: Sa 09.04.2011, 20:10:13 »
Also ich würde da keine Energie in die alten Programme verschwenden. Wer solche Programme hat und sie unbedingt noch benutzen muß oder will der sollte sich einen Drucker mit entsprechenden Druckeremulation besorgen...in der Firebee könnte über ein CPX evtl. eine Umleitung der LPT-Daten auf einen USB-Drucker angeboten werden. NVDI oder GDOS sollten natürlich unterstützt werden. Vielleicht schafft man es die Firebee so Kompatibel zu machen das NVDI auch ohne Patches läuft...

das bringt aber alles nichts, wenn das Programm die nvdi-Schnittstelle nutzt. Ist nvdi nicht da, passiert gar nichts.
du redest von "solchen Programmen". Wo bekommst du den aktuellere Programme her? Texel ist mWn von seiner Art auf dem Atari konkurrenzlos, nutz aber in 2,2 die nvdi-Schnittstelle zum Drucken. Dass ein ähnliches neues Programm in Sicht ist, sehe ich nicht.
Und mono hat ja schon auf dieProblematik der nvdi-Druckertreiber-Beschreibungen hingewiesen.
M.E. ist Hemuts Ansatz der einzig vernüftige,um etwas zukunftsicherheit in das Them "Drucken" zu bekommen, aber hier ist wohl ziemlicher Programmieraufwand erforderlich. Da stellt sich dann die Frage, wer setzt das um.

Und solange noch versucht, wird mit Nvdi und ähnlichen Produkten Geld zu verdienen, sieht es wohl auch mit einer Quell-Offenlegung schlecht aus.
Dass das 12 Jahre nach dem letzten Release immer noch so ist, ist eigentlich traurig, denn auch dem findigsten Geschäftsmann sollte klar sein, dass das Atari-System heute meist wenig mehr als eine Liebhaberbeschäftigung ist.

Aber vielleicht hat das ACP-Team auch hier etwas "in der Mache"?! ;)

@ michschmi, bitte nicht nur querlesen sondern durchlesen und begreifen.

@Mathias, das Umleitung der LPT-Daten auf einen USB-Drucker sollte mit jedem Programm (das eigene Druckertreiber benutzt) und das die entsprechenden Betriebsystemfunktionen benutzt und den Druckerport nicht direkt ansteuert auch möglich sein. Frag mal "deine Jungs" vom ACP-Team. ;D

hab nichts "quergelesn", sondern deine Antwort so  verstanden dass du die "alten Propgramme" lieber gar nicht nutzt und lieber auf was Neues setzt. Daher meine Frage, wo das "Neue" herkommen soll. Genauso dein Asatz mit der Drucker-Emu. So wie ich es verstehe: Wie soll die funktionieren, wenn die Programme NVDI zur korrekten Funktion voraussetzen und nur auf dessen Schnittstellen drucken? NVDI kennt keine USB-Schnittstelle und selbst wenn ich einen Drucker finde, der HPDeskJet emulieren kann, muß der noch lange nicht zum entsprechenden NVDI-Treiber kompatibel sein.
Ich habe jahrelang mit meinem Canon BJC-1000 in NVDI über dessen Canon BJC 250-Treiber gedruckt. Das ging auch gut, solange nicht vielfarbige Grafiken gedruckt werden sollten. Der Druker "stieg dann aus", sprich druckte die Grafik, aber nur umrisshaft. Tests mit einem geliehenen BJC-250 gaben korrekte Ergebnisse.... (soviel zur Emulation oder Abwärtskompartibiltät der Drucker...  ::)  ::) )

Womöglich möchtst du dich aber nicht genau erklären! DAS zumindest lese ich aus deiner flapsigen "Antwort". Ich kann ja nicht in dein Hirn gucken und wissen, was du alles als bekannt voraussetzt, um verstanden werden zu wollen (das geht mir hier nicht zum ersten mal so!!!)
« Letzte Änderung: Sa 09.04.2011, 20:33:57 von michschmi »

gstoll

  • Gast
Re: Atari Coldfire Project Reloaded
« Antwort #821 am: Sa 09.04.2011, 20:14:20 »
NVDI wird als VDI garantiert nicht laufen!  Dies ist eine Aussage von Fredi Aschwanden, die vor 2 Monaten nochmals bestätigt wurde.
Und als reines GDOS? So läuft es ja schliesslich hier auf dem Milan.

Zitat von: m0n0
NVDI zum laufen zu bekommen und herausbekommen wie ein NVDI Treiber aufgebaut ist
Sehe nicht was da anderster sein soll als bei allen GDOS Treibern. Einziger unterschied ist, daß sie wohl die Funktion
- v_create_driver_info
- v_delete_driver_info
- v_read_default_settings
- v_write_default_settings
unterstützen, welche mit NVDI 5 eingeführt wurden und vom Druckerdialog genutzt werden. Wenn man natürlich die Treiber der Version 5 nutzt.

Zitat von: HelmutK
Ich hatte ja schonmal die Idee,  ein TSR oder kernel-modul zu schreiben, das sich in den VDI-trap hängt, und  aus den eingehenden Daten postscript oder sonstwas macht.
Für was das? Dafür gibt es doch das GDOS mit seinen Treibern. Ich habe hier z.B. einen nicht fertigen Treiber zur PDF Ausgabe.

Gerhard

Offline Mathias

  • Moderator
  • *****
  • Beiträge: 1.578
Re: Atari Coldfire Project Reloaded
« Antwort #822 am: Sa 09.04.2011, 20:27:29 »
Und als reines GDOS? So läuft es ja schliesslich hier auf dem Milan.
Muß man ausprobieren um Gewissheit zu erlangen. Aber eher nicht. Aber darum hab´ ich ja auf VDI hingewiesen, da die Möglichkeit noch nicht zu 100% auszuschließen ist.


Ich habe hier z.B. einen nicht fertigen Treiber zur PDF Ausgabe.

Gerhard
Bittebitte fertig machen! ;)
MegaST 4 mit Sounddesigner II MegaBus-Hardware und 56001, MegaSTE, Hades 040, MagiC Mac auf Mac OS 9 und eine FireBee.

Offline michschmi

  • Benutzer
  • Beiträge: 642
  • Ich liebe dieses Forum!
Re: Atari Coldfire Project Reloaded
« Antwort #823 am: Sa 09.04.2011, 22:00:50 »
m0n0, ich bin am "arbeiten" wegen der Sache.


wg. NVDI:

NVDI wird als VDI garantiert nicht laufen!  Dies ist eine Aussage von Fredi Aschwanden, die vor 2 Monaten nochmals bestätigt wurde.

Uns war das von Beginn an klar, und wir haben fast 2 Jahre versucht NVDI zu bekommen, oder sogar auf eine kommerzielle Lösung hinzuarbeiten. Das waren einerseits mehrere Telefonate mit Wilfried Behne, andererseits der Versuch mit Bitstream eine Lösung zu finden.

Bitstream hat nichteinmal reagiert, um irgendeine Lösung wie "Zahlung pro Verkauf", "Einmalzahlung  für unlimitierte Lizenz" oder Freigabe ihres Vector Font Scalers oder sonstwas anzudenken. Sie haben einfach die Kommunikation verweigert. Ich war eigentlich sehr verwundert, da die Firma nichtmal 70 Angestellte hat.

Wilfried Behne hat 2009 angedacht NVDI 2.5 freizugeben, und u.U. auch einen Programmierer ranzulassen, der unter NDA von 2B an den "closed sources" von NVDI 5 arbeitet um den Bitstreamcode rauszuproggrammieren. 2010 hat Alles ganz anders geklungen. "Behne & Behne hätten das nochmals besprochen, es werde nichts freigegeben, die "Nachprogrammierung" ist vermutlich einfacher, wir sollen das einfach neu machen". Und auf die Aussage daß NVDI dann für immer verloren wäre, wurde "that´s Live" entgegnet, …
Nichtmal Freigabe als Freeware geht da ja die Bitstreamlizenz abgelaufen ist.   

So, und jetzt stehen wir also vor einem richtigen kapitalistischem "Closed Source" Dead End! Wir brauchen also irgendeine komplett andere Lösung. Auch für unsere kleinen Ataris, da wir ja nicht alle Neuankömmlinge mit nicht lizensierten Kopien (bzw. Abandonware, die ich persönlich für durchaus legitim halte) versorgen können – als Zukunftsstrategie meine ich. Ich hab´ diese Lösung momentan nicht. "Helmuts Ansatz" bzw. komplette Neuprogrammierung der NVDI-Funktionen, das wäre ein super aufwändiges Zusatzprojekt, wo sich 2-3 sehr gute Programmierer 1-2 jahre ihrer ganzen Friezeit dransetzen müßten – und die gibt es momentan nicht. Vermutlich ist es aber unsere einzige Chance – irgendwelche Freiwilligen?

Das Drucken selbst ist noch das große Problem (also abseits von den TOS-eigenen Druckern).  Und ja es wirft auch für uns Fragen auf, die noch nicht zu beantworten sind.
GDOS mäßig selbst geht womöglich bald was mit TTFGDOS oder GDOS+, wir sind am arbeiten diesbezüglich.


Hallo Marhias,

danke für deine AUSFÜHRLICHE und VERSTÄNDLICHE Antwort.

Zum GDOS: Habt Ihr schonmal Falke-Verlag angesprochen. Die haben die Rechte an Speedo (nicht umsonst ist eine Soeedo-Emulation in Stemulator enthalten). Wenn man diese Quellen hättem könnte man evtl. etwas neues damit anfangen.
Und noch ein Problem gibt es. NVDI ist ja nur die eine Seite. Die andere ist Wdialog, welches teilweise eng verzahnt mit NVDI zusammenarbeitet und auch die generellen Druckerdialoge (Drucker/Seiteneinstellung) liefert, die NVDI dann auswertet. Auch Cops arbeitet nicht ohne Wdialog. Hier wurde von woller Anstrengungen mit gemacht, Ndialog Anstrengungen gemacht, einen Wdialog-Ersatz zu schreiben, der bisher soweit funktioniert, dass die Steuerung von Cops damit funktioniert und die Fontauswahl. Eeine Implementierung von Drucker-Diaslogen war angedacht, aber wegen der unauberen Implementierung in WDialog nicht beendet. Evtl. sind diese Quellen auch erhältlich?!

Offline Nervengift

  • Benutzer
  • Beiträge: 1.533
Re: Atari Coldfire Project Reloaded
« Antwort #824 am: So 10.04.2011, 14:35:13 »
Moin, moin,

diese ganze Fontgeschichte fand ich in GEM schon immer ziemlich beschissen gelöst und diese teilweise doch eher komplizierte Hantiererei mit irgendeinem GDOS eher nervig. Nichts desto trotz ist es auf einem Atari mit so ziemlich die einzige Möglichkeit, unterschiedliche Fonts zu nutzen und diese sollte auch auf der Firebee gegeben sein. Ansonsten wäre das schon sehr, sehr schade.

Was ich in dieser Hinsicht auch für gar nicht gut halte: Viele Programme kochen dort ihr eigenes Süppchen! Papyrus z. B. kommt ganz ohne GDOS aus und hat eigene Fonts und Druckertreiber eingebaut. Schön und gut, aber warum kann man sich nicht an Konventionen halten?!

Für die Zukunft wäre es besser, wenn man eine neue Lösung dieses Problems anstrebt, daß sich auch die Anwendungsprogrammierer daran halten und jene nutzen. Allerdings ist die Situation eben nicht rosig, was das angeht und insofern ist es wohl viel wichtiger, sicherzustellen, daß alte Software vernünftig läuft, denn wirklich neue wird es so schnell nicht geben (wenn überhaupt).

Andreas
520 ST(M) (TOS 1.02), Falcon030 (16 MHz, 16 MB RAM, CF-Karte, MiNT & MyAES), Milan040 (25 MHz, 48 MB RAM, EasyMiNT 1.90), Firebee (2nd Edition), PowerMac G5 Late 2005 (2 x 2,3 GHz, Mac OS 10.5), iMac 4K Late 2015 (intel Core i7 4 x 3,3 GHz, Mac OS 10.11.6), IBM XT SFD (640 KB RAM, DR DOS 6.0), Compaq LTE 5300 (Pentium/133 MHz, DR-DOS 7.03), AT-PC (Cyrix 6x86L/200 MHz, Windows 98 SE/MS-DOS 6.22 & Windows 3.11)

Offline m0n0

  • Benutzer
  • Beiträge: 984
Re: Atari Coldfire Project Reloaded
« Antwort #825 am: So 10.04.2011, 16:40:52 »
Naja, für die Fonts - da gibt es ja noch diverse andere GDOS'se die ja evt. besser laufen auf der Firebee... ( trotzdem nicht schön das man auf nicht mehr supportete / closed source sachen zurueckgreifen muss).

Und FVDI, wurde mir schon einige male erläutert, macht keinen Sinn zu erweitern - es wäre angeblich besser ein komplett neues VDI zu schreiben ;) Das zumindest hatte Pepster vom Super-Videl projekt geschrieben.

Helmuts Idee klingt garnicht schlecht und was gstoll da in der mache hat, klingt ja auch nicht verkehrt :)

Offline joska

  • Benutzer
  • Beiträge: 20
Re: Atari Coldfire Project Reloaded
« Antwort #826 am: So 10.04.2011, 20:55:31 »
Und noch ein Problem gibt es. NVDI ist ja nur die eine Seite. Die andere ist Wdialog, welches teilweise eng verzahnt mit NVDI zusammenarbeitet und auch die generellen Druckerdialoge (Drucker/Seiteneinstellung) liefert, die NVDI dann auswertet. Auch Cops arbeitet nicht ohne Wdialog. Hier wurde von woller Anstrengungen mit gemacht, Ndialog Anstrengungen gemacht, einen Wdialog-Ersatz zu schreiben, der bisher soweit funktioniert, dass die Steuerung von Cops damit funktioniert und die Fontauswahl. Eeine Implementierung von Drucker-Diaslogen war angedacht, aber wegen der unauberen Implementierung in WDialog nicht beendet. Evtl. sind diese Quellen auch erhältlich?!

This is not a problem with XaAES. The printer-dialog and the windowed dialogs are fully implemented.

Offline michschmi

  • Benutzer
  • Beiträge: 642
  • Ich liebe dieses Forum!
Re: Atari Coldfire Project Reloaded
« Antwort #827 am: Mo 11.04.2011, 12:31:13 »
Moin, moin,

diese ganze Fontgeschichte fand ich in GEM schon immer ziemlich beschissen gelöst und diese teilweise doch eher komplizierte Hantiererei mit irgendeinem GDOS eher nervig. Nichts desto trotz ist es auf einem Atari mit so ziemlich die einzige Möglichkeit, unterschiedliche Fonts zu nutzen und diese sollte auch auf der Firebee gegeben sein. Ansonsten wäre das schon sehr, sehr schade.

Was ich in dieser Hinsicht auch für gar nicht gut halte: Viele Programme kochen dort ihr eigenes Süppchen! Papyrus z. B. kommt ganz ohne GDOS aus und hat eigene Fonts und Druckertreiber eingebaut. Schön und gut, aber warum kann man sich nicht an Konventionen halten?!

Für die Zukunft wäre es besser, wenn man eine neue Lösung dieses Problems anstrebt, daß sich auch die Anwendungsprogrammierer daran halten und jene nutzen. Allerdings ist die Situation eben nicht rosig, was das angeht und insofern ist es wohl viel wichtiger, sicherzustellen, daß alte Software vernünftig läuft, denn wirklich neue wird es so schnell nicht geben (wenn überhaupt).

Andreas

das stimmt nicht ganz. Papyrus nutzt schon Gdos, sonst würde ich auf den Stemulkator keinen Ausdruck hinbekommen. Es hat allerdings auch eigene Druckertreiber, due aner alle für Parallel-Port-Drucker sind und damit mit moderner Hardware nutzlos sind.
Imho ist daher GDOS überhaupt die einzige Möglichkeit, Ausdrucke mit der aktuell zur Verfügung stehenden Software hinzubekommen.
Ist gibt natürlich auf reiner Atari-HW ein weiteres Problem, das ich auf dem Stemulator nicht habe: Dort regelt das Windows-Systzem, das eine Seite so wue im Programm formatiert, auf em Drucker rauskommt, ich brauche daher keinen Treiber auf der Atari-Seite, sondern nur GDOS. Der Stemulator regelt "den Rest".
Duese Möglichkeit fällt auf der Firebee weg, hier müsste also wieder Druckertreiber über das VDI o.ä zur Verfügung stehen und die müssten dann auch aktuell sein, so wie alle möglichen Schnittstellen (USB; Parallel) ansprehbar sein. Ob es klapppen würde, einen Parallel-Drucker mittels Parallel/USB-Weiche zu betrieben, ist auch unklar (d.h. bei einigen wirds funktionieren, bei anderen nicht).

Offline michschmi

  • Benutzer
  • Beiträge: 642
  • Ich liebe dieses Forum!
Re: Atari Coldfire Project Reloaded
« Antwort #828 am: Mo 11.04.2011, 12:39:13 »
Und noch ein Problem gibt es. NVDI ist ja nur die eine Seite. Die andere ist Wdialog, welches teilweise eng verzahnt mit NVDI zusammenarbeitet und auch die generellen Druckerdialoge (Drucker/Seiteneinstellung) liefert, die NVDI dann auswertet. Auch Cops arbeitet nicht ohne Wdialog. Hier wurde von woller Anstrengungen mit gemacht, Ndialog Anstrengungen gemacht, einen Wdialog-Ersatz zu schreiben, der bisher soweit funktioniert, dass die Steuerung von Cops damit funktioniert und die Fontauswahl. Eeine Implementierung von Drucker-Diaslogen war angedacht, aber wegen der unauberen Implementierung in WDialog nicht beendet. Evtl. sind diese Quellen auch erhältlich?!

This is not a problem with XaAES. The printer-dialog and the windowed dialogs are fully implemented.

o.k. so check, if Texel 2,2 runs with this. If so, then it'sa  really good progress. If not, what I assume (for Texel 2,2 stringently demands WDIALOG), then the Problem remains and a program, wich is unrivalled in the ST-Universe won't run.
And moreover, what to do with the programs that check if Nvdi is running. How to outwit them; or is the general opionion to neglect them?
Some insist on nvdi, the won't run if e.g. Speedo is present.

Offline michschmi

  • Benutzer
  • Beiträge: 642
  • Ich liebe dieses Forum!
Re: Atari Coldfire Project Reloaded
« Antwort #829 am: Mo 11.04.2011, 12:43:00 »
Naja, für die Fonts - da gibt es ja noch diverse andere GDOS'se die ja evt. besser laufen auf der Firebee... ( trotzdem nicht schön das man auf nicht mehr supportete / closed source sachen zurueckgreifen muss).

Und FVDI, wurde mir schon einige male erläutert, macht keinen Sinn zu erweitern - es wäre angeblich besser ein komplett neues VDI zu schreiben ;) Das zumindest hatte Pepster vom Super-Videl projekt geschrieben.

Helmuts Idee klingt garnicht schlecht und was gstoll da in der mache hat, klingt ja auch nicht verkehrt :)

so wie ich Mathias verstanden habe, wird nvdi sowieso nicht laufen, sodass sowieso ein Ersatz her muß. Aber wie soll das aussehen. Es sollte erst mal sichergestellt sein, dass Programme, die prüfen, ob nvdi läuft auch weiterhin laufen und sichergestellt sein, dass man drucken kann wie man möchte.
Evtl. sehe ich das auch etwas eng, aber ich benutze Computer (auch den ST/e früher) immer mit Blick darauf, das ich irgendwann mal eine Arbeit auf Papier habe. Gut, es gibt hier und da Export-Möglichkeiten, aber dann brauche ich ja doch wieder einen PC/Apple mit den Programmen zum importieren meiner mi ST-Software erstellten Dateien, um diese zu drucken. Warum dann einen Atari-Clone?
« Letzte Änderung: Mo 11.04.2011, 12:45:54 von michschmi »

Offline m0n0

  • Benutzer
  • Beiträge: 984
Re: Atari Coldfire Project Reloaded
« Antwort #830 am: Mo 11.04.2011, 15:55:33 »
Ich gebe dir in so fern recht, das ich natuerlich auch gerne
meine Arbeiten ausdrucken moechte, aber es ist nunmal ein
problem, und noergeln bringt einen da auch nicht weiter ;)

Im moment bin ich mir noch garnicht im klaren mit
welchen Programmen und deren Druckertreiber implementierung
ich konfrontiert werde, vielleicht findet sich bei einigen
ein netter workaround, bei anderen nicht... das wird sich
noch zeigen.
Aber das es als Problem angesehen wird, ich glaube damit
stehst Du nicht alleine...

Offline michschmi

  • Benutzer
  • Beiträge: 642
  • Ich liebe dieses Forum!
Re: Atari Coldfire Project Reloaded
« Antwort #831 am: Mo 11.04.2011, 17:08:47 »
Ich gebe dir in so fern recht, das ich natuerlich auch gerne
meine Arbeiten ausdrucken moechte, aber es ist nunmal ein
problem, und noergeln bringt einen da auch nicht weiter ;)

Im moment bin ich mir noch garnicht im klaren mit
welchen Programmen und deren Druckertreiber implementierung
ich konfrontiert werde, vielleicht findet sich bei einigen
ein netter workaround, bei anderen nicht... das wird sich
noch zeigen.
Aber das es als Problem angesehen wird, ich glaube damit
stehst Du nicht alleine...

im Moment gehe ich davon aus, dass mangeks Alternativen eben Programme wie Texel 2,x und Papyrus 8-10,x verwendet werden müssen, sollte man, den aktuellen Rechner für sowas einsetzen wollen.
Ohne das jetzt abwertend gemeint ist, aber evtl. täusche ich mich ja und die Maschine ist "von Atari Freaks für Atari-Freaks gedacht" und es wird davon ausgegangen, dass der Nutzer entsprechendes Kow-How und Geschick hat, um bei Bedarf selbst hand anzulegen und Nachbauten o.ä. umzusetzen.
Ich habe bisher leider den Eindruck, dass der Schwerpunkt auf OS-Ebene liegt (was irgendwie auch logisch ist), das als Grundvorausetzung absolut nötig ist, so locker im Hinterkopf schweben dann doch irgendwo Anwendungsprogramme herum, aber wirklich vergessen wurde, dass in den letzten sehr aktiven Jahren der Atari-SW 1998/99 vermehrt dazu übergegangen wurde, Programme äbhängig von anderen Programmen laufen zu lassen (mir sind seinerzeit auf dem Milan begegnet, die nur unter Magic liefen und unter Mint/N.AES gar nicht starteten. Ich habe momentan aber leider keine Beispiele parat
 :(  )

Und weil einige Posts vorher mangelnde Standards angesprochen wurden: Es gab einfach wenige bis keine. Jeder Programmierer entschied selbst, was er von vorhandenen Quasi-Standards einbaute (z.B. BubbleGem oder ST-Guide-Hilfe). Für Drücker gab es nichts; jedes Programm musste seine eigenen Treiber mitbringen; erst mit NVDI 4,x wurden systemübergreifende Druckertreiber eingeführt. Damit wurde die denkbar schlechteste Alternative gewählt. Davon ab konnten im Prinzip nahezu jedes GDOS auf Gerät 21 ausgeben; nur gab es eben keine Treiberunterstützung bis auf für NVDI.

Sehr unörderlich war auch die quasi.Konkurrez-Situation von Magic und N.AES. Beides waren Bezahl-OS-Erweiterungen, mit dem Vorteil für N.AES, dass mit Mint inzwischen ein Freeware-Programm als Unterbau zur Verfügung stand. Diejenigen Entwickler, die Magic nahestanden optimierten ihre Programme für Magic, während es bei N.AES keine direkt im selben Vertrieb befindlichen Programme gab und die Absicht eher dahin ging, alle sauber prorammierrten Programme lauffähig zu haben (also solche, die nicht maschinen-nah programmiert waren).
Wegen dieser Situation kam es zu einem Durcheinander, welches heute ausgebadet werden muß und die Entwicklung einer neuen HW-Plattform bei nur sehr wenig verbliebenen SW-Entwicklern sehr sehr schwierig macht.
Damals war es so: Milan gekauft und ich konnte 80%meiner vorhanden Software weiterverwenden.
Und heute: Heute steht es eher so, dass weniger als 20% weiterverwendet werden können, da Abhängigkeiten von alten System-tools bestehen, die nicht mehr laufen werden.

Deshalb sehe ich das weniger als "Noergeln", denn als mE realistischen Blick auf die Zukunft.

Da aber nach meiner Auffassung heute die wenigsten Atari-SW-Nutzer ihr System  weniger
für produktive als z.B. für HW-Entwicklungstests oder Spiele nutzen, ist das u.U. nicht so ein großes Problem....

Offline Mathias

  • Moderator
  • *****
  • Beiträge: 1.578
Re: Atari Coldfire Project Reloaded
« Antwort #832 am: Mo 11.04.2011, 17:14:33 »
so wie ich Mathias verstanden habe, wird nvdi sowieso nicht laufen, sodass sowieso ein Ersatz her muß.
Richtig. Wir haben gestern auch NVDI als reines GDOS probiert,und auch das hängt sich auf.


ich benutze Computer (auch den ST/e früher) immer mit Blick darauf, das ich irgendwann mal eine Arbeit auf Papier habe.
Ja, ich auch. Und es ist klar, daß das ein essentieller Punkt ist.


Gut, es gibt hier und da Export-Möglichkeiten, aber dann brauche ich ja doch wieder einen PC/Apple mit den Programmen zum importieren meiner mi ST-Software erstellten Dateien, um diese zu drucken. Warum dann einen Atari-Clone?
Bitte, niemand im Team denkt in die Richtung "kann man eh mit anderen Plattformen machen". Nur weil wir für manche Fragen noch keine Lösungen haben, heißt das ja nicht, daß die für immer ungelöst bleiben. Ganz im Gegenteil, so viel "Aufbruchsstimmung" wie die letzten beiden Jahre habe ich seit 10 Jahren nicht mehr mitbekommen.

Ich bin da lieber ehrlich,  und sage, "ja das ist ein Problem, und wir kennen die Lösung noch nicht". Aber ich bin guter Dinge, daß es eine geben wird.

Ich finde es auch immer gut wenn Fragen besprochen werde, statt heile Welt vorzuspielen. Aber niemals stellt das den ganzen Clone in Frage! Denn wenn ich so gedacht hätte, dann wäre das Projekt nie mehr ins Laufen gekommen.

Also; wenn wir uns gemeinsam um Lösungen bemühen wird es auch früher oder später welche geben.  ;)
MegaST 4 mit Sounddesigner II MegaBus-Hardware und 56001, MegaSTE, Hades 040, MagiC Mac auf Mac OS 9 und eine FireBee.

Offline Mathias

  • Moderator
  • *****
  • Beiträge: 1.578
Re: Atari Coldfire Project Reloaded
« Antwort #833 am: Mo 11.04.2011, 17:28:36 »

Ich habe bisher leider den Eindruck, dass der Schwerpunkt auf OS-Ebene liegt (was irgendwie auch logisch ist), das als Grundvorausetzung absolut nötig ist, so locker im Hinterkopf schweben dann doch irgendwo Anwendungsprogramme herum,
Nein, falsch. Ich habe von Beginn an versucht Anwendungsprogrammier mit einzubinden! Invers, Thing-Programmierer und Soundpool sind im Team. Mit ROM, 2B, Seimet, Anodyne, etc. etc. gab es sehr viel Kontakt.

Aber bitte was sollen die denn momentan großartig machen wenn auf OS-Ebene noch nicht alles fertig ist?


aber wirklich vergessen wurde, dass in den letzten sehr aktiven Jahren der Atari-SW 1998/99 vermehrt dazu übergegangen wurde, Programme äbhängig von anderen Programmen laufen zu lassen
Nein wurde es nicht. Aber wenn diese unter Verschluß gehalten werden, wass soll man dann tun?



Wegen dieser Situation kam es zu einem Durcheinander, welches heute ausgebadet werden muß und die Entwicklung einer neuen HW-Plattform bei nur sehr wenig verbliebenen SW-Entwicklern sehr sehr schwierig macht.
Ja, richtig, und wir versuchen unser Bestes, und auch immer eine zukunftsfähige Variante á la GPL. Liegt aber immer an den (ehemaligen) Herstellern was letztlich möglich ist.


Da aber nach meiner Auffassung heute die wenigsten Atari-SW-Nutzer ihr System  weniger
für produktive als z.B. für HW-Entwicklungstests oder Spiele nutzen, ist das u.U. nicht so ein großes Problem....
Hmm, ich habe das Gefühl, daß Du in jedem 2. Post Deine vage Angst formulierst daß die FireBee nicht als eigenstädiges System existieren können wird.
Das ist aber unser erklärtes Ziel, und ich denke es hat sich so viel getan, daß diese Angst zwar historisch berechtigt, aber gegenwärtig nicht begründet ist.
Im Gegensatz zur CT6x z.B. versuchen wir fertige Systeme zum "besorgen und einschalten" zu (er)schaffen, die auch wieder von Neueinsteigern genutzt werden können.

Kein Stress also; ich will selbst zu 100% auf die FireBee umsteigen, wenn mal alles fertig ist.
« Letzte Änderung: Mo 11.04.2011, 19:25:49 von Mathias »
MegaST 4 mit Sounddesigner II MegaBus-Hardware und 56001, MegaSTE, Hades 040, MagiC Mac auf Mac OS 9 und eine FireBee.

gstoll

  • Gast
Re: Atari Coldfire Project Reloaded
« Antwort #834 am: Mo 11.04.2011, 19:52:26 »
seinerzeit auf dem Milan begegnet, die nur unter Magic liefen und unter Mint/N.AES gar nicht starteten. Ich habe momentan aber leider keine Beispiele parat
Der Emailer wird wohl dazu gehören. Dafür funktioniert z.B. GEMDict nicht mit MagiC.

Für Drücker gab es nichts; jedes Programm musste seine eigenen Treiber mitbringen; erst mit NVDI 4,x wurden systemübergreifende Druckertreiber eingeführt.
Das stimmt so nicht GDOS gibt es schon seit anbeginn aller Zeit. Problem war das Atari es nicht geschaft hat dies noch ins ROM zuschieben. Es mußte schon immer nachgeladen werden. Was mit Diskette natürlich kein besonderes Vergnügen war.
Und wenn mich nicht die Erinnerung täuscht, war es nicht automatisch dabei. Habe auch irgendwas mit Lizenzen in Erinnerung, kann aber auch falsch sein.

Und der Standard beim Drucken ist einfach das VDI zunutzen.

Einzig was ich heute ändern würde ist das mit der ASSIGN.SYS-Datei. Nämlich einfach wie bei GEM/3 alles in den GEMSYS-Ordner. Was da drin ist wird versucht als Treiber zuladen.

wird nvdi sowieso nicht laufen, sodass sowieso ein Ersatz her muß. Aber wie soll das aussehen. Es sollte erst mal sichergestellt sein, dass Programme, die prüfen, ob nvdi läuft auch weiterhin laufen und sichergestellt sein, dass man drucken kann wie man möchte.
Es muß ein entsprechendes VDI her. Und wenn es die Funktionen von NVDI bietet kann man den Cookie setzen.

Ob fVDI tatsächlich so schlecht ist kann ich nicht beurteilen, aber vielleicht kann man sich ja um eine Veröffentlichung des NOVA VDI kümmern. Und schauen ob es besser ist.
Zum GDOS, theoretisch müßte R.O.M. logicware Quellen haben. Zumindest haben sie mal eine SpeedoGDOS 4.2 veröffentlicht. Ansonsten hatte no Software (Vertrieb: Compo) die Quellen und die letzten bis Version 5.5 gemacht.

Gerhard

Offline joska

  • Benutzer
  • Beiträge: 20
Re: Atari Coldfire Project Reloaded
« Antwort #835 am: Mo 11.04.2011, 21:11:25 »
o.k. so check, if Texel 2,2 runs with this. If so, then it'sa  really good progress. If not, what I assume (for Texel 2,2 stringently demands WDIALOG), then the

I only have Texel 2.0 which runs fine. Is there a demo of Texel 2.2 I can try?

And moreover, what to do with the programs that check if Nvdi is running. How to outwit them; or is the general opionion to neglect them?
Some insist on nvdi, the won't run if e.g. Speedo is present.

Are there any programs that checks specifically for NVDI?

gstoll

  • Gast
Re: Atari Coldfire Project Reloaded
« Antwort #836 am: Mo 11.04.2011, 21:52:10 »
Is there a demo of Texel 2.2 I can try?
http://www.snailshell.de/Texel/download.html

Are there any programs that checks specifically for NVDI?
Papillon 3.xx, needs NVDI 5.

Phoenix checks for NVDI > 3.02 and use then vqt_ext_name, if not it use only vqt_name.

I think more programs check in this way for NVDI.

Gerhard

Offline joska

  • Benutzer
  • Beiträge: 20
Re: Atari Coldfire Project Reloaded
« Antwort #837 am: Mo 11.04.2011, 22:36:12 »
http://www.snailshell.de/Texel/download.html

The demo archive seems to be broken. I'm not able to unpack it. So I tried the Milan-version which immediately crashed with a nasty memory violation.


Papillon 3.xx, needs NVDI 5.

Phoenix checks for NVDI > 3.02 and use then vqt_ext_name, if not it use only vqt_name.

I think more programs check in this way for NVDI.

Then the replacement VDI must install a NVDI cookie indicating the NVDI version that corresponds with the offered functionality.

Offline michschmi

  • Benutzer
  • Beiträge: 642
  • Ich liebe dieses Forum!
Re: Atari Coldfire Project Reloaded
« Antwort #838 am: Mo 11.04.2011, 23:05:10 »
http://www.snailshell.de/Texel/download.html

The demo archive seems to be broken. I'm not able to unpack it. So I tried the Milan-version which immediately crashed with a nasty memory violation.


Papillon 3.xx, needs NVDI 5.

Phoenix checks for NVDI > 3.02 and use then vqt_ext_name, if not it use only vqt_name.

I think more programs check in this way for NVDI.

Then the replacement VDI must install a NVDI cookie indicating the NVDI version that corresponds with the offered functionality.

I think you misunderstood me, because Texel 2.2 checks for WDIALOG. N.Dialog (the N.aes equivalent )does well, but Texel 2,2 won't print anything, if any other gdos than nvdi is present. It's relying on nvdi to print.

Offline michschmi

  • Benutzer
  • Beiträge: 642
  • Ich liebe dieses Forum!
Re: Atari Coldfire Project Reloaded
« Antwort #839 am: Mo 11.04.2011, 23:10:58 »
seinerzeit auf dem Milan begegnet, die nur unter Magic liefen und unter Mint/N.AES gar nicht starteten. Ich habe momentan aber leider keine Beispiele parat
Der Emailer wird wohl dazu gehören. Dafür funktioniert z.B. GEMDict nicht mit MagiC.

Für Drücker gab es nichts; jedes Programm musste seine eigenen Treiber mitbringen; erst mit NVDI 4,x wurden systemübergreifende Druckertreiber eingeführt.
Das stimmt so nicht GDOS gibt es schon seit anbeginn aller Zeit. Problem war das Atari es nicht geschaft hat dies noch ins ROM zuschieben. Es mußte schon immer nachgeladen werden. Was mit Diskette natürlich kein besonderes Vergnügen war.
Und wenn mich nicht die Erinnerung täuscht, war es nicht automatisch dabei. Habe auch irgendwas mit Lizenzen in Erinnerung, kann aber auch falsch sein.

Und der Standard beim Drucken ist einfach das VDI zunutzen.

Einzig was ich heute ändern würde ist das mit der ASSIGN.SYS-Datei. Nämlich einfach wie bei GEM/3 alles in den GEMSYS-Ordner. Was da drin ist wird versucht als Treiber zuladen.

wird nvdi sowieso nicht laufen, sodass sowieso ein Ersatz her muß. Aber wie soll das aussehen. Es sollte erst mal sichergestellt sein, dass Programme, die prüfen, ob nvdi läuft auch weiterhin laufen und sichergestellt sein, dass man drucken kann wie man möchte.
Es muß ein entsprechendes VDI her. Und wenn es die Funktionen von NVDI bietet kann man den Cookie setzen.

Ob fVDI tatsächlich so schlecht ist kann ich nicht beurteilen, aber vielleicht kann man sich ja um eine Veröffentlichung des NOVA VDI kümmern. Und schauen ob es besser ist.
Zum GDOS, theoretisch müßte R.O.M. logicware Quellen haben. Zumindest haben sie mal eine SpeedoGDOS 4.2 veröffentlicht. Ansonsten hatte no Software (Vertrieb: Compo) die Quellen und die letzten bis Version 5.5 gemacht.

Gerhard

ja, gdos gibt es schon lang, aner kein gdos ausser nvdi machte bisher den Aufwand, auf das Drucker-Gerät ädequate Treiber zu packen. Das war ja im Prinzip auch gut und funktionierte solange bis Entwicklung stattfand. Die Entwicklung steht still und mittlerweile sind 12 Jahre und ein neuer bevorzugter Drucker-Port mit verschiedenen Spezifikationen ins Land gegangen. Und die Art der Verbiegung des Systems durch nvdi maxcht es heute schwierig, es zu erneuern.

Eugentlich müsste der Falke-Verlag im zuge des Erwerbs der TOS-Lizenz auch Speedo haben.
« Letzte Änderung: Mo 11.04.2011, 23:13:56 von michschmi »