Welche "Linux 32-bit Installation mit einigen recht alten Paketen" ist das jetzt genau?
Devuan ASCII - müßte Debian 9 (32-bit) sein. Bin z. Zt. im Dänemark-Urlaub, deshalb die späte Reaktion.
Beiträge von kmg
-
-
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.
-
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 ?
-
wenn man nichts sucht und doch was findet..., im Web gelistet - die RC-BOX:
-
...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.
-
Also mal langsam: ich habe nicht geschrieben, daß das wirklich ein Aprilscherz ist.
Stimmt, Heft 4 schon, jedoch hast Du nirgends erwähnt, dass das ein _Sonderheft_ Nr. 4 ist.
Auf mich macht die Schaltung trotzdem den Eindruck, als wenn die Redaktion den interessierten Leser ein wenig verschaukeln wollte - also Aprilscherz. Trotz Sonderheft (wurde vielleicht aus der regulären April-Ausgabe übernommen). 
Wegen der Begehrlichkeiten ... ich glaube, daß das so mit das letzte ist, was man an einem C16 wirklich vermissen würde - Krach bei jedem Tastenklick.
Ich bin auch mehr für eine leise Tastatur, aber wenn ich daran denke, was ich 1984 so alles in mein Video-Genie eingebaut habe...
Und wenn doch, dann kann man das auch ganz einfach in die Interruptroutine mit reinhängen,
Schon, aber das ist ja gerade der Charm der abgelichteten Schaltung: Kein Spezialwissen, einfach zusammenlöten, +5V, den Draht und ein einzelnes Signal dran und fertig ist der Klick. Diese umwerfende Einfachheit ist ja gerade der Speck, mit dem man den Computer-Nerd fängt. Und dann diese 20cm Antenne, eine geniale idee. So sieht gleich jeder, das man die Tastaturklick-Erweiterung eingebaut hat. Sehe ich als eine weitere Leimspur für den C16-Besitzer.
Es ist leider schon zu lange her, aber es wäre schon interessant zu erfahren wie die damalige Community diese Erweiterung aufgenomen hat. Glaube nicht, das dass gänzlich unbeachtet geblieben ist
-
aus dem Heft 4 von 1987
Heft 4
- Schelm ist, wer Böses denkt..., Eine Hex-Wüste als April-Scherz wäre bei der Clientel wohl eher erwartet worden denn in Form von Hardware - getreu der Annahme, das sich damit nur wenige so gut auskennen, das der Gag gleich durchschaut worden wäre. Und dan am Ende die langen Gesichter, wenn nach mühevollem Einbau das Ganze nicht so recht klicken will. So wird Fehlersuche geübt...Verdächtig war mir schon , das die Antenne nach außen gelegt werden mußte, da ansonsten nur jede 2te Taste eine Tastenklick erzeugt - eine nicht so recht einsehbare Randbedingung. Trotzallem, allein die Vorstellung, wie aus dem C16 so ein langer Mäuseschwanz heraushängt, finde ich amüsant genug. Und dann die "Schnitzeljagd" nach Pin-6..., es soll ja auch nicht zuu kurzweilig (für die Kids) sein.
Rückgefragt: Was waren damals die begehrtesten Hardwarehacks für den C16 - war das ev. der Tastenklick ? Der aber, richtig implementiert teuer/schwierig gewesen ist und so diese 'Billiglösung' wegen ihrer Einfachheit sofort große Begehrlichkeit hervorgerufen hat ? Wodurch es wiederum besonders leicht war, die Leser auf's Glatteis zu führen ? Soetwas klappt ja meist nur dann richtig gut, wenn Wunsch und Wirklichkeit eine hinreichend große Divergenz aufweisen, also nicht lange über- sondern gleich losgelegt wird.
-
Derartige Schaltungstricks sind mir aus dem Bereich AC-gekoppelter DC-chopper Messverstärker bekannt. Diese Verstärker benutzten so verschaltete Transistoren, da diese dann eine sehr niedrige Uce-rest hatten. Ein Umstand der für die Verarbeitung von kleinen zu messenden Spannungen und der Messgenauigkeit entscheidend ist. Im Artikel wird ja auch auf die Besonderheiten dieser Verschaltungsweise hingewiesen. Ich bezweifle aber, das im Einstiegsartikel diese Sache von Bedeutung ist. Die Summer funktinieren auch noch noch mit 3V ganz gut, da sind 100mV Uce-rest bei korrekter Bschaltung eher unerheblich, von 10mV ganz zu schweigen -> Frage 2 ist immer noch vakant...
-
Die 1. Frage ist zuallererst mal: Was für ein Signal liegt an Pin-6 ? Die 2. Frage lautet: War der Tag der Veröffentlichung der 1. April des Jahres ?
Ein 20cm langer Draht sammelt 50Hz Netzbrumm aus der Luft auf. Mit welcher Amplitude hängt vom Wert des Abschlußwiderstandes an der Basis ab. Die Zenerdiode sowie der Transistor sind gesperrt. Darüber hinaus empfehle ich ein Steckbrett, ein Scope zum messen, sowie ein 5V-Netzteil. Wenn klar ist, was für ein Signal an Pin-6 anliegt, hilft sicherlich ein programmierbarer Funktionsgenerator weiter. Alles andere ist Kaffeesatzleserei. Mein Verdacht geht zur 2. Frage
-
Mal davon abgesehen, das der NPN spannungsmäßig verpolt ist (Plus am Emitter, Minus am Kollektor, gehört eigentlich anders herum), ist das Konzept bemerkenswert. Mangels C16 kann ich das nichts überprüfen - wenn's funktioniert, tolle Idee. Die Antenne liefert wohl die für den Beep notwendige kapazitive Einkopplung, damit der Transistor aufgesteuert wird. Wie gesagt, einzig die Polung der 5V bereitet mir Kopfzerbrechen.
-
So, noch schnell die aktualisierte Version (von Guidol) geflasht und ausprobiert - löppt ! Ich habe alle *.bin files in einen Ordner 'bin' verschoben und noch zusätzlich ein Script für's flashen (Linux) sowie das 'esptool.py' hinzugefügt. So sind Doku und Daten schön getrennt. Windows-Nutzer müssen sich die Kommandozeile aus dem Arduino-Flash-Log (von Guidol) im bin-Ordner entsprechend extrahieren. Da ich die Richtigkeit der Extraktion nicht kontrollieren kann (mangels Windows), habe ich dem nicht vorgegriffen. Der Datenteil (bin-files) steht nämlich etwas abseits der Kommandozeile. Wie der Teil anzuhängen wäre übersehe ich nicht zweifelsfrei.
-
Mit der FabGL Bibliothek habe ich wohl zwischen meinen nun 3 verschiedenen Arduino-Umgebungen vertan.
Also, mit der FabGL-0.8 und meiner Arduino-IDE-V1.8.9 (Linux) schmeißt der Compiler Fehlermeldungen auf den Schirm, sowas wie "multiple definitions...". Ich habe den Fehlerscreen nicht kopiert - jedenfalls ist da mit meiner Arduino-Installation scheinbar nichts zu machen.
Wenn Du nur Text brauchst ist auch der VGATextController gut, da er mehr Zeilen(32?) liefert - aber weniger Text-Attribute oder Fonts.
Das werde ich für den Anfang ins Auge fassen, denn neben dem Terminal-Thema ist da auch noch der Hardware-Handshake beim Multicomp. Mittels Google habe ich den Verdrahtungsplan für ein Null-Modem-Kabel mit Handshake-Loopback gefunden. Werde also jetzt ersteinmal das Kabel zusammenlöten und testen - schaun 'mer mal, es regnet ohnehin grad' wieder...
-
guidol Danke für den link - sehr hilfreich.
Martin Irgend etwas mache ich hier falsch, ich habe schon wieder reichlich Fehlermeldungen. In Deinem letzten Archiv ist die terminal.cpp nicht enthalten, ist das richtig so ? Im readme steht, das alle 4 (terminal.* & tekterminal.*) ins ~/arduino/libraries/FabGL/src Verzeichnis sollen (und die alten sichern). Ist doch richtig ?
Die Arduino-IDE ist ok, eine Probe-Compilierung des ANSI-Terminals läuft einwandfrei durch. Der Cache in ~/.aduino15/cache ist leer, Guidol hatte da von unschönen Erfahrungen im Forum berichtet.
die Hardware steckt zwar schon im Gehäuse, ich muß jedoch mit dem Scope nochmal die abgehende RS232-Schnittstelle überprüfen. Da kommt noch nichts raus (mit ANSI-Terminal).
-
Hallo Martin,
vielen Dank für Deine Erklärungen, der Teufel scheint sehr im Detail zu stecken - damit habe ich nicht gerechnet. Ich hatte schon länger nach einer Terminal-Emulation mit Grafik-Möglichkeiten gesucht und war deshalb sehr davon angetan, als mir das TekTerm auf dem TTgo_VGA32 über den Weg lief. Sollte Dir die Integration noch einmal gelingen, ist es wohl in Anbetracht der Probleme angeraten, sich alle beteiligten (und zusammenpassenden) Softwarepakete zu archivieren, sollte eine Neuinstalation wegen defekter/neuer Hardware anstehen. Ich drück' schon mal die Daumen für's gelingen.
Gruß
Kurt
-
hhmmm, unter Linux findet sich nur ein Ordner ~/.arduino15/cache (kein build oder so), dessen Inhalt habe ich einmal gelöscht, ändert aber nichts - die Fehlermeldungen bleiben. Ansonsten kann ich nirgendwo weiter was verdächtiges finden. Die Linux-Version der Arduino-IDE könnte sich durchaus in dieser Sache anders verhalten. Ich hatte mitguidol schon konferiert, er konnte mein Problem mit den aktuellen Bibliotheken zumindest reproduzieren. Deshalb gehe ich davon aus, das dass Problem echt ist. Meine C(++)-Kenntnisse sind so minimal, das ich hier nur auf gut Glück hacken könnte, mit sehr geringen Erfolgsaussichten. Trotzdem Danke für den Hinweis, jeder Versuch zählt.
-
Nachdem ich schon Anfang des Jahres mir 2 TTgo-VGA32 V1.4 besorgt habe, bin ich nun zur Tat geschritten und habe das TektronixFabGLTerminal.ino compilieren wollen. Die Einrichtung der IDE entsprechend dem readme war etwas holprig, es ist das erste mal, das ich mich so intensiv mit der Arduino-IDE einlasse. Aber letztlich war dann alles soweit für die Übersetzung.
Installiert sind die Bibliotheken FabGL-1.0.2 & FreeRTOS-10.4.3-8. Der erste Run mit 'Überprüfen/Kompilieren' wirft dann leider ein gutes Dutzend Fehlermeldungen auf den Schirm. Versuche mit Fabgl-1.0.0 & -1.0.1 ergeben die gleichen Fehlermeldungen. An FreeRTOS in älteren Versionen habe ich mich nicht mehr versucht. Als Hardware ist ESP32_Pico_Kit (hatte auch ESP32_Dev_Module probiert) ausgewählt. Hat aber keine Besserung gebracht.
Die Fehlermeldungen im Anhang. Vielleicht kann sich Martin das einmal ansehen, ich komme da nicht weiter.
-
Also ich wäre bei der nächsten Aktion auch dabei. Ich bin mit 1 Tasse mit dem Vereinlogo zufrieden. Da ich etwas weit im Norden sitze, wären wohl die Kosten für Tasse + Versand die Lösung.
-
Ich denke nur, es sollte auf dem Grundgerät laufen,
ohne spezielle Erweiterungen, die ja nicht jeder besitzt.
Schon klar, das war ja worauf ich hinaus wollte - mal sehen, wie weit ich komme (bin mit dem System-Handbuch für meinen Z80-Rechner gerade fertig geworden - damit ist wieder Luft für anderes...).
-
danke für die Dokumentation
Keine Ursache, gern geschehen.
-
Genau genomen ließe sich das Programm dahingehend optimieren, dass die Daten des jeweiligen Sternbildes in DATA-Zeilen ablegen werden. Das hätte den Vorteil, diese ohne Änderungen am Programm ergänzen zu können. So, wie es jetzt geschrieben ist, erinnert der Code mehr an einen Brute-Force-Hack. Aber genau das war ja der Einstiegsgedanke - was läßt sich verbessern...
Vielleicht sollte man als erstes die Forderung "Grundhardware" streichen und dahingehend abändern, daß alles auf einem ASCII-Bildschirm stattfinden soll (meine Kiste sieht nicht aus wie und ist auch leider gar kein Commodore-Rechner). Farbe nur insofern, als das es nur 3 Farben (ROT, GRÜN & BLAU) und ev. in max. 3 Helligkeitsstufen sein sollen (mehr ginge auf meine Büchse ohne hin nicht). Damit dürfte auch ein Commodore-Rechner klar kommen. Sofern es machbar ist, könnte man auch bei den oberen 127 Zeichen der ASCII-Tabelle einige Zeichen durch Symbole mit unterschiedlich großen Punkten ersetzen, um so die unterschiedliche scheinbare Größe der im Sternbild beteiligten Sterne (annähernd) wiederzugeben. Das mal als Vorschlag, soll ja auch nicht zu kompliziert werden. Wie man das in den DATA-Statements unterbringt, wäre noch zu überlegen.
-
Danke für die Bestätigung meiner Annahme. War schon interessant, die Namen der Sternbilder zu markieren. Obwohl mir die meisten bekannt sind, kam ich nur einmal auf 60% (in dem Fall hatte ich wohl gut geraten), die lateinischen Namen sind mir leider nur von den prominentesten geläufig - sei's drum...
-
Hab' das mal an MBASIC für CPM adaptiert, i.d.H. waren das notwendige Blanks eingefügen. Das PRINT CHR$(147); habe ich zu GOSUB 2280 umgeändert. Unter 2280 findet sich dann PRINT CHR$(27);"[H";CHR$(27);"[2J"; was auf dem Terminal den Bildschirm löscht. Ich gehe mal davon aus, dass das die ursprüngliche Absicht war.
Cheers
Kurt
-
Das selbst-compilieren habe ich nach Deinem Muster probiert - hat soweit geklappt
Im HT-C Handbuch steht auf den Seiten 3...4 'Getting started' wie man das typische Hallo-World compiliert. Dort steht auch der Hinweis, wie im Falle von FLOAT's der Compileraufruf aussehen muß.
Chers
Kurt
-
Ich bin etwas spät dran, wir hatten hier einen Ausfall des Internets in 3/4 von Geesthacht. Geht alles seit ein paar Minuten wieder.
Geht runstart/runend nur auf Deinem System?
Ja, leider. Ich habe auf meinem System speziell für Zeitmessungen eine 32-bit Zähler mit 1ms Clock. Den kann ich für solche Messungen über 'RUNSTART' & 'RUNEND' einsetzen.
Ich musste fuer die korrekte Darstellung die Anzahl von Zeichen von 84 auf 80 reduzieren
War mir auch aufgefallen. Da ich den Run über den Laptop im Terminalfenster ausgeführt hate, reichte es das Fenster entsprechend breiter und höher aufzuziehen. Die ausgegebenen Zeilen sind auch mehr wie 30, aber dank der 'Elastizität' des Fensters kein Problem... Soweit mein C-Verständnis reicht, müßte in Zeile 2 der Laufbereich der Schleife angepaßt werde auf -15 ...+15, wenn es ganz in ein 80x30 Fenster passen soll. Aber dann scrollt das Ganze immer noch hoch, wenn der Lauf fertig ist. Der Scroll-Vorgang/Zeilenumbruch selbst hat bei mir keinen erkennbaren zusätzlichen Zeitaufwand verursacht, das macht ja alles der Laptop.
Cheers
Kurt
-
Ich habe Deine Post mal zum Anlaß genomen, den HT-C Compiler auf meinem System zu benutzen und den 3-zeiler compiliert:
A0:>C -V mand.c -LF
A0:>runstart;mand;runend
Compilieren geht recht schnell, die Laufzeit von MAND.COM ist 1m 22.865s. CPU-Takt 25MHz. Von der Laufzeit sind 65ms ab zu ziehen, da für die Zeitberechnung ein transientes Programm benutzt wird (RUNEND.COM benötigt Ladezeit von der SD-Karte).
Cheers
Kurt
