Was habt ihr eigentlich an "Vorab" nicht verstanden?
Es ist nicht das erste Mal, dass hier Nörgler bei allem und jedem, was ich hier unter Aufwendung eigener Zeit schnell bereitstelle, meinen, mich zurechtweisen zu müssen.
Da augenscheinlich Unterstützung nicht gewünscht ist, bitte @Forenverwaltung: meinen Account unverzüglich löschen, damit ich nicht weiter hier in die Versuchung komme, hilfsbereit zu sein.
Das war der allererste Link, den man mit "D4265 DRAM" findet.
Sehr schön.
Allerdings würde ich mit mindestens 400dpi S/W einscannen, mit 600dpi S/W wird die Datei auch nicht viel größer - ist aber noch besser lesbar und mit OCR zu bearbeiten.
Wer über den Zustand geschenkter Gäule meckert, wird zukünftig keine mehr bekommen.
Da es noch etwas dauert, bis ich wieder einen größeren Batch für Bitsavers zusammen habe, vorab, das Siemens-Datenbuch zur FL- unf FZ-Serie vorab:
Die 12.63:
Da steht jetzt im Eprom nichts besonderes drin; das ist eine Sinus-Interpolationstabelle, aber er liefert zumindest etwas anderes als Nullen.
Bei dem 2716 muss man das Häkchen für ID-Check abschalten, dann liest der auch 2716. War mir auch zuerst passiert. Der Chip war allerdings anderweitig defekt; er war auch nach Stunden im Löschsarg nicht leer.
Bei den 27128 und 256ern sollte man genau im Datenblatt des Chips nachsehen, welche Programmierspannung die brauchen; die Auswahl hat, hmm, gewisse Ungenauigkeiten...
Möglicherweise ist das beim 27010 auch das Problem.
Nachtrag: Ich habe in meinem Archiv doch noch ein schönes altes Datenbuch von Siemens gefunden: "Digitale Schaltungen MOS" von 1974/75, welches die FL- und FZ-Serien enthält. Muss ich bei Gelegenheit mal für Al Kossow scannen; Bitsavers hat das noch nicht.
Die FZ-Serie findet sich im 1976er Digitale Schaltungen-Datenbuch von Siemens, was leider wohl nicht im Netz ist; ein Auszug steht unter https://www.mikrocontroller.net/attachment/410939/lsl.pdf
Die FL-Serie sind die Pro-Electron-Benennung für die 74er-Bausteine, wobei die ersten beiden Buchstaben FL die TTL-Serie bezeichnen, der 3.Buchstabe sagt etwas über die Art, z.B. H sind Gatter, J, Flipflops, K Monoflops, etc.
Auch wenn obiges Siemens-Datenbuch nicht im Netz ist, kann man allerdings trotzdem rausfinden, welche Bezeichnung welchem 74er entspricht; eine entsprechende Tabelle steht interessanterweise im Analoge Schaltungen-Datenbuch http://www.synfo.nl/datasheets…G-INTEGRATED-CIRCUITS.pdf
Many thanks Wawavoun !
I am going to put them into IDA and comment them. Scheduled for later.
Beim 8080 (CP/M) und zahllosen früheren Minicomputersystemen hatte man dasselbe Problem, dass absolute Adressen im Code durchscheinen. Der gängige Weg dafür ist es, ein Object-File-Format zu erzeugen, welches relokatible Adressen aller Art markiert - OMF, COFF, Intel-OBJ/Hex oder Motorola S1/S2/S9-Format und diverse andere. Beim 650x gibt es nichts Standardisiertes. Das ist eigentlich der Kardinalfehler - ein netter Prozessor, aber keine verbreitetes Infrastruktur seitens des Herstellers.
Der 6502 ist nicht auf Relokatibilität hin designed; selbst sein Vater, der 6800 war da besser - es gibt im 6502 zwar relative Sprünge, aber z.B. kein BRA/BSR, welche recht einfach realisierbar gewesen wären. Der Stack ist an 0x100-0x1ff festgenagelt, die Zero-Page ist eben bei 0x00nn. Man hat auf Register verzichtet, welche direkt 16-bit-Adressen speichern konnten. Der 8080 hatte solche, der 6800 zumindest mit SP und X zwei davon. Die 128 indirekten Paare in der Zero-Page sind nur ein müder Ersatz, wenn sie nur 8-Bit-portionsweise befüllt werden können. Beim Disassemblieren des HP35 (der einen embedded 6502-Core enthält) war mir das schmerzlich aufgefallen - der Code ließe sich mit 16-Bit-Instruktionen massiv kürzen. Beim 6809 hat man dazugelernt.
Danke guidol, für die Arbeit an dem Zeitungsartikel.
Interessanter wären allerdings die beiden UTB-Taschenbücher 588 und 589 in der 1. Auflage, die genau diese Version (FOSBIC 1) dokumentieren. Bei ZVAB und via Fernleihe konnte ich leider nur die 2. Auflage auftreiben, die den, wohl nicht publizierten, verbesserten FOSBIC 2 beschreiben, bei dem sich doch einiges geändert hat. Die Beispiele test_a*.bas und test_b*.bas sind Code-Beispiele daraus, die mit dem FOSBIC1 laufen; file*.bas sind Beispiele, welche ich selbst nach Code-Analyse geschrieben habe - wäre interessant, was die Original-Autoren sich in UTB 589, 1.Auflage dabei gedacht haben.
Für Leute, die mal etwas Retrofeeling von früheren Batch-orientierten Systemen erleben wollen:
FOSBIC (FORTRAN Simulated BASIC Interpretive Compiler) ist ein batch-orientiertes BASIC-System, welches in FORTRAN IV geschrieben wurde. Es entstand wohl ursprünglich als "UWBIC" an der University of Washington für die IBM7094, und wurde etwa um 1976-77 vom Fachbereich BWL der Justus-Liebig-Universität Gießen auf deren damalige CDC3300 als Lehrsystem für die Studenten portiert, dabei ergänzt um ein rudimentäres Handling von sequentiellen und ISAM-Files, sowie um MAT (Vektor/Matrizen)-Operationen, die man in heutigen BASICs nicht mehr findet.
Es läßt sich leicht mit GNU gfortran unter Linux bzw. Windows (mingw/cygwin) übersetzen, so dass man damit spielen kann; für produktiven Einsatz eignet es sich nicht wirklich mehr.
Die Original-Sourcen, die Portierung, Doku und zahlreiche Testbeispiele finden sich unter https://github.com/hveit01/FOSBIC
Mit anderen Worten, die Argumente sind ausgegangen. Ich versuche auszuloten, ob es mir etwas bringen könnte, Mitglied zu werden. Danke für die Bestätigung meiner Einschätzung, dass es nicht lohnt. Tut mir leid, etwa an Jos und andere, dass es keinen Feedback mehr geben wird.
Maker sind die Leute, die Artefakte *schaffen*, wie sie etwa in Heises "Make" (bzw. im Original) beschrieben sind, wenn es nicht gerade nur das 999te Zusammenklicken eines Adafruit-Boards an einen Arduino ist. Die Leser, die sowas nachbauen, sind keine Maker, ebensowenig wie jemand, der bei Kali-Linux das nmap starten kann, ein Hacker ist.
Man kann kann solche Leute auch Künstler oder, ebenso abgegriffen, "Kreative" nennen - jedenfalls sind das Leute, die nicht nur Erfahrungen aus zweiter Hand nutzen (können). Insofern gehört zum Retro-Hobby nicht nur das alte Blech, sondern auch Know-How, es zu verstehen, zu reparieren, zu erweitern und zu beherrschen, und im Zweifelsfall dafür auch seine Werkzeuge herzustellen. Sage ich als Ingenieur und Entwickler.
Was ist denn ein Maker für dich? Für mich ist es jemand mit einer extrem hohen Sach- und handwerklichen Kompetenz. Jemand, der nicht nur einfach irgendwas benutzt (ein User). Letzteres kann jeder irgendwie.
Man kann natürlich nur User sein. Dann wird man aber abhängig vom Goodwill von anderen, und hat u.U. deutlich weniger Spass, als wenn man das Hobby ordentlich betreibt, selbst dazulernt, und etwas selber beherrscht ("Maker sein").
BRN + code ist beim 6809 eine ziemlich interessante Möglichkeit, geeignete Peripheriegeräte über das 2. Byte zu kontrollieren. Das Gerät muss dazu eigentlich nur erkennen, wo ein BRN+code-Befehl anfängt. Das geht beim 6809E über den LIC-Output recht einfach.
Leute, ich habe schon 1000 Mal irgendwelche ROMs joinen oder splitten müssen, ob Big- oder Little Endian und/oder mit oder ohne Offset. Der Aufwand, dafür ein simples C-Programm zu schreiben (Dateien mit "rb" öffnen, in der richtigen Reihenfolge Bytes lesen und schreiben, Close), ist eigentlich eine lächerliche Fingerübung, die schneller geht als allein nur im Netz nach irgendeinem passenden Convert-Tool zu suchen. Man muss ja nicht gruselige Perl- Pack/Unpack-Funktionen bemühen, aber wenn ihr euch selbst mit dem Zusammenlöten der tiefsten Bits und Bytes von alten Computern beschäftigt, sollte das doch eigentlich keinen langen Thread mehr wert sein, oder?
Ich habe noch eine etwas besser kommentierte Version des Monitor-Programms. Fall jemand Interesse daran hat, bitte 'private Message'
Wenn man etwas genauer sucht, findet man auch die Scans der Originaldoku von Elektor bzw. Dr. Huschitt. Für viel besser halte ich das aber auch nicht. Die Konstruktion mit der Jump/Call/Return-Stackemulation ist übrigens auch nicht neu; ich habe Vergleichbares auch schon im MK-14 und als Tipp in einer JOCE&N-Ausgabe gefunden - ursprünglich war das wohl im KitBug des Introkits. SC/MP-I und II waren eigentlich schon zu der Zeit, als Elektor das als Computer pushte, im Vergleich zu Konkurrenz (8080, 6800) hoffnungslos veraltet. Beim SC/MP-III hat National immerhin dazugelernt und echte Call/Jump-Instruktionen hinzugefügt.
Die Citation hättest du fairerweise drinlassen können, wenn du das schon von https://www.dos4ever.com/SCMP/SCMP.html klaust 
Es gibt unter https://britzl.github.io/roguearchive/ ein rogue17cpm.zip.
Alles anzeigenVielleicht versuche ich mich mal an einem Einplatinenrechner "68008 klassisch", bei dem nur zeitgenössische Bauteile erlaubt sind. GALs gehören da ja schon dazu, so dass die Glue Logic nicht viel Platz brauchen dürfte. Dazu RAM, ROM, serielle Schnittstellen für Terminal und Modem -- viel mehr braucht es doch gar nicht?
Mein priorisierter Kandidat ist eine geringfügig modernisierte Kat-ce. 68000 ...
Der Vorteil der Kat-ce: es gibt einen Pascal-Compiler im ROM, alternativ gibt es RTOS/UH mit Pearl. Ein kleines Problem dabei wäre die Beschaffung der damaligen ROMs. Ich hab nur den ROM-Satz ohne Compiler.
Gruß, Ralf
Hat jemand die Pascal-ROMs?
RTOS und die c't 1.5 ROMs habe ich.
Sorry, bislang kein weißer Rauch.
Ja und nein. Weiter oben hatte ich ja schon das Programm gepostet. Fritz hatte den Link der Homepage in Bezug auf archive.org gepostet gehabt, daher der Bezug. Es gibt auch einen klitzekleinen Unterschied, die Programmversion die ich gepostet habe zeigt den Schriftzug "Elektor", die Du gepostet hattest, "Elektuur".
Obiges enthält den VB6-Sourcecode.
Du suchst diese Datei.
Wenn du keine Angst vor Bestellungen in den USA hast, dann findest du den hier: http://www.unicornelectronics.com/IC/8000.html . Der "8060" für 9.99$ ist in der Tat ein SC/MP-II. Der "8073" ist übrigens der noch interessantere SC/MP-III mit dem 2,5K-Tiny-BASIC. Ich hatte dort vor Urzeiten mal diese geordert.
Nachtrag: in der Bucht findet man auch welche, allerdings zu Apothekenpreisen, und aus China. Was man dann da bekommt, würde ich eher für eine Wundertüte halten.
Kommt das aus den PDOS/68K diskimages ? Nur der ROM-dump durfte ja nicht gereicht haben dieses Listing zu erstellen.
Jetzt noch das gleich fur die BIOS and dann ist die Software Seite der Stride abgedeckt. Fehlt die hardware Seite...
( Schaltbild MMU und MFM Kontroller )
Der MFM kontroller von Stride und Sage sollen ja ziemlich unterschiedlich sein.
Das ROM ist zu 80% identisch mit dem ROM der Sage-IV. Im User's Guide sind die I/O-Ports gelistet. Das reicht aus, um die Funktion z.B. des Winchester-Bootloaders herauszufinden. Die MMU wird im PROM nur auf Bypass gesetzt. Da müßte man vielleicht einen Blick auf das Unix werfen.
Nein, allerdings bin ich ziemlich gut im Reverse-Engineeren. Vielleicht baue ich das PROM in einen Emulator ein.
Vielleicht hilft dieses jemandem weiter.
Was ist das ? Ich erkenne ein Assembler-Listing.
Das kommentierte Stride 3.10 PROM
