PowerFest 94's format

Post all database contributions here.
Post Reply
User avatar
C. V. Reynolds
Datter
Posts: 269
Joined: 17 Jun 2009 04:42

PowerFest 94's format

Post by C. V. Reynolds » 24 Jul 2018 21:58

Currently in the DOM the game PowerFest 94 is stored in an odd way. It's split into four separate entries though the files cannot function without each other. I've concluded this is wrong and I intend to change it. But the problem is there are two different ways to change it. I list the ways below.

1: PowerFest 94 files mended together into one file. Has the advantage of always being in correct ordering. The DSP files are stored this way currently as well. And it's also the way NES files are stored in the NES dat, of course. This way is probably more true to current No-Intro standards.

2: PowerFest 94 files kept as separate files, but all together in one DOM entry. This has more storage accuracy on its side from a point of view.

We can keep the other older entries as well (I'd just set them to be excluded from the dat). Both of the above methods would be added as dumps on the DOM, but only one can be the MAIN one and included in the dat.

Which one would be the best choice for now? I'm fine switching to method 1 unless there's a preference for method 2.

Hiccup
Datter
Posts: 525
Joined: 09 Oct 2015 11:29

Re: PowerFest 94's format

Post by Hiccup » 25 Jul 2018 11:58

I think 1) should be done, as it matches the rest of the dat better.
When xuom2 implements the multi-format feature we can have both types.
Last edited by Hiccup on 26 Jul 2018 11:59, edited 1 time in total.

User avatar
Tauwasser
Datter
Posts: 186
Joined: 04 Oct 2010 06:51

Re: PowerFest 94's format

Post by Tauwasser » 25 Jul 2018 22:33

I'd actually prefer the second option if we can manage. I thought the necessary changes were almost ready for prime time and only the redump verification functionality is currently broken? We should definitely move to split, but should consult with DAT users beforehand, so no nasty surprises pop up.

Screwtape
Posts: 30
Joined: 29 Aug 2017 08:46

Re: PowerFest 94's format

Post by Screwtape » 26 Jul 2018 03:11

I assume option 1 means just blindly concatenating the four dumps in some fixed order? That would work, as long as somebody somewhere preserves where the divisions between them are. In practice, that would be in the source-code of a tool like byuu's "icarus", but it'd be nice if there were some way to make an official No-Intro record too.

I prefer the purity of option 2, but would there be compatibility issues with tools like CLRMamePro that people use to validate their collections? Would people wind up with a .zip or .7z file containing four individual .sfc files? If so, that would probably cause confusion for emulators that "support" .zip-compressed games by grabbing the first file they see with the expected extension... but I don't think any such emulators support PowerFest 94 anyway, so maybe that's not a concern.

User avatar
C. V. Reynolds
Datter
Posts: 269
Joined: 17 Jun 2009 04:42

Re: PowerFest 94's format

Post by C. V. Reynolds » 05 Aug 2018 21:23

Thanks for the responses. I liked reading them, I can honestly say. :3

I too prefer the second option (purely because of the storage accuracy... I would also like split NES files to be an option), but will be going with the first option for the time being. Because, well, it's what No-Intro is already doing all over (mostly). This change is just to fix the problem quickly and shouldn't be seen as a choice having been made on what method is correct. I'm going with what doesn't change the system for now because I'd really like to get the matter fixed. We can still switch to the split method at any time if the decision is made.

I also thought about option 2's potential of confusing ROM manager programs, but I don't think it would happen. I know at least RomCenter can handle sub folders (and sub zips?). Files typically all in one folder, but with sub folders for games with multiple files. Redump.org's PS2 dat, for example.

Here's where we are currently:

1: The older four PowerFest 94 entries are left intact, only now excluded from the dat file.

2: A new PowerFest 94 entry was created. Default is currently the four files "stacked" in accurate order. It lists what the order is in the Datomatic.

3: The Alternate dump for the new entry (mentioned in item 2 above) is the split versions of the files. The accurate storage method. Different files on different buses, is it? I'm still learning this sort of thing.

4: We could switch the split files version to being the default at any time by changing which dump has the "other" designation in the DOM. I don't know what this will look like if we do, though. I'm guessing PowerFest 94 would be the name of a folder (or zip file) that contains the split files (like in Redump.org's stuff), but I don't know for sure. I think No-Intro has a system somewhere that has split files already, though. So... it'd be like that one. ;P

Regardless, it'll be really good when we can give the users the option to choose which method they prefer. :3

Screwtape
Posts: 30
Joined: 29 Aug 2017 08:46

Re: PowerFest 94's format

Post by Screwtape » 07 Aug 2018 07:25

> Different files on different buses, is it? I'm still learning this sort of thing.

That's always been my mental model, although sometimes people ask me to explain further, so I guess it's not an automatic and universally-understood model.

I mentioned this development to byuu, and he agreed to teach icarus (the "import ROMs to higan's format" tool) to recognise and support this concatenated PowerFest '94 ROM. However, he mentioned some other corner-cases you might want to look at if you're in the mood:

- Since PowerFest '94 includes Super Mario Kart, it logically also includes DSP1B(?) firmware, so that should be included too. Of course, SNES co-processor firmware is an issue that affects a lot of games, though, so it doesn't have to be solved for PF'94 right now. On the other hand, PF'94 doesn't appear on Wikipedia's "List of Super NES games that use enhancement chips", so we should ensure it doesn't get missed when the co-processor firmware thing gets decided.

- Sonic & Knuckles contains two different ROMs behind a memory-mapper that switches between them; one ROM is used when playing Sonic & Knuckles alone, or with Sonic 3 attached to become "Sonic 3 & Knuckles". The other ROM is a patch for Sonic 2, used when Sonic 2 is attached to become "Knuckles the Echidna in Sonic the Hedgehog 2". Currently, the DoM lists one ROM as Sonic & Knuckles (World), while the other is only available as part of a pre-patched Sonic & Knuckles + Sonic The Hedgehog 2 (World). byuu was playing with "lock-on technology" recently (much like higan already emulates the Super Game Boy, where you pick one cart and it asks what you want to add on top), and found the unusual cataloguing of this game to be quite frustrating; it'd be handy if somebody could add an alternate dump of "Sonic & Knuckles" that included each ROM separately (but probably not the concatenated version, since that would confuse matters).

- "So yeah, always more work to be done. But, this is good news. My gratitude to them."

User avatar
byuu
Posts: 4
Joined: 06 Aug 2018 16:48

Re: PowerFest 94's format

Post by byuu » 07 Aug 2018 11:29

Boo :P

Foreword, I get too pushy about things I care about, I'm sorry for that. I do appreciate the work being done here.

So, Campus Challenge '92 and Powerfest '94 are each single physical "cartridges." Each have four ROM chips inside, one menu + three games.

You really can't just take another game and put it in there, and expect it to work. Maybe you could swap a CC'92 and PF'94 ROM, but it's very unlikely.

Furthermore, the most intuitive concatenated ordering is menu+game1+game2+game3, but ... in truth, there is no ordering. The memory mapper controls which chips are selected. The only reasons I accept concatenation is to get a unique hash per complete game, and to deal with the vast majority that just absolutely refuse to accept split ROM games.

FitzRoy had this fascinating idea to SHA256 each file, sort the hashes, and then hash the list of hashes. It's certainly an intruiging concept. The key concern for me is the hash for SPC7110 games would change, for reasons I'll get to later.

But I digress ... back to CC'92 and PF'94. Both games contain a DSP1 (non-B) chip, a NEC uPD77C25 with 6KiB program ROM + 2KiB data ROM. As strict Harvard architecture without unaligned memory reads ... we can say that there's not only no absolute ordering (program+data or data+program)?, and not only that there's no endian (big or little?), there's not even a proper guarantee of whether the 24-bit program ROM instructions should be padded to 32-bits, and if so, what the padding byte should be. The official programmer for those chips expected 32-bit big endian with 0xFF padding bytes.

Having to pick something, my choice was 24-bit unpadded. The padding byte could be anything and still be valid, so I didn't want padding to interfere. I chose little endian to match literally every other ROM on the SNES, including all of the dumped coprocessors.

The DSP1 firmware is, of course, essential, and part of the game. And well, you all know my feelings on that. And if I had to order files for hashes, my proposal would be menu+game1+game2+game2+dsp1program+dsp1data.

HOWEVER, it gets even more fun!! This game just keeps on giving. The truth is, CC'92 and PF'94 are not properly preserved, and never will be :(

Both games contain another chip ... a NEC uPD78P214GC. This is an 8-bit microprocessor that contains an ALU (w/MUL, DIV, BCD), 19 interrupts (12 internal, 7 external, 2 priority levels), and, most importantly to us ... a 16384x8-bit program ROM, and a 512x8-bit RAM. This is undumped, and let's face it. It never will be dumped. It's as unlikely as the SNES PlayStation NEC MCU being dumped, and for the same reason: one copy of each of the two variants of CC'92 and each of the two variants of PF'94 exist in the world. Even though this chip has a read-out mode, nobody's going to do it. And this is EPROM data, so it's going to bit rot soon, and these single copies are going to be goddamned paperweights, but hey ...

Still, if we wanted to "do this right" for all of time, let's consider what we'd do if we DID have this ROM. Where would it go? If we stuck with the single-hash, my proposal would be:

sha256(menu+game1+game2+game3+uPD7725.program+uPD7725.data+uPD78214)

But this is getting pretty silly, isn't it? Split files are the only sensible form that won't invalidate this dump as a single merged file in the impossible event that one day, the uPD78214 gets dumped and emulated.

Right now, higan unfortunately uses HLE for this chip. That is what the deal is with this nonsense:

https://gitlab.com/higan/higan/blob/mas ... nt.cpp#L60

As Screwtape pointed out, my gratitude for you guys moving in the right direction here. I'll reciprocate by supporting your proposal, even with DSP1 firmware missing. To run this in bsnes/higan, I'll allow the DSP1 firmware to be loaded from the "bsnes/firmware/" folder, where it will search for dsp1.program.rom + dsp1.data.rom, if it's missing from the concatenated ROM file.

I do hope we can address this in the future.

...

Now let's talk other systems for completeness here. It may inform thoughts on PF'94, so bear with me please.

Sonic & Knuckles. A Mega Drive / Genesis cartridge that contains a 2048KiB program ROM, plus a 256KiB patch ROM. It also contains a passthru cartridge connector. The patch ROM is a Sonic 2 patch to convert the older game into Sonic 2 & Knuckles. The base cart maps that ROM in when Sonic 2 is detected as attached to it, that mapping is done by software.

No-Intro stores the base S&K program ROM, but without the patch ROM. So that ROM is incomplete. Again, there's no true mapping order, but the most sensible approach is program+patch if you were to concatenate them.

No-Intro further stores S&K + Sonic 2, and S&K + Sonic 3. But this isn't correct. They're not single cartridges, they're separate cartridges, unlike Powerfest '94 here.

Further, what No-Intro calls "S&K + Sonic 2" is actually S&K program + Sonic 2 (1.1) + S&K patch ... not Sonic 2 (1.0), and No-Intro lacks S&K + Sonic 2 (1.0) entirely.

Further, more games can be attached to S&K. Different games get you different Blue Sphere level selections (it's generated based on some hashing S&K does on the attached cartridge's ROM), and Sonic 1 unlocks the full Blue Sphere game.

Sonic & Knuckles is no different than the Game Genie. You wouldn't store Game Genie + <every game ever released>, right?

Expanding on this: we want to follow the same logic as the Super Game Boy (+ boot ROM) and Game Boy games, the BS-X Satellaview slotted cartridges and BS Memory data packs (both mask ROM and rewritable flash ROM), and Sufami Turbo with zero, one, or two slotted Sufami Turbo cartridges. One game entry per physical cartridge.

The case of Sufami Turbo + Poi Poi Ninja World + Poi Poi Ninja World is particularly interesting. It's tempting to pick the same game twice, but then they'll both be writing SRAM to the same location on disk. It pretty much falls on the user to understand how it's impossible for a single game to exist in two slots at the same time, and if they want to run this case, make a second copy of Poi Poi Ninja World. Which is why it's good to express to users the concept of "each entry is a physical game."

...

Now let's look at the Game Boy. There exists the MMM01 mapper, which merges a boot menu with 2+ other games. It's similar to PF'94 in that the mapper controls which game is mapped in at which time. But this time, these games exist on a single ROM chip. So even though you can't read it out from a Game Boy cart dumper in linear order, you can read out the ROM chip. And surprisingly, the ROM data is stored as game1+game2...+menu. Shit. This is a pain in the ass, since your standard Game Boy heuristics in an emulator will look at the usual ROM header location, and will think this is just an MBC1 game.

But the broader question becomes, do we act like MAME and store one file per physical IC, or do we act like bsnes and store one file per "intent"? MAME's approach is a real quagmire. DSP1 program+data ROMs would become one file, and literally hundreds of SNES games exist in both 2x <small ROM> and 1x <large ROM> variants that are absolutely identical in every way to emulators. In MAME's case, the MMM01 would be a single file, with the menu being last.

But if we followed my approach (and even higan doesn't do this now), the ROM should be split to a menu file plus a file for each game. My approach allows for one version of the 2x <small ROM> and 1x <large ROM> variants, allows splitting coprocessor firmware, and allows splitting the SPC7110 program and data ROMs. And if you want to talk the FEoEZ fan translation, the expansion ROM as well. All of which have different semantics.

There is also the Game Boy MBC1M mapper, which is kind of similar to the MMM01, only this time, it really does act exactly like a regular Game Boy MBC1 game. The MBC1 pins are just reconfigured to allow more ROM mapping at the expense of no RAM mapping. So this makes it rather inconsistent with the MMM01 now ... rats.

So you see, this is why higan doesn't split the MMM01 right now. It's a mess, and even I don't know what to do. From an emulation perspective, the MMM01 is awkward:

https://gitlab.com/higan/higan/blob/mas ... m01.cpp#L4

That's basically a pure hack around the arbitrary ordering of the ROM data.

...

So now onto the SNES' SPC7110 and SDD1.

The SPC7110 allows for a program ROM that is either 8mbit or 16mbit, and a data ROM that is either 8mbit, 16mbit, 32mbit, or 64mbit.

It just so happens that all commercial games are 8mbit. And even the FEoEZ fan translation's program ROM is 8mbit. But it can support 16mbit, and how do you tell if the ROMs are concatenated to one file? You can't. Is a 24mbit ROM an 8mbit program ROM + 16mbit data ROM, or a 16mbit program ROM + 8mbit data ROM? You can't know unless you split the files, or use a game manifest to tell you.

This does matter. Only the data ROM lets you use the SPC7110 DMA decompression function. Different registers control how the program and data ROM map and mirror onto the bus.

So for higan, I split these to program ROM + data ROM.

And then you have the FEoEZ fan translation ... it decided to expand the data ROM to 40mbit (on a physical cartridge, this would end up being 32mbit + 8mbit mirrored to 32mbit => 64mbit), and then throw in another 8mbit ROM that lives outside the SPC7110 and its memory mapping entirely.

So for higan, I kind of just hacked together 8mbit SPC7110 program ROM + 40mbit SPC7110 data ROM + 8mbit expansion ROM => 56mbit disaster.

In case you're asking ... they couldn't (easily) have expanded the program ROM. It would have caused parts of the data ROM banks to become inaccessible, and the game wasn't programmed to allow for that. The expansion ROM was a pretty brute-force hack, and similar to what I would have done. They made the best of a bad situation, and put out a stellar translation. But I can't deny it's a complete mess for emulators now.

The SDD1 is simialr to the SPC7110, but in this case, the up-to-64mbit ROM is basically just a single bus. There's no functional difference, and it all acts the same, so there is no logical divice between program and data, which is also the case for all other SNES ROMs.

...

Of course we all know about the NES. Currently, they are a combination of a made-up, imprecise, iNES header + program ROM + character ROM. I'd advocate a split program ROM + character ROM. And I don't know what to say about the iNES header. I'd probably store iNES 2 (NES 2.0) headers as a separate file for the sake of emulators without databases, since we lack a universal manifest format.

But you're gonna break every NES emulator in existence when and if you do this. Have fun with the fallout from that one.

...

We're not done yet. There's also the Nintendo Super System and Super Famicom Box.

In both of these cases, you have the base system with its own set of a bunch of various ROMs for different funky architectures. And then you have the games.

Each system has multiple game cartridge slots ... IIRC, the NSS has 3, and the SFBox has 2? I could be mistaken. The NSS "carts" (realy, raw PCBs) are each one game, along with some primitive signing ROM data, and they may have a DSP on them. The SFBox carts are actually multi-game carts, and can have 2-3 games plus an optional DSP on them.

Again, the way I'd do it would be each NSS game would be its own game in the database, and each SFBox cartridge would be the set of 2-3 games, plus any DSP firmware, so you'd get PSS61 = "Super Mario Kart + Star Fox + Super Mario Collection".

Trickier still is the base systems themselves. Neither the NSS nor the SFBox is a Super Nintendo, and so a Super Nintendo shouldn't be playing these games like they're SNES games. Even though you can get away with that on the NSS, though you'd be missing some DIP switch settings that control the games like your standard arcade games. Although you could hack around that too by emulating it as an SNES game with a DIP switch.

But ideally, you'd have to restructure your entire emulator to treat the NSS and SFBox as separately emulated systems, and devise a way to let users load a set of game cartridges into each.

There's also the Nintendo Gateway System, but I don't know enough about that one to really comment.

...

And that's it (for now!)

Are you questioning your decision to get into game preservation yet? Because I sure am ^-^;;

User avatar
Tauwasser
Datter
Posts: 186
Joined: 04 Oct 2010 06:51

Re: PowerFest 94's format

Post by Tauwasser » 11 Aug 2018 14:45

I'm pretty sure nobody wants to support yet another concatenated format. Ordering is going to be ridiculous.

The point of the DoM is to verify dumps and allow easy redumps. That's where it gets tricky with stuff that not many people can redump, like the DSP roms, that are attached to games that can be easily redumped.
byuu wrote:
07 Aug 2018 11:29
There exists the MMM01 mapper, which merges a boot menu with 2+ other games. [...] So even though you can't read it out from a Game Boy cart dumper in linear order, you can read out the ROM chip.
You can totally read it out in linear order and that's how my dumper does it. You just cannot read all at once for big ROMs without resetting the mapper a few times.
byuu wrote:
07 Aug 2018 11:29
And surprisingly, the ROM data is stored as game1+game2...+menu. Shit. This is a pain in the ass, since your standard Game Boy heuristics in an emulator will look at the usual ROM header location, and will think this is just an MBC1 game.
Well, the heuristic can be expanded fairly easily to look at the last two ROM banks and determine if the logo is there. The tricky part is that not all official MMM01 games set the correct mapper type in the internal header. You won't get around some sort of manifest in those cases.
byuu wrote:
07 Aug 2018 11:29
But the broader question becomes, do we act like MAME and store one file per physical IC, or do we act like bsnes and store one file per "intent"?
Answering that is tricky, because it can lead to undesired behavior. Right now No-Intro stores (for cartrdiges at least) the data in the most sensical order. There is one Game Boy game that is stored as one file even though it's actually on two chips. NES is obviously another case of that.

However, if we just blindly switch to storing stuff as single files split per "intent", stuff gets even trickier, because now the original mapped order must be recorded, i.e. where does each file get mapped onto the bus or buses. Secondly, what do you do with stuff where the menu was put into unused space? Game Boy Sachen games do this, and I think one of the MMM01 releases does this as well.
There is also the possibility to now build custom multi-ROM games that couldn't actually be done on real hardware, like switch one ROM in the middle for a ROM twice its size and expect it to work and all that. It gets complicated with this additional freedom.

On the other hand, taking the MAME approach might be a good compromise if we extend it with metadata, like individual checksums/matching rules for ranges in a ROM that can be linked to other DoM entries or something. I fear however, that a generic approach will always fall short and console-/game-specific approaches are needed.

byuu wrote:
07 Aug 2018 11:29
There is also the Game Boy MBC1M mapper, which is kind of similar to the MMM01, only this time, it really does act exactly like a regular Game Boy MBC1 game. The MBC1 pins are just reconfigured to allow more ROM mapping at the expense of no RAM mapping. So this makes it rather inconsistent with the MMM01 now ... rats.
That isn't a mapper and mappers don't act like games. The fables MBC1M "mapper" is actually just a regular MBC1 on a DMG-M-BFAN or DMG-MC-DFCN PCB instead of a DMG-BEAN PCB. That's why the board information is so important and not some magical mapper information.

I actually think, the NES could use some love in that regard to pare down the number of "mappers" currently in use. Your SNES library is also a great start, but I'm not sure if you ever created schematics for every board or just dumped a memory map and that's it.
byuu wrote:
07 Aug 2018 11:29
From an emulation perspective, the MMM01 is awkward:

https://gitlab.com/higan/higan/blob/mas ... m01.cpp#L4
Still don't correctly emulate that one, I see ;)
byuu wrote:
07 Aug 2018 11:29
That's basically a pure hack around the arbitrary ordering of the ROM data.
It's not arbitrary, it's just that all high-order address bits are reset to 1 instead of 0. RA14 switches acts as usual (so 0 for 0x0000-0x3FFF and 1 for 0x4000-0x7FFF, i.e. it tracks A14 on the GEC), but the high-order address bits are double-buffered and writes cannot be seen until the mapping is activated.

--

Pretty sure we all mostly agree that the state of affairs right now is sub-optimal. The real question is what to do about it. Redumping/verifying every image out there and creating manifests is a very time-consuming task. It could be done for Game Boy, because I and several others have enough information. NES and SNES we would have a good starting point with your and Bootgod's documentation, but it would probably involve some work.

The real question is how to document the PCBs and mappings. For newer systems this isn't such a concern, because mostly they're just one linearly addressable ROM and a serially-addressable EEPROM and that's it. Older systems had a few tricks up their sleeves.

If you're willing, we could totally come up with some description that is concise per game -- just which PCB it uses, configuration like solder bridges, resistors, battery populated etc. -- and a detailed description per PCB like ROM, RAM mapping, mapper chips, additional chips, configuration options. Of course, these should be specified in a way that they're generic so more emulator authors can get behind the idea.

cYa,

Tauwasser

User avatar
byuu
Posts: 4
Joined: 06 Aug 2018 16:48

Re: PowerFest 94's format

Post by byuu » 13 Aug 2018 03:40

I'm pretty sure nobody wants to support yet another concatenated format.
I sure don't. What people don't get when I'm arguing for it is that I'm doing so only as an olive branch to people who are even more determined to never use split files.

Ultimately, whatever we choose is going to end up being a ZIP file, or a ZIP file with a custom extension. I don't like ZIP at all, but I certainly understand the inevitability that ZIP will be the format chosen.
Well, the heuristic can be expanded fairly easily to look at the last two ROM banks and determine if the logo is there.
It can, and that's exactly what I do, it's just annoying.
That isn't a mapper and mappers don't act like games. The fables MBC1M "mapper" is actually just a regular MBC1 on a DMG-M-BFAN or DMG-MC-DFCN PCB instead of a DMG-BEAN PCB.
I am quite aware that the MBC1, MBC1M, and MBC1S (sonar) are the same physical chip.

And yes, PCB information would clarify the wiring for us. It's a shame there's no project like preservation.byuu.org to record all Game Boy PCBs <> SHA256 sums that I could pull from.
Your SNES library is also a great start, but I'm not sure if you ever created schematics for every board or just dumped a memory map and that's it.
The best I've done is: https://preservation.byuu.org/boards/SycB

Record the information observable to emulation. The hardware level trace details would be absolutely psychotically expensive to emulate (and bsnes is slow enough, right?), and with my skill level, I may have to desolder chips to plainly see where all the traces go.

Someone should absolutely do this, however.
Still don't correctly emulate that one, I see
Nope, my Game Boy core doesn't get a lot of attention.

If it had a thriving scene like the NES to document it properly, it would.

But every time I try and implement new discoveries, it just ends up that the new discoveries were incomplete and it breaks my core even more. So I stopped touching it.
NES and SNES we would have a good starting point with your and Bootgod's documentation, but it would probably involve some work.
The key thing is, I can't do it alone, or everyone will say it's "byuu's proprietary format", and indeed it'll only work in bsnes/higan.

You can find posts from me in 2006 trying to work with the ZSNES developers to come up with a standard. I've been calling for collaboration since at least then, and to this day, nobody else supports any kind of manifest format whatsoever. My "go it alone" approach keeps changing, because I'm still dumping new games on new PCB types, and understanding new limitations I hadn't thought of before. I'm hoping that if/when I ever complete dumping every unique PCB type, I can at least come up with my own stable format.
If you're willing, we could totally come up with some description that is concise per game -- just which PCB it uses, configuration like solder bridges, resistors, battery populated etc.
I think it needs to be per-system, as you agree. But we should share as much as possible between them.

In higan/bsnes v107, I've moved to separating the documentation between "what's physically on this PCB" and "how does this PCB work?" -- under the observation that the former is a whole lot easier to make into a stable format. The latter is still a key concern, but thankfully, that can be emulator-specific.

User avatar
C. V. Reynolds
Datter
Posts: 269
Joined: 17 Jun 2009 04:42

Re: PowerFest 94's format

Post by C. V. Reynolds » 21 Aug 2018 23:58

Welcome to the forum, byuu. You'll find I dance in and out. Especially if I'm feeling low or when my computer's PSU is preparing to die. It's always good to hear words of appreciation. :3

I hadn't thought about the DSP1 in PowerFest 94. But I guess my thoughts on it are the same as it's always been. I'd like to include it with PowerFest 94 (and include DSPs with any games that need them), but the current DOM makes it difficult. When the DOM gets its update it should be better and easier to handle such things.

Fascinating hearing about the Sonic & Knuckles situation. I too have long questioned the frustrating situation with the Sonic games here at No-Intro. But I didn't really know where to start at the time, so I gave up. I'd like to give it another try sometime. Even if it means old emulators can't run the images due to their lack of proper lock-on emulation. Users can always keep the old files around for themselves anyway. I think it would be good to do.

The extra data at the end of Sonic & Knuckles + Sonic The Hedgehog 2 is the patch that puts Knuckles in Sonic 2, right? Where would that go in the Sonic & Knuckles ROM? That would ideally be a file of its own, right?

Screwtape
Posts: 30
Joined: 29 Aug 2017 08:46

Re: PowerFest 94's format

Post by Screwtape » 25 Aug 2018 07:33

I realise you're waiting for a response from byuu, but I'm not sure how regularly he checks this forum, so...
C. V. Reynolds wrote:
21 Aug 2018 23:58
The extra data at the end of Sonic & Knuckles + Sonic The Hedgehog 2 is the patch that puts Knuckles in Sonic 2, right? Where would that go in the Sonic & Knuckles ROM? That would ideally be a file of its own, right?
As I understand it, yes. Since the S&K ROM and the Sonic 2 patch are not part of the same address-space, they should be stored separately, not concatenated.

KingMike
Posts: 405
Joined: 22 Sep 2012 16:36

Re: PowerFest 94's format

Post by KingMike » 03 Sep 2018 06:38

byuu wrote:
13 Aug 2018 03:40
And yes, PCB information would clarify the wiring for us. It's a shame there's no project like preservation.byuu.org to record all Game Boy PCBs <> SHA256 sums that I could pull from.
The most I could have done is photograph the PCBs of my personal collection of something like 200 GB carts, but it is a sad state that the best camera I had around was my 3DS. So they're quite blurry but I tried to get as close to readable photos of the chips as I could, though it's probably still not very good.
I don't know if such photos are desired.

I was particularly curious production date stamps and a few of them surprised me.

User avatar
Tauwasser
Datter
Posts: 186
Joined: 04 Oct 2010 06:51

Re: PowerFest 94's format

Post by Tauwasser » 03 Sep 2018 17:55

I actually have pictures (front, back) and schematics for all PCB types I own. That's 68 Nintendo PCBs and some unofficial PCBs so far. I'm currently (very slowly) building a kind of database application for my homepage, but it's not ready for prime time yet.

Post Reply