Hallo, ich bin neu im Forum und relativ neu im Bereich µC. Ich hatte in der Uni vor Jahren Microcontroller I + II (ARM/RISC). Wir haben dort eine Waage und Pumpe angesteuert und einen simplen Wasserspender gebaut. Also "Grundkenntnisse" & "Erfahrung" sind bedingt vorhanden, aber ich habe nie irgendetwas ausserhalb der Labore damit zu tun gehabt. Da ich in den letzten Monaten viel im Bereich Arcade Automaten zu tun hatte wächst nun das Interesse an µC und Hardware im allgemeinen Stück für Stück. Wobei wir auch direkt beim Thema wären. Ich habe ein Neo Geo MVS Board. Bei dem System werden bis zu acht Highscores in einem Backup RAM gespeichert (Siehe Bild) Ich würde jetzt gerne den RAM raus nehmen und gegen eine Schaltung austauschen, um die Highscore auslesen und manipulieren zu können. Das ganze soll im Idealfall irgendwann mit dem Internet Syncronisiert werden. Aber erst mal eins nach dem anderen. Ich hatte mir das ganze jetzt so vorgestellt: RAM raus, eigene Schaltung rein. Die Schaltung sollte bestehen aus einem µC, dem original RAM und einem weiteren (größeren) Speicher für die Highscores. Aufgabe der Schaltung soll sein den Adressbus zu überwachen: 1. Wird die ID des aktuellen Games in den RAM geschrieben, dann im Highscore Speicher nach schauen ob die HS vorhanden ist und ggf. in den Backup RAM schreiben. Ansonsten die acht Slots alle als leer markieren, damit das Spiel eine neue Highscore erstellt. 2. Wird auf den Adressbereich der Highscores zugegriffen (schreiben) die neuen Highscores in den HS-Speicher übertragen. Soviel zum Grund Gedanken, das ganze ist mit Sicherheit noch nicht 100% rund aber ich denke ein guter Anfang. ;) Wollte jetzt erst mal fragen ob das Prinzipiell so machbar ist und auf was muss ich achten bei der µC Wahl? Wie wähle ich den richtigen Takt für den µC anhand der Zugriffszeit des Backup RAMs? Danke schon mal an alle die sich das alles durch gelesen haben. Grüße Michael
Angehängte Dateien:
-
Cd2_batram__1_.jpg
74 KB
Coole Idee. Problematisch stelle ich mir hier ein bisschen das Timing vor; auf den SRAM kann ja recht zügig (bis runter zu 100 ns) zugegriffen werden. Du solltest am besten mit einem Logikanalyzer herausfinden, was da genau auf dem Bus passiert, und wie schnell. Dann kann man weitersehen.
http://wiki.pcbotaku.com/w/images/c/cc/Sony_CXK5864.pdf Ok, also innerhalb einer RAM Zugriffszeit von 100ns soll eine Erkennung, Entscheidung, Ersatzwert laden und ausgeben Aktion stattfinden ? Hört ich für mich jetzt nach FPGA Hardware an.
Das Foto vom Ram und dessen Eigenschaften sind kaum hilfreich, um Deine Frage zu beantworten. Erzähle uns mal, wie das RAM angesprochen wird (Timing Diagramm) und welche Zeiten eingehalten werden müssen, damit der Rest der Schaltung noch funktioniert.
Abhängig davon, wie oft auf den RAM zugegriffen wird, könnte es reichen, mit einem CPLD oder mit diskreten FFs die übertragenen Daten zu latchen und dann mit einem µC auszulesen. Wenn jedoch immer wieder relativ lange Write-Bursts auftreten, dann ist da wohl ein größerer Puffer gefragt, damit du alles aufzeichnest und dann mit einem µC ausliest. Edit: Stefan us schrieb: > Erzähle uns mal, wie das RAM angesprochen wird > (Timing Diagramm) und welche Zeiten eingehalten werden müssen, damit der > Rest der Schaltung noch funktioniert. Es ist ein normales SRAM mit 100ns Zugriffszeit. Da keine Busy Leitung vorhanden ist, kann man wohl davon ausgehen, dass man die Zeit, die geschrieben wird, nicht verzögern kann.
:
Bearbeitet durch User
Ich würde den RAM drinlassen und nur irgendwie parallel mit dem uC auslesen und schreiben. Man muss dann nur sicherstellen, dass der uC seine Finger weg nimmt, wenn der Automat schreiben oder lesen will.
Michael Petri schrieb: > Wollte jetzt erst mal fragen ob das Prinzipiell so machbar ist Mit einem FPGA schon. > und auf was muss ich achten bei der µC Wahl? Dass ein FPGA mit dabei ist... ;-) Ein uC ist gar nicht schnell genug, während eines Speicherzugriffszyklus alle nötigen Unterschritte (angelegte Adresse und Steuersignel auswerten, Daten holen und am Port bereitstellen) zu erledigen... Du könntest bestenfalls das RAM durch ein Dual-Port RAM ersetzen, und könntest dann in aller Gemütsruhe über den 2. Port den RAM-Inhalt manipulieren. http://www.cypress.com/?id=85
Michael Petri schrieb: > Aufgabe der Schaltung soll sein den Adressbus zu überwachen: > 1. Wird die ID des aktuellen Games in den RAM geschrieben, dann im > Highscore Speicher nach schauen ob die HS vorhanden ist und ggf. in den > Backup RAM schreiben. Dazu musst Du den Bus "arbitrieren", d.h. dem geben der Ih benötigt. Du hast Zwei Master: Deine Konsole und deine Huckepackplatine. Beide wollen auf das RAM zugreifen. Den einen Master - Konsole - kannst Du nicht ausblenden oder wegarbitrieren, der muss immer auf das RAM zugreifen können. Wird schwierig werden - da kann ich mir eher Dual-Ported SRAM vorstellen. Auf der einen Seite die Konsole, auf der anderen Seite dein Huckepack-Schaltung. Mal suchen obe es 8kx8 Dual-Ported SRAM noch gibt. rgds
Hi,
schon mal vielen Dank für diese VIELEN Antworten! :)
Also ich glaube das ganze wurde etwas falsch Verstanden.
Statt dem RAM möchte ich eine Schaltung an dem Board anbringen die aus
einen Microkontroller, dem aktuellen Backup RAM und einem weiteren
Speicher besteht.
Beim einschalten des Systems, wird die aktuelle Spiele-ID in den Backup
RAM geschrieben.
Meine Idee wäre jetzt den Adressbus & Datenbus zu überwachen.
Sobald jetzt auf die Adresse an der die Spiele ID abgelegt wird
geschrieben wird. Nehme ich die Spiele ID vom Datenbus und schaue in
meinem zusätzlichen Speicher nach ob dort eine Highscore für das Spiel
hinterlegt ist. Ist das der Fall, lade ich die Daten und schreibe diese
in den Backup RAM.
Wenn jetzt zu einem viel späteren Zeitpunkt die Highscore benötigt wird
ist diese bereits im RAM und ich sollte nicht das Problem haben, dass
ich zum Zeitpunkt des Zugriffs die Daten erst holen muss.
Wird eine neu Highscore gespeichert, sprich in den Backup RAM in den
Highscore Adress Bereich geschrieben, dann würde ich die Daten
zusätzlich in den Highscore Speicher schreiben.
Von der Schaltung her hatte ich mir das so vorgestellt:
[MVS BOARD RAM SCHNITTSTELLE]
|
[Microcontroller]---[Erweiterter Speicher]
|
[Backup RAM]
Falls es jemanden Interessiert hier ein paar Infos zur RAM Aufteilung:
http://wiki.neogeodev.org/index.php?title=Backup_RAM
Hoffe das ganze war jetzt etwas verständlicher! :)
Grüße
Michael
Vielleicht ist ein kleiner FPGA wirklich nicht so schlecht. Auf jeden Fall schnell genug und das Dual-Port-SRAM baut man sich da ggf. ganz problemlos selbst zusammen. :)
Also auch für mich sieht das auf den ersten Blick nach einer Anwendung für einen FPGA aus. Deiner beiden Schilderungen entnehme ich immer wieder Punkte, die eine "sofortige" Reaktion erforderlich machen, d.h. eine Reaktion die genauso schnell ist, wie der Zugriff auf das ursprüngliche RAM alleine. Ich habe im Zusammenhang mit der Schilderung Deiner Erfahrungen und Deiner Wortwahl den Eindruck, dass Du Dir manche Detailvorgänge nicht vorstellen kannst. Das aber gefährdet den Erfolg Deines Vorhabens. Ein Beispiel: >Wenn jetzt zu einem viel späteren Zeitpunkt die Highscore benötigt wird >ist diese bereits im RAM und ich sollte nicht das Problem haben, dass >ich zum Zeitpunkt des Zugriffs die Daten erst holen muss. Du musst in diesem Fall aber wie vorher auch, entscheiden, ob Du die Daten aus dem sekundären Highscore-Speicher holst oder aus dem primären. Das ist ein aktiver Prozess, der zeitlich im Rahmen der Zugriffszeit liegt. Das schafft kein uC, aber ein FPGA eben schon. (Beachte hier bitte auch meinen Versuch Begriffe eindeutig zu kennzeichnen. Du schreibst einerseits von RAM und vom Highscore). Ich möchte Dich wirklich nicht entmutigen. Aber ganz so einfach, wie Du denkst, ist das alles nicht. Die Natur der Sache ist auch nicht mit der Bedienung eines Interfaces einer Waage und der Kontrolle einer Pumpe zu vergleichen. Wenn ich Dir etwas empfehlen darf, dann würde ich vorschlagen, dieses erste Mal, das Projekt mit einem erfahreneren und bezahlten Entwickler gemeinsam anzugehen und Dir damit die Kenntnisse für weitere ähnliche Probleme anzueignen.
Michael Petri schrieb: > Also ich glaube das ganze wurde etwas falsch Verstanden. Das Problem ist eher, dass du noch keine Vorstellung davon hat, was sich da am nackten Silizium abspielt. > > Statt dem RAM möchte ich eine Schaltung an dem Board anbringen die aus > einen Microkontroller, dem aktuellen Backup RAM und einem weiteren > Speicher besteht. Das ist alles klar, aber ... > Meine Idee wäre jetzt den Adressbus & Datenbus zu überwachen. Genau hier liegt der Hund. Das spielt sich alles viel zu schnell ab, als das dein µC da mitkommen würde. Und da reden wir noch gar nicht davon, dass er mit den mitgelauschten Daten irgendwas manipulieren könnte. Die Umgebungshardware wartet nicht. Die legt die Adresse auf den Bus, dann kommt der Read-Puls und 100ns später holt sie sich die Werte vom Datenbus. Egal, ob dein µC schon mit auflegen der Daten auf den Datenbus fertig ist oder nicht. Der µC muss aber anhand der mitgelesenen Adresse erst mal entscheiden, welches Datenbyte da jetzt überhaupt auf den Bus soll. Bzw. das ganze dann auch umgekehrt beim Schreiben. Die Originalhardware wartet nicht. Das geht zack, zack und danach liegt am Datenbus schon wieder ganz was anderes.
:
Bearbeitet durch User
Um eins noch mal klar zu stellen: Das ganze war ein Gedanke den ich gerne irgendwann Umsetzen würde, das bedeutet nicht, dass ich ende der Woche mir alle Teile bestellen will und planlos drauf los basteln will. Genau deswegen bin ich hier, mein nächster Schritt wird sein heute Abend nach der Arbeit mich mal grob in das Thema FPGA, Dual Port SRAM & Logic Analyzer ein zu lesen. Für den Start und einstieg habe ich mir ein paar PIC und AVR Controller gekauft und bastel an einem n64 Controller und einem alten Super Nintendo rum. Wobei der Super Nintendo auf Basis einer Anleitung und fertigen Sourcecode umgebaut wird :) Noch mal vielen Dank für alle die sich die Zeit genommen. Grüße Michael PS: Die Idee mit dem bezahlten Entwickler finde ich ganz nett, wie findet man so jemanden und wo liegen die Stundenlöhne? :)
Karl Heinz schrieb: > Die Umgebungshardware wartet nicht. Die legt die Adresse auf den Bus, > dann kommt der Read-Puls und 100ns später holt sie sich die Werte vom > Datenbus. Egal, ob dein µC schon mit auflegen der Daten auf den Datenbus > fertig ist oder nicht. Das soll auch gar nicht passieren. Der µC soll wie gesagt den RAM beim System start manipulieren. Der Zugriff auf den Backup Ram, bzw. auf die Highscores dort erfolgt ja erst wenn jemand das Spiel beendet hat. (Es sei denn das System zieht die Daten vorher schon aus dem BRAM in einen anderen RAM, was mir bisher nicht bekannt ist!) Ich denke das Thema Logik Analyzer ist der Schlüsselpunkt. Ich werde mich da mal schlau machen und schauen ob's etwas passendes für mich gibt. Danach denk ich kann man mehr sagen. Grüße Michael
> ... das bedeutet nicht, dass ich ende der Woche mir alle Teile bestellen >will und planlos drauf los basteln will. Das haben wir nicht unterstellt. Aber ist gut zu wissen. Für Dich! >Die Idee mit dem bezahlten Entwickler finde ich ganz nett, wie >findet man so jemanden und wo liegen die Stundenlöhne? :) Das hängt von Deinem Verhandlungsgeschick ab. Zu beachten ist auch, dass derjenige Dir ja nicht nur das Projekt selbst entwickeln soll, sondern Dir auch beibringen wie das funktioniert und wie Du Ähnliches selbst machen kannst. Das nehme ich an, weil Du schriebst: >Da ich in den letzten Monaten viel im Bereich Arcade Automaten zu tun >hatte wächst nun das Interesse ... Ich gehe davon aus, das Du das professionell machen willst. Der Stundensatz wird wohl irgendwo zwischen 'ner Kiste Kaffee und 90 Euro liegen. Falls Du das aber als Hobby machst, dann hast Du ja Zeit. Dann kannst Du einfach auf Deine Erfahrungen aufbauen und Dir weitere Grundlagen aneignen. So in ein bis zwei Jahren (vorausgesetzt Du hast nur neben der Arbeit Zeit) bist Du dann soweit, sowas anzugehen.
>Ich denke das Thema Logik Analyzer ist der Schlüsselpunkt.
Das ist als wenn ein angehender Elektroniker ein Multimeter für das
Alpha und Omega hält. Ein kapitaler Irrtum. Das ist nur ein Werkzeug und
es erspart Dir keine Grundlagenkenntnisse.
>> Die Umgebungshardware wartet nicht. Die legt die Adresse auf den Bus, >> dann kommt der Read-Puls und 100ns später holt sie sich die Werte vom >> Datenbus. Egal, ob dein µC schon mit auflegen der Daten auf den Datenbus >> fertig ist oder nicht. >Das soll auch gar nicht passieren. Der µC soll wie gesagt den RAM beim >System start manipulieren. Der Zugriff auf den Backup Ram, bzw. auf die >Highscores dort erfolgt ja erst wenn jemand das Spiel beendet hat. (Es >sei denn das System zieht die Daten vorher schon aus dem BRAM in einen >anderen RAM, was mir bisher nicht bekannt ist!) Du betrachest hier zwei völlig unterschiedliche Zeitskalen. Was 100 Nanosekunden dauert, dauert Dienstags und auch bei Vollmond immer 100 Nanosekunden. Deine Einlassung auf die Aussage von Karl Heinz bestätigt, (was ja an sich nicht gegen Deine Person spricht) das Du nicht genügend Kenntnisse hast. Es ist (im allgemeinen und wie ich meine in diesem Fall) mehr oder weniger sinnlos wenn ein Anfänger einem Profi widerspricht. Nimm lieber Rat und Hinweise als wesentlich wahrscheinlicher zutreffend an, als die Ideen, die Du nach zwei Stunden programmieren von vor X Jahren hat. Ich will Dich sicher nicht dissen, Dir nur die Skalen klarmachen.
ich würde es so machen einen 2ten Speicherbaustein parallel anklemmen, der µC lauscht mit schreibt das dann in aller ruhe in den 2ten Speicherbaustein und schaltet danach einfach auf den 2ten Speicherbaustein um. Zeitkritisch wäre dann nur das umschalten. Kenne noch Emulatoren von früher die hatten 3 Speicherbausteine. 1 mal die Originaldaten und dann sogar 2 weitere Speicher . So konnte man immer Problemlos zw. Original und geänderten Daten umschalten da immer der inaktive Baustein im Hintergrund geschrieben/verändert wurde und dann im Betrieb auf den anderen Speicher umgeschaltet wurde. In der Uranwendung gab es aber nur einen lesenden Betrieb.
Verne schrieb: > Du betrachest hier zwei völlig unterschiedliche Zeitskalen. Was 100 > Nanosekunden dauert, dauert Dienstags und auch bei Vollmond immer 100 > Nanosekunden. Deine Einlassung auf die Aussage von Karl Heinz bestätigt, > (was ja an sich nicht gegen Deine Person spricht) das Du nicht genügend > Kenntnisse hast. Was Zugriffszeiten sind weiß ich. Ich wusste nur nicht, dass es ein Microkontroller in dem Bereich nicht hinter her kommen. Tut mir leid dass ich da an euch vorbei geredet habe. Will hier niemanden Widersprechen. Wie du selbst sagt ich bin Anfänger. Hatte deswegen auch das Gefühl ich hätte mich falsch ausgedrückt und ihr versteht nicht was ich meine. Wie gesagt hier wurde jetzt viel gesagt und ich werd jetzt erst mal lesen müssen. Lektüre gibt es im Internet ja mehr als genug. Werde mich sicher noch mal melden. Danke und Grüße Michael
Thomas O. schrieb: > der µC lauscht mit schreibt das dann in aller ruhe Nette Idee, Dein Lauschen sieht aber so aus: Alle 100ns können 8 Datenbits + Adr. kommen. Das entspricht einer Datenrate von 10Megabyte die da 'in aller Ruhe' gelesen werden müssen + Adressauswertung. Das geht nur mit spezieller Hardwareunterstüzung, und die programmiert man sich in ein FPGA. Wenn ein Schreibzugriff stattfindet und die MCU gerade an dem zweiten Speicher rumfingert, und der, sagen wir mal 10ns(!) Zugriffszeit hat, dann hat die MCU noch 90ns um den Zugriff zu erkennen, die Finger wegzunehmen und den Speicher wieder 'aufzuschalten'. Sonst sind die Daten korrupt. Bei sagen wir mal einer 100Mhz getakteten MCU und lauter 1 Takt-Befehlen in brutal optimiertem Assembler wären das 10ns pro Befehl, d.h. die ganze Show muss in 9 Befehlen über die Bühne gehen, wenn es 0.00ns Einschwingzeit an den Pins gibt. Und das war die optimistische Sichtweise.
Thomas O. schrieb: > ich würde es so machen einen 2ten Speicherbaustein parallel anklemmen, > der µC lauscht mit schreibt das dann in aller ruhe in den 2ten > Speicherbaustein und schaltet danach einfach auf den 2ten > Speicherbaustein um. Zeitkritisch wäre dann nur das umschalten. Und natürlich, dass inkonsitente Daten auftreten können. Das bekannte Semaphorenproblem eben. Aber ich meinte, schon mal das Stichwort DPRAM erwähnt zu haben. Das minimiert die Wahrscheinlichkeit eines Konfliktes. Es geht natürlich trotzdem schief, wenn gleichzeitig der uC und der Konsolenprozessor auf die selbe Adresse schreiben. Michael Petri schrieb: > Das soll auch gar nicht passieren. Der µC soll wie gesagt den RAM beim > System start manipulieren. Der Zugriff auf den Backup Ram, bzw. auf die > Highscores dort erfolgt ja erst wenn jemand das Spiel beendet hat. Dass nicht auf das RAM zugegriffen wird bedeutet nicht automatisch, dass der Bus frei ist. Kann ja sein, dass solange mit dem selben Bus etwas anderes angesprochen wird. Und dann kann nicht einfach der uC da drauf zugreifen...
> Für den Start und einstieg habe ich mir ein paar PIC und AVR > Controller gekauft und bastel ... Schön. Dir ist wohl nicht klar, dass FPGA's völlig anders funktionieren. Mikrocontroller Know-How nützt Dir da ungefähr gar nichts.
Stefan us schrieb: > Schön. Dir ist wohl nicht klar, dass FPGA's völlig anders funktionieren. > Mikrocontroller Know-How nützt Dir da ungefähr gar nichts. Nein weis ich nicht. Habe ich auch nie behauptet dass es mir was nützt, egal.
Einige Quellen[1] behaupten, dass der Zugriff auf das Backup-RAM immer über BIOS-Funktionen erfolgt - wäre es da nicht einfacher, das BIOS anzupassen um Datenblöcke für mehr Spiele zu verwalten statt das Problem komplett mit Hardware zu erschlagen? Das Unibios kann Highscores immerhin schon auf eine angeschlossene Memory Card "umleiten", ganz abwegig scheint die Idee also nicht zu sein. [1] z.B. http://wiki.neogeodev.org/index.php?title=Backup_RAM
ohne zu wissen was auf dem Bus los ist kann man eh nichts dazu sagen. Und der andere Gegenpart wird warscheinlich auch ein µC sein und der hat sicherlich auch längere Takte als der 10nS Speicher. Ansonsten laßßt man hält erst reinschreiben und liest dann den Speicher aus. Man kann ja jederzeit durch einen Interrupt mit der Aktion aufhöhren. Ist ja nicht so das das da ununterbrochen neue Highscores geschrieben werden. Aber hier noch eine weitere Idee 2 Speicherbausteine parallel beschreiben lassen, danach den 2ten auskoppeln, bearbeiten und im passenden Moment wieder umschalten.
Was mir noch nicht so richtig klar ist, was Du genau machen willst. Nehmen wir an du hast Spieler <ERNI> und Spieler <BERT>. Nun speichern beide ihren Highscore unter ihren Namen ERNI und BERT und das Spiel bekommt meinetwegen auch eine ID. Wie ich dich verstanden habe, soll der Highscore in z.B. 3Wochen, wenn die beiden wiederkommen, immer noch verfügbar sein obwohl in der Zwischenzeit schon hunderte andere gespielt haben. Nun kommen die beiden also wieder und geben ihren Namen ein. Der Controller des Automaten lädt ja erst mal nur stupide die Daten aus dem RAM und eine interne Routine schaut nach, ob die Namen bzw, ID schon vorhanden sind. Wenn Du nur am Daten- und Adressbus des RAM lauschst, weißt doch gar nicht, welche Daten er überhaut sucht. Beim schreiben der Daten mag das ja noch einigermaßen funktionieren, aber beim lesen?
Ingo Korb schrieb: > Einige Quellen[1] behaupten, dass der Zugriff auf das Backup-RAM immer > über BIOS-Funktionen erfolgt - wäre es da nicht einfacher, das BIOS > anzupassen um Datenblöcke für mehr Spiele zu verwalten statt das Problem > komplett mit Hardware zu erschlagen? Das Unibios kann Highscores > immerhin schon auf eine angeschlossene Memory Card "umleiten", ganz > abwegig scheint die Idee also nicht zu sein. > > [1] z.B. http://wiki.neogeodev.org/index.php?title=Backup_RAM Hi, das BIOS war damals auch mein erster Gedanke, da das ganze aber aus dem Gedanken resultiert Highscores irgendwann mal auf mehreren Arcades zu synchronisieren via Internet würde man so nichts gewinnen. :/ Ich glaube diese Dual-Port RAMs sind sehr Interessant und vllt. kann man das ganze auch so gestallten, dass man es vor dem einschalten des NeoGeo Systems via Taster ausführt und einfach die acht Highscores die im RAM liegen syncronisiert, so würde man der NeoGeo Hardware schon mal nicht in die Quere kommen. Hier geht ich natürlich einen Riesen Schritt von "nur" mehr Speicherplätze direkt zu Netzwerkverkehr! Ob es dadurch leichter wird Bezweifle ich jetzt erst mal :) Grüße Michael
Steffen N. schrieb: > Was mir noch nicht so richtig klar ist, was Du genau machen willst. > > Nehmen wir an du hast Spieler <ERNI> und Spieler <BERT>. Nun speichern > beide ihren Highscore unter ihren Namen ERNI und BERT und das Spiel > bekommt meinetwegen auch eine ID. Wie ich dich verstanden habe, soll der > Highscore in z.B. 3Wochen, wenn die beiden wiederkommen, immer noch > verfügbar sein obwohl in der Zwischenzeit schon hunderte andere gespielt > haben. Nun kommen die beiden also wieder und geben ihren Namen ein. Der > Controller des Automaten lädt ja erst mal nur stupide die Daten aus dem > RAM und eine interne Routine schaut nach, ob die Namen bzw, ID schon > vorhanden sind. Wenn Du nur am Daten- und Adressbus des RAM lauschst, > weißt doch gar nicht, welche Daten er überhaut sucht. Beim schreiben der > Daten mag das ja noch einigermaßen funktionieren, aber beim lesen? Der plan war die Highscore-Daten an einen Server zu senden, dieser sollte diese dann Auswerten und in eine Datenbank schreiben und bei einem Request ein Datensatz (wie er in den RAM liegt) zurück geben. Für mich war der Dreh- & Angelpunkt bisher aber erst mal die Daten aus dem RAM zu lesen und zu schreiben. :)
Michael Petri schrieb: > Ich hatte in der Uni vor Jahren Microcontroller I + II (ARM/RISC). > Wir haben dort eine Waage und Pumpe angesteuert und einen simplen > Wasserspender gebaut. Ich weiss nicht, was du da studiert hast, aber fuer dein aktuelles Projekt war es das Falsche. Nichts gegen eine Herausforderung - aber das hier ist fuer dich eine Ueberforderung. Fang nochmal kleiner an. Schon den fest eingebauten Speicher durch ein Modul ersetzen und das dann manuell zu synchronisieren duerfte allerdings immer noch eine Hausnummer zu gross sein...
Ein Teil der Controller der Serien TMS320F54/F55 ermoeglicht die externe Adressierung des internen Speichers, darunter natuerlich auch die internen RAMs. Damit kann eine externe Schaltung bequem Bereiche des RAMs adressieren und Daten lesen und schreiben. Auf diese Daten kann der Controller dann natuerlich auch zugreifen um sie auszuwerten und zu manipulieren. Es muss also nicht immer gleich ein FPGA sein. 100 ns sind fuer einen mit 100-300 MHz getakteten TMS320 auch viel Zeit...
Quack schrieb: > Ich weiss nicht, was du da studiert hast, Informatik und wenn du weiter lesen würdest sage ich selbst ich habe keine Ahnung und steige gerade in das Thema erst ein. Ich wollte lediglich wissen ob das so wie ich es mir gedacht habe überhaupt möglich ist, damit ich ein Ziel habe auf das ich hin arbeiten kann. > aber fuer dein aktuelles Projekt war es das Falsche. Und noch mal, das alles war ein Gedanke und ich wollte mich nur mal schlau machen. Es sollte nicht mein aktuelles Projekt für den Einstieg werden. Dafür habe ich wie bereits gesagt gerade andere Baustellen. Trotzdem Danke fürs Zeit nehmen und deinen Einwand. Grüße Michael
Den Ansatz, das über das BIOS zu lösen, finde ich ziemlich gut. Wenn du damit die Daten des RAMs irgendwie rausschreiben kannst, dann kannst du sie ja auch mit einem µC einlesen und dann weiterverarbeiten. Da spricht dann auch nichts gegen eine Vernetzung von mehreren Automaten. Es gibt sogar ein Open-Source BIOS, nämlich NeopenBIOS.
:
Bearbeitet durch User
Ich würde mir einfach mal einen Logikanalyser besorgen/ausleihen und den Zugriff auf den RAM auswerten. Somit weißt du dann wann und wie schnell auf den RAM zugegriffen wird und du siehst auch, welche Daten gelesen oder geschrieben werden. Dann kannst du weitere Entscheidungen treffen, á la Mikrocontroller/FPGA/bringt nichts da nicht ArbeitsRAM/etc. Wenn du natürlich das BIOS anpassen könntest bzw. es hier schon angepasste gibt, wäre das natürlich auch was. gruß Mat
Hi, BIOS anpassen ist machbar, da auf dem Speicher SEHR viel frei ist. Ich selbst verwende gerade das Unibios. Wie würdet ihr die Daten via BIOS aus dem System extrahieren? Danke/Grüße Michael
:
Bearbeitet durch User
Bei www.xmos.com gibt es Mikrocontroller, die evtl. schnell genug sind.
Michael Petri schrieb: > Wie würdet ihr die Daten via > BIOS aus dem System extrahieren? Über einen freien Pin am Prozessor, falls einer vorhanden ist. Ansonsten müsste man einen bereits verwendeten missbrauchen. Ich kann auf den Schaltplänen [1] leider nichts erkennen. Laut [2] werden zum Schreiben des Backup-RAM Bios-Routinen verwendet. Darauf könnte man aufbauen. Voraussetzung ist hier jedoch, dass du diese editieren kannst. Da bräuchtest du schon den Source-Code. Für Unibios habe ich bis jetzt keinen gefunden. [1] https://wiki.neogeodev.org/index.php?title=MVS_schematics [2] https://wiki.neogeodev.org/index.php?title=Battery-backed_RAM
Hi! 6A66 schrieb: > da kann ich mir eher Dual-Ported SRAM > vorstellen. Auf der einen Seite die Konsole, auf der anderen Seite dein > Huckepack-Schaltung. Mal suchen obe es 8kx8 Dual-Ported SRAM noch gibt. Es reicht doch, wenn die Huckepackschaltung auf das RAM zugreift, wenn die Konsole aus ist oder? Die Huckepackschaltung bräuchte ihre eigene Stromversorgung. Wenn sie erkennt, dass die Konsole ausgeschaltet wurde, holt sie die Daten aus dem RAM und sendet sie an den PC. Der "optimiert" die Highscoreliste und sendet sie zurück an die Huckepackschaltung welche die Daten dann ins RAM schreibt. Während dieser Zeit muss man halt unterbinden, dass die Konsole eingeschaltet wird (Relais in Stromversorgung o.ä.) Das Timing ist dabei absolut unkritisch. Gruß
Michael Petri schrieb: > 1. Wird die ID des aktuellen Games in den RAM geschrieben, dann im > Highscore Speicher nach schauen ob die HS vorhanden ist und ggf. in den > Backup RAM schreiben. Hallo schriebschrieb, anhand der zitierten Anforderung bin ich davon ausgegangen dass beide System - der Host und das Huckepacksystem - aktiv sind. Sonst wäre es ja einfach, da bräuchte man nichtmal ein DualPort SRAM, da kann ich auch während des Resets auf das RAM zugreifen weil ich nicht befürchten muss dass mir der Host dazwiscchenfunken will. rgds
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.