Beiträge von helwie44 †

    Nun PAW - mit dem SID habe ich einfach über den BIOS-Vektor (bei mir mit 0xF200 h, 62 k cp/m)

    In 6. THE BIOS ENTRY POINTS (cp/m Alteration Guide !!)


    einige Subroutinen mit Reg C = 0 auf

    Diskette A: call 0xF21B ,

    Track 0 call 0xF21E h, den ersten

    Sektor (cp/m) mit 0 call 0xF221 h, und

    DMA mit 0x6500 h call 0xF224 h, mit BC=0x6500 h eingestellt.

    Dann einfach ein „read“ 0xF227 ,

    unten die erwarteten (bekannter INHALT) DATEN zu sehen.



    Wenn ich also die cp/m Sektoren von 0 bis 31 anwähle kommen alle Sektoren einer SPUR!

    Im DiskPARABlock sind Anzahl auf 32 (cp/m sec/trk), offenbar von 0 bis 31!

    Bei 32 in Reg C = 20h liefert ein Fehler - später nach einem „READ“ !!!

    Offenbar erkennt das DU.COM die Mimik mit dem „S“ und dem „PS“ immer richtig.

    Hallo PAW -

    ich habe ein lupenreines 8080 cp/m 2.2, das müsstest du bereits bei dem Ablaufprotokoll von der Displayanzeige über den PRINTER-AUSGANG ( über V24 Kabel auf das TeraTerm (WIN-Prog) als File (.txt) geleitet - wie dort zu sehen ist.


    Hast du mal deine identische Testdiskette mit dem DU.COM ( läuft auf jedem cp/m > vers. 2.0 und Z80, 8080, 8085 Chip) zum Vergleich gedumpt?


    Ich meine in DDUMP050 ist bei der „S“ ector keine „0“ erlaubt! Fehler-Eingabe_Bell!

    Das ist auch völlig richtig von der Bedeutung, sonst kommen doch ein USER mit deinem Prog. ins schleudern.


    Wie ich zuvor angedeutet - sollte man die Ursache in der BIOS-Anpassung ( möglich ) über den HostBuf und den Block - DeBlock zu finden können. Schau doch mal was du in deinem Prg. gemacht hast.


    Bei dieser cp/m von mir ist der HostBuf 2 kB, also je ein EXT-Block. Siehe meine Protokolle zuvor!


    Wie arbeitet deine READ/ WRITE cp/m Anpassung?

    So sollte der DUMP bei meiner TA-alphaTronic P2U in der richtiger Sektorfolge zeigen:

    Der BEITRAG zuvor vom DU.COM standard cp/m dump ansehen.



    HIER:

    Nun das PAW Programm als Display-Protokoll als .txt File hier zu sehen und zum VERGLEICH:

    (auch einige Bemerkungen **** helwie in runden Klammern)

    Offenbar ist der 1.er 128 Teil (record sec=1 ) nicht sondern mit dem 2.ten Bereich also als sec=1 angezeigt - oder?

    Wie du genau vorgegangen bist - hast du sicher das DU.COM im weiten WEB - um mal bei die ruhig mit einem Z80 Chip zu testen.

    Hallo PAW - dein DDUMP050.COM erster TEST:


    Bei der TA- alphaTronic unter dem cp/m startet alles normal (als 8080 CODE), ok.


    Offenbar wird immer in jedem TRACK der 1.ter Teil vom HostBUF also 128 nicht als 1 Sector (cp/m) von deimem Programm gedumpt - sondern der zweiter Teil - 128 Byte vom HostBUF als 1 Sector angezeigt (gedumpt)!

    DAS TA alphaTronic P2U physikalisches Diskettenformat ist 256 Byte je 16 Sectoren, Track von 0 bis 39 und zweiseitig.


    Muss ich evtl. etwas anderes einstellen - oder?


    Zum VERGLEICH habe ich den Anfang physikalisch

    Track 0 und Sektor 1 mit dem standard DU.COM (cp/m Disk Utility) gedumpt:

    Mit dem DU Prog. arbeite ich intiutiv - sonst noch mit dem ? werden help - Infos angezeigt!

    Zusatz ist in (runden Klammern) als Erklärungen von mir zugefügt.

    Ich mache also eine weitere Sitzung mit dem DDUMP050.COM - soweit identisch den DATEN-DUMP-Bereich wie zuvor durch zu führen. mombi....

    Leider habe ich kein echtes CP/M-System

    Was bedeutet das bei dir?



    Ich habe im Datenpool (Sysquest - Platten) einen ATZTEC - 8080 C-Compiler und mit allen Quellen um jedes Element der C-Biblothek ansehen/anpassen und mehr. Die Elemente sind Teile in Assembler und selbst in C. DAS ist optimal zu einer Hardwareanpassung.

    (Nur der C-Compiler ist für eine TPA 100h als .COM File vorhanden)


    Als vorgemerkte BAUSTELLE:

    Für z.B. eine alphaTronic P2 werde ich eine C-BIB zur Ausführung von C-Programmen auf eine TPA 4200h zu benutzen. Leider ginge es nur ein C-Programm unter dem ATZTEC-compiler für ein TPA100 cp/m System.


    Der ATZTEC-C 8080 erzeugt ein .ASM oder .MAC . Früher habe ich sehr viele Anwendungen mit dem C-Compiler erarbeitet.

    Experiment mit READ-TRACK Floppydisk


    Da hier offenbar fehlerhafte SECTOREN CRC-Fehler gesucht und gedumpt PAW werden sollen -

    habe ich vor einiger Zeit in einem


    thread "Triumph Adler" einiges über den Bereich:


    READ TRACK (Assembler-Eben) bearbeitet;

    Eine Spur (alle Rohdaten mit sync, gap, cmd, data usw. mit dem CRC je SECTOR..) in den Speicher zu lesen.

    Auch eigene Assemblerroutinen zur Nachrechung aus richtigen Rohdaten entsprechend ein 16 Bit CRC


    Generatorpolynom:
    Aus den Datenblätter vom 1791Cpip steht das folgende Polynom.

    CRC-CCITT (CRC-16) für Disketten G(x):: = X16 + X12 + X5 +1;


    selbst zu berechnen / nach zu rechnen.

    Nicht unter 8080/8085 Chip cp/m Maschinen


    Dein „Wunsch_Programm“ habe ich mal auf einer TA alphaTronic P2U, klar für 100h TPA versucht zu starten.

    In deinem PASCAL-Programm habe ich schnell Z80 Instruktionen mit dem SID.COM gesehen.

    Hier ist zudem noch ein 8085 verbaut. Es sind ja 12 CODE in der CODEMATRIX beim 8080

    als NOP.


    Der 8085 benutzt die 12 anders mit undokumentierte Intel-Instruktionen!!


    DAHER SCHADE nur dein Programm unter einer Z80 - klar ablauffähig!


    Erst wenn ich ziemlich an den Anfang der Beiträge blätterte „zeigt …. PASCAL Z80 … die Bestätigung.


    Zusatz FRAGE:

    Haste du die Speicherlage des cp/m Bios-Vektor dynamisch beim Startvorgang geholt und verwendet? Dann sollte das Programm ja unter jedem cp/m aber mit einem Z80 verbaut ablaufen.

    alphaTronic P1/P2 öffentlich vorgestellt


    In den vorherigen Beiträgen hatte ich und etliche USER einiges zur TA (Triumph Adler) und die

    Geschicht zur Entwicklung einer alphaTronic P1/P2 dargestellt. Hier kompakt darf nicht etwas über die öffentliche Vorstellung der Maschine fehlen:

    TA Prospekt-Auszug


    Alles begann mit der KISS

    Hier habe ich passend zur Vorstellung (am 17.Sep. 1979 in München) um und über die TA alphaTronic P1/P2,

    einen HNF BLOG von dem Wissenschaftler und - Blogger, Ralf Bülow geschrieben.

    Live: alphaTronic P1 Vorführungen / SYSTEMS 1979 München


    Mit der von sks ( Steinmetz - Krischke Systemtechnik, Karlsruhe) wurde zuvor in orangerotem Gehäuse das KISS Microcomputer System entwickelt und stand zum Einsatz bereit.

    Das bekannte sks- MOS wurde bei der TA Alphatronic P1/P2 (und weitere Varianten) identisch übernommen und in EPROMs verbaut.


    Den HNF BLOG ist über den Link sehr lesenswert. Viele Informationen ist aus dem Beitrag der historischen Microrechner zu finden.


    (Quelle: HNF - Heinz Nixdorf MuseumForum)

    einen Soundchip

    Keine Ahnung - aber offenbar hatten vermehrt andere Mikros eine "sound",

    da wollten die nicht nachstehen?


    "

    The CBM-II line was Commodore's followup to their original PET/CBM machines. Enhancements included extra memory, better screen editor, three-voice sound (SID), RS-232 port, cartridge port, expansion port, and a new keyboard with function keys... all in a sexy new cas.."

    sks MAUD-System für/mit KV Segeberg

    Hier ist ein Beispiel mit Öffentliche Einrichtungen (KV Kassenärztliche Vereinigung) Projekte für Hard- und Software Systeme in die Praxis zu entwickeln.

    Ich erinnere mich, das etwa 1976 Kontakte zur KV Segeberg ( Rechenzentrum) gab. Es gab diverse Besprechungen in Karlsruhe (sks) und auch in Segeberg (KV). Die Hardwarekoniguration war recht kurzfristig realisiert.


    Die Hardware MAUD:



    Es war ein Mehrplatzsystem - ein 9 Zoll Display und ein 15 Zoll Bildschirm. Die Tastaturen waren sks-Standard ( aber später nach geänderte Tasten-Kalotten). Dabei befand sich ein MC4 Rechnerkern mit 6 K-Wort Tinemsharing Microbefehlssatz. Der RAM wurde von 32 kB bis 48 kB verbaut. Als Speicher befanden sich zwei 8 Zoll Disketten-Laufwerke und zwei DC300 Kassetten-Laufwerke ( 800 / oder 1600 dpi).

    Weiter Anschlüsse für zwei Drucker (nach Wahl) und eine Anschaltung über die BSC 2780 Procedure (DFÜ).


    Die Software MAUD

    Die MAUD-Projektgruppe wurde aus (im Kern) eingearbeitete Programmentwickler bei sks Karlsruhe zusammen gestellt. Das Softwareprojekt wurde aber gleich der Ort für die KV festgelegt.

    Ich hatte zusätzlich einen zeitweisen Projektorleiter entsand. Daher brauchte ich eigentlich nur wenige Dienstbesuche zur KV durchführen. Vom KV Rechenzentrum wurde ein Crossassembler ( Fortran ) für den sks ASS400 Makroassembler im Vorlauf realisiert und getestet. Dazu bereits vom Rechenzentrum die BSC 2780 - sks KTC 100 ( KTC400, MAUD) zum Datenverkehr getestet.

    Die sks Entwickler konnte daher an dem KV Großrechner ( ich meine UNIVAC) sehr schnell und effektiv Programmodule entwickeln / bearbeiten. Das Projekt lief - ich meine - ca. 7 - 9 Monate. Die gesamten Unterlagen wurden Eigentum der KV ( Kunde).


    Ein damaliger historischer Anschlag in RZ für ein Feierabendumtrunk.

    Die vier Computer - Killer waren die sks Entwickler vor Ort:

    Der gezeichnete Aushang stammt von Simo K.

    Von links Andreas M., Günther J., Lothar G., Simo K. : Etwa ca Mitte 80 er Jahren habe ich zu verschiedenen Zeiten schon die Personen getroffen.

    Wenn die Randbedingungen für die AUFGABE richtig formuliert ist:

    Der Zugriff darf aber nicht über BDOS erfolgen, sondern direkt über BIOS-Aufrufe.

    muss man sich sicher dann ein "WUNSCH_PROGRAMM" sowas selber bauen.

    Da musst du in die BIOS Liste und Parameterversorgung einsteigen. Bisher kenne ich z.B. nur cp/m Programme wie ähnliche : DU.COM (disk utility, aber klar per BDOS!) .


    Viel Erfolg.

    Solche Schreibmaschinen liegen aber auf einer tieferen Liga.

    TA hatte eine ganze Reihe elektronische Schreibmaschinen, die konnten sowas durchaus.

    Von Mikrorechner - oder PC -Entwicklungen sind kaum oder keine bahnbrechende eigenen TA System zu gewesen sein.

    Solide Mechaniken und Elektrik soweit erforderlich hatte die Gruppe guter Erfolg erwirtschafteten. Den weiteren Gang haben ja viele hier aus den Analen (Suchmaschinen) umfangreich berichtet.

    Genau -TA hatte und war ja keine Mikroelektronik-Entwicklungszelle!


    Es sind ja viele bekannten Microechner / PCs oft von kleinen Entwicklerlabore entwickelt und dann unter „anderen Unternehmen“ in den Markt gebracht wurden.


    Prominentes Beispiel:

    Microsoft kaufte ja das Betriebssystem - von einem canadischem - Softwareentwickler die Grundlagen (Quellcode und alle Rechte) für das spätere MS-DOS.

    Sieht man ja auch, daß die viele Sachen extern entwickelt haben lassen bzw zugekauft (TA PC8, P1/P2,...).

    Hier sind schon doch Zusammenhänge in diesem Beitrag für die TA Geschichte bekannt.

    PCs, als es diese noch gar nicht gab


    oder Die Entwicklung der Hell-Datensichtgeräte


    Aus schon alten Zeiten - habe ich hier ein Foto mit einem DS 2069 Sichtgerät und

    Herrn Dipl.-Ing. Christian Onnasch.


    Er war über meher als ca. 30 Jahre bis zum Ruhestand bei der Firma Dr.-Ing. Rudolf HELL, Kiel im Satzbereich (Sichtgeräte / DOSY / RESY) tätig.



    DS2069 mit der ersten Tastatur-Version ( später eine flache SIEMENS-Tastatur Anpassung für HELL)


    Dazu ist eine kompakte Abhandlung aus seiner Sicht über die Geschichte der HELL Sichtgeräte als pdf unten beigefügt.

    DS 2069 HELL, quasi bereits ein PC

    Bisher habe ich schon einige Infos zu den HELL Datensichtgeräte / Satzsystem DOSY - RESY wie z. B.:

    das DS 2032 und das DS 2038 berichtet.

    Schon mit dem DS 2038 wurde das Steckkarten und Baugruppensystem von damals sks, Karlsruhe entwickelt und dann aber von Dr.-Ing. Rudolf HELL, Kiel überarbeitet und für den indusriellen Einsatz optimiert.


    Etwa 1980 wurde ein völlig neues entwickeltes HELL Daten-Sichtgerät DS 2069 aufgelegt.

    Datensichtgerät : DS 2069 von Dr. Ing. Rudolf HELL, Kiel


    Vom Grundprinzip wie sks-MC80 BUS, Baukarten von KISS und etwa alphaTronic P2 kamen als Basisentwicklung wieder von sks, Karlsruhe für Fa. HELL.


    Zitat von Herrn Christian Onnasch, HELL:

    "Hans-Joachim Steinmetz war der Chef von SKS, Helmut Wiertalla schrieb ursprünglich

    die Software für SKS und später für Hell. Auch das erste Betriebssystem MOS für das

    DS 2038 und DS 2069 stammte aus der Feder von Helmut Wiertalla.

    Das MS-DOS kam ja erst Jahre später.

    Herr Onnasch (HELL) schrieb die Spezifikationen für die Geräte"


    Einige Merkmale /Spezifikation wurden realisiert für das DS 2069:

    • drehbarer Bildschirm,
    • schwenkbarer Bildschirm,
    • bewegliche Tastatur,
    • Sondertatatur mit klare Sondertastenblöcke,
    • zwei Minidisketten LW 5 1/4 Zoll
    • --> spezial Filesysten . Text, Schriften, Multicodes, Formate, Programme
    • Online Anschaltung bis zu vier Satzrecher ( DOSY / RESY)
    • vier ladbare Anzeigeschriften mit 16 x 16 pixel per Zeichen
    • Spezial-Sichtgerät Programm " SIPRO" zum Betrieb OFFLINE / und oder ONLINE
    • MOS Anpassung für die Tastatur und den Monitor (nur die Ports)

    Habe '73 bis '74 dafür als Junior Programmer Selbsttest-SW usw. entwickelt - mit FrontPanel und Lochstreifen.


    Hast du noch alte Unterlagen oder Mustergeräte/ Fotos von deinen Arbeiten?

    Realer Replikator - Additive Fertigung

    Bisher sah man ausschließlich im Science-Fiction-Film, wie sich ein Bauteil aus dem Nichts materialisierte. Nun gibt’s das auch im echten Leben.


    Hier möchte ich mal etwas über den Tellerrand der schon bekannten 3-D-Druckverfahren- mit einem neuen Beitrag aus der VDI-Nachrichten ( (c) Ausgabe Nr.9, 5.März 2021, Verein Deutscher Ingenieure) - mal vor zu stellen.




    Es gibt ja viele 3-D-Druckverfahren für Systeme zum industriellen Einsatz und bis zu recht günstigen 3-D-Drucker für fast Jedermann (Privatbereich).

    Dieses "Xolographie" Verfahren ( Systemkosten ca. 50 T€) ist sicher nicht z.Z. für den Privatbereich erschwinglich, aber neue Entwicklungen zeigen oft Anregungen in einigen Jahren zu drastische geringen Systemkosten.

    Personen bei sks Karlsruhe

    Hier habe ich noch ein historischen "Urlaubsantrag" die folgenden Personen dabei auftauchen.

    Nach den etsprechenden Daten war Herr Linhart und ich dienstlich in Paris bei der Fa. Honywell Bull. Einige sks Geräte waren vorher von Honywell Bull Mitarbeiter per PKW mitgenommen. Es ging um ein Basisgerät als "POS" ("Point of Sale") also eine Art Kassensystem. Die entsprechned Software und weiter Tools wurde einige Tage in Paris übergeben und ein Workshop für das sks - System geschult.


    Die grundlegenden Arbeiten für das "sks MOS" - aus 1978 ist hier verbunden mit Herrn Dipl.-Ing. Radek Linhart und Herrn Dipl.- Inf. Ziegler.

    In der PDF (hier unten abrufbar) sind die Signierungen von der Geschäftführung ( "UK" für Ute Krischke) und helwie44 † als Leiter der Softwareentwicklung.


    sks - Steinmetz- Krischke- Systemtechnik, Karlsruhe

    MOS-Developer
    Dipl.-Ing. Radek Linhart
    , studies RUHR-University-Bochum 1972-1976, software developer at sks later at HP,

    and Dipl.-Inf. Herr Ziegler studies UNI Karlsruhe - Informatik devoleper at sks.

    Schachprogramm (cp/m) Beschreibung

    MICROCHESS MANUAL

    Zu dem Beitrag#102 für dort ein FORTRAN Schachprogramm abgelegt ist - habe ich ein ziemlich vergilbtes Manual für microchess (?) gefunden. Ich denke die Bedienungsgrundsätze passen zu dem FNT-Programm. Sicher sind im letzten Handbuchteil nicht die Patchangaben zum damaligen Erfinder zutreffend.

    Eine Übersicht ist hier vorab unten beigefügt. Eine PDF-der Beschreibung ist abrufbar.


    Aber soweit ich mich erinnere, ist das Manul zum Bedienen brauchbar gewesen.


    Für Tüftler befindet sich etwas im MANUAL über die Bewertungs-Strategie bei der Programm-Entwicklung.

    Evtl. hat jemand mal den Fortran-Code übersetzt und unter einem cp/m Rechner probierte.


    Viele Grüße helwie44 †

    Das könnte aber bei einer Hochsprache ( C, Fortran, Pascal, ADA, COBOL usw.) - Programme doch oft über /swiches für wählbare Zielprozessoren möglich zum Übersetzen sein.

    Programme für den Z80 kompiliert

    Wenn der Endcode hier auf: muSIMP-80 deutet, müsste ein lupenreiner 8080 code sein, oder? Sonst würde evtl. doch dann Z80 vermerkt sein.

    "muSIMP-80 2.14 (12/19/81)

    Das schließt ja nicht aus, das man unter einem cp/m Z80 System damit hantiert.

    Es dürften halt nicht nur die "codelücken ::= Z80" 8080/8085 Maschinenbefehlscode ( ich meine 8 byte) nicht im Anwenderprogramm verwendet wurden.

    Klar - das macht ja nichts, wenn bei der Maschine unter Z80 code der cp/m Anpssungsteil enthält.

    Die alphaTronic PC-8 Maschine ist ja mit einem Z80 verbaut worden.


    Ist TurboRadler bei MuMATH/MuSIMP für CP/M genau bekannt - ob die unter cp/m vorhandenen Programme evtl. nur für den 8080 Maschinencode erzeugt wurden?


    Falls JA - würden ja solche Programme auf cp/m 8080 Maschinen ablaufen könnten.

    Dann wäre eine Übertragung auf z.B die alphaTronic P2 / P3 sinnvoll und mal damit zu probieren?

    Ich habe ja ein TA P2 cp/m modifiziert - um in dem BIOS 6 log. cp/m drives eingerichtet.

    Für LW 1 für alphaTronic Pc 8 als E: und noch für LW 2 dafür F: !

    Von einer PC 8 cp/m Diskette hatte ich von netmercer einige Programme auf eine P2 kopiert - und sogar von der PC 8 Diskette einige Programme gestartet hatte. Klar per DU.COM „Disk Utility“ hatte ich vorher nach Z80 codes mal geprüft - meist haben ja weitsichtige Programmentwickler fast nur als 8080 code erzeugten.


    Viele Grüße helwie44 †

    alphaTronic P2 ( 8085) cp/m Schachprogramm

    Wer Lust hat und sich damit beschäftigen möchte Shadow-aSc und viel MFA-USER (8085)... bitte hier - die Quelle.

    Die Datei ist mir mal einfach zugelaufen. Klar in den 80.er ging das über Disketten. Die Ursprungs-Signatur ist noch in der Quelle enthalten.


    Ich habe das Fortran - Schachprogramm - damals unter cp/m auf einer alphaTronic P2 (8085) compiliert, mit F80.COM und mit L80.COM zum laufen gebracht hatte.

    Zum hochladen ist noch .txt erweitert. Bitte abändern und viel Freude.