Beiträge von mgroeber

  • Infos zum GEOS TTF-Treiber

    Danke für das Update, Jirka!

    Um diese Idee hier etwas zu unterstützen...

    Zitat von Jirka Kunze

    Dann muss die Performance des Treiber noch deutlich verbessert werden. Ein direkter Vergleich der Renderzeiten von Nimbus und TTF-Treiber wäre auch noch interessant um herauszufinden wieviel da noch zu tun ist. Da die Font Funktionen im Kernel quasi für die Struktur der Nimbus-Fonts 'maßgeschneidert' wurden wird der TTF-Teiber die Performance des Nimbus-Treibers nicht erreichen können.

    ...habe ich mal eine kleine Ergänzung an meinem Font Lister gemacht, so dass er auch die ungefähre Rendering-Zeit für einen Buchstaben anzeigen kann. Dazu werden die Buchstaben A bis Z nacheinander in 29pt (wofür es hoffentlich fast nirgendwo optimierte Bitmaps gibt) in einen Bitmap-GString gemalt und die Zeit gestoppt. Das geht zwar pro Systemstart nur einmal (danach ist der Font-Cache gefüllt), aber eine Idee gibt es schon mal. Im Moment würde ich grob einen Faktor 10-12 zwischen TTF und Nimbus sehen:

    Den Quellcode gibt es hier: https://github.com/mgroeber9110/freegeos-font-lister

  • Pi/GEOS Alpha!

    Hallo Thomas,

    die Frage hat zwar nur am Rande mit Pi/GEOS zu tun, aber mangels Pi zum Ausprobien frage ich einfach mal hier:

    Wie löst du das Problem mit der TLS-Kompatibilität beim Browser, da die Geos-SSL-Library ja nur sehr begrenzt HTTPS erlaubt? Benutzt Pi/GEOS einen lokalen Proxy?

    Ich versuche gerade, mir so was unter Windows aufzusetzen, um den aktuellen Browser in FreeGEOS mal etwas besser zu testen (via pppd und squid), aber vielleicht hast du ja ein eleganteres Setup gefunden.

    Hab es mal kurz hiermit probiert, aber noch ohne Erfolg: https://system7today.com/setup-crypto-ancienne

  • Internet-Verbindung aus der DOSBox per PPP?

    Zitat von t.hass

    Ich habe dann nacheinander SYSTEM/NET.GEO und SYSTEM/NETUTILS.GEO mit den Versionen aus BBX4.1.3 ausgetauscht: ohne Effekt. Danach SYSTEM/SOCKET/PPP.GEO und den Rest in SYSTEM/SOCKET. Das führt aber sofort zum KR-06/07 nachdem gewählt wurde.

    Der PPP-Treiber enthält gegenüber dem EtherODI/PKT ja auch C-Code. Vielleicht ist da ja was noch nicht sauber umgestellt.

    Danke für die Experimente! Mal überlegen, ob man das noch irgendwie einkreisen kann - wäre doch schön, wenn man die erste Relase von FreeGEOS auch mit Pi/GEOS laufen lassen kann. Kann natürlich wirklich sein, dass das Problem auf den PPP-Treiber beschränkt ist, dann wäre zumindest Falks Direktverbindung zur DOSBox davon nicht betroffen.

    ciao marcus

  • Internet-Verbindung aus der DOSBox per PPP?

    Zitat von t.hass

    in Pi/GEOS wird die Internetverbindung wie im von Dir verlinkten Posting aufgebaut. Das funktioniert auch mit allen GEOS-Version ab 3.1 nur nicht mit FreeGEOS. Daher ist es gut möglich, dass etwas in der von Dir ausgemachten Bibliothek fehlerhaft ist.

    Danke - das ist auch ein guter Datenpunkt. Wenn FreeGEOS unter Pi/GEOS auf diese nicht ins Internet kommt, das letzte Breadbox-Ensemble aber schon, ist das auf jeden Fall ein Grund, noch mal auf Fehlersuche zu gehen (z.B. durch Austauschen von Libraries), parallel zu den Experimenten von Falk mit einer direkten Verbindung über die DOSBox.

    Kannst du vielleicht etwas genauer beschreiben, was mit FreeGEOS auf dem Pi nicht funktioniert? Bei mir scheitert schon der Versuch, die PPP-Verbindung auszuhandeln (ich glaube, es endet mit mit einem LCP-Timeout).

  • Hat schon mal jemand probiert, ob Geos in TinyEMU läuft?

    Zitat von MeyerK

    Dieses Ding ist echt Klasse, weil man so auch immer schnell mal gucken kann, sich das offizielle GEOS verhält, wenn man beim Programmierrn unsicher ist ob man gerade einen Bug produziert hat.... wäre echt mega wenn wir das Ding an die CI hängen könnten, so dass automatisch mit jedem GitHub-Build auch so eine Referenzinstallation im Web erfolgt...

    Das wäre nicht so schwierig, man müsste nur den Code für den Emulator und die Seite auf dem gleichen Server hosten, auf den man auch die CI-Builds pusht, da sonst die Cross-Origin-Beschränkung des Browsers dazwischenfunkt.

    Das einzige, was noch nötig wäre, ist jeweils eine feste Konfigurationsdatei für jsdos in der hochgeladenen .zip-Datei zu ergänzen.

    Da Falk die Builds (soweit ich weiß) sowieso auf einem eigenen Jenkins-Server macht und dann auf Github hochlädt, könnte man das vermutlich recht einfach einrichten - vielleicht unter live.bluewaysw.de oder so, damit Build und Hosting in einer Hand bleiben.

  • Internet-Verbindung aus der DOSBox per PPP?

    Ich habe neulich mal einen Versuch gestartet, für das aktuelle #FreeGEOS einen einfachen, stabilen Weg zu dokumentieren, wie man unter Windows eine Internet-Verbindung ausprobieren kann.

    Dabei schien mir erst mal der Ansatz per PPP-Einwahl über ein simuliertes Modem am vielversprechendsten, wie er hier beschrieben ist. Perfekt wäre ein kleines Windows-Programm, das das Routing übernimmt, aber die Idee sollte sich erst mal auch mit dem WSL2-Subsystem für Linux in Windows verwirklichen lassen.

    Ich habe schon erste Kontakte zwischen dem pppd und GEOS in der DOSBox hinbekommen, aber noch keine echte PPP-Verbindung aufbauen können, über die sich Daten austauschen ließen (meist scheint es irgendeinen Speicherüberlauf im Umfeld von NetUtils zu geben).

    Hat jemand zufällig Erfahrung damit, ob das mit dem aktuellen #FreeGEOS überhaupt geht? Ich habe mich bisher noch nicht so detailliert mit dem Zustand des TCP/IP-Stacks beschäftigt, daher könnte es einfach sein, dass irgendein Feature in der GEOS.INI noch gar nicht richtig eingerichtet ist. Auch die Details der Modem-Emulation der DOSBox scheint stark vom verwendeten Fork abhängig zu sein, weil sie wohl fast nur für Multiplayer-DOS-Spiele genutzt wird.

  • Hat schon mal jemand probiert, ob Geos in TinyEMU läuft?

    Ich habe noch mal ein bisschen weiter experimentiert, im Moment mal mit js-dos, da es dort mit https://dos.zone/studio/ eine sehr einfache Möglichkeit gibt, ein .zip (wie z.B. von github) noch mit den nötigen DOSBox-Konfigurationsdaten "anzureichern" und dieses Paket dann mit ein paar Zeilen JavaScript im Browser laufen zu lassen.

    Nur mal als Idee ist hier die aktuelle (englische) Release von github (pcgeos-ensemble_nc.zip) - allerdings muss die im Moment noch als Kopie auf meiner Domain liegen, da der JavaScript-Client sie wegen CORS (einem Sicherheitsfeature) nicht von einem anderen Server holen kann und weil eben die [font='Courier New, Courier, mono'].jsdos/dosbox.conf[/font] noch zusätzlich im gleichen .zip benötigt wird:

    https://www.mgroeber.de/geos-live.html

    Als i-Tüpfelchen würde jetzt noch fehlen, einen neuen Geos-Build nicht nur bei github zu veröffentlichen, sondern auch auf einer anderen Domain, wo dann auch die Seite mit der DOS-Box im Browser liegt. Damit könnte man dann jeden aktuellen Build sofort im Browser ausprobieren, ohne irgendwas installieren zu müssen.

  • Hat schon mal jemand probiert, ob Geos in TinyEMU läuft?

    Zitat von bolle732

    Ist das _der_ Fabrice Bellard? Dem verdanken wir QEMU und die Anfangszeiten davon waren extrem spannend. Vorallem, wenn man mit den Programmierern noch direkt per Email Ideen und Probleme austauschen konnte...


    Ja, das müsste _der_ Fabrice Bellard sein. Von ihm habe ich erst neulich zum ersten Mal gelesen. Ich glaube, dass er auch FFMPEG initiiert hat - das ist wohl einer der großen Helden der Zunft...

  • Hat schon mal jemand probiert, ob Geos in TinyEMU läuft?

    Zitat von Rainer

    Schon cool! Bei mir ließ sich aber keines der GEOS-Programme starten. :(

    Stimmt - geht bei mir leider auch nicht. Da müsste man wohl noch ein bisschen herumexperimentieren. Was mir im Moment vorschwebt, wäre eine Webseite, die so einen DOS-Emulator enthält und sich jeweils das aktuelle Image von https://github.com/bluewaysw/pcgeos/releases/tag/CI-latest holt.

    Dann könnte man jederzeit die aktuelle Nightly-Version in einem Browser anschauen - natürlich nicht zum Arbeiten (weil man ja keine Dateien dauerhaft speichern kann), aber um schnell mal etwas ausprobieren oder zeigen zu können, ohne irgendwas installieren zu müssen.

  • Hat schon mal jemand probiert, ob Geos in TinyEMU läuft?

    Noch ein Fundstück zu diesem Thema: https://archive.org/details/breadbox-ensemble-lite-4.0.

    Hier hat jemand eine freie Demoversion von Breadbox Ensemble 4.0 auf Internet Archive hochgeladen, und zwar so, dass sie auch in einer DOSBox-Emulation im Browser läuft.

    Man kann also auf den Screenshot klicken, und es bootet tatsächlich ein benutzbares Ensemble im Browserfenster. Mit 3000 cycles nicht besonders schnell, aber das erste mal, dass ich so was in Aktion sehe.

    Nachtrag: Internet Archive benutzt wohl Emularity, das selbst wieder auf em-dosbox aufbaut (das ja auch schon in Jörg's Liste erwähnt war).

  • Hat schon mal jemand probiert, ob Geos in TinyEMU läuft?

    Ein Projekt, über das ich gerade zufällig gestolpert bin: https://bellard.org/jslinux/

    Dort gibt es verschiedene in VMs, die auf einem in JavaScript geschriebenen Emulator direkt im Browser laufen, sogar inklusive Windows 2000.

    Jetzt frage ich mich natürlich: hat das schon mal jemand mit Geos ausprobiert?

    Theoretisch würde das ja die Möglichkeit eröffnen, dass man ein aktuelles Geos direkt aus dem Quellcode erzeugt und daraus sofort ein Image für TinyEMU macht (zusammen mit FreeDOS), das dann jeder im Browser ausprobieren kann. Natürlich ohne dauerhaftes Speichern von Dateien und so, aber für den schnelle Einstieg ohne Installation und ohne Server wäre das vielleicht ganz spannend...

  • Fragen zu einem C-Code

    Der Ausdruck "src+dp" liefert dir einen Zeiger auf src[dp]. Zusammen mit dem ersten "*" im Makro hat das die gleiche Wirkung wie src[dp], aber hier eben erst, nachdem der Zeiger in einen Zeiger auf 16-bit Werte umgewandelt wurde.

    Diese etwas komplizierte Folge ist nötig, um zunächst die Zählung von dp in Bytes beizubehalten, dann aber von der Adresse am Ende zwei Bytes gleichzeitig zu holen.

    Und dann kommt noch le16toh() dazu, um ggf. die Reihenfolge von LE zu korrigieren.

    Ich würde persönlich eine etwas andere Form bevorzugen:

    Code
    base = src[dp] + (((uint16_t)src[dp+1])<<8);


    weil das ohne die LE-Funktion auskommt und das Umwandeln von 8-bit-Zeigern in 16-bit vermeidet, da manche Prozessoren Probleme haben, wenn man 16-bit-Werte von "ungeraden" Adressen lesen will. Aber das ist auch eine Stilfrage...

  • Fragen zu einem C-Code

    • Frage 1: der Grund ist in Zeile 14 zu finden - dort wird nrn aus der Variable src (also den Binärdaten, die dekodiert werden) geladen - und die ist uint8_t, weil die Daten byteweise interpretiert werden. Damit diese Zuweisung problemlos funktioniert, ist auch nrn als 8-bit-Wert deklariert.
    • Frage 2: zumindest wird bei diesem Geltungsbereich angenommen, dass die Werte nur innerhalb eines Schleifendurchlaufs verwendet werden. Über die Initialisierung wird nichts gesagt: es wird also nicht auf 0 initialisiert, wenn das nicht ausdrücklich dabei steht. Die Variablen haben also am Anfang der Schleife einen undefinierten Wert, der nicht garantiert ist und vom Compiler abhängt.
    • Frage 3: Ja, genau so ist es gemeint. Viele C-Programmierer mögen diesen Stil mit Zuweisungen in der Mitte von Ausdrücken auch nicht sehr, weil er leicht unübersichtlich wird und ein guter Compiler in beiden Fällen den gleichen Code erzeugen sollte.
    • Frage 4: Diese Darstellung liest erst das Byte an der Position dp ein und holt sich nur die oberen 4-bit davon. Anschließend wird dp um 1 erhöht. Wie du vermutestet, würde ++dp stattdessen das nächste Byte einlesen. Auch wieder so eine Optimierung mit "Seiteneffekten" (es wird nicht nur eine Variable geändert, sondern zwei), die aus Gründen der Lesbarkeit nicht unumstritten ist, aber für einfache, häufig vorkommende Aktionen wie "Byte holen und einen Schritt weitergehen" häufig verwendet wird, weil es eben schön kompakt ausdrückt, was man machen will.
    • Frage 5: in dieser speziellen Situation sind "++i" und "i++" gleichwertig, weil der Wert von i an dieser Stelle nicht verwendet wird. Das ist tatsächlich nur ein Befehl, der implizit als letzte Zeile der Schleife ausgeführt wird, und das Ergebnis der Rechnung ist egal. Der fehlende erste Teil bedeutet in der Tat, dass der aktuelle Wert von count einfach weiter gezählt wird.


    ciao marcus