Posts by Manawyrm

    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.

    und wenn er das gefixt hat, schreib ich hin, dass der Code in Nepal nicht funktioniert, die haben tatsächlich UTC+5:45... :whistling: :D

    (hab das nicht tatsächlich getestet und da er nach Minuten der Zeitzone fragt, würd ich sogar fast erwarten, dass das klappt)


    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 :P

    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:

    Code
    1. $ echo -n JBSWY3DPEHPK3PXP | base32 -d | xxd -ps
    2. 48656c6c6f21deadbeef

    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.

    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...

    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.

    Das heißt, du hast dir einen neuen VIC besorgt, uraufgesteckt und er lief wieder?

    Wo hast du den Chip denn her, neu bestellt oder aber aus einem alten Rechner?

    Genau! Ich hab vorher selbst nochmal mit dem Scope verifiziert, dass keine wilden Spannungen oder komischen Signale (Buskonflikte, etc.) anlagen, sah aber alles gut aus.

    Nur deswegen hab ich mich getraut, dort den anderen Chip einzusetzen :)


    Den 6561 hatte ich noch in meiner großen Sammlung von ICs, entweder kommt der von einem Amateurfunkflohmarkt (z.B. ehemalige Interradio) oder aus so einem Pollin-Zufällige-ICs-Sortiment.

    Da hatte ich damals auch meine ganzen Z80's, U880, etc. her ^^


    Der neue VIC-1 hat jetzt natürlich auch einen Kühlkörper spendiert bekommen, er soll ja lange und gut leben :D

    Hallo,


    ich versuche gerade mit einer guten Freundin ihren VC20 wieder zum Laufen zu bringen.

    Eine richtige VC20 Ecke haben wir ja nicht, deswegen frage ich mal ganz dreist hier?



    Fehlerbild ist:

    - Rahmenfarbe vorhanden, wilde Bildfehler, keine Zeichen erkennbar (siehe Foto)

    - Rechner läuft korrekt (BASIC wird ausgeführt, VIC-1 kann angesprochen werden, LOAD von Datasette klappt)



    Alle gesockelten Chips wurden einmal entfernt und mit Kontaktspray wieder eingesetzt.

    Das Netzteil wurde getauscht und mittlerweile liegen an allen Chips direkt 5.0V an (statt vorher 4.7V).


    Ein Entfernen des Charakter-ROM bringt keine sichtbare Veränderung der Anzeige.


    Habe dann ein kurzes Programm geschrieben, welches an 0x1800 ein neues Charakterset hinlädt und den VIC auf diese Adresse umschaltet. Dieses Programm im Emulator getestet (ROM-Image kaputt gemacht, nach Laden meines Programmes ist die Ausgabe wieder OK).

    Programm dann in ne .wav konvertiert und per Datasette in den Rechner geladen. Programm läuft, Rahmenfarbe blinkt und der Sound quietscht (wie im Programm angegeben), aber der Bildschirminhalt geht von random zu leer über, anstatt dass das Charakterset aus dem RAM angezeigt wird.


    Folgende Chips müssten OK sein:

    - Character-ROM (weil entfernt)

    - CPU (weil Programme laufen)

    - RAM (weil Programme laufen. ... Macht der VIC auch einen Memory-Check beim Boot, wie der 64er?)

    - Kernal und Basic-ROM (weil BASIC korrekt ausgeführt wird)


    Verdächtige für mich:

    - VIC-I (6561)

    - Logik-ICs (z.B. die 74LS245 Bustreiber zwischen VIC und Adress/Datenbus?)


    Vorschläge, wo man jetzt am besten weitersucht?


    Hier nochmal als Stichwörter einige Details:

    - Platinenversion: VC20 (CR), PAL (keine ASSY sichtbar/gefunden?).

    - Gerät ist unmodifiziert.

    - Netzteil ist ein Eigenbau, der Trick mit den 2 Steckernetzteilen.

    - Fehler tritt ohne zusätzliche Hardware ständig auf.

    - Keine Chips werden (ungewöhnlich) heiß. Der Rechner nimmt 930mA auf der 5V Schiene auf.

    - Ja, Multimeter vorhanden, Speicheroszilloskop und Logikanalysator nicht nur bei Manawyrm, nicht bei der Besitzerin.

    - Löterfahrung ist vorhanden


    Vielen Dank für alle Hinweise!