Beiträge von Martin Hepperle

Vielleicht noch ein nützlicher Hinweis: Die in den Intel Handbüchern und anderen für die 8088 und 8086 angegeben Takte pro Instruktion scheinen nicht immer zu stimmen bzw. hängen dann doch von der Instruktionsfolge ab. Nur einfach aufaddieren stimmt nicht immer, sondern gibt nur ein grobes Bild.

Vor kurzem hatte ich im vcfed einen Faden gestartet um etwas besser zu verstehen, wie die CPU Takte arbeiten und wie sie sich die Instruktionen bei der ausführung überlappen. Dabei ist in post #7 auch ein Simulationsprogramm xtce_trace aufgetaucht, das die Zyklen genau simuliert und auch solche Effekte wie Prefetch Queue berücksichtigt. Das ist ganz hilfreich, wenn man genauer wissen möchte wie sich die CPU z.B. in Schleifen oder bei Sprüngen verhält.

... und noch eine Ergänzung:

kürzlich sind noch aus dem Nachlass von Emmanuel Roche (CP/M und Newsgroup Freunde werden ihn gekannt haben) Disketten aufgetaucht.

Darunter befinden sich (neben vielen anderen) auch Disketten mit GSS-Plot und GSS-Kernel:

(https://forum.vcfed.org/index.…software-archive.1248862/)

Zusammen mit den schon bekannten Quellcodes ist damit ziemlich alles was es zum GSX-80 System gab verfügbar.

Martin

Der Auszug aus dem HP-System-Journal ist zwar wie bei HP üblich sehr gut, aber leider ist dieser "Scan" ein abschreckendes Beispiel, wie man keine Dokumente archivieren sollte.

Zum Glück gibt es das HP-Journal auch in normal gescannter Form, bei der die OCR Ergebnisse nur unsichtbar überlagert sind.

Die schlimmsten OCR-ten Dokumente habe ich bisher direkt auf den Epson Web Seiten gefunden, dort sind dann auch Zahlenangaben oft vollkommen falsch oder für die Drucker Escape-Sequenzen total verkehrt. Die OCR ist halt auch nur künstliche Intelligenz und versteht nicht was sie da übersetzt. Bei technischen Dokumenten ist das oft katastrophal.

Wenn sich also jemand die Mühe macht, solche Dokumente zu scannen, dann bitte Texte nicht mit OCR ersetzen lassen, sondern eine Option wählen bei der die OCR Ergebnisse bestenfalls als verborgene Ebene in den Scan eingebettet werden.

Ich würde erstmal die zugehörigen Dokumentations-Dateien lesen.

In HPAAA.TXT steht eigentlich Schritt für Schritt, wie man sich eine Diskette für die HPWUTILS (das ist der Vorläufer der LIFUTILS) zusammenbauen kann.

Dazu braucht man das Programm UNHEX, das man z.B. mit Quick- oder Turbo-C übersetzen kann.

Damit kann man die *.HEX Dateien zurückwandeln:

D:\HP>unhex < hpbdoc.hex > disk\HPBDOC.TXT
D:\HP>unhex < hpbdoc.hex > disk\HPK_DOC
D:\HP>unhex < hpBGET.hex > disk\HPK_GETM.E
D:\HP>unhex < hpBHLP.hex > disk\HPK_HELP
D:\HP>unhex < hpBKER.hex > disk\HPKERM02
D:\HP>unhex < hpbwut.hex > disk\HPWUTIL.EXE
D:\HP>unhex < hpbmis.hex > disk\HPK_MISC
D:\HP>unhex < hpblif.hex > disk\HPWLIF.DIR
D:\HP>unhex < hpbini.hex > disk\HPK_INIT

Wenn man das entsprechend der Beschreibung macht, bekommt man auf dem DOS-System einen Satz Dateien, die man mit den HPWUTILS auf eine Diskette kopieren kann.

In dem beigefügten Archiv habe ich ein Verzeichnis mit den so erzeugten Dateien verpackt.

Dort müsstest Du die HPWUTILS aufrufen und alle Dateien auf eine leere Diskette kopieren (ggf. vorher mit LIF formatieren).

Martin

e

Bei den LIFUTILS kann man auch die "Implementation Bytes" explizit angeben (als user defined file type).

Ein "HP 9000 Basic Programm" müsste dann wohl 0xE950 haben - "HP-UX" wäre so etwas wie 0xE946 oder 0xE94B.

Das aber nur, wenn es tatsächlich ein PROG ist. Wenn es tatsächlich eine Textdatei ist, dann kann man die nicht mit LOAD einlesen, sondern muss man die mit GET einlesen. Siehe BASIC Handbücher. Bei älteren BASICs ist das eine Extension, z.B. bei BASIC 2.1.

Du kannst auch auf dem HP 9000 eine Diskette mit einem BASIC Programm beschreiben und dann mit LIFUTILS den Verzeichniseintrag mit dem Implementation Bytes ansehen.

Zitat von Wolfgang Dreyer

Das Testprogramm T8088V1,

läuft auf dem NCR PC4i nicht.

Bleibt wieder nach der Frequenz Eingabe hängen .

Ist der NCR Rechner denn überhaupt IBM-PC kompatibel?

Wenn das Testprogramm mit Turbo-Pacal für den IBM PC übersetzt wurde (also nicht Turbo-Pascal für generisches MS-DOS), werden z.B. INT 10h und INT 1A des IBM-BIOS verwendet.

Wenn ein Rechner kein IBM-PC kompatibles BIOS hat, funktioniert das natürlich nicht.

Ansonsten liegt wohl ein Programmierfehler vor, aber mangels Quellcode wird das wohl noch die nächsten 80 Postings weiter diskutiert werden

Zitat von guidol

Das AVRCPM hat wohl Probleme mit ANSI als Konfig.
Joe G. (Feinmechaniker) hatte v3.00A von Turbo Pascal als VT100 konfiguriert auf seiner B:-Floppy

Mein V3.01A hatte kein VT100 Terminal, so habe ich mir die Settings-Datei der V3.00A genommen und V3.01A damit konfigiert.

Ahem, das AVR System weiß doch nichts von VT oder ANSI oder sonstwas. Das ist Sache der Software und des Terminals am anderen Ende der Leitung. Da kann der arme AVR-CP/M Stick nichts.

Die für VT100 konfigurierte TP Versoin hat Joe G. wohl beigepackt, weil sein Propeller-Terminal ein VT 100 emuliert.

Hmmm ... das ist wieder merkwürdig - ich habe mit TP sehr viel auf dem AVR-CP/M System gearbeitet (ich glaube mit 3.00, aber das sollte keinen Unterschied machen) und ich nehm TP auch immer als allgemeinen Texteditor. Ansonsten habe ich viel mit FORTRAN gemacht, auch das lief problemlos.

Ist Dein TP für das Terminal(-emulator) passend konfiguriert?

Martin

So, jetzt habe ich mal in den geologischen Schichten von 2018 gegraben.

Dass meine Version ein r0.0 zeigt, hat keinen tieferen Grund, ich habe damals lokal nicht die svn Revisionsmechanismen verwendet.

Ich habe einen V3.1 AVR-CP/M-Stick, also im Layout leicht anders als die frühere Version, schlatungstechnisch aber identisch.

Weil ich damals 2018 aber einiges an I2C Peripherie (eine weitere serielle und eine parallel Schnittstelle sowie eine Echtzeituhr) dazugebaut und dazu auch das System entsprechend erweitert habe, ist meine .HEX Datei nicht unbedingt für Dein System sinnvoll nutzbar. Die Peripheriegeräte werden ja mit in den Simulator kompiliert

Meine wesentlichen Erweiterungen wurden damals aber in die offiziellen Quellen eingepflegt und sollen dort verfügbar sein.

Dort lässt sich mit #defines dann die aktuelle Hardware-Konfguration wählen und das System entsprechend kompilieren.

Ähnlich ist es im CP/M BIOS, damals hatte ich dort noch IOBYTE Unterstützung nachgerüstet und dazu die I2C Peripherie eingebaut. Auch das ist in den offiziellen Quellen enthalten.

Wichtig ist dass das Gerät mit 3.3V arbeitet und 5V nur ggf. für die I2C Peripherie verwendet wird.

es scheint auch DRAM Chips zu geben, die nicht stabil mit 3.3V arbeiten - ich hatte aber keine Probleme.

Beim flashen werden 5V verwendet, dabei sollte die SD Karte entnommen werden.

Meine Konfiguration besteht aus

- ATmega 328P

- zwei RAM chips 256x4, 4256 (Makefile: DRAM_8BIT undefiniert, d.h. nicht 0, verwendet dram-8bit.inc und dram-8bit.asm)

- erste RS232C via software UART vom AVR chip und MAX232

- zweite RS232C via I2C (SC16IS740 und MAX232)

- Centronics Schnittstelle via I2C (MCP23017)

- Echtzeituhr via I2C PCF8563

Joe G. hat später nach 2018 noch eine neue Platine entworfen (mit Propeller Chip für ein VGA Terminal) und dabei wohl noch einige Änderungen gemacht. Diese Entwicklung habe ich nicht mehr mit betrieben, da ich mit dem kleinen Grundgerät und Terminalbetrieb zufrieden bin.

Ich hänge nochmal ein paar Notizen von damals an.

Martin

Ich habe seit Jahrzehnten noch eine r0 auf meinem CP/M-Stick (dem Nachfolgemodell Deines Boards) laufen und die funktioniert gut, sodass ich kein Bedürfnis hatte, da etwas zu ändern.

Danke für die Erläuterung - man könnte auch überlegen, die Tastaturfolie zu laminieren, evtl. auch nur einseitig, wenn es langlebiger sein soll.

Und, ich glaube, solche Schnappscheiben gibt es in vielen Varianten und Härten. Das ist ein großes Experimentierfeld und wird je nach Benutzer unterschiedlich beurteilt.

... aber ein 'E' ist doch kein 'E' und hex-codes sind auch keine hex-codes ... die spinnen schon immer, die Informatiker.

(in der Original hex Tabelle rechts ist übrigens ein Fehler, wer ihn findet, bekommt eine Belobigung)

Schönes Design - finde ich besser als die übliche Mikrotaster mit sehr hartem Druckpunkt.

Sind die Knackfroschscheiben denn nur aufgelegt und mit dem Klebeband fixiert oder werden die noch irgendwie anders fixiert? Kann ich auf den Bildern nicht so klar erkennen.

... vielleicht hilft dieses Bildchen auch zu Zuordnung Löcher <-> Speicher ... ist aus der Anleitung des PDS 1020 Computers.

Ich habe mal zusammengestellt, welche Lösungen ich sehe:

A) Mit lokalem Speicher (SD-Karte, lokale Festplatte)

A1) HPDRIVE https://www.hp9845.net/9845/projects/hpdrive/

A1.1) HPDRIVE auf Pentium PC mit Windows 98 und ISA oder PCI Karte.

A1.2) HPDRIVE auf ThinClient mit PCI-Karte

Verwende ich mit zusätzlichem Arduino Bedienpanel mit LCD Display und 4 Tasten zur Auswahl eines Disk Images via HPDRIVE -remote Option.

Der Thin Client startet ohne Tastatur und Bildschirm und lässt sich durch einfaches Ausschalten sauber herunterfahren (Windows XP).

A2) HP85Disk - SD-Karte (Mike Gore, Jay Hamlin) https://github.com/magore/hp85disk

Funktioniert gut an langsamen Rechnern wie Serie-80, für schneller Rechner zu lanmgsam.

A3) HPdisk (Anders Gustafsson) http://www.dalton.ax/hpdisk/

Die aktuelle Version "Mark IIc" scheint auch mit schnelleren Rechnern zu funktionieren, es gibt auch ein Bedienpanel dazu.

B) mit remote Speicher (Server, Cloud), Kommunikation über z.B. WiFi

B1) HPDRIVE wie A1) aber mit gemounteten FIlesystem vom Server, sollte leicht machbar sein.

B2) neue Hardware-Lösung mit Bedienelementen, idealerweise mit 2, einzeln bestückbaren(wählbaren Datenpfad-Optionen:

B2.1) mit lokalem Medium

B2.2) mit WiFi-Verbindung + Server-Software, erfordert Kommunikation zur Auswahl einer Imagedatei sowie zur Datenübertragung.

C) The real thing

Die Auswahlmöglichkeit für eine Imagedatei ist insbesondere bei kleinen Rechnern, wie der Serie-80 nützlich, da die kein hierarchisches Dateisystem haben. bei größeren Rechnern könnte man darauf verzichten.

Ich selbst verwende A1,1) und A1.2) sowie A2) regelmässig (und natürlich C)).

Von A3) habe ich nur eine frühe Version, die lief bei mir nie stabil und war deshalb nicht brauchbar. Die aktuellen Versionen sind aber anscheinend gut brauchbar.

Vielleicht lässt sich ja ein "Pflichtenheft" zusammenstellen, das mehrere Anwendungsszenarien befriedigt.

Eine Frage ist z.B. soll das Gerät mehr als eine HP-IB Adresse unterstützen (also Speichersysteme mit unterschiedlichen HP-IB Adressen, nicht Geräte-Nummern z.B. für Festplatte und Magnetband)? Bei HPDRIVE braucht man dann mehrere HP-IB Karten im PC (ich habe zwei für zwei HPDRIVE Instanzen), was bei 3 oder 4 dann unhandlich wird.

Martin

Ich habe HPDIR verwendet um backup images von HP6000-335H Laufwerken mit HP-1000-A RTE Systemen zu erstellen. Das hat problemlos funktioniert.

Auch HP790x Laufwerke für andere HP-Rechner habe ich mit HPDRIVE verwendet (allerdings nicht mir HP-1000).

Ich denke aber (famous last words), das sollte problemlos auch mit älteren HP-1000 Systemen funktionieren.

Martin

Inzwischen habe ich unter https://github.com/MartinHepperle noch ein Sammellager für muLISP Informationen angelegt.

Dort findet sich auch eine weiter fehlerbereinigte Version des russischen LISP Kurses und Links zu den verfügbaren muLISP Versionen im Internet (die CP/M Versionen muss ich noch ergänzen).

Angehängt noch das Kapitel 9 mit Anhängen aus dem muLISP-87 Handbuch. Mehr habe ich zurZeit nicht.

Darin wird erklärt, wie man Maschinensprache-Routinen anbinden kann, z.B. um direkt Hardware anzusprechen.

Der "Trick" (warum mein Test nicht funktionierte) war, dass die Routinen an ungeraden Adressen platziert werden müssen.

Vielleicht wacht doch noch ein irgendwo schlummerndes Handbuch auf und begibt sich sich auf einen Scanner.

Die Übersetzung der russischen WEB-Site mit vilene muLISP Hinweisen habe ich auch nochmal etwas überarbeitet (im wesentlichen Syntaxfehler durch die Übersetzung beseitigt).

Ja, Danke, die HELP.LSP kenne ich, damit kann man sich die Befehle mit ihren Parametern als Einzeiler Gedächtnisstütze anzeigen lassen, aber es fehlen eben die Erklärungen, insbesondere für die nicht LISP Standard Befehle.

Inzwischen habe ich aus Frankreich eine Kopie von ein paar muLISP-87 Handbuchseiten (Scan von der Kopie einer Kopie...) bekommen, das hat schon mal weiter geholfen, aber ein komplettes Handbuch wäre natürlich noch viel besser.

Immerhin kann ich nun schon mal grundsätzlich ein in Assembler geschriebenes Unterprogramm aufrufen und ohne Absturz NIL zurückgeben. Das ist zwar Nichts aber doch schon was

SDL Stecker und Buchsen hatte ich auch schon mal bei Mouser gekauft, ich vermute, die haben sie auch noch.

Man muss nur nach den Farben sehen (schwarz/grau bzw. transparent/weiss) damit die Kodierungsnasen passen.

Für muLISP-86, -87, -90 sind nirgendwo Handbücher verfügbar.

Ich vermute, dass die Originale in Paperback-Form sind und die deshalb niemand einscannen wollte.

Insbesondere zu muLISP-90 interessiert mich, wie man die Funktionen ALLOCATE und BINARY-LOAD verwenden kann, um Assembler-Routinen einzubinden,

Ich kann zwar Speicher allokieren und dann dort hinein mit BINARY-LOAD Maschinencode einlesen, aber die Verknüpfung der Speicheradresse mit einer aufrufbaren LISP Funktion (z.B. mittels PUTD) klappt nicht. Dazu müsste es in den Referenz-Handbüchern Erläuterungen geben. Es müsste dort auch Hinweise auf von Assembler-Programmen aufrufbare internen LISP Funktionen geben.

Hat hier jemand Handbücher für diese MS-DOS Versionen von muLISP in denen er mal nachsehen könnte?

PS: Als Quelle zu LISP allgemein mit speziellen Hinweisen zu muLISP-85 und -86 habe ich aus einer russischen Web-Site eine (maschinelle) Übersetzung ins Englische komponiert - dort wird aber auf diese muLISP Spezialitäten verständlicherweise nicht eingegangen.

Martin

46020 und 46021 wären die richtigen Tastaturen für HP-HIL an einer HP 9000/&300.

46010 ist für Terminals und den HP 150, mit einem anderen Stecker und seriellem Protokoll.

C1405 ist für Terminals gedacht.

Eine größere HP Tastaturliste hatte ich mal unter

Log In

angelegt

Mein Vectra (für den ich die Tastatur von Dir bekommen habe) hat schon einen WD Festplattencontroller mit einer Seagate - beides von HP eingebaut.

Ich hatte damals in 1987 einen Vectra mit der Nighthawk 20 MB Platte gekauft, aber die Platte zeigte schon innerhalb des ersten Jahres defekte Sektoren und ich habe sie dann gegen einen Priam 63 MB Platte + Adaptec Controller ausgetauscht. Die war zuverlässiger.

Wenn man den Vectra mit dem zugehörigen monochromen Multimode Grafik-Adapter betreibt, kann man übrigens einige Software (z.B. Borland BGI) für den AT&T 6300 bzw. Olivetti M24 anpassen - alle verwenden die gleiche 640x400 Auflösung und interleaved Organisation des Bildschirmspeichers mit dem 6845 Grafikcontroller.

Die Tastatur des Vectra fand ist sehr angenehm im Vergleich zu den Original IBM KlickeDiKlack Tastaturen (XT und AT) - gut definierter Druckpunkt und weiche Dämpfung das Anschlags.

... ah, Danke ... könnte man eventuell sogar mit so einer Magnetflüssigkeits-Linse sichtbar machen...

Ich hatte mich immer gefragt, wie die Katzenaugen hergestellt werden.

Mit den obigen Bildern habe ich mal gerechnet...

Eine Umdrehung dauert bei 300 1/min 60/300 s = 0.2 s = 200 ms

Eine Umdrehung dauert bei 360 1/min 60/360 s = 0.166/ s = 166 ms

Aus dem Oszillograph lese ich für jedes Katzenauge ca. 4 Einheiten also bei 20 ms Zeitbasis 2 * 4 * 20 = 160 ms Gesamtzeit für beide Augen.

Daraus schliesse ich dass das Laufwerk mit 360 1/min dreht und die exzentrische Spur genau einmal pro Umdrehung "wobbelt".

Dann wird bei der Herstellung der Schreibkopf einmal pro Umdrehung hin- und geschoben.

Man könnte also eine digitale Kalibrier-Diskette herstellen (keine Analoge), wenn man die Diskette leicht (1/10 mm?) exzentrisch montiert und dann eine Spur schreibt?

Ist das so richtig?

Martin

"Always two there are, no more, no less. A master and an apprentice." (Yoda)

Mit "Privatmuseum" meine ich eher solche Sammlungen, die unzugänglich in irgendwelchen Kellern, Garagen oder Schuppen vor sich hinlagern bis dann das nächste Hochwasser kommt oder die Erben sich damit auseinandersetzen müssen. Nicht solche Sammlungen, die öffentlich zugänglich sind und bei denen sich der Besitzer auch Gedanken um die Zukunft gemacht hat.

Die nicht versteigerten, großen Restbestände des LCM sind ja nun auch an ein anderes Museum weiter gegangen, was schön ist.

Die Erlöse der ersten P. Allen Auktion kann man auf Christies Web Seiten nachsehen.

Unglaubliche Preisspannen, ein paar Sachen gingen noch zu halbwegs vernünftigen Preisen weg, aber manches ist schon irre.

Daran können sich jetzt zukünftige EBay Anbieter orientieren

Schade nur, dass das meiste jetzt nicht mehr öffentlich zugänglich sein wird, sondern in irgendwelchen "Privatmuseen" landet.

Leider gibt es wohl keine disassemblierten und kommentierten ROM Listings (gab es vermutlich früher mal von Epson).

Im Zusammenhang mit der Forth-ROM Analyse habe ich die zwölf V1.0 und 1.1 ROMs (Versionen für Japan/US, Europa) diassembliert und bei Bedarf dann lokal kommentiert/formatiert, aber nur in sehr, sehr kleinen Bereichen weil der Code doch sehr komplex und kompakt ist.

Interessant wäre es, BASIC Erweiterungen in das System einzuhängen, wie es manche kommerzielle Anwendungen aus der Zeit machen (auch das Disk BASIC). Das System ist ja schon für solche Erweiterungen konstruiert.

Dazu muss man aber die Parse-Routinen kennen und verstehen; was ist beim Aufruf eines Schlüsselworts bzw. einer Funktion auf dem Stack bzw. im FP Akkumulator, wie holt man die nächsten Parameter, etc.

Martin

Ja , die betreffende Routine liegt an unterschiedlichen Adressen, je nach Version:

1.0: $E1FA

1.1: $E1DB

Der aufgerufene Unterprogramme sehen so aus:

                ; copy 6 bytes from RTC data area to destination buffer
E1FA            LE1FA:           ; X has destination start address for date/time
E1FA : 0F           sei         ; stop intr.
E1FB            LE1FB:
E1FB : 96 4A        ldaa X004A  ; read control register A
E1FD : 2B FC        bmi  LE1FB  ; wait while busy
E1FF : 5F           clrb        ; initialize B=0
E200            LE200:          ; loop while B<6
E200 : 3C           pshx        ; save destination array start address
E201 : 8D 0F        bsr  LE212  ; determine address of item B:
E203 : A6 00        ldaa $00,x  ; X has  48 47 49 44 42 40  addresses
E205 : 38           pulx        ; result  M  D  Y  h  m  s  is now in A
E206 : 3C           pshx        ; restore X, save again, A=RTC byte
E207 : 3A           abx         ; final destination address in array
E208 : A7 00        staa $00,x  ; store A in array
E20A : 38           pulx        ; restore dest. array start address
E20B : 5C           incb        ; B++
E20C : C1 06        cmpb #$06   ; until B==6
E20E : 26 F0        bne  LE200  ; B<6: next B
E210 : 0E           cli         ; enable intr.
E211 : 39           rts             
                ;
E212          LE212:            ; get byte at offset B in clock data area
E212 : CE E2 1B    ldx #$E21B   ; src
E215 : 3A          abx          ; idx = src + B
E216 : EE 00       ldx $00,x    ; get[idx] to X
E218 : 18          xgdx         : X -> D
E219 : 4F          clra         ; clear high byte
E21A : 18          xgdx         ; D -> X  (abs. addr. of byte to read)
E21B : 39          rts
                ;
E21C : 48        db $48         ; address of month
E21D : 47        db $47         ; address of date (?)
E21E : 49        db $49         ; address of year
E21F : 44        db $44         ; address of hours
E220 : 42        db $42         ; address of minutes
E221 : 40        db $40         ; address of seconds