Gerade erschienen, ziemlich interessantes Video zum Entstehungsprozess eines neuen SID-Emulators:
[Externes Medium: https://www.youtube.com/watch?v=pePq68HaI7M]
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
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.
das secret base64 decoden und hex darstellen isses nicht
aber fast: der secret ist base32 kodiert. etwas ungewöhnlich, aber für URLs ganz praktisch, weil Gross/Kleinbuchstaben da keine Rolle mehr spielen.
Für SMD-Arbeiten kann ich auch das echte (!, es gibt leider viele Fakes, die dann einfach nur Vaseline oder schlimmeres sind) Amtech NC-559-V2-TF empfehlen.
Ich hatte meine letzte Tube von LTronics EU (via Amazon), das war echtes.
Das Zeug ist echt magisch beim Verlöten, inbs. wenn Heißluft im Spiel ist. Leider ziemlich übler Preis, aber das lohnt sich durchaus.
Wenn eine Produktionsdatei mitgeliefert wird zu den Gerber, dann ist die Sache für jeden erhältlich.
So ist es, ich mache das bei allen meinen Projekten mittlerweile so
Jetzt fehlt mir nur noch ein einheitliches Austauschformat für die anderen Boardeinstellungen (z.B. ob eine Platine Goldbeschichtet sein soll, etc.), damit dass die Besteller nicht mehr händisch eintragen müssen (und dabei Fehler machen könnten) und dann ist der Nachbau von allerlei Projekten echt ein Kinderspiel...
JLCPCB meinte ich, die machen jetzt auch Through-Hole Teile und nehmen externe Bauteile an.
PCBWay ist gut für größere Batches.
Mit Aisler bin ich schon mal böse auf die Nase geflogen, da halte ich Abstand von.
Es ist mehr Kritik an mir selbst, denn ich könnte das nicht nachbauen.
Ich will hier jetzt keine Werbung machen, aber ein bekannter Hersteller von Platinen aus Fernost bietet neuerdings auch an, solche Teile direkt von Mouser und co. zu bestücken.
Wenn die blöde Chipknappheit vorbei ist, brechen da goldene Zeiten für uns Hobbybastler an
Ja, das ist die beste Chance, sich was kaputt zu machen!
Ja, aber doch nicht beim VC20. Die 9V AC werden ja nur für den User-Port und die Datasette verwendet, mehr passiert damit nicht. Power-Sequencing ist da völlig egal.
Beim C64 finde ich gerade im VIC und SID Datenblatt auf Anhieb nichts, was ein direktes Problem darstellen würde, weder in den Absolute Maximum Ratings noch den Operating Conditions sind Parameter genannt, die groß problematisch wären. Klar, 9V vor den 5V zu haben ist schöner, damit der Bus nicht über Body-Dioden die Chips versorgt ist ordentlicher, aber hey.