Plugins? Who likes 'em? Just code your own damn emulator from scratch if you want controller support so much. Not that complicated. Steve Sent from my iPhone
HMMMMMMMMMMMMM.............. that is a great idea. Slow as fuck, but they even have Yabause ported to PSP. This really was a kinda back burner idea I was tossing around for when I'm done Oh, and AamirM: I was planning to use Qt, so I might just try that.
N64 is about the limit on the PSP, and many of those games won't be full speed. DC isn't even a consideration. The only reason the PSP was mentioned was to point out that getting rid of plugins forced devs to all work on the same code instead of all working on their own plugins. That's good for a port, but not so good for the original program (debatable, but we won't get into it again). Yabuse for the PSP was funny - more of a proof of concept than a real attempt to get Saturn emulation on the PSP. The Saturn is complicated - too complicated to expect a C++ emulator written for a modern PC to work at any reasonable speed on the PSP. Saturn on the PSP will have to wait for someone to be interested enough to make an old fashioned, mostly assembly emulator from scratch. To get closer to the topic, nulldc would have been interesting to work on for the PS3... if Sony had every let OTHEROS devs have proper access to the RSX. Damn Sony...
Still, my biggest issue with NullDC is that you can't use a controller without something like PPJoy. I wish I could just plug in my 360 controller and go with it.
Tried nullDC yesterday. Unfortunately Sonic Adventure 2 lagged to hell when in a level. I really need a computer with a dedicated graphics card. >_>
Hay guize, I've been trying this out with a couple of NAOMI games and it's pretty sweet. However, has any work been done on getting Dreamcast games up in a non-bastardised format (no custom intros, texture/movie downsampling, etc.)? I've avoided the DC "backup" scene so I'm pretty out of the loop.
A lot of games are being distributed in a '.GDI' format now, which was intended to solve that. Personally, I dislike the format altogether just because it's not really much of a format at all. A GDI release is made up of a .GDI file and a bunch of track files. The GDI is essentially a simplified Cue sheet, and the tracks are the same track1.bin, track3.bin, etc. files that you get when you rip a disc with BBrip. So the resulting images are only useful in an emulator. Had someone taken the extra step, the pieces could've been re-packaged into an existing format (even bin/cue) that would still match the correct track structure of the GD-ROM but also be burnable and bootable as an MIL-CD with no changes required as long as the game was small enough. Though I believe the format was developed specifically for emulators, so this probably wasn't a thought.
I have the same exact problem, and is the reason why I don't do so much DC emulation on this computer. Sonic Adventure 1 may work ok, but unless that's preferred over SADX, I can just play SADX natively on PC
Yes. It's called GDI. It's used by TOSEC and redump.org. See http://dumpcast.thekickback.com/. GDI was designed to be an exact preservation format for GD-ROM discs, dumped directly on the Dreamcast using httpd-ack in conjunction with the Broadband Adapter, which you said [BBrip]. Check the Dumpcast link for an explanation of the design of GD-ROMs and the GDI format. As such, it is the optimal way to distribute game data, but it cannot be burned. In addition, there is no way (and no point) to include burning and MIL-CD data due to how different the original GDs are to the hackish burns. There are many variables that change. First and foremost, the majority of games will require modification of the data to fit on a CD-R. Next, the bootsector and session layout have to be exactly configured. Finally, the most advanced releases do fancy things like edit the file order on the disc for optimization and shrink packed AFS files. It's really best to keep the preservation dumps separate from burnable releases. Your first stop should be Dreamcast Resurrection.
Hmm.... I wonder how reliable a Katana unit would be for backups. I'm going to start tracking one down, I'll use it to perfect nullDC. (Test all the Shinobi, Ninja, etc. libraries)
Has there been any known development yet? I'm not too sure how or where to track down post-open-source development.
The points you make are irrelevant, because they aren't obstacles to the boot process. My "as long as the game was small enough" statement covered your file order and shrinking arguments. That wasn't my point. Consider the normal structure for the average Dreamcast game: Track 1 - Data Track 2 - Audio: "This should not be played in a normal CD player" Track 3 - Data, at LBA 45000. This exact same structure works fine on an MIL-CD, as long as track 3 starts at LBA 45000. A similar structure was used for some of the later Dreamcast releases that couldn't spare 11700 sectors for an opening audio track. The IP.BIN boot sector is at the beginning of the LBA 45000 track, just like a real GD-ROM. The actual problem with my argument was covered in the link you provided: MIL-CD's require the 1st_read.bin files to be scrambled. This was the one thing I forgot about when I made my previous post, which makes the universal image I had hoped for impossible. Still, it's disappointing that they couldn't have packaged these GDI's inside an existing format so they could be mounted in a virtual drive.
You can use the PuruPuru plugin to use controllers right now. Well, there have been lot of fixes lately. Last fix was 6 hours ago. Current Issues tracker: http://code.google.com/p/nulldc/issues/list Current Source and Revs tracker: http://code.google.com/p/nulldc/source/list
Remember, my port is locked down until I get it working decently on at least x86 Windows and Linux. The official version is still being worked on, yes.
Thanks a lot for that! Though, from what I'm seeing, it looks like you need to be able to compile that stuff to use it... Ah well, guess I shouldn't be surprised.
