Modding-Thread für den neuen Competition PRO Retro

Es gibt 19 Antworten in diesem Thema, welches 2.261 mal aufgerufen wurde. Der letzte Beitrag (6. Oktober 2009 um 09:16) ist von enthusi.

  • Mahlzeit,

    Skoe hat gerade die Idee im Chameleon-Thread aufgebracht, dass man den neuen Competition PRO aufgrund seines modding-freundlichen Kabels (alle 9 Pins belegt) mit Autofeuer ausstatten sollte.

    LAAAAANGWEILIG!

    Irgendeiner von Euch Atmel-Microcontroller-Freaks sollte sich doch finden, der nen Joystick-Sequencer programmieren kann, oder? Also eine Art Aufnahme-Funktion. Ich spiele Monty on the Run, starte die Aufzeichnung mit einem der Zusatz-Buttons und langsam aber sicher läuft der Speicher voll. Wenn ich fertig bin, drücke ich wieder und der Joystick kann jetzt - wenn man die gleichen Anfangsbedingungen hat - das Spiel bis "hierhin" wieder spielen. Ist vielleicht bei einem jump&run nicht das Allerbeste, aber so einfachere Dinge wie Hot Dog bei Winter games sollten immer drin sein. Ich kenn' soooo wenige Leute, die da auf Anhieb den 10.0-Sprung hinbekommen :smile:

    So ne Bauanleitung muss es mal in der Happy Computer gegeben haben, ich erinnere mich da dunkel...

    Natürlich sind einfachere Mods auch denkbar, also Zusatz-Feuerknopf für die Atari und Sega Konsolen, Dauerfeuer und slow-motion-Funktion.

    Jens

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • Na jetzt findet sich vielleicht auch jemand, den es interessiert, das zu machen.

    Sollte natürlich nicht mehr kosten als der Joystick selbst :)

    Wenn man sich jeweils nur DeltaT und dann den neuen Zustand merkt, wäre das recht Speicher sparend (aka speichersparend).

    Denkt man an durchschnittlich 5 Zustandsänderungen pro Sekunde (was schon ein ziemliches Gerüttel ist), 1 Byte für den Zustand und 2 Bytes für DeltaT, käme man auf:
    5 * 3 = 15 Bytes je Sekunde
    1024 / 15 = 68 Sekunden pro KiB.

    Bei der Herangehensweise würde die Aufzeichnungsdauer von der Spielintensität abhängen. Falls Dauerfeuer aufgezeichnet wird, sollte dort nicht jeder Schuss einzeln gespeichert werden, sondern ein "Dauerfeuer ein"-Bit. Das Feuer-Ergebnis muss natürlich jedesmal gleich sein.

    So, nun kann jemand anderes weiterspinnen: Wie genau bedient man das?

    Edit: Gegenüber des schnöden NE555-Dauerfeuers bräuchte man hier nichtmal externe Beschaltung. Na gut, einen 100 nF Kerko oder sowas.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • Hier ist das Doom Demo Format beschrieben was schon als recht sparsam gilt, vielleicht kann das ja der geneigte Programmierer als Gedankenstütze gebrauchen:
    Bitte melde dich an, um diesen Link zu sehen.

    Die Idee, so wie ich sie verstanden habe, ist die das man einen Timer laufen lässt und sich nun einfach nur merkt, 10 ticks, Feuer gedrückt, 25 ticks, Feuer losgelassen, 64 ticks, Links gedrückt, 66 ticks, Feuer gedrückt, 100 ticks, Links losgelassen, 110 ticks, Feuer losgelassen, ....
    Wenn jetzt wenig gedrückt wird ist der Speicherverbrauch gering, bei viel gerüttel wird er schon beachtlich.

    Blog: Bitte melde dich an, um diesen Link zu sehen. - The Seventies Board: Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ein Terminal und ein Z80 :D

  • Die Idee, so wie ich sie verstanden habe, ist die das man einen Timer laufen lässt und sich nun einfach nur merkt, 10 ticks, Feuer gedrückt, 25 ticks, Feuer losgelassen, 64 ticks, Links gedrückt, 66 ticks, Feuer gedrückt, 100 ticks, Links losgelassen, 110 ticks, Feuer losgelassen, ....
    Wenn jetzt wenig gedrückt wird ist der Speicherverbrauch gering, bei viel gerüttel wird er schon beachtlich.


    Hast Du jetzt meinen Vorschlag nochmal beschrieben oder den von der Seite? Falls ersteres, ja, so hatte ich es gemeint :)

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • Ok, ich habs jetzt nicht so detailliert geschrieben, weils eigentlich keinen nachher interessiert wie es im MC gelöst wurde.

    Ansonsten Pseudo-C vorraus, ungefähr so würde ich es machen:


    Den interessanten Code hab ich mal raus gelassen weil genau dieser die Wochenend-Bastelei wird. ;)

    Blog: Bitte melde dich an, um diesen Link zu sehen. - The Seventies Board: Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ein Terminal und ein Z80 :D

  • Ah, fortschritt.

    if(lastkey==recordkey)record(); if(lastkey==playkey)play(); putkeys(lastkey);


    Keine elses? Dann führt ja record/play auch zu putkeys...

    Und die Dauerfeuertaste: Die würde ich genauso aufzeichnen wir die anderen Tasten.

    Wie wär's übrigens mit einer zweifarbigen LED, um den Record/Play-Status anzuzeigen?

    Sehe ich das richtig, das Du absolute Ticks abspeicherst (hab jetzt keine Zeit, genauer hinzuschauen)? Wenn Du dir Deltas abspeicherst und z.B. Die Ticks auf 1/100 s oder 1/50 s stellst, kommst Du mit einem Byte pro Zeitstempel aus, also 2 Bytes pro Eintrag. Dann müsste der Code aber immer spätestens nach 2,56 s einen Eintrag machen, damit die Zeitstempel nicht überläuft.

    Ich würde übrigens 1/100 s nehmen, damit man bei 1/50 s nicht im Extremfall genau hinter der Abfrage im Spiel liegt und damit einen Frame daneben.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Einmal editiert, zuletzt von skoe (10. September 2009 um 07:19)

  • Das gab es (auch?) in einer 64er...
    Ich blaettere grade fast alle nochmal durch und schreie wenn ich darauf stosse.
    Wie maechtig ist das Ding eigentlich? Evtl. ein Echtzeit RLE? Um z.B. sehr lange Pausen oder sowas zu kuerzen.

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • Evtl. ein Echtzeit RLE?


    Wenn er, wie in der reinen Lehre, nur bei Veränderungen speichert, wird dir nichts bringen :)

    Hab oben noch was dazu editiert. Das mit den 2,56-Sekunden ist wahrscheinlich in der Realität kürzer als großere Zählerwerte zu erlauben und dafür dann insg. 3 Byte pro Record zu haben.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • Doch bei allen Ruettelspielen :wink:
    Wenn man lossy RLE zulaesst, hehe - aber hast ja recht.

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • skoe:
    Genau dieses Problem der Leerpakete möchte ich ja mit den absoluten umgehen.
    Und sendkey bräuchte die anderen Tasten ja nicht weiter zu geben, ist eh nur der Prototyp des Prototypen-codes damit man gemeinsam mal eine Vorstellung bekommt wie der Code ablaufen muss und als Programmierer vom selben Ding redet.
    Wenn ich nicht schon genug andere Dinge um die Ohren hätte würd ich es ja machen...

    Blog: Bitte melde dich an, um diesen Link zu sehen. - The Seventies Board: Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ein Terminal und ein Z80 :D

  • Genau dieses Problem der Leerpakete möchte ich ja mit den absoluten umgehen.


    Auf Kosten von 50% größeren Daten (2 Bytes => 3 Bytes). In einem normalen Spiel bewegt man den Joystick ohnehin nur selten länger als 2,5 Sekunden *nicht*, es gebe diese "Leerpakete" also höchstens in Ausnahmen. Und das die Aufnahmezeit ziemlich größ ist, wenn man den Joystick gar nicht bewegt, macht die Record-Funktion nicht sinnvoller :) Deswegen sehe ich den Vorteil klar im 8-bit-Delta.

    Wenn ich nicht schon genug andere Dinge um die Ohren hätte würd ich es ja machen...


    Dito.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • Ihr könntet auch Zeitcodes variabler Länge verwenden - Bit 7 markiert, ob das nächste Byte noch dazugehört.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Ihr könntet auch Zeitcodes variabler Länge verwenden - Bit 7 markiert, ob das nächste Byte noch dazugehört.

    ...was einem primitiven runlength-encoding entspricht. Eine ähnliche Technik habe ich in der Fifo-Datenstruktur des Catweasel MK4 verwendet, dort kann man "long wait" oder "precise wait" machen. "long" wird mit einem Bit angezeigt und verschiebt den eigentlichen Wert ein paar Bits nach links. Präzision erreicht man wieder mit dem Anhängen von kurzen Waits.

    Die Idee ist natürlich der Einfachheit von Hardware geschuldet: Das hat weniger Platz im FPGA verbraucht. In Software macht es vielleicht mehr Sinn, tatsächlich mit variabler Datenlänge zu arbeiten und so am Ende eines *jeden* Datensatzes die volle Präzision zu erreichen.

    Jens

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • Die Idee ist natürlich der Einfachheit von Hardware geschuldet: Das hat weniger Platz im FPGA verbraucht. In Software macht es vielleicht mehr Sinn, tatsächlich mit variabler Datenlänge zu arbeiten und so am Ende eines *jeden* Datensatzes die volle Präzision zu erreichen.


    Das wäre auch zwingend notwendig. Wenn man z.B. 20 Sekunden nach rechts gelaufen ist und dann einen präzisen Sprung machen will, sollte der nicht plötzlich 1/2 Sekunde daneben liegen :)

    Unseens Vorschlag ist gut. Kombiniert platzsparende Datenhaltung bei Rüttelsituationen mit höchster Aufzeichnungsdauer bei ruhigen Sequenzen.

    (Und trotzdem würde ich Deltas aufzeichnen und keine absoluten Zeitstempel - aber das ist ja nur eine Frage, wann man die Subtraktion/Addition durchführt)

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • Vielleicht war das ein bischen zu ambitioniert für den Anfang, scheinbar will sich niemand so recht an dieses Projekt begeben.

    Belassen wir's also mal bei einfachen Mods, wie zusätzlichen Firebuttons. Ich habe irgendwie im Kopf, dass es zwei unterschiedliche dual-firebutton Methoden gibt; eine von Sega (die schließt einfach einen POT-Eingang gegen Masse), und eine von Atari, die braucht wohl noch einen Widerstand an der POT-Leitung. Oder war's ne Diode? Ich hab' keine Ahnung wie da die Standards sind. Hat jemand Unterlagen, passende Links?

    Jens

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • Wieviel Speicher steht denn überhaupt zur Verfügung?
    Ist SRAM erlaubt? oder soll der Stick das dauerspeichern?


    Ich würde bei einem einzelnen Microcontroller bleiben, kein externes Ram - das wird zu viel Löt-Arbeit. Den Controller suchst Du Dir natürlich selbst aus, da schreibt Dir keiner was vor.

    Jens

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • Bei Einsatz eines ATMEL AVR gibt es Controller im DIP40 Gehäuse mit bis zu 4 KB internem Speicher. Controller in kleinerem Gehäuse haben eher weniger RAM, für mehr (bis zu 16 KB) wird das Gehäuse schwer handhabbar. Einige wenige Typen können 64 KB externes SRAM ansteuern, aber da wirds mit dem RAMchip und der Logik davor schon recht kompliziert, da viele Leitungen dazwischen sind.

    Alternativ wäre vielleicht noch ein kleiner AVR (auch tiny) mit TWI (also SPI) und daran ein serielles EEPROM - da kriegt man mittlerweile 8 Pin Chips mit 32 KByte und mehr. Das Speichern/Auslesen den EEPROMs müsste eigentlich schnell genug sein, man darf für das Projekt nicht nur an SRAM als Möglichkeit denken.

    Viele Grüße
    hexagon

  • wie läst sich den auf den SD karten speichern ?
    wenn man ein microSD -> SD Adapter als Kartenslot rein bastelt , ist es billig und man kann viel speicher verbraten,
    Dazu kann man ja auch immer den speicher wechseln, evtl verschiedene aufzeichnungen haben (lol, einen art mini Videothek)

    aber ich hab auch keine ahnung, warscheinlich bracht das noch extra hardware um eine SD karte als speicher zu verwenden.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • ich hab jetzt nicht nochmal alles quergelesen, aber das scheint mir im Zweifel doch arg komplex?
    Die Loesung in der 64er damals sah allerdings simpel genug aus?
    Ich faende sonst auch einen zeitlich begrenzten programmierbaren Ablauf interessant.
    Z.B.: Feuer gedrueckt halten und einmal im Uhrzeigersinn von unten nach links - und das dann auf einen Extra Button/Schalter. Das waere lustig fuer Turrican und so weiter...
    Das braeuchte nur minimalen Speicher und muesste auch nicht cycle exakt sein.

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.