Beiträge von Dom

Zitat von Ice Man

SRAM ist auch leicht via Header auslesbar.

$7FD8 bzw. $FFD8 ist die SRAM-Größe

Glaube das sollte eigentlich klar sein, aber danke trotzdem für deine schicke Tabelle

Bisher berechne ich die SRAM Größe mittels 2^Dezimalwert.

Wollte eigentlich nur wissen, ob es Spiele gibt, die Annomalien aufweisen was das angeht oder ob das bisher so passt?

Bei Doom z.b. habe ich den Fall, dass hier kein SRAM erkannt wird, obwohl es 512kb sein müssten.

Genauer habe ich mir das noch nicht angesehen, werde ich evtl. morgen dazu kommen

Update auf v0.2!

ROM types werden nun über Ice Man s Liste erkannt

Die SRAM Angaben könnten noch ausgiebig von jemandem getestet werden.

Das würde ich gerne als nächstes angehen.

Zitat von byuu

LoROM and HiROM don't actually exist. Although I don't have a better name for this, what you're implying is basically A22=0 vs 1. Of course I'll have better luck eliminating SMC than this terminology, I'm sure

Zitat von Ice Man

Wenn es jemand genau weiß oder sagen kann, gerne raus damit.

Zitat von Ice Man

Und 7FBx ist unwichtig, wenn es um die Funktion deines Programms geht.

Eben nicht... Da stehen die Company Codes drin bei ROMs mit neuerem Header...

Zitat von Ice Man

LoROM und HiROM gibt es in der Tat.

Dann zeig mir die Stelle mal bitte in den offiziellen Entwicklerhandbüchern.

Ich habe da bisher noch nichts drüber lesen können und zugegebenermaßen auch noch nicht wirklich viel rein geschaut

Zitat von Ice Man

Star Ocean ist eben nur LoROM. Oder sieht du bei x407FC0 den Header nochmal?

Star Ocean wird auch über die Plausibilitätsprüfung als LoROM erkannt, ABER schaut man sich danach die gefundene Info im Header an... Was findet man da?

-> guggst du hier <--

Das wirft wieder Fragen ethischen Ausmaßes auf...

Btw. wäre der Header generell besser ab 407FB0 zu lesen, da es ab ca. 1994 hier eine Änderung gab

Zitat von Ice Man

Abgesehen davon, dass es ExLoROM offiziell gar nicht gibt, ja.

Naja, LoROM und HiROM gibt es ja offiziell auch nicht... das sind nur Szenebegriffe für die verschiedenen ROM layouts

Zitat von Ice Man

Star Ocean z.B. ist NICHT ExLoROM sondern nur einfach ROM+S-DD1+RAM+Battery (LoROM!)

Den Unterschied hatte ich auch schon festgestellt, aber dennoch befindet sich im Header das Byte, welches es als ExLoROM identifiziert.

Ich glaub ich gehe da etwas anders vor als die meisten ROM Tools, die einfach nur anhand einer Plausibilitätsprüfung den map mode identifizieren.

Nach der Plausibilitätsprüfung nehme ich nochmal das entsprechende ROM type Byte, lese das aus und lege dann erst fest, welcher map mode angezeigt werden soll. Wer weiß was nun korrekter ist? Ich halte es jedenfalls für das bessere Vorgehen, da Star Ocean anhand seiner Größe und dem Header Offset ja auch ein ExLoROM ist. Oder sehe ich das falsch?

Gilt die Liste auch bei ExLo- und ExHiROMs? Was für LoROM gilt gilt auch gleichzeitig für ExLoROM? Sprich, wenn der Header bei 407FB0 oder 40FFB0 gefunden wird?

Zitat von Ice Man

Ah bezüglich Region Locks. Ich glaube uCON macht das auch....ABER... es elimiert so ziemlich alles was nach "3F 21" aussieht, leider eben auch nicht Region Locks.

Wichtig hierbei ist glaube ist, dass man nach "AD 3F 21" bzw "AF 3F 21 00" sucht.

Hast du das in etwa so gemacht?

So ähnlich... Ich habe die ganzen Codes aus dem Quelltext vom uCON64 (ab Zeile 1999) gezogen, aber das Verfahren dazu selbst entwickelt. Hierbei pflege jeweils für PAL und NTSC Spiele 3 Listen, welche 1 x den locking Code, 1 x den unlocking Code und 1 x das Pattern zum Ersetzen beinhalten. Die locking Codes werden über das Pattern gesucht und der unlocking Code an der entsprechend variablen Stelle ergänzt und anschließend wird der locking Code mit dem erstellten unlocking Code überbügelt... Ich hoffe du kannst das einigermaßen nachvollziehen Hast du ein Beispiel wo das nicht klappt bzw. wo es Abweichungen zu uCON64 gibt? Würde mir das gerne ansehen.

P.S.: Bitte beachte, dass es eine neue Version gibt, falls du noch die alte verwendest

Zitat von Ice Man

Und ja, die ROM Type Liste ist komplett.

Super

Dann würde ich die übernehmen und am Wochenende so implementieren

Zitat von x5t

Interessantes Thema, vielen Dank dafür!

Sehr gerne! Danke auch für dein Interesse

Update: Das Tool sollte nun so gut wie alle Reion locks aufspüren und vernichten können

Habe das natürlich an einer Hand voll ROMs verifiziert, sollte aber passen.

Download wurde entsprechend aktualisiert! Ab jetzt mit Versionsnummer

Zitat von Ice Man

Hab schon gemerkt, dass ROMs mit Spezialchip nicht richtig dargestellt werden. Hier mal eine Liste an Hexwerten, die dir behilflich sein könnten.

Auf diese Schlampigkeit hatte ich ja hingewiesen:

Zitat von Dom

Die Erkennung des ROM types ist noch etwas schlampig

Aber danke mal für die Auflistung der einzelnen Codes

Ich versuche das derzeit nicht über eine simple switch case Anweisung, sondern über das Interpretieren und Zusammenfügen des entsprechenden Bytes, weshalb das noch nicht 100%ig funktioniert... Aber wenn deine Tabelle tatsächlich vollständig ist und stimmt würde ich die gerne übernehmen

Derzeit sieht das in etwa so bei mir aus:

                if(readROMType[0] == 0x00)
                {
                    stringROMType = "ROM Only";
                }

                else if (readROMType[0] == 0x01)
                {
                    stringROMType = "ROM + RAM";
                }

                else if (readROMType[0] == 0x02)
                {
                    stringROMType = "ROM + RAM + SRAM";
                }

                else
                {
                    byte chip = readROMType[0];
                    chip &= 0xF0;

                    byte layout = readROMType[0];
                    layout &= 0x0F;

                    switch(chip)
                    {
                        case 0: stringROMType = "DSP"; break;
                        case 16: stringROMType = "SuperFX"; break;
                        case 32: stringROMType = "OBC1"; break;
                        case 48: stringROMType = "SA-1"; break;
                        case 224: stringROMType = "Other"; break;
                        case 240: stringROMType = "Custom"; break;
                        default: stringROMType = "";  break;
                    }

                    switch(layout)
                    {
                        case 3: stringROMType += " + ROM"; break;
                        case 4: stringROMType += " + RAM"; break;
                        case 5: stringROMType += " + RAM + SRAM"; break;
                        case 6: stringROMType += " + SRAM"; break;
                        default: stringROMType += ""; break;
                    }

Ist keinesfalls sonderlich schön, noch komplett

Habe noch ein Tool, mit dem man Offsets von Lo- in HiROM umrechnen kann und andersrum.

Deine Tabelle ist schon mal ein guter Anfang würde ich sagen, danke!

Ich nehme an, dass als EPROM hier der 27C801 anzunehmen ist,, oder?

Generell werde ich jedoch erst zusehen, dass ich alle Region locks hinbekomme und der ROM type / SRAM richtig interpretiert und angezeigt wird.

Danach kann man dann an die Implentierung der Hi- <-> LoROM Konvertierung gehen, aber ich bin sicher, dass das zu machen ist.

Zitat von Ice Man

Was mich immer nur stört ist, dass SwapBin nur für 27C801 bzw. 8Mbit funktioniert.

Nachtrag, hatte ich übersehen...

Das SwapBin ist ausschließlich beim 27C801 möglich, da die anderen EPROMs wie 27C4001 etc. einen anderen Aufbau besitzen.

Es können weniger Banks intern getauscht werden, wodurch immer noch ein nahezu gleichbleibender Aufwand beim Rewiring bestehen würde.

Zitat von RedScorpion

Da fällt mir ein, es gibt auch einen Hirom-> Lorom konverter für Spiele. Hab ich mal auf ultimate console gesehen!

Müsste ich mir mal ansehen... Sollte aber, ähnlich dem SwapBin, über ein Vertauschen der Banks möglich sein

LoROMs bestehen imho aus 32 kB und HiROMs 64 kb Banks. Werde das die Tage mal prüfen

Zitat von blackerking

Ich fände es schön wenn du bei der Größe diese Infos beachtest:

https://de.wikipedia.org/wiki/Binärpräfix

Dachte das hätte ich bereits? Generell schreibe ich die Einheiten gerne aus (bits / Bytes), damit es zu keinen Verständnisproblemen beim User kommt.

Zitat von Ice Man

In diesem Fall wäre sinnvoll das ROM auf die nächste volle MB (in diesem Fall 2MB) automatisch zu expandieren und dann SwapBin anzuwenden.

Was hälst du von diesem Vorschlag?

Das hatte ich bereits so ähnlich drin, glaube aber, dass das bei einigen ROMs zu Problemen mit den Checksums geführt hatte

Du musst erstmal manuell auf die gewünschte Größe Expanden, dann das expandierte ROM nochmal laden, schauen ob die Checksum noch in Ordnung ist (ggf. fixen und das gefixte ROM nochmal laden) und dann den SwapBin durchführen.

Hallo zusammen,

aus Spaß an der Freude und um meinen eigenen Horizont in Sachen SNES-Technik zu erweitern habe ich die letzten Wochen über an einem kleinen ROM-Tool gearbeitet, welches ich einfach mal frech "Advanced SNES ROM Utility" getauft habe Klar gibt es sicherlich Tools die mehr können, aber diese wurden auch über Jahrzehnte von verschiedenen Leuten entwickelt

Genug der großen Worte...

Was kann das Tool bisher?

• Allgemeine Infos über das ROM anzeigen
• Header hinzufügen
• Header entfernen
• ROM Infos editieren
• Falsche internal ROM size Angaben fixen
• SwapBin für 8 Mbit oder durch 8 Mbit teilbare ROMs
• ROM Expanden bis 64 Mbit (experimentell)
• ROMs splitten
• Interleaved ROMs deinterleaven
• Eine defekte Checksum reparieren
• Region locks entfernen
• IPS / UPS / BPS Patches anwenden
• Kommt auch mit BS-X ROMs klar

Was gibt es derzeit zu beachten / Woran wird noch gearbeitet?

Derzeit wird geprüft, ob man ohne größeren Aufwand den Company Code ändern kann

Da alles in C# gecoded wurde braucht ihr mindestens das .NET-Framework 4.5.

Wie kann ich helfen?

Ganz einfach: testen und berichten! Ich bin über jeden Verbesserungsvorschlag und konstruktive Kritik froh!

Wo finde ich denn das Tool bzw. den source code?

Download über RHDN

Github (Branch: "Redesign")

Das Wort zum Schluss:

Bei Fragen einfach melden! Ich helfe euch selbstverständlich sehr gerne weiter.

Und natürlich um mich abzusichern: Die Benutzung der Software geschieht natürlich auf eigene Gefahr!

Wir wurden gerade netterweise im Retro Klub auf Rocket Beans TV erwähnt (ca ab Minute 42:00)
Vielen Dank an Gregor und vorallem Fabian für die Erwähnung.

Desweiteren geht die Folge um das Analogue Super Nt. Lohnt sich also, den Rest der Folge auch zu schauen.

Alles Besteller wurden angeschrieben und mit Infos versorgt
Sollte ich den ein oder anderen vergessen haben, bitte melden und mir nicht übel nehmen...
Geht hier gerade alles etwas drüber und drunter

Und wieder News!

Die Boxen sind angekommen und erfüllen all unsere Anforderungen
Jeder Besteller bekommt im Laufe des Wochenendes eine PN

Es gibt Neuigkeiten

@ffmcloud schrieb:

"Hallo zusammen,
die Ersatzlieferung geht heute angeblich per UPS an mich raus. Sollte also morgen Nachmittag spätestens da sein. - 24.01.2018"

Zitat von Wuchti

ich weiß grade nicht welche sd2snes version ich habe, aber bei mir gibt es da so 3 LEDs linksoben "unter" dem Label. Die liegen ca... 5 mm von der oberen Labelkante weg. Ist demnach der "Super Nintendo"-Schriftzug weit genug unten oder würde der Schriftzug dann über den LEDs liegen welcher entsprechend mit Löchern versehen werden müsste? Bzw. es war ja mal u.a. im circuit board die Rede von verschiedenen Labelentwürfen. Eines Davon mit eurem Stuff bestellen geht wohl aufgrund der Stückzahl nicht?

Gute Frage
Der "Super Nintendo"-Schriftzug fängt, gemessen an der Oberkante des Labels, 7mm weiter unten an.
Wenn du dann nochmal 1mm vom Labelrahmen am Modulrand runter gehst solltest du ca. 8mm Platz haben.
Reicht das? Wenn nicht würde ich nochmal einen Entwurf machen mit herunter gesetztem Schriftzug, hier müsstest dich dann aber dann selbst um die Herstellung kümmern und mir die benötigten Maße geben.
@NeoRame oder @Northstarex sollten dir bei der Produktion weiterhelfen können

Zitat von RedScorpion

Zitat von »KillBill_158«

Ist die hier angebotene dann die offizielle DE Version und von ikari abgesegnet? Interesse besteht nämlich.

Ja genau so ist es! Ikari selbst hat drüber gelesen!

Gruß

red

Alles anzeigen

Danke @Red
Ikari war einer der Testleser und hat auch selbst noch die ein oder andere Korrektur gemacht

Da es mittlerweile einiges an Neuigkeiten gibt, will ich euch diese natürlich nicht vorenthalten

Ich kopiere hier einfach mal die ursprünglichen Beiträge von @ffmcloud rein:

@ffmcloud schrieb:

"Hallo zusammen,

es gibt eine gute Nachricht, alles ist da und theoretisch Versandbereit.

Theoretisch? Ja, die Boxen haben einen minimalen makel. Das Papier ist nicht das gleiche wie beim letzen Muster, woraufhin ich die Bestellung ausgelöst habe. Da befinde ich mich gerade in der Klärung mit der Druckerei, aber ihr könnt euch vorstellen, dass da dieses Jahr nicht mehr viel passieren wird. Mal schauen, was dabei rauskommt.

Dennoch anbei ein paar Bilder, dass ihr euch darauf freuen könnt, was ihr von uns erhaltet.

Beste Grüße
Dom und ffmcloud"

- 22.12.2017 18:04

@ffmcloud schrieb:
"Danke für eure Unterstützung. Es fühlt sich auch etwas dünner an das Papier, dadurch wirkt auch die komplette Verpackung etwas instabiler.

Ich habe morgen Nachmittag ein Termin bei der Druckerei und bespreche das mit denen vor Ort. Ich werde natürlich Berichten was dabei rauskommt. - 03.01.2018 09:32"

@ffmcloud schrieb:
"Ich darf berichten, dass wir kostenlosen Ersatz bekommen. Mit der Lieferung sollten wir noch diesen Monat rechnen können.

Das Papier ist beides von gleicher Qualität, kommt aber jeweils von einem anderen Lieferanten. Ist doof gelaufen, aber kann passieren. Offiziell ist es kein Fehler, da die Qualität des Kartons nach Norm/Richtlinien die gleiche ist und bei der Bestellung (und bei den Muster) nicht weiter spezifiziert wurde. - 04.01.2018 17:13"