PROM-Inhalte zusammenführen und binär darstellen
-
excel HEXinBIN
-
Ich würde ja ein kleines Progrämmchen in Java schreiben:
1) Die drei Dateien öffnen und in je ein Bytearray einlesen.
2) Neues int Array erstellen: int[] result = new int[1024]
3) Schleife über die 1024 Bytes
4) Darin den Wert zusammensetzen: result[i] = arr1[i]<<16 + arr2[i]<<8 + arr3[i]5) Dann speichern, drucken oder was anderes damit anstellen
Also ungefähr so ...
-
Es war schon spät ...
In der Schleife müsste es für korrekte Ergebnisse wie folgt aussehenCodefor (int i=0; i<1024; i++) { result[i] = ((d1[i] & 0xFF) << 16) + ((d2[i] & 0xFF) << 8) + (d3[i] & 0xFF); System.out.println(String.format("Address %04X = %08X", i, result[i])); }Ob die Reihenfolge der Bytes korrekt ist, kann ich nicht sagen.
-
Ich würde ja ein kleines Progrämmchen in Java schreiben:
Ich kenne mich mit Java nicht aus, deshalb die Fragen bitte als Fragen und nicht als Rechtfertigung verstehen.
Ist "d[i] & 0xFF" nötig, weil d[] doch als byte definiert ist und daher sowieso 8bit breit ist?
Und m.E. muss result kein Array sein. Der Ergebnis, das in result[] gespeichert wird, ist ja nur temporär.
Aber das nur nebenbei.
-
Es gibt eine sehr schöne Seite mit einem EPROM Brenner Tool, die hier auch schon paarmal verlinkt war (mir fällt nur gerade nix passendes ein, vielleicht findet es sich ja noch) und das genau das kann. Ob mit 3 EPROMs kann ich nicht sagen, aber wahrscheinlich auch das.
Ansonsten ist der Ansatz von oben brauchbar. Man kann das sogar auf der Kommandozeile (Unixoide) machen. Das sieht dann so aus
Bash
Alles anzeigen#!/bin/sh sz=$1 f1=$2 f2=$3 f3=$4 echo "size : " $sz echo "files : " $f1 "," $f2 "," $f3 for i in `seq 0 $sz` do dd bs=1c count=1 skip=$i if=$f1 >> out.file dd bs=1c count=1 skip=$i if=$f2 >> out.file dd bs=1c count=1 skip=$i if=$f3 >> out.file done echo "done , output written (appended) to 'out.file'"Eingabe sind die (Filelänge-1) und die drei Namen. Also z.B. für 3 Files mit 1024 Byte Länge
rommixer 1023 rom1 rom2 rom3
Das Skript sammelt (auf eine unglücklich komplizierte Weise) jeweils ein Byte von jeder der drei Dateien ein und schreibt diese hintereinander in out.file in der Reihenfolge wie in der Befehlszeile. Danach dann das nächste Byte usf - von 0 bis zur eingegebenen Zahl.
Wenn man das mehrmals laufen lassen will, muß zwischendurch das out.file immer per Hand gelöscht werden.
Kein Ahnung, wie gut das klappt, sollte aber.
Anzeigen geht am Besten mit einem Hexeditor. "hexdump" ("hd") oder "tweak" wären Linuxvarianten, sowas gibt es aber für alle Systeme.
Wenn Du es als 32 Bit Zahlen haben willst, müßtest Du noch eine weitere Datei anlegen, die nur "00" Bytes enthält und diese als vierte dazubringen. (braucht dann eine weitere "dd" Zeile im Script, genau wie die anderen, nur eben mit "f4", und noch dazu "f4=$5" am Beginn).
Wichtig ist außerdem die Reihenfolge der Bytes. Je nachdem was das Zielsystem erwartet, müßte "rom1 rom2 rom3" oder "rom3 rom2 rom1" benutzt werden zum Verknüpfen.
-
Wenn Du es als 32 Bit Zahlen haben willst, müßtest Du noch eine weitere Datei anlegen, die nur "00" Bytes enthält und diese als vierte dazubringen. (braucht dann eine weitere "dd" Zeile im Script, genau wie die anderen, nur eben mit "f4", und noch dazu "f4=$5" am Beginn).
Oder für die vierte Datei einfach /dev/zero nehmen. Skip kannste dann auch weglassen.
-
Zitat
Ist "d[i] & 0xFF" nötig, weil d[] doch als byte definiert ist und daher sowieso 8bit breit ist?
Ja leider muss man das in Java so machen, die Schiebeoperationen erweitern byte automatisch nach int, natürlich Vorzeichengerecht. Das Array Result ist in dem Fall tatsächlich nicht notwendig, nur falls man das Ergebnis noch irgendwie weiterverarbeiten wollte.
-
Hier noch eine Powershell-Variante:
Code
Alles anzeigen$bytes1 = [System.IO.File]::ReadAllBytes("D:\02113-80006.bin") $bytes2 = [System.IO.File]::ReadAllBytes("D:\02113-80007.bin") $bytes3 = [System.IO.File]::ReadAllBytes("D:\02113-80008.bin") $triple = @() for ($i=0; $i -lt $bytes1.count; $i++) { $triple+=$bytes1[$i] $triple+=$bytes2[$i] $triple+=$bytes3[$i] } [System.IO.File]::WriteAllBytes("D:\02113.bin", $triple) -
Der Vollständigkeit halber, noch eine C Variante. Das von 16 auf 24 bit zu erweitern, bleibt als Hausaufgabe
-
die Schiebeoperationen erweitern byte automatisch nach int, natürlich Vorzeichengerecht.
Ich haette byte als unsigned angesehen, das dann auf unsigned int erweitert wird.
Aber gut.
Danke fuer die Info.
-
Hurra Hurra!
Der 21 M Prozessor der HP1000E funktioniert wieder.
Und wie immer kleine Ursache große Wirkung:
Ein Am9334 (74LS259) mit HP-Bezeichnung (3 zu 8 Dekoder)
Dieser Baustein arbeitet als 3 zu 8 Multiplexer und generiert aus 3 Bits des Microcodes 8 Steuersignale für die CPU, nachdem die mit den passenenden
Clocksignalen (davon gibt es mehrere) synchronisiert (NAND und andere Logikschaltungen )wurden.
In diesem Falle das FETCH-Signal: MIR3 ist das Signal aus dem Multiplexer. Darüber MIR4 zeigt ein Clocksignal mit dem geNANDet wird. Heraus kommt
das Fetch als LOW-Signal. Weiter rechts ist ein weiteres Signal aus dem zu diesen Zeitpunkt ge"disable"ten Multiplexer. Es tauchen sehr viele auf, aber
solange die Clock nicht zeitgleich taktet gibt es keinen Fetch und stört nicht. Überhaupt soll das Signal nur einmal direkt nach dem Einschalten des Rechners kommen und die CPU warten lassen bis das Power-On (=Powergood) vom Netzteil kommt.
Das FETCH-Signal resettet/löscht den Stack-Pointer. D.h. Die CPU hat vergessen wo die Rücksprungadressen (z. Bsp. beim Return-Befehl) abgelegt wurden.
Ein Problem war, das man nur wenige der vielen Fetch-Signale sehen konnte. Das liegt darin begründet, daß das Clock-Signal die Signallänge
definiert. Wenn sich das Signal aus dem Multiplexer nur ganz gering mit der Clock überschneitet wird das Signal ganz schmal. Wenn dann die Sample-Zeit
des Logikanalysators nicht schnell genug eingestellt ist, werden sie als Signal nicht erkannt.
Wir haben mit unserer Einstellung, die fur die normalen Signalbreiten ausgelegt war nur wenige gesehen. Außerdem lagen sie zunächst außerhalb
der untersuchten Abschnitte. Die CPU blieb nach dem Resetten des Stackpointern ja nicht stehen, sondern verhielt sich wie "anschossen" und blieb
irgendwann in einer Schleife hängen. Wir sind den Code Schritt für Schritt durch gegangen, um den (ersten) "Tatort" zu finden.
War natürlich eine Stelle, bei der das Signal zu schmal für die Aufzeichnung war. Wir wussten daß was mit dem Stack nicht stimmt, aber warum.
Wir haben die ICs des Stacks ausgelötet und ersetzt. Kein Fehler. Dann den Pointer mit allen Anschlüssen überprüft. An der Stelle gab es keinen
Hinweis. Erst beim Durchscrollen tauchte ein sichtbares Fetch-Signal am Clear-Eingang des Pointers auf. Was macht das da? Gehört das dahin?
Der Microcode an der Adresse sagt nein. Und dann gab ne noch mehrere dieser Signale. Wo kommen die her? usw. usw.
So haben wir den Multiplexer gefunden.
Der OP-Tisch: Das EKG wurde gerade abgeklemmt
Da saß er (jetzt 74LS259)
Die CPU
Danke an alle, die uns hier geholfen haben
Rolf und Axel
PS: Wer es noch nicht mitbekommen hat Rolf ist mein Bruder. Uns gibt es immer im Doppelpack
-
Glückwunsch,
was für ein Haufen Chips. Respekt für die erfolgreiche Fehlersuche euch beiden. -
Guten Abend
damit die Mitleser unter HP1000E sich auch was vorstellen können,
, -
Guten Abend
damit die Mitleser unter HP1000E sich auch was vorstellen können,
,Danke.
Ich kanns aber leider nicht lesen.
TTL-Rechner der 70iger?
-
-
Nachtrag:
Hinter der Tür
Die CPU befindet unten im CPU-Modul (Bedenplatte entfernt und von unten fotografiert)
Durch die beiden Schächte links und rechts oben kommt Kühlluft von den Netzteillüftern und sorgt für Luftaustausch.
50 Watt Strom werden hier vorallem in Wärme umgewandelt.
Das ist die Huckepackplatine unten links.
Es ist das FAB-Board zur Aufnahme von Erweiterungsroms. Sie ergänzen den Microcode auf der CPU-Platine, damit diese
"lernt" das Bandlaufwerk und das Wechselplattenlaufwerk anzusprechen. Die notwendige Hardware, also die Interface-
karten finden oben als Einsteckkarte in den BUS ihren Platz. Wie man sieht läßt sich das noch erweitern.
Erwähnenswert sind noch die Transistoren im Metallgehäuse. Diese schalten den Strom für die ROMs ein und aus, je nachdem
ob sie gerade gebraucht werden oder nicht. Man könnte meinen, daß man damit den Stromverbrauch reduzieren wollte. Aber
weit gefehlt. Die ICs laufen heiß, wenn man sie eingeschaltet läßt, denn hierher kommt nicht genug Kühlluft.
Für wichtige ROM-Erweiterungen gibt es noch das FEB-Board. Hier sind die ROMs für die Floatingpointerweiterung oder selbstgeschriebene
Befehlssatzerweiterungen in Microcode (z.Bsp. für selbstentwickelte Hardware) . Die Karte sitzt zwischen den Interfacekarten und wird mit einem zusätzlichen Flachbandkabel direkt mit der CPU verbunden. Die ROMs auf dem FEB besitzen eine höhere Priorität im System als die auf dem FAB.
Dies Erweiterung habe ich nicht.
direkt mit der CPU verbunden
