Olympia Boss C vom Trigger58 übernommen

    Wie ich schon in der Kurzvorstellung schrieb, habe ich den Boss C von Trigger58 übernommen.

    Zerlegt ist er schon....

    Trigger hatte dazu auch ein paar Fragen gestellt, habe ich gelesen.

    Die Doku zum Rechner wird von hier stammen.

    Gibt es weitere Pläne zum Rechner oder der Graka?

    Die ZIP zur Graka/CRTC dazu habe ich. Da drin sind 15 Seiten Doku, aber nur eine Seite Plan.

    Da fehlen noch 2, und es ist auch eine andere Version.


    In dem Rechner war als SNT ein Astec AA11500. Das kann auch nicht das originale SNT sein,

    da das mit 115/230V läuft.

    Gibt es von dem org. NT Fotos oder ist noch eins irgendwo am Einstauben?

    Tastatur sehe ich mit Müh und Not, dass der Cursor woanders hinspringt.

    Diskette ist z.Z. erst mal egal.

    Erstmal muss ich was sehen.

    Es liegt nicht am CRTC-Controller und auch nicht an den EPROMs.

    Ein Video:

    1000000076.mp4
    MagentaCLOUD - Alle Dateien sicher an einem Ort
    magentacloud.de


    Pläne wären ja mal schön.....


    Deswegen ja auch meine Fragen.

    Mit Schematic kann ich auch nicht diesen,

    habe auch keinen Boss oder ähnliche vergleichbares


    aber ich würde erst mal schauen wenn wir das rechts Mitte als "Boss* identifizieren als Hardware init/ progroamm bezeichnen

    ob das Disketten System Laufwerk, Tastatur funktioniert

    nach der Anleitung, wenn du aueine leere Diskette zugreifen kannst sollte das rundominäre soweit auch funktionieren,



    Wenn dies schon nicht funktioniert, müssen wir tiefer einsteigen,

    Graphikkarte, Ansteuerung, Monitor,

    dazu benötigen wir im Forum aber mehr hochauflösende Bilder

    Noch ein einzelne Foto von vorher, da sieht man das:



    Die ganzen anderen Freds kenne ich bereits:

    Thema
    Olympia Boss Z80 Fehlersuche
    Guten Abend,

    habe von @rfka01 das Topmodell der Olympia Boss Serie mit 5 MB Festplatte bekommen, den @MarNo84 auf Youtube mal hier vorgeführt hat.

    Leider funktioniert er nicht mehr und ich gehe hier mal weiter auf Fehlersuche.

    Vermutlich hat das Originalnetzteil mit seinem hohen Ripple auf der 5V Schiene irgendwas zerstört. Auf +5V hatte ich unregelmäßige Nadelausschläge bis auf ca. 6 V gesehen. Ich hatte das Problem unter Last und ohne Last.

    Ich habe jetzt ein Zweitnetzteil angeschlossen,…
    Aquarius
    Thema
    Olympia Boss ROMs und Bilder
    Boss D: Hier sind ROMs und Bilder vom Mainboard und den Steckkarten zum Download

    Boss B, C, D: Hier gibt es Infos zum CRT-Controller
    Aquarius
    Thema
    Olympia Boss D Prologue Harddisk Support
    Hier das Image des Prologue Betriebssystems auf einer frisch formatierten Seagate ST-506.

    Prologue lässt sich im Boss D direkt vom Einschaltbildschirm booten. (Return Taste drücken)

    Basis ist die Z80-Architektur.

    Ich habe verschiedene Prologue-Kernel aufgespielt:
    MBOSS3
    MBOSS3A
    BOSS1
    BOSS3
    Aquarius
    Thema
    Suche Position eines Bauteils in einem Olympia Boss
    Moin,
    ich habe ja den Olympia Boss Typ B oder C aus den Kleinanzeigen gekauft. Nach Sichtung des Computers und aller beiligenden Teile muss ich leider feststellen, das die Reparatur doch aufwendiger wird als gedacht.

    Eines vorweg: Der Vorbesitzer ist leider verstorben. Ich habe daher leider keinerlei Informationen darüber, was genau vorher alles an dem System verändert worden ist.

    Daher habe ich zwei Fragen:

    1.) Gibt es hier eine Schematic vom Z80 Mainboard des Olympia Boss?

    2.) In dem beiligenden…
    Trigger58




    Wie gesagt, Diskette ist z.Z. irrelevant, erstmal muss das BIld stimmen.

    Deswegen auch oben unter #4 meine Frage.

    Runtergeladen haben ich soweit auch alles an Doku und Software, so ich nichts übersehen haben.

    Zum Graka gibts ne ZIP mit 15 Seiten Doku aber eine Seite Plan.

    Pläne scheint den Links nach jemand zu haben.

    Hat dein Grafikboard einen CRT-Kontroller Type uPD3301 ?

    Dieser muß nach einem Reset bzw. beim Einschalten erst programmiert werden, damit durch ihn u.a. die

    passenden Timings generiert werden.

    U.U. werden diese Daten dabei nicht vollständig/korrekt übermittelt.

    Ja, das was hier im Forum zu sehen ist.

    Der 3301 steckt da drin.

    Es sieht schon so aus, als ob das nicht passt.

    Schätze mal das H-Sync und V-Sync nicht richtig erzeugt werde, sonst würde das Bild stimmen.

    Drum auch vorn die Frage, ob dafür der RAM dafür gebraucht wird.

    Wollte ich mir die Tage dann mal vorknöpfen.

    Das Ram wird in der Regel hierfür nicht benötigt. Wenn die dargestellten Charakter keinen Sinn ergeben, dann ist das meist

    ein Problem mit dem Ram. Für die Initialisierung des 3301 , die ganz zu Anfang nach dem (PowerOn-)Reset, stattfindet, werden die Werte

    aus dem (E-)Prom gelesen und von der CPU an den Kontroller übertragen. Da könnte es ein Problem geben.

    Ohne Schaltplan lassen sich die daran beteiligten Bausteine nur schwer identifizieren. Mit einem Oszi oder Logicstift wurde ich die

    Datenleitungen am Controller während des Einschaltvorganges überprüften. D.h. Es müssen Signale vorhanden sein, die nicht permanent High-

    oder einen Low_Pegel aufweisen.


    Ich habe erstmal diesen RAMTEST07 durchgeführt.

    Auf die Tastatur scheint der Rechner nicht zu reagieren.

    Die oberen 32kb sind wohl ok. Bei den unteren 32kb gibt es

    hier und da bei DB2 Probleme.

    Manchmal wird der RAM auch gar nicht gefunden, das Ganze scheint auch noch temperaturabhängig zu sein.

    Mal gucken, wie ich das mache.


    Hallo Enrico,


    wie ich sehe hast Du den Test von hier ausprobiert: RAMLOW 007


    Während der Test läuft funktioniert die Tastatur nicht. Das ist eine spezielle Software, die ohne RAM laufen muss. Daher sind die Funktionen sehr eingeschränkt.


    Beim unteren RAM gibt es Probleme, aber soweit ich gesehen nicht nur "hier und da", sondern fast dauernd!



    Die Meldung, dass das RAM nicht gefunden wurde (Check for RAM exist... NOK) bezieht sich auf einen Test, bei dem die Adresse 0000 gelesen, invertiert und ins RAM zurückgeschrieben wird. Danach wird die Speicherzelle nochmals gelesen und wenn der Wert nicht passt ... ABORT. (Siehe Quellcode)





    Hier ist die Routine über den ersten Test hinweggekommen und bringt Fehler beim Test mit dem Wert 00



    Der Test beginnt bei Adresse 0000. Interessant ist, das erst bei 001E ein Fehler gefunden wird, obwohl der Dump auch schon bei 000E einen falschen Wert anzeigt! Offenbar wird beim Lesen nicht immer der gleiche Wert zurückgeliefert. Muss also vorher (bei 000E) den richtigen Wert 00 gelesen haben.


    Jedenfalls hat das betreffende Bit (X) ein Problem, also binär gesehen 00000X00. Die anderen Bits scheinen bis hierher korrekt zu sein. Das dürfte sich auch in dem Wert vom ersten Test wiederspiegeln, wo der gelesene Wert hex FB war. Hier schien auch das gleiche Bit betroffen zu sein: binär 11111011, wobei man hier nicht sagen kann welcher Wert vorher im RAM stand und dann invertiert wurde.


    Ich kenne die RAM-Struktur leider nicht, aber wenn pro Bit ein RAM verbaut ist, dann würde ich mal dieses RAM tauschen. Eventuell auch die Datenpfade, bzw. die Enable-Leitungen überprüfen. Falls Du kein neues RAM zur Verfügung hast, dann einfach zwei RAMs vertauschen. Dann müsste der Fehler auf ein anderes Bit wandern.


    Ich wünsche gutes Gelingen!


    PAW

    Guten Morgen PAW!

    Zitat von PAW

    Hallo Enrico,


    wie ich sehe hast Du den Test von hier ausprobiert: RAMLOW 007


    Während der Test läuft funktioniert die Tastatur nicht. Das ist eine spezielle Software, die ohne RAM laufen muss. Daher sind die Funktionen sehr eingeschränkt.

    Ja, der Test von Dir.

    Da dort "D]ump A)bort", etc drin steht, dachte ich dass es so wäre, oder noch eher

    die Serielle dafür abgefragt wird.


    Sehr schön danke, Deine Erkärungen zu den Quellen helfen mir da schon weiter.


    Wie mans nimmt, bei einigen Durchläufen ist Bit 2 wesentlich seltener defekt.

    Von daher würde ich nicht unbedingt davon ausgehen, dass es wirklich der eine RAM ist.


    Das sind 32 Stück 16kx1D-RAMs.

    Da Du den Test geschrieben hast, hätte ich vermutet, dass Du das weist.


    (irgendwie komme ich mit der Zitiererei nicht wirklich zurecht; Zitat auftrennen, dazwischen rein antworten....)

    Zitat von Enrico

    (irgendwie komme ich mit der Zitiererei nicht wirklich zurecht; Zitat auftrennen, dazwischen rein antworten....)


    Hallo Enrico,


    das mit dem Zitat ist recht einfach. Du markierst den Text, den Du zitieren möchtest. Dabei scheint ein Feld auf "Zitat speichern". Wenn Du drauf klickst, erscheint dann rechts unten eine Anzeige "EIN ZITAT". Wenn Du dann in Deinem Beitrag dieses anklickst kannst Du ein oder mehrere Zitate einfügen (inkl. Link). Das funktioniert aber nur innerhalb des gleichen Themas (habe ich zumindest festgetellt).



    Zitat von Enrico

    Da dort "D]ump A)bort", etc drin steht, dachte ich dass es so wäre, oder noch eher

    die Serielle dafür abgefragt wird.

    Die Abfrage findet erst statt, wenn ein Test mit "00" fehlerfrei beendet wurde, also vor dem nächsten Test mit "FF", etc.

    Bei Dir gab es schon vorher einen Fehler, daher kommt das Programm nicht zur Abfrage.



    Zitat von Enrico

    Da Du den Test geschrieben hast, hätte ich vermutet, dass Du das weist.

    Ich habe zwar den Test geschrieben, aber Aquarius hat mir die Hardwaredetails dazu gegeben. Habe ja selbst auch keine Testmöglichkeit. Kenne mich mit PHILIPS P2500 aus und habe ursprünglich dafür das Testprogramm entwickelt.



    Zitat von Enrico

    Das sind 32 Stück 16kx1D-RAMs.

    Also falls diese gesockelt sind, würde ich als erstes einen Tausch des einen Bits durchführen (aber unbedingt dokumentieren, welcher Chip welcher ist/war). Das nicht immer das Bit2 fehlerhaft ist, kann mehrere Ursachen haben, von der internen Chipstruktur, über Timingprobleme, Buffer, etc. Wenn Du die RAMs tauscht kannst Du die Fehlersuche weitgehend auf RAM oder nicht-RAM eingrenzen.


    Grüße, PAW

    Zitat von Enrico

    Also ich vermute erstmal, dass ich nicht an dem RAM liegt, sondern eher ein Zeitproblem.

    Wenn das so ist, warum funktionieren dann die anderen Bits und nur dieses eine nicht?

    Kann natürlich sein, dass auch die anderen ein Problem machen, welches bisher nicht sichtbar ist.


    Außerdem funktionieren die oberen RAMs ja komplett.

    Hier im Forum steht, dass der Boot-ROM nur in den unteren 32kb eingebunden ist unvollständig dekodiert.

    Da ist also etwas mehr Logik dahinter, als bei den oberen 32kb.

    Der eine RAM kann etwas langsamer sein als die anderen.

    Wäre es der RAM würde das eine Bit immer defekt sein, vorrausgesetzt es wären die Ausgangs/ EIngangstreiber des RAMs.

    Wären es intern einzelne Zellen, müssten es doch immer die selben Adressen sein.

    Wären es die Bustreiber, würde gar nichts funktionieren.

    Für Probleme mit der Stromversorgung ist mehr die Fehler nicht zufällig genug.

    Dann sollten das hier und da andere Bits sein.


    Ich muss erstmal mit dem Oszi messen, und noch ein paar Seiten Pläne zusammenkritzeln.

    Ich hatte mir Pläne zusammengemalt, und danach erst dann noch eine weitere Planseite gefunden.


    Das eine Bit rausgeschnitten, nun geht es mit vielen Fehlern auf der 2. Bank weiter.

    Wenn ich das richtige sehe, sind das Adressierungsfehler?

    Es sind immer die selben Fehler.

    Aber, wie, was?


    Zitat von Enrico

    Wenn ich das richtige sehe, sind das Adressierungsfehler?

    Es sind immer die selben Fehler.

    Aber, wie, was?

    Hallo Enrico,


    das Bit 2 dürfte ja jetzt funktionieren, :thumbup:


    Beim AdrTEST geht es darum, die Adresse, die in HL steht in das RAM zu schreiben und wieder auszulesen. Bei hex 4000 sollte also 00 und in 4001 sollte 40 stehen. (low byte first). Statt 00 wird aber 40 eingelesen. Vermutlich hat da das Bit 6 ein Problem, da es dauernd auf 1 steht. (Bit 7 = highbit, Bit 0 = lowbit). Warum das aber bei den vorigen Tests nicht zum Tragen kommt?


    Unterschied zwischen den Tests ist, das vorher jeweils in eine Zelle geschrieben und dann sofort gelesen wurde. Beim AdrTEST wird das ganze RAM beschrieben und danach erst ausgelesen. Könnte sein, dass durch einen Scghreibvorgang weiter hinten, der Wert vorne verändert wird.


    Also eventuell auch Bit 6 tauschen.


    Grüße, PAW


    Code
        ;logical address space
ROMBEG    EQU    0    ;begin of ROM
ROMLEN    EQU    00800H    ;length of ROM
RAMBEG    EQU    01000H    ;begin of RAM-area    <--- must set also to 1000H by L80 !
RAMEND    EQU    01FFFH    ;end of RAM-area
RAMWORK EQU    08000H    ;begin of RAM-area for moving code

RAMCOPY EQU    0F800H    ;begin of program in RAM (copy of ROM)
    Zitat
    Zitat
    Zitat von Enrico Wenn ich das richtige sehe, sind das Adressierungsfehler?
    Es sind immer die selben Fehler.
    Aber, wie, was?

    Hallo Enrico,


    das Bit 2 dürfte ja jetzt funktionieren, :thumbup:

    Ja, das betrifft aber die 1. 16kb Bank. Die obersten 32kb waren ja anscheinend von Hause aus ok.


    Zitat

    Beim AdrTEST geht es darum, die Adresse, die in HL steht in das RAM zu schreiben und wieder auszulesen. Bei hex 4000 sollte also 00 und in 4001 sollte 40 stehen. (low byte first). Statt 00 wird aber 40 eingelesen. Vermutlich hat da das Bit 6 ein Problem, da es dauernd auf 1 steht. (Bit 7 = highbit, Bit 0 = lowbit). Warum das aber bei den vorigen Tests nicht zum Tragen kommt?


    Das ist dann aber in der 2. RAM Bank, das sind andere ICs.

    Ich habe mal den Taschenrechner gezückt, ein paar Zellen umgerechnet, bei denen ist dann schon immer das Bit 6 gesetzt.

    Warum funktioniert dann aber das Beschreiben mit dem Bitmuster?


    Zitat

    Unterschied zwischen den Tests ist, das vorher jeweils in eine Zelle geschrieben und dann sofort gelesen wurde. Beim AdrTEST wird das ganze RAM beschrieben und danach erst ausgelesen. Könnte sein, dass durch einen Scghreibvorgang weiter hinten, der Wert vorne verändert wird.


    Das wäre auch denkbar. Oder es wird falsch adressiert, der Test nennt sich ja so.

    Problem ist aber, dass für den ganzen RAM die gleiche Adresstreiber genommen werden.

    Da geht es nicht, dass die 3 anderen Bänke für schreiben/lesen richtig angesteuert werden, bei der 2. Bank

    der RAM aber für schreiben/ lesen unterschiedlich adressiert wird.

    Oder es gibt ein Problem mit dem Refresh.


    Hast Du für das Programm eine Beschreibung hinterlegt, oder die Quelle?

    Ich glaube, ich habe da nichts gesehen.

    Zitat von Enrico

    Hast Du für das Programm eine Beschreibung hinterlegt, oder die Quelle?

    Habe Dir ja oben den betreffenden Ausschnitt aus dem Sourcecode reinkopiert.


    Ich könnte mir vorstellen, dass es in dem RAM (Bit 6) in der betreffenden Bank ein Probmlem gibt. Deshalb habe ich ja auch den "Adresstest" gemacht. Bei "primitiven" Test wird halt nur in eine Zelle geschrieben und danach gleich gelesen und verglichen. Gibt es Adressierungsproblem innerhalb des RAMs bei den Zellen, dann kann es vorkommen, das beim Schreiben auf einer bestimmten Adresse, (auch) eine andere Zelle überschrieben wird.


    Daher meine Empfehlung: auch Bit 6 in der entsprechenden Bank tauschen.


    Zitat von Enrico

    Oder es gibt ein Problem mit dem Refresh.

    Eher unwahrscheinlich, weil nur das eine Bit betroffen ist und andererseits durch das sequentielle Schreiben und Lesen des RAMs eigentlich refreshed wird (unabhängig vom "normalen" Refresh).