Wenn Du Dich in Bascom einarbeiten willst, kann ich Dir den Kurs vom ELV-Journal (6/2012-3/2015) empfehlen.
https://github.com/MCUdude/MicroCore mit der Arduino-IDE ist der vernünftigere Weg in 2025.
BASCOM darf langsam mal sterben -- vor 20 Jahren war das noch ganz lustig, aber propritäre, käufliche Toolchains gehören echt ins Museum 
HSCSD/CSD ist wirklich tot... hätte ich mal vorher hier gefragt:
Ich mein -- falls du die alte Karte nicht brauchst, meine Museumlaptops freuen sich immer und mein Museums-2G-Netz kann auch CSD 
habe mir mal gerade sowas bestellt... mal schauen.. ob es in einem XP Notebook noch funktioniert..
Jein.
Ja, funktionieren wird es in deinem Notebook noch.
Die schlechte Nachricht ist aber, dass die GSM-Netze "CSD" aka Circuit Switched Data, die Technik für leitungsvermittelte Datenübertragung (also quasi Modemanrufe über GSM) alle in den letzten Jahren abgeschaltet haben.
In DE gibt es leider keinen Provider, der es noch anbietet. Im EU-Ausland findet man vereinzelt noch Provider, die es unterstützen.
Hintergrund: Bei "Modemanrufen" über GSM werden keine Modemtöne als Sprache übertragen, stattdessen werden die Daten digital verschickt und beim Provider steht eine "IWF" (Interworking Function), die dann den eigentlichen Modemanruf (oder auch ISDN-Verbindung) zum Ziel aufbaut und dort dann die Bits übermittelt. Genau diese Funktionen sind aber jetzt leider abgeschaltet.
GPRS wird in den Netzen noch angeboten, kann aber die Karte (meines Wissens nach) noch nicht.
SMS und Telefonanrufe sollten damit gehen. Für Datenübertragung muss man sein eigenes kleines Museums-2G-Netzwerk aufspannen.
Falls du einen normalen (Musik-)Kassettenrekorder hast und den an den PC angeschlossen bekommst, kannst du
https://wav-prg.sourceforge.io/ nehmen, eine .tap Datei aus dem Internet besorgen und die in eine .wav Datei konvertieren, die du dann "nur noch" auf die Kassette überspielen musst.
Fies, ein 250425 ohne PLA-Sockel... Das ist echt nervig. 
Aber ja, tausch den zweiten RAM-Chip auch noch, kommt ja aus genau der gleichen Charge, also gut möglich, dass der auch hin ist.
Gerade erschienen, ziemlich interessantes Video zum Entstehungsprozess eines neuen SID-Emulators:
Nanu, Posts editieren geht gar nicht mehr? Seltsam...
Anyway, hier noch ein Link zu der Story: https://catskull.net/gameboy-boot-screen-logo.html
daß sich schlechte Kontakte in einem kaputten Start-Logo repräsentierten? Mglw. so als Vorab-Check?
Ja, das war quasi Absicht.
Die Story war wohl, das Herstellen von Drittanbieter-Modulen war an sich legal, aber Nintendo wollte das natuerlich (siehe Video Game Crash 1983) verhindern.
Deswegen hat Nintendo in jedes Modul eine Kopie des Nintendo-Logos (markenrechtlich geschuetzt) eingebaut, welche von der Cartridge gelesen wurde.
Beim Start vergleicht dann das ROM in der CPU das Logo mit dem richtigen Logo und gibt nur dann das Spiel frei.
Ein unlizensiertes Drittanbietermodul waere dann eine Markenrechtsverletzung und Nintendo koennte rechtlich vorgehen...
Hm, man könnte als Techdemo z.B. mal den Fake86 mit cc65 probieren zu bauen.
Wenn man sich geschickt anstellt, könnte ein SD2IEC (vllt. mit JiffyDOS als C64 Kernel) sowohl als HDD/FDD Image wie evtl. sogar als Swap dienen
Wird zwar dadurch noch viel langsamer, würde aber auf einem originalen C64 laufen.
Hui! Das nenne ich mal ne ordentliche Menge Sockel.
Da würde ich persönlich auch bei jedem IC mal die Pins etwas anrauen und die Sockel alle samt mit Kontaktspray reinigen.
Oh, der Autor war flott unterwegs und hat den Bug schon gefunden und behoben:
https://github.com/classilla/t…0b218961c8f075fadf910L492
Neue Version 0.5.1 ist jetzt auch verfügbar:
https://github.com/classilla/totp-c64/releases/tag/0.5.1
Und jap: Funktioniert und rechnet die richtigen Codes aus
und wenn er das gefixt hat, schreib ich hin, dass der Code in Nepal nicht funktioniert, die haben tatsächlich UTC+5:45... 
(hab das nicht tatsächlich getestet und da er nach Minuten der Zeitzone fragt, würd ich sogar fast erwarten, dass das klappt)
https://github.com/classilla/totp-c64/issues/1
Hab mal hingeschrieben
Wenn ich raten müsste, bestimmt irgendwo ein Off-by-One drin. Zeitzonen sind schon immer echt ein Traum beim Arbeiten 
Nein, statt 17:00 hab ich 08:00 eingegeben, weil die Jungs in -8 sind und wir in +1
Ah!
Ich hab's am Laufen! Ich glaub da ist wirklich ein Bug in der Zeitzonen-Routine.
Wenn man eine US-Amerikanische Zeitzone (in meinem Fall PST, -8) eingibt und dann die Lokalzeit in PST (und unser Hex-Secret wie oben beschrieben) nimmt, dann gehts!
Das generierte Passwort müsste man dann ja auch irgendwo verwenden können.
Das ist ein Generator für einen Industriestandard namens TOTP.
Damit kannst du dich z.B. bei PayPal, Google, etc. ausweisen.
Du bekommst dazu dann beim erstmaligen Anlegen so einen Hex bzw. Base32 Code angezeigt (für die Nutzerfreundlichkeit wird das als QR-Code gemacht), den scannst du dann (üblicherweise) mit deinem Handy ab und das Handy zeigt dir dann einen 6 stelligen Pin an, der von der Uhrzeit abhängig ist.
Wenn jetzt ein Angreifer deinen Account bei PayPal, Google, etc. hacken möchte, muss er den ständig aktuellen (30 Sekunden Gültigkeit) 6-stelligen Pincode kennen.
Dieses C64 Programm sollte diese Pincodes nun errechnen. Es errechnet auch welche, aber sie stimmen leider nicht 
Ich bin auch nicht sicher ub ich die Uhrzeit in UTC oder in lokaler zählung eingeben soll.
Weil er nach der Zeitzone fragt, würd ich stark von Lokalzeit ausgehen.
Sonst könnte er sich den ganzen Kram mit der Zeitzone sparen, denn berechnet wird am Ende ja mit UTC.
Ich hab leider auch gerade nicht die Muße durch den Assemblercode durchzuschauen. Bei mir wäre so ein Projekt eher ein Fall für cc65 (oder das neue llvm-Backend für die 6502... hmm ).
Ich würde an dieser Stelle annehmen, dass es eher was mit der Uhrzeit zu tun hat.
Ich hab einige Kombinationen von Zeitzonen sowie Little und Big-Endian Eingabe (jeweils Wordweise) der Hex-Nibbles probiert, kam aber bisher immer die falsche Ausgabe raus.
Bin so vorgegangen:
die Konvertierung von base32 -> klappt damit, "Hello!" und dann (in hex) deadbeef ist da in dem Secret kodiert.
Aber das C64 Tool gibt tatsächlich die falschen TOTP Secrets aus. Nicht ganz sicher, warum... *hm*
Spannenderweise spricht der Autor in seinem Blogpost von "keys should be provided in hexadecimal or as binary data, not base 40.", aber base 40 wird für TOTP eigentlich nicht eingesetzt.
