Beiträge von dirkt

  • Olivetti P6060

    Bei der Analyse der Diskettenformate gibt es ein paar Fortschritte: Ich verstehe noch nicht alles, aber innerhalb P6FSYS sind offenbar Verzeichniseinträge mit einer magischen Bytefolge gekennzeichnet, und direkt vor dem Dateiinhalt.


    Das macht es einfach, Archäologie zu betreiben: Eines der Images, die ich habe, ist jetzt eine Userdiskette, war aber offenbar früher einmal Systemdiskette, die von Olivetti mit ausgeliefert wurde (oder eine Kopie davon).


    Da sind dann z.B. die Unterschiede von Release 2.0 zum vorigen Release beschrieben, mit Datum 25.2.77:

  • Kyroflux und Greaseweazle - Tools?

    Wie ich gesehen habe, ist das Kryoflux Stream format auch dokumentiert - ist im Wesentlichen identisch mit dem, was über USB geht, und gibt dir die Zeitabstände zwischen den Flusswechseln zusammen mit anderer Information wie Indexlöchern.


    Wenn's da nichts Fertiges gibt, kann man also auch selbst was basteln.


    Gibt's Doku für das ETS 2010 Format?

  • 286er Mainboard - DIN Tastaturanschluss Frage

    Wenn du einen passiven Adapter hast, brauchst du eine Tastatur, die die jeweiligen Protokolle unterstützt. Meine Cherry hier kann sowohl PS/2 wie USB, viele moderne USB-Tastaturen können es nicht mehr. Also genau nachschauen, welche Tastatur du dranhängen willst, und was die kann.


    Das gilt genauso für den Dongle.


    Wenn die Tastatur bzw. der Dongle es nicht kann, brauchst du einen aktiven Adapter, also einen kleinen Mikrokontroller, der die Protokolle übersetzt. Kann man selber basteln, wenn man mag, gibt's bestimmt auch irgendwo zu kaufen, wenn du keine alte Tastatur findest.

  • X-Terminal mit 88000 CPU zu anderem nutze als Terminal

    Definiere "standalone".


    Die X-Terminals damals an der Uni, die auch an HPs hingen, bekamen ihre Software per Netboot; das war halt im wesentlichen der X-Server. Der lief dann "standalone" und hing sich über XDMPC an eine der HPs, für die man ihn dann als Terminal benutzen konnte.


    D.h., im Prinzip kann der eigenständig Software laufen lassen; du wirst aber wahrscheinlich Probleme haben, fertige Software zu finden, die kein X-Server ist. Mit genügend Reverse-Engineering kann man da vielleicht was schreiben, aber das ist eher ein größeres Projekt.


    Im Prinzip hätte man die auch ins Netz zu einer modernen Linux-Kiste hängen können, und für diese dann als X-Server benutzen.


    Ob das auf dein X-Terminal zutrifft oder nicht, weiß ich nicht, das Photo macht die Identifikation nicht so richtig einfach...

  • Olivetti P6060

    Zitat von 1ST1

    Mein Kyroflux und Greaseweasle muss ich erstmal installieren, und einen Adapter auf 8-Zoll-Laufwerke hab ich auch nicht.

    Im Technikum hat es ein Adapterkabel von einem normalen IBM-PC-Floppy-Controller auf das 8-Zoll-Laufwerk.


    Wenn Roland_t29 einverstanden ist, könnte ich Kabel+Laufwerk vielleicht auch ausleihen, und auf das Treffen an der Uni Mainz mitnehmen.

  • Olivetti P6060

    Zitat von lgp30

    Wenn's ein 5100 und kein 5110 ist, würden wir den gerne adoptieren. Dann könnte ich mein Reverse-Engineering mit dem Disassemblieren der ROS beim 00er fortführen.

    Ist zwar OT für diesen Thread, aber haben die hier dich mittlerweile eigentlich erreicht? Die hatten ja einen ROM-Dump vom 00er gemacht, und konnten dich nicht per Email kontaktieren.


    Aber vielleicht hast du den ja schon, und brauchst irgendetwas anderes.

  • Olivetti P6060

    Zitat von lgp30

    Kryoflux wird das nicht viel besser können, aber vlt. hast du ja Glück.

    Hast du die Scheibe aus der Hülle rausgenommen und gereinigt? (Wasser/Spüli oder, was ich bevorzuge, Screen99). Das mache ich bei fleckigen und gammeligen Disketten immer.

    Ich hatte Kryoflux bis jetzt noch benutzt, aber da 1ST1 jetzt eins hat und in der Gegend ist, dachte ich, es wäre eine gute Gelegenheit, es mal auszuprobieren.


    Hat das nicht irgendwie einen Modus, um die gleiche Stelle mehrfach zu lesen, und dann ein wenig Statistik auf das Signal zu werfen und es so zu verbessern? Mich zumindest hätte es in den Fingern gejuckt, da so etwas einzubauen, aber vielleicht hat es das ja auch nicht.


    Gereinigt haben wir sie nicht, es war jetzt mal der erste Versuch (und wir haben nichtmal 10% der Disketten ausprobiert, aber nach der bisherigen Stichprobe sind wohl fast alle problematisch).


    Wie macht ihr das, Hülle vorsichtig an einer Seite aufschlitzen, rausnehmen, wieder rein tun? Wir haben auch keine neueren 8-Zoll-Disketten. Gibt's die irgendwo noch?

  • Olivetti P6060

    1ST1 Kurzes Update: Ich war heute im Technikum, und mit freundlicher Unterstützung von Roland_t29 habe ich mal versucht, ein paar von den Disketten als Images zu sichern. Die Disketten sind in schlechtem Zustand (sieht man teilweise auch mit bloßem Auge, einige haben erkennbare Flecken wie die, die in den Laufwerken waren). Nachdem ich die Number of Retries in Imagedisk auf 10 hochgesetzt hatte, ging es etwas besser, aber die vielen Lesefehler machen das eine sehr langwierige Geschichte. Nach einem halben Tag Arbeit hatten wir ein einziges Image ohne Fehler, und 5 Images mit zwischen 4 und ca. 60 kaputten Sektoren.


    Evtl. muss dann da doch Kryoflux ran.


    Das Image ohne Fehler war übrigens eine Systemdiskette. Das Betriebssystem ist Release 3.0.

  • Olivetti P6060

    Zitat von Raffzahn

    Hier noch ein paar Bilder bevor ich die P6066 wieder zumache:

    Basis-RAM (48 KiB) mit 4116ern.

    Interessant die Verwendung des 3242 DRAM Multiplexers/Refreshcounters. Sehr praktischer Chip der komischerweise bei Micros selten aufgetaucht ist.

    Und vielleicht bin ich ja blind, aber ich zähle da 17x einen 4116-Chip (in der unteren Reihe ist noch ein artfremder dazwischen). Das wären dann 16 Bit + Parität auf 16K, also zusammen 32K (und nicht 48K), was auch zu der Bezeichnung "ME006" passt.


    Damit hättest du dann die normale Konfiguration der P6066.

  • Olivetti P6060

    Und hier kann man den Konfigurations-Aufkleber einer P6066 sehen:



    Das entspricht der Speicheraufteilung im zweiten STAC: Slot 6 kann bis zu 64K für den unteren Speicher, von den 32K im oberen Speicher werden wahrscheinlich 4K durch den ROM überlagert. Mehr ist nicht vorgesehen.


    Raffzahn, wenn deine P6066 einen ähnlichen Aufkleber hätte, wäre das interessant, denn ich verstehe wirklich nicht, wie 64K und 48K in dieses Schema passen.


    In dem STAC mit der 64K-Karte ist noch eine interessante Beispielkonfiguration:



    Man beachte das Loch bei C000-C800, das dem ROM bei 8000-8800 entspricht. Sie schreiben leider nicht dazu, wozu man diese Konfiguration gebrauchen kann. Es gibt Anzeichen, dass der Mikrocode nur 10-Bit Springadressen verwendet, und damit wirklich auf 8000-BFFF beschränkt wäre. Dann wäre diese Erweiterung auch nicht für mehr Overlay-RAM für die Firmware zu gebrauchen.


    Oder man kann tatsächlich den ROM auf C000-C7FF verschieben. Dann wäre die Firmware in den ganz oberen 32K, und man hätte 64K+32K zusammenhängenden Speicher für den /360-Teil. Das bräuchte dann wirklich ein 17tes Bit, und in diesem Fall würde ich erwarten, dass die zugehörige Firmware auf den Systemdisketten signifikant anders ist als bei der P6060 und der P6066 mit der "klassischen" Aufteilung.


    Raffzahn, falls deine P6066 also Systemdisketten hat, die wirklich mehr RAM als 64K nutzen (sollte ENVIRONMENT eigentlich anzeigen), wäre ein Image davon extrem interessant.

  • Olivetti P6060

    So, nochmal nach dem RAM geschaut. In verschiedenen Versionen das STAC findet sich zunächst dieses hier:



    Also "48K MASSIMI", maximaler Nutzspeicher 48K, in Slots 4 und 5, Slot 6 hat 16K für das System, und Slot 8 hat 16K für die Firmware. (Das ist auch die Konfiguration, die hier auf der Olivetti P6060 klebt).


    Der Bereich 8800-9FFF ist nicht genutzt.


    Dann gibt es diese Variante:



    Im Prinzip wie oben, nur kann Slot 6 jetzt die ganzen 64K enthalten, und der Firmware-RAM ist auf 28K gestiegen (die 24K von mir waren ein Abschreibfehler). Immer noch 48K maximaler nutzbarer Speicher.


    Dann gibt es dieses hier, Notizen für die "neue 64K-RAM Karte":



    Man kann da also mit Banking und Klingelchen und Glöckchen spielen, aber das Grundlayout des Speichers bleibt wohl gleich.

  • Olivetti P6060

    Zitat von Raffzahn

    Und welchen Sinn macht dann bitte eine Speichererweiterung über 64 KiByte RAM hinaus - so wie ich sie in wenigstens 2 Maschinen hab:

    Du brauchst immer 24K für den Mikrocode RAM, und wenn du 64K RAM unten noch hast, gibt das maximal 88K RAM.

    Zitat von Raffzahn

    Das würde dann auch eher zu der P6066 die ich hier stehen habe passen - die hat 112 KiB Speicher eingebaut. Wär schon arg doof wenn davon mehr als die Hälfte nicht verwendbar wär.

    Das würde ich gerne sehen, wie die RAM-Karten da eingebaut sind, und ob die wirklich 112K hat. Die STAC-Dokumente erklären ja die RAM-Konfiguration.


    Unsere zwei P6060 waren klassizifizert nach "benutzbarem" RAM, die eine hatte 16K, die andere hatte 48K. Rechnet man 16K System-RAM unten und 24K Mikrocode-RAM dazu, sind das insgesamt 56K bzw. eben die 88K im Vollausbau.

    Zitat von Raffzahn

    Der Microcode muss also einen Weg haben darauf zuzugreifen - so wie er einen Weg haben muss auf eigene Konstanten im eigenen Code zuzugreifen. So wie sich die Tabellen in den bisher zitierteten Papieren lesen hat die Kiste 64 Ki Adressraum und adressiert damit 16 bit Speicherworte. Die Unterscheidung High/Lowbyte braucht auch nicht Haufenweise code. Da gibts eine Vielzahl von Möglichkeiten das übersichtlich zu halten.

    Schau dir mal die ROMA, CRTA und CRTB Mikrocode-Befehle auf der einen Seite an (die lesen 16-bit Worte aus dem wort-addressierten Adressraum) und die MAD/AMD/AMI/BMI sowie AMIP/BMIP/MAIP/MBIP Mikrocode-Befehle auf der anderen Seite an (die schreiben und lesen 8-bit Bytes aus dem unteren byte-addressierten Adressraum, dazu wird der Shifter im Datenpfad benutzt, die oberen 15-bit produzieren die Wortadresse, und das niedrigste Bit steuert dedizierte Hardware für das low/high-byte an).


    Das ist alles so gemacht, dass man die unteren 64K RAM effizient für die CPU-Emulation verwenden kann, und aus den oberen 64K für Mikrocode-interne Zwecke nur gelesen wird.


    Die Infrastruktur für durchgehende 17-Bit Addressierung zu verwenden wäre dann sehr überraschend.


    Aber vielleicht hast du ja recht, und ich irre mich. Du hast ja Zugriff auf funktionierende P6060, also kann man das einfach testen: Schreibe ein kleines Assemblerprogramm, das z.B. 0x00000 (System-RAM) und 0x10000 (Boot-ROM) liest, und vergleiche die Werte. Wenn das wieder Erwarten funktioniert, und die /360-Seite wirklich Zugriff auf die oberen 64K hat, dann kannst die gleich den Boot-ROM dumpen, denn den bräuchte man noch.


  • Olivetti P6060

    Zitat von Raffzahn

    Ich schätz mal wir reden gerade wieder aneinander vorbei. Die 360 Seite arbeitet mit Byteadressen, nicht Wortadressen. Entsprechend braucht es 17 bit um 128 KiB zu adressieren. Und genau das sind die 17 gültigen Bits die Bedingen dass es 3 von 4 Bytes eines Adressworts belegen. Nicht?

    Fast richtig, aber es werden nur die unteren 64KiB addressiert. In den oberen 64KiB ist nur Mikrocode, auf den hat die /360-Seite keinen Zugriff (und braucht auch keine Zugriff) Deshalb sind es nur 16 gültige Bits. (Außerdem wäre es eine Verschwendung, den Mikrocode zu zwingen, für das eine Bit noch haufenweise zusätzlichen Code hinzustellen. Soviel Speicher hat das Ding nicht). Wie gesagt, siehe Patente.

  • Olivetti P6060

    Zitat von Raffzahn

    Was halt bedeutet dass eine adresse im /360 Code wenigstens 17 gültige Bits hat - sprich mindestens 3 Byte zum Abspeichern braucht.

    Nein, sie hat 16 gültige Bits. An die Firmware (Mikrocode) kommt sie nicht ran. Siehe die Patente.


    > (Irgendwie hab ich da auf Github jetzt keine Codestücke gefunden, sonst hätt ich gleich mal Beispiele rausgesucht.)


    Da sind keine Codestücke, du musst Radere2 mit dem P6060-Plugin auf das P6SW-Extrakt anwenden. Dann hast du alles komplett. :)

  • Olivetti P6060

    Zitat von Raffzahn

    ...


    > Äh, irgendwie addieren sich die werte nicht so ganz auf wenn das Byteadressen sein sollen:


    Es sind Wortaddressen ("phyisch" = was der Mikrocode sieht). Die Größenangaben dagegen sind Bytes (um die mit den Prospekten in Einklang zu bringen).


    > Ergo: Der Speicher ist logisch wahrscheinlich als 16 Bit (32 Bit wie vor angenommen wohl nicht) organisiert, angesprochen mit 16 bit (Halb)Wortadressen. Daher braucht das Microprogramm nur 16 bit Speicheradressen in den Befehlen. wie die beiden Bytes im Wort adressiert werden müsste man im Microprogramm sehen.


    So ist es. Wahrscheinlich habe ich mich schlecht ausgedrückt.


    > und Adressen sind doch immer noch Worte in den P6060 Programmen


    Ich habe bis jetzt eigentlich immer nur relative Adressen gesehen, nie irgendwo absolute. Die Module sind verschiebbar, alle Adressen dort relativ. Referenzen auf Systemtabellen über R12 und R13, auf den Stack mit R14. Aber vielleicht stolpere ich mal über eine.

  • Olivetti P6060

    Zitat von lgp30

    Dein Tool ist kaputt. Der Text sollte ERMAP lauten, nicht EYTAW. Bei EBCDIC liegen die Buchstaben lochkartenbedingt in 9er-Gruppen ($C1-C9, $D1-D9 und $E2-E9)


    Das Tool zeigt ASCII an, nicht EBCDIC. (Was wesentlich sinnvoller ist, wenn die meisten Texte in ASCII sind...) Genauer gesagt, es zeigt 7-bit ASCII an, und ignoriert das 8te Bit.



    Code
    echo 'ERMAP' | iconv -f ascii -t ebcdic-us - | hexdump -C
00000000  c5 d9 d4 c1 d7 25                                 |.....%|

  • Olivetti P6060

    Zitat von Raffzahn
    Da bei Adressen von der Hardware nur die niedrigsten 24 Bit ausgewertet wurden war es bei der /360 Usus das erste Byte für Flags zu verwenden.

    Das ist bis jetzt auch nur fundierte Spekulation, aber die P6060 hat für den /360-Adressraum nur 64K, also 16 bit-Adressen, die ein Byte addressieren.


    Der Mikrocode benutzt 16-bit Adressen, die ein Wort adressieren (d.h. der /360-Adressraum erscheint in der unteren Hälfte).


    Siehe das verlinkte Patent für Details, sowie das STAC-4 Dokument für ein paar Adressen:

    Code
    Physical memory map: Slot/Piastra, range, ...
  6  0000-1FFF  RAM Software  (16 K)
  6  2000-7FFF  RAM Utente    (48 K max)
  7  8000-87FF  ROM 4K
  8  8800-BFFF  RAM firmware  (24 K)

  • Olivetti P6060

    Raffzahn Du kannst auch gerne selbst schauen, das Repo mit Extrakten und Radare-Plugins is hier. Syntax läßt sich auch zu Großschreibung und Hexadezimal ändern. Das alles ist WIP und teilweise etwas halbgar.


    Nur meine halbgaren Anmerkungen zu diversen Modulen sind nicht drin, die müssen noch in Radare-Befehle übertragen werden. Und ich muss Radare noch irgendwie dazu überreden, dass er Referenzen sinnvoll auflöst.


    Den Link hast du wahrscheinlich auch schon vor einem Jahr gesehen.

  • Olivetti P6060

    > Interessant dabei dass hier ein 22 als RETEXT umgesetzt wird. Wo hast D das her?


    Geraten :) und verifiziert dadurch, dass es bis jetzt an allen Stellen passt. Wie auch ein paar andere Dinge, die ich bis jetzt nirgendwo gefunden habe.


    > Wär interessant zu sehen was auf Adresse 3BDC ff und 3BE0 ff steht. Beides Wort-Adressen.


    Mit großer Wahrscheinlichkeit 4 Bytes, die die I/O-Aktion beschreiben. Was alles nicht zu dem "i_o fisico in assembler" Dokument passt, wo es 8 Bytes sind, und anders aufgebaut. Wie gesagt, ich verstehe es noch nicht. Konkret:


    Code
                0x00003dbc      .byte 0x00
            0x00003dbd      .byte 0x2b
            0x00003dbe      .byte 0xef
            0x00003dbf      .byte 0xef
            0x00003dc0      .byte 0x01
            0x00003dc1      .byte 0xff
            0x00003dc2      .byte 0xff
            0x00003dc3      .byte 0xff


    37 und 36 sind wahrscheinlich Kanalnummern, wobei es auch da Umsetzungen zu geben scheint, so dass die Kanalnummern der Basic-Befehle nur bedingt helfen.


    > Es muss also wo noch ein 'Systemprogrammierer'-Manual geben die ACT, CALEXS, CALEXT, RETEXT und RLSEM erklärt.


    Das wäre schön, aber ich vermute stark, da gibt's nur interne Dokumentation. CALEXT und RETEXT kommen dauernd vor, CALEXS und CALL habe ich bis jetzt nirgendwo gesehen, und ACT und RLSEM auch nicht. ACT und RLSEM sollten auch ziemlich offensichtlich sein, die Module/Segmente sind auf S. 3-11 im "Manuale generale del systema" erklärt. Im "üblichen Betrieb" werden die einfach über CALEXT angesprungen, ohne locking.


  • Olivetti P6060

    Und da die stackrelevanten Opcodes ja offenbar Interesse finden, hier mal ein Beispiel wie das in existierendem Code aussieht:


    Die "arg" sind Pseudo-Opcodes weil das dumme Radare2 mit der variablen Argumentzahl nicht klarkommt (wie es auch mit einigen anderen Dingen in diesem Befehlssatz nicht klarkommt). Der zugehörige Epilog dieser Routine:


    Code
    ----------- ; done
  └└└─└└└─> 0x00003cba      9324742a       ??93 1066(r7), 36           ; 0x3dc0
     │      0x00003cbe      5010c130       st r1, 304(,r12)
     │      0x00003cc2      9829d004       lm r2, r9, 4(r13)
     │      0x00003cc6      58d0d000       l r13, 0(,r13)
     │      0x00003cca      4100007c       la r0, 124
     │      0x00003cce      2200           fsa r0, r0
     │      0x00003cd0      2800           retext 0

    Der 93 ist übrigens einer von den undokumentierten Opcodes, vermutlich I/O.


    In die lokalen Unterroutinen springen sie dann aber doch mit BAL oder BALR an und nicht mit CALL.

  • Olivetti P6060

    Zitat von Raffzahn

    Überhaupt liegen alle SxA und SxL Befehle ohne ersichtlichen Grund an anderer Stelle (02/03/04/06).

    Meine bisherige Vermutung ist, dass sie die Opcodes eine bisschen zusammengequetscht haben, um die Dekodierung im Mikrocode zu vereinfachen. Wenn man mal eine Tabelle macht, sieht man, dass von nur neun Werte von den 16 des High-Nibbles benutzt werden. Aber um das zu überprüfen müsste ich erstmal den Mikrocode verstehen.


    Ein weiterer Aspekt ist, das alle Unterschiede zum /360 Befehlsatz natürlich gegen evtl. Ürheberklagen geholfen hätten.


    Es gibt auch diverse I/O-Befehle, die im Handbuch nicht dokumentiert sind, und die ich noch nicht verstehe.


    SRL hat in den von mir benutzten Quellen übrigens Opcode 08, und nicht 06.

  • Olivetti P6060

    Zitat von Raffzahn

    Ja, durchaus - wobei mehr noch als an den Disks sind es Handbücher und Zubehör. Wir haben z.B. zwar den original Monitor (gruseliges Blechteil, aber im richtigen Farbton), aber nicht den 'Grafikzusatz' welcher über den I/O Bus angeschlossen war.

    Bis jetzt habe ich nur das Standardhandbuch plus ein Handbuch für den Plotter gesehen (der Plotter selbst ist nicht mehr vorhanden). An optionalen Karten ist nichts drin außer der Karte für den Plotter (vermutlich IPSO).


    Also wohl keine große Ausbeute in dieser Richtung.

  • Olivetti P6060

    Zitat von Pyewacket

    Wenn das ASCII ist wundert es mich nicht dass die 3741 die Diskette nicht erkannt hat.


    Eine genaue Beschreibung wie die einzelnen Sektoren initialisiert sind kann man hier finden. Die angegebenen HEX Werte stimmen bei ASCII nur bedingt..

    http://www.bitsavers.org/pdf/i…ormation_Manual_Sep77.pdf

    Aus dem Link habe ich ja die Beschreibung, wie es aussehen soll :)


    Wenn du selbst schauen willst: Hier ist die VTOC von einem der Images von 1ST1

    Beim Extrahieren bekommt man

    Code
    devuan:~/repos/git2/olivetti/p6060/tools$ ./vtoc.py /tmp/yyy
volume label='K01179'
name='P6FWR2.0'
  01001-08003 create=23.11.1976 expire=None
name='P6FWO'
  08004-10004 create=None expire=None
name='P6SW'
  11013-52007 create=None expire=None
name='P6FSYS'
  52008-73026 create=None expire=None

    Man beachte das Datum für die Firmware Release 2.0, aber das fehlende Datum bei den anderen.


    Und ich weiß, dass es zumindest bei z/OS da auch irgendwelche ASCII-Varianten gibt; aber keine Ahnung, ob es die damals auch schon gab. Und evtl. haben sie den Bootstrap auch noch mit EBCDIC gemacht, und der wurde dann irgendwann mit der ASCII-Version ersetzt, sobald sie die Entwicklung auf die P6060 selbst verschoben haben. Aber das sind natürlich alles nur Spekulationen.


    Man beachte auch diesen Thread (Google Translate hilft); wir sind nicht die Ersten, die das diskutieren :)


    Die ERMAP ist übrigens immer noch EBCDIC:



    Aber ich weiss nicht, ob die auf der P6060 überhaupt benutzt wird.

  • Olivetti P6060

    Zitat von Roland_t29

    super, danke ! Das führt schon mal weiter. Und in der Tat: der 6060 Assembler ist bzgl. Syntax dem /360 Assembler sehr sehr ähnlich. Und der Maschinencode ist (nach kurzer Durchsicht geschätzt) zu 75% binärkompatibel zum /360 Code. Es gibt aber auch deutliche Differenzen, die der anderen Architektur der 6060 geschuldet sind (zB Stack-Kommandos) - interessante Maschine !


    Roland

    Spassig sind vor allem die CALL und CALEXT-Befehle (der letztere ist etwas stiefmütterlich dokumentiert, man muss da schon zwischen den Zeilen lesen), die eine variable Zahl von Argumenten zulassen. Und ASA und FSA nehmen deutlich ENTER und LEAVE from x86 vorweg.

  • Olivetti P6060

    Weil ich hier Diskimages habe, und die entsprechenden Teile extrahieren kann, und es bis jetzt den IBM-Formaten folgt, zumindest laut IBM-Dokumentation.


    Allerdings ist alles ASCII statt EBCDIC, und ich bin mir auch nicht sicher, ob alle Felder so mit Daten belegt sind, dass es eine IBM versteht. Ich habe auch keine echten IBM/360 Images zum Vergleichen.


    Aber das Ganze sieht schon verdammt so aus also ob sie mindestens mal das Bootstrapping mit Hilfe einer IBM gemacht hätten.

  • CPU resetted Video Speicher SRAM nicht mehr - Taktfrequenz unsymmetrisch und bei 1 Mhz

    Hallo, wir hatten ja kurz auf der CC2023 geredet. Etwas Suchen findet das "Apple III Service Reference Manual 1982.pdf" von hier.


    Auf den Seiten 5.4 und 5.6 gibt es Timing-Diagramme für alle wichtigen Timing-Signale. Wenn du noch Zugang zu einem Oszi hast: Die sollte man ungefähr in derselben Reihenfolge prüfen wie auf Seite 5.4, also erstmal C14M, C7M, C3.5M, C1M und ihre Negationen; dann Q0 bis Q3 incl. Negationen, dann AX und /RAS.


    Die Qs sind schon sehr Apple3-spezifisch, die werden durch eine Schieberegister erzeugt, und sind das phasenverschobene C3.5M.


    Da du ja noch Zeichen auf dem Monitor sehen kannst, ist insgesamt wahrscheinlich nicht so viel in der Takterzeugung kaputt.


    Auf Seite 5.8 wird der "1 to 2 MHz Gearshift" erklärt, unter bestimmten Bedingungen hat PHI0 nur 1 MHz statt 2 MHz (ist aber immer noch symmetrisch). /Q0, RAS und /Q3 gehen alle ein in die Erzeugung von PHI0, also erstmal diese messen.


    Damit sollte man den Fehler dann einigermaßen eingrenzen können.


  • Olivetti P6060

    Da 1ST1 auf der CC2023 ja eine Olivetti P6060 aus Dresden zugeflogen ist, mache ich mal ein bisschen Infodump über ein paar Sachen, die man an den üblichen Stellen nicht findet. Vielleicht ist das ja auch noch für jemand anderen interessant.


    Die P6060 hat eine reine TTL-CPU auf zwei Karten (PUCE1 und PUCE2), vermutlich basierend auf der 74181 ALU (aber das muss man überprüfen, wenn die Platinen sauber genug sind, dass man die Aufschriften wieder lesen kann). Diese CPU, die auch in der Olivetti TC800 verwendet wurde, wurde von Francesco Vecchi entworfen. Es gibt mindestens ein Patent dafür, Kandidaten sind US4032895A und US3987420. Die unterscheiden ein wenig, vermutlich ist es das erste, und das zweite war eine früherer Entwurf. Aber auch das muss man gegen den tatsächlichen Aufbau der Platinen verifizieren.


    Wenn das erste Patent zutrifft, hat die CPU drei ROMS für den sogenannten Nanocode (was anderswo der Mikrocode ist; also die Werte für die Steuerleitungen). Der Nancode interpretiert 16-bit Mikrocode aus dem ROM auf der ROM-Karte (Bootvorgang und interne Hardware und Floppy). Ein Teil des Mikrocodes wird dann auch von der Systemdiskette geladen. Der Mikrocode wiederum enthält einen Interpreter für den eigentlichen Assemblercode, nämlich einmal einen sehr an den IBM/360 angelehnten Befehlssatz (wobei nicht alle Befehle implementiert sind, und es ein paar neue Befehle gibt), und vermutlich auch einen weiteren Interpreter für übersetzte BASIC-Programme.


    Die 8-Zoll Floppies sind im IBM/360-Format. Die Systemfloppy enthält drei Datasets für das System, nämlich P6FWR (mit Versionsnummer) für die Resident Firmware (MIkrocode),

    P6FWO für die Overlay-Firmware, und P6FSW für das eigentliche Betriebssystem in IBM/360-Maschinensprache. Das Betriebsystem ist in Module untergliedert, die dynamisch geladen werden.


    Für die Benutzerdaten gibt es ein weiteres Partioned Dataset namens P6FSYS.


    Der Mikrocode sieht einen Hauptspeicher von 64K-Worten mit jeweils 16-bit, die IBM/360 Maschinensprache sieht davon die unter Hälfte als 64K-Adressraum mit 8-bit.


    Wenn man die hintere Abdeckplatte löst, sieht man rechts den Rahmen für die Karten.


    Die Standardbelegung der Karten ist


    Code
      13  GOINO  = governo periferiche integrate
  12  FLOA   = floppy
  11  FLOB   = floppy
  10  UC019  = unita centrale 1009 / CPU / PUCE1 / UC1009
   9  UC020  = unita centrale 1009 / CPU / PUCE2 / UC1009
   8  RAM
   7  ROM
   6  RAM


    Bei der Maschine aus Dresden ist ganz unten vermutlich noch eine IPSO (Paralleler Interface-Standard von Olivetti) Karte.


    So, vielleicht reicht das erstmal für den Anfang.

  • Turbo Pascal nach Apple II UCSD Pascal konvertieren

    Das hat nichts mit Little oder Big Endian zu tun, sondern damit, wie der Compile die Variablenliste in der Deklaration "x, y, z: integer" abarbeitet, nämlich einmal die Liste vorwärts, und einmal die Liste rückwärts. Was daran liegt wie der Parser diese Liste erstellt.


    Wenn du das umformulierst in "(z : integer; y: integer; x: integer; b: boolean)" sollte es in beiden Varianten tun.


    UCSD Pascal kennt übrigens ein Endian Field für den P-Code, aber Apple UCSD implementiert nur eine Variante.

  • Mein neuestes Etwas

    Zitat von 1ST1

    Klasse, auch das ist ein ordentlicher Klotz! Da hätte ich auch ein paar PDFs und Diskimages dazu, ist aber zu groß um es hier anzuhängen.

    Wenn ich mich mal verspätet in den Thread einhängen darf: Ich suche Diskimages für die P6060, falls du da welche hättest, wäre ich sehr dankbar...