Beiträge von 2ee

Nachdem ich am Sonntag nach etwas hirnen den FA12 Treiber noch in den Boot Loader integriert hatte, blieb nur noch die Frage, wie Testen?

Ich hab deshalb heute mal eine SD-Karte via Partition Assistant mit drei Partitionen erstellt. Da der Partitionierer leider keine FAT12 Partitionen erstellen kann sah die Partitionsliste erst mal so aus:

Partition 1 250MB FAT16

Partition 2 250MB FAT16

Partition 3 7GB FAT32

Aus Partition 1 habe ich dann via Disk Editor eine 1,44MB große FAT12 Partition gebastelt, welche auch sofort von Windows erkannt wurde. Die neue BOOT.SYS drauf kopiert und gleich mal im Junior gestartet. Der anschließende Crash kam tatsächlich nicht vom FAT12 Treiber, sondern wurde durch meine CLUSTER_TO_BLK Routine verursacht, die mit einer Clustergröße von einem Block nicht zurecht kam. Mit einem BEQ war das dann aber behoben. Ausserdem war mir aufgefallen, dass ich bisher - entgegen meiner Code Kommentare - bei FAT16 und FAT32 ein EOF mit Carry Flag = 0 statt 1 angezeigt hatte. Im FAT12 Code war das richtig. Da hieß aber, dass der FAT12 Loader nach dem ersten geladenen Block gleich abgebrochen wurde - weil siehe oben. Das ganze war dann im FAT16/32 Code mit einem CMP $FF statt wie bisher CMP $00 (was man ja sowieso nicht machen soll) aus der Welt.

Erneuter Versuch...und Tataaaa, die vollständige 32KB große BOOT.SYS war im Speicher.

Ich habe im ROM auch noch einen Fehler gefunden, weshalb ich auch hier gleich ein paar weitere Änderungen vornehmen werde.

Bisher wurde von der ROM Boot Routine bei einer SD-Karte im MBR nur die Partition 1 berücksichtigt, welche sofort geladen wird, wenn diese als Boot fähig markiert ist.

Ich werde jetzt allerdings - und das ist der Grund, warum ich auf meiner SD-Karte drei Partitionen untergebracht habe - den MBR daraufhin untersuchen, ob dort auch schon ein 6502 Boot Code liegt, und diesen dann gegebenenfalls laden. Somit kann ich dort ein Boot Menü unterbringen und so verschiedenen Betriebssysteme von SD starten. Das macht es dann auch mit dem CPM-65 von Dietrich einfacher.

Sobald ich da was geschrieben habe und der Bootstrap Loader für FAT32 Partitionen auch läuft, melde ich mich wieder.

Edit: Für alle die es interessiert als Anhang noch der neue Code der Boot.sys

Gerade eben bin ich mit dem Code für die BOOT.SYS soweit fertig geworden, dass diese auch verteilt auf verschiedene Cluster unter FAT16 sauber geladen wird. Der Code für FAT32 ist auch schon drin, aber noch nicht getestet, da ich den Bootstrap Loader für FAT32 noch nicht geschrieben habe.

Erfreulich ist, dass ich noch 180 Bytes im ersten Block übrig habe, um den FAT12 Loader unterzubringen. Das sollte reichen.

Der Boot Code berechnet jetzt die benötigte Anzahl der Blöcke, die eingelesen werden müssen, um BOOT.SYS vollständig in den Speicher zu laden.

Ich hab im ersten Schritt die Datei künstlich auf 4KB aufgeblasen und gespeichert. Die Clustergröße des FAT16 Volumes ist ebenfalls bei 4KB (also 8 Blöcke).

Um die Cluster auf dem Volume auseinander zu reißen, hab ich dann eine andere Datei auf SD-Karte gespeichert, BOOT.SYS auf 16KB vergrößert, wieder eine neue Datei dazwischen gespeichert und zum Schluss BOOT.SYS auf 32KB vergrößert. Im Code werden dann noch alle 4KB Marker gesetzt um zu schauen, ob alles da ankommt, wo es hingehört.

Im Test Code können beim Booten die geladenen Blöcke in ihren Cluster Ketten angezeigt werden.

Hier sieht man, dass zuerst die verbleibenden 7 Blöcke an LBA $000A26 bis $000A2C des ersten Clusters noch eingelesen werden (der erste Block ist ja schon im Speicher). Dann wird der zweite Cluster mit den Blöcken an $000A5D bis $000A64 gelesen. Danach folgen noch 6 Cluster im durchgängigen Bereich $000A7D..$000AAC.

Zum Schluss noch der Test, ob alle Marker im Speicher stehen

In der Zip ist mal die BOOT.SYS mit 32KB Größe und ohne Anzeige der geladenen Blöcke. Zum vollständigen Laden benötigt der Junior ][ bei mir 1,67 Sekunden, was mit den zwischengeladenen FAT Blöcken dann einen Durchsatz von 21,6 KB/s macht.

Um die BOOT.SYS größer oder kleiner zu machen müsst ihr nur die ORG xxxx Zeilen im Code ändern/rausschmeissen und dann neu kompilieren. Die assemblierte Datei BOOT.BIN in BOOT.SYS umbenennen und dann auf Karte kopieren.

Morgen mache ich dann noch den FAT12 Code fertig.

Zitat von Wir3dBrain

Ja, es muss ja der Fat-Agnus sein, sonst wird der Ram nicht erkannt.

Steht direkt am Controller auf dem Mainboard "FAT AGNUS" ist der 8372A und sollte somit das MB auch können. Ist ein Revision 6A Board. Jumper J2 steht auf 2-3 (Chip RAM). JP7A steht bei mir noch wie ursprünglich auf 1-2 und somit Ext RAM disabled. Da ich sowieso keine RAM Karte besitze und zukünftig einbauen werde, ist das mit dem onboard RAM für mich völlig in Ordnung.

Die fehlenden zwei Filterkondensatoren sollten erstmal kein Problem darstellen, da in direkter Nachbarschaft die Kondensatoren der anderen beiden Speicherbausteinchen liegen. Die werden aber natürlich von mir noch eingebaut, wenn meine 100nF Schublade wieder befüllt ist.

Zitat von PC-Rath_de

RAM wird angezeigt ist nicht funktioniert.

Der Satz soll wohl soviel heißen wie RAM.visible <> RAM.working . Da ich die Speicher einzeln geprüft hatte, spricht eigentlich alles dafür, dass sie - nachdem das RAM erkannt wurde - auch im Rechner funktionieren. Eine vollständigen Speichertest auf dem Amiga habe ich aber tatsächlich noch nicht gemacht. Werde ich mit dem Einlöten der noch vermissten Kondensatoren aber nachholen.

So, nach einer langen (aber kurzweiligen) Fernwartungssession mit NorbertJ sind wir dem Phänomen auf die Spur gekommen, warum bei Norbert der Boot Block nicht auf die SD-Karte zurückgeschrieben werden konnte.

Grund ist, dass ich in der Beschreibung geschrieben habe, ihr sollt den Bootstrap Loader einfach mit LM via XMODEM in den Speicher laden. Das Problem ist nun, dass XMODEM immer ganze Blöcke mit einer Größe von 256 Bytes läd. Beim Bootstrap Loader heißt das, Startadresse ist $63E und die geladene Endadresse ist somit $83E ($63E + 2 x 256 Bytes). Die Endadresse des Block Buffers liegt aber bei $7FF. Daher werden 62 Byte in den IO Bereich geschrieben.

Meine IO Karte ist auf K4 gejumpert, also Anfangsadresse $1000. Die von Norbert (und möglicherweise von den meisten anderen) ist aber auf K2 und somit $0800 ! Die 62 Byte überschreiben also fleißig die Register der beiden VIAs und machen somit die Kommunikation via SPI und somit zur SD-Karte unmöglich.

Die Lösung ist jetzt erst mal einfach. Statt eines einfachen LM Befehls nehmt ihr 600.7FF LM, was den Ladebereich einschränkt. Ich hab das in der Beschreibung auch gleich geändert. Ich werde aber einen "Bootblock Creator" schreiben, der dann die einzelnen Schritte vereinfacht. Wird aber leider noch ein paar Tage dauern.

Bis dahin könnt ihr das aber jetzt so wie in der Anleitung beschrieben zusammenschustern.

Heute meine Amiga 500 onboard auf 1MB aufgerüstet.

Leider hatte ich nur noch zwei 100 nF Kondensatoren da. Funktioniert aber natürlich trotzdem

Hallo Norbert,

nachdem du die oben genannten Schritte gemacht hast, hast du dann ja mit Sicherheit wie beschrieben den kurzen Code an $3000 noch ausgeführt und somit den Boot Block auf SD-Karte gespeichert. Somit sollte der erste Schritt fertig sein. In der BootCode.Zip befindet sich auch noch die Datei BOOT.SYS, welche du einfach unter Windows auf die frisch erstellte SD-Karte kopierst. Dann die Karte wieder in den Junior stecken und neu starten. Danach sollte die Boot Meldung

This is M/OS 65 Version 0.1

erscheinen. Fertig. Das Demoprogrämmchen macht nicht viel, ausser einen ">" Prompt und deine Eingaben auf den Bildschirm auszugeben. Endlosschleife. Abbruch mit der Taste ST der Hex Tastatur.

Statt der beigelegten BOOT.SYS kannst du nun allerdings auch ein eigenes Programm schreiben, welches an Adresse $2000 beginnt. Assemblieren, die Bin Datei in BOOT.SYS umbenennen, auf SD-Karte kopieren und davon booten. Dann wird dein eigener Code ausgeführt.

Übrigens: Da der Boot Strap Loader aus Einfachheitsgründen nur im ersten Root Directory Block nach dem Eintrag "BOOT.SYS" sucht, bringt es nichts, auf eine bereits gut gefüllte Karte diese Datei zu schreiben, da diese dann womöglich erst in zweiten, dritten oder gar zehnten Block auftaucht. Also die Datei BOOT.SYS am Besten gleich nach dem Formatieren draufkopieren. Macht MS DOS glaube ich auch so.

Zitat von NorbertJ

mit 0600.06FF steht in der ersten Zeile EB anstatt B0

strange oder liegt es am Userinterface?...

Der Befehlscode EB wird natürlich erst nach einem Reset - sprich Reboot - ausgetauscht.

Hallo Norbert

Zitat von NorbertJ

müßte unter der Sparte 'OEM-String ändern' nicht der zweite Programmstring nicht identisch mit dem ersten sein? Im zweiten steht am Anfang ' 600 - B0' anstelle des '600 : EB' zuvor.

Die Code Sequenz die du bei $600 eingeben musst, beginnt mit EB 3C 90. Das ist der originale x86 Code der im Boot Block steht. EB ist hier ein Short Jump, 3C der Sprungoffset und 90 einfach ein NOP.

Nach dem Booten des Junior II siehst du dann aber ab $600 den Code B0 3C 90, da das Junior BIOS den x86 Short Jump gegen einen 6502 BCS Befehl austauscht.

Hintergrund ist (und ich glaube das früher schon erwähnt zu haben), dass Windows den Datenträger nach dem Vorhandensein der Sequenz EB 3C 90 untersucht. Ist diese nicht vorhanden, möchte Windows deine SD-Karte gleich wieder formatieren wenn du sie am PC einliest. Deshalb tauscht der Junior das EB erst nach Einlesen des Boot Sektors direkt im Speicher aus und springt dann nach $600. Da von der BIOS Routine bei fehlerfreiem Laden des Boot Blocks zuvor das Carry Flag gesetzt wurde, verzweigt dann B0 3C an die Adresse, an der der Boot Strap Loader steht ($63E), welcher dann wiederrum die Datei BOOT.SYS sucht, läd und ausführt.

Warum wird bei dir übrigens der Boot Strap Loader bei $064A durch ein Break abgebrochen?

Hast du den Loader Code vor dem Schreiben des Boot Blocks auch schon in den Speicher geladen, oder hast du nur die ersten 11 Bytes geschrieben, um den OEM String zu ändern?

Edit: Ich werde bald ein einzelnes Programm basteln, dass den gesamten Boot Strap Loader Code in einem Rutsch schreibt. Jetzt ist das alles noch sehr rudimentär mit den drei Schritten, die auf dem Junior ausgeführt werden müssen. Sorry.

Hier nun mal die neueste BIOS Version (1.0.5), die ihr benötigt, um eure eigenen SD-Karten Boot Versuche zu starten. Ich musste in der Routine LOAD_LBA auch noch einen Fehler fixen, der bei SD-Karten bis 2GB auftrat. Hier wurde die endgültige (Byte orientierte) Adresse nicht richtig berechnet, weil ich vergessen hatte nach dem Bit-Shifting das LSB mit $00 zu füllen. Die Variable SD_TYPE ist von $EE nach $1A gewandert, um nicht mit Dietrichs CPM-65 zu kollidieren. Das sollte aber für die meisten von euch eh irrelevant sein.

In der ZIP Datei "Boot Code" findet ihr eine Anleitung zum Erstellen einer passenden SD-Karte. Statt der beigelegten BOOT.SYS könnt ihr auch eure eigenen Versuche unter diesem Namen auf die Karte schreiben. Einschränkung ist allerdings die Größe, welche 512 Byte nicht überschreiten darf.

Nächste Woche werde ich meine BOOT.SYS weiterschreiben und die FAT Read Treiber integrieren.

Ihr könnt mir gerne jederzeit Feed Back geben und natürlich auch Fragen stellen, wenn sich welche auftun sollten.

Cheers

Jörg

Zitat von Dietrich

FAT12 würde ich nicht mehr in Betracht ziehen. Das benutzt niemand mehr. Keep it simple

Das nächste Hardwareprojekt wird ein Floppy Controller und eine Grafikkarte. FAT12 ist also ein Muss. Ausserdem warum Simpel, wenn es auch spannend geht?

Zitat von ThoralfAsmussen

Kennst Du evtl. die Idee hinter dem Bootloader GRUB von den Linux-Geschichten ? Die laden da mit Stufen 1.5 , soll runtergebrochen auf hier heißen, daß man generisch erstmal nur rausbekommt, was für ein Format die RAMcard hat und dann passend ein BOOT12.SYS oder BOOT16.SYS oder BOOT32.SYS nachlädt, die schlicht alle auf der RAMdisk liegen.

Das hatte ich auch schon überlegt, falls die Treiber nicht in die 512 Bytes passen sollten. Ich werde aber erst mal schauen, wie viel Platz ich für den Code brauche. Im ersten Block müssen ja auch nur die FAT Read Treiber rein. Das macht die Sache deutlich einfacher.

Zitat von Dietrich

Wenn wir dann noch dafür sorgen, dass alle Images in lückenlos aufeinander folgenden Sectoren liegen, haben wir gewonnen.

Das dürfte schwierig werden, wenn man die Images unter Windows, Linux oder MacOS speichert. Die Chance ist zwar bei einem leeren Datenträger groß, dass die Cluster alle aufeinander folgen, aber falls sich z.B. ein defekter Block auf der Platte befindet, kann das schon wieder ganz anders aussehen.

Jetzt war es dann doch wieder komplizierter als gedacht.

Ich hatte jetzt mal einen universellen FAT12/16/32 Bootstrap Loader geschrieben, der dann so gerade noch in den Bootblock gepasst hat.

Als ich das dann mit einer FAT32 formatierten SD-Karte ausprobieren wollte, musste ich feststellen, dass bei FAT32 der Einsprung Offset bei $58 liegt, und nicht wie bei FAT12/16 bei $3C. Somit hat man unter FAT32 für den Code 28 Bytes weniger Platz, was dann nicht mehr ausgereicht hätte.

Ausserdem habe ich einige per JSR aufgerufene Unterroutinen wie ADD_32_32 etc. die nach dem Verschieben des Codes nicht mehr funktionieren würden.

Eine Auslagerung der Unterroutinen in das BIOS ROM finde ich nicht so gut, da dann eine Portierung des Betriebssystems wieder schwerer gemacht wird.

Ich habe mich deshalb entschlossen (wahrscheinlich macht das Windows auch so), für FAT12/16 und FAT32 verschiedene Bootstrap Loader zu schreiben, die dann bei der Formatierung entsprechend in den Bootblock geschrieben werden. Eventuell braucht man für FAT12 formatierte Disketten auch einen extra Loader, da der Code meines Wissens, bei unter M$-DOS formatierten Disketten, bei einem Offset von $1E begonnen haben. Unter Windows formatierte Disketten haben dann aber wieder den Offset $3C.

Jedenfalls funktioniert unter FAT16 der Loader jetzt, läd den ersten Block der Datei BOOT.SYS in den Speicher und führt ihn aus. Das ist jetzt das erste mal, dass ein Programm auf dem Junior ][ nicht via XModem vom PC übertragen wurde. Dazu jetzt die ersten Takte von "Also sprach Zarathustra" ... Bombom Bombom Bombom Taaa Taaaaaa Tataaaaaa...

Heute hab ich mal angefangen, den Bootstrap Loader zu schreiben. Als Test wird jetzt erst mal ein Directory Listing des Root Verzeichnisses ausgegeben.

Morgen kommt die Ausgabe dann wieder raus und statt dessen eine Suchroutine für die Datei BOOT.SYS, von welcher dann der erste Block geladen wird. Ich hoffe, dass ich in diese 512 Byte dann die Read-Treiber für FAT12, FAT16 und FAT32 unterbringen kann, um weitere Blöcke der BOOT.SYS Datei zu laden. Sollte aber klappen...

Das ROM hat jetzt die Versionsnummer 1.0.5 bekommen. Das sollte dann das endgültige BIOS für einen von SD-Karte bootfähigen Kernel sein.

Auf dem Floppy Controller soll es dann noch ein eigenes ROM geben, dass dann von Floppy booten kann. D.h. die jetzt noch verfügbaren 794 Byte im System ROM (ich dachte zuletzt, es wären nur noch 700) können dann noch für anderen Unsinn verbraten werden (nein NorbertJ da bekomme ich beim besten Willen kein PacMan rein ).

Wie dann das ganze für das CPM-65 von Dietrich aussieht, kann ich noch nicht vollständig abschätzen. Dietrich meinte, es wäre eventuell eine gute Idee, die CP/M Disketten als Image Dateien unter FAT auf der SD-Karte zu speichern und diese dann als virtuelle Laufwerke zu mounten.

Hier könnte man also in der BOOT.SYS statt eines Befehlsinterpreters dann einen Image Mounter und den CP/M Bootstrap Loader unterbringen.

Hab gerade bei Kleinanzeigen eine Compact-1 Rollkugelmaus für 17€ gefunden und geordert. Das Thema mit der optischen Maus werde ich aber noch weiterverfolgen und berichten.

Danke erst mal an all die hilfreichen Tipp Geber.

Zitat von Franky

...ich hoffe, dass Du beim Ausdrucken nicht irgendeinen Skalierungsfaktor (unbewusst) eingestellt hattest?

Nein, war 100%. Ich hatte da schon drauf geachtet, da ich mir schon dachte, dass das ganze sau empfindlich sein wird.

Edit: Hab gerade mal den Ausdruck mit Linienbreite 0.12 ausprobiert. Da zuckt dann bei mir der Mauszeiger garnicht mehr. Ich werde das wohl mal auf einem 1200 DPI PS Laserdrucker rauslassen. Vielleicht hilft das ja.

Edit2: Und das hier habe ich gerade bzgl. der Farben der Pad Aufdrucke noch gefunden

Ich hab jetzt gerade in einem älteren Foreneintrag von ThoralfAsmussen drei PS Programme für SUN Mäuse gefunden. Das für die Type 5 Maus setzt die Linienbreiten für Horizontal und Vertikal auf 0.12.

In dem PS Code den ThoralfAsmussen hier gepostet hat sind die Breiten 0.8 respektive 0.6, was dann auch eventuell nur für die Type 3 Mäuse passt.

Zitat von Martin Hepperle

Ich meine, dass die Linien auf den Original Sun Mousepads eher transparent blau waren und darunter eine spiegelnde Oberfläche - vielleicht hat die Photodiode ihren Schwerpunkt in einem entsprechend zu blau hin verschobenen Spektralbereich?

Mal in blau ausdrucken und ggf auf Transparentfolie und dann etwas Alu darunterlegen?

Zitat von 1ST1

Das originale Mauspad ist doch reflektierend, oder?

Ich werde mal das ganze auf eine selbstklebende Folie in blau drucken und damit eine Aluplatte bekleben. Bin gespannt.

Zitat von capmilk

Wenn du möchtest, dann lege ich meine Mausunterlage mal auf den Scanner.

Ich war damals mit dem Ding aber auch unzufrieden und habe mir für meine SparcStation eine männliche Maus gekauft. Seitdem liegt die originale Maus mitsamt Pad in einer Kiste.

Wahrscheinlich wird das Raster durch das Scannen eher unscharf. Trotzdem Danke für dein Angebot. Weißt du noch, welche Maus du als Ersatz genommen hast? Ist ja doch eine sehr spezielle Anschlussart mit dem drei poligen Mini-Din Stecker. Ist das womöglich eine "normale" RS232 Maus?

Zitat von Franky

Falls jemand mit der PS-Datei nix anfangen kann...

Schade, ich hatte jetzt mit der PDF nicht viel Erfolg. Meine Maus ruckelt sich immer noch nur schwergängig horizontal, und ein wenig vertikal. Allerdings nur nach oben. Seltsam ist, dass ich bei Vertauschen der Achsen (Blatt 90 Grad drehen) ein besseres Ergebnis habe. Der Ausdruck kam jetzt mal aus dem Office Tintenstrahldrucker. Eventuell hab ich ein besseres Ergebnis wenn ich es mal auf einem Postscript fähigen Laserdrucker rauslasse. Aber vielleicht hat ja doch die Maus einen Schaden.

Zitat von gpospi

Ja diese optischen Sun Mäuse brauchen die Raster-Mousepads.

Ja, das dachte ich mir schon. Ich war mir nur nicht sicher, weil ich annahm, die hätten noch zwei optische Sensoren für Horizontal- und Vertikalabtastung gehabt.

Zitat von ThoralfAsmussen

Probier mal das

Genial. Danke! Danach hatte ich schon gesucht, aber nichts passendes gefunden. Probiere ich morgen gleich mal aus.

Zitat von rolfp

brauchst halt so etwas.....

Hast du eine Quelle? Ich hab die leider noch nicht einzeln gefunden, oder ich verpasse die Angebote bei der Bucht immer. Wenn das mit der gedruckten Vorlage funktioniert wäre es allerdings auch schon OK. Ich hab ja jetzt nicht gerade vor produktiv mit der Classic zu arbeiten .

So, es ist vollbracht. SunOS 5.7 alias Solaris 7 ist installiert.

Für mein externes SUN CD-ROM Laufwerk hatte ich leider kein passendes Kabel (SPARCclassic : Half Pitch DB50, CD-ROM Half Pitch DB68), also zuerst der Versuch mein altes NeXT Laufwerk mit Caddy und SCSI-1 zu verwenden. Das wurde zwar mit scsi-probe-all erkannt, beim Versuch davon die frisch gebrannte Solaris 7 CD zu booten, meldete der Rechner allerdings, dass kein Laufwerk gefunden wurde (trotz eingestellter ID 6).

Also kurzerhand das SUN Laufwerk aus dem Gehäuse gebaut, und mit passendem Kabel intern angeschlossen. Hier kam dann der Fehler "Bad magic number in disk label". Mir ist dann eingefallen, dass es da bei einigen SPARCs Probleme mit den 2048 Byte Blocks gab.

Im Keller lag zum Glück noch ein SCSI-Laufwerk von einem Kunden herum, dass ich vor ein paar Monaten aus einem alten Pentium Rechner ausgebaut hatte. Das lässt sich von 2048 Byte Blocks auf 512 Byte jumpern. Ich hab dann gleich noch die doch etwas schmale 200MB Conner Platte gegen eine 4GB IBM ausgetauscht.

Mit dem neuen CD-ROM ließ sich dann Solaris problemlos installieren.

Letztes Problem ist die Maus. Die lässt sich nur horizontal in kleinen Schritten hin- und herruckeln. Die gesamte Installation hatte ich per Tastatur erledigen müssen. Jetzt die Frage an alle SUN Spezialisten: Ist das noch eine Maus, die das spezielle Mauspad mit Rasteraufdruck benötigt? Hier mal Bilder von dem guten Stück

Auf dem VcFe hatte ich mir natürlich nicht nur die Amiga vom Flohmarkt geholt, sondern dort stand auch noch diese Sparc Classic mit Vertical Stand, Tastatur und Maus. Da konnte ich natürlich nicht widerstehen.

Ich hatte bereits 2009 eine Classic bei eBay für einen Euro erstanden, bei der aber durch Blitzschlag sowohl das Netzteil als auch das Mainboard defekt waren. Ich hatte damals deshalb einfach ein Micro ATX Mainboard mit einem Intel Atom eingebaut, auf dem heute OpenSolars läuft. Jetzt doch noch eine funktionsfähige Sparc Classic mit Original Hardware zu bekommen war also einfach genial.

Klar war, das nach all den Jahren die Batterie des NVRAMs MK48T08 - oder auch Timekeeper RAM - leer sein musste. Aber zunächst wollte ich sehen, ob die Maschine noch läuft. Das Netzteil lieferte bei nur angeschlossener Festplatte auf den 5V Leitungen nur noch 4,85V, also vermutlich die Bufferkondensatoren nicht mehr in Ordnung. Die +-12V Versorgungen waren OK.

Nach dem Einschalten meldete sich der Rechner natürlich erst mal mit "The IDPROM contents are invalid", was mir allerdings erst mal egal war. Nach Eingabe von "boot disk" war klar, dass der Rechner mal an der Uni Freiburg seinen Dienst verricht hatte.

Weniger schön waren allerdings zwei sporadische Vollabschaltungen, und am nächsten Tag ließ sich der Rechner dann garnicht mehr einschalten.

Offensichtlich hatte sich der Boot Strap Elko des Schaltnetzteils verabschiedet. Also erst mal Netzteil aufschrauben und inspizieren.

Da besonders gerne die Elkos in der Nähe der Kühlkörper verenden, ging hier also erst mal meine Suche los. Und tatsächlich konnte man schon an einigen Elkonahen Bauteilen ausgelaufenes Elektrolyt erkennen. Von den drei Elkos rund um den PWM Baustein waren alle vollständig defekt, weshalb mein Vertrauen in die restlichen Kondensatoren schon ziemlich zerstört war. Die Buffer Kondensatoren für die 5V Versorgung waren auch bereits 30% unter Wert. Deshalb wurden dann von mir gleich alle Elkos getauscht. Fazit: Von 22 Elkos waren 12 entweder vollständig defekt, hatten zu niedrige Werte, oder bereits Spuren auslaufenden Elektrolyts. Nach dem Tausch läuft das Netztteil jetzt wieder zuverlässig.

Beim NVRAM wollte ich kein neues kaufen, schließlich geht es hier ja um den Erhalt alter Hardware. Aber wenigstens gibt es das noch als Option.

Prinzipiell gibt es zwei mechanisch verschieden aufgebaute Timekeeper RAMs. Das bei meiner Sparc verbaute NVRAM hatte einen "schwebenden" Anbau. D.h. der Teil mit der Batterie und dem Oszillator ist links und rechts auf den RAM/Uhrenbaustein geklebt und hat einen Spalt zwischen den beiden Komponenten.

Das macht eine Reparatur etwas schwieriger, wie sich noch zeigen wird. Um an die Anschlüsse für die Batterie zu kommen, muss man seitlich vorsichtig das Gehäuse auffräsen, was bei mir noch wunderbar funktionierte. Beim anschließenden Freikratzen der Anschlüsse, hat dann allerdings irgend so ein Depp ( ) zu kräftig mit dem Schraubenzieher zugelangt, so dass nicht nur die Anschlüsse vom Chip zur Batterie, sondern auch einer der Quartanschlüsse abgebrochen ist .

Zum Glück waren die aus dem RAM kommenden Anschlüsse noch lang genug, um hier ein Batterieanschlusskabel und einen passenden Uhrenquarz anzulöten.

Das ganze habe ich dann links und recht mit zurechtgeknippsten, aufgeklebten Teilen von Kaminzündhölzern "eingeschalt", und darauf wieder den Originaldeckel geklebt. Dann noch etwas Heißkleber zum Fixieren der Leitung und Fertig.

Den Batteriehalter habe ich auf eine Lochrasterplatine gesetzt, welche als Sandwich noch eine zweite Platine zum Schutz und zur Befestigung via Kabelbinder darunter gelötet bekommen hat. Zum Schluss noch den Original Aufkleber des NVRAMS wieder aufgeklebt und gleich mal ausprobiert.

Nach dem Speichern der MAC Adresse und Host-ID blieben die Werte dann wie erwartet auch ohne Strom erhalten. Und die Uhr tickt auch. Was will man mehr. Als nächstes muss noch ein neues Betriebssystem drauf. Das kann aber erst mal noch warten. Hauptsache der Rechner läuft wieder.

So, jetzt bin ich doch gerade selber etwas erschrocken, als ich gesehen habe, dass es bereits 6 Wochen her ist, als ich mich das letzte mal hier gemeldet hatte. In den letzten Wochen waren bei mir so viele private aktivitäten, die mich von Basteleien und dem Junior im speziellen abgehalten hatten.

Aber jetzt habe ich wieder Zeit und auch richtig viel Lust am Junior ][ weiter zu arbeiten. Hier mal meine Agenda für die nächsten Wochen:

Als erstes werde ich mich noch ein wenig um die Software kümmern, sprich den Boot Code zumindest mal soweit angehen, dass auch jemand anderes als ich ein kleines DOS für den Junior basteln könnte. Dazu wird eventuell nochmal eine kleine Änderung am ROM Code nötig sein, weshalb ich mich vielleicht auch gleich noch mit dem fehlenden Treiber für einen (parallelen) Papertape Reader beschäftige.

Der nächste Punkt ist die dritte Erweiterungsplatine. Hier soll zumindest ein Grafikprozessor und ein Floppy-Controller drauf. Eventuell auch gleich noch eine Banking Logik um die zweiten 64K RAM anzusprechen. Eventuell kommt aber auch gleich noch ein weiterer 128K RAM Baustein mit drauf. Ein Joystick-Port wäre natürlich fein, ließe sich aber auch mit dem zweiten VIA des bisherigen IO-Boards erledigen. Mal schauen.

Beim Grafikprozessor war ja der ESP32 mit FabGL eine große Option. Hier werde ich mich wohl erst mal mit der FabGL beschäftigen müssen. Das Interfacing ist hier auch noch nicht ganz geklärt.

Beim Floppy Controller hatte ich zuerst überlegt, diesen mit einem ATMega zu realisieren. Das war mir aber dann doch zu viel Aufwand, da die MFM Codierung doch recht zeitkritisch ist und ich dann alles hätte in Assembler schreiben müssen. Ich habe mich jetzt deshalb für den GM82C765B Floppy Sub System Controller entschieden, der bei UTSource noch in ausreichender Stückzahl und recht günstig zu haben ist. Ich werde dort in den nächsten Tagen mal ein paar ICs auch für andere Projekte bestellen und mich dann ausgiebig mit diesem Controller beschäftigen.

So weit erst mal wieder ein Lebenszeichen von mir. Ich hoffe, es gibt noch ein paar wenige, die sich für den Junior ][ interessieren, um mich da weiterhin ein wenig vorran zu treiben.

Cheers

Jörg

Zitat von PC-Rath_de

Der Stecker ist doch sicherlich mal durch meine Hände gegangen?

Hab gerade mal nachgesehen: eBay Händler tatsächlich pc-rath_de. Da hätte ich mir aber eigentlich schon einen Foren-Rabatt erhofft.

Jedenfalls Danke für den Stecker samt Gehäuse. Hast meinem Amiga das Leben ein Stück bunter gemacht (mit meiner Löt-Hilfe natürlich ).

Zitat von Gardenman

Na dann ist doch gut, daß man schon bei AmigaOS1.3 die Gui "anpassen" konnte. Für die Zeit eigentlich schon ganz schön.

Wie war das eigentlich bei den AtariSTs und den Macs zu der Zeit? Ging sowas dort auch?

Mit dem Resourcen Editor ResEdit konnte man unter MacOS so ziemlich alles anpassen, im Control Panel war das aber - wenn ich mich richtig erinnere - nicht möglich. Beim Atari hab ich keine Ahnung ob es möglich war das Aussehen des (der) Maus Cursor zu ändern.

Edit: Ich meinte natürlich, den Maus Cursor zu ändern, war im Mac Control Panel nicht möglich. Sound, Background Pattern Farbe, etc natürlich schon.

So, jetzt hab ich meine absolute NICHT-Lieblingsarbeit vollendet. War aber für einen guten Zweck, nämlich der Amiga den grauen Star austreiben, sprich ein RGB Kabel basteln.

Ein SCART Kabel hatte ich letztes Jahr noch irgendwo bestellt um für meinen Triumpf Adler Alphatronic PC auch mal ein RGB Kabel zu löten. Hatte da aber irgendwie noch keine Lust gehabt. Jetzt musste ich feststellen, dass diese Kabel wohl offensichtlich doch nicht mehr sooo in Gebrauch sind, sonst wäre wohl deren Qualität wohl nicht so grotten schlecht. Teilweise waren an den Crimpanschlüssen Übergangswiderstände von 500-600 Ohm messbar, weil die Anschlüsse schlampig gequetscht waren.

Wie auch immer. Mission erfüllt, mein Amiga kann nun auch Farbe.

Beim Mauszeiger konnte ich leider nicht anderns als den in was brauchbares zu ändern. Bin halt ein alter MacOS Liebhaber. Sorry

Aber dieses Pfeil Dingsda der Work Bench ist doch echt ziemlich gewöhnungsbedürftig.

Leider hat sich übrigens nach ein paar Tagen herumliegen der Zustand des Floppy Laufwerks wieder etwas verschlechtert. Ein Booten war erst nach zwei Anläufen möglich. Hier muss ich also demnächst nochmal ran.

Nachdem der Amiga jetzt mal so weit wieder lief, war zunächst nur noch das Fehlen einer Workbench Diskette das abschließende Problem. Im Internet konnte ich dann für wenig Geld eine Workbench 1.3 und die Amiga Extras 1.3 mit Amiga Basic 1.2 Disketten erstehen.

Beim Booten gab es dann allerdings neben ständigen Lesefehlern ein sehr unangenehmes Quietschgeräusch aus dem Laufwerk. Offensichtlich hatte sich der Wasserschaden auch auf das Lager des Steppermotors für den Schreib-/Lesekopf ausgeweitet. Mit einem Tropfen Maschinenöl in die Achslager, etwas Schmierfett auf die Spindel und einer gründlichen R/W-Kopf Reinigung wurde der Bootvorgang mit jeder Wiederholung dann etwas besser ausgeführt.

Mittlerweile startet der Rechner ohne Quietschen vollständig bis zum Desktop, und eine Backup Kopie der Workbench-Diskette konnte ich auch schon fehlerfrei erstellen.

Nächstes Projekt ist nun noch ein RGB-Monitorkabel. Die etwas unübliche DB-23 Buchse ist jedenfalls schon mal bestellt.

Zitat von 286Micha

ich werde den "Flugrost" daher lieber "entfernen".. (was ja klar ist )

Besser is das!

Rostumwandler ... ?

Wo gibt es sowas ?

Scheinbar hat der tatsächlich braunen Rost in "Glanz" verwandelt (vorletztes Bild).

Oder warst da noch mit Schleifpapier drean ?

Den Rostumwandler hatte ich noch im Keller meines Vaters gefunden. War ursprünglich für Autorost gedacht, sprich es gibt so was auch im KFZ Zubehörhandel.

Die Schleifspuren stammen noch von der Vorbehandlung mit der rauen Seite eines Küchenschwamms. Ansonsten ist es so, wie Holger gesagt hat. Es bildet sich eine Eisenphosphatschicht, die dann als Schutz vor weiterem Rost drauf bleibt. Das sieht dann so leicht gülden aus.

Auf dem VCFe in München konnte ich nicht widerstehen und hab mir dort auf dem Flohmarkt eine(n) Amiga für wenig Geld gekauft.

Da ich eher aus dem Apple Lager komme, waren für mich Commodore Amiga und Atari ST eigendlich nie von Interesse gewesen. Mittlerweile besitze ich nun aber zwei Atari ST und noch keine Amiga, deshalb wurde es also Zeit.

Ein erster Blick auf das neu erstandene Schmuckstück zeigte schon, dass hier etwas getan werden musste. Eine Gehäuseecke war vollständig herausgebrochen und der Verdreckungsgrad war unanständig.

Ausserdem war weder eine Maus, noch ein Netzteil im Karton. Das Netzteil konnte ich dann gleich auf dem VCFe via eBay kaufen. Vermeindlich defekt, was mir aber egal war, ich brauchte eigendlich nur den quadratischen Netzteilstecker.

Als ich den Rechner dann zuhause das erste mal öffnen konnte, war klar, dass der Wasserfleck auf dem Karton entstanden war, als sich die Amiga darin befand.

Das Mainboard hatte ein paar Stellen, an dem das Kupfer schon leicht angegriffen war. Allerdings allesamt Masseflächen und ohne Kontaktierungsverluste. Nach der Reinigung der Platine waren dann erst mal keine weiteren Probleme zu erkennen.

Das (defekte) Netzeil war mittlerweile auch eingetrudelt. Also aufschrauben und erst mal schauen, ob doch was zu retten ist. Und siehe da, an der Platine waren alle Spannungen vorhanden. Allerdings tat sich nach dem Anschluss an den Rechner nichts. Am Floppylaufwerk kamen gerade mal 300mV an. Die +/-12V waren aber in Ordnung. Als ich mir dann den Netzteilstecker ansah, war klar, dass dieser auch mal Feuchtigkeit gesehen hatte. Die Pins waren alle ziemlich grün. Also den Stecker erst mal mit Essig, dann mit Alkohol und zum Schluss mit Kontaktspray fluten. Nach dem erneuten Anschluss an den Rechner tat sich zwar immer noch nichts, dafür war aber die 5V Versorgungsspannungen auch an den einzelnen ICs in Ordnung.

Eine Oszi-Messung am Takteingang der 68000 zeigte dann, dass dort nichts taktete, dafür war aber der 28MHz Takt am Quartz vorhanden. Ein Blick auf den Schaltplan zeigt, dass Fat Agnus für die Takterzeugung zuständig ist. Nach einem Wasserschaden also das nächstliegende probieren: IC aus der Fassung, Kontaktspray reinpusten und nochmal probieren. Und tatsächlich bekam ich dann auf dem Bildschirm nach kurzer Zeit die Aufforderung eine Boot Diskette einzulegen.

Allerdings leuchtete die Power LED auf dem Keyboard noch nicht, die Caps Lock LED wollte auch nicht leuchten und Ctrl-Amiga-Amiga hatte keinen Reset Effekt. Wieder ein Blick auf den Schaltplan zeigte, dass die Power LED einfach direkt zwischen dem Status Pin und Masse geschaltet ist. Und genau hier war das Problem. Die Pins Masse, Status und In Use waren im Stecker weggerottet. Glücklicherweise hatte ich noch genau ein 8 poliges Anschlusskabel mit Stecker und - witzigerweise - genau der gleiche Farbkodierung.

Nach dem umlöten der Stecker tat dann der Rechner wieder soweit vollständig!

Der Rest war dann intensives Schrubben der Tastatur, die wohl offensichtlich in einem Katzenhaushalt ihren Dienst getan hatte und behandeln der Abschirmbleche mit Rostumwandler.

Beim Gehäuse tat sich dann bei eBay ein unbeschädigter Ersatz für ein paar Euro auf.

Da ich wie gesagt nie mit einer Amiga gearbeitet habe, fehlt mir zum Glücklichsein noch eine Workbench Diskette. Vielleicht findet sich ja auf der kommenden CRT in Stuttgart ja ein (Kopier) Spender. Ich komme jedenfalls mal mit ein paar leeren Disketten vorbei. Ansonstenwürde ich mich auch freuen, falls hier im Forum jemand zufälligerweise eine Kopie übrig hätte.

Jetzt muss ich doch noch ein ROM Update nachschieben, weil sich in der Version 1.0.3 zwei Fehler eingeschlichen hatten.

Zum einen konnte nach einer Umschaltung der Standard Eingabe von ASCII-Tastatur auf Terminaleingabe (z.B. in BASIC via IN#0) die XModem Routine nicht mehr fehlerfrei Daten lesen. Jetzt läuft alles wieder so wie es soll.

Das andere Problem hatte sich in der Boot Routine ergeben.

Ich war stillschweigend davon ausgegangen, dass ich im Boot Block der FAT32 Partition auf der SD-Karte das erste Byte (x86 Opcode $EB = short jump) gegen einen 6502 Opcode $B0 = BCS (Branch on Carry Set) austauschen kann, damit ich nur noch zum Anfang des Boot Block Buffers ($0600) springen muss, um den Boot Code zu laden. Es hat sich aber herausgestellt, dass Windows eine Änderung an genau diesem Byte des BB nicht wirklich mag und nach einer solchen Änderung die SD-Karte immer als unformatiert angezeigt wird.

Die Lösung ist nun, erst nach dem Einlesen des Boot-Blocks, den Wert $EB im RAM Buffer an $0600 gegen ein $B0 zu tauschen und dann erst mit einem JMP $0600 den Boot-Code auszuführen.

Ich hab jetzt mal einen kleinen Dummy Boot-Code in den Boot-Block geschrieben. Das ganze sieht dann gerade so aus.

Der nächste Schritt ist nun, das Root Directory zu lesen, eine Datei BOOT.SYS zu finden und diese zu laden. Somit können dann die FAT-Treiber und das DOS vom Datenträger geladen werden.

Zitat von Antikythera

Kleiner Tipp: morgen ist ab 18 Uhr wieder ein Retroabend im shack und nächste Woche findet dort die zweitägige CRT statt.

Morgen wird es bei mir leider nichts. Aber an der CRT sollte es evtl. klappen. Am Samstag werde ich wohl so gegen 13:30 Uhr auf dem Campus sein und dann mal sehen, ob man in das Computermuseum rein kommt (je nach Andrang).

Wo habt ihr denn den WANG 144-T ausgegraben? Hast du den mitgebracht, oder war der irgendwo im Uni-Keller gelegen?