Hallo Besucher, der Thread wurde 6,4k mal aufgerufen und enthält 39 Antworten

letzter Beitrag von Mike am

VIC-2020 MINIMON Cartridge

  • Läuft der Minimon ohne ROMs? Vermutlich nicht, weil der Hardware-Init fehlt (VIC z. B.)?

    Ins BASIC durchstarten sollte der VC-20 schon noch. MINIMON nutzt allerdings auch nur KERNAL-Routinen, und keine aus dem BASIC-Interpreter.

    Und die Abfrage der Vektoren?

    Da ist mir nicht ganz klar was Du genau meinst. Beim Start durch SYS ändert MINIMON den BRK-Vektor in $0316/$0317 auf seinen Break-Eintritt (PC, Status, Register, Stackpointer wegschreiben) und den NMI-Vektor in $0318/$0319. Letzterer hält sich selbst und den BRK-Vektor bei einem BASIC-Warmstart durch STOP/RESTORE aktiv.


    Sonst müsste da noch eine Version für den Kernal-Sockel her. ^^

    Die 2 KB kriegst Du aber nur freigeschaufelt, wenn Du sowohl die Tape- als auch die RS232-Routinen entfernst. Durch letzteres ist's aber auch Essig mit Remote-Debugging.


    Die Frage ist aber auch, was Du mit MINIMON in einem halbtoten Rechner machen willst, was mit einem dedizierten Deadtest-KERNAL nicht geht.



    Da macht schon eher eine Version von MINIMON Sinn, die sich bei $8800..$8FFF im Character-ROM versteckt, und zwar so, daß nur die CPU den Code sieht, der VIC aber immer noch auf den Klein-/Großschrift-Zeichensatz zugreifen kann. :D

  • Ich meinte MINIMON alleine, ohne alle ROMs. Da muss er dann bei FFFC/FFFD den Startvektor hinterlegt haben. Aber ja, wozu. Stimmt eigentlich.

    Da macht schon eher eine Version von MINIMON Sinn, die sich bei $8800..$8FFF im Character-ROM versteckt, und zwar so, daß nur die CPU den Code sieht, der VIC aber immer noch auf den Klein-/Großschrift-Zeichensatz zugreifen kann. :D

    Auch eine schöne Idee. ^^

    "Wenn du überredet, ermahnt, unter Druck gesetzt, belogen, durch Anreize gelockt, gezwungen, gemobbt, bloßgestellt, beschuldigt, bedroht, bestraft und kriminalisiert werden musst. Wenn all dies als notwendig erachtet wird, um deine Zustimmung zu erlangen, dann kannst du absolut sicher sein, dass das, was angepriesen wird, nicht zu deinem Besten ist." - Quelle unbekannt.


    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.

    "Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.

    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.


  • [... MINIMON im Character-ROM ...] Auch eine schöne Idee. ^^

    Das braucht nur einen schnellen 2764 im Adaptersockel, mit VA12 und VA13 auf /CS und /OE - sowie SPhi2 von geeigneter Stelle des Mainboards auf A12 des EPROMs. Das EPROM wird mit folgendem Inhalt belegt:


    $0000..$07FF: Großbuchstaben/Grafik (SPhi2 = 0, d.h. VIC dran)

    $0800..$0FFF: Klein-/Großbuchstaben (SPhi2 = 0)

    $1000..$17FF: Großbuchstaben/Grafik (SPhi2 = 1, d.h. CPU dran)

    $1800..$1FFF: MINIMON (SPhi2 = 1)

  • So, jetzt mal die Gretchenfrage an (Stand dieses Beitrags) Dierch-Jentz, emulaThor, aitsch, oobdoo, knusis, Freak, kinzi, -trb-, HouseOfPain, Goodwell, Paradroid und Parser, die anders als Jotta sich noch nicht weitergehend geäußert haben - bin ich mit dem Entwurf der Hardware überhaupt auf einer Linie mit welcher der informierte potentielle Benutzer überhaupt was anfangen kann bzw. möchte?

    Ich habe diesen Beitrag als 'Projektvorstellung' verstanden und fleißig mitgelesen. Da ich technisch nicht so fit bin wie viele andere hier kam auch keine Antwort meinerseits sondern 'nur' ein Like. Das Projekt gefällt mit gut und ich wäre auch ein potentieller Nutzer aber du hast noch keine Bezugsquelle genannt. So eine Karte selbst herstellen und mit einem EPROM bestücken könnte ich nicht.

  • Ich würde ja sagen: "Beware of feature creep" und "diminishing returns". Für mich wäre die Minimon-Cartridge das ideale Ergänzungs-Modul zu bestehenden Erweiterungen wie MegaCart, Penultimare, FE3 usw. Der Speicherbereich $9800-$9fff ist perfekt gewählt, da es nur kaum eine Handvoll anderer Software gibt, die diesen Bereich nutzt. Den Minimon an eine andere Stelle im Speicher verschieben zu können, ist dann auch praktisch nie nötig und dafür hardware-technisch Aufwand zu betreiben meiner Meinung nach Overkill. Der Freeze-Reset zur Umgehung des Modulstarts ist in Verbindung mit dem Monitor meiner Meinung nach das Killer-Feature :-) Schön ist auch die Möglichkeit, in den $9800-$9fff-Bereich eigene Software zu flashen, wie z. B. einen Fastloader. Alles in allem, wüsste ich nicht, was man noch sinnvoll an der Cart ergänzen könnte ohne dass die Komplexität/Preis unnötig erhöht wird.

  • Ich habe diesen Beitrag als 'Projektvorstellung' verstanden und fleißig mitgelesen.

    Über den Schritt Projektvorstellung im Sinne von "Anfrage zur Ideensammlung" bin ich schon lange hinaus.


    Wenn ich einen frühesten Zeitpunkt benennen sollte, wo mir die Idee kam, einen Monitor für den VC-20 in den I/O-Bereich zu stecken, dann könnte ich ein Posting im Denial-Forum von 2014 angeben.


    2 KB Platz um neben Hex-Dump-Anzeige und -Änderung, Register-Anzeige und -Änderung, Programmstart und BRK-Handler und Laden/Speichern (das ist in etwa der Funktionsumfang von TinyMon) auch noch den Direkt-Assembler und Disassembler plus noch Verschieben/Vergleichen/Suchen/Füllen unterzubringen, das ist schon eine Herausforderung.


    Ende 2017 hatte ich dann den Software-Teil des Projekts gestartet und Mitte 2018 war die Firmware dann fertig. Neben dem eigentlichen Quellcode umfaßt das Projektverzeichnis noch dutzende Textdateien mit Seitendokumentation, in denen die Funktionsweise aller Routinen noch mal detailliert ausgeführt ist, plus ein Journal in dem sorgfältig alle Änderungsgründe für alle Builds (35 Stück in der Zahl) aufgeführt sind. In der Summe stecken da ca. 100 Stunden drin.


    Anfang 2019 gab es dann den ersten Hardware-Prototypen auf Basis einer +3K-RAM-Erweiterung. Der sollte testen, daß die Logik zur Ansteuerung eines EPROMs im I/O-Bereich richtig funktioniert. Diese Cartridge war dann auch im harten Einsatz bei der Revision 2019. :)


    Zeitgleich hatte ich in Denial das erste Posting dazu geschrieben. Da kam recht zeitnah das Angebot von einem Foren-Mitglied, das ganze in eine eigene Cartridge zu bringen und das brachten wir dann Anfang 2020 auf den Weg. Leider hatte derjenige so seine ganz eigene Agenda, die mir erst klar wurde, als das Teil-Projekt schon recht weit fortgeschritten war, und die mir nicht paßte (das ist noch nett ausgedrückt) und ich mußte da die Notbremse ziehen. Einen Zwischenentwurf aus dieser Zusammenarbeit konnte ich aber als zweiten Prototyp fertigen und damit zumindest schon mal die I/O-Umschaltung zwischen Monitor und Cartridge im durchgeschleiften Cartridge-Port testen.


    Der jetzige Stand ist also bereits das Ergebnis eines längeren Entwicklungsprozesses und es sind einige Erfahrungswerte aus aktueller Nutzung eingeflossen.


    Ich würde ja sagen: "Beware of feature creep" und "diminishing returns".

    Keine Sorge. Firmware und Hardware stehen auf solider Basis. Ohne zureichenden Grund ändere ich da absehbar nichts mehr. :)


    Die zuvor angebrachte Anfrage zur Relozierbarkeit ist ja bereits geklärt - eine RAM-Erweiterung plus ein kleines Support-Tool reichen ja schon. Es gab auch noch in PN die Nachfrage nach einer integrierten Dezimal/Hex-Umrechnung. In MINIMON selbst ist für sowas kein Platz mehr, wenn es bei 2 KB Größe bleiben soll, aber als transientes Utility geht (fast) alles.


    [...] ich wäre auch ein potentieller Nutzer aber du hast noch keine Bezugsquelle genannt.

    In einem vorigen Beitrag hatte ich ja bereits erwähnt, daß ich absehbar nicht dazu kommen werde, in eigener Regie eine Kleinserie in Sonn- und Feierabendstätigkeit zusammenzubauen und zu verkaufen. Wenn jemand hier dazu einen Vorschlag hat, immer her damit!

  • Anfang Juni hatte ich MINIMON hergenommen, um das Spiel "Get More Diamonds" dahingehend zu verbessern, daß man jetzt unendlich viele Leben hat, statt am Anfang nur 3. Es gibt zwar Extraleben in den Levels (dargestellt als Herzen), aber die Schlüssel-Tor-Rätsel sind auch so schon knifflig genug.


    Tools die vergleichbares auf anderen Systemen/Konsolen leisten, benutzen häufig folgende Methode um die Speicherstelle herauszufinden, wo die Anzahl der Leben gespeichert ist - entweder um diese Anzahl direkt zu erhöhen oder um die Befehle auszuschalten, welche die Anzahl der Leben auf Null runterzählen: direkt am Anfang wird das Spiel ge-freeze-d, die Anzahl eingegeben und daraus eine Liste von Kandidaten-Adressen generiert. Nach Wiederanlauf wird ein Leben verloren und nach erneutem Freeze die Liste abgeprüft, wo da jetzt die Anzahl minus 1 drinsteht. Dieses Vorgehen wird solange wiederholt, bis das Ergebnis eindeutig ist. Auf einem Rechner mit limitiertem Speicher ist diese Methode aber nicht sinnvoll einsetzbar.


    Wenn man GMD spielt, fällt einem recht schnell die reduzierte Bildschirmgröße von nur 16x16 Zeichen auf. Die erste Textzeile zeigt die Punkte, die Anzahl der Leben und noch andere Sachen an. Wir können annehmen, daß die Anzahl der Leben als Bytewert gespeichert ist, möglicherweise in der Zeropage. Jetzt den Code danach händisch zu durchkämmen ist einigermaßen umständlich - aber es schadet sicher nichts, wenn wir uns erstmal in ASCII-Ansicht einen Überblick verschaffen:



    Hier wurde zunächst das Spiel geladen, dann MINIMON gestartet und dann das transiente ASCII-Dump-Tool aus Beitrag #8 hier im Thread geladen.


    Mit +24K RAM oder mehr geht der BASIC-Speicher von $1201 bis $7FFF, und GMD will sogar eine +35K-Erweiterung! Den erneut angezeigten Registerdump ändern wir um, so daß PC=$02A3 (Startadresse des Tools) und $AC=12 ist ...



    ... womit nach G die Speicherseite $12xx angezeigt wird:



    Das liefert uns gleich den ersten Hinweis - die Adressen $1221 bis $1230 enthalten die "Blaupause" für die Punkteanzeige!


    Jetzt ist es schon recht wahrscheinlich, daß auf diese Blaupause mit einem register-indizierten Befehl zugegriffen wird, mit entweder $1221 oder $1220 als Basis-Adresse. Mit dem Befehl H 1200 7FFF 21 12 bekommen wir 3 Treffer und wir disassemblieren bei diesen Adressen, minus 1 um den Opcode des Befehls mit drin zu haben:



    Gleich der erste Treffer bei $3254 bringt uns schon weiter: das ist die Schleife, welche die Statuszeile beim Start des Spiels in die erste Bildschirmzeile kopiert. Wir halten fest, daß die Anzahl der Leben im Bildschirmspeicher an der Adresse $1008 zu liegen kommt. Als nächsten Schritt suchen wir darum nach einem Speicherbefehl auf $1008 - etwa STA $1008.


    MINIMON zeigt aus Platzgründen in einem Disassembly die (bis zu 3) Hex-Bytes zwischen Adressen und Mnemonic nicht an, aber mit einem "Test-Assembly" plus dem M-Befehl kommt man trotzdem an das gewünschte Suchmuster.


    Wir assemblieren STA $1008 testweise nach $033C. Das ist der Anfang des Tape-Buffers, da stört das gerade keinen. :) Heraus kommt $8D $08 $10 als Suchmuster. Mit H 1200 7FFF 8D 08 10 erhalten wir nur einen Treffer und disassemblieren noch ein paar Befehle davor, die uns zeigen wo die Anzahl der Leben gespeichert ist - ein scharfer Blick zeigt uns den Befehl LDA $3F an Adresse $3275:



    Das nächste Suchmuster ist für DEC $3F (wobei wir der Form halber ein BRK hinterher schieben, um das "Testassembly" hinter dem DEC-Befehl aufzuräumen), dies sind die zwei Bytes $C6 und $3F. Mit dem entsprechenden H-Kommando erhalten wir wiederum nur einen Treffer, bei $3338, ...



    ... und das Disassembly zeigt uns hier ganz klar einen typischen "Test auf Null Leben übrig". :D


    Bleibt nur eins: wir ersetzen den Befehl DEC $3F durch 2 NOPs, beenden MINIMON und fragen BASIC ganz lieb, wohin die äquivalenten POKEs hingehen sollen - und mit welchem Wert:



    Damit schalten die zwei POKEs POKE13112,234:POKE13113,234 unendlich viele Leben in GMD frei. Die POKEs werden nach LOAD und vor RUN eingegeben.



    Nachtrag: die Info bezieht sich auf das erste Release des Spiels vom 6. Juni 2022 (+/-) . Mittlerweile gibt es eine Version 1.5 - da liegt der Befehl DEC $3F möglicherweise woanders.

  • Eine der klassischen Anwendungen eines Monitors ist dann noch die Erzeugung einer Sicherkeitskopie, hier mal gezeigt am Beispiel von "Las Vegas 20" von Anirog, von Tape auf Diskette. Das Spiel kommt mit erzwungenem Autostart und Turbotape daher, natürlich sind auch STOP und STOP/RESTORE gesperrt.


    Also, Ärmel hochgekrempelt und die etwas härteren Bandagen ausgepackt: statt mit LOAD die Turbotape-Routine durchstarten zu lassen, laden wir erstmal nur den Header ein, mit SYS 63407 und starten dann MINIMON mit SYS 38912:



    Die Turbotape-Routine steht jetzt bereits im Tape-Buffer, hinter dem Dateinamen. Inspizieren wir mal den Tape-Buffer ab $033C:



    Die $03 in $033C bedeutet, daß die folgenden Start- und Endadressen immer zum Laden der Nutzlast hergenommen werden, selbst dann wenn die Sekundäradresse 0 ist! Das bedeutet, selbst ein einfaches LOAD + [RETURN] erzwingt den Autostart. Die Nutzlast wird von $0300 (inklusive) bis $0334 (exklusive) geladen. In diesem Bereich liegen die BASIC- und KERNAL-Vektoren, damit "übernimmt" das Turbotape den Rechner. Das können wir jetzt natürlich nicht zulassen, und darum laden wir die Nutzlast erstmal nach $1300, indem wir die Highbytes der Start- und Endadresse bei $033E und $0340 auf $13 ändern:



    Außerdem brauchen wir ja für später auch noch die richtige Einsprungadresse in die Turbotape-Routine. Mit SYS 62980 laden wir jetzt die Nutzlast nach $1300 ...



    ... und inspizieren dieselbe jetzt ab $1300:



    Oho! Die Turbotape-Routine macht hier gerade mal kurzen Prozeß mit den BASIC- und KERNAL-Vektoren! Ungefähr alle Vektoren werden mit $0351 überschrieben - deutlicher kann man die Startadresse der Turbotape-Routine nicht mitteilen.


    Kleines interessantes Detail am Rande: die KERNAL-Tape-Routinen laufen ja interrupt-gesteuert. In $0314/$0315 wird die richtige Adresse für das Laden "am Leben" gehalten - normalerweise steht da bei SAVE ein anderer Wert drin! Die Nutzlast wurde also auf ähnliche Weise getrennt vom Header auf Band geschrieben, wie wir gerade Header und Nutzlast getrennt geladen hatten.


    Jetzt werfen wir einen scharfen Blick auf die Turbotape-Routine ab $0351. Wenn wir sie jetzt einfach mit G 0351 starten, wäre noch nichts gewonnen, denn sie startet ja dann direkt zum Spiel durch:



    Die Unterroutine in $03AF initialisiert die Turbotape-Routine, danach lädt sie mit JSR $03D8 einzelne Bytes von Band. Die ersten vier Bytes sind Start- und Endadresse im Speicher, erstere geht als laufender Zeiger nach $C1/$C2, letztere geht nach $2D/$2E ... wird hier etwa ein BASIC-Programm geladen?


    Das Disassembly fortgesetzt:



    Tatsächlich. Die Befehle von $0397 bis $03A0 enthalten eine Variante des Standard-Idioms um von Maschinensprache aus ein BASIC-Programm zu starten (BASIC-Programm re-linken, CLR, TXTPTR auf Start des BASIC-Programms setzen, Einsprung in Interpreter-Schleife).


    JSR $FD52 bei $0386 stellt die KERNAL-Vektoren wieder her, das gleiche macht JSR $E45B bei $038C mit den BASIC-Vektoren. Zuvor kümmert sich JSR $FDF9 bei $0383 noch um die VIA-Register. Damit ist soweit alles wieder im Lot. Allerdings dreht die Turbotape-Routine noch an $0328 (Vektor zur Überprüfung der STOP-Taste) und $0302 (BASIC-Warmstart-Vektor) - das wollen wir gerade nicht, und darum überschreiben wir mit F 038F 0396 EA diese unerwünschten Befehle mit NOPs.


    Zur Kontrolle wird der BASIC-Speicher noch mit $2A vorbelegt (F 1203 7FFF 2A) und als letzte Vorbereitung darf die Turbotape-Routine jetzt in $03A0 mit JMP $9800 zu MINIMON zurückkehren. :D



    G 0351 und Trommelwirbel ...


    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :

    :


    ... da ist MINIMON wieder und das Spiel ist jetzt im Speicher. Schauen wir mal in $2B..$2E BASIC-Start und Programm-Ende (bzw., Start der Variablen) an:



    $2D/$2E zeigt auf $47F2 und der Speicherdump zeigt ein $2A in $47F2 nach zwei Nullen in $47F0 und $47F1, das sieht ja ganz gut aus. Also, zurück ins BASIC, ...



    ... mit SAVE machen wir schnell die Sicherheitskopie, mit LIST sagen wir mal kurz dem BASIC-Stub "Hallo!" und mit RUN gönnen wir uns jetzt eine nette Runde "Einarmiger Bandit". :)

  • Braucht der I/O Bereich nicht ein paar Speicherzellen um die Register zu retten?

    Der Registerdump wird im unteren Stackbereich, in den Adressen $0110..$0116 gesichert.

    Preis für eine Vorserie?

    Einen Preis kann ich im Moment nicht sinnvoll angeben, da bislang nur Einzelexemplare gebaut worden sind und ich nicht dazu kommen werde, in Eigenarbeit eine Kleinserie zu fertigen.

    Stammt der Monitor von Jim Butterfield (Tiny Mon)?

    Dazu habe ich hier im Thread in Beitrag #5 bereits genaueres geschrieben. Unmittelbare Vorlage war der TEDMON der 264er-Serie. Neben Anpassungen der benutzten Zeropage-Adressen und Anpassungen an die verkürzte Zeilenlänge beim VC-20 habe ich noch eine Menge Arbeit reingesteckt um ein paar richtig dicke Bugs (u.a. Stack-Overflows in zwei Routinen, der Range-Check bei den Branch-Befehlen war kaputt, u.a.) und Unzulänglichkeiten (z.B. überlappende Transfers gingen unfallfrei nur zu niedrigeren Adressen hin, u.a.) im Original auszubügeln.


    Tinymon geht gerade mal als Hex-Dump-Speicher-Monitor durch (mit Registerdump, Go-Befehl und BRK-Funktionalität, o.k.) aber er wartet eben nicht mit einem Direkt-Assembler und Disassembler, Hunt, Fill und Compare/Transfer auf. Gemeinsam mit VICMON und HESMON hat Tinymon zudem das Problem, daß eine Anpassung des Zeropage-Gebrauchs beim Port von der PET/CBM-Serie zum VC-20 nicht erfolgt war, und darum alle drei Monitore kräftig den Arbeitsbereich des BASIC-Interpreters in der Zeropage zertrampeln.



    P.S. http://sleepingelephant.com/ip…in/bb/viewtopic.php?t=660 ;)

  • Zitat

    Das war ja von mir. :D


    Inzwischen sind unsere Kinder 10 Jahre älter und ich nehme mir jetzt die Zeit für den Vic20.


    Der NeuMon war schon ein gewaltiges Projekt, funktionierte aber nur noch in Verbindung mit dem 65SC802.

    Der kleine Bruder der Super CPU und ich hörte damals leider damit auf.


    (Platzmangel im dem CBM 8032, EPROM wurde übervoll).


    Nun, ich melde einfach mal Interesse an. 8o


    Es gibt noch 2 Kollegen die Interesse haben.

    Platine kann ich nachfragen.


    Thomas

  • Ich hätte hier auch konkret Interesse an einem Stück.
    Wenn die nötige Menge noch nicht beisammen ist, nehm ich auch Zwei :-) (falls es das beschleunigt)

  • Ich hätte hier auch konkret Interesse an einem Stück.

    Danke! Ich nehme das noch mal als Bestätigung zu deinem Beitrag #13 auf. :)


    Im Moment existieren ein paar handverlesene Exemplare, in welchen das in meinem Beitrag #10 genannte Hardware-Update drin ist, und die auch funktionstüchtig getestet sind. Die sind bereits vergeben und ich komme hoffentlich in den nächsten Tagen auch dazu, sie an die Adressaten zu verschicken.


    Darüber hinaus gilt aber jetzt immer noch die von mir bereits angesprochene Grundproblematik: über diese "Null-Serie" hinaus werde ich nicht dazu kommen, in Sonn- und Feierabendtätigkeit (vorzugsweise an verregneten Tagen) eine Kleinserie der Karte zu bauen. Für Lösungsvorschläge bin ich nach wie vor dankbar.

  • Verstehe ich natürlich.
    Ich nehme an das Projekt ist nicht open source?


    Du könntest zb nackte Platinen und gebrannte ROMs verkaufen, den Rest muss sich der geneigte Softwareentwickler selber besorgen und löten.

    So würde das geistige Eigentum in deiner Hand bleiben und der Kosteneinsatz (Platinen und ROMs auf Halde legen) wäre trotzdem hoffentlich nicht existenzgefährdend.


    Oder hab ich die Komplexität des Moduls jetzt anhand der Bilder unterschätzt?

  • Ich nehme an das Projekt ist nicht open source?

    Derweil ist es so, ja. Es wollte mich bereits jemand mit einer Zwischenversion des Projekts über's Ohr hauen - zum Glück hatte er nicht alle Daten, um mit dem Vorhaben erfolgreich zu sein.

    Du könntest z.B. nackte Platinen und gebrannte ROMs verkaufen, den Rest muss sich der geneigte Softwareentwickler selber besorgen und löten.

    Eine Variante wäre die teilbestückte Platine (alle SMD-Bauteile) und der Käufer lötet "nur" noch die bedrahteten Bauteile (ZIF-Sockel, Platinen-Steckverbinder, Schiebeschalter, ...) selbst auf. Neben einem vollständigen Lizenz-Nachbau wäre das eine mögliche Variante.

    Oder hab ich die Komplexität des Moduls jetzt anhand der Bilder unterschätzt?

    0805 und teilweise 0603 SMD-Hühnerfutter ist nicht jedermanns Sache. An einer Stelle muß die Schaltung verhindern, daß da versehentlich ein Oszillator im UKW-Bereich anspringt ... ;) ... ganz so trivial, wie die Platine auf der Gesamtübersicht im Startbeitrag vielleicht aussehen mag, ist sie nicht.

  • Schon krass, dass es im Hobbybereich immer wieder kriminelle Energie gibt. Als ob man davon reich werden könnte…


    SMD bestückt wäre natürlich super, würde die THT Selbstlöter nicht ausschließen.

    Ich würde aber auch die nackte Platine nehmen wenns das einfacher für dich macht und es dir den Aufwand spart.