While the forums were down 64DD cart conversions have been released into the wild! LuigiBlood has been kind enough to host them along with the original dumped disks. So no, there wasn't a magically "hardware revision 3". They do use a specialized bootstrap though, implementing the system initialization and disk initialization usually performed by the IPL. It's a much higher-level hack than Dezaemon is, making no attempts to simulate register behavior. Read/write requests are converted directly into EPI requests. All confirmed working on a 64drive. Use menu 1.12d or later. They've also been tested on a v64jr using a bootloader with the correct seed value. Thanks to LuigiBlood Project 64 not only supports these conversions but also has mouse support. You will need an LLE plugin to use Polygon Studio due to how geometry is selected. The new GlideN64 plugin is safest HLE choice though its LLE support will not work properly with some titles. Cen64 and MESS also will run them unless I'm mistaken, and there should be a fork of Mupen that does the same. Notably the Everdrive64 will not load them as of yet and it's probably the same reason it won't run the Dezaemon XD hack. Full functionality with that thing can be somebody else's project. A lack of documentation seriously doesn't help any. The CIC is a unique one (5167) using the same seed as the 64DD IPL. Secret number is 0 8 3 C 6 C 7 7 E 0 B 1. Obvious features not implemented: Can't use a modem or video capture cart with these. Would require additional reverse-engineering and hacking to provide similar functions via USB. RTC reports the time of the disk pressing. The RTC differs in its storage format and access method from Animal Forest significantly. In all cases, games using the clock only load the time once, usually before actual gameplay, and time continues to tick forward based on the system clock. This is the same way Animal Forest functions and why it is fully playable even without the RTC present unless your hard/software collides with it. In all cases this just sets the timestamp for saved data. Krom is already translating Sim City 64 and I'm doing an English version of F-Zero XP.
I`m wondering why this would never work with the Everdrive 64. "Sorry Everdrive 64 folks, but this will just never work on your flashcart."
Maybe it's possible to work this out on Everdrive 64 v3 hardware. But the OS has to support the bootstrap correctly first. EDIT: I don't know if it would be worth it especially if the price of an ED64v3 pretty much reaches a 64drive's. Why it doesn't work? First it has to support the custom bootstrap, then it probably needs a way to enable writing to the cartridge space. And Zoinkity's stuff never worked on an ED64 ever.
If they at least had a specification or something maybe, but then the hardware for each version varies as well. If SRAM really is saved to the end of cart space on a version 2 then F-Zero XP couldn't work on it. At any rate, somebody actually experienced with fiddling with that thing would have to take it upon themselves to do the necessary modifications. Since it runs fine in more than one flashcart as far as I'm concerned this is an ED64-specific problem beyond the scope of the original hacks. Some obvious issues: I know it's menus read some metadata from the cart headers and this caused problems with previous patches. These cart headers are structured differently, eliminating some of the metadata in order to embed important disk info. They also need to support the seed, meaning somebody with the capacity to build a menu will need to set up an additional test for it. The 64drive already supported it since it happened to support the 64DD IPL's bootstrap already and the tests coincide on account of building the new bootstrap against the IPL. For the games to work properly you need mutable cartrom space. Chances are since it isn't incompatible with certain retail titles containing IS64 support it's safe to say it isn't writable by default. No idea how to turn it on, but that should be a simple patch. Nobody has determined why Dezaemon XD won't run on an Everdrive and that doesn't bode well. Granted this works in a very different manner and may be related to the SRAM issue, but it really isn't remarkably different from the original ROM either. These are solvable, but I'd like to avoid the flood of "why doesn't this work on ED64?" emails by simply stating that it doesn't. Do have a terrible track record for breaking Everdrives ;*)
Since I own an ED64v2 I'm out of luck. No problem there What about emulators? I've tried mupen64plus with winmupen front end and the first public release of gliden64 and the only game I got to work was Dezaemon. The rest gave only black screen. Is there any emulator that already support those convertions?
And it was very easy to implement in Project64. And it's part of the official repo, just build or get a build from EmuCR and you're good.
I downloaded the latest build from EmuCR and it doesn't seem to have the graphics plugin. I also can get the latest build of GLideN64 to work with it either.
Sorry but it's not very well emulated. Graphics HLE is definitely not working right with this game. Have to deal with LLE via GLideN64 or angrylion, but on my PC it's stuttering a lot. I can't fix that. Not my expertise.
Nope. None of them supports 64DD. Only MESS does as of today. I tried to port the code to CEN64 but something's not right. Also, if Project64 emulated 64DD, I wouldn't have bothered to make it support conversions. It would have made a bit of noise too...
Well, that's sad. But how hard is it to emulate the N64DD anyway unless someone donates a used N64DD to the forum?
Someone can just port what's on MESS now. Not going to be me for now. If you make a N64 emulator on Android and make it support 64DD, yeah it probably would with some effort. Except there's none... and I don't see the appeal so you won't see me messing with emulators on Android.