CBM 8032: Mein neues Restaurationsobjekt

Zitat von tuti

Bei der Auswahl des nun zu brennenden BINs habe ich mir beide noch einmal angesehen:

[...]Dann wäre dieses ROM also wohl wirklich für beide Grafikchips geeignet. Aber es hat halt diese Byte 0x00 am Einsprungspunkt. Vielleicht ist der Einsprungspunkt hier ein anderer? Nur welcher?

Dass in einem Manual steht, dass die HSG mit sys40960 initialisiert wird und dass dann dort nur ein "BRK" Befehl steht hat mich nicht losgelassen.

Kann es vielleicht sein, dass der Break/Interrupt-Vektor zuvor auf einem anderen Wert gesetzt wurde?

Ich habe verstanden, dass bei CBM_Ba die Karte funktioniert. Wohin zeigt denn Dein Brk/IRQ Vektor bei einer funktionierenden HSG Karte ?

obbi

Zitat von obbi

Ich habe verstanden, dass bei CBM_Ba die Karte funktioniert. Wohin zeigt denn Dein Brk/IRQ Vektor bei einer funktionierenden HSG Karte ?

Und wer sollte den BRK-Pointer vor dem Initialisieren des ROMs entpsrechend gesetzt haben?

Das kann eigentlich nicht sein. Eine $00 am Einsprungpunkt muss ein Fehler sein. Ist das bei CBM_Ba auch so?

Zitat von tuti

Vielleicht ist der Einsprungspunkt hier ein anderer? Nur welcher?

Ich kann mir das ROM gerne mal anschauen, wenn das gewünscht ist. Wo ist das verlinkt?

Oder wurde das schon analysiert?

Zitat von tuti

So, EPROMs sind gelöscht (übrigens erstmal mit diesem Ultraschall-Ding, das letztens in einem anderen Thread Thema war ).

Eproms löschen mit Ultraschall?

Wenn an A001 A0 steht, ist klar was passiert ist.

Zitat von detlef

Zitat von obbi

Ich habe verstanden, dass bei CBM_Ba die Karte funktioniert. Wohin zeigt denn Dein Brk/IRQ Vektor bei einer funktionierenden HSG Karte ?

Und wer sollte den BRK-Pointer vor dem Initialisieren des ROMs entpsrechend gesetzt haben?

Das kann eigentlich nicht sein. Eine $00 am Einsprungpunkt muss ein Fehler sein. Ist das bei CBM_Ba auch so?

Post 80 RE: CBM 8032: Mein neues Restaurationsobjekt enthält einen Link zum ROM-Image.

Auch über eine Internetsuche findet man genau dieses Image.

Ich habe mir das mal im Disassambler angesehen und für mich ergibt das alles keinen Sinn.

Evtl. sind einfach alle Images falsch?

Dann könnte CBM_Ba evtl. sein Image mal hier teilen

Wenn man den Code start Point auf A001 setzt, kommst auch nichts vernünftiges bei raus.

Das mit dem geänderten Break Vektor war nur eine erste Idee .

Ich kenne die HSG Karte leider nicht, und weiß deshalb nicht, ob da nicht evtl. noch eine andere Resetroutine ins Spiel kommt

obbi

PS.: Sorry: Ich wollte noch sagen: Das Disassembling ergibt im späteren Verlauf keinen Sinn. Der Ausschnitt oben sieht fast ok aus. Statt dem BRK müsste da was anderes stehen. Sinnvoll wäre m.E. nur ldy

Einfach die ersten beiden Bytes weglassen. Das ist die Startadresse.

Zitat von tuti

Zitat von Toast_r

Einfach die ersten beiden Bytes weglassen. Das ist die Startadresse.

Das klingt spannend. War mir nicht aufgefallen. Das probiere ich aus. Müssen jetzt aber erst einmal nach Mutter und Schwiegermutter sehen. Ich werde berichten...

Da bin ich auch gespannt.

Ich habe das ROM Image mal in verschiedenen Variante disassembliert und für mich ergibt keines einen rechten Sinn. Der Anfang (ab A002) kann getrost als Initialisierung verstanden werden. Wenn man dort beim vorliegenden Image startet, springt im spätere Verlauf ein JMP direkt auf einen Vergelichsbefehl.

Das muss nicht falsch sein, wäre aber schon ungewöhnlich.

Wenn ich das ganze Image um zwei Byte verschiebe, sieht es besser aus, im späteren Verlauf stoße ich dann aber auf einen Befehl, der versucht ein Byte im ROM zu imkrementieren

Auch ist es ungewöhnlich, dass das Image 4113 Bytes groß ist.

4096 Bytes fände ich nachvollziehbarer

obbi

PRG Dateien beginnen beim CBM immer mit der Startadresse. Das ist also nicht ungewöhnlich, sondern Standard.

So eine Datei sollte man dann allerdings nicht ohne weitere Bearbeitung in .BIN umbenennen.

Eigentlich müsste die Datei dann aber 4098 Bytes groß sein.

Jungs,

hier mal das Image der Original HSG mit 512x512.

Soeben frisch für euch gezapft!

Have fun!

Das aktuelle BIN-File von CBM_Ba und das BIN-File "hsg a000-afff.bin" aus dem älteren Beitrag (das um eine Bytes zu lang ist) sind im Bereich 0000-0EFF identisch. Ab 0F00 kommt aber nichts sinnvolles mehr. Aber wenn die Anfangsadresse mitgebrannt wurde, dann kann es ja auch nicht funktionieren.

Am besten das File von CBM_Ba nehmen, das hat die richtige Länge und lässt sich so direkt brennen.

Das hat sich jetzt überschnitten.

Ich habe mal das ROM von CBM_Ba durch den Assembler gejagt und hier angehängt:

Beitrag

RE: Data Becker Highres Grafikboard - der Versuch eines Nachbaus

gelöscht, weil falscher Thread

detlef

10. März 2024

detlef

Weil es grad gut passt: Genau DIE Karte baust du nach!

Passt meines Wissens nach aber nur in die Boards der 12" Varianten (40xx/80xx).

Oder aber- und da bist du auf 80 Zeichen begrenzt- die Data Becker Karte!

Evtl. schreibt zitruskeks aber noch richtig ausführlich was dazu- er hat ja auch noch weitere Karten nachgebaut (unter anderem diese Supersoft-Teile, die wohl auch im 3032 funktionieren. Diese hat AndyG schon erfolgreich getestet!

tuti

Jetzt gehts los! Lass ihn die Columbia aufs Phosphor hämmern.

Viele Grüsse, ihr Grafikzwirbler!

Na dann lasse ich mich derbsten überraschen!

Geht sie denn?

Mit dem Screen ist so ne Sache. Ist halt ein komplett anderer Grafikmodus als die Pets selber ausgeben. Ausgegeben auf einem Fixfrequenzmonitor. Ich denke ideal ist für die HSG ein dedizierter externer Monitor. Oder man findet einen Einstellungskompromiss.

Ok, neuer Versuch.

Also ich habe mal das ROM durch den Disassembler gejagt und hänge das der vollständigkeithalber hier mal.

Ich habe jetzt die Memory Map der Karte nicht mehr im Kopf. Ich nehme an, dass ab $AF00 der Controller eingeblendet wird?

Ansonsten sieht alles aus wie eine typische Basic-Erweiterung mit Befehlsliste und Sprungtabelle.

Zitat von CBM_Ba

detlef

Weil es grad gut passt: Genau DIE Karte baust du nach!

Passt meines Wissens nach aber nur in die Boards der 12" Varianten (40xx/80xx).

Oder aber- und da bist du auf 80 Zeichen begrenzt- die Data Becker Karte!

Nein. Ich fürchte nicht.

Ich suche ja eine Grafikkarte, die sich pixelgenau über den Textmodus legt. Mit gleicher Auflösung und auch ohne externen Monitor. Denn genau so eine Grafikereiterung hatte ich damals in meinem 3032. Und sie darf den Bereich $9000-$A000 nicht blockieren. Da liegt mein Exbasic. Diese Karte hier liegt ja anscheinend mitten drin ($A000) und blockiert alles.

Es gibt ja noch das Eltec-Board für den 3032. Ich weiß jetzt aber schon gar nicht mehr, in welchem Speicherbereich das arbeitet.

Zitat von obbi

Wenn ich das ganze Image um zwei Byte verschiebe, sieht es besser aus, im späteren Verlauf stoße ich dann aber auf einen Befehl, der versucht ein Byte im ROM zu imkrementieren

Mir hat meine obige Erkenntnis keine Ruhe gelassen.

Bei einem bisschen Nachforschen ist mir klar geworden, dass offenichtlich bei AF70 die Register des GDP eingeblendet werden.

Dann ergibt alles einen Sinn.

Schon blöd, wenn im Internet bin-files bereitgestellt werden, die eigentlic PRG Files sind

obbi

PS: Ich sehe gerade detlef ist zu der gleichen Erkenntis gekommen

Das Problem mit den RAMs im RCT hatte ich schon öfter- und dein Kompromiss ist dir sehr gut gelungen! Die HSG beginnt „sehr weit unten“, das ist wohl normal.

Auf der letzten CC haben wir mit dem RCT so unsere Erfahrungen gemacht.

Sowohl gute ICs als schlecht gestestet, als auch umgekehrt.

Zitat von tuti

Jetzt hat die Grafik keine Fehler-Pixel mehr:

Und eine Kompromiss-Bildjustage zwischen Text und Grafik konnte ich auch finden.

Cool! Ich freu mich besonders da du damit auch die Funktionalität des 512*256 Modes bestätigt hast.

Mit dem RCT ist doof. Für den Preis (und die Geheimniskrämerei drumrum).

Zitat von tuti

Ein RAM zickt (obwohl im RCT alle gut waren). Habe ich erst einmal auf den 2. Screen gesteckt. Jetzt hat die Grafik keine Fehler-Pixel mehr:

Darauf wurde ja schon öfter hingewiesen, dass der Chiptester nicht prüfen kann, ob ein Baustein 100%ig in Ordnung ist. Dafür müsste er mit den jeweiligen Grenzwerten testen (Spannungen, Frequenzen und eigentlich auch Temperaturen). Der kann nur feststellen, ob ein Baustein definitiv kaputt ist, woraus man in den meisten Fällen schließen kann, dass er wohl in Ordnung ist.

Wie gesagt, auch ich hatte zigfach falsche Aussagen mit dem RCT. Aber klar, er kann nicht zaubern.

- 4116 werden selten korrekt geprüft (klar, komplett Defekte schon)

- 74er Logik lag auch schon oft daneben- da wird es wohl an den Timings der Bausteine liegen? Kenne mich ja nicht so aus

Jedenfalls verwende ich den Tester wirklich nur als ganz groben Anhaltspunkt.

Bei der HSG-Karte hatte ich doch auch das Thema mit den Grafikfehlern beim Ausführen von HCOPY. Es war einer der RAM-Bausteine, aber der RCT testete alle gut, auch mehrfach.

Deshalb: Nicht zu 100% drauf verlassen, Burschen- als generelles Testwerkzeug zum groben ranwursteln an den Fehler ist er jedoch schon klasse.

Viele Standardbausteine kann man auch mit dem TL866 bzw. T48 prüfen (natürlich nicht die alten RAMs). Aber da hat man prinzipbedingt das gleiche Problem.