|
|
Post by tgwaste on Jan 18, 2008 19:26:06 GMT 1
|
|
|
|
Post by countbuggula on Jan 18, 2008 20:14:15 GMT 1
Haha, that's hilarious. So it's not already a hacked ROM, it's just a standalone program for PC or something?
|
|
|
|
Post by tgwaste on Jan 18, 2008 20:17:03 GMT 1
ya.. an .exe file.. works really well to.. but would love to play it via LJP instead, hopefully they make a rom version.
|
|
|
|
Post by _Em on Jan 18, 2008 22:20:23 GMT 1
That'd take a LOT of work to port to SNES. Maybe they could do something similar using the SMW editor though....
|
|
|
|
Post by Tinnus on Jan 19, 2008 0:36:38 GMT 1
Looks like fun ;D
|
|
|
|
Post by samphex on Jan 19, 2008 2:51:36 GMT 1
Woah that is sweet!
|
|
|
|
Post by Tinnus on Jan 19, 2008 12:30:33 GMT 1
Nope, my current project is LJX  |
|
|
|
Post by samphex on Jan 20, 2008 19:53:22 GMT 1
hey I do not know if post is legal or not in these forums, but in ljx can you make it possible to implement hacks on gamboy games, like visual boy advance can do? When I mean hacks I mean being able to enter codes into games to say,.... automatically beat pokemon in a pokemon game. (still waiting for that ljx version for pc so I can connect my pc to my Tv and have fun  ) |
|
|
|
Post by Tinnus on Jan 20, 2008 23:23:13 GMT 1
Wow, they still got Zodiacs for sale? Hope you can still get a hold of a battery for some time, since that should be the one to suffer since it's propably like 2-3 years old already (since the Zodiac stoppe dbeing produced).
|
|
|
|
Post by samphex on Jan 20, 2008 23:39:04 GMT 1
Like a Game Genie? (or the newer gameshark?) BTW: Tinnus: Just got a Tapwave Zodiac 1. Very first thing I did was fire up LJP. Very nice. . . very nice indeed. . .  Um, ya.... theres vids on youtube showing people entering coeds into visual boy advance so they automatically beat Pokemon. |
|
|
|
Post by Tinnus on Jan 21, 2008 1:01:18 GMT 1
Most likely there will be support for Game Genie/GameShark/Action Replay, as long as the formats of the codes are documented.
|
|
|
|
Post by _Em on Jan 21, 2008 7:42:03 GMT 1
The formats are well documented... however, you could also do it the mednafen way and use a gamegenie ROM to enable it in-game.
|
|
|
|
Post by samphex on Jan 21, 2008 21:27:55 GMT 1
The formats are well documented... however, you could also do it the mednafen way and use a gamegenie ROM to enable it in-game. Say what? More explanation please? |
|
|
|
Post by Tinnus on Jan 21, 2008 21:59:17 GMT 1
Seems like you could have the ROM of the Game Genie cartridge dumped ad use that to patch, just like the original ;D (Did the GG have a cartridge? Or am I talking crap? ) |
|
|
|
Post by _Em on Jan 21, 2008 22:06:31 GMT 1
That's exactly right, Tinnus -- the emulator needs to check to see if that ROM is present, and if so, load the selected ROM on top of the GG footprint. This way you'd be emulating the interface and the memory manipulation, and would only need to implement a minimal set of hardware loading routines instead of a full memory modifying layer.
[edit] The GG came as a cart for most systems -- it was a very stubby cart that the game cart then plugged into. When you booted up the system, it launched to the GG menu where you could enter your codes, etc. and then launch your attached game.
The problem with Game Genie is that its codes only modified 1 word of memory IIRC -- which resulted in the fact that you couldn't reliably generate codes for carts larger than 8mb. Gameshark and Action Replay carts had 2 words of memory (their codes were twice as long) which meant they could handle much larger carts.
|
|
|
|
Post by Tinnus on Jan 21, 2008 22:43:10 GMT 1
I thought Game Shark and Action Replay patched RAM instead of the cart's ROM? Or was that only for PS1?
|
|
|
|
Post by _Em on Jan 21, 2008 23:33:44 GMT 1
That's only for PS1 where there was RAM to be patched. In the others, they were basically a bit filter; whenever a code request came through to the ROM, they'd substitute the value that got sent back to the console.
|
|
|
|
Post by Zer0linK on Jan 22, 2008 16:07:05 GMT 1
hi, I've been reading all this thread, about the LJX, let's see if I get this right: The emulation modules core are plataform independent, so what will be needed to port to diferent plataforms is the LJX framework you'r working on, is that right?
|
|
|
|
Post by _Em on Jan 22, 2008 16:56:41 GMT 1
Sort of... the LJX emulation modules are written in portable C on top of the SDL framework, which itself has already been developed for most platforms. This means that most of the heavy lifting is already done and all he needs to do is design the framework (already done I think) and launcher (not yet done) in such a way as they can compile for all targets.
Of course, this is in theory... in reality, there are little non-portable bits that crop up in the various pieces of code, and those need to be modified to be portable before that part of the system will work.
|
|
|
|
Post by Tinnus on Jan 22, 2008 17:55:00 GMT 1
It's better tha that The modules are written on top of the LJX framework, not SDL. SDL is just one of the host implementations, which are the ones you have to write to port to a new platform. But in theory (and trust me, that works most of the time), the only thing you have to port is that. For example, the SDL port was programmed in a Windows environment. It compiles and runs in Linux out-of-the-box and in the PSP I just needed to add a check for the color format since the PSP's SDL uses BGR istead of RGB (for reasons unknown to me ). But for example, the Palm port is not using SDL. But even then I managed to get it working in like 5 minutes, just implementing the startup, control and screen functions (which are the most important ones). What has to be done for LJX is: - Creating a framework that makes the emulation modules and the hosts "talk" with each other in a way that everyone can talk with everyone else (done!) - Adapting the modules to use the functions in the framework (done for NES, SMS/GG, GB/GBC and Genesis!) - Creating host ports that implement all of the expected functionality (drawing, sound, control, etc -- done for SDL and on proof-of-concept for PalmOS!) - Creating at least one Launcher to, well, launch the emulators - Further optimizing the emulation modules - Adding further features to all of the modules (ex: Game Genie) The deal with the launcher is as follows. My primary idea is to code a launcher that would use all of the framework magic to just work anywhere. BUT, since the launcher is actually a separate application from the modules, anyone could write a replacement launcher if they wanted with any half-@$$ environment, say, Game Maker What a launcher has to do is to pass a bunch of information to another app, which is the framework+module, in the form of a file called emudata.dat, which is a plain text file containing all of the information needed (control config, screen mode, sound, bla bla bla) with one datum per line. Now, that is one of the reasons that get me thinking on doing the framework+modules first. Anyone could do a fan-made launcher for example with little knowledge on programming and none at all in emulation What's cool in that is that non-portable bits usually happen in several places. So, one change could maybe fix the problem for several platforms (classic example: endianness) |
|
|
|
Post by Zer0linK on Jan 22, 2008 19:00:21 GMT 1
now I have all clear in my head, and I really love the idea (now is very much more than an idea) of a framework, the LJX framework, and the modules written on top of it. I knew something was wrong when I read the "on top of SDL framework", because if that, then there would be no port for palmOS (forget about that SDL palmOS port).
And, like you say, it seems really easy to write a launcher without knowing anything of emulation, if it's just needed to pass that emudata.dat file, ... that's great.
I was thinking about an android port, but I don't think it's documented the develop of native applications for that plataform, because the applications run on top of a Java VM, so they're supposed to be developed on java. All in all, a native application should run on top of the linux kernel, so I think a linux port should work.
It was just an idea, because I dont think I ever get a device with android xD.
|
|
|
|
Post by Tinnus on Jan 22, 2008 19:26:40 GMT 1
I was thinking about an android port, but I don't think it's documented the develop of native applications for that plataform, because the applications run on top of a Java VM, so they're supposed to be developed on java. All in all, a native application should run on top of the linux kernel, so I think a linux port should work. It was just an idea, because I dont think I ever get a device with android xD. I don't think there's a way yet to run native stuff on it. I do know that officialy, no though. |
|
|
|
Post by countbuggula on Jan 22, 2008 20:12:20 GMT 1
If they've hacked the iPhone which isn't supposed to run anything at all (even Java) I'm sure people will find a way to run native code on an Android phone.
|
|
|
|
Post by Tinnus on Jan 22, 2008 20:33:51 GMT 1
They have, but no one has done anything more than console apps as far as I found out I'm pretty sure that will happen eventually though, so let me know when it happens |
|
|
|
Post by Zer0linK on Jan 22, 2008 21:03:59 GMT 1
|
|
|
|
Post by Tinnus on Jan 22, 2008 21:59:15 GMT 1
|
|
|
|
Post by Zer0linK on Jan 22, 2008 23:35:07 GMT 1
|
|
|
|
Post by Tinnus on Jan 23, 2008 22:47:46 GMT 1
Hello again. SOme news who might be interesting for some I'm currently building my all-new-prc-tools-toolchain so I can finally start doing cool stuff for the PalmOS port. I got that SDL port thing and got it compiled, but... it crashed when ran! Yep, it seems I have to build from source new versions of gcc and binutils. So, there I went, and that should take one more day at least, since I'm compiling gcc for an hour already and no sign of it nearing completion (note: I have to compile everything twice: for 68K and ARM. SO far it's only starting to compile arm-gcc) In any case, it shouldn't be needed to update the toolchain to develop non-SDL stuff, but I want to get that SDL framework working since it uses PEAL and that cool ARM stuff (including a 90% complete libc, which for you mortals, means "port anything without having to change a lot of stuff to boring PalmOS-specific function calls"). Although IMO that libc still has some limitations (it only searches for files in one volume), so I'm most likely going to improve it so it has what I want for LJX |
|
|
|
Post by Zer0linK on Jan 23, 2008 23:07:33 GMT 1
including a 90% complete libc that's cool, so they made a port of the libc, but just to manage to port the sdl, that should be a separate project, cause have a complete libc available for palmos apps would be a great advance. I'm currently building my all-new-prc-tools-toolchain I would like to know about this toolchain you're setting up, that may come useful to me. |
|
|
|
Post by Tinnus on Jan 23, 2008 23:10:26 GMT 1
Get the SDL source package, there are instructions there.
|
|
)
