Looking at what could be added to the current hardware, obviously BS-X support is high on the list. I have seen some docs but so far it looks like a mess.
Some (one?) games also use a RTC, maybe that could be loaded/saved from a txt file? Not sure if that would be usable or just too annoying.
Someone mentioned PAR codes work on RAM, I assume that is in cart SRAM instead of system RAM?
Does it support loading save state files (even if it means picking the save state file while loading the ROM, and pressing the Reset button to reload the same save state)? I'm not talking about SaveRAM backups, but emulator save states.
PAR codes work on system ram. There has to be some form of Interrupt handler or code hijacking, in order to be able to update the system ram with the PAR code values, then a means to return back to the game code.
The nice part with this cart, is that you could load in your PAR handler into one of the banks, then in place of the original NMI handler, the first few instructions of it, gets replaced with a jump to the PAR handler bank you chose, that gets run, then those first few instructions that were overwritten get run, followed by a jump back into the remainder of the code.
If the first instruction happens to be a long jump, then it works rather nicely, since the execution of that long jump upon PAR handler completion, will go right into the actual NMI handler code.
I would like to see an option to write new .SRM save files, if that's feasible.
As for BS-X support, isn't there some sort of RTC issue to work out for that, too, since some of those games were scheduled installments? I don't know much about it, but didn't some of the games have to be hacked to work in emulators?
The
Sufami Turbo is sort of like the SNES's Aladdin Deck Enhancer. It should be do-able on the SNES PowerPak.
Many of the BS-X games that anyone would really want to play should work fine already, mostly the crappy magazines and things used the BIOS for text and such, I wouldn't put that first on your list.
mic_ wrote:
Does it support loading save state files
Is it possible to save the entire state on real hardware? Someone said the SPC state isn't, how about other graphics/timers etc?
caitsith2 wrote:
PAR codes work on system ram. There has to be some form of Interrupt handler or code hijacking, in order to be able to update the system ram with the PAR code values, then a means to return back to the game code.
That makes more sense, should be easy just to replace the nmi vector in the game to go to my code instead. Will have to figure out where in SNES mem it can be placed to break the least number games. Shouldn't take that much space.
naI wrote:
I would like to see an option to write new .SRM save files, if that's feasible.
Possible but lots lower on the list. Too annoying to enter file names
bunnyboy wrote:
naI wrote:
I would like to see an option to write new .SRM save files, if that's feasible.
Possible but lots lower on the list. Too annoying to enter file names
Just copy the name of the ROM (truncated?) + a number + .SRM
The list with three created save files for one game (Final Fantasy VI (J).SMC) would look like:
Final Fantasy VI (J).SRM
Final Fantasy VI (J)_1.SRM
Final Fantasy VI (J)_2.SRM
Something I was curious about was there was talk about certain chips like Cx4 and PICs and PIC cores fitting into the FPGA's remaining room. So does that mean certain more simple chips might be possible like Cx4, OBC-1, not sure what else might fall in that category.
About Save States, many copiers support Save States. But it all depends on how the copier saves and restores a save state as well as the game in question. Some games are no problem saving mid-game. Other games won't work at all, or only in certain parts. For example maybe not during gameplay but between levels or during some sort of cutscene a save state might work. I generally don't use the in game save and restore feature in games but sometimes the feature can be very helpful.
AR Cheats would certainly be a nice feature. If possible it would be nice to have a button combination to enable and disable all codes or if you could have a separate section of codes where certain ones are always on and others toggle on and off. The same thing would be nice for Game Genie codes too. Remember that the Game Genie had a switch on it and some codes required you to disable the codes at certain times to avoid crashing the game.
Quote:
Is it possible to save the entire state on real hardware? Someone said the SPC state isn't, how about other graphics/timers etc?
I haven't checked which IO regs are readable. But I was talking about loading an existing save state file, not creating new ones on the fly.
If possible some form of simple progress indicator when loading a large rom would be nice.
Save states are possible except the SPC state of course (that would require hacking every game's SPC code). For the write only registers, and registers that once read can't be rolled back, you "need" to put local copies in the FPGA; copiers do it entirely in software like the PAR.
I thought of something in the shower, could the old decompression packs ala
http://www.caitsith2.com/sjns/ be used to emulate the few games that use the SPC7110?
There is more than just the decompression packs. The SPC7110 does have some math functions built into it as well, and not only that, in the case of Tengai Makyo Zero, you also have to deal with an RTC as well.
Rom addressing though, could be dealt with using unused address space.
How about supporting the Super Game Boy? Seriously though, which would be more difficult, the supporting the FX chip or the Super Game Boy?
Jagasian wrote:
How about supporting the Super Game Boy? Seriously though, which would be more difficult, the supporting the FX chip or the Super Game Boy?
A whole gameboy emulator in there?
See the hell byuu went through here:
http://board.byuu.org/viewtopic.php?f=5&t=364
I really think Super FX isn't that complicated when you consider it's just a CPU chip where as the Super Gameboy is an entire Gameboy system. That would be crazy though to have a SNES PowerPAK with a FPGA large enough to emulate the SGB allowing playback of GB roms on SNES.
It's really not that far fetched, it would take a 100-200K gate FPGA to emulate the GB. The SNES PowerPak ships with a 15K, so obviously it's not happening but the smallest FPGA made today are 50K gate, the average are 500K and the largest are like 2M. Not only would such a FPGA be able to emulate the GB, but it also NES, Atari etc using the SNES' I/O. I think it would be cool (but a hell of a lot of work).
MatthewCallis wrote:
A whole gameboy emulator in there?
See the hell byuu went through here:
http://board.byuu.org/viewtopic.php?f=5&t=364
Registration and manual approval required. Would you summarize?
Well I belive the Super-FX is a RISC, that means it was designed to work with as few transistors as possible to gain clock soeed right ? If I'm right that'd mean it'd fit into a smaller FPGA than a complicated processor right ?
tepples wrote:
Registration and manual approval required. Would you summarize?
Basically...
byuu wrote:
For those who don't remember, I implemented Super Game Boy support soon after v045 was released, but I was never able to complete it due to a lack of understanding how the $7800 register worked. I abandoned this support because it required building all of gambatte inside bsnes. That isn't a bad thing at all, gambatte is a great emulator. The problem was more all of that extra code and complexity for something that didn't really work.
If the SuperNES Powerpak's FPGA can't hold the SuperFX I think a good supplementary product would be a SuperFX only Powerpak light. Maybe with instead of a CP flash card reader built in it could connect directly to usb. Maybe with 4MB of flash space to keep cost down. I'd pay extra for a second supplementary cartridge like that. Or, more simply, an FX board with a ZIF socked for eproms for us sloppy solderers. Just some thoughts. I hope he can iron out the compatibility issues because this is awesome
there are plenty of people who would solder on some sockets to a super FX board around the forum for the right price, including myself.
Other than something like Star Fox 2, I'd imagine one could probably buy the whole short list of games that use the FX chip for about what it would cost to buy a specially developed flashcart.
I really think the only reasons anyone would want Super FX support would be A. Star Fox 2, and alot less likely B. to attempt to develop their own Super FX program. I think the answer would be A. 99 times out of 100.
No ! I really wish I could develop a game taking advantage of the FX (or something else cool) one day !
Altough it's probably doable by destroying a common Yoshi's Island cart.
SuperFX would be a hell of a lot easier than the Super Game Boy. Even with my SGB emulator, I had to exploit peeking at $2181-2182 to determine where the SGB BIOS was attempting to read from (it streams VRAM data from $7800 serially.) Of course, you can probably do that on real hardware, too.
I'm not sure what to think about that. On one hand, it's really awesome to have such an all-in-one cart, but on the other hand, if you're emulating the SuperFX anyway, why not just use an emulator? To me the only real advantage of real hardware is getting perfect accuracy.
Unfortunately a passthru cart won't work for the SFX and SA-1 since the program ROMs are behind the SFX chip. But for all the other special chips, you could create a T-connector. Preserve the perfect accuracy but allow custom data to be run.
As for SGB, I'd say it's easier to just use a real SGB and a Game Boy flash cart. Those are much easier to obtain, and you gain the benefit of perfect accuracy instead of using another emulator.
Quote:
Registration and manual approval required. Would you summarize?
He was linking to a private forum. Hidden only so emu news sites don't update every single day about new WIP releases, which really just annoys everybody.
Registration is just anti-spam, so far 100% effective. Serious question -- how's open registration working around these parts? It's pretty terrible at the Zboard right now. </offtopic>
byuu wrote:
just use a real SGB and a Game Boy flash cart. Those are much easier to obtain
During the GBC to GBA transition, near the start of 2002, it was a lot easier to get one's hands on a GBA flash cart than one for the GBC.
Quote:
Registration is just anti-spam, so far 100% effective.
That depends on how you define spam.
naI wrote:
Just copy the name of the ROM (truncated?) + a number + .SRM
The list with three created save files for one game (Final Fantasy VI (J).SMC) would look like:
Final Fantasy VI (J).SRM
Final Fantasy VI (J)_1.SRM
Final Fantasy VI (J)_2.SRM
This would be great.
Also, a default SRM (Final Fantasy VI (J).SRM) should be created automatically if it does not exist.
I wonder why nobody mentionned it yet, but can the Super Power Pak play .spc files ? If it can't it definitely should.
I agree with the spc music playback. That would be a great feature. Also, if co-processors like the SuperFX require a bigger FPGA, would that mean there would be a new hardware revision to the SNES PowerPak in the future? Or would it be an addon to the original hardware release?
Nether, its not gonna happen.
I suppose it's not quite Powerpak related, but is there an SNES Repropak in the works?
peppers wrote:
Nether, its not gonna happen.
I suppose for the very small number of games requiring the SuperFX chip, it wouldn't be a very cost effective addon/addition to implement. I'm very happy with DSP 1 support though. For the SPC playback, I wouldn't think it would be too hard to make work. It would just require a small SPC player that can fit inside the firmware.
As far I know all that'd be required for SPC playback is to send the whole SPC file to SPC memory using the official protocol, write all DSP values to DSP (which I guess can be done with official protocol by writing to $f2/$f3 ?), and tell the SPC to jump to the .SPC file Programm Counter adress.
The hard part is to make the A, X, Y and SP registers contain proper values. I guess there is already a programm that convert a .spc to .smc so this is definitely possible. I think it adds a bit of code in the echo buffer, not sure what would happen on .spc that have no echo buffer and use the whole memory (such as Super Castlevania IV).
Kasumi wrote:
I suppose it's not quite Powerpak related, but is there an SNES Repropak in the works?
No idea if it is, it would be nice but you'd still need official CIC/Lockout chips for the games to work in official systems. But it would be nice still since you could make a board that accepts standard EPROM or Flash parts and not have any rewiring.
There's so many copies of Madden 97 or whatever floating around that the lack of a replacement CIC is a non-issue at this point.
That said, we really need an SNES Repropak as working with existing boards is pure torture.