Warning: Long post! In a post on a different forum (http://www.assemblergames.com/forum...on-the-horizon&p=668766&viewfull=1#post668766) someone mentions about Krikzz maybe going back and working on the program code for the current Everdrives. This made me wonder what improvements we'd like to see on the Everdrive 64, in case Krikzz does ever decide to add more to the ED64 feature list, and I've listed the ones I could think of here. If you can think of any others, then please describe them (and if you think any of my suggestions are wrong or just plain stupid then please say so). To be honest, I think the ED64 is almost perfect as it is, with Gameshark code support, better controller pak management, and fixing the two ED64 (semi)incompatible games, being all I think it really needs to be more or less perfect. But I'll list everything I can think of, including what I remember other people asking for. I'll post this at both http://krikzz.com/forum/index.php?board=4.0 and http://www.assemblergames.com/forums/forumdisplay.php?110-Everdrive-64, so all ED64 users can potentially add to the list. 1. Gameshark code. This is the only one I really care about, and Chilly Willy is already working on it, but I know he's busy with lots of stuff, and anyway two or more people working at something can only be a good thing. There are some fantastic cheat codes (including some not-really cheat codes, that instead alter the games function to add new features, or make beta/prototype features appear in the game, or to make the controls of a given game more comfortable, etc), and if these codes could be used on the ED64 (sadly, the hardware cheat devices are incompatible with the Ed64, so to use these codes on an ED64-equipped N64 the ED64 would have to do the work of the cheat code engine) then that would be *fantastic*. All the more so if there was an easy to use menu system that would read the codes off the SD Card (say from a text file, either one .txt file per game, or one overall .txt file containing cheats for various games), and allow the player to easily enable/disable any codes they chose for a particular game. If there is one thing that could really benefit the Everdrive 64, this is surely it. It would not only allow you to cheat on, or play differently, or even improve some games, but would mean that we don't have to rely on the ever dwindling number of Gamesharks (surely the most unreliable N64 addons ever, due to being cheaply made). If you do one thing for the ED64, Krikzz, please consider this. It probably won't be easy to do, but it will be well worth it. 2. Improvements to the controller pak management. It would be great if this was made into a proper menu drive program, that allowed you (via on onscreen keyboard) to name the files that were produced on the SD Card from the controller pak, that allowed the user to copy individual saves to and from the controller pak/SD card, and to format the controller pak. And if the ED64 could create the .MPK files as it needed them, as opposed to their having to already be a file on the SD Card. Also, I know Krikzz has already made a system where the ED64 can automatically copy an .MPK to the controller pak before a given game starts, but he's disabled it for now. Personally I'm not bothered about this feature (though some people will love it, no doubt), but if it does get enabled in future software updates then please make it possible for the user to disable this feature via the ED64's settings menu. 3. Making incompatible games work with the ED64. As far as I know, only two games now have problems with the ED64; Dezaemon 3D and Animal Forest. Dezaemon 3D works OK, but can't save as the ED64 doesn't simulate the required 768kb protocol. Would this be easy to implement on the ED64? Animal Forest includes a realtime clock on it's cartridge, which I imagine is impossible to simulate without adding extra hardware to the ED64? Also, the hacked Super Mario 64 files refuse to run on a real N64 (with or without an Everdrive 64 attatched - they are emulator only), but they are apparently next to impossible to fix, unless the author of the editor that made them updates the emulator to create files that work on an N64. 4. ZIP/archive support. This isn't too important, I think, as there are so few N64 games, and 8GB + SD cards are so cheap that you can easily afford an SD card that will hold every N64 rom unarchived, and sometimes duplicated (i.e. Perfect Dark might be in say /First person Shooters/ and /P/ folders), plus ZIP support would make loading slower (due to the time needed for the N64 to unzip the file) but I don't know how much slower this would be. Does anyone think ZIP support is necessary? 5. Automatic patching of ROMs. Not to fix game compatability, as 1.29 already does for Banjo Tooie, but for game hacks. But there are so few game hacks for the N64 that this isn't necessary, as you can just perform the patch yourself and put the few patched games on your memory card, and as noted in point 3, SD Card space isn't a problem on the Everdrive 64, really. 6. The ability to delete files from the SD Card. It would be great if, when you position the selection bar over a game (whereupon you can then press START to load that game), if you press C-Down instead, then a menu comes up saying; Delete [game name] Delete [game name]'s game save Delete [game name] and it's game save Cancel (the two game save related menu items would only appear if the game had a gamesave in the \ED64\SAVE\ folder. And in the menu, selecting "Cancel" would take you back to the main menu. Selecting any of the 'Delete's would ask "Are you Sure, Y/[N]" with the "N" highlighted, and the user could press A or B to return to the main menu (B is cancel, A is select, but in this case ("Are you Sure, Y/[N]") selects N (for no) which is the same as cancel), or the user might press right on the D-Pad or analogue stick to move the highlight to the Y in the "Y/N", and then press A to select Y, and the ED64 would delete the file(s). Actually, I think it would be better if instead of deleting the files, the files would get moved to a temporary directory, that the user could later sort through on their PC. I.e. if the user choose to delete Diddy Kong Racing (U).Z64 then the file "Diddy Kong Racing (U).Z64" was moved to a directory called \User deleted files\ and the save (if it existed) file Diddy Kong Racing (U).eep would be moved to \User deleted saves\ 7. Regarding point 6, since C-Down would now be used to delete files, how about if pressing Left Shoulder Button loaded the last loaded game? And when the user pressed the Right Shoulder Button, then the game save mechanism for the selection game could be chosen from a menu, including an option to select the default (known) option for each known game. 8. Skinning the ED64's menu system. Personally I've never cared about skins, but some people really do like being able to arrange things to their own liking (such as being able to choose the background colour, the colour of the selected game's text, the colour of all other games' text, the colour of folder's text), and several people have asked about making the ED64 menu system display the box art for the currently selected game. If anyone (Krikzz or anyone else) does decide to make the menu skinable, then it might be an idea to ask users what they want first, to see what the majority favour. Also, I know some people might want to suggest snapshot save/loading on the ED64, but that's apparently impossible, as (Chilly Willy said) the N64 has write only ports that would need extra hardware on the ED64 to monitor them, so unless Krikzz designs an ED64 v3 then snapshot load/saving isn't an option. And to be fair, most N64 games do have the ability to save anyway, and it's only games like Turok 2 that really make you wish there was a snapshot ability (in Turok 2 the checkpoints can be miles apart...).
I definitely support 1.Gameshark code use 6. The ability to delete files from the SD card I would like it better if, when you deleted a file it gets permanently deleted, also the ability to delete files off of the mempak. Everything else is not important to me. Points 2,7, and 8 I wouldn't mind seeing, but I think that what you talked about would be all too much work for Krikzz to make possible when the out come is not all that great. I'm satisfied being able to customize my ED64 wallpaper. #4 is something we really don't need at all.
2. Improvements to the controller pak management i support this. i would really like to backup/restore individual save files and option to write the associated .mpk file to the controller pak after choosing the game and before the game begins. it might decrease the controller pak's life but this option might be disabled and backuping/restoring individual save files can be used for the cautious ones. i would also like a small cover of the game on the menu select screen. i know it will slow down the menu and it is hard to code but it would be a great future. though it would be better if krikzz could spend his time on a more important future than this. maybe someone knowledgeable with N64 can provide tips to krikzz for a cool menu, or write it himself/herself etc. just wishful thinking.
One thing i would really like to see is multiple save support. Maybe bring up a menu to select which save file to load along witg the rom.
It would be good if the Everdrive 64 had both a "last loaded" menu and a favourite menu, so that if you hold down say C-Left, then you get a list of the last ten different games loaded, and you can choose from any of those to load. This is what happens in the SNES emulator ZSNes. Also, it would be nice if you could define ten games that would be listed if you press C-Right - the files could be defined in a text file on the SD Card, called fav.txt and the format would be the path and name of each file, so that the text file might contain; \GAMES\Banjo-Kazooie (U) (V1.0) [f1].z64 \GAMES\Banjo-Tooie (U) [!] (patched to work on Everdrive 64).z64 \GAMES\Body Harvest (Europe) (En,Fr,De).z64 \GAMES\Conker's Bad Fur Day (E) [!].z64 \GAMES\Duke Nukem - ZER0 H0UR (E) [!].Z64 \GAMES\GoldenEye (Europe).z64 \GAMES\Jet Force Gemini (U) [f1].v64 \GAMES\Perfect Dark (E) [!].v64 \GAMES\Robotron 64 (E) [!].z64 \GAMES\Super Mario 64 (U).v64 Ideally the limit for both the 'last loaded' and the (user defined) favourite list would be higher than ten, say one screen full of game names. I think it would be ideal when you select delete if instead of being asked "Are you Sure, Y/[N]" as I previously suggested, the user should instead be asked "Do you want to Delete, Move, or [Cancel] ?", with cancel being the default option, and the user has to press left or right to reach any of the three options, and of course delete means remove from the card, move moves the game to the \User deleted files\ folder, and cancel returns to the main (game load) menu. That's a good idea. It would would allow in effect different 'profiles' (different saves for different players) to be used, so that people could use their own saves in games that don't allow saves to be named, or don't have enough save slots for the number of players who play on that game on that N64.
I would go for : 1. GameShark Support 2. Better controller pak management. I don't think deleting features are all that great. Just take out your SD card and put it in your computer. You'll have less chance of deleting a game by mistake that way. Of course game compatibility is one very important point. I don't personally care for those games but for the sake of saying the device plays all known commercial games, that feature could be important! Thanks for making this thread.
Does ED64 work with an actual gameshark? Probably not. Anyway, yes that support is always needed, as is better controller pak management. ZIP file support on ANY flash cart is unlikely and wasteful. You'd be stuck waiting for the zip to be extracted every time.
No, though it's not strictly the ED64's fault; a Gameshark is designed to react differently according to if it's plugged into an N64 or into another Gameshark. If the Gameshark is plugged into an N64 then the Gameshark functions as a cheat device, as you expect. But if it detects that it's plugged into another Gameshark (and that that Gameshark is plugged into an N64, which it has to be otherwise no power will get through to the top Everdrive),then the Gameshark automatically tries to update it's firmware/data by copying the code/data from the other Gameshark. This is so that if a Gameshark becomes corrupted then it can be fixed by plugging it into a working Gameshark. The trouble is, when an Everdrive 64 is plugged into a Gameshark then the Gameshark thinks the Everdrive is another Gameshark, and so instead of booting into cheat device mode, the Gameshark boots into update mode, and tries to read the Gameshark code from the Everdrive... I don't know if this can be fixed by altering the Everdrive's firmware (I really doubt it though), but even if it did work, it would still leave us having to trust the unreliable (and difficult to find, if you want to buy one, since they get rarer as more of them permanently die) Gamesharks, when the ED64 has proven to be much more (totally?) reliable, so I'd *much* prefer to see the ED64 made to use Gameshark codes directly, rather than made to work with the real Gameshark devices.
What about real time support like what is in Animal Forest? I heard that The 64DD also supplies a clock, it's implemented in some forks of mupen64plus, and the register is used by Animal Forest. Maybe the ED64 could read and write the register if their OS/firmware were written to do so? I know a few people who would love to use such a feature when hacking games like Majora's Mask. The games that already use it, and new hacks that would end up using it as well would be a major sales point for Krikzz. Heck I'm making a Zelda hack now, and I want to keep learning more and more about hacking it and understanding the way the game works. Maybe even I would end up making such a hack. I know someone who has even ported the way time and day works and a clock to keep up with it from Majora's Mask into Ocarina of time. She's still working on some bugs, because it doesn't work right in some area's, but she knows a lot more than me about hacking the games. I'm sure she will get it working right in all area's of it.
the animal forest clock thing... theres patches for pokemon games that used the clock on the GBA to allow the games to work with flash carts, i think it works by calculating the time eliminating the need for a real time clock. couldnt the animal forest game for n64 be hacked in much the same way? i would suspect part of the problem resulting in this game not being clock fixed is due to the fact it's japanese only. i'm not sure exatly what standard of save type dezaemon 3d is using but there were patches back in the days of the old copiers which enabled games which used 16k eeprom to save to 4k eeprom. the downside was that you could only use one of the save slots but thats better than nothing and at least enabled save function. if there is no way to allow dezeamon 3d to save via everdrive OS update maybe the save type could be hacked for dezeamon 3d in the same sort of way as the old save fixes. once again the fact the game is japanese only may be part of the reason a fix was never made. i had this game for years in my rom collection when i was still using my doctor v64 copier. i never even knew the game didn't save. other than to compatibilty test it i never really played it tbh.
There is a english hack for it, it worked about as far as the Japanese version would work on the ED64. It's very hard to find though... I think there's a copy of the patch on the Isozone... not sure because I got it a long time ago when I first got my Everdrive. I don't know about the whole hacking the game itself thing, that's something I don't have a clue about. If someone did pull it off then good deal, but unless said person told any of the other N64 game hackers how it was done, we wouldn't really know how to do it ourselves :/
It is possible to simulate a RTC with the ED64-FPGA but the limitations are, that you have to set the date every time before you start Dōbutsu no Mori and it's not super precise without a quartz. In practice you could use for example a M41T00 with a battery and a 32768Hz quartz, that is accessed with the I²C-Bus. (up to 5 years with a 50mAh/3V cell) How Dōbutsu no Mori is reading/writing the RTC, was figured out by zoinkity already. AF-RTC stands for the Animal Forest real time clock. 00 status 01 controller read 02 controller slot read 03 controller slot write 04 eeprom read 05 eeprom write 06 AF-RTC status 07 AF-RTC read 08 AF-RTC write FF reset
Thanks Saturnu! this is awesome stuff. I'll definitely be doing this soon. Just to be sure, do you have to input your date every time even with batter and quartz? Or would that be something you had to do anyways?
Perhaps it wasn't written clear enough by me. Forget about the extra rtc, that was just an example how one is implemented and that it needs a battery. ^^ In that case you will need Krikzz to write you a special firmware and give you some solder-points that interacts with that rtc. :> Or you have to add a second device (FPGA) to the expansion port, that lets you access the rtc.... To much work. If you really want to experiment and add one by yourself... Maybe you could add a rtc to the usb port, attach some functions to the rom and hook the calls, that's not impossible but a lot of work. it would be a lot easier to buy the original game. cheers, saturnu
Yes that does sound like a lot of work and my ED64 doesn't have UBS :/ I figured I would never need it since everything could be updated with the SD card. I would get the original game, but I don't understand Japanese haha. If only people knew more about making their own N64 carts, I would just buy an animal forest cart and try to get the English patched version on it.
