Is that Phantasy Star Collection Translation Still Being
- Thread starter Link
- Start date
MasterAkumaMatata
Staff member
I don't think so. I remember Arakon mentioning that this game has a protection in the form of a CRC check or something which is not easy to bypass. Anyway, with the Smash Pack emu for the DC being able to play Phantasy Star II (officially) and PSIII and PSIV (both unofficially), and that there is an SMS emu for the DC as well, I don't see why someone would want to work on this project, unless he or she just wanted to show everyone that he/she succeeded where others have failed.
The visuals and speed in the DC smash pack are OK, video output is a bit too sharp or bright or something, gets annoying after a while. But that's all fine and dandy. The real bad thing about the smash pack is the SOUND. In an old game that uses simpler music, its not TOO bad, but I wouldn't want to imagine PSIV with that thing... what it sounds like with Vectorman is bad enough...
Yeah, the sound emulation is pretty bad, and the games run in an interlaced video mode which makes them look funny. When I first heard about the Smash Pack I had huge expectations for it. I guess they could have done a better job considering it's a commercial emulator. ??? I thought Sega would base the emu on kgen, since I had heard they bought the source code off the author or something like that.
I've been thinking about Genesis/SNES emulation on the Saturn... actually it's been tried several times on the PSX but failed due to lack of RAM. But, the Saturn can have up to 6 megs isn't it? Now what's holding us back? I think we can still coax a pretty decent 68k emulation out of the Saturn's CPUs.
Well, maybe that's because the Z80 emulation core has been written in C... with some decent optimizations it can be as fast as the real thing. Consider this: some time ago Tezxas was released, a ZX spectrum emulator running on a TI-89 calculator
Well, the Speccy runs from a Z80 and a TI-89 has a 10mhz 68k... so if one 10mhz 68k can do it, i'm pretty darn sure two 28mhz SH-2's can do it better... just depends on the code i guess
Well, the Speccy runs from a Z80 and a TI-89 has a 10mhz 68k... so if one 10mhz 68k can do it, i'm pretty darn sure two 28mhz SH-2's can do it better... just depends on the code i guess
hmmm.. I didn't know the Saturn has a 68k... I'm sort of an enthusiast about this kind of stuff but by no means an expert. What does the Saturn use it for anyway?? sound?
The 68k it's part of the sound assembly.
Tezxas... Yes, but Tezxas uses a native 68k ASM CPU code... and noone (but me, but one instruction that's slower than the C compiled code shouldn't count ^^
has ever attempted to do an SH2 ASM Z80 core.
As for SNES emulation, you can allways read my Stardust source code, if you can figure anything out of it
... I'm thinking in replacing the 65c816.c functions to Inline ASM macros somethime in the near future, if time all
Tezxas... Yes, but Tezxas uses a native 68k ASM CPU code... and noone (but me, but one instruction that's slower than the C compiled code shouldn't count ^^
As for SNES emulation, you can allways read my Stardust source code, if you can figure anything out of it
vbt
Staff member
If yo want to check Z80 ocre you should have look on
SMS Plus :
http://cgfm2.emuviews.com/emul.htm
and his Saturn port (not my version) :
smsemu.emuunlim.com
SMS Plus :
http://cgfm2.emuviews.com/emul.htm
and his Saturn port (not my version) :
smsemu.emuunlim.com
This is the report of my piftull attempt at an Z80 Opcode, based on the SMS Plus core:
http://litespeedcomputers.com/sx....issilly
Notice also ExCyber warning about the genral speed of emulation and need for fast opcodes.
AntiPasta, SH2 is alot like a MIPS, except it only has 15 registers and no floating point unit. Give it a try, it's not terrible.
http://litespeedcomputers.com/sx....issilly
Notice also ExCyber warning about the genral speed of emulation and need for fast opcodes.
AntiPasta, SH2 is alot like a MIPS, except it only has 15 registers and no floating point unit. Give it a try, it's not terrible.
I'd really like to know what kind of research was done to form such a crazy idea. I've been able to mod the roms without any kind of problems which basically tosses out that theory. As far as re-inserting the US counterparts are concerned, I think more work needs to be done in order for that to work. It looks like either the us versions might have used hardware that isn't supported by PSC(I really doubt that) or PSC does a few cheats and references certain parts of the rom for graphics, text, and specific code. The latter would explain why when one inserts a proper format US PS rom over the jap, it still starts, but locks up at the title screen.
Cyber Warrior X
MasterAkumaMatata
Staff member
Hah, I had totally forgotten about that thread.
Cyber Warrior X
Cyber Warrior X
Er, so... 7 months after, could anyone with a AR extract the ROM file after being loaded? I assume, that they wouldn't patch a ROM inserting exceptions in the main "emulation" cycle. A pos-load patch would be mutch more reasonable, altough god knows why did wouldn't they do it on the final file, anyway. I wonder if Sega was unable to "hard-modify" the files due to contracts with the game maker ^^;. Why all the trouble leaving exact ROM data on a CD and ripping and converting into a saturn-able format in "real time"? Maybe bytecomp with the original files would give some idea of the modifications?
Hn, just to finalize my train of thought, could anyone check if both tile or map data for the Title Screen of the US and Sat ROM version start at the same address, using a tile viewer? If it is the same, the "executable" should carry the same offset (or the memory location of the file) somewhere. With any luck, maybe even a table of offsets could be found, and we could start from there looking for the exceptions.
Er, I _do_ belive all this was already tried, but it's never late to sound like a smartass.
Hn, just to finalize my train of thought, could anyone check if both tile or map data for the Title Screen of the US and Sat ROM version start at the same address, using a tile viewer? If it is the same, the "executable" should carry the same offset (or the memory location of the file) somewhere. With any luck, maybe even a table of offsets could be found, and we could start from there looking for the exceptions.
Er, I _do_ belive all this was already tried, but it's never late to sound like a smartass.