Beiträge von kmg

    Das "Ur"-CPM3 ist von DRI für einen 8080 compiliert. Lediglich Sachen wie ZPM3, Z3plus, NZCOM, ZSDOS etc. wurde exkl. für den Z80 programmiert, sonst hätte man die Platzvorgaben von DRI für CCP & BDOS nicht einhalten können. Ein kleiner Hoffnungsschimmer besteht, aber auf lange Sicht steht man sicherlich doch vor dem "Z...". Das Z-System ist schlichtweg ein riesiger Schritt nach vorn, vergleichbar mit dem von CPM2.2 nach CPM3.1.

    Bezieht sich auf #1 & #3(-> erster Satz):

    Mein Vorschlag wäre, das RAM auf z.B. 64k zu erweitern, wobei sich die unteren 32k mit dem ROM überlappen - will heißen, das ROM ist lesbar, das RAM (erst einmal nur...) beschreibbar. So kann man aus dem ROM(-Monitor) booten, ein ev. CPM2.2 aus dem ROM in die oberen 32k kopieren, das ROM abschalten und dann das CPM oder was auch immer starten. Die dann vollständigen 64k RAM ergeben dann das gesamte System und es kann losgehen. Als RAM-Baustein könnte man den AS6C1008 (128kx8) nehmen. Ist dann weiterhin nur ein IC, aber eben mit viel mehr RAM.


    AS6C1008.pdf


    Cheers

    Kurt

    Wobei die 80% noch nach oben wegdriften können.

    volle Zustimmung. Hab' mir aus dem HP-Museum gerade den Schaltplan des Rechner gesaugt. 51 Seiten handgezeichnet ! Der Einsender hat sich anscheinend regelrecht mühsamst durch den Rechner gearbeit - Hut ab, dazu gehört Ausdauer. Leider erschwert diese Kleinteiligkeit des Schaltplanes den großen Überblick ganz erheblich. Ein Service Manual konnte ich nicht auftun. Die eingesammelten Dokumente muß ich morgen erst einmal sichten. Aber viel Hoffnung auf erhellende Einsichten mache ich mir nicht, da eine technische Beschreibung anscheinend nicht dabei ist- schaun 'mer mal !


    A propo Grafikbilder: die sehen eigentlich ganz gut aus. Unterscheidet der Rechner eigentlich zwischen Grafik u. ASCII Bildspeicher oder ist das alles nur Grafik ?


    Cheers

    kurt

    Ist die Frage, wie gut kennst du dich mit der Hardware des 9815 aus.

    gar nicht. Aber ich habe oft genug Hardware mit Fehlern gehabt, die auf Temperatur reagiert haben. Die anfängliche Frage ist stehts, wo muss der Übeltäter verortet werden. Solange man hier im trüben fischt ist jede Reparatur fast unmöglich. Kältespray bzw. (Finger)Wärme soll die Suche eingrenzen. Je nach eigener Präferenz u. Fehlerart gibt es mehrere "Testverfahren":

    1. Kälte/Wärme: bei Driftproblemen von Arbeitspunkten, funktionstechnischen Veränderungen

    2. klopfen: bei Kontaktproblemen (z.B. von Relaiskontakten, losen Steckkontakten)

    3. Leiterplatte leicht verwinden: bei kalten Lötstellen z.B., oxydierten Steckkontakten

    4. Sichtkontrolle: beschädigten Leiterbahnen, defekten Bauteilen (z.B. Elkos, überhitzten/gebrochenen

    Widerständen, abgerissen Drähten, durch hohe Temperaturen angelaufene Gehäuse/Kühlkörper)

    5. Mit der Nase unüblichen Geruch suchen: IC's riechen mitunter verbrand/überhitzt, Überhitzung, die

    ohne sichtbaren Schäden erfolgte, aber dennoch riecht....

    ohne techn. Unterstützung kann ich da wenig helfen.

    Stimmt, das leidige Problem der Ferndiagnose, es bleiben nur Ratschläge/Hinweise. Das Groh der Arbeit bleibt beim Hilfesuchenden hängen - das ist mit voll bewußt.


    Mein damaliger Geselle kategorisierte die Fehlersuche immer so: 80% finden sich durch Auge und Nase, den Rest muß man suchen. Zugegeben, diese Regel stammt aus einer Zeit, als Röhrenfernseher noch häufig anzutreffen waren. Aber Grundsätzlich liegt man mit diesem Ansatz immer noch ganz gut. Allerdings fürchte ich, hier sind es die verbleibenden 20%, welche mit 80% Arbeit zu Buche schlagen - meint suchen bis der Arzt kommt... ;)


    Chers

    Kurt

    Das sieht wirklich sehr merkwürdig aus. Zum Teil sind die Großbuchstaben wie z.B. das 'H' in den oberen paar Zeilen aus dem Charakter-ROM vertümmelt bezw. in der Helligkeit wie's scheint reduziert. Ist das Charakter-ROM gesteckt oder eingelötet ? Wenn gesteckt, zieh es mal aus dem Sockel, reinige mit den Fingern etwas die Beinchen oder mit einen Baumwollhandtuch vorsichtig abreiben, damit die Oberfläche wieder oxydfrei wird. Dann wieder in den Sockel. Wenn gelötet, könnte das ROM mit seinen Daten Probleme haben. Sowas ist per Ferndiagnose immer etwas heickel, ich tippe in solchen Fällen auch immer mal ganz gern mit der Hand von unten gegen die IC-Beinchen, um zu sehen was sich dann da so tut. Derartige Methoden haben leider auch immer etwas mit der eigenen Erfahrung in Sachen Fehlerdiagnostik/Reparatur zu tun. Was für ein Fehlerbild ergibt sich auf dem Bildschirm, wenn Du die gestörten Buchstaben einmal ganz gezielt darstellen läßt ? Sowas liefert u. U. noch mehr Einblicke bez. des Problems.



    Cheers

    Kurt

    Also wenn da irgendwas über die Zeit verschwindet und dann bei betriebswarmen Gerät durch "Neustart" nicht reproduzierbar ist, würde ich immer auf einen wärmeabhängigen Effekt tippen. Silizium wird schneller, wenn es warm ist, das betrifft auch Signallaufzeiten und Schaltverhalten - ev. hat auch ein TTLer eine leichte Macke und sorgt für einen Bitfehler auf einem Adressbit für den Charakter-ROM (sollte Deine Beobachtung zutreffen), der im betriebswarmen Zustand dann verschwindet. Wenn Du hast, benutz doch mal Kältespray. Damit könnte sich der Verursacher lokalisieren lassen. Einfach die in Frage kommenden IC's kurz anspühen. Kontrollier auch mal die 5V, ob da nicht Spannungseinbrüche drauf sind, die mit der Zeit verschwinden.


    Cheers

    Kurt

    kmg: den V-Edit 2.33 muss man wohl noch installieren aus deinem .ZIP? Ich sehe da nur 2 .COM-Files

    So ist es, aber bei der Installation werden die Terminalemulation (die ganzen Steuercodes fuer den Bildschirm) nebst vieler andere Sachen, die das Verhalten des Editors etc. betreffen, einstellen. Da kann/darf man nicht dran vorbei. Ich habe mir den Burschen so einmal für das Linux-Terminal und das andere mal für den Multicomp spezifisch konfiguriert - leider, da die Tastatur/Terminal-Codes beider Ternimals unterschiedlich sind. Beim Multicomp kneift es bezüglich der Tastaturcodes ganz erheblich (zu wenig/keine Multikey-Codes), weshalb die Bedienung recht unterschiedlich ist. Beim Multicomp kommen deshalb viele der Fx-Tasten ins Spiel, andernfalls wären Sachen wie horiz. Scrollen oder wortweises springen mit dem Cursor, seitenweises scrollen etc. nicht machbar gewesen - kleine Stolpersteine des täglichen Lebens...


    Cheers

    Kurt

    ...nicht nur dort. Unter linux gehts mit xarchiver auch. Was mir unter linux noch fehlt, ist etwas, was CPM Dateien in ein CPM .lbr Archiv verpacken kann. Ist so eine Möglichkeit jemandem bekannt ?


    Die Möglichkeit für Arme, mit Grant's Verpackungsmethode alles nach CPM übertragen, dort in ein .lbr stecken und dann wieder zurück auf den Laptop zwecks Backup geht super, könnte aber auch komfortabler (sprich kürzer/direkter) sein.


    Cheers

    Kurt

    Warum das Apfelmänchen unter PASCALZ4 bei der Menge der dargestellten Zeichen anders aussieht, liegt am FLOAT. Turbo-Pascal hat 48-bit FLOATs = 10 signifikante Stellen, PASCALZ4 nutzt 32-bit FLOATs mit 6 1/2 signifikante Stellen. Dadurch sinkt die Auflösung und die Iteration bricht früher ab. Um das auszugleichen mußte die Iterationstiefe auf 28 erhöht werden. Darüber hinaus zu gehen bringt nichts mehr, da dann die Auflösung auch mit mehr Iterationen nicht mehr verbessert werden kann. Konkret heißt das: das letzte benutzte Zeichen ist das $-Zeichen, wenn mit dem Blank gestartet wird. Damit in Inneren des Apfelmänchens das '-' Zeichen erscheint muß n2:=2 gesetzt werden. Dann ist das Blank aber außen vor. Damit Mandelbr auf das ENTER wartet, muß statt READLN der Befehl READ(n1) benutzt werden. READLN hat unter PASCALZ4 die Funktion der File-Eingabe, die hier nicht zum Tragen kommt - deswegen auch kein warten auf eine Tastatureingabe. CHARACTERS ist als characters:ARRAY[1..18] of CHAR; zu definieren, der zugewiesene Zeichenstring muß dann allerdings auch 18 Zeichen lang sein. Regionale unterschiedehalt - deswegen verstehen die Bayern ja auch die Ostfriesen nicht und umgekehrt ;)



    mandelbr4.pas.zip

    PascalZ4.zip

    Hier mit MYZ80 und Z3PLUS SMALL

    wuste doch, das ich mit dem Zitat etwas falsch mache, jetzt stimmt's ;)


    Der Run im MyZ80 Emulator sieht besser/ok aus. Das dass mit den Zeichen nicht so richtig stimmt, liegt sicherlich an meiner Korrektur, da würde ein genaueres hinsehen eine Besserung bewirken. Die Indizierung der Zeichen funktioniert wohl nicht mehr wie gewünscht. Aber nicht mehr heute abend. Eigentlich sollte ich einen Run auch noch mit dem SBasic-Compiler versuchen, das mandelbr-Programm bietet sich geradezu dafür an. Anschließend kann ich immer noch Ursachenforschung betreiben.

    Zitat

    kmg das sind aber auch andere Zeichen, die fuers das Mandelbrotmuster, bei Deiner Uebersetzung des Programmes ;)

    Macht dies der Compiler?

    Am Programm-Code habe ich nichts geändert bis auf die markierte Stelle:

    PROGRAM mandelbrot;

         VAR im, re:Real;

                zr, zr2, zi, zi2:Real;

                n,n2:Integer;

                characters:String 18;

    _____________________________^^^^


    Aus Syntax-Gründen mußte ich die "[" & "]" löschen. Der Rest ist unverändert.


    Zitat

    Du kannst Z3PLUS auf SMALL setzen, manchmal ist dann aber doch noch zu wenig Speicher vorhanden.

    Das mit dem small für Z3plus habe ich noch auf dem Todo-Zettel. Wen ich das so wie es ist aufrufe ist das System etwas strange configuriert und nicht gut zu gebrauchen... Insofern hast Du mit Deinem Hinweis recht. Ich sollte das so langsam mal machen.

    Ich erhalte auf meinem CPM-System (CPM3 mit Z3plus) ebenfalls die "out of memory" Meldung. Das liegt eindeuting am Z3plus, da damit die TPA zu klein ist. Mit ZPM3 gehts ohne Fehlermeldung (TPA 60.5k). In beiden Fällen habe ich das mit TP compilerte com benutzt. Ich habe das pas-File dann mal mit pascalz4 übersetzt und die Zeit gestoppt: ~39sek. Ob das nun tatsächlich genau 39sek. sind oder wegen aus dem Augenwinkel handgestopt auch 40sek. ist erst einmal egal. Interessant ist aber die erzeugte com-File größe: TP = 8832 Byte, PASCALZ4 = 7754 Bytes. Das sind beachtliche 1024 Bytes kürzer. Ob das representativ ist, laß ich mal offen, denn die Tastaturabfrage "Start mit Enter" & "Weiter mit Enter" funktioniert nicht (es wird nicht gewartet, s. Bild).

    ja, in Sachen Tempo ist die Kiste beeindruckend.


    Ich hab' im Handbuch noch nicht geblättert und danach gesucht, ob sich über den Dateimanager auch externe Software starten läßt (oder wie auch immer). Wenn das ginge, könnte aus der Sache durchaus mehr werden.


    Nach dem Datenblatt für den Prozessor hab' ich nicht gesucht, geschweige denn nach einem Assembler etc. Vielleicht sollte man, schadet sicher nichts. Den Source-Code für den Interpreter gib's ja auch (nur auf Anfrage hin, nicht einfach so und nur für die eigene Nutzung), aber das ist nichts für mich. Das Feld überlaß ich den Experten, mal reingesehen zu haben reicht mir.

    Der englische Shop scheint der einzige zu sein, der komplet, also mit Gehäuse, verkauft. In den USA gibt es wohl bevorzugt nur das Mainboard und für's Gehäuse zum Selberbohren nur Schablonen - dafür ist es dann auch etwas teurer ;) Das Board selbst kostet wohl (ohne Versand) soviel wie aus UK das ganze Gerät (inkl. Versand), Dafür ist die Lieferzeit (aus USA) mit einer Woche recht schnell, Der Kauf ist kein Notfall, ich kann durchaus etwas warten.

    Bin gestern abend in einem englisch sprachigen Forum über einen Hinweis auf den Color Maximite 2 gestolpert. Die Videos auf Youtube sind sind schon beeindruckend. Etwas vergleichbares für den Z80 unter CPM gibt es leider nicht (in sehr geringem Maße vielleicht der SBASIC5.4 (Compiler) welches von KAYPRO her bekannt ist, keine Zeilennumern, strukturierter Befehlssatz, aber nichts mit Grafik. Dafür beherrscht der Compiler eine brauchbare Biliotheksverwaltung). Konnte ebenfalls nicht umhin, mir einen Maximite zu bestellen. Bei der gegenwärtigen schwäche des Pfundes mit €96,-- nicht einmal zu teuer ;) Mal abwarten, wann das Teil bei mir aufschlägt, die Lieferzeiten (~3 Wochen) sind ja etwas lengthy... ;)

    Der Emic 2 ist auch gut, der serielle Anschluss wäre sogar noch besser. Eine Hörprobe der wav-File klingt sogar recht gut - mich stört jedoch, dass nur English und Spanisch als Sprache möglich sind. Englische Phoneme fuer deutsche Texte zu nehmen dürfte ein recht schwer verständliches Ergebnis erzeugen. Können die Phonem-Daten des Talker-80 ausgetauscht werden ? Im Ordner /Talker-80-master/src/atmega644 gibt es einige *.h Files die das vermuten lassen.

    Die Dinge sind leider doch etwas komplizierter: Mein erster Gedanke war, den Talker-80 über einen 8255-IO Port zu steuern (Mein CP/M-System besteht nur aus einem FPGA plus 8255-PIO). Dann muß die Software aber vermutlich anders ansteuern, d.h., Signale wie n_WR & n_RD etc. müssen per Software gesteuert werden, damit es geht. Grundsätzlich sollte das aber kein großes Problem sein, solange der Datenfluß stimmt oder ?

    ganz schön abgedreht ! Da ich aber weder einen TRS80-M1 noch M3/M4 besitze gleich die Frage: ginge das auch für CP/M ? Im zip auf Github sind alle Basic-Progs tokenized bzw. als *.cmd Programme enthalten. Das ist etwas hinderlich. Läst sich das offener gestallten, d. h. als ASCII bzw. im source ?