Posts by kmg

    Wenn Du die MMU auf einem Experimentierboard aufbaus, zuerst die VCC und GND Leitungen verlegen. Die 100nF Stütz-C's an den VCC-Pins gegen Masse für jedes IC nicht vergessen (absolut wihtig). Die Versorgung muß frei von Störungen sein, also keine Peaks oder Einbrüche, ansonsten kannst Du jeden Schaltungsaufbau wegen nicht nachvolziehbarer Fehlfunktionen vergessen. Falls Du mit dem Tastkopf ran gehst und bei den Flanken klingeln bzw. große Über-/Unterschwinger mißt, der Masseklipp am Tastkopf ist eine Induktivität undbekannt dafür, das Messsignal in dieser Form zu verfälschen. Sehr gute Messergebnisse erhälst Du, wenn die Signalmasse zum Messen per kurzen Draht vom Massering an der Tastkopfspitze abgenommen wird (die Signalmasse möglichst immer am Ort des zu messenden Signal abnehmen ! Auf dem Steckbrett besonders wichtig). Das ist etwas frickelig, vermeidet aber besagte Probleme. Sollten bestimmte Signal wegen langer Signalleitung auf der Platine dennoch Probleme machen, kann auch ein Widerstand (27R...47R) direkt am Signal-Ausgang in Serie zur Leitung als Dämpfung der Leitungsinduktivität/kapazität Wunder wirken. Derartige Dämpfungswiderstände helfen auch, solltest Du die MMU-Platine auf's Steckbrett stecken, um den erweiterten Rechneraufbau zu testen. Die Steckbretter haben leider eine relativ hohe Kontaktinduktivität gepaart mit ~5pF Schaltkapazität (meine Erfahrung). Das macht die Bretter nicht unbrauchbar, man muß es nur berücksichtigen, dann geht es meistens.

    Sicher gehen die auch, der CPU-Takt muß dann nur niedriger gewählt werden, damit die RAM's nicht überfahren werden. Beim 6809 NitOS9 CocoDEV-Rechner von Coco-Daddy kommt ein 512k 10ns SRAM zum Einsatz, was wiederum 25MHz CPU-Takt ermöglicht. Sind die SRAM's langsamer, wie Deine 20ns Typen, liegt der max. mögliche Takt vielleicht bei 16MHz. Aber selbst das bedeutet immer noch ein beachtlich schnelles System - also kein Grund zur Sorge. Man sollte nur nicht unbedingt mischen, denn der langsamste bestimmt den 'Takt'.

    Es gibt bei kiCAD im Schaltplan-Editor unter DATEI -> plotten im dann auf-poppenden Fenster die Möglichkeit den Schaltplan in diversen Formaten zu plotten. Das pdf wird im Stammverzeichnis des Projektes abgelegt. Geht schnell und unkompliziert für einzelne Schaltpläne oder alle des Projektes. Hat auch den Vorteil, wenn es Problme mit Symbolen gibt, im pdf nachsehen zu können (unabhängig von kiCAD), wie der Originalzustand sein soll.

    Ich hab' mal bei utsource nach dem MC6829 gesucht und ... nichts gefunden, auch eBay glänzt durch Unkenntnis. Der Chip ist bekanntermaßen nicht zu bekommen, womit Du leider der einzige bist, der am Ende das Projekt realisiert. Gibt es da wirklich keinen anderen Weg ?


    Ich bin vor ein paar Tagen auf ein Projekt namens 'UniFlex' gestoßen. Dort kommt auch ein 6309 zum Einsatz und die Hardware besitzt ebenfalls bezüglich MMU und Betriebssicherheit einige sehr bemerkenswerte Eigenschaften. Man braucht für ein Grundsystem 4 Eurokarten und einen 19"-Einschubgehäuse. Letzteres setzt die Einstiegskosten leider schon recht hoch an. Eventuell läßt sich aus den Schaltplänen Honig saugen und ein Ersatz für den MC6829 basteln.

    Ausserdem habe die meisten unserer Geräte doch ein H-Kennzeichen

    Wenn es nur darum geht ein Anschaungsobjekt mit so original wie möglich gehaltenen Erweiterungen auszustellen, hast Du allemal recht. Ich finde es auch immer wieder spannend zu sehen, was damals für'n Aufwand betrieben wurde, um die Rechner mit Must-Have-Features aufzubohren. Da sind aber Überlegungen wie anfangs zu lesen 'Jetzt steht noch die Frage an, TTL-Grab oder CPLD. Da bin ich mir noch nicht schluessig' nicht erlaubt. Das klingt doch eher wie 'Retro' oder 'Vintage' ?. CPLD wäre dann Retro, TTL-Grab gleich Vintage. Dr. Google liefert einen Erklärungsansatz:


    "Echt Vintage oder nur Retro-Stil? ... “ Im Klartext: Vintage ist tatsächlich alt, Retro ist neu, lehnt sich aber an alte Designs an.":nixwiss:


    Ich empfehle die Münze zu werfen ::heilig::

    Das TTL-Zeug gibt es seit Jahrzehnten, und ich schätze, daß es das auch nach ein paar weiteren Jahrzenten noch geben wird.

    Fragwürig, wo doch immer mehr auf Energieeffizienz geachtet wird. TTL-Gräber saugen auch als LS erhebliche Leistung auf.

    Wenn ich mir die Lagerhaltung bei reichelt & Co anschaue, wird die Beschaffbarkeit von 74LSxx auch immer duenner bis zu null.

    Kann ich nur bestätigen. Zum Teil muß man sich aus diversen Quellen bedienen um an alles zu kommen, das Treibt die Projektkosten wegen der jedesmal anfallenden Versands unangenehm in die Höhe. Bei Kauf in China sind es außerdem die erheblichen Wartezeiten.

    Jetzt steht noch die Frage an, TTL-Grab oder CPLD.

    TTL-Grab ist zu statisch - denke dabei auch an den Entwicklungsaufwand - auch wenn sich die Grafikkarte auf einem Steckbrett aufbauen läßt. Ich tendiere mittlerweile zum Löten by Editor weil ich mir dann dieses ganze Geraffel mit Lökolben und der notwendigen Stellfläche als 'Dauerexponat' sparen kann. Den Mehraufwand durch ISE oder Quartus nehme ich da gern in kauf - ein Labtop ist schneller zusammengeklappt und weggeräumt wie wie das hantieren mit dem Testaufbau samt Scope und Meßgeräte bis endlich alles steht und läuft. Ich sehe auch für den Nachbau(er) beim CPLD ganz klar die meisten Vorteile: Da weniger Bauteile, weniger Fehlermöglichkeiten, von Problemen bei der TTL-Bauteilbeschaffung einmal ganz abgesehen.

    Dafür hat man ja im Drucker verschiedene Profile...

    Daran muß ich mich wohl erst noch gewöhnen, ist aber sicherlich der richtigere Weg.

    Also mit der pulverbeschichteten Platte war das Ablösen so was von leicht...

    Ich hatte ganz zu Anfang einen Haltewinkel gedruckt, der war in Z-Richtung 12mm hoch und auch sonst recht massiv. Soweit ich mit noch erinnere, ging der deutlich besser vom Druckbett zu lösen. Gleiches gilt für ein 5cm hohe Pyramide. Sobald die Teile einfach nur dünn sind (besagte 2mm), hilft verbiegen des Bleches nicht viel, da das Druckgut dem einfach folgt und sich nicht wie gwünscht ablöst. Das ist dann das typische Beispiel, bei dem dann nichts geht wie erwartet.


    sollte man solche Infos nicht eher im 3D-Bereich zur Verfügung stellen,

    Diesen Weckruf sollte man vielleicht erhören. Was als kurze Zwischenfrage gedacht war verselbständigt sich so langsam zusehens... Ich bin auch fürs verschieben. Titelvorschlag: "Haften eure Ausdrucke auch so fest..."

    Sieht genau so rauh wie die meinige aus. Mir kommen Zweifel, was meinen Probedruck auf der Pulverplatte betrifft. Ich werde den noch einmal wiederholen, dann aber mit etwas größerem Testobjekt, um mehr Oberfläche zu haben. Der erste war merkwürdigerweise ca. 1/10tel dicker wie er hätte sein dürfen und paßte deshalb nicht in die Nut. Kleinkram, soetwas kann man schließlich vorhalten. Aber davon unabhängig werde ich mir im nächsten Monat die satinierte bestellen und die auch testen.

    Gibt von Prusa jetzt aber auch eine satin-rauhe, das könnte was für dich sein.

    muß ich mir ansehen. Gerade bei Frontplatten ist eine leicht rauhe Oberfläche mitunter angenehmer, die Lichtreflektion ist defuser und man sieht dann (hoffentlich) die kleinen Ungenauigkeiten im Druck nicht so. Mußte Ich gerade heute erfahren, als ich nach dem Grund für Resonanzen der Druckplatte suchte, wenn der Druckkopf in der nähe der oberen Plattenkante druckte. Den leichten Druck mit dem Finger, um zu testen ob was lose ist, kann man jetzt in einer geringfügig anderen Lichtreflektion sehen.


    Bin ich nicht wirklich Fan davon.

    Hate ich heute vor dem oben erwähnten Druck getestet. Die 85°C der Druckbetttemperatur haben das Crepp leicht schrumpfen lassen und die Kanten stelten sich auf. Beim Überfahren ist der Druckkopf leicht hängen geblieben. Die Druckspur ist dann an der Stelle abgerissen. Ich konnte schlimmeres gerade noch verhindern. Für ein beheiztes Druckbett ist es sicherlich ein No-Go, auf kaltem Bett (vom CADET) ist es eine gute Lösung (mit PLA). Isopropanol ist nur zum entfetten gut, ansonsten unveränderter Klebekrampf. Es bleiben noch Spuke und Spüli :)


    Dr. Google hat mir heute auch noch offenbart, das es sogar ein Profile für den Mini+ für CURA gibt. Das Howto wie man das Profil installiert muß ich allerdings noch abarbeiten. Auf dem CADET konnte mich Cura durchaus überzeugen, aber für den ist sie schließlich auf den Leib konfiguriert.

    Ich hab noch eine 3rd-party Strukturplatte

    Von welchem Verein ist die ?, Würde ich gern mal ein Auge drauf werfen, alternative Quellen sind immer Hilfreich. Taugt die was, die magnetische Haftung auf dem Druckschlitten muß gewährleistet sein, sonst ist es nicht zu gebrauchen.

    Dieses Trennschicht-Problem zw. Druckplatte u. Druckgut hat was von Allchemie und Kaffeesatz... Der Tipp mit der Spucke ist aus dem täglichen Leben. Es soll ja haften aber auch nicht zu bodenständig sein. Ich habe hier noch 2 Rollen blaues Malercrepp liegen, mich nur noch nicht getraut es auf ein Druckbett zu kleben, welches dann auf 90°C aufgeheizt wird. Laut Datenblatt ist es dafür nicht geeignet - hat das trotzdem schon mal jemand versucht ? Was macht da ev. der Klebefilm auf dem Druckbett ? Bei einem unbeheiztem Druckbett war die Haftung auf dem Crepp gut und das Druckgut einfach davon zu trennen. Insgeheim gehe ich davon aus, das mindestens ein Druckbett versauen wird, bevor sich 'Erfahrung' einstellt. Das glatte Druckbett zeigt schon erste Verschleißspuren wie Kratzer und kleine Lunker, dort wo das PetG zu fest haftete.


    Das Thema Support-Struktur und die siche ergebende unschöne Oberfläche des Druckguts ist wohl nur konstruktiv zu lösen, indem da wo es zu sehen ist eine Art Blendplatte etc. drübergeklebt wird, sofern sich das Teil nicht so gestallten/zerlegen läßt, das supportbedürftige Überhänge vermieden werden. 3D-Druck erfordert schon ein beachtliches Toolset: Slicer, 2D/3D-CAD-Software, Reinigungsmittel/Trennmittel und einen guten Kleber für die vielen Einzelteile. Jedenfalls werde ich das mal so in mein persönliches Pflichtenheft übernehmen. Danke für die Anregungen und Kommentare.

    @zitruskeks

    Danke für die sehr hilfreichen Hinweise. Meine eigentlich guten Erfahrungen mit Überhängen und Support sind dem CADET von MONOPRICE und CURA-4.8 geschuldet. Nur der kann kein PetG und die ganzen Druckeinstellungen nach CURA zu übertragen habe ich noch nicht versucht (wenn's überhaupt sinnvoll geht).


    @csdragon

    Die Erfahrung habe ich auch gemacht. Die Haftung ist exzellent, einen 2mm dicken Ausdruck habe ich mir deswegen schon durchgebrochen. Aber Wasser und etwas Seife (Spüli ?) habe ich noch nicht versucht, werd's ausprobieren. Zum Ablösen nehm ich statt Skalpel lieber ein Schweizer Taschenmesser, ist nicht so scharf. Meine Finger sind mir auch wichtig. Mit der pulverbeschichteten Druckplatte habe ich nur einmal etwas gedruckt, die resultierende Oberfläche war doch recht rauh. Mit welcher Platte druckt Prusa eigentlich seine Teile für die Drucker aus ? Deren Oberflächenstruktur hatte ich mit der pulverbeschichteten in Verbindung gebracht.

    Moin,

    zum Thema Support habe ich da mal eine Frage. Verwendest Du PetG Filament von Prusa und wenn ja, wie gut ist bei Deinen Ausdrucken der Support vom eigentlichen Druckobjekt lösbar ? Wenn ich mit meinem Mini+ etwas mit PetG u. Support ausdrucke, ist es jedesmal ein heiden Krampf die Support-Strukturen zu entfernen. Eine weitere Frage: Wie sieht die Oberfläche des Druckobjektes aus, die auf den Suport-Strukturen gedruckt wurde ? Bei mir ist es keine geschlossene Oberfläche sondern es sind Filamentfäden, die erst in der nächsten Druckschicht eine geschlossene Fläche bilden. In den Druckeinstellungen konnte ich hierzu nichts verbesserndes finden, um das zu ändern. Der GCode wird mit dem PrusaSlicer 2.30 (Linux) erstellt.

    Die Bohrung nicht als Presspassung auszulegen ist sicherlich richtig und wichtig, denn Klebungen haben ein sehr großes Problem mit Kräften, die rechtwinklig zur Klebefläche auf die Klebefläche einwirken. Auch wenn es nicht ganz original ist, könnte es hälfen, einen Art Ringschelle an den Enden zu installieren (wie eine Überwurfmuter), welche die Kräfte beim Drehen aufnimmt und so an dieser Stelle die beiden Hälften zusammenhält und am spalten hindert. Auf die schnelle kann ich leider keine Zeichnung oder ähnliches zur Verdeutlichung anbieten - aber mit etwas Kopfkino sollte es gehen...

    Der Handgriff wird auf der Seite, die auf dem Druckbett zu liegen kommt, die Oberflächenstruktur des Druckbetts haben und damit anders sein, wie die, die als letzte Ebene auf der Oberseite gdruckt wird. Das läßt sich nur verhindern, wenn der Handgriff in der Mitteleben geteilt, also in 2 Hälften aufgespalten wird. Beide Teile wären dann anschließend zu verkleben. Ich habe mir vor längerem einen 3D-Druck-Kleber von Filamenworld (http://www.filamentworld.de) gekauft. Könnte sein, das der sich dafür eignet. PLA hat er jedenfalls ganz gut verklebt.

    Moin,

    Fritz' Test-Run mit dem SC126 hat mich dazu veranlaßt, TRANSFER auch auf

    meinem Multicomp mit ZPM3 (m. SD-Karte) einmal laufen zu lassen. Das Ergebnis

    ist in sofern überraschend, das ich der Meinung war, das ein Z180 etwas

    schneller läuft wie ein Z80. Skaliere ich z. B. das Lese-Ergebnis auf die

    36,864MHz hoch, kämen 172800 Byte/s heraus. Die Waitstates bei seinem SC126

    bremsen das ganze doch schon erheblich. Fritz, kannst Du den Test mit 18,432MHz

    ohne Mem & IO-Waits wiederholen, dann wäre ein Vergleich realistischer ?. In wie weit das BIOS

    hier auch noch 'bremsend' mitwirkt, übersehe ich nicht. Aber die LBA-Rechnung

    bei CF- oder SD-Karte dürfte da (hoffentlich) nicht so viel ausmachen.


    ###############################################################################


    Transfer, Version 2.12a, 3.12.88 CT / 07.90 A.K. (auf Multicomp mit 25MHz)


    Das Programm wird jetzt 960000 Bytes ins aktuelle Verzeichnis schreiben.


    Ist das ok ? (J/N) J


    Start schreiben, Bloecke:

    123456789101112131415161718192021222324252627282930

    Dauer: 9.00 s

    Anzahl Byte: 960000 ==> Transferrate: 106667 Byte/s


    Start lesen, Bloecke:

    123456789101112131415161718192021222324252627282930

    Dauer: 8.00 s

    Anzahl Byte: 960000 ==> Transferrate: 120000 Byte/s


    Die 960000 Byte grosse Testdatei gleich loeschen? (J/N) : J

    Könnte es ev. auch daran liegen, das manche (viele) CF-Card Adapter nicht bootfähig sind und deshalb Probleme bei der Kartenerkennung durch das OS machen ? Bei meinem P112 Rechner war es jedenfalls so. Von den 5 Adaptern die ich hatte war nur einer bootfähig und mit dem funktionierte die Kartenerkennung sowie das Booten problemlos. Die restlichen 4 waren absolut nicht zu gebrauchen, egal was ich versucht habe.


    Diese hier funktionieren bei mir:

    https://www.ebay.de/itm/402772531944


    Der Adapter hat eine Pin-Header Buchse (!), alle meine Problem-Adapter hatten einen boxed Pin-Header. Außerdem befindet sich die gelbe LED links auf dem Adapter (das ist zumindest das augenfälligste Unterscheidungsmerkmal).

    Geht eben nichts über ein "schönes" (Quick'n'Dirty) Makefile ...

    danke für's makefile. Compiliert bei mir auch anstandslos. Ich mußte allerdings noch die Diskdef's von cpmtools ins build-Verzeichnis kopieren, damit cife sich nicht wegen deren fehlen beschwert.

    Auf der Github Seite ist natürlich das ganze Projekt mitsamt Source Code und Projekt Dateien.

    Super Sache, habe aber eine bitte als nicht Software-Experte: Im Github-Archiv vielleicht eine 32-bit Version bei den Binaries mit hinzufügen (ich nutze seit Jahren eine Linux 32-bit Installation mit einigen recht alten Paketen, die es nicht mehr gibt) oder eine kurze Compilieranleitung im Readme. Ich stecke jedes mal fest, wenn bei C++ das übliche simple 'make <Makefile>' nicht ausreicht.

    Wenn Du Dich nur nach Aussen mit anderen Mailboxen verbinden möchtest, spielt DCD keine Rolle.

    Das ist schon mal gut, denn Nachverdrahten von Signalen geht nicht, da keine IO's am FPGA mehr frei sind. Als Firmware ist das ZiModem aufgespielt. Ich bin bis jetzt nur noch nicht dazu gekommen, etwas damit zu machen. Anfangs hatte ich mit der Ab-Werk-Firmware die Uhrzeit von einem NTP-Server geholt. Das hat aber nur in gefühlt 50% der Fälle funktioniert, weil beim Anmelden im heimischen Wifi-Netz die Prozedur immer mal wieder hängen geblieben ist. Das war die bisher einzige Anwendung des Wifi-Moduls.

    Wichtig ist DCD nur, wenn Du andere bei Dir "Einwählen" lassen möchtest.

    Ist nicht beabsichtigt. Macht wohl auch nur Sinn, wenn DCD einen Interrupt auslöst. Die dafür sinnige Hardware fehlt jedoch, es gibt nur den 20ms Ticker für die System-Uhr (am INT-Eingang).

    Nimm einen ESP-32,

    Der ist aber nicht so klein wie der ESP8266 und für mehr ist auf dem Board kein Platz. Ansonsten wär's keine schlechte Wahl.


    Ich habe die Absicht, als Modem-Software das ZMP1.5 zu nehmen. Mal davon abgesehen, das es etliche gibt, macht das Sinn ? Mit KERMIT werde ich nicht warm. Es gibt da auch noch ASCOM-2.2 als Kommunikationsprogramm. Gefällt mir von der Bedienung her ganz gut. Bei beiden ".txt" löschen.


    ascom22.lbr.txt

    ZMP15.LBR.txt

    Fazit: egal ob echtes Modem oder Wifi Modem mit Zimodem Firmware: ohne DCD vom Modem direkt an den SIO/2 weiter zu geben funktioniert "BYE" schlicht nicht.


    Ich hoffe ich konnte das jetzt nochmal ausführlich darlegen.

    Danke, super Erklärung. Werd' das mal als Grundlage nehmen, um meine Optionen ohne DCD zu klären, denn meine ESP826-Schnittstelle sieht leider so aus:


    Mal sehen, mit welcher Software ich die Einwahl auf dem Z80-System hin bekomme und welche Baustellen sich zusätzlich auftun, denn das BIOS kennt als physikalische Geräte nur CRT & TTY, Da ist also noch Luft nach oben...

    Nicht "klassisch" sondern per Telnet-Client unter Linux...

    Für mich nicht so ganz offensichtlich, spielt 'DCD' bei Verwendung eines Telnet-Clients eigentlich eine Rolle ? Auch: wenn ich das mit dem 'ZiModem' programmierte ESP8266 Wifi-Modul für den Kontakt benutze(n würde, Modem habe ich keines), habe ich auch kein 'DCD' zur Verfügung. Wie paßt das zusammen ?

    ...man, das ist lange her, dass ich mit einem Modem (300Bd) unterwegs war. Kann man da nicht mal die LogIn-Seiten der BBS'e so wie bei den Funkamateueren mit ihren QSL-Karten dokumentieren ? Wäre interressant und außerdem auch mal was anderes wie an Hardware oder Software zu frickeln ! ...und zudem auch was praktisches für das eigene Spielzeug.

    wenn man beim echten Z80-MBC2 den Chip fuers GPIO und den Extender/Expander bestueckt

    Das ist das grundsätzliche Problem bei der Wahl der Hardware. Wer nur mal reinschnuppern will, ist sicherlich für den Anfang mit der ESP32-Emulation eines CPM-Rechners gut bedient. Wenn's gefällt, aus dem ESP32 kann man ja später mehr machen, wird nach was passenderem gesucht. Ansonsten tun die paar Euro nicht weh.


    Was beim ESP32 als VT-100 Terminal als Serial-TTL arbeitet, könnte bei der CPM-Emulation auch ein I2c-Bus sein. Alles eine Frage des Treibers in der Emulation und welche IO's benutzt werden. Was dann als Erweiterung am I2c-Bus hängt, ist Sache des Anwenders und wie aus CPM heraus auf die IO's Zugriff genommen werden kann. Welche Einschränkungen bestehen, hängt von Programmierer der Emulation ab. Machbar ist da sicherlich vieles.

    Hmm... - da erschließt sich mir der tiefere Nutzen nicht so wirklich...

    Der Vorteil liegt in der Größe des Gesamtsystem und der enthaltene Peripherie: 8 x 7 x 2,5 cm^3. Im Gehäuse steckt der ESP32 zusammen mit einem Serial-TTL-to-RS232 Konverter. Kompakter geht es nicht und das zu einem unschlagbaren Preis von ca. €12. Da kann der Z80-MBC2 nicht mithalten - ist aber geschmacksache. Der Z80-Rechner daneben hat eine Kantenlänge von 10 x 10 x 5 cm^3 und da steckt auch schon eine Menge Hardware drin trotzdem ist er mit ca. €60 (nur Material) deutlich teurer und kann auch nicht mehr.