Beiträge von kmg

  • DRVVEC unter ZPM3 anpassen

    Nach dem wirklich ergiebigen/hilfreichen Chat mit fritzeflink hier mal eine Rückmeldung zu den Umstellungen an meinem Z80-System.


    Arbeiten auf der SD-Karte:

    Der Wechsel von CPM3.1/Z3plus nach ZPM3 war eher simpel und beschränkte

    sich auf das Umkopieren einiger noch benötigter Programme aus der Z3plus-Installation auf's ZPM3-Laufwerk. Da ich wegen der intensiven Nutzung von RSX'en für meine Zusatz-Hardware mit CPM2.2 u. seiner Klone eh' nichts mehr anfangen konnte, habe ich das zum Anlaß genommen die betreffenden Laufwerks-Images nach dem Verschieben von CPM3 (Image3) auf's Image 2 und ZPM3 (Image7) auf Image2 die dann freien Images 3...7 mithilfe des Boot-Monitors neu zu formatieren und so in Zukunft als Datenlaufwerke 3...8 (Image8 war eh schon frei) zu nutzen. Image9...18 stehen weiterhin als Laufwerke mit der schon vorhandenen großen Sammlung an Z-System Programmen und anderer CPM Software zu Verfügung. Image 19 u. 20 habe ich als Ergänzungslaufwerke angelegt, damit Platz für weitere CPM-Software vorbereitet ist. Prinzipiell kann das noch bis Image253 ausgebaut werden, aber das wäre ein Overkill, der das Sichern der SD-Karte auf den Laptop nur unnötig aufbläht. Durch packen als zip oder tar.gz Archiv schrumpft das Image zwar deutlich, aber zuvor wären dann immer noch 2GB von der SD-Karte zu übertragen und das dauert halt recht lange...


    Arbeiten am System:

    Bei einer Blockgröße von 4kB auf dem Laufwerk ist der Verschnitt bei meist kurzen Programm-Dateien doch recht erheblich. In der Vergangenheit ist es mir deshalb öfter passiert, das entweder keine Dir-Einträge mehr zur Verfügung standen oder das Laufwerk voll war bei gleichzeitig noch freien Dir-Einträgen. Um dem zukünftig besser vorzubeugen, wird von lbr-Archiven ausgiebig gebrauch gemacht. Alle nicht zwingend auf dem Bootlaufwerk (also A0:) benötigten Programme sind in einem lbr zusammengelegt. Sie werden jetzt mittels CMDRUN.COM über Makros im File ALIAS.CMD gestartet. Hierbei kommt das Z-System Utility LX.COM zu Einsatz. Mit seiner Hilfe können Programme aus einem lbr-Archiv heraus gestartet werden - was eine beachtliche Einsparung an Platz auf dem Laufwerk und an Dir-Einträgen bewirkt. Dank SD-Karte und 25MHz CPU-Takt geht das alles immer noch recht flott von statten.


    Für Systeme mit 4MHz und Floppy-Drives habe ich jedoch den Eindruck, dass diese Lösung zu langsam wird, weil einfach zu viele Daten gelesen werden müssen bevor eine Aktion endlich ausgeführt werden kann. Das Durchsuchen der lbr's (SYSUTILS.LBR = 460k : ZUTILS.LBR = 316k) dauert denn doch etwas und macht das System bei 4MHz träge.


    Auf A0: liegen jetzt nur noch Programme, die den Betrieb des System auch dann ermöglichen, sollte durch zu viel gebastel die Unterstützung durch CMDRUN.COM wegfallen (alles jüngst durchlebt... =:o) ) bzw. unabdingbar wegen des gewählten Konzeptes auf A0:SYS vorhanden sein müssen (kritisch sind hier STARTZPM.COM, ZPM3.SUB, SUBMIT.COM). Das CPM3/Z3plus-Image brilliert hauptsächlich als Rettungssystem (durch die Praxis als sinnvoll bestätigt...), falls der angerichtete Schaden einmal so groß ist das nichts mehr geht. Im schlimmsten Fall bleibt dann aber noch, das gesicherte SD-Image auf die SD-Karte zurück zu schreiben...


    Rückblick:

    Das ganze gefrickel am System hat sich klar gelohnt. ZPM3 als auf's Z-System ausgerichtetes Betriebssystem ist ein riesen gewinn. Mein Fokus liegt jetzt ganz klar hier, da die TPA ohne Zusätze 61kB groß ist. CPM3 ohne Z3plus ist einfach zu weit vom Z-System entfernt, sollte einmal ein 'Z3plus OFF' notwendig werden. Gerade die zu Ordnern umdefinierten User-Nummern sind sehr hilfreich, wenn die Laufwerksgrößen den engen Rahmen von Floppies verlassen und man nicht in endlosen DIR-Listings ertrinken will - von den Vorteilen der lbr's ganz zu schweigen (s. meinen DEV:-Ordner im angehängtem zip). Auf CPM3-Ebene zurückgefallen fällt der Verlust der Z-System Vorteile einfach zu stark ins Gewicht (was jedoch das Gespann CPM3/Z3plus nicht abwerten soll, ich mußte mich halt für eine Seite entscheiden und es gibt ja noch das Rettungssystem...).


    Cheers

    Kurt


    BOOT-Meldungen_u_File-Listings.zip

  • LED Lampen schützen durch RC-Glieder?

    Für die EVU's ist es am einfachsten, die Netzfreq. konstant zu halten. Bei der Netzspg. dürften Regionale schwankungen, ausgehend von der Nennspg. hin zu häufigerer Über- oder Unterspg. mit an der Lebensdauer von einfachen LED-Leuchten drehen. Die letzten angeschaften (etwas teureren) Deckenleuchten, haben alle einen Kasten als Betriebselement vorgeschaltet. Da merkt man bereits beim Einschalten, das da kontrolliert besaftet wird. Birne rausdrehen ist wegen der LED-Streifen nicht möglich, also bei kaputt -> neu. Die laufen jetzt aber auch schon seit über einem Jahr und sind recht häufig länger an als nötig (in der sonst dunklen Garderobe könnte ja ein Fremder stehen... :-| ).


    Cheers

    Kurt

  • LED Lampen schützen durch RC-Glieder?

    Zitat von x1541

    Baue ich jetzt am WE ein, mal sehen wie lange die hält.

    Ich habe bei mir bereits einige LED-Lampen nun mehrere Jahre am Laufen. Wenn die vernünftig designed sind stimmt die angegebene Lebensdauer auch. Allerdings hatte ich auch einen totalen Fehlkauf von aus mehreren LEDs aufgebauten Strahlern, die waren reproduzierbar nach ein paar Wochen hin. Waren aber auch billige Schnäpchen-Birnen... (gekauft, als es mit den LED-Lampen so langsam los ging).


    Cheers

    Kurt

  • LED Lampen schützen durch RC-Glieder?

    Zitat von Toshi

    Kennt ihr das? Ist da was dran? Verlängert das ein LED Lampen-Leben?

    Grundsätzlich falsch ist das was Reichelt da schreibt nicht - Spanungsspitzen und auch Überspannung sind Gift für LED-Lampen. Gute Lampen haben daher eine entsprechend ausgelegte Elektronik als Vorschaltelement. Diese sollte mit den üblichen Situationen am Stromnetz klar kommen und sorgt gleichzeitig für einen Sanftanlauf beim Einschalten nebst vernünftigem Betriebsstrom (ein zu hoher Einschaltstrom außerhalb der Spezifikation sorgt für einen verfühten tot der LED's durch 'ausbrennen = Heligkeitsverlust'). Deshalb ist der vorgeschlagene Kondensator eigentlich überflüssig und wenn falsch dimensioniert, kann auch der u. U. geschädigt durch Spannungsspitzen, dielektrische Verluste etc., platzen - also womöglich nur ein zusätzliches Problem statt Abhilfe. Damit so ein Kondensator hilft, braucht's auch mindestens noch einen Vorwiderstand oder Seriendrossel, sonst filtert er gar nichts. Der Hinweis fehlt z.B. In meinen Augen nett gemeint, aber irreführend.



    Cheers

    Kurt

  • RunCPM Speed-Vergleich auf verschiedenen Plattformen

    zu #79:

    Meinen Versuch, das Apfelmännchen mit X11basic (dieser Interpreter erzeugt Token als Zwischencode, eine Interpretation entfällt dadurch) zu berechnen habe ich abgebrochen. Um die beiden GOTO's aufzulösen, muß das Programm doch recht gründlich umgeschrieben werden. Damit dürfte aber auch die Vergleichbarkeit entschwinden. Sei's drum, ist ja keine Forschungsaufgabe, die Ergebnisse sind dennoch sehr aufschlußreich.


    Cheers

    Kurt

  • RunCPM Speed-Vergleich auf verschiedenen Plattformen

    Außer Konkurenz, hier einen Lauf mit BWBASIC unter Linux in der Konsole, CPU-Takt ist 2.8GHz. Da BWBASIC nichts genaueres zur Zeitmessung bietet wie TIMER & TIME$, beide liefern nur 1s an Auflösung, liegt die Laufzeit zwischen 1...2s. Mehrfaches wiederholen des Laufes zeigt kein anderes Ergebnis wie 1s Zeitdifferenz, also irgendwo zwischen 1s und 2s. BWBASIC ist in C programmiert !, führt keine Tokenisierung durch und arbeitet rein interpretativ. Das Program ist leicht geändert, die '%'-Zeichen sind entfernt (mag BWBASIC nicht) und stattdessen am Anfang DEFINT und DEFSNG Anweisung eingefügt. Ändert aber gegenüber reinen REAL-Variablen nichts erkennbar am Ergebnis.


    Cheers

    Kurt


    ASCIIART_bas_BWBASIC.txt


    Nachtrag:

    Linux bietet den 'time'-Befehl zur Laufzeitmessung von Programmen auf Systemebene in der Konsole. Nutz man diesen, 'time bwbasic ASCIIART_bas_BWBASIC.bas', dann übernimmt Linux die Zeitmessung mit einer Auflösung von 1ms - schon mal deutlich besser als die 1s von TIME$. in Zeile 240 muss für diese Messung statt END QUIT stehen, sonst bleibt man in BWBASIC hängen !

    Interessanter Weise liegt die Zeit unter 1s ! und das obwohl hier der gesamte Ablauf, also 'time' starten, GWBASIC starten, welches dann wiederum das Program zu laden hat, gemessen wird. Dazu noch, im Rechner steckt eine SSD als Platte, was Ladevorgänge per se deutlich beschleunigt.


    Trotzdem wird man von dem Tempo nicht bewustlos und das bei 2.8GHz CPU-Clock. Dafür gibts dann aber Multi-User und Multi-Tasking satt, verdrehte Welt...:tüdeldü:

  • RunCPM Speed-Vergleich auf verschiedenen Plattformen

    Zitat von funkenzupfer

    hat fuer mich einen :wand:

    Danke !, wie ich schon weiter oben schrieb "(mit interner Stopuhr gemessen)", also per Hardware-Zähler u. nicht von Hand. Im Übrigen ist das meine Meßroutine für Laufzeitmessungen, die ist halt der Einfachheit wegen so eingestellt (s. Screenshots). Es ist also keine Erbsenzählerei, eher banaler Pragmatismus um nicht für jeden Sonderfall die Software anpassen zu müssen, deswegen ja auch die Meßzeit von Tagen bis herunter zu ms !


    Cheers

    Kurt

  • RunCPM Speed-Vergleich auf verschiedenen Plattformen

    Zitat von funkenzupfer

    Die Differenz der Differenzen ist 1 ms. Mit einer Tick von 1 ms

    In dem Punkt reden wir aneinander vorbei. Ich hatte dich so verstanden, das die geringe Differenz der Runs mit/ohne PRINT auf Toleranzen vonf handgestoppten Zeiten zurückzuführen ist (was gut hätte sein können, da man selbst nicht immer so exakt reagiert, deshalb der Hinweis 'Stoppuhr'). Das Du die Differenz der Differenzen meintest, ist mir entgangen... :nixwiss:


    Ansonsten hast Du recht. Überrascht hat mich schon eher die nahezu identischen Werte. Ich werd' mir jetzt jedoch nicht die Mühe machen, heraus zu finden, warum dem so ist. Soo wichtig ist das Apfelmännchen nun auch wieder nicht :tüdeldü:


    Cheers

    Kurt

  • RunCPM Speed-Vergleich auf verschiedenen Plattformen

    Zitat von funkenzupfer

    ...Zeitunterschied (im Rahmen der Messtoleranz)...

    Keine Meßtoleranz, die gestoppten Zeiten haben eine Auflösung von 1ms. Die Stoppuhr ist ein 1ms-Zähler mit Zwischenzeitenregister, die über OUT-Befehle gesetzt werden. Die PRINT-Anweisungen im Programm sind lediglich auskommentiert. Zumindest der Interpreter muß dann immer noch das REM erkennen und zur nächsten Zeile gehen, aber der dafür notwendige Zeitaufwand ist recht gering. Der Compiler erzeugt dafür keinen Assemblercode. Basic-Prog mit Compiler-PRN hier:


    ASCIIART_bas_und_PRN.txt


    >> BTW: Nachträglich Glückwunsch zum Geburtstag!


    Danke !



    Cheers

    Kurt

  • RunCPM Speed-Vergleich auf verschiedenen Plattformen

    Wenn ich die Laufzeiten einmal mit und ohne PRINT-Ausgabe für den Interpreter und das Kompilat messe, erhalte ich folgendes:


    Diff compiliert 19.768s - 18.410s = 1,358s

    Diff interpreter 46.710s - 45.351s = 1,359s


    Zumindest bei meiner Kiste scheinen die PRINTs nicht die Spaßbremse zu sein. Die meiste Zeit wird wirklich mit der Berechnung verschleudert...


    Cheers

    Kurt

  • RunCPM Speed-Vergleich auf verschiedenen Plattformen

    Hier die mit bascom5.3 und der Option /Z compilierte Ausgabe:


    CPU: T80

    Clock: 25MHz

    Laufzeit: 19.768s (mit interner Stopuhr gemessen)

    Ausgabe: 115.2kBd.


    Hätte nicht gedacht, dass das so viel bringt. Ich habe den Eindruck, als wenn die serielle Ausgabe bereits zum Nadelöhr wird, aber bei 115.2kBd. ist halt Schluß.


    Cheers

    Kurt

  • Elektor EC65 Z80-CP/M-Karte EPROM (BIOS80) fehlt

    Zitat von tante ju

    Aber wenn Du den SC/MP hast...

    Leider nein, der ist vor über 25 Jahren den Bach runter gegangen (Zimmerbrand..., lag nicht am SC/MP !). Ich habe aber vom Elbug und den NIBL-Interpreter zip-Files. Beim Basic-Interpreter gilt das in den Elektor-Heften gesagte bezüglich der Adresslage etc. Leider ist das Ganze schon recht lange zurück, aber ichdenke die beiden zip's decken das SC/MP System ab, sonst nachfragen.


    elbug.zip

    NIBL_asm.zip



    Cheers

    Kurt

  • Interesse und Mitwirkende für Gigatron gesucht

    Zitat von klaly

    Dem Thread hier bin ich breigetreten, um Anregungen zu bekommen, was man evtl. noch damit machen könnte.

    Die Frage, nach abgeschlossenem Projekt, habe ich schon häufiger gelesen. Ich habe mir die Schaltpläne des Gigatron mal angesehen und mir ist dabei folgender Gedanke gekommen:


    Wäre es nicht sinnvoller, folgenden Ansatz zu wagen und mittels Quartus2 die Stromlaufpläne zu übernehmen und damit einen Softcore des Gigatron zu erstellen. Als Hardware-Basis würde sich das Cyclone-II Board von http://www.retrobrewcomputers.org anbieten. Das hat alle notwendigen Interfaceanschlüsse und frei IO's on Board (die speziell für spätere Erweiterung bzw. zum debuggen). Schaltpläne in Quartus zu zeichnen geht recht schmerzbefreit, wäre also nicht unbedingt ein Problem. Die Property-Bibliotheken werden hoffnungsweise die meisten TTL-IC abwerfen (habe ich jetzt nicht überprüft). Die CPU übernimmt man von Grant's Multicomp.


    Bevor jetzt jemand/alle aufstöhnt, ich beabsichtige hier keine Werbung für FPGA's zu machen !, schon wegen der umfangreichen Quartus2-Software ist das sicher nicht jedermanns Sache, aber einfach etwas nachbauen, um es dann beiseite zu legen ist schon etwas krass. Sollte das Interesse am Ergebnis nach Projektende nachlassen, besteht immer noch die Möglichkeit, die Hardware für was anderes zu nutzen (6809 System mit NitrOS9 von Neal Crook z.B.) oder auch den Gigatron mit eigenen Ideen "um zu bauen". Solange man sich auf die IC-Bibliotheken stützt (stützen kann), bleibt VHDL unterhalb des Radars. Ein weiteres Argument sind die Projektkosten. Das Core-Board + die PCB, exkl. Bauteile, die hat vielleicht jeder in seiner Bastelkiste, sollte für geschätzt €30,-- zu haben sein (ich kalkuliere mal Bulk-Bestellungen), der Gigatron sicherlich nicht.


    Nur so ein Gedanke. Es gibt sicher noch mehr Pro's & Con's, aber da kann man drüber reden...


    Cheers

    Kurt

  • Elektor EC65 Z80-CP/M-Karte EPROM (BIOS80) fehlt

    [ok, zu lang gewartet, hat sich dann wohl überholt...]


    Etwas tiefer auf der Web-Side finden sich vermutlich die gesuchten ROM-Images:


    http://retro.hansotten.nl/6502…r-junior/junior-software/


    A collection of dumps of various ROMs from Juniors, expansion cards, EC65/Octopus. Not tested but may be useful.


    – PM. TM Monitor etc, 506, Mini EPROM 511(n)


    – VDU, Character, Micro Ade, SYM AIM BASIC EPROMer 6502 tracer, 244, Mini EPROM 51


    – EC 65 Octopus ROMs, dumped from CPU cards


    – a bootstrap eprom (ESS515 download here, source in Paperware 2) able to load OS65D (V3.1 or 3.3)


    Multiple-Choise, aber lösbar... ::pc::


    Cheers

    Kurt

  • Taugt das was ? Handheld/Multimeter + Oszilloskop (bis 40MHz) KKM781

    Zitat von Peter z80.eu

    Wer das so hypergenau anzeigen will, kann auch gleich in die Hardware-Entwicklung gehen.

    ...stimmt, da liegst Du richtig. Es ist nur häufig so, das man sich in etwas verkuckt und anschließend mit etwas da steht, was nicht weiterhilft, weil es nur unzureichend paßt. Von Glaubenskrieg kann also nicht die Rede sein, Lehrgeldzahlungen sind nur die aufwändigste Art Geld unter die Leute zu bringen - ich bilde da keine Ausnahme. Ich wollte nur vor der Kaufentscheidung ausreichend Licht in die Sachverhalt bringen damit nicht hinterher einem ein Licht aufgeht...


    Cheers

    Kurt

  • Taugt das was ? Handheld/Multimeter + Oszilloskop (bis 40MHz) KKM781

    Zitat von detlef

    200-300 MHz sind sicher ganz nett, aber für welchen Einsatzzweck? Um den Takt eines 6502 oder Z80 zu messen? Muss man da ein perfektes Rechteck sehen.

    Deshalb gibt es ja Logik-Analysatoren. Wenn ausschließlich digitale Signale (wie in einem Rechner z. B.) gemesen werden, ist die Darstellung des analogen Signals "Rechteck" unwichtig. Dort kommt es auf zeitliche Beziehung zwischen Flanken an und genau hier steckt wieder der Teufel im Detail. Damit das zuverlässig funktioniert, muß die Bandbreite sowie die Abtastrate hoch sein. Andernfalls erfolgen Pegelwechsel womöglich zwischen zwei Abtastungen, was wiederum bedeutet, das eine sichere zeitliche Beurteilung des "Wann" dieses Zustandswechsels nicht mehr möglich ist. Damit geht ein wichtiges Messkriterium verloren. Mit einem "Wenn-Dann-Vielleicht-oder-auch-Nicht" zu einem bestimmten Zeitpunkt kann man nichts anfangen. Insbesondere dann nicht, wenn die Flanke zu einem bestimmten Zeitpunkt liegen muß, man das aber aufgrund der zu groben Abtastung nicht genau feststellenn kann. Mit so einem Sachverhalt Fehlersuche betreiben zu wollen, kann da ganz schnell nervig werden. I. d. R. wird man nur dann was messen wollen, wenn etwas NICHT funktioniert. Dann aber auch verläßlich u. richtig...


    Cheers

    Kurt

  • Taugt das was ? Handheld/Multimeter + Oszilloskop (bis 40MHz) KKM781

    Zitat von Peter z80.eu

    Es gibt noch ein anderes Handheld-Oszilloskop, das man leider nicht mehr auch als Multimeter nutzen kann.

    Mit den Messstripen eines DVM's kann man keine steilflankigen Logisignale messen, dafür sind deren Leitungsinduktivitäten einfach viel zu hoch. Deshalb benutzt man in Verbindung mit einem Scope auch nur Tastköpfe und die wenn möglich auch nur mit möglichst kleiner Eingangskapazität (<15pF) und nur in 10:1-Einstellung( Ri=10Mohm). Bei sehr breitbandigen Signalen vermeidet man es sogar direckt, den Masseklipp zu benutzen und klemmt den Messpunkt zwischen Messspitze und dem daneben liegenden Massering an. Alles das hat/kann ein DVM mit Scope-Zusatz nicht leisten. Deren Einsatzgebiet ist das Arbeitsumfeld eines Elektrikers und nicht die eines Elektronikers. Verzwerge Deine Ansprüche nicht unnötig, das führt zu Doppelkäufen und fuhrt im nachherein betrachtet nur zu erhöhten Ausgaben. Ein gutes DVM ist wichtig, aber dann eines mir integrierter 4-Drahtmessung, hoher Stabilität und Auflösung. Das ist dann eher ein Vorteilskauf. Ein Scope mit Logikanalysator und Funktionsgenerator ist z.B. eine super Kombi, weil es im selben "Teich" jagt. Das soll jetzt von mir keine Ansprache für einen Spendierhoseneinkauf sein (was für ein Wort ... ;-)), es soll nur aufzegen was zusammenpaßt - letztlich Entscheidest Du was für dich sinnvoll ist.



    Cheers

    Kurt

  • Taugt das was ? Handheld/Multimeter + Oszilloskop (bis 40MHz) KKM781

    Zitat von funkenzupfer

    Aber warum muss ich diese Oberwelle noch 10 fach samplen?

    Sieh Dir einfach mal an, was ein Rechteck-Signal bei 10 Abtastpunkten/Periode für Verenkungen macht, dann wirst Du meine Aussage durchaus berechtigt finden.

    Zitat von funkenzupfer

    Ok, 10 Punkte / Periode sind das absolute Minimum. 20 bis 50 sind bestimmt nützlich.

    Genau diese Deine Aussage wirst Du dann tätigen, mit der Betonung bei 50 Abtastpunkten. Ich habe mit meinem Scope genau diese Sachlagen durchgespielt - im Nachherein bin ich froh, mich für 300MHz und 2GSample im Einkanalbetrieb entschieden zu haben. Auf einem hochaufgelösten Auge sieht man einfach mehr ;)


    Chers

    Kurt

  • Taugt das was ? Handheld/Multimeter + Oszilloskop (bis 40MHz) KKM781

    Du wirst nicht um ein Gerät mit 200MHz Bandbreite und 1...2GSamples Abtastfrequenz herumkommen, wenn auf dem Schirm Rechtecksignale und nicht nur ein müder Sinus zu sehen sein sollen. Das hat seinen grund darin, das zur Darstelung eines Rechtecks neben der Grundwelle auch noch die Oberwellen benötigt werden und zwar mindesten bis zur 10ten Oberwelle. Bei einem Clock (als Beispiel) von 16MHz bedeutet das 160MHz Bandbreite. Da heutzutage ale Geräte Sampling-Scopes sind, muß weiterhin die Abtastung die 10te Oberwelle auch noch vernünftig erfassen können, was in etwas 10 Abtastungen pro Sinuswelle benötigt. Bei 160MHz wären das dann 1,6GHz. Ein Scope mit 200MHz Bandbreite und 1...2GHz Abtastrate wären da also angemessen. Ein weiterer Punkt ist der Tastkopf. Gemeinhin haben die auch eine Bandbreite. Nehme ich als Beispiel den Tastkopf meines Scopes, der hat 350MHz Bandbreite (bei 10:1 Einstellung). Die Resulierende Bandbreite ergibt sich aus der Wurzel der Summe der Qaudrate der Anstiegszeiten. Rechnet man das durch bleiben 173MHz überalles. Damit wird der 16MHz Clock noch als Halbwegs gutes Rechteck dargestellt. Sollen auch noch einigermaßen zuverlassige Signal- oder Timing-Analyse gemacht werden, ist weniger unsinnig.


    Das klingt jetzt recht hart, meine eigenen Erfahrungen bestätigen das aber. Insbesondere, wenn Fehler gesucht werden, ist ein aussagekräftiges Meßsignal ein MUß, alles andere ist unbefriedigend und eher Kaffesatzleserei. Das von Dir also erwähnte Meßgerät mit Scope ist also mehr ein "Signal-ist-da" Tester, für den Elektriker bestens geeignet, für Messungen in Digitalschaltungen aber nur sehr bedingt geeignet. Zieher eher in Betracht, ein Scope mit integriertem Logic-Analysator zu kaufen. Gerade dieser ist im digitalen Bereich äußerst hilfreich. Etwas mehr Geld solltest Du also schon mal einplanen. Schau mal bei CONRAD bei der DS1000 bzw. DS2000 Reihe vorbei, dort gibt es entsprechende Gräte. Deren Logic-Analysatoren tasten mit 500MHz bis 1GHz ab !, das ist notwendig, ansonsten gibt es im Bereich der Flanken starke Timing-Unsicherheiten, die nicht erwünscht sind - man will Fehler durch schmale Pulse ja schließlich auch finden können.



    Cheers

    Kurt

  • DRVVEC unter ZPM3 anpassen

    Alles wird gut... :sunny:


    Ich habe jetzt einfach das lx-[1|3|4].com aus dem Z3COMs.ZIP genommen und das noch einmal ausprobiert. Damit klappt es anstandslos (???, exkl. 4). Gut - ich bin da grundsätzlich pragmatisch. Wenn das LX es tut, dann bleibts dabei. Aus dem ASM-File von LRUN23 hat sich nichts ergeben. Ein Text wie 'ZCPR3' gibt es da nicht, folglich beschwert sich da jemand anderes.

    Wie leicht zu erkennen, es geht, sogar mit der Typ3-Variante.

    Code
    00:49 A15:ROOT>lx-3
LX, Version 2.2  (Type 3 at 8000H)
 Syntax: LX [/] [-[dir:]library] command_line
 (Use "/" option when chaining from ARUNZ default alias)
00:49 A15:ROOT>

    Typ4 geht definitiv nicht, wie man sieht:

    Code
    00:35 A15:ROOT>lx-4 -zutils peek1 100

00:37 A15:ROOT>

    LX-4 meint 'kein Kommentar' und enthält sich einer weiteren Äußerung - das sagt aber auch schon das ZPM3-Manual. Also alles ok.


    LX1_LX3.zip


    Cheers

    Kurt


    PS: Motto des heutigen Tages: 'Leg dich nicht mit Zotan an ...'

  • DRVVEC unter ZPM3 anpassen

    So langsam glaube ich an Geister..., LRUN20.COM & LRUN23.COM steigen beide wegen angeblich fehlendem ZCPR3 aus. Ich kann leider nicht mehr nachvollziehen, was gewesen ist. Von LRUN23 liegt der ASM-Code vor, den werde ich mir morgen mal ansehen. Vielleicht findet sich was, damit der Grund für die Meldung verständlicher wird. So ist alles nur Kaffeesatzleserei...


    Cheers

    Kurt

  • DRVVEC unter ZPM3 anpassen

    Stelle gerade fest, das LRUNZ rumzickt mit:

    Code
    20:13 A15:ROOT>LRUNZ -ZUTILS PEEK1 100
LRUNZ3  Version 3.0

Requires ZCPR3!
20:16 A15:ROOT>

    Keine Ahnung mehr was ich da letztens spät abends gemacht habe...


    Also zurück auf LOS und noch mal von vorn. ZSHOW behauptet für den CCP etwas mit 3.4 Die zum testen von LRUNZ302 benutzte ALIAS.CMD ist leider untergegangen - Kopierfehler... Was für eine Eigenschaft von ZCPR3 ist den hier so wichtig, das der ZCCP nicht kompatibel genug ist ?

  • DRVVEC unter ZPM3 anpassen

    Moin Fritz,

    Zitat von fritzeflink

    Welche Libraries mit Z-Utils hast du denn ?

    ich habe mir das Manual "The Z-System User's Guide" zur Hand genommen (ab Seite 78) und dann alles aus 'z3coms.zip' und 'z-utils.zip' anhand der Beschreibung zusamenkopiert was mir hinreichend sinnvoll erschien (ohne dabei auf Details zu achten wie *.com|*.3om und ob das wirklich im Nachgang funktioniert). die Datei 'command.lbr' ist deshalb auch als experimentell zu sehen. Da muss ich noch genauer durchtesten. In einer groben schnelldurchsicht zeigten einigen Kandidaten denn auch 'Unwilligkeiten' wie komentarloses Beenden, gemecker wie 'das ist kein Z-System (???), ZCPR3[.3] nicht gefunden und auch systemhänger mit notwendigem Hardware-Rset um den Rechner neu zu starten. Diese Kandidaten werde ich noch aussortieren. Vielleicht findet sich da im 2ten Durchgang besseres (jetzt funktioniert ja die Z3Help).


    Hier die zip's zum selbst experimentieren:

    Z-Utils-Package.zip