It is currently Mon Oct 16, 2017 3:20 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 15 posts ] 
Author Message
 Post subject: Running DSP-1 Homebrews
PostPosted: Mon Sep 26, 2016 11:47 am 
Offline

Joined: Sun Sep 25, 2016 12:24 pm
Posts: 4
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.


Top
 Profile  
 
PostPosted: Mon Sep 26, 2016 11:58 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 552
Shipping copyrighted compiled code would be illegal.


Top
 Profile  
 
PostPosted: Mon Sep 26, 2016 12:34 pm 
Offline

Joined: Sun Sep 25, 2016 12:24 pm
Posts: 4
calima wrote:
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...


Top
 Profile  
 
PostPosted: Mon Sep 26, 2016 1:50 pm 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 429
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)


Top
 Profile  
 
PostPosted: Mon Sep 26, 2016 2:02 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
AWJ wrote:
(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.


Top
 Profile  
 
PostPosted: Mon Sep 26, 2016 2:09 pm 
Offline

Joined: Sun Sep 25, 2016 12:24 pm
Posts: 4
Myask wrote:
but this is a digression.

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

(appreciate the info though)


Top
 Profile  
 
PostPosted: Mon Sep 26, 2016 3:10 pm 
Offline

Joined: Sat Aug 06, 2016 10:22 pm
Posts: 15
Quote:
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.....
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 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.


Top
 Profile  
 
PostPosted: Mon Sep 26, 2016 3:44 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 327
Location: FL
suFami wrote:
so maybe ikari has it configured in the sd2snes software on a game by game basis.

Correct:

Code:
if(!memcmp(header->name, "PILOTWINGS", 10)) {
  props->dsp_fw = DSPFW_1;
} else {
  props->dsp_fw = DSPFW_1B;
}


Top
 Profile  
 
PostPosted: Mon Sep 26, 2016 6:40 pm 
Offline

Joined: Sun Mar 19, 2006 9:44 pm
Posts: 911
Location: Japan
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.

_________________
http://www.chrismcovell.com


Top
 Profile  
 
PostPosted: Mon Sep 26, 2016 10:26 pm 
Offline

Joined: Sun Sep 25, 2016 12:24 pm
Posts: 4
Revenant wrote:
suFami wrote:
so maybe ikari has it configured in the sd2snes software on a game by game basis.

Correct:

Code:
if(!memcmp(header->name, "PILOTWINGS", 10)) {
  props->dsp_fw = DSPFW_1;
} else {
  props->dsp_fw = DSPFW_1B;
}

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


Top
 Profile  
 
PostPosted: Tue Sep 27, 2016 9:34 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1338
> 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:

Code:
if(!memcmp(header->name, "PILOTWINGS", 10)) {
  props->dsp_fw = DSPFW_1;
} else {
  props->dsp_fw = DSPFW_1B;
}


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

Image

... or at least, it can.

Image

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.


Last edited by byuu on Tue Sep 27, 2016 9:48 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Tue Sep 27, 2016 9:40 am 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 137
Is there anything actually documenting that manifest format, by the way? I don't fully understand how those masks work.


Top
 Profile  
 
PostPosted: Tue Sep 27, 2016 9:52 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1338
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.


Top
 Profile  
 
PostPosted: Thu Sep 29, 2016 3:33 am 
Offline
User avatar

Joined: Sat Jul 04, 2009 2:28 pm
Posts: 140
Location: Wunstorf, Germany
byuu wrote:
Actually, this is also incorrect. The PAL version of Pilotwings uses the DSP-1B.


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


Top
 Profile  
 
PostPosted: Thu Sep 29, 2016 7:47 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 327
Location: FL
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!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: nocash, Troglodyte and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group