letzter Beitrag von syshack am
Naja, die "Intelligenz" der USB-Drucker liegt heute nicht mehr im Drucker selber sondern der angeschlossene Computer muss das ganze Blatt/Seite aufbearbeiten und über USB zum Drucker schicken, mit solchen umfangreichen USB-Druckertreiber wird der C64 aber überfordert sein
Ja, es gibt GDI-Drucker. Die können heute aber alle (auch/wieder) PCL und Postscript, manche auch noch andere Emulationen.
Naja, die "Intelligenz" der USB-Drucker liegt heute nicht mehr im Drucker selber sondern der angeschlossene Computer muss das ganze Blatt/Seite aufbearbeiten und über USB zum Drucker schicken, mit solchen umfangreichen USB-Druckertreiber wird der C64 aber überfordert sein
OK; ich kenne mich mit den Protokollen für die Printer nicht so aus.
Die Frage ist, ob eine Seite gepackt an den Drucker gesendet werden muss, oder ob auch ein senden von Zeichen, bzw Pixeln möglich ist.
In diesem Fall könnte der CEVI das schon schaffen, wäre halt nur etwas langsamer.
Im notfall müsste man halt eine Raspberry dazwischen hängen, dass die Druckaufträgt von CEVI übernimmt und an den Drucker weitergibt.
So gesehen überarbeite ich meinen Vorschlag noch mal in:
Es wird langsam Zeit für einen User-Port-Raspberry-USB-Adapter.
Und weiterhin: Freiwillige vor.
Mal so in den Raum geworfen: LAN.
So was soll das jezt heißen, fragen sich sicher einige. Weiß ich doch nicht! Ich bin müde und fantasiere gern 
Ernsthaft: Wäre nicht ein "Druckertreiber" für Netzwerkdrucker die schönste Lösung? Vorteile: über lange Strecken drucken, im Heimnetzwerk integriert, Drucker bereitet die Druckdaten auf (träume ich vielleicht nur, aber die Netzwerkdrucker sind doch keine GDI sondern mit Druckprozessor)
Dank Servant64 / RRnet / 1541u1net ...sicher keine falsche Idee, hm? 
Mal so in den Raum geworfen: LAN.
So was soll das jezt heißen, fragen sich sicher einige. Weiß ich doch nicht! Ich bin müde und fantasiere gern
Ernsthaft: Wäre nicht ein "Druckertreiber" für Netzwerkdrucker die schönste Lösung? Vorteile: über lange Strecken drucken, im Heimnetzwerk integriert, Drucker bereitet die Druckdaten auf (träume ich vielleicht nur, aber die Netzwerkdrucker sind doch keine GDI sondern mit Druckprozessor)
Dank Servant64 / RRnet / 1541u1net ...sicher keine falsche Idee, hm?
Ich habe mir auch über die Thematik Gedanken gemacht. Eine Netzwerklösung hört sich toll an, aber die Kompatibilität zu den bestehenden Anwendungsprogrammen aus den 80ern/90ern kann man wohl vergessen.
Die meistens Programme bieten den Ausdruck für MPS801/803 oder Epson FX via serielle Schnittstelle, also Device 4 an. Einige über den Userport.
Die kompatibelste Lösung wird IMHO sein, für einen externen Rechner wie z.B. ein Raspi einen Drucker Emulator "Zwischenspeicher" zu schreiben, welcher per IEC angeschlossen wird.
Idealerweise sollte dieser so modular gestaltet sein, dass man unterschiedliche Druckertreiber als PlugIns realisieren kann und dann Drucker-Plugins wie einen MPS801, MPS802, MPS803, MPS1230, Epson ESC/P, IBM Proprinter, HP-GL, PCL und Postscript (letztere zwei z.B. für GEOS) etc. bauen kann.
Da der C64 auch damals immer auf den Drucker bzw. den Ausdruck warten musste, stelle ich mir etwas naiv die Implementierung des IEC Protokolls und Timingsgedöns als weniger zeitkritisch an als bei einer IEC-Floppy-Emulation.
Der Ausdruck soll dann wahlweise in ein Grafikfile wie auch beim VICE oder PDF gehen.
Wenn man diesen Teil mal hat, ist schon viel getan. Der nächste grosse Sprung wäre dann, eine Netzwerk-Funktionalität einzubauen, dass ein Netzwerkdrucker direkt angesprochen wird, und dann ein Ausdruck darauf möglich wäre.
Ich weiss nicht wie gut die Unterstützung von den Raspi OS für Drucker ist, aber Postscript und PCL sollte nicht so ein Problem sein, denke ich mal.
ich hab mir das WLan-Userport-Interface von Leif Bloomquist gekauft.
wäre doch eine geile Sache, wenn man von GEOS aus auf den Netzwerkdrucker drucken könnte.
ob das überhaupt funktionieren könnte weiß ich nicht, wäre aber mal gut durchzudenken.
ich hab mir das WLan-Userport-Interface von Leif Bloomquist gekauft.
wäre doch eine geile Sache, wenn man von GEOS aus auf den Netzwerkdrucker drucken könnte.
ob das überhaupt funktionieren könnte weiß ich nicht, wäre aber mal gut durchzudenken.
Wie oben schon erklärt, finde ich die kompatibelste Lösung wäre es auf eine Emulation eines verbreiteten Druckers von damals zu setzen, wie z.B. MPS801 oder ESC/P (Epson) , welche die Daten entgegennimmt und dann in ein standardisiertes Format wie Postscript abspeichert oder es an einen PS Drucker weiterleitet.
Wie es das macht, ist dann der Lösung überlassen, also LAN oder WLAN. Über WLAN müsstest du einen Server haben, der die Datenentgegennimmt und im LAN Segment an den Drucker schickt. Direkt an den Drucker gehr nur, wenn du eines der propertären WLAN Protokolle umsetzt. Da gibt es mindestens was von HP und Apple was.
Eine Hand voll Emulationen, sprich 2-3 Commodore MPS und ESC/P würden doch vollkommen reichen, um alle C-64-Programme mit Druckfunktion abzudecken. Nadeldruckerausdrucke sind letztendlich immer Bitmaps, auch Textdruck kann man mit Bitmapfonts im Druckeremulator in eine Bitmap drucken. Und so eine Bitmap kann man an CUPS unter Raspian übergeben, welches das dann auf beliebigen Druckern ausgeben kann.
Genau das habe ich als Idee auch fürs CosmosEx an den Entwickler vorgeschlagen, und der findet die Idee gut und umsetzbar. Beim CosmosEx handelt es sich um einen Floppy und Festplattenemulator für den ATARI ST/TT, der auch Netzwerklaufwerke am Atari einbinden kann. Im CosmosEx läuft ein RaPi. Die Idee ist, den CosmosEx auch noch den an der ASCI Schnittstelle (also genau wie eine ATARI Festplatte) angeschlossenen ATARI SLM 804 Lasdrdrucker emulieren zu lassen. Die Seiten werden bei dem Drucker im Speicher des Atari ST/TT gerendert und als Bitmap über ACSI an den SLM geschickt. Der CosmosEx soll diese Bitmaps empfangen und sich dabei gnaz genau wie ein SLM verhalten. Dann wandelt er das in das Format um, welches CUPS benötigt und CUPS schickt das dann an beliebige Drucker raus.
Das selbe sollte sich als Nadeldruckermeulation für den C-64 auch machen lassen. Man bedenke, man könnte dann z.B. auch direkt in PDFs drucken.
Die kompatibelste Lösung wird IMHO sein, für einen externen Rechner wie z.B. ein Raspi einen Drucker Emulator "Zwischenspeicher" zu schreiben, welcher per IEC angeschlossen wird.
Idealerweise sollte dieser so modular gestaltet sein, dass man unterschiedliche Druckertreiber als PlugIns realisieren kann und dann Drucker-Plugins wie einen MPS801, MPS802, MPS803, MPS1230, Epson ESC/P, IBM Proprinter, HP-GL, PCL und Postscript (letztere zwei z.B. für GEOS) etc. bauen kann.
Da der C64 auch damals immer auf den Drucker bzw. den Ausdruck warten musste, stelle ich mir etwas naiv die Implementierung des IEC Protokolls und Timingsgedöns als weniger zeitkritisch an als bei einer IEC-Floppy-Emulation.
Der Ausdruck soll dann wahlweise in ein Grafikfile wie auch beim VICE oder PDF gehen.
Ich habe hier so einen Drucker-Spooler rumfliegen, könnte man den nicht als eine Art Zwischenspeicher einsetzen und
dann umsetzen auf z.B. Postscript.
Dann könnte man sofort am Cevie weiterarbeiten.
Das wäre doch was als Grundlage.
Hier mal ein paar Bilder:
Da der C64 auch damals immer auf den Drucker bzw. den Ausdruck warten musste, stelle ich mir etwas naiv die Implementierung des IEC Protokolls und Timingsgedöns als weniger zeitkritisch an als bei einer IEC-Floppy-Emulation.
Man könnte auch einfach faul sein und eine schon funktionierende IEC-Implementierung aus einem existierenden IEC-Laufwerks-Projekt übernehmen (unter Beachtung der Spielregeln) und müsste sich dann zumindest um den Teil keine Sorgen mehr machen.
Floppy oder Drucker macht auf dem Bus erstmal keinen Unterschied vom Timing her, der Drucker darf ja keine anderen Geräte durch seine Anwesenheit stören und die IEC-Routinen auf C64-Seite sind auch die gleichen.
Könnte man nicht in die SD2IEC FW einen virtuellen Drucker einbauen und die Druckausgabe als Bitmap, PNG, whatever speichern? Könnte man dann bequem zum PC tragen und ausdrucken wenn man es wirklich auf Papier haben will.
Man könnte auch einfach faul sein und eine schon funktionierende IEC-Implementierung aus einem existierenden IEC-Laufwerks-Projekt übernehmen (unter Beachtung der Spielregeln) und müsste sich dann zumindest um den Teil keine Sorgen mehr machen.
Da gibst eine Variante davon, die hat USB und die hat - wenn ich mich recht erinnere- sogar eine rudiemntäre Vorbereitung für Ethernet. Die könnte man doch nutzen, um da direkt einen USB-Drucker oder einen über Ethernet und z.B. LPR anzusteuern?
Da gibst eine Variante davon, die hat USB und die hat - wenn ich mich recht erinnere- sogar eine rudiemntäre Vorbereitung für Ethernet. Die könnte man doch nutzen, um da direkt einen USB-Drucker
USB Host geht nicht. Der Hostcontroller in dem Chip hat einen Bug, der selbigen in manchen Situationen zum kompletten Stillstand bringt, bis man den Chip vom Strom getrennt hat. Es gibt keinen Workaround.
Zitatoder einen über Ethernet und z.B. LPR anzusteuern?
Ethernet ist eh nur auf ein paar Lötpads und war nur zum Rumspielen auf der Platine. Tests haben ergeben, dass das Layout zu schlecht ist, um einen stabilen Link aufzubauen.
ZitatLeider hat der einst enthusiastische Entwickler
...nicht mehr so viel Zeit für Softwareentwicklung wie früher.
ZitatEin paar Leute, die sich große Hoffnungen auf diese neue Hardwarevariante gemacht haben
...sind zu blind zu zu erkennen, dass sie auch so von Features profitieren, die sie anderswo nicht oder nur in abgespeckter Form bekommen. Es gibt da z.B. diesen Anschluss für ein Parallelkabel, der mit (der richtigen Version) von DolphinDos genutzt werden kann. Auch in anderen Bereichen wird mehr geboten, z.B. ist das EEPROM-FS mehr als doppelt so gross und auch wird das zusätzliche RAM als Cache verwendet.
Zitatdie sich z.B. ohne eigenen Programmieraufwand leicht um ein zusätzliches Display erweitern ließen.
Tja, leider gibts viel zu viele Leute die nur lautstark meckern und nur sehr wenige, die mal einen Finger bewegen, um einen aus ihrer Sicht bestehenden Missstand zu beseitigen. Vielleicht wäre es besser gewesen, wenn ich mich 2007 in erstere Gruppe eingeordnet hätte und nicht in letztere.
Oder man betrachtet es marktwirtschaftlich - vielleicht ist die Nachfrage nach einer Displaylösung nicht gross genug damit sich jemand mal die Mühe macht, etwas fertiges anzubieten? Die Platine, über die du hier so sehr jammerst (und die du vermutlich problemlos verkaufen könntest wenn die Situation denn so unaushaltbar ist) unterstützt ohne weiteren Programmieraufwand schon jetzt die Lösung mit dem I2C-Display mit Eigenintelligenz.
Zum Thema Druckeremulation gibt es tatsächlich was Neues, allerdings für Ultimate 1541 II Besitzer:
https://www.facebook.com/photo…4035472753&type=3&theater
Ist zwar noch nicht spruchreif, aber Gideon unterstützt die Idee.
