Beiträge von scorp

    Ich habe auch was passendes zum Thema RTC. Falls jemand Interesse hat welche Möglichkeiten man sonst hat um an funktionierendes RTC zu kommen, vielleicht habe ich was für Euch. Ich Habe zwar schon vor einigen Tagen damit herum experimentiert, aber heute ist das Video dazu herausgekommen:


    Externer Inhalt youtu.be
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Warum Fehler? Objektiv ist das obsoleter Elektroschrott mit einem Materialwert von ca. 1€. Da dürfte er Spaß bekommen das vor Gericht anzufechten ;)

    Glückwunsch zum Megaschnapper :thumbup:

    Könnte man von jedem Oldtimer auch behaupten. Ich denke, juristisch ist das ganze schon etwas kompliziert, aber auch bei 139€ wäre das den Aufwand nicht wert vor Gericht zu ziehen.

    Der Code im Arduino sieht stark vereinfacht so aus:


    Code
    int main() {
      setup();
      while(true) { loop();}   
      return 0;
    }

    Also, loop() wird dann bis in die Unendlichkeit aufgerufen. Im setup() habe ich eine Zeile verloren, den display.display() Aufruf in der Zeile 37 habe ich oben hinzugefügt. Vermutlich steckt der in RTC Initialisierung fest, zeigt aber nix auf dem Display, weil ich die Zeile vergessen habe. Was die Serielle Ausgabe angeht, wo kommt das 'Serial OK' andauernd her? Ich würde auch die Puffer-Größe verkleinern (In Zeile 65 auf 32 herunter gesetzt), macht keinen Sinn bei so einem kleinen Display 256 Buchstaben vorzuhalten. Dadurch wird der Stack nicht so viel verbraucht. Ich muss auch sagen, dass die verwendeten Bibliotheken schon echt viel Speicher verbrauchen. Mein Compiler meckert, dass das ganze instabil laufen könnte.

    Ich habe mir die Freiheit genommen etwas aufzuräumen und ein Paar Kommentare zu schreiben :lupe: Natürlich habe ich es nicht getestet, aber es ist weitestgehend das selbe.

    Es gab schon etliche Untersuchungen. Durchs Bleichen wird Plastik nicht porös oder brüchig, da das ganze nur an der Oberfläche im Mikrometer bereich wirkt. Da braucht man sich keine Sorgen zu machen, aber es kann durchaus schnell wieder vergilben, je nach Umgebung und Plastik. Daher ist der Tipp mit dem Farbspray von H.EXE auch super, vor allem wenn man denselben Farbton verwendet. Umfärben mag ich dagegen nicht, das ist nur noch sehr schwer wieder zu entfernen.


    Auf jeden Fall, schöner Rechner!

    Ich habe meine Versuche hier dokumentiert, falls jemand interessiert ist:


    Externer Inhalt youtu.be
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Das Test Tool von Creative hatte in einer der letzten Version (kann mich jetzt nicht genau erinnern welche) einen Bug und funktionierte nicht richtig. Ich habe Mal eine Sound Karte entwickelt und habe drei Tage damit verbraten, bis ich verstanden habe, dass es an der Software lag. Eine ältere Version des Tools genommen und es ging. Nicht nur meine Soundkarte ging vorher nicht richtig, auch diverse Creative Karten hatten das selbe Problem mit dem Tool.

    Komischer Weise möchte das Board mit keinen meiner SIMM-Module arbeiten. Für mein Vorhaben erst mal nicht so wichtig, aber man fragt sich schon warum.

    Liegt an der Speicherbusbreite. Man braucht immer gewisse Anzahl von Modulen, möglichst gleichen, aber manchmal hat man Glück und unterschiedliche Module spielen zusammen.


    30-pin SIMMs sind 8-bit breit

    72-pin SIMMs sind 32-bit breit


    286/386SX hat 16-bit Speicherbus, braucht also Sets von je 2x30-pin Modulen


    386DX/486 hat 32-bit Speicherbus, braucht also Sets von je 4x30-pin, oder 1x72-pin Modulen


    Pentium hat 64-bit Speicherbus, also je Satz braucht es 2x72-pin Module.

    Es ist ein weit bekanntes Problem, dass Windows 98 sich auf der neueren Hardware/CPU mit z.B. Ryzen ab Modell 3x00+ nicht installieren lässt. Weder geht das direkt auf der Hardware, noch in einer VM. Die CPUs sollen u.A. zu schnell sein. Heute habe ich es versucht und bin während der Installation erwartungsgemäß in den "Explorer" Crash wegen angeblich fehlenden DLLs hinein gelaufen. Nun ich habe etwas recherchiert und bin auf einen Patch gestoßen, der das Problem für mich gefixt hat. Es gab wohl früher einen Patch auch für Windows 95 schon, aber der soll weder unter Windows 98 anwendbar sein, noch bei den schnelleren Ryzen CPUs helfen. Nun gibt es einen neuen Patch, der für alle Windows 9x passen sollte. Ich habe den ausprobiert und voilà, es läuft. Man findet im Projekt im Bereich "Releases" auf der rechten Seite die Downloads. Ich habe mir die Bootdiskette heruntergeladen und meiner VM mitgegeben. Nach dem Booten der VM von der Diskette, habe ich dann patch9x ausgeführt und den Anweisungen gefolgt. Danach konnte ich Windows 98 in der VM einwandfrei benutzen. Vielleicht findet das der eine oder andere auch nützlich. Da stehen auch sehr viele interessante Details, falls man in die Tiefe graben möchte.


    GitHub - JHRobotics/patcher9x: Patch for Windows 9x to fix CPU issues
    Patch for Windows 9x to fix CPU issues. Contribute to JHRobotics/patcher9x development by creating an account on GitHub.
    github.com

    Also, habe heute auf dem MSI X4->AH4 verbunden und nun läuft Coppermine da auch. Was erfreulich ist, dass ich AM2 nicht entfernen musste, denn das ist etwas mehr Aufwand, und Y33 liegt immer noch auf Masse, dabei scheint das Board zumindest unter DOS stabil zu laufen. Ich habe einige Benchmarks laufen lassen und die Performance scheint auf den ersten Blick auch zu stimmen. Ich muss das ganze noch unter Windows testen, dann sehen wir weiter. Die ganze Geschichte ist echt seltsam, denn AOpen läuft ohne Veränderung und da ist X4 nicht mit AH4 verbunden. Der Rest schaut identisch aus, aber ich bin mir sicher, dass ich etwas übersehen habe. Immerhin war es einfach das MSI zu überzeugen mit dem Coppermine zu spielen.

    Moin Leute.


    Habe heute beim Basteln etwas seltsames festgestellt und kann es nicht erklären. Vielleicht könnt Ihr ein Paar nette Ideen beisteuern. Ich habe hier zwei i440LX Boards, ein AOpen MX3L und ein MSI MS-6159. Das AOpen Board habe ich vor langer Zeit in Ordnung gebracht und BIOS gepatcht, damit es mit dem Coppermine läuft. So weit, so gut. Nun bekam ich vor kurzem das MSI Board, welches ähnlich ist. Ich habe dort Coppermine gesteckt und die Spannungen sind i.O., läuft alles runter bis 1,5V astrein, doch mit Coppermine blieb der Bildschirm schwarz. Eigentlich sind beide Boards offiziell nur für Mendocino spezifiziert und ich weiß, dass man ggf. etwas an den Pins spielen muss, aber ich habe erst Mal mit einfachem BIOS Patch versucht und es hat nix gebracht, also Coppermine läuft nicht (Mendocino schon). Nun, ich dachte ok, muss ich mir doch den Socket genauer ansehen, und ich wusste noch, dass matt da großartige Arbeit abgeliefert hat und in dem Thread über die Slotket Adapter gezeigt, welche Pins, wie verändert werden müssen, damit Coppermine läuft. Ich dachte, kein Problem, habe aber erst entschieden die besagten Pins auf dem AOpen zu testen, denn da läuft Coppermine ja einwandfrei. Nun zu meinem Erstaunen, sind die betroffenen Pins auf beiden Boards identisch. Also AM2->Ground, X4 und AH4 sind nicht verbunden, Y33->Ground. Wie kann das sein? Warum funktioniert es beim AOpen Board und beim MSI nicht? Sowas kann doch nicht mit irgendwelchen BIOS Hacks gelöst worden sein, oder? Ich meine, ich kann die Änderungen am MSI vornehmen und mit etwas Glück funktioniert es dann dort, aber trotzdem, was ist da los? Irgendwelche Ideen?

    Gesucht werden explizit Hi-Res Spiele.


    Lemmings

    Aber nur im Hauptmenü, das Spiel selbst ist low res:grübel

    Das sieht verdammt nach einem Fall, den ich Mal verursacht habe. Beim Messen am D0 im ISA slot, bin ich ausgerutscht und mit der Spitze gegen den 12V daneben gekommen. Damit wurden 12V in den Datenbuss geschickt und alles, was nicht hinter einem Transceiver versteckt war wurde sofort gegrillt. Der Chipsatz auch, daher war das Board offiziell tot.