Hello, Guest the thread was viewed3.4k times and contains 36 replies

last post from dmantione at the

Uridium-Modul mit speicherbaren Hiscores

    Noch etwas zur Nacht...


    Ich hätte gern ein Uridium Modul bei dem die Highscores auf dem Modul gespeichert werden. Ich weiss, das kriege ich mit 'nem KFF auch hin aber darum geht es ja nicht immer. ;)

    Habe dann überlegt wie ich das einigermassen günstig umsetzen könnte. Dabei bin ich bei den, relativ neuen, AVR Dx Controllern hängen geblieben.


    Zum Schnuppern habe ich mir einen AVR32DD28 besorgt und ihn zusammen mit einem 4MBit Flash auf ein Protoboard von Polyplay gebraten. Das sieht dann so aus:


    Vorne: Hui!



    Hinten: Shyce! 8o



    So ist das halt bei Prototypen. Der 4-Pin Connector ist der UPDI-Port (ISP).


    Der Controller läuft mit dem internen OSC, max. 24 MHz (erstmal unkalibriert) und verfügt über ein paar konfigurierbare LUTs, ähnlich einem FPGA, in denen man ein bisschen Glue-Logic unterbringen kann. Wirklich nur ganz wenig. Aber es reicht um IO1, RW und A1 zu verknüpfen und so ein paar Takte in der ISR zu sparen. Wenn ich mich nicht verrechnet habe ist das Read-Timing zu schaffen. Ob das wirklich funktioniert? Muss der OSC evtl. doch kalibriert werden? ISR oder doch Polling Loop? Ich hab keine Ahnung aber dafür habe ich die Teile ja zusammengelötet.


    Das namenlose Modul soll (weitestgehend) Magic Desk kompatibel sein. Zum Daten Speichern stehen 256 Byte internes EEPROM zur Verfügung. Nicht viel, reicht aber erstmal.


    Register Map könnte so aussehen:


    $DE00 : Magic Desk Register

    $DE01 : Flash & LED Control

    $DE02 : Memory Status & Control

    $DE03 : Memory FIFO Data


    Die ersten beiden sind write-only, die letzten beiden read-write Register.


    Das Flash soll komplett "von aussen" programmierbar sein. Ich hab halt keinen Programmer und muss mir irgendwie helfen. Daher klatsch ich mir als nächstes aus einem Pi Pico, einem Level-Shifter und 'nem Modul-Connector eine Testumgebung zusammen. Mal schauen ob ich da überhaupt was zum Fliegen bekomme.

    das ist sehr interessant, würde ich gerne mehr drüber erfahren, ich denke das es einen eigenen Fred Wert wäre.

    lame-zock-opa als Ersteller

    controlport2 als Admin

    was meint Ihr dazu

    Vielen Dank für die Ausgliederung, controlport2 .

    Quote from fongo2k

    Sehr interessantes Projekt. Gefühlt sind 24 MHz viel zu langsam, ähnliche Projekte (wie das KFF) arbeiten ja mit einem wesentlich höheren Takt. Aber was weiß ich schon, ich drück dir die Daumen.

    Ja, ich bin mir da auch wirklich unsicher. Zumal auch schon andere Leute ähnliches probiert haben.


    Meine naive Überschlagsrechnung ist:


    Sync der Control Signale nach der LUT -> 2cc

    max. IRQ Latency -> 8cc

    IRQ disable -> 1cc

    Datenbus treibend schalten -> 1cc

    FIFO Daten (liegen im einen der vielen Register vor) auf Datenbus ausgeben -> 1cc


    Macht 13cc. Bei einer Cycle-Time von ca. 42ns -> 546 ns

    6510 Read Access Time (Tacc) = 575ns max. @ 1MHz


    Knappes Höschen, zumal noch das Delay der PLA für das Dekodieren des IO1 Signals und das Register to Port Delay vom AVR fehlt und vermutlich noch einiges mehr. Sorgt man dafür, dass der AVR im Idle sich in einer rjmp-Loop befindet, reduziert sich die IRQ Latency um einen Takt, glaube ich. Trotzdem knapp und mit unkalibriertem OSC vermutlich nicht zu machen. Mit dem AVR bin ich am Port-Limit. Nix mehr frei. Da muss dann schrittweise ein Adress LSB vom Flash herhalten und entsprechend umfunktioniert werden. Bei Verwendung des AVR32DD32 entspannt sich die Lage etwas, da 3 Port-Bits mehr, allerdings TQFP32 und nicht Lochraster konform.


    Evtl. bleibt nur die MD Funktion und etwas LED blinken übrig. Sehr spannend, ich hab da tierisch Spass dran.

    Quote from lame-zock-opa

    Bei Verwendung des AVR32DD32 entspannt sich die Lage etwas, da 3 Port-Bits mehr, allerdings TQFP32 und nicht Lochraster konform.


    Evtl. bleibt nur die MD Funktion und etwas LED blinken übrig. Sehr spannend, ich hab da tierisch Spass dran.

    Der AVR64DD32 würde bei gleicher Bauform sogar den SRAM auf 8kB und Flash auf 64kB verdoppeln

    Quote from Focko

    Der AVR64DD32 würde bei gleicher Bauform sogar den SRAM auf 8kB und Flash auf 64kB verdoppeln

    Eigentlich wollte ich, zumindest erstmal, auf dem internen EEPROM speichern, da 100.000 Schreibzyklen. Das Flash hat nur garantierte 10.000. Hat jemand von Euch damit Erfahrungen gemacht? Reichen 10.000 bis zur Rente+15 Jahre? Vermutlich schon, oder? :D Zugriffe aufs EEPROM sind halt etwas einfacher zu handhaben. Schade ist, dass es nur 256 Byte EEPROM sind und das bei allen Typen der Familie. Die Uridium Highscores belegen, mit etwas Trickserei, unter 64Byte.


    SRAM ist nebensächlich von der Sicht würde auch 'n AVR16DD32 reichen. Den mit 4kByte habe ich schon zur Sicherheit genommen. Man weiss ja nie.

    Quote from Hucky

    Ich hab ein Modul mit HS-Save für das Spiel Magic Math gebastelt.

    Kannste dir ja mal angucken.

    Habe ich, zugegeben nur beiläufig, verfolgt. Habe allerdings auch keinen Schaltplan in Erinnerung. (Habe selbst aber auch noch keinen :D) Was mir daran gefällt ist, dass es ohne x-fach schnellere MCU auskommt und dadurch alles in allem authentischer ist. Was mir nicht gefällt sind die "vielen" Bauteile. Ich hätte das alles ganz gerne in einem TFW8B Stumpy Case. OK, das klappt vielleicht mit SMD. CPLDs sind einfach zu teuer und die Tools zu schmerzhaft.

    ich bin noch dabei den Eintrag für meine HP zu basteln 😬

    Die Sammelbestellung hast du offenbar verpennt 😀

    Quote from lame-zock-opa
    Quote from Hucky

    Ich hab ein Modul mit HS-Save für das Spiel Magic Math gebastelt.

    Kannste dir ja mal angucken.

    Habe ich, zugegeben nur beiläufig, verfolgt. Habe allerdings auch keinen Schaltplan in Erinnerung. (Habe selbst aber auch noch keinen :D) Was mir daran gefällt ist, dass es ohne x-fach schnellere MCU auskommt und dadurch alles in allem authentischer ist. Was mir nicht gefällt sind die "vielen" Bauteile. Ich hätte das alles ganz gerne in einem TFW8B Stumpy Case. OK, das klappt vielleicht mit SMD. CPLDs sind einfach zu teuer und die Tools zu schmerzhaft.

    SMD bin ich raus.

    Wenn du die HS auf dem Atmel speichern willst wirst du das Spiel wohl "etwas" umfangreicher patchen müssen 🤔

    wird bei Deiner Platinen-Version nicht eine Batterie benötigt zum Speichern der HighScores?

    ja

    CR2032