Posts by Crass Spektakel

    Windows 10 hatte ich auch mal auf einem Pi4 und einem Netbook mit Atom N270 installiert.


    Von Windows 11 erwarte ich keine bessere Benutzbarkeit.


    Es geht grade so. Die Oberfläche läuft nicht in Zeitlupe, Libreoffice, Wordpad uswusf laufen brauchbar, sogar Steam und ein paar extrem einfache Spiele sind ok. Wobei Steam z.B. eine permanente Grundlast von 15% erzeugt wenn man es ohne "-miniconsole" oder so ähnlich startet. Schlimm wird es wenn man im Internet surft. bOhne Noscript im Firefox rennen Websites wie Heisedotde oder newsdotgoogledotde glattwegs in einen Timeout. Mit Noscript und sehr sparsam erlaubten Scripten kann man zäh surfen. Und nein, uBlock ist da keine Alternative da selbst der Unterschied zwischen uBlock und Noscript schmerzhaft ist. Übrigens, der alte Edge 1 Browser - ist ja lange deprecated und durch den Chrome-Clone Edge ersetzt - war MASSIV performanter als Chrome oder Firefox auf dieser Plattform. Es ist sehr schade daß Microsoft Edge1 defakto begraben hat, das Ding war superschlank und flink. Unter Windows würde ich trotzdem Edge2 als performantesten Browser betrachten, selbst Chrome oder Vivaldi kommen da nicht ran. Aber der Vorsprung ist nicht mehr so groß wie mit Edge1.


    Ganz schlimm sind Animationen oder - gottbewahre - Videos im Browser. Da läuft nichteinmal 240p ruckfrei. Ab einem N570 geht es oder mal spielt Youtube/Internetvideos einfach konsequent immer im VLC ab, der breaucht nur einen Bruchteil der Rechenlast und konnte auf menem N270 sogar 720p fast perfekt und auf dem N570 sogar 1080p perfekt abspielen.


    Interessanterweise läuft Firefox unter Linux besser. Weil die Hardwarebeschleudigung für GMA300/G945 unter Linux schlicht besser ist als unter Windows. Einen leicht auf 2Ghz übertakteten Pi400 würde ich als solide Surfstation betrachten, liegt leistungsmässig so irgendwo zwischen einem neuen Goldmont+ und einem älterem Core2.


    Als Laufwerke verwende ich an Pi4/Pi400 grundsätzlich externe gebrauchte SATA-SSDs der besseren Klasse. Alle paar Wochen erwische ich da eine gebrauchte Marken-SSD 60-120GByte für 4-8 Euro, oft sogar MLC und ein par Megabyte Cache, noch ein UAS-USB-Gehäuse oder USB-SATA-KAbel für €5 dazu und die Katze rennt. Der Geschwindigkeitsunterschied selbst zu schnellen USB-Sticks/SD-Chips ist GEWALTIG. Wobei ich in letztens sogar eine Samsung 830 Pro 240GByte für €11 erwischt habe. Glück braucht man halt. Mehr würde ich aber nicht zahlen weil man neue Geräte mit 120-240GByte auch schon für €15-€25 bekommt.

    ZZ9000


    M.E. brauchst du erst mal IDE.


    IDE-CF-Adapter

    Danke für die Vorschläge, ja in die Richtung will ich.


    Also preislich ist die ZZ9000 garnichtmal so schlecht. Als ich das erste mal von der hörte hätte ich mit einem höherem Preis gerechnet. Das wäre wirklich "the final solution" und bringt restlos alles mit was man irgendwie jemals brauchen könnte. Einzig die Tatsache daß anschliessend meine Piccolo und Ariadne arbeitslos werden ist ein wenig bitter.


    Für meinen Amiga 1000 mit A590 stellt sich die gleiche Frage.


    Mit den hier genannten Tipps bin ich bei amigashop.eu und Vesalia über Adapter von SCSI auf SD gestolpert, der ist mit €60 recht überschaubar. Taugt sowas Schafft das wenigstens 1-2MByte/s?


    Alternativ würde natürlich auch ein PiStorm drauf laufen was ja noch spannender und günstiger wäre.


    Gäbe es den PiStorm für den Amiga3000 wäre die Diskussion schnell erledigt.

    ich habe noch ein paar SCSI-Platten auf Lager, aber erfahrungsgem. ist es nur eine Frage der Zeit bis die Teile die Grätsche machen. In der Bucht würde ich auch nicht mehr nach Ersatz suchen, wer weiß schon wie lange die nächste gebrauchte Platte hält.


    Wäre ein IDE-Controller keine Alternative. Gibts nagelneu für ca. 60 € und daran kann man CF-Karten oder DOMS klemmen.

    Bei mir sieht es ähnlich aus, an SCSI-Platten habe ich keinen Mangel aber das Zeug ist so alt daß ich das Vertrauen verlohren habe. Zumal das teilweise schon recht schräge Dinger sind. In der Grösse 2-4GByte habe ich noch ein paar normale Fast-SCSI-Platten, darüberhinaus aber nur noch UWSCSI, teils sogar die 80pol-Variante die nur noch LVD kann, und das bringt am Amiga3000 auch nichts. Mit einer SSD jehnseits der 10GByte könnte ich auch etwas mehr mit NetBSD experimentieren.


    Derzeit habe ich auf der 4,5GByte HD 2,2GByte für AmigaOS, 2,2GByte für Debian 4-m68k und eine zweite 2GByte HD mit NetBSD. Alles auf einer 120GByte SSD wäre natürlich schöner und dann müßte ich auch nicht länger beim Platz sparen.


    PS, Image von der HD habe ich mir schon mit dd gezogen, also wenn die abraucht ist erstmal nix kaputt.

    Meine alte 4,5GByte HD stirbt gerade langsam. Verbaut in einem Amiga 3000 mit 16MByte FastRAM, Piccolo-32Bit-Grafikkarte, Ariande-Ethernet und Multiface3-IO-Karte.


    Da ich noch ein paar 120/240GByte SATA-SSDs herumliegen habe würde ich gerne preiswert diese Gerät im Amiga verwenden.


    Was sind denn die günstigsten und was die vernünftigsten Lösungen um eine SATA-SSD am Amiga zu verwenden?


    Was ich bisher gesehen habe sind nur sündhaft teure SCSI-zu-SATA Adapter, längst ausverkaufte Zorro-Karten.


    Günstig = Keine Bells und Whistles, einfach nur eine bezahlbare und halbwegs flotte Zorro3-Karte die mit 2-4 SATA-Laufwerken umgehen und booten kann.

    Vernünftig = wenn für überschaubares Geld noch zusätzliche Nützlichkeiten zu haben sind würde mich das schon interessieren. z.B. USB oder GPU oder Ethernet. Hauptsache der Rechner kann davon booten.


    Oder gibt es andere Flash-Lösungen für den Amiga3000 die günstiger kommen? Irgendwelche SD/Compactcard/sonstwas Lösungen?

    Was ich noch dunkel erinnere ist, dass manche meiner Freunde sich auf ebendiese original Commodore Speichererweiterung 256K, die in die Front des 1000ers reingesteckt wurde, Huckepack nochmal 256K zusätzlich raufgelötet haben. Dabei wurden die zusätzlichen Speicherchips auf die bereits vorhandenen raufgelötet ...


    Dieser Speicher musste dann aber auf der CLI oder startup-sequence noch extra irgendwie eingebunden werden ... damit er genutzt werden konnte... dann hatte man damit 256k onboard + 2*256K Expansion in der Frontklappe ...

    Jein, es war üblich diese Karten von 256 auf 768kByte aufzurüsten, also zwei RAMs draufzulöten. Ein paar Kabel mußte man auch noch innen in den PC verlängernd reinlegen. Damit kam der Amiga auf 512kByte ChipRAM und 512kByte SlowRAM. Alternativ konnte man den Amiga auch ohne diese Trapdoor-Erweiterung auf 1024kByte aufrüsten indem man direkt im inneren die Bausteine und Kabel verlegte. Das wurde sogar mal in der 68000er oder Happy Computer als Artikel abgedruckt und war spottbillig. Interessanterweise war der interne Einbau fast identisch zu ähnlichen Umbauten am Atari ST.


    Das mit "addmem" ist korrekt und hat ein paar witzige Stolpersteine. Hat man das RAM komplett intern verbaut erkannte der Amiga nur 256kByte und man mußte einmal 256kByte ChipRAM und einmal 512kByte SlowRAM mit addmem anmelden was dazu führte daß das ChipRAM partitioniert war und man z.B. nicht im Stück 300kByte ChipRAM nutzen konnte. Und Bootloader sahen natürlich auch nur 256kByte.


    Mit addmem konnte man noch andere lustige Sachen machen, z.B. das IO-RAM eines Sidecars/A2088/A2286 als FastRAM anmelden solange der PC nicht emuliert wurde. Das waren 128kByte geschenktes FastRAM.


    Theoretisch gingen sogar mehr als 1024kByte aber das war halt SlowRAM. Nicht erstrebenswert. Keiner meiner Amigas (500-3000) hat SlowRAM, hab das immer gezielt vermieden.

    +256K WOM war auf dem Mainboard dabei da wurde das Kickstart reingeladen...

    +256K RAM war auch auf dem Mainboard dabei

    +256K Frontside-Expansion wurde in Deutschland ab 1986 eigentlich immer dazugelegt

    Das WOM war bei einigen Amigas auf einer Extra-Platine die übrigens in einem ROM-tauglichen Sockel steckte und bei anderen direkt auf dem Mainboard. Die Extra-Platine hatte den Vorteil daß man das WOM einfach durch ein (EP)ROM ersetzen hätte können. Wenn es jemals passende ROMs dafür gegeben hätte ;-)



    --- schnipp ---


    Und jetzt was ganz anderes.


    Mein Amiga ist ein US-Model mit der Seriennummer 146. Ein lokaler Distributor hatte eine handvoll Geräte sehr früh und teuer direkt importiert und eines der Geräte seinem Sohn geschenkt.


    Der Sohn nutzte das Gerät kaum zwei Jahre ohne es auf PAL/DE umzubauen. Das 110V-Netzteil hang an einem externem 220-zu-110V-Wandler. Dann lies er den Amiga ungeliebt in der Ecke verstauben und verkaufte ihn mir um 1989 für 600DM. Ich ärger mich heute noch daß ich das Sidecar für 100DM nicht dazugenommen habe... Aber er gab mir ein Umbauset auf PAL/DE dazu, gratis, das lag jahrelang ungenutzt neben dem Rechner. Dafür fehlten sämtliche anderen Unterlagen.


    Interessante Features:


    -WOM/WCS sitzt auf einer Extra-Platine. Bei PAL-Amigas ist das nicht der Fall.

    -kein Extra-Halfbrite-Mode mit NTSC-Chips. Ich habe NTSC aber nur sehr kurz auf dem Gerät verwendet weil ich den 1100V-Wandler zurückgeben mußte und habe das Gerät anschliessend dauerhaft auf PAL umgebaut.

    -Innen und Aussen kein Schriftzug bezüglich "1000". Allerdings habe ich das Netzteil getauscht und das NTSC-Netzteil ist tief in der Bastelkiste begraben.

    -Die deutschen Tastenaufkleber sitzen auch nach 35 Jahren bombenfest.

    Beim Antworten auf einen anderen Beitrag ist mir gerade aufgefallen daß es ja einen Amiga mit nur 256kByte gab: Der Ur-Amiga aus der ersten Reihe. So einer steht sogar auf meinem Dachboden aber als ich ihn gebraucht erworben habe kam er schon mit 512kByte RAM die intern auf die alten RAM-Chips verlötet waren - sowas war anno tobak ja immer eine preiswerte Methode das RAM aufzurüsten.


    Was kann man eigentlich mit einem Amiga mit 256kByte anfangen? Ich schätze selbst mit Kickstart 1.0 war nach dem Booten der Workbench bestenfalls noch 180kByte frei.


    Hat jemand von euch jemals mit sowas gearbeitet?

    Und die Verarbeiten sogar "die gesamte MS/DOS"-Software. Soso. Windows 2.x (was auch '87 rauskam) auf dem Amiga 500. Das wärs (nicht) ;-)

    mit dem Sidecar war das wohl so...kleines unerwähntes Detail....

    Dafür brauchte man nichteinmal ein Sidecar, die Transformer-Software reichte ja. Und die lag imho dem Amiga 1000 serienmässig bei, vor Kickstart 2.0 konnte man das zumindestens nachkaufen.


    Und ja, Amiga Transformer war ELEND lahm und bot ausschießlich Textmodus. Imho lag die Leistung bei einem 0,5Mhz 8088. Spätere x86-Software-Emulatoren waren auf der gleichen Hardware locker drei bis viermal schneller. Beachtlich war aber daß relativ viel Speicher zur Verfügung stand. Imho belegte der Emulator nur 32 oder 64kByte so daß selbst ein 256kByte Amiga noch 192-224kByte nutzbaren DOS-Speicher anbot.


    Insgesamt war das aber eklatanter Quatsch. Der Transformer übernahm den Amiga komplett und ein Datenaustausch war praktisch nicht möglich. Was wirklich bescheuert war, der Transformer konnte Disketten voll MSDOS-kompatibel nutzen aber vom AmigaOS aus gab es noch mehrere Jahre keine Möglichkeit auf diese Inhalte zuzugreifen. Mit Speichererweiterungen und Harddisks oder anderen Upgrades konnte Transformer auch nicht umgehen. Updates gab es auch keine. Klassische Halbtot-Geburt. Hätte das Ding ein bischen Pflege erhalten (Multitasking, Datenaustausch) dann wäre das tatsächlich zu irgendetwas gut gewesen.

    MOD:
    xmp - module player supporting AWE32, GUS, and software-mixing
    timidity* - Software sound renderer (MIDI sequencer, MOD player)


    Leider kann ich nichts dazu sagen, wie performant oder resourcenschonend diese auf dem Pi laufen.

    Der Timidity-Hintergrunddienst läuft sogar auf Pi Zero aber dann bleibt für sonst nix Rechenleistung übrig. Man braucht das auch für viele Anwendungen/Spiele/etcpp die auf Midi angewiesen sind, z.B. Descent, OpenTTD. Auch viele DOS-Spiele im Emulator hören sich mit MIDI besser an als mit OPL. Als Soundbank ist freepats (imho vorinstalliert/abhängig) ein guter Anfang, grössere und bessere Soundbanks gibt es auf Fan-Sites, da bin ich allerdings out-of-date.


    Man kann die Config von Timidity per Hand editieren und ein paar Effekte ausschalten dann braucht es locker 90% weniger Rechenleistung, siehe Kommentare in /etc/timidity/timidity.cfg

    Ebenfalls hilft es das rtkit (Realtime Kit) per apt/dpkg zu deaktivieren/entfernen weil das zwar das Abspielen genauer macht aber auch die Rechenlast deutlich erhöht.

    Ohne rtkit und mit "slow CPU" rennt timidity sogar auf einem Amiga 1200 locker im Hintergrund.

    Im Paket alsa-utils findet man aplaymidi, einen sehr einfachen Midi-Player für die Kommandozeile. Schwierig ist es eigentlich nur das richtige Midi-Ausgabegerät auszuwählen, egal ob aplaymidi, VLC oder sonstwas...

    Soweit ich weiß, waren Intel und AMD bis einschließlich 486'er identisch. Erst ab Pentium hat AMD angefangen, wirklich eigene x86-kompatible Prozessoren zu entwickeln.

    Nope.


    Beim 386DX waren AMD und Intel technisch noch ident und arbeiteten mit den gleichen Masken auch wenn es den 40Mhz-Chip nur von AMD und in anderer Fertigungtechnik gab.


    Beim 486er war AMD dann selbständig. Zur Info, ein 486er ist kaum mehr als ein 386er mit Cache und FPU. Es ist wirklich so einfach, schalte bei frühen 486er (16-33Mhz) Cache und FPU aus und Du hast einen 386. Erst spätere 486er wichen von dieser Formel ab.


    Also war es für AMD ein einfaches den von Intel lizensierten 386 zu einem 486 aufzubohren. Wobei die AMD-486er sogar ein wenig mehr überarbeitet wurden und z.B. schrittweise bis zum 486dx4-133Mhz alias 5x86PR75 komplett umgekrempelt wurde, bei der vom Intel-Original kaum noch was übrig war. Mehr Cache, Writeback- statt Writethrough-Cache, überarbeitete Pipelines, überarbeitete ALUs/Multiplier/Burst-RAM-Zugriffe uswusf... nicht umsonst stellte der 486 bei 160Mhz oft sogar einen Pentium 100 in den Schatten...

    Die USB-Soundlösungen unterscheiden sich in der Klangqualität teils massiv.


    Für viel Geld gibt es natürlich tolle Lösungen aber wer nach günstig und gut sucht ist mit einem Speedlink Vigo gut beraten. Coronabedingt kostet das Gerät derzeit €10, vor Corona wars die Hälfte. Unter einem dutzend getesteter Low-End-Modelle war das nach Meinung mehrerer Bekannter der Testsieger auf einer LAN-Party.


    Einziger Nachteil, unter dem Namen gab es auch mal andere Lösungen. Also idealerweise mit Rücksenderecht testen.


    Das schafft es sogar mein Sennheiser Game One mit genügend Saft zu versorgen.


    https://geizhals.de/speedlink-…-8850-bk-01-a1599629.html

    mp3blaster ist ein sehr resourcenschonender Player der sogar auf 486ern im Hintergrund problemlos läuft. Selbst auf einem Pi3 liegt die Rechenlast unter 5% Prozent so daß mehr für andere Dinge übrig bleibt.


    Schön ist er zwar nicht, dafür einfach zu bedienen, unterstützt praktische Commandline-Parameter, ist Scriptfähig und läuft unauffällig im Hintergrund


    Und das Beste: SID-Files spielt er auch ab. Leider keine Amiga-Module.

    Mit 8GB lässt sich praktisch nichts machen mit einem Desktop Linux. Die ist ja sofort voll.

    Was nur wieder belegt, dass auch heute übliche „Desktop Linux“ Distributionen völlige Bloatware sind.

    Gibt es kein Puppy oder DSL für den Pi?

    Das Problem ist nicht "das OS". Ein Debian/Ubuntu-Minimal oder Debian/Ubuntu-LXDE-minimal saust selbst auf 2GByte Storage wie ein junger Dackel und da läßt sich auch mit Puppy&Co nicht unterbieten.


    Das Problem sind die Anwendungen. Ein Firefox und erst Recht ein Chromium sind eben fett und träge auf solcher Hardware.

    Aber was sind die Alternativen? Dillo? Kann der überhaupt noch Google darstellen? Lynx/W3M? Echt jetzt?


    Die sogenannten sparsamen Distributionen lehne ich inzwischen ab. Ja, sie verfolgen interessante Ideen die sich aber aus technischer Sicht nur auf eine passende Vorauswahl von Anwendungen mit geringem Verbrauch beschränken. Dafür sind sie notorisch veraltet und mit Updates unterversorgt. Immer. Besser man geht den Weg sich an einer sparsamen Distribution zu inspirieren welche Software wenig Resourcen verbraucht und dann installiert man genau das aus dem stinknormalem Packet-Manager auf der grossen Distribution.


    Exemplarischer Firefox-Exkurs: Beim Optimieren muß man vorsichtig sein. Schaltet man z.B. im Firefox die diversen Blacklists für Schadverhalten aus dann spart man sich zwar ein paar 100MByte Storage und RAM aber sitzt völlig nackt in einer bösen Welt. Schaltet man Caches im Arbeitsspeicher oder Massenspeicher ab kann das zwar kurzfristig was bringen aber nach dem nächsten Update braucht er vieleicht mehr aber darf nicht und läuft dann schlechter. Daher habe ich das Rumschrauben an Arbeitsspeicher-Cache-Einstellungen weitgehenst eingestellt - Massenspeichercache abschalten spart ein paar 100MByte und schon das Flash aber kostet deutlich Leistung wenn man Firefox öfters neu startet. Imho bringt es am meisten die Anzahl der Threads zu reduzieren - jeder braucht etwas mehr RAM - wenig Addons zu verwenden - und mittels ublock Origin oder noch besser No-Script alles zu blocken was man nicht braucht - es ist zum Staunen wie flott Firefox auf Ultra-Low-End-Hardware rennt wenn man mittels No-Script nur das allernotwendigste zuläßt. Und das allerbeste, selbst Puppy-Linux-Firefox ist langsamer als ein stinknormaler Windows/Debian/Ubuntu-Firefox den man manuel


    https://www.techosaurusrex.com…nd-laptops-and-computers/


    Nachtrag, das Entfernen der Locales bringt auch oft überraschend viel: https://wiki.debian.org/ReduceDebian

    Mir haben bisher immer englische und deutsche Locales gereicht.

    OK, das stimmt nicht so ganz

    Korrekte Einschätzung. ;) Es geht darum, herauszufinden, welchen Codec ein aktuell laufender (evtl. ruckelnder) Stream verwendet und nicht darum, herauszufinden, was es sonst noch so alles gibt. Und noch besser, als es nur herauszufinden, wäre es, auf YouTube einstellen zu können, welchen Codec man verwenden möchte. Andere Einstellungen, wie z.B. die Auflösung, kann man ja auch wählen.

    Das Firefox-Addon "Video Download Helper" kann zumindestens gezielt ein bestimmtes Format herunterladen.


    In gewissen Grenzen kann man das abzuspielende Format auch mit einem VLC-Plugin fest einstellen, dann schaut man das Video im VLC an der ohne viel weniger Leistung zum Abspielen als Firefox braucht. Theoretisch ist dieses Youtube-Plugin schon im VLC drin aber notorisch veraltet. Auf meinem uraltem EEE901 mit Ubuntu 18.04 kann man das wie folgt aktualisieren: wget "https://raw.githubusercontent.com/videolan/vlc/master/share/lua/playlist/youtube.lua" -O /usr/lib/i386-linux-gnu/vlc/lua/playlist/youtube.luac und in VLC kann man den Codec und die Auflösung einstellen (ich komm nur grade nicht drauf wo, ist verdammt gut versteckt).


    Natürlich kann man auch im Firefox was machen.. entweder schaltet man Codecs ganz ab oder man installiert ein Plugin, das folgende habe ich in einer Minute Google gefunden: https://en.blog.themarfa.name/…e-video-codec-on-youtube/ - diese Lösung gefällt mir zwar wenig aber Firefox und Chrome sind bei sowas hochflexibel und notfalls drückt man F12 und überschreibt im Debug-Monitor die Variable in der der Codec gespeichert wird.

    Problem daran ist, Pi ist arm. Die ganzen Games sind für x86/x64 programmiert. Dazu müsste man den ganzen Kram portieren. Wi

    Die meisten Mobil-Games erscheinen heute exklusiv für ARM. Man muß also entweder Android-Native oder einen Android-Wrapper nutzen. Bei der Rechenleistung kommt der Pi durchaus an ein zwei Jahre altes Mittelklasse-Gaming-Smartphone ran. Ob Fortnite darauf gut läuft kann man diskutieren aber z.B. GTA3 in der Android-Version läuft sehr gut: https://www.raspberrypi.org/forums/viewtopic.php?t=19949 - das lief sogar schon mit deutlich älteren Pis recht brauchbar.


    Der C64 wurde mit Sicherheit in mehr Büros verwendet als die CBM-Rechner, schonmal weil er billiger, kompakter war und mit mehr RAM kam - Visicalc, Vizawrite usw. machten doch erst mit 64kByte Sinn.


    An einem FBAS-Monitor war der C64 scharf genug, spätestens nach POKE53280,0:POKE53281,0:POKE646,5 kam echtes CBM-Feeling auf. 50hz-Flimmern gab es sowieso bei beiden.


    Ich merke gerade daß ich den CBM8296 mit dem MMF9000 verwechselt habe, das ist ein PET mit zusätzlicher 6809-CPU. Wozu das Ding gut war ist mir ein absolutes Rätsel...

    Die Nutzung als Spiele-Computer wurde nicht einfach freudig in Kauf genommen, sondern war (wenn man sich z.B. den VIC II und den SID anschaut) klar geplant. Für was außer Action Games benötigst du denn das schnelle Softscrolling und die vielen bunten Sprites und den 3-Kanal-Sound? Und für ernsthafte Anwendungen hatte Commodore (anders als Konkurrent Atari) ja auch noch die PET/CBM-Reihe. Beim VC20 hat Commodore schon die Erfahrung gemacht, dass Spiele sehr wichtig sind für eine Home-Plattform – und hat beim C64 dann in die Vollen gegriffen, was die Spieltauglichkeit anging. "Störte sie nicht" ist da krass untertrieben – es war das primäre Ziel.

    Der C64 war den meisten PET/CBM-Maschinen der ersten Generation (PET2001, CBM30xx) deutlich überlegen, schon wegen des grossen Speichers und des sehr günstigen Preises. Zusätzlich war der C64 zu diesen Rechnern sehr kompatibel was z.B. in meinem Bekanntenkreis ein Hauptargument für die Anschaffung des C64 war - man war ja mit CBM-Software perfekt versorgt, gerade in der Anfangszeit 1982/1983/1984 als des kaum native Software für den C64 gab.


    Daß der C64 keine 80 Zeichen darstellen konnte war je nach Anwendung ein Vorteil weil er so auch an billigen Monitoren und Fernsehern lief.


    Erst die zur CBM-Reihe völlig inkompatible 8296-Reihe übertraf den C64 in dieser Disziplin ohne aber darübehinaus irgend einen Sinn zu ergeben. Und da stimmt mir sicher jeder zu daß der C128 der 8296-Reihe deutlich überlegen war.

    Monitore/Glotzen sind hier eh genug vorhanden

    Wem es an Monitoren mangelt: Ein Gang auf den Wertstoffhof und man findet mehr brauchbare Monitore und Ferneher mit HDMI als man tragen kann. Selbst regulär gekauft kostet sowas auf Ebay oder Geizhals kaum mehr als ein Wurschtbrot.

    Hat die Series X so viel Power? Also meine GTX 1660 Super 6 GB Ram DUAL ADVANCED EVO kostet so um die 250 Euro, und ist richtig flott - siehe hier - für insgesamt 800 Euronen haste also nen flotten GamingPC.

    Nein. Nominell hat sie zwar die GPU-Eckdaten einer Radeon 5700 bezüclich Shader und CUs ist aber langsamer getaktet und muß sich den Bus mit der CPU teilen was gerade bei den grundsätzlich verschiedenen Zugriffprofilen verherrend ist - die GPU will grosse Datenblöcke im Stück transferieren und die CPU greift kreuz und quer auf kleine Einzelbröckerl zu, das GDDR6 ist aber für groses Blöcke optimiert wodurch die CPU und GPU sich gegenseitig oftmals bis zu 50 Taktzyklen ausbremsen. Es kann durchaus sein daß man synthetische Benchmarks basteln kann in denen XBX und RX5700 gleichschnell sind. Aber in der Praxis düfte sie rund 30% langsamer sein und damit zwischen RX5500/€200 und RX5600/€300 liegen.

    Dazu solltest du dir 'Log2RAM' anschauen. Schreibt die Logs in eine RAM-Disk und diese einmal pro Stunde oder beim Shutdown auf die SD-Karte.


    https://mcuoneclipse.com/2019/…berry-pi-lorawan-gateway/

    Das ist etwas redundant da man Logfiles auch gepuffert schreiben kann was die Last auf den Flash-Chips locker um 99% reduziert - war irgend eine versteckte rsyslog-Funktion oder alternativ das FS gepuffert ohne updated starten.


    Oder alternativ legt man /var/log ins RAM und weist das sowieso laufende logrotate an die Dateien einmal pro Stunde mit gzip/bzip2/xz zu komprimieren und nach /var/backup/log zu schieben.


    Angeber schreiben die Logdateien einfach auf einen anderen Server per Netz - das "R" in rsyslog steht nämlich für "remote", mit einer Konfigänderung schreibt dann der Pi-rsyslog die Dateien auf einen rsyslog eines anderen Systems ;-) Das war in der Uni immer lustig wenn auf hp00 die /var/log/messages ungelogen 2MByte/s wuchs weil rund 500 Rechner dort ihre Logs ablegten... wohlgemerkt, 1990 :-) Einmal pro Stunde Logrotate sonst wäre selbst das damals größte RAID nach einem Tag geplatzt...


    Faule Säcke wie ich lassen das Zeug einfach in der tmpfs/RAM-Disk verschimmeln, der Shutdown entsorgt sie dann normgerecht. Zumindestens auf reinen Arbeitsplätzen steht da nie was wichtiges drin. Auf meinem EEE901 LUbuntu18.04 32Bit oder dem Pi0 fallen da pro Tag keine 500kByte an Daten an. Server sind natürlich ne andere Geschichte.

    Fest verbauten Speicher finde ich hingegen keine gute Idee. Mit der SD-Lösung kann man schnell zwischen verschiedenen OS wechseln, je nachdem was gewünscht wird.

    Das eine schlließt das andere nicht aus. Einen Pi kannst Du wie einen Amiga oder einen PC sowohl vom internen als auch externen Speicher booten. eMMC wäre halt praktisch weils klein, preiswert und relativ performant ist.


    Es kommt aber natürlich immer auch drauf an was man so mit der Karte treibt. Im "normalen" Desktopbetrieb mache ich mir da nicht soviele Sorgen. Ich habe aber auch Raspis im Serverbetrieb laufen, bei denen sekündliche Logeinträge anfallen. Nachdem ich die erste SD Karte innerhalb eines Monats geschrottet hatte, habe ich die Logs ganz schnell in eine RAMdisk verlagert. Damit halten die Karten nun schon ein paar Jahre.

    Ja, das kenne ich auch. Gerade billige SD-Chips oder USB-Sticks halten nur ein paar hundert Schreibvorgänge pro Zelle aus. Mit ungepufferten Log-Dateien habe ich billige USB-Sticks an einem Tag geschrottet...


    Tipp, das Tool dumpe2fs gibt für Ext2-Ext4 Filesysteme die Menge der geschriebenen Daten seit Erzeugung des Filesystems an.

    Das Gaming Thema kann man gar nicht groß genug einschätzen, wenn man einen Computer erfolgreich machen will. Daaamals™ wie heute.

    Ja und eigentlich ist der Pi400 dafür garnicht schlecht.


    Die Leistung des Pi400 liegt um Faktor Zehn über Nintendo Gamecube, Xbox1, PS2, Wii und Faktor Zwei wenig über der Switch, XBox360, PS3 - selbst mit €500-Gaming-Smartphones kann es der Pi400 aufnehmen!!!


    Nur so als Beispiele, Fortnite, World of Tanks Blitz, Doom3, Halflife 2 gibt es native für ARM und laufen mit mehr oder weniger Tricks auf dem Pi400 und das macht grafisch schon etwas her. Java-Spiele laufen gut (Minecraft, Wurm Online), FDA/XDA/Mono-Spiele sind teilweise auch gut. Ich wette E-Sports-Titel wie Dota, CSGO, Fortnite kämen auch gut rüber. Portieren müßte man sie eben. Das ist weniger ein technisches als ein "lets do it" Problem.


    Das Problem: Die Nutzung vieler Spiele auf dem Pi400 ist schwierig. Man kann das Ding nicht einfach dem Sohnematz (oder in unseren Fällen eher den Enkeln) hinstellen und sagen "lad Dir mal Dota2 bei Steam runter". Da steckt sehr, sehr, sehr viel Arbeit dahinter und man muß regelmässig das OS wechseln. Z.B. läuft Fortnite "im Prinzip gut" aber eben nur unter Android. Also bootet man Android. Doom3 wieder läuft gut als 32Bit-Binary unter RaspberryOS und Minecraft wiederum läuft besser als 64Bit-Binary unter Ubuntu 20.10. Man wechselt dauernd...


    "Im Prinzip" wäre es sogar möglich alle genannten Spiele unter einem OS zu verwenden. Stichwort "Android unter Linux". Aber da ist das aktuelle RaspberryOS/Debian-32Bit nicht der richtige Ansatz, da muß man eher in Richtung eines angepaßten Debian64/Ubuntu64 sehen bei dem die Virtualisierungsfunktionen und Kompatiblitäts-APIs für Android+Google-Services, 32Bit und 64Bit ARM und eventuell XEN-86 integriert sind.


    Gäbe es ein besseres Basis-OS und darin eine Art Steam für den Pi bei dem man mit einem Klick das Spiel laden kann dann wäre das ein Killerfeature weil der Pi als Spielkonsole eigentlich ziemlich gut ist. Bis auf aktuelle Spielkonsolen kommt da derzeit nichts ran und die kosten "etwas mehr" als €70...


    Die echte Kröhnung wären natürlich Bare-Metal-Banging-Games. Aber naja, ich denke sowas werden wir in diesem Jahrtausend nicht mehr sehen...