Running DSP-1 Homebrews

Hello everyone, I've been thinking about writing some experimental homebrew ROMs that use the DSP-1, but I've come to a huge issues: I can't figure out any ways to run such ROMs on emulators or flash cartridges.

I've been looking around, and most emulators seem to have no way of telling that the ROM is meant to run with a DSP-1, rather than a DSP-1b or a DSP-2. I believe this sort of thing has been achieved in old versions of bsnes, but I can't figure out how to get this on recent versions of higan with homebrew ROMs.

As for flash cartridges, I haven't tried any, but I imagine that the sd2snes and Super EverDrive with DSP module would have the same problem. I also imagine that a Super PowerPak or a Super EverDrive with a DSP-1 soldered on would be a good way to do this, but I don't have either of those.

Anyway, if any of you have advice or have tried this yourself, your information would be greatly appreciated.

Bonus question: as a side note, do any of you have any ideas about whether or not using a DSP-1 BIOS ROM as part of a homebrew application would be infringing upon copyright? Might it be considered transformative enough to be protected by fair use? I'm just throwing out the idea, I know nearly nothing about fair use myself.

Shipping copyrighted compiled code would be illegal.

I guess that's why I don't see anyone talking about homebrewing with the DSP-1 then...

Distributing the DSP firmware infringes copyright, but distributing code that simply uses it (or a compatible black-box implementation) doesn't. Otherwise distributing software for any computer with an operating system would be illegal without the OS maker's permission (and as much as Apple would like that to be the case, it isn't)

and Nintendo generally, and SEGA of yore, and numerous hardware manufacturers, including those who make printers, etc. etc. but this is a digression.

Yes it is! Testing ROMs, that's what we're here for.

(appreciate the info though)

I believe the sd2snes has a way of deciding to use DSP-1 or DSP-1b since I read somewhere that Pilotwings on the sd2snes correctly uses the DSP-1 chip. However, I think Super Mario Kart will use the DSP-1B chip, and I don't think there is anything in SMK's code which tells it to use the DSP-1 or DSP-1B, so maybe ikari has it configured in the sd2snes software on a game by game basis.

Correct:

Yes, this is a tiny bit of a pain. A while back, I hacked that "NEC DSP test ROM" to use the Mario-Kart-style DSP1 addresses (rather than Pilotwings-style addresses) because some emus (& my SNES UFO8 copier) would only do the Mario-Kart addresses if the flag was set to DSP and didn't have a Pilotwings CRC. A bit of a mess, there.

Good, so all I gotta do is change the header name to PILOTWINGS, and presumably use the same mapping as Pilotwings. The sensible solution

> do any of you have any ideas about whether or not using a DSP-1 BIOS ROM as part of a homebrew application would be infringing upon copyright?

It would be illegal, otherwise I would include it. Instead, I'm simultaneously trying my best to talk No-Intro into including the firmware with their releases, and also aiming to supplant them as the eminent SNES games database in the near future. If I fail the former, it will at least make the latter easier.

> I guess that's why I don't see anyone talking about homebrewing with the DSP-1 then...

No, that would be because only higan and MESS MAME can run the firmware, and they have way too small of a market share to do anything interesting with them.

Other emulators use HLE that you could at least use for homebrew, but it would run at infinite speed (literally every operation completes instantly to the emulated code.)

The real fun though would be writing your own firmware instead of borrowing the DSP-1's.

> Correct:



Actually, this is also incorrect. The PAL version of Pilotwings uses the DSP-1B.



... or at least, it can.



And this is why the firmware needs to be appended to the ROMs to make them unique. Otherwise it becomes impossible to preserve both of these boards simultaneously.

> some emus (& my SNES UFO8 copier) would only do the Mario-Kart addresses if the flag was set to DSP and didn't have a Pilotwings CRC. A bit of a mess, there.

Right. It's not just "HiROM" and "LoROM."

These are the various PCB configurations that exist: https://preservation.byuu.org/Boards
(and there will be more once the JP set is dumped.)

You cannot detect which board to use based on just the ROM header alone.

Like iNES, but to a lesser extent at least, it's a problem that needs to be solved. Unfortunately every other SNES emulator has been dead for five and a half to ten years now. So there's no one to collaborate with on a new standard, and so anything I try and do to fix this will be seen as a "proprietary" format.

Is there anything actually documenting that manifest format, by the way? I don't fully understand how those masks work.

My intention was to formalize it once I've completed dumping my Japanese set and thus have 100% of boards adequatey described. Once there's no chance for surprises, I'll go through a final refinement and open it up for input from others.

The masks basically act like address lines are not connected.

So when you see mask=0x8000, it's saying A15 is not connected (eg LoROM-style adressing; 32K banks.)

So imagine you have a 24-bit address like this: 01234567 89abcdef ghijklmn
mask=0x8000 removes the bits set from the address, thus you get: -01234567 9abcdef ghijklmn where - = 0
It converts the SNES address bus location to the physical ROM location.

I don't bother with masking the higher bits that aren't connected because there is also mirroring in place for when the ROM address exceeds the ROM size. Which you can also manually control with the size= attribute.

It's a farily clever way of handling how these boards were designed. Easy to set a mask that will select between all the various memory configurations for NEC uPD data/status regiser selects; handles the carts that mirror the first 8KiB of a larger SRAM chip in one region while exposing the full SRAM area to another region; etc.

Well that's rich. So they just didn't care if the plane crashed in attract mode?

Obviously, since it uses both the DSP-1 and DSP-1B, the correct solution is to detect the PAL version of Pilotwings and then select one firmware or the other at random.

Will the plane crash this time? Stay tuned and find out!