Brotkastenfreunde 008: Interview mit Boris Schneider-Johne

Es gibt 76 Antworten in diesem Thema, welches 16.304 mal aufgerufen wurde. Der letzte Beitrag (5. April 2022 um 18:20) ist von Retro-Nerd.

  • Ja das ist normal bei dem Spiel, aber der zusätzliche Lag am TheC64 mini macht es ja trotzdem nicht besser. Man kennt das Spiel und sein Verhalten vom Original-C64 und wenn das eben zu stark abweicht dann lässt sich das kaum vernünftig spielen, egal um welches Spiel es sich handelt.

    - neue Spiele für den C64 -
    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • Ich hatte so'n Teil mal in der Hand. Technisch wissen wir ja alle, dass es nur ein Pc mit Emu ist. Von der Haptik wars reiner Schrott , eine Schande fürs Label. Selbst das Gehäuse des Maxis fühlt sich um Längen besser an. Webit muss man echt nicht haben

    Ich glaube das war gar nicht mal so schlimm, aber wann kam denn das Ding? 1998? Mit fast allem als Basis hätte ich das Gerät spannend gefunden: Linux, Windows NT, OS/2, vielleicht GeoWorks Ensemble * ... aber Windows 3.1 wollte ich zu dem Zeitpunkt niemals wieder nutzen. Der Softwareschock beim Umstieg vom Amiga auf den Pentium 75 war schon hart und ich froh dann endlich auf Windows 95 zu wechseln (endlich wenigstens lange Dateinamen!) und mit Windows NT 4.0 SP3 war das erste stabile System von Microsoft auch schon am Start. Da hätte ich mir Windows 3.1 mit Trumpet Winsock gewürge niemals angetan, das war damals auch nicht Retro (ein C64 schon) sondern einfach nur endlich überwundener Schund.

    * Wenn ich mir das so recht überlege, also mit Dualboot in den C64-Emulator oder GeoWorks Ensemble und einem Gehäuse in beige, wäre es tatsächlich gefühlt (für mich) ein echter Commodore geworden. :huh:

    Ideen, die ich mit eurer Hilfe gerne wahr machen würde:

    1. Eine wirklich neue Maus am C64 auf Basis der Bitte melde dich an, um diesen Link zu sehen.

    2. Die erste echte Maus für die 264er mittels Anschluss einer Bitte melde dich an, um diesen Link zu sehen.

  • Boulder Dash kenne ich nur als träge Version. Schon beim C64er damals musste ich mir angewöhnen, dass das Männchen erst nach einer gefühlten halben Sekunde auf eine Joystickeingabe reagierte. Lag vielleicht auch an meiner Schulhofversion?

    Nee, das muss so sein.

    Letzte Woche noch mit meinem Sohn gespielt - auf Original Hardware.

    Der Sound, wenn das Männchen mit den Hufen scharrt bevor er einen Schritt in die gewünschte Richtung macht "tscht, tscht, tscht" - unvergesslich! :emojiSmiley-23:

  • Habe den Podcast jetzt im der Bahn zwischen Hamburg und Hannover zu Ende gehört, tolle Folge, super Themenwahl. Werde jetzt sowohl Combian64 als auch BMC64 mal ausprobieren.

    Freue mich schon auf die nächste Folge!

  • Das ganze Heftchen ist ein Leporello und ich habe diese beiden Seiten gerde remote über den Scanner meiner Eltern zu mir geholt. Wenn Interesse am ganzen Dokument besteht, mache ich beim nächsten Besuch auch gerne mal ein Foto (ist ausgefaltet länger als DIN A4 hoch).

    Nun, so richtig hat da doch hier Keiner nach gefragt, aber da ich den Scan nun gemacht habe, will ich ihn mal einstellen ^^. Es ist schon erstaunlich, dass da ein Anwendungsszenario beschrieben ist, dass erst jetzt - mit dem Raspberry Pi400 - wirklich eingelöst wurde.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Ideen, die ich mit eurer Hilfe gerne wahr machen würde:

    1. Eine wirklich neue Maus am C64 auf Basis der Bitte melde dich an, um diesen Link zu sehen.

    2. Die erste echte Maus für die 264er mittels Anschluss einer Bitte melde dich an, um diesen Link zu sehen.

  • Sehr schoen, vielen Dank :)

    Ja, das Teil ist schon irgendwie ulkig.

    - neue Spiele für den C64 -
    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • mir ist dieses Teil so in 2010 mal zugefallen, ich habe es recht schnell weitergegeben. Es steht zwar Commodore drauf, hat aber rein gar nix mehr mit dem Hersteller zu tun. Nicht mal ansatzweise ist die Genetik von C zu erkennen.

    Es war aus meiner Sicht ein lieblos zusammengezimmertes Teil mit'm C Logo drauf. Da hat selbst mein C64 Maxi mehr Charme.

    Den WebIT sehe ich auf der gleichen Stufe wie diese billigen MP3-Player oder Telefone mit C-Logo drauf.

    Ich vermisse das Ding nicht, nicht mal aus Nostalgiegründen.

    "Ich bin das Schwert, ich bin die Flamme." (Heinrich Heine)

    „Lerne leiden, ohne zu klagen!“ (Friedrich III.)

  • Zum Thema HDMI Lag wollte ich auch eben noch meinen Senf dazugeben. Moderne HDMI Monitore brauchen kein volles Bild, die bauen es zeilenweise von oben nach unten auf, so wie es über das HDMI Kabel hereinkommt, genau wie alte Fernseher. Beamracing geht genauso auf HDMI wie auf CRT. Das wurde von den „Blurbusters“ schon vor langer Zeit genau aufgedröselt, und wird inzwischen nicht nur von FPGA Geräten wie MiSTer (im low lag Modus vsync_adjust=2) sondern selbst unter Windows im Amiga Emulator WinUAE (im „lagless Beamracing“ Modus) gemacht.

    Hallo, dieses Thema interessiert mich. Hast Du dafür Quellen?

    Und woran erkenne ich einen Monitor, der das kann?

  • Und ich dachte schon, es käme ein neuer Brotkastenfreunde Podcast. Hatte mich schon gefreut ... :emojiSmiley-17:

  • Zum Thema HDMI Lag wollte ich auch eben noch meinen Senf dazugeben. Moderne HDMI Monitore brauchen kein volles Bild, die bauen es zeilenweise von oben nach unten auf, so wie es über das HDMI Kabel hereinkommt, genau wie alte Fernseher. Beamracing geht genauso auf HDMI wie auf CRT. Das wurde von den „Blurbusters“ schon vor langer Zeit genau aufgedröselt, und wird inzwischen nicht nur von FPGA Geräten wie MiSTer (im low lag Modus vsync_adjust=2) sondern selbst unter Windows im Amiga Emulator WinUAE (im „lagless Beamracing“ Modus) gemacht. Das Retroarch kein lagless Beamracing kann, liegt nicht an HDMI sondern an der Libretro API. Die API kennt als kleinste Einheit nur ganze Frames, keine Streifen aus ein paar Scanlines.

    Ach, weil der Thread gerade aufpoppt, nochmal zwei Worte, äh Absätze zum Beamracing. Hier haben wir Äpfel mit Birnen verglichen.

    Was inzwischen geht, ist abzufragen, welche Zeile gerade über den HDMI-Out gegeben wird. Es gibt Emulationstechniken um damit Frame Lag beim Output (!) zu reduzieren und damit gewinnt man bestenfalls knapp (!) einen Frame. Auf einer sehr schnellen Maschine. Mit ständigem Nachgucken im HDMI-Output. Denn verständlicherweise ist das eigentlich eine auf moderner Hardware völlig sinnlose Funktion denn...

    (zweiter Absatz) den meisten Monitoren ist das stinkegal. Sobald es keinen Elektronenstrahl gibt, wird der Screen Refresh völlig unabhängig vom Input gemacht von einer internen Logik. Bestes Beispiel dafür sind alle Fernseher/Monitore die das Bild 100/120x in der Sekunde aufbauen um entweder durch kurze schwarze Frames den Motion Blur zu reduzieren, oder die Zahl der sichtbaren Farben zu erhöhen (das machen aus der Mode gekommene Plasma-Screens, die 8 Bit pro Kanal nur durch temporales Rauschen hinkriegen und die Topmodelle machen das mit 120 Hz (ich habe so eines besessen), angeblich passiert genau das auch bei preiswerteren HDR OLEDs), oder einfach Bildverbesserungseffekte (= alles außer "Game Mode") drüber zu legen. Und dazu wird in der Regel auch das ganze Bild gebuffert und hier holt man sich schnell ein bis zwei Frames unvermeidbaren Lag. (Was glaubt ihr warum alle guten Soundbars Fatures haben um den Ton mit dem Bild zu synchronisieren?).

    Ich wäre also auch sehr daran interessiert, welche HDMI-Monitore mit LCD, LED, OLED oder XYZ es gibt, die das Bild auch nachweislich zeilenweise in Realtime auf der sichtbaren Fläche refreshen (und nicht im internen Buffer beliebige Framerates akzeptieren).

  • Ich wäre also auch sehr daran interessiert, welche HDMI-Monitore mit LCD, LED, OLED oder XYZ es gibt, die das Bild auch nachweislich zeilenweise in Realtime auf der sichtbaren Fläche refreshen (und nicht im internen Buffer beliebige Framerates akzeptieren).

    Ein sehr interessantes Thema, das wir in einem eigenen Hardware-Tread besprechen sollten.

    Da wird sicher einiges an fachkundigen Posts zusammenkommen.

  • Ein sehr interessantes Thema, das wir in einem eigenen Hardware-Tread besprechen sollten.

    Da wird sicher einiges an fachkundigen Posts zusammenkommen.

    Au fein, dann hat sich mein Generve in dem anderen Thread ja doch noch gelohnt :)

    Ich glaube, der arme Unseen haette mich am liebsten geblockt (Sorry, Unseen)

  • (...)

    Und dazu wird in der Regel auch das ganze Bild gebuffert und hier holt man sich schnell ein bis zwei Frames unvermeidbaren Lag. (Was glaubt ihr warum alle guten Soundbars Fatures haben um den Ton mit dem Bild zu synchronisieren?).

    Ich wäre also auch sehr daran interessiert, welche HDMI-Monitore mit LCD, LED, OLED oder XYZ es gibt, die das Bild auch nachweislich zeilenweise in Realtime auf der sichtbaren Fläche refreshen (und nicht im internen Buffer beliebige Framerates akzeptieren).

    Zum ersten Kommentar: Nein, das ist schon seit Jahren nicht mehr so. Wennn Dein TV nur halbwegs modern ist von sagen wir mal den letzten 5 Jahren oder so, und im Gamemode ist, dann geht Deine Soundbar mit 0 Frames Delay. Wenn Deine Soundbar da eine Verzögerungseinstellung von mehr als Null braucht, dann ist Dein Fernseher ungewöhnlich lahm oder der Gamemode ist nicht aktiviert. Das wird auch auf Seiten wir rtings.com und anderen inzwischen immer wieder gesagt. Bei meinem Samsung ist es auch so: Im Gamemode kann die Soundbar mit Verzögerung "Null" gefahren werden.

    Zum zweiten Kommentar: Welche HDMI Monitore? Alle derzeitigen und aus den letzten zehn Jahren oder länger. Der Aufbau ist in einem etwas dickeren Streifen von oben nach unten. Die Ausnahme sind eigentlich nur ein paar antike Plasmabildschirme, die das Bild anders puffern und darstellen. Plasmas sind da ganz schlimm, was Lag und diesen komischen Bildaufbau angeht.

    Beweisvideos gibt es einige: Siehe zum Beispiel hier:

    Bitte melde dich an, um diesen Link zu sehen.

    Ganz aktuell zum Mythos Displaylag auch dieses Video von RetroRGB hier, wo genau gemessen wird:

    Bitte melde dich an, um dieses Medienelement zu sehen.

    Da wird es auch klar gezeigt: fast alle HDMI Displays haben weniger als einen Frame Lag, selbst billige. Deine "ein bis zwei Frames unvermeidbarer Lag" stimmen nicht. Es hilft nicht, wenn immer wieder Leute wie Du in Podcasts diesen Mythos vom Displaylag re-iterieren, der einfach schon lange nicht mehr stimmt.

    Ich habe auch vor kurzem an meinem MiSTer FPGA ganz eigenhändig einen totalen, gesamten Lag (von Knopfdruck am Controller bis Bildänderung am Bildschirm) von nur 4 ms gemessen, also nur 1/4 Frame. Das heisst, von Knopfdruck bis Reaktion auf dem LG LCD Monitor. Das habe ich getestet mit Leuchtdiode direkt am Controllerknopfkontakt, und mit 240 Hz IPhone Kamera. Siehe angehängtes Bild: Ein 240 Hz Frame Delay = 4 ms.

    Lakka am Pi 400 dagegen hatte mit optimalen Settings bei mir ganze 20 ms totalen Lag. Alles war gleich, nur Pi 400 mit Lakka 4.1 statt MiSTer. Bild auch angehängt.

    Ganz schlimm war aus irgendeinem Grund Retroarch auf Windows oder MacOS, da habe ich bei gleichem Setup bei MacOS 40 ms Lag und bei Windows 10 36 ms Lag. Eventuell gibt es da irgendwelche Settings um das zu reduzieren. Das waren in diesem Fall die Retroarch Standardsettings, allerdings mit Hard GPU Sync: ON und 0. Da habe ich auch ein Bild zu MacOS angehängt.

    Wie immer gilt: Behaupten kann man viel, aber nur die Messung entscheidet es dann.

    EDIT: Eine echte wissenschaftliche Herangehensweise würde diese Lagmessungen jetzt jeweils hundertmal wiederholen und dann Durchschnittswerte und Standardabweichungen ausspucken. In meinen Videos sind jeweils ca. 6 Messungen enthalten, und alle waren mit den gezeigten ms Zahlen in den Beispielbildern konsistent.

  • Zum Thema HDMI Lag wollte ich auch eben noch meinen Senf dazugeben. Moderne HDMI Monitore brauchen kein volles Bild, die bauen es zeilenweise von oben nach unten auf, so wie es über das HDMI Kabel hereinkommt, genau wie alte Fernseher. Beamracing geht genauso auf HDMI wie auf CRT. Das wurde von den „Blurbusters“ schon vor langer Zeit genau aufgedröselt, und wird inzwischen nicht nur von FPGA Geräten wie MiSTer (im low lag Modus vsync_adjust=2) sondern selbst unter Windows im Amiga Emulator WinUAE (im „lagless Beamracing“ Modus) gemacht.

    Hallo, dieses Thema interessiert mich. Hast Du dafür Quellen?

    Und woran erkenne ich einen Monitor, der das kann?

    Ja siehe meinen vorherigen Post einen drüber. Das aktuelle RetroRGB Video dort.

    Und Du kannst genau nachschauen in den Hardwarelisten und Lagtests bei rtings.com, was verschiedene Monitore für einen Lag haben:

    Bitte melde dich an, um diesen Link zu sehen.

    Da siehst Du das praktisch alle derzeit erhältlichen Bildschirme weniger als einen Frame, weniger als 16 ms Lag haben.

    Github: Bitte melde dich an, um diesen Link zu sehen.

    2 Mal editiert, zuletzt von rsn8887 (5. April 2022 um 07:39)

  • Das ist so auch korrekt. Das HDMI Signal selbst verursacht keinen Lag (da wird nichts beim Bildaufbau gebuffert). Das hatte, glaube ich, auch Mike Chi (Retro Tink Geräte) schonmal so erwähnt. Akuelle LCD TVs/Monitore oder OLED Geräte (LG würde ich da immer vorziehen) kann man bedenkenlos kaufen. Das Lag kommt vom Display, den Emulatoren samt OS, den Eingabegeräten und den TV Einstellungen (also alles außer den Game Mode). Aber auch das wird heute immer besser.

    Hier wird auch nochmal einiges zusammengefasst. Gibt sicher noch "wissenschaftlichere" Beiträge zu.

    Bitte melde dich an, um diesen Link zu sehen.

  • Eine andere Sache ist auch genial bei vielen modernen HDMI Monitoren:

    Die Zeiten dieser fest gelockten Displays mit einer festen Frequenz, also 120 Hz, 100 Hz oder so, sind schon lange vorbei. Moderne Monitore können sogar auch krumme Frequenzen (51 Hz, 49.2 Hz, 71 Hz etc) über HDMI tadellos darstellen, da wird jeder einzelne Frame angezeigt, ohne Mikroruckler oder verdoppelte Frames, und mit <1 Frame Lag. Speziell Displays, die Freesync oder G-Sync unterstützen, können das soweit ich weiss immer, aber andere auch, obwohl es eigentlich nicht dem HDMI Standard entspricht.

    Das ist total praktisch für Retrozocker. Die Ausgabe muss dabei nicht explizit das Freesync oder Gsync Protokoll unterstützen. Sie muss nur 1080p mit der krummen Frequenz statt 50 oder 60 Hz ausgeben können, und der Monitor synchronisiert sich dann automatisch drauf. Das "Frame Pacing" ist dann perfekt wie beim originalen Gerät an der Röhre.

    Zum Beispiel gibt das RetroTink 5x im Frame Lock Modus exakt die gleiche Frequenz über 1080p HDMI aus, die vom originalen Gerät kommt, also 51 Hz, oder 49.2 Hz oder was weiss ich der C64 oder das N64, was man anschliesst, genau ausspucken. Und das mit nur ca. 0.2 Frames Lag in der Konvertierung analog->HDMI.

    Beim MiSTer im Low Lag Modus ist es auch so: Der Atari ST Core im Monochrom Modus gibt sogar 72 Hz über HDMI raus, wie bei einem echten Atari ST. Selbst beim Amiga ist es nicht genau 50 Hz, sondern fast 51 oder so.

    Das Scrolling ist dann butterweich ohne einen einzigen Mikroruckler und in der exakten Geschwindigkeit des originalen Gerätes, und dazu noch mit viel weniger als einem Frame Lag.

    Solche Displays sind auch spottbillig. Mein LG IPS Freesync Monitor der das kann, hat unter $100 gekostet. Ich glaube, viele moderne Fernseher können das auch, speziell wenn sie VRR unterstützen.

    Anbei ein Bild vom Atari ST Core im MiSTer im Monochrom Modus: Der Monitor springt auf 72 Hz um. Die Frequenzanzeige beim Menü des LG Monitors hat leider keine Nachkommastellen und ist gerundet, aber die echte Frequenz ist ca. 71.5 Hz glaube ich.

  • Auch das stimmt. Das hatte PiCiJi ja nun endlich auch im Denise Emulator einbauen können. Das funktioniert dann natürlich auch mit der Original Hardware an Freesync/Gsync fähigen Bildschirmen, wenn ein guter Video Scaler dazwischen geschaltet ist (OSSC, Retrotink etc). Besonders interessant natürlich für Arcade Spiele, die mit 55-57Hz liefen. Die kann man auch in Original Geschwindigkeit laufen lassen, ohne die Emulation auf 60fps/60Hz erhöhen zu müssen (um ruckeln/tearing zu vermeiden).