Posts by Crass Spektakel

    Dafür müßte ja eine Line Doubling bzw. 3x-6x Funktion wie man das vom OSSC kennt mit rein. Für PAL bietet sich 5x halt an. Dann braucht man auch keinen Scaler Chip (der Input Lag generiert), da 5x288p = 1440p nativ. NTSC ginge auch noch pixelperfekt, 6x240p = 1440p)

    Wenn man sich heute für €20 eine 0815-Ansteuerungselektronik für LCD-Panels bei Alibaba kauft kann das Ding sowieso Scaling. Und zwar praktisch immer latenzfrei. Selbst die spottbillige Ansteuerungselektronik von TCL (€3) kann das und bietet sogar einen einfachen Glättungsfilter, berücksicht aber nur vier Nachbarpixel. Eine Luxusansteuerungselektronik aus der Studiowelt von Mitsubishi oder Samsung für sagenhafte €40 hat sogar einen Deinterlacer inklusive Software-Deinterlacing und einen 3:2 Inverse-Telesyn-Corrector integriert... Selbst das kostet nur einen Frame Verzögerung.


    Erst wenn man Zwischenbilder und solchen Quatsch berechnet muß man mehrere Frames Latenz hinnehmen. Was aber schlicht der Tatsache geschuldet ist daß man für Zwischenbilder mehrere Bilder zwischenspeichen muß.

    Nachteil: Für jegliche Form von Animation total ungeeignet. Altert sehr stark. Ich denke daß kein einziger dieser alten Monitore heute noch nennenswert nachleuchtet. Das Ding leuchtet im dunklen Zimmer nach dem Ausschalten 30 Sekunden lesbar nach.

    Die Alterung kann man sehr stark begrenzen, wenn man die Helligkeit deutlich reduziert und dafür die Umgebungshelligkeit reduziert. Große Helligkeit lässt die Röhre altern und stellt für die Leuchtschicht den Alterungsfaktor dar. Helligkeit deutlich reduziert lässt dagegen die Leuchtschicht nur sehr wenig altern und die Röhre hält was unbegrenzt.

    Du sprichst den schonenden Umgang mit der Elektronenkanone am hinteren Ende des Monitors an. Das ist korrekt.


    Ich meine aber die phosphoreszierende Leuchtschicht im vorderem Teil des Monitors. Von der imho die üblichen CBM-Monitore eben keine hatten (1762, 1801, 1081, 1084, 1085). Das gab es nur bei ein paar wenigen Modellen (imho 1082 und 1086 oder so). Die alltert einfach weil sie altert. Dafür reicht schon leicht schummrige indirekte Beleuchtung im Keller. Im Betrieb altert diese Schicht locker 50% alle 10.000 Betriebsstunden und selbst im Schummerlicht verliert das Ding 5-10% je nach Lichteinstrahlung. Da ist nach 30-35 Jahren selbst im lichtdichten Karton nicht mehr viel übrig. Zumal ich nur einen einzigen dieser Monitore je gesehen habe, nämlich auf einem Amiga-Club in den 1980ern. Dort hat man ihn mit Begeisterung verwendet aber nachkaufen konnte man den schon lange vor 1990 nicht mehr.


    Edit: Der halbwegs weit verbreitete A2024 hatte auch eine leicht phosphoreszierende Beschichtung. Allerdings konnte der sowieso kein Interlace und lief bei den meisten Anwendern mit 63hz. Daher leuchtete dieser Monitor auch nur relativ kurz nach. Das Bild war "wie geleckt" und ich wette selbst ein TFT-verwöhnter Anwender würde das Ding als perfekt ruhig und stabil bewerten.

    Grundsätzlich wird das Flimmern de Röhre selbst von 2 Faktoren bestimmt: Bildwiderholrate und die Leuchtcharakteristig des Phosphors. Es gab zu grünmonitorzeiten (auch in CBM geräten) stark nachleuchtendes Phosphor. Da hat der Cursor mehr pulsiert als Geblinkt. Für Text und büro geht das, aber ein Spiel würde in einer einzigen schmiererei enden


    Ich kann mir durchaus vorstellen, dass das Hirn hier lernfähig ist und das Flimmern mit der Zeit raus rechnet.

    Ich bin zB bei Farbrad DLP beamern sehr emfindlich, sitze aber lieben gerne auch vor meinem echt 50Hz trinitron und sogar meine Leinwand mit mit dem Röhrenbeamer (in dem Falle aber 75 oder 60hz beschickt).


    Es gab auch Farbmonitore mit extermer Nachleuchtdauer, sogar von CBM gezielt für den Amiga, z.B. der A1082 oder 1086 (bin mir bei der Bezeichnung nicht ganz sicher). Das sind schlicht Varianten des alten 1081 mit extrem hoher Nachleuchtdauer. Und damit meine ich eexxttrreemm. Sogar 50hz Interlace war damit erträglich. Ich war in meiner Jugend sehr empfindlich bezüglich 50hz und habe praktisch bei erster Gelegenheit meinen Amiga auf 60hz umgebaut und später per Software während des Bootens umgeschalten.


    Nachteil: Für jegliche Form von Animation total ungeeignet. Altert sehr stark. Ich denke daß kein einziger dieser alten Monitore heute noch nennenswert nachleuchtet. Das Ding leuchtet im dunklen Zimmer nach dem Ausschalten 30 Sekunden lesbar nach.

    Mal ne ganz andere Idee: Monitor als DIY!

    Im Ernst, es gibt bei Alibaba dedizierte Ansteuerungselektronik für LCD/TFT/IPS-Panels. Die kommen oftmals mit einem Firmware-Blop und manchmal sogar Tools um sie frei zu programmieren. Oftmals erledigt diese Elektronik auch Skalierung. Einige moderne Varianten können sogar selber Video-Datenströme dekodieren und diverse Filter anwenden. Ich denke auch das ist im Prinzip programmierbar aber wohl selten dokumentiert.


    D.h. man besorgt sich einen kaputten Schlepptop, baut das LCD-Panel aus, besorgt sich bei Alibaba für €20 eine passende Elektronik und trägt freie Sync-Bereiche ein. Größtes Problem: Die Elektronik die man dafür vor fünf Jahren verwendete bekommt man heute praktisch garnichtmehr. Ich hab damals einfach eine Forums-Empfehlung aus Linus Tech Tipps bei Alibaba für €13 gekauft, acht Wochen auf Lieferung gewartet und damit rumgespielt. Liegt seit drei Jahren samt Displays in einer Schachtel auf dem Dachboden weil ich irgendwann die Lust verlohren habe und mehr als genügend normale Monitore rumstehen habe.


    (Notiz an mich selber, ich wollte mal eine Umbauanleitung ausprobieren mit der der Touchscreen des Tablets-Displays entweder als Touchpad oder Touchscreen am Desktop-PC nutzbar wird. Leider ist das deutilch komplizierter als die Nutzung des LVDS-Displays, zumindestens wenn man das über USB extern anschliessen will - aber ok, das ist hier offtopic)


    Die Ansteuerungselektronik von "rohen" LCD-Displays ist ja hinlänglich bekannt, LVDS, RGB-TTL und mittlerweile MIPI. Das ist alles halbwegs normiert. Naja, ausser bei Apple, die geben sich richtig Mühe daß man ihre Displays nicht vernünftig weiterverwenden kann. Apple halt. Wenn man ein wenig im Internet sucht findet man massenhaft einzelne Ansteuerungselektronik für LVDS und ähnliches. Das ist sehr praktisch weil man so mit sehr wenig Aufwand z.B. das Display eines (defekten/veralteten?) Notebooks oder Tablet am PC nutzen kann. Begrenzt wird man praktisch nur durch die Anzahl der Monitoranschlüsse am PC. Und bei Displayport nichteinmal das weil da Daisychain geht.


    Aber halt. Kein Legacy-Computer hat HDMI oder gar Display-Port. Und ich kenne im Moment auch keine Ansteuerungselektronik mit VGA/RGB. Ich bin aber auch kein Fachmann für sowas.


    Siehe https://www.electro-tech-onlin…t-lcd-to-computer.148391/


    Diese Adapter kosten bei Alibaba oftmals unter €20.


    Ich habe aus einem alten 7-Zoll-Windows-Tablet und einem 12-Zoll-Android-Tablet die Displays ausgebaut und steuere sie mit einem ALPS (sind das die vom Floppy-Laufwerk?) Controller an. Da beide den gleichen LVDS-Anschluß verwenden ist der sogar mit einem ROSOFF mit zwei Handgriffen getauscht.


    Witziges Detail am Rande, meine Ansteuerungselektronik ist hinsichtlich der Bildfrequenzen sehr freizügig programmierbar. Im Prinzip interessiert das Panel nicht, man schickt ihm die Daten und entweder kann das Panel das darstellen oder halt nicht. Es ist also nicht so daß das Panel wie am PC rückmeldet "ich kann 60hz" sondern das entscheidet die Ansteuerungselektronik. Meines Verständnisses nach kann man ein LCD-Panel durch "Over/Underclocking" auch nicht schrotten. Keine Gewähr. Das Tablet-Display kann ich z.b. mit 75-90hz problemlos ansteuern obwohl es unter Windows nur 60hz schaffte. Wobei man ab 75hz häßliche Artifakte bekommt. Der Tablet-Bildschirm hingegen kotzt schon ab 65hz und schaltet hart ab. Sehr interessant ist daß beide Displays nach unten bis 15hz synchronisieren und zwar PERFEKT. Weniger kann ich schlicht nicht im Setup einstellen allerdings liegt die Firmware theoretisch als Binary Blop vor, ich müßte nur die Programmierpins mal drauflöten (scheint laut Anleitung eine Art TTL-basierte RS232-Geschichte zu sein). Auch lächerlich niedrige Pixelfrequenzen schlucken sie anstandslos.


    Hätte meine Platine einen VGA/RGB-Eingang wäre das die ultimative Lösung für Vintage/Retro/Legacy-Computing.

    Ein Retro-Monitor... was wär das geil.... Ob 4:3 oder 16:9 wäre mir egal hauptsache das Scaling klappt gut und man kann viel anschliessen. Das wäre ein Sofortkauf für mich.


    Eigentlich sollten LCD-Bildschirme unabhängig von der Frequenz immer ein scharfes Bild darstellen. Aber manchmal zweifel ich am Verstand der Entwickler.


    Beispiel, mein HP 2065 (IPS 1600x1200, 4:3, 20 Zoll) am Amiga: Er stellt absolute Quatschauflösungen PERFEKT dar, z.b. [email protected] interlace oder [email protected] progressive. Sogar [email protected] bis 50hz (das habe ich am PC und nicht am Amiga getestet mit handgebastelten X11-Modelines) progressive stellt er absolut scharf dar. ABER er blendet dann mitten ins Bild ein blaues Fenster mit weissem Warnsignal "Signal out of Range!" ein. Wohlgemerkt, es läuft ALLES perfekt, nur dieses nichtabschaltbare Fenster steht da mitten auf dem Bildschirm und verdeckt ein Drittel des Bildes. WTF...


    Oder der Noname-TCL Fernseher meines Nachbarn. Auf VGA/HDMI nimmt er HSYNC nur 31-75khz entgegen. Auf SCART-RGB allerdings alles von 15 bis 48khz. Bei VSYNC nimmt er auf VGA/HDMI 48 bis 72hz an, auf SCART-RGB 48 bis 62... WTF... immerhin, ein Amiga läuft über RGB überraschend gut, sowohl progressive als auch interlace, sogar ein paar krumme Sondermodi. Naja, ausser daß ein paar Randpixel flimmern und sich das Bild nicht gut einpassen läßt...


    Mein Amiga 500 läuft seit ein paar Jahren an einem LCD-Bildschirm mit 1024x768/14-Zoll/32768-Farben. Ist ein urururalter PC-VGA-Monitor und der schluckt witzigerweise 1024x768 bei 10hz. Gestochen scharf, es ruckelt lediglich sehr stark und Audio spinnt meistens. Und ja, dazu habe ich mir schlicht eine Custom-Resolution für mein ECS-Chipset gebastelt. Es läuft richtig geil. Auch das Umschalten auf andere Auflösungen sieht brauchbar aber nicht spitze aus.


    Der 3000er hängt im Moment an einer alten 17 Zoll Röhre. Ich weis auch nicht was ich da als nächstes machen soll, die Grafikkarte würde ich schon gerne weiter mit 1280x960 betreiben.


    Für die alten 8Bit-Rechner stehen noch ein paar 1081/1084 rum. Die gehen regelmässig alterbedingt kaputt aber da kenne ich die Sollbruchstellen, das ist normalerweise in einer Stunde nachgelötet. Bisher nur kalte Lötstellen und ein einziger kaputter Kondensator.


    Auch ein CRT muss nicht flimmern.. Denke an z.b 17 Zoll VGA- Monitor und 100Hz.. Der flimmert nicht mehr.

    Es gab ja auch speziell nachleuchtende Röhren, z.B. auch den CBM 1082 der so lange nachleuchtete daß sogar Interlace-Modi akzeptabel waren. Imho gab es auch bei der CBM-Multifrequenz-Baureihe (1940/1942/1960/usw) irgendein Modell welches ewig nachleuchtete. Nachteil: Für Spiele total unbrauchbar. Und baut mit der Zeit sichtbar ab. Keine Ahnung ob die alten Geräte heute überhaupt noch ausreichend nachleuchten.

    Die Frage hat sich mir auch gestellt, nachdem Brotbox64 den interessanten Link gepostet hat und meine Reaktion auf die Frage war der Gedanke: "So sieht also ein Fass ohne Boden aus." ;)


    Und dann habe ich einen Schritt zurück gemacht und mich gefragt: Was ist das Ziel der Veranstaltung? Spaß mit Pixeln und Retrofeeling? Herausforderung beim Game-Gestalten durch Limitierungen? Braucht man für die Ziele einen emulierten Fantasie-Rechner aus emulierten real existierenden Komponenten?


    Und dann habe ich mir das Open-Source-Projekt TIC-80 nochmal angesehen, weil die Grafikscreens dort auch eine Breite von 240 Pixeln haben und es auch als Bare-Metal-Projekt auf dem Raspi laufen soll. Mein Ziel ist, das mal zumindest in der Praxis als Bare-Metal-Version auf dem Raspberry Pi auszuprobieren, um zu klären, wie weit das davon entfernt ist, was "man" eigentlich erreichen will.

    Vor dem Pixel kommt immer erstmal die Kommunikation.


    Also würde ich als zweite Komponente nach der CPU immer RS232 integrieren. Ja, das bringt erstmal fürs Endprodukt keinen sichtbaren Nutzen aber immerhin kann man dann schonmal "irgendetwas" machen. Und sei es nur einen Speichermonitor oder Debugger verwenden. Ausser ein paar MAX232 und ein paar TTL-Pins braucht man dafür nicht viel. Und die MAX232 kann man auch weglassen wenn die Gegenstelle (z.B. ein anderer Raspi) auch TTL-Pegel verwendet. Dann reduziert sich die Hardware auf ein paar Kabel. Auch die Software ist sehr einfach und der Memory-Footprint geht gegen Null. Noch mehr Bare-Metal wäre nur machbar wenn man das RAM über Kippschalter direkt ansteuert :-)

    Dann hat man aber vermutlich keine Grafik und keinen Sound, oder? Sprich das muesste man von externen Chips erzeugen (oder ist der ESP8266 so leistungsfaehig, dass man auf dem parallel zum eigentlichen Programm noch das Grafiksignal erzeugen koennte?)

    Da hast Du mich kalt erwischt, der ESP8266 hat sowas natürlich nicht serienmässig. Auch gibt es da aktuell so gut wie nichts mehr.


    Aber vor ein paar Jahren gab es noch ein paar Micro-Controller-Units mit Grafik, die Option fehlt aber heute bei Geizhals komplett... verständlich, der kleinste Raspi kostet ja auch nur €5.... https://geizhals.de/?cat=hwepcmcu und https://geizhals.de/?cat=mbarm


    In der c't wurde vor fünf oder sechs Jahren mal ein Modell getestet mit 80Mhz CPU und LVDS-Monitorausgang. Ich glaube es hatte 32kByte RAM und 32kByte Flash und eine GPIO-Leiste die man auch nutzen konnte um eine PS/2-Tastatur anzuschilessen. Es gab dafür sogar ein Basic fürs interne Flash bei dem das MCU klassisch C64-like ins Basic bootete. Das Ding hat ein Bekannter im 20er Pack für unter €50 abgestaubt, eins könnte noch am Dachboden liegen zwischen den ISA- und AGP-Karten... als C64-geschulter kam mir das Ding sogar ganz performant vor. Ich wußte nur nicht was ich damit anfangen sollte...


    Edit 1, ein paar Modelle mit HDMI hab ich noch gefunden, LVDS oder VGA allerdings nicht: https://geizhals.de/?cat=hwepcmcu&asuch=hdmi&asd=on&hloc=de


    Edit 2: Eigentlich müßte man doch mit einer flotten GPIO-Leiste sowas ähnliches wie LVDS "in Software" emulieren können? Das wäre ziemlich ZX80-Like :-)

    Code komplett bare metal am Raspi zu schreiben und starten ist Recht straight forward. Auch in 100% Assembler wie gesagt. Man Google Mal nach 'raspi assembler starfox' für ein komplettes Spiel und erstaunlich kurzem Quelltext.

    Ja das ist ein schönes Beispiel das die Möglichkeiten aber auch die Grenzen von Baremetal aufzeigt.


    Die gezeigte Demo ist ein Proof-of-Concept aber nutzt in keinster Weise die Vorteile. Ich gehe sogar so weit und sage daß die gleiche Demo unter Linux und Nutzung von Standard-Bibliotheken deutlich besser laufen würde. Quake3 und Urban Terror laufen z.B. mit 30-50fps auf dem Pi Zero bei weit besserer Grafik. Aber gut, es ist ein Beispiel, kein Testsieger. Und dafür bin ich beeindruckt.


    Die offensichtlichsten Probleme:


    1. Peripheriegeräte werden über GPIO-Pins angebunden. Damit umgeht man die Probleme mit dem komplexen USB-Protokoll. Logischerweise ist man dadurch auf spezielle Adapter angewiesen und hat wenig Auswahl bei der Peripherie.


    2. Die Grafik nutzt vermutlich nicht die DMA-Unterstützung der Videobeschleunigung des Raspi, auf der Projectpage werden Performance-Probleme beim Zugriff mit der CPU auf den Grafikspeicher angesprochen.


    3. Massenspeicher-Zugriff braucht zwar dieses spezielle Programm nicht aber auch sonst ist das ein Tabu-Thema in der Bare-Metal-Raspi-World. Eben mal wieder wegen USB.


    Vermutlich wäre es einfacher einen simplen ESP8266 statt eines Raspi auf Bare-Metal zu programmieren.

    Wie lange braucht ein entrümpeltes Linux, um auf Raspi 0/1/2/3/4 zu booten. Armibian oder sowas?

    Das kannst Du einfach selber ausprobieren (ich habe leider keinen Raspi ich bin eher der Retro-PC-Sammler): Linux-Kernel mit der Option "init=/bin/sh" starten. Achtung, ne echte sh ungleich bash ist extrem rudimentär. Und am Raspi schätze ich daß man die Bootmeldungen irgendwie auf RS232 oder so umleiten muß oder kann der sowas über HDMI anzeigen?


    Mein 486dx4-160 - mein aktuell langsamster unter Linux funktionsfähiger PC mit einem selbstgebackenem monolitischem Kernel aus der späten 2.6-Reihe - braucht dafür vom LILO-Prompt bis zur bash so 1-2 Sekunden. RAM belegt der Kernel etwa 800kByte. Lasse ich den Rechner regulär booten - weitgehenst ein Debian 4.0 - dann braucht er 10 Sekunden und belegt 5MB RAM.


    Vor Äonen (Kernel 1.0.9?) konnte ich mit dem /bin/sh-Trick auf einem 386sx16 mit 1MB RAM ein paar PC-Demos, einen SID/MOD-Player und VGA-Bilderanzeiger nutzen, wohlgemerkt ohne Swap denn mit init=/bin/sh wird ja auch kein Swap gestartet. Die Bootzeiten waren kaum meßbar kurz, der Rechner fühlte sich dreimal flotter als unter DOS an.


    Edit: Ooops, einen Oldi glatt vergessen, ich hab ja noch einen Amiga 3000 mit einem 2.4er-Kernel. Von amiload bis Bash braucht der 3-4 Sekunden. Regulär ins stark reduzierte Debian 3.1 mit 4.0-Backports sind es eher 50-70 Sekunden mit 3MB RAM-Belegung. Allerdings ist Linux auf m68k wirklich sauschlecht optimiert und kaum mehr als ein Proof of Concept.


    Die SVGA-Lib bzw. Kernel-Framebuffer-Tools/Support belegen je nach Bedarf 200-500kByte RAM. Wobei gerade Libs unter Linux ja nicht unbedingt komplett geladen werden sondern nur die relevanten Kacheln. Ich denke wer da nur etwas Grafik initialisiert der läd da keine 20kByte von der SVGALib. Das sind dann die Dinger die in Top sinngemäß melden "ich habe 100MB RAM reserviert und 20kByte physikalisch belegt"...


    Ergo ist der Overhead eines Linux-Kernels sehr gering.

    Ich finde das Thema spannend aber weniger wegen der konkreten Emulation sondern wegen des Bare-Metal-Hardware-Bangings. Mein Bauchgefühl würde einen Low-Level-Raspi mehr schätzen als die hundertdrölfte Emulation eines No-Name-Rechners.


    Ich freu mich schon auf eine "Raspi Memory-Map mit Wandervorschlägen" in Anlehnung an eine alte Artikelreihe aus dem 64er Magazin "C64 Memory Map mit Wandervorschlägen".


    Ein Raspi oder ein 0815-€200-PC kann unter Windows und Linux sowieso fast alles in Echtzeit emulieren was im 20. Jahrhundert rausgekommen ist. Den Vorteil von Bare-Metal braucht man da garnicht. Und kleiner als ein Raspi geht ja kaum noch ausser man greift bei irgendwelchen €1-SOCs zu und selbst die sind teilweise mit 80Mhz und 32kByte RAM schon recht zackig.


    Einen Raspi allerdings in Hardware zu programmieren... hehe, das wäre schon sehr witzig. Allerdings wird mir bei den ganzen Teilproblemen schwindelig... ein C64, Amiga oder gar ein VGA-PC ist ja noch eine recht geradlinige Sache. Das Keyboard ist mit ein paar Registern direkt kontrollierbar, Poke 1024,65 gibt auf jedem Bildschirm immer ein "A" aus ohne sich durch irgendwelche HDMI/DRI/MIA-Setups zu hangeln aber heute gibt es so viele Dinge die wirklich kompliziert geworden sind... z.B. (wurde ja schon angesprochen) HDMI-Ausgabe oder USB-IO oder schlicht Queue-Handling der Hardware-IO oder SMP-Handling... wenn man das Einsatzspektrum nicht extrem eng ansetzt muß man auch noch viele Sonderfälle berücksichtigen (ich sag nur "USB2.0-Keyboard an einem USB3.2-Hub an einem Raspi)" - oder das manuelle Setup von MMU und Cache-Handling abhängig vom Anwendungsspektrum eines Adreßraums... - selbst der heiligste Bare-Metal-Banger wird da ganz schnell zu einer grossen Zahl vorgefertigter Bibliotheken greifen müssen.

    Siehe


    Mein Bauchgefühl sagt mir daß man sehr weitreichendes Hardwarebangings mit minimalem Verlust an Kontrolle aber sehr viel Komfort bekommt wenn man schlicht Linux mit dem Kernelparameter "init=/bin/meinhardwarebangingprogramm startet. Imho sitzt USB-Support bei fast allen Kerneln zumindestens für Basic-HUD im Kernel und nicht in den Modulen. Und ich habe mehrere Hardware-Banging-Demos auf meinem Linux-PC die wirklich direkt auf die Hardware zugreifen und dazu nicht auf X11 zugreifen. Viele weitere Demos nutzen zumindestens noch die SVGALib welche zumindestens das Initialisierung der Grafik und die Rückgabe direkter Hardware-Adressen zur direkten Nutzung stark vereinfacht. Soweit mir bekannt ist gibt es etwas ähnliches wie SVGALib nicht für Raspi, das ist letztlich immer ein Kernel-Framebuffer und daher dem direkten Zugriff entzogen.

    Mein Bauchgefühlt würde sich daher zusätzlich noch eine "SVGALib" wünschen. Der "Leistungsverlust" gegenüber hochheiligem Hardwarebanging wäre imho mikroskopisch, die "Komplexität" aber enorm reduziert. Und überhaupt, für einen Hammer ist alles ein Nagel, für einen Unix-Admin ist alles eine Frage der Linux-Anpassung...


    Mir schwebt da etwas anderes vor als anderen Foristen. Vieleicht werde ich alt aber das eine erscheint mir fast unmöglich (komplettes Bare-Metal), das andere schwierig (Linux-Kernel als fettes Backend) und das letzte relativ einfach machbar (Linux-Kernel mit einigen sehr wenigen Userspace-Libs wie z.B. SVGALib).


    Ja, ich gebs zu, irgendwie schwebt mir als Endziel eine Art "Bootloader-Megademo" ala "RSI Megademo" vor... nur eben mit der Leistung eines Raspi ;-)

    Im Prinzip sollte man das Laufwerk mal einem Low-Level-Test unterziehen und das ist unter AmigaOS extrem schwierig, dazu später mehr.


    Mit etwas Glück ist das Laufwerk selbst in Ordnung und nur die Partitionierung ist im Eimer. Das erste Werkzeug ist die bei AmigaOS enthaltene grafische HDToolbox. Damit kann man den Bus / die Busse nach Laufwerken scannen was man aber explizit anfordern muß. Frag nicht wie, war irgend ein Knopf "Read Geometry" oder "Scan Bus" oder so. Dann sieht man wie die einzelnen Devices an der xtbus.library (0-1) und scsi.library (0-7) durchprobiert werden. Wird hier nichts gefunden hat man einen Briefbeschwerer.


    Wird hier etwas gefunden kann kann ggf alte Partitionen löschen und neue anlegen. Fürs Booten war es imho wichtig oder wenigstens ratsam ein Filesystem-Handler, z.B. ein möglichst aktuelles L:fastfilesystem-handler in den Rigid-Disk-Block = Boot Block zu schreiben. Praktischerweise kann sowohl HDToolbox als auch der normale Format-Befehl nach Bad-Sectors suchen und die gefundenen Treffer in eine Datei schreiben.


    Ich gehe aber davon aus daß das Laufwerk schlicht im Eimer ist. Gerade die Quantums verdauen lange Standzeiten sehr schlecht, hier sind alle vergammelt. Ein Low-Level-Test am PC ist sinnvoll, mit Low-Level-Tools vom Hersteller ein Low-Level-Format / Low-Level-Diagnose machen und auf Fehlermeldungen achten oder unter Linux mittels dd das Laufwerk komplett durchlesen - letzteres geht zur Not ja auch mit Linux direkt auf dem Amiga aber Spaß macht das nicht. Oder mal im Aminet nach Gnu-Tools suchen, da müßte dd auch drin sein - habe ich nie direkt auf meinem Amiga verwendet aber müßte gehen.


    Ersatz-SCSI-Laufwerke bekommt man auf Ebay für wenige Euro. An meinem Amiga 1000 hängt ein hochwertiges Server-4GB-7200rpm-Laufwerk und am 3000er zwei hochwertiges Server-9GB-10000rpm-Laufwerke, zusammen keine 10 Euro wert. Ein Umstieg auf Flash ist sicher langfristig sinnvoll aber imho ist das ein Stilbruch :-)


    Nettes Bonmot am Rande, das alte CBM-Fastfilesystem kann nur Partitionen bis 2GB nutzen. Es gibt Patches/Neuimplementierungen aber da muß man sich einarbeiten. https://www.amigawiki.org/doku…system:filesystems_limits - ich war faul, mein Amiga 1000 ist in zwei 2GB-FFS-Partitionen unterteilt und mein Amiga 3000 hat auf jeder Platte je zwei 2GB-FFS-Partitionen und eine 5GB-Linux-RAID1-PArtition - alles zu 90-95% leer - 18GB Plattenplatz bekommt man unter AmigaOS sowieso kaum voll :-)

    Ja, der Preisverfall bei Software allgemein und bei Programmiersprachen und Entwicklungsumgebungen im besonderen ist schon enorm. Heute kann man ja quasi jede Programmiersprache kostenlos bekommen und viele Entwicklungsumgebungen auch (und selbst für Betriebssysteme und Office-Pakete muss man nicht unbedingt Geld ausgeben – ganz legal). Das hat Borland ja besonders schmerzlich zu spüren bekommen.

    Der GCC kam 1987 raus und hat vieles verändert, kam allerdings gerade in der Wintel-Welt spät und nur in der zweiten Reihe zur Geltung. Auf Unix und Amiga wars hingegen recht schnell der Standard-Compiler. Nicht unbedingt unter dem Namen GCC, da gab es viele Anpassungen usw. namens ZC, ACC uswusf. Der GCC alleine war zwar recht nutzlos aber Includes und Bibliotheken gab es ja gottseidank fast immer von den Herstellern gratis oder zumindestens vom grauen Markt. In der Wintel-Welt habe ich GCC glaube ich erst im 21. Jahrhundert selber verwendet...


    Die zahlreichen guten und freien Entwicklertools haben mich auch recht früh in die Unix-Ecke gelockt. In der Uni war es sowieso üblich nur freie Software für die Fortbildung zu verwenden.


    Ich meine vor dem GCC hätten wir auch mit irgendwelchen Gratis-C-Compilern gearbeitet, irgendwelches Zeug aus der BSD-Welt. Und damit meine ich nicht die grottenlahme und sehr fehlerreiche Referenzimplementierung von K&R.


    Hier ist auch wieder zu sehen, wie sehr dem CGA-Standard unrecht getan wurde und wird. Bei analoger Ausgabe ist das Ergebnis lange nicht so traurig, wie man es (bei digitaler Ausgabe) kennt.

    Ich gebs zu, ich kannte nur digitales CGA und die guten Farbgrafiken bei ancientelectrinics haben mich total verblüfft. Ich denke ich werde mich mal einlesen warum analoge CGA-Grafik so gute Farben hat. Scheint wohl so ein "Schmutzeffekt" wie auf dem C64 mit FLI-Grafiken zu sein. CGA ist an mir fast komplett vorbeigegangen, meine einzige "echter" CGA-Rechner waren die Amiga-Sidecar/A2088/A2286-Lösungen und das war natürlich ersten emuliert und zweitens digitale hässliche Farben. Davor hatte ich am IBM5150 Hercules-Grafik und nach dem Amiga überall VGA-Grafik.

    War aber natürlich damals schweineteuer. Für den Hausgebrauch, wo man keine Rechteverwaltung benötigt, war Kirschbaum-NETZ eine echte Alternative. Damit konnte man einfach Verzeichnisse von Rechnern aus dem Netz mounten, nicht mehr und nicht weniger. Ob das auf einem 286'er lief, weiß ich allerdings nicht. Die Homepage gibt es zwar noch (steinalt mit DM-Preisen), aber zur alten Version 1.53 verrät es leider nicht die Mindestanforderungen: https://www.pos-ware.de/produkte/kirschb.htmDie 1.53 kostete DM 99, was für PC-Verhältnisse damals günstig war.

    Kirschbaum war spätestens mit neueren DRDOS/OpenDOS-Versionen völlig obsolet. In DRDOS/OpenDOS sind restlos alle Komponenten für ein Novell IPX Peer to Peer Netzwerk enthalten und das gibt es schon über 15 Jahre sogar kostenlos zum runterladen. Ich hab das sogar auf einem 8088-Rechner mit 256kByte RAM genutzt - der hatte nach dem Booten mit Maustreiber, Netzwerk und sonstigem Kleinkram zwar nur noch 140kByte frei aber damit konnte man auch noch einiges anstellen.


    Ist es in den 32-Bit-Versionen nicht immer noch drin? Und in 64-Bit-Windows generell nicht? Schon XP x64 konnte jedenfalls weder DOS- noch 16-Bit-Windows-Programme.

    Schön daß Du diese Frage stellst denn das Thema ist sehr interessant:


    Seit Windows 8.0 wird bei KEINEM Windows ein Win16-API automatisch installiert...


    Für Windows 64Bit gibt es auch keine direkte Win16-API - aber da gibt es Ausnahmen: XP 64Bit kann man mittels einiger uralter Microsoft-Erweiterungen auf Win16 aufrüsten allerdings ist das unsupported und unstable. Und auf Windows 10 64 Bit kann man mittels der integrierten Virtual-Machine einfach ein altes Windows-32Bit und darin Win16 installieren. Aber Obacht, man hat anschliessend schlicht zwei getrennte Systeme auf der Platte und das Setup läd wirklich knallhart zig Gigabytes z.B. für Windows 7 auf die Platte.


    Bei Windows 32Bit ist mit Windows 8 das 16Bit-System ebenfalls geflogen. aber man kann die gesamte Win16-Ebene schlicht nachinstallieren: https://www.groovypost.com/how…ation-support-windows-10/ - das ist sogar fully supported.


    Was man mit einem 286'er mit 25 MHz machen kann hängt sicher auch viel von der sonstigen Ausstattung ab.
    Mit 16 MB Hauptspeicher geht schon eine Menge und eine höhere Taktrate ist vielleicht auch noch drin. Auf diese Art und Weise kann man mit dem Gerät sicher jede Menge machen. Selbst die Einbindung ins Netzwerk sollte keine große Hürde darstellen.

    Ein 286er kann nur insgesamt 16MB Speicher addressieren und das kann nicht alles RAM sein weil rund 1-2MB von anderen Dingen belegt werden. Imho konnten die meisten 286er Chipsets nur 1-4MB RAM nutzen, ein paar Server mit 8MB habe ich zumindestens mal in Zeitschriften gesehen. Von einem 286er mit mehr als 8MB RAM habe ich nie gehört (EMS-LIM mal ausgeschlossen, das war ja kein direkt addressierbarer Speicher).

    Ihr denkt alle viel zu kompliziert ;-) KISS - Keep It Simple Stupid.


    Mit SLIP und CSLIP existriert ein Layer2-Protokoll für RS232 was alle bietet was ihr braucht. Für Win95 gibt es viele How-Tos und Tricks und ähnlich sollte es bis Windows 10 klappen. CSLIP ist theoretisch etwas performanter, SLIP aber problemloser. Wenn beide Rechner über eine serielle Schnittstelle auf 16550-Basis verfügen kann man problemlos mit 115200bps arbeiten. Bei einem 16450 muss man eventuell runterregeln bis auf 9600bps. Einfach mal probieren. Letztlich kann man damit ALLE normalen Dienste verwenden, d.h. SMB, HTTP, telnet, DNS uswusf - eventuell muss man auf dem Gateway noch Routing per Hand einrichten, Tante Google weis mehr. Für reine Dateitransfers reicht es aber ganz ohne Routing einfach den anderen Rechner mittels \\\1.2.3.4\Freigabe anzusprechen.


    Nur eins ist ärgerlich: Die Datenrate von einer 115200bps-Verbindung wird von SMB/TCP/IP schlecht genutzt. Bestenfalls kommen 7-8kByte/s an.


    Wenn man also grosse Datenmengen transferieren will greift man zu TwinExpress. Das ist eine uralte Low-Level-Hacking-Software um Dateien zwischen PC und Amiga über RS232 auszutauschen die locker mal mit 1-8MBit (!!!) arbeitet. Zwischen zwei 286ern habe ich mit 8MBit/s Daten transferiert und zwischen Amiga und PC mit 2MBit. Das ganze bedient sich zwar sehr rustikal ist aber auch selbsterklärend. Link weil man es heute schwer findet: https://www.arnosoft.de/Code/T…Amiga-PC.htm#Twin_Express und ev. auch Aminet.

    PC Geos läuft auf einem 286er.
    Damit konnte man schon tolle Sachen machen, trotz der geringen Rechenpower.
    Ein komplettes Office-Paket mit GUI und Maus-Bedienung.

    Gute Idee, Windows 3.1 läuft übrigens auch auf 286ern und das durchaus flott und mit einem beachtlichem Software-Pool. Viel Software gibt es direkt für Win16-API und noch mehr kann man selber einfach kompilieren, z.B. Dillo als Browser, Putty, Xming (zumindestens eine alte Version) uswusf... Das Win16-API wurde übrigens von Windows 1.0 (1983) bis Windows XP (EOL 2014) offiziell unterstützt und in diesen 30 Jahren gab es wirklich eine Menge Software dafür.


    Mit einigen alten MOD-Playern konnte man sogar recht gut MOD- und SID-Musik abspielen während man arbeitete. MP3 kann man natürlich vergessen. Könnte WinAMP gewesen sein, es gab aber sehr früh auch andere für Windows.


    Auch sehr empfehlenswert: Alte PC-Demos z.B. von pouet.net und weils bisher sonst keiner gesagt hat: Flugsimulator von Sublogic und Microsoft ;-)

    EMS gibt es auch für 286er. Kommt halt darauf an, was für einen Chipsatz du hast.
    Ansonsten ist F1GP schon ein guter Ansatz und das Teil auszulasten. Mit texturierter Strecker dürfte der ganz schön in die knie gehen.

    Das bestätige ich aus eigener Erfahrung. Für viele modernere 286er Chipsets gibt es passende EMS-Treiber und ein [email protected] ist schon sehr modern. Bei mir lief EMS auf einer ganzen Reihe von XTs und ATs mittels Spezialtreiber und/oder Spezialhardware - EMS kann man sogar auf XTs nutzen, dann allerdings nur in Form dedizierter EMS-Erweiterungskarten.


    Im Prinzip war EMS am Anfang eine recht lahme API um Speicherbereiche aus dem normalem RAM auszutauschen. Angeblich lief das über Bankswitching aber die ersten Karten machten das ganz stupide über Polling mit Datenraten von 20-50kByte/s. Immerhin, es gab sogar EMS welches auf Plattenlaufwerken lief - das war zwar kein Swapping im heutigen Sinn aber fühlte sich entfernt ähnlich an - es war vor allen Dingen richtig lahm, teils klapperte sich die Harddisk kaputt und wuppte trotzdem nur 2-5k/s - und wenns ganz lustig sein sollte machte man das mit Floppy mit Datenraten dass man mit Tippen schneller war. Mit den Public Releases 3.0 bis 4.2 wurden dann viele Erweiterungen festgeschrieben so dass man echten Speicher und echtes Bankswitching verwenden mußte und auf einmal war das ziemlich flott und zuverlässig. Die Bankswitching-Technik brachten dedizierte EMS-karten natürlich mit, normale XT- und AT-Boards hatten das nicht im Chipset. Aber ab der Generation NEAT-286 hatten alle neuen Chipsets das ganze direkt implementiert. Ich schätze die meisten 286er Chipsets können das und ich meinte es gab auch ein paar wenige XT-Chipsets mit der Funktionalität. Teils langsamer aber meistens sogar schneller als dedizierte Karten. Natürlich brauchte man immer einen absolut angepassten Treiber, der nannte sich mal emmneat.sys oder pcemm.sys oder emmhd.sys uswusf. Beim 386er konnte die MMU/Speicherverwaltung das nochmals besser, dann war das Thema erledigt weil das sowieso in jeder CPU steckte und man nur noch einen einzigen generischen emm386.sys brauchte.

    Die PCs haben überlebt und sich sogar durchgesetzt, der Amiga nicht. Weil die User alle so doof sind? :gruebel

    Lies nochmal ganz genau: Wer kauft sich 1986 einen PC10 für 2800 Mark wenn ein Amiga 1000 für 1950 Mark zu haben ist? Dass die Brot-und-Butter-Amigas sich im Kern von 1985 bis 1992 nicht weiterentwickelten steht ja wieder auf einem anderem Blatt. Und dass 1991 ein 386DX40+ET4000 einem Amiga 2000 bei recht ähnlichem Preis überlegen war bestreitet auch keiner. Ich wills auch nicht vertiefen, die Gründe für das Ableben von CBM sind hier total offtopic und andernorts schon genügend oft durchgekaut worden.


    Ich behaupte mal dass die Implementierung eines 8088-Systems kaum anders und sicher nicht komplexer als ein 6502- oder Z80-System war. Um so verwunderter bin ich dass ich immer noch garnichts zum Thema Selbstbau-PC in den 1980ern gefunden habe. Dass es in den frühen 1980ern nix gab akzeptiere ich inzwischen. Aber auch in den späten habe ich auf die Schnelle nichts konkretes finden können. Meine c't-Archive beginnen auch erst 1989 und sind im Stapel gaaanz unten, bleibt also noch mein c't-ROM-Archiv und das liegt gottseidank ab 1990 auf meinem Fileserver :-) da werde ich mal für 1990 schmöckern - ausser die haben da die Anzeigen entfernt, das wäre natürlich doof.


    Edit: Natürlich sind im c't-Archiv keine Anzeigen enthalten. Also gehe ich später mal mit grosser Schaufel mein Archiv umgraben...

    So, neue Infos... beim Aufräumen alter Comic-Hefte bin ich über eine falsch einsortiers 64er Magazin 1986-12 gestolpert. Und dort habe ich einige Preise für Fertigsysteme gefunden aber praktisch keine PC-Komponenten.


    Nota Bene, in diesem Heft gab es wohl Tests von 10 EPROM-Brennern und 10 Centronics-Interfaces. Ich kann mich garnicht erinnern dass das mal relevant war...


    Syndrom bot folgendes an:
    PC10 2798DM
    PC10 mit Platte 3898M
    PC20 4389DM
    Amiga 1000 mit 512kByte 1948DM
    VC64 479DM


    HEWY:
    AT 3999DM
    XT 2x360k Floppy, 640k RAM, TTL-Monitor, DOS 1699DM
    Schneider PC1512 512k RAM, Mono-Monitor, 1x360k Laufwerk 1999DM
    Joyce PCW 8256 1799DM


    PUG:
    PC 10-II 640k RAM, 2x360k Floppy, AGA-Karte, Monitor, Tastatur, MS-DOS, GW-Basic 2888
    mit 20MB HD 3999DM


    Geisler:
    ein paar PC-Komponenten z.B. HD, Multi-IO, RAM-Erweiterungen zu zeitgemässen Preisen
    GPC-20-II-XT, 256k RAM, 20MB HD, Monitor, Tastatur 2499DM


    Der Amiga 1000 wurde recht oft angeboten für rund 1950DM mit 512kByte.


    Soooo.... Resüme... Ende 1986 gab es sogar in Fachfremden Magazinen wie dem 64er Magzin ein paar PC-Angebote. Aber bis auf den Geisler-PC waren alle PCs ziemlich überteuert und Bastler werden garnicht angesprochen. Wer bitte ist so doof und kauft sich einen PC10 mit 4,77Mhz für 2800DM wenn er einen Amiga 1000 für 1950DM haben kann? Auch Geräte wie Joyce oder Schneider-PC waren technisch absolute Witzfiguren und knackig teuer.


    Überhaupt bin ich überrascht wie günstig man damals an den Amiga rankam. Der einzige preisliche Konkurrenz ist ein C64. Und mit Floppy, Maus, Geos und ein paar kleinen Tools wie Final Cadrige kam der auch schon auf 1300DM. Da wars zum Amiga für 1950 nicht mehr weit. Preislich dazwischen lag der C128D für 1298DM. Noch Maus, Geos und Final Catridge dazu und man kam mit 1600DM auch schon wieder verdammt nah an den Amiga 1000.


    Und was mich aus heutiger Sicht ziemlich wundert, dass CBM nie den logischen Schritt gegangen ist die Floppy der 8Bit-Computer serienmässig direkt im Computer einzubauen UND sich die Ansteuerungslogik zu ersparen. Wer hat denn 1985 ersthaft einen C64 mit Kassette verwendet? Das wäre imho problemlos über die interne CPU und einen zusätzlichen IO-Chip für wenige Cent gegangen und hätte die Combo C64+Floppy locker 100-200DM ghünstiger gemacht. Aber naja, CBM und Logik...


    Insofern wundert es mich nicht dass C64 und Amiga bis zur unnötigen CBM-Pleite den Markt beherrschten. Frech gesagt waren PCs erst interessant als die CBM-Geräte vom Markt waren.


    Das Ding hatte ab Werk DRAM-ICs huckepack(!) auf die im Board eingelöteten 1:1 draufgesetzt, um den Speicher zu verdoppeln. Keine Ahnung, wie IBM das gemacht hat, da war nichts gefädelt oder so - ich vermute, da wurde extra ein spezielles IC mit anderem Pinout dafür entwickelt. Leider habe ich das Board recht bald entsorgt, weil ich ein anderes, schnelleres, besseres :D bekam. Heute würde mich z. B. das Thema mit den Huckepack-DRAMs brennend interessieren.

    Stimmt, Huckepack-Lösungen waren damals ja des Bastlers liebste Geheimwaffe... Viele Rechner mit einfacher Speicherarchitektur konnte man damals auf diese Art sehr einfach erwitern, z.B. IBM-PC, VC20, PET, Atari ST - interessanterweise aber NICHT den Amiga der da oft querschoss, zumindestens beim Chipram. Beim C64 wiederum ging das auch aber war halt nur mit gesonderter Bankswitiching-Hard- und Software zu irgendwas gut und total inkompatibel.


    Ich kann mich noch an einen Artikel im 68000er Magazin erinnnern bei dem ein 256kByte-AtariST mit vierfach-Huckepack auf 1MB erweitert wurde. In einigen frühen CP/M-Selbstbau-Maschinen habe ich noch tolldreistere Konstruktionen gesehen aber nie selber damit zu tun gehabt.


    Üblicherweise wurde ja ein Adresspin am Sockel vorbei mit den CPU-Adresspins verknödelt. Leicht zu erkennen an Fädeldraht und ein paar Bauteilen an jedem RAM-IC. Aber manchmal hatte der RAM-Sockel und die RAMs mehr Pins als man eigentlich für die konkrete Speichergrösse benötigte. Dann konnte man einfach mehrere aufeinander löten und mußte nur einen Pin innerhalb des Turms anders anschliessen. Hat man sauber gearbeitet konnte man das von aussen nicht sehen.