My How Things Have Changed...

[ketchupgun]

I come back to my GP2X and these boards and it amazes me where we're at.
GPSP gba emu is a real treat! (though not everyting is working perfect..yet!

I must say "yet" is the operative word for this community. Your devs kick ass! another example is Sega CD...non existent ahile back! It seems I come bck and this machine's uses double!

questions:
• Is anyone finding PicoDrive 1.3 more stable than 1.31? cause I am.
• With the new Mame, which I have not tried yet...am I ever going to get to play Quartet 1 & 2
• Is playing Marvel vs Capcom or X-Men Children of Atom a pipe dream? Any news on these fronts?
• New Firmware? I'm on the old 2.0..do I got to the latest 2.X or the 3.0?

peace
--
Ketchup

 

[___]

• Is playing Marvel vs Capcom or X-Men Children of Atom a pipe dream? Any news on these fronts?

No it's not a pipedream. There is a cps2 emulator alread which seems to work quite fine and a port of final burn alpha plus is in the works for cps1 emulation and some other treats.

• New Firmware? I'm on the old 2.0..do I got to the latest 2.X or the 3.0?

Better take the last 2.X as 3.0 is more of a graphically polished but functionally cut down version.

 

[ketchupgun]

Oh! and one other question:

I know NOTHING about dev'ing (I'm a print graphics/photgraphy guy on MacOSX) but how come we have so much trouble emulating SNES and esp. GBA when NEOGEO is like completely perfect?

What is it about these systems that makes them so diffuct to emulate?

i guess Sega MD/GG/SMS is easier than SNES/GBA, but honestly, to me NeoGEO graphics look way more complex than GBA/SNES.

(layman's terms encouagred

 

[Blah]

The graphics chips of the Neo Geo and Mega Drive/Genesis did little more than blit sprites to the TV. There are special hardware tricks the SNES and GBA can do such as sprite rotation and scaling, transparency, etc. These functions which are performed entirely in hardware by a chip in the console have to be emulated entirely in software on the GP2X.

Also some CPUs are just harder to emulate than others. Or they are just emulated better. We have great code for the Z80 and 68000 (used by various consoles such as Neo Geo, MD, GG [Z80 only], SMS [Z80 only], Gameboy Color/Mono, Amiga [68000], MAME, etc), but not so much for the 6502 and 65c816 (C64 [6502], NES [6502], SNES [65c816]).

ARM (GBA [ARM7], GP2X [ARM9], GP32 [ARM9]) is a weird one. It is complicated (but ZodTTD and Exophase are making good progress), but in some cases emulation isn't necessary (Squidges GP32 emulator, although incomplete, uses the GP2X's ARM processor to directly run the GP32 code and only has to emulate the graphics, sound and input).

 

[notaz]

• Is anyone finding PicoDrive 1.3 more stable than 1.31? cause I am.

What exactly do you mean by "more stable"? The latest one is 1.32 BTW.

 

[christo930]

The graphics chips of the Neo Geo and Mega Drive/Genesis did little more than blit sprites to the TV. There are special hardware tricks the SNES and GBA can do such as sprite rotation and scaling, transparency, etc. These functions which are performed entirely in hardware by a chip in the console have to be emulated entirely in software on the GP2X.

Also some CPUs are just harder to emulate than others. Or they are just emulated better. We have great code for the Z80 and 68000 (used by various consoles such as Neo Geo, MD, GG [Z80 only], SMS [Z80 only], Gameboy Color/Mono, Amiga [Z80 only], MAME, etc), but not so much for the 6502 and 65c816 (C64 [6502], NES [6502], SNES [65c816]).

ARM (GBA [ARM7], GP2X [ARM9], GP32 [ARM9]) is a weird one. It is complicated (but ZodTTD and Exophase are making good progress), but in some cases emulation isn't necessary (Squidges GP32 emulator, although incomplete, uses the GP2X's ARM processor to directly run the GP32 code and only has to emulate the graphics, sound and input).

The Amiga is a 68000 cpu not a z80 and is far more complicated to emulate than the snes. The Amiga has 3 custom chips besides the cpu to emulate and more complex timing. However, one thing that makes the snes so hard to emulate is that so many games pushed the snes to it's limits, using every feature of the hardware and some even had custom hardware (inside the cartridges). So good enough to run most games, is perfect. For example it would be comparatively easy to make a snes emulator that only ran one game, because it would only have to emulate the hardware well enough for that one game to run. Adding to this is that custom hardware is usually not well documented (at least publicly) and that most of the hardware used in the snes is only used in the snes and you can't borrow from other projects. So, if you want to write a neo geo emulator, there are lots of great 68000 and z80 emulators to start you off with that have been perfected over the last 10+ years...

 

[BobBorakovitz]

Hey, ketchupgun! Welcome back

 

[Exophase]

Oh! and one other question:

I know NOTHING about dev'ing (I'm a print graphics/photgraphy guy on MacOSX) but how come we have so much trouble emulating SNES and esp. GBA when NEOGEO is like completely perfect?

What is it about these systems that makes them so diffuct to emulate?

i guess Sega MD/GG/SMS is easier than SNES/GBA, but honestly, to me NeoGEO graphics look way more complex than GBA/SNES.

(layman's terms encouagred

For the most part NeoGeo isn't more graphically capable than GBA (which is itself significantly more capable than SNES, aside from resolution), and in terms of CPU power it is drastically weaker, think on the order of 3-4x. Not only is there a much smaller array of games, but a lot of them are practically clones of each other, so I'm sure that some assumptions as to how the graphics are used go a long way. You probably don't even have to worry about raster effects at all, which would help tremendously. Raster effects are used very often in GBA games.

christo930; I wouldn't call 68k complicated to emulate. Actually, most of these high performance 68k emulators are using 64k lookup tables that have been auto generated, an approach outlined in the Generator paper years ago. The output looks like a mess, but it isn't that difficult to manage, and since it's preprocessed it's not too bad to output it directly to assembly (where it works out being better than what a lot of compilers can do even though it lacks any kind of optimizations you'd think a huge piece of macro output would need).

It's a more robust instruction set than Z80, sure, but it has more straightforward and consistent encoding, and both CPUs are very slow (per clock).

I'm pretty skeptical that a basic Amiga (first generation specs) is more complicated to emulate than an SNES.

 

[Blah]

The Amiga is a 68000 cpu not a z80...

I knew that...its a typo.

 

[christo930]

Oh! and one other question:

I know NOTHING about dev'ing (I'm a print graphics/photgraphy guy on MacOSX) but how come we have so much trouble emulating SNES and esp. GBA when NEOGEO is like completely perfect?

What is it about these systems that makes them so diffuct to emulate?

i guess Sega MD/GG/SMS is easier than SNES/GBA, but honestly, to me NeoGEO graphics look way more complex than GBA/SNES.

(layman's terms encouagred

For the most part NeoGeo isn't more graphically capable than GBA (which is itself significantly more capable than SNES, aside from resolution), and in terms of CPU power it is drastically weaker, think on the order of 3-4x. Not only is there a much smaller array of games, but a lot of them are practically clones of each other, so I'm sure that some assumptions as to how the graphics are used go a long way. You probably don't even have to worry about raster effects at all, which would help tremendously. Raster effects are used very often in GBA games.

christo930; I wouldn't call 68k complicated to emulate. Actually, most of these high performance 68k emulators are using 64k lookup tables that have been auto generated, an approach outlined in the Generator paper years ago. The output looks like a mess, but it isn't that difficult to manage, and since it's preprocessed it's not too bad to output it directly to assembly (where it works out being better than what a lot of compilers can do even though it lacks any kind of optimizations you'd think a huge piece of macro output would need).

It's a more robust instruction set than Z80, sure, but it has more straightforward and consistent encoding, and both CPUs are very slow (per clock).

I'm pretty skeptical that a basic Amiga (first generation specs) is more complicated to emulate than an SNES.


It isn't the 68k thats so difficult to emulate, it's the THREE custom chips. There are quite a few video modes to emulate including hi-resolution and 64k colors on screen at once (ham 8) You must be carefull not to compare systems output power with emulatability. Take the Sega Saturn. Most people would argue that the N64 has much more power and features than a Saturn yet we have usable N64 emulation. WHY? The saturn has I believe 7 chips running in parallel. As if emulating 7 chips isn't bad enough, they are running in paralell. A fast cpu isn't running in paralell, so the timing needs to be done in software which really slows things down. The Amiga has the same problem, just 4 instead of 7, this is why the snes emulator can run most games full speed and the Amiga emulator cannot.

Chris

 

[Exophase]

It isn't the 68k thats so difficult to emulate, it's the THREE custom chips. There are quite a few video modes to emulate including hi-resolution and 64k colors on screen at once (ham 8) You must be carefull not to compare systems output power with emulatability. Take the Sega Saturn. Most people would argue that the N64 has much more power and features than a Saturn yet we have usable N64 emulation. WHY? The saturn has I believe 7 chips running in parallel. As if emulating 7 chips isn't bad enough, they are running in paralell. A fast cpu isn't running in paralell, so the timing needs to be done in software which really slows things down. The Amiga has the same problem, just 4 instead of 7, this is why the snes emulator can run most games full speed and the Amiga emulator cannot.

Chris

Sorry, but most game systems have several custom chips running in parallel, Amiga might have stood out in this regard amongst computers of the time but compared to the SNES? Not really. And HAM can do 4096 colors, not 64k (we're talking about the original chipset right). Then again most people didn't use HAM and instead there were 32 colors onscreen..

And where do we have useable N64 emulation..

You really think I would just look at overall power when considering how easy to emulate a platform is?

Seriously, look at SNES again, it has a complicated video subsystem, a secondary CPU dedicated to audio and a DSP that it controls, sound familiar? Yeah, it sounds a lot like what you described, only it's typical for it to be pushing a lot more pixels around, and the sound is a similar setup to Amiga's but more powerful two (8 channels vs 4). And yes, all of these are running in parallel (when would a system have X chips running in serial anyway..)

No matter what, I guarantee you that over the years more overall effort has been put into SNES emulation than Amiga emulation.

 

[ketchupgun]

• Is anyone finding PicoDrive 1.3 more stable than 1.31? cause I am.

What exactly do you mean by "more stable"? The latest one is 1.32 BTW.

what i mean is that Pico 1.3 was crashing mid-game a few times..and a good handful of games (sorry I can't list any off the top, but it's irrelevant now) just wouldn't open the rom, that DrMDx would open no-problem.

with that said, I've found Pico 132 amazing, now that I have it. It's seriously awesome. Sega Cd..WOW! Herzog Zwei! sweetness! nice job.

btw..I've posted this elsewhere, but maybe I can get a hand here:
I'm trying to play Snatcher. on 1.32 .. and it just hangs on the Konami Credits, and doens't move into the game.

is this a settings thing?

as for the ROM itself, let's just say other have the same ROM working, but on Pico114(??) (or something)



@bob .. hey man! thx for the warm welcome!

 

[christo930]

It isn't the 68k thats so difficult to emulate, it's the THREE custom chips. There are quite a few video modes to emulate including hi-resolution and 64k colors on screen at once (ham 8) You must be carefull not to compare systems output power with emulatability. Take the Sega Saturn. Most people would argue that the N64 has much more power and features than a Saturn yet we have usable N64 emulation. WHY? The saturn has I believe 7 chips running in parallel. As if emulating 7 chips isn't bad enough, they are running in paralell. A fast cpu isn't running in paralell, so the timing needs to be done in software which really slows things down. The Amiga has the same problem, just 4 instead of 7, this is why the snes emulator can run most games full speed and the Amiga emulator cannot.

Chris

Sorry, but most game systems have several custom chips running in parallel, Amiga might have stood out in this regard amongst computers of the time but compared to the SNES? Not really. And HAM can do 4096 colors, not 64k (we're talking about the original chipset right). Then again most people didn't use HAM and instead there were 32 colors onscreen..

And where do we have useable N64 emulation..

You really think I would just look at overall power when considering how easy to emulate a platform is?

Seriously, look at SNES again, it has a complicated video subsystem, a secondary CPU dedicated to audio and a DSP that it controls, sound familiar? Yeah, it sounds a lot like what you described, only it's typical for it to be pushing a lot more pixels around, and the sound is a similar setup to Amiga's but more powerful two (8 channels vs 4). And yes, all of these are running in parallel (when would a system have X chips running in serial anyway..)

No matter what, I guarantee you that over the years more overall effort has been put into SNES emulation than Amiga emulation.

I was bringing in an example from the PC world. We have usable N64 emulation and still no Saturn emulation.
The sound chip and video system wouldn't be said to be running in parallel, that's what I mean. Chip A, B, C or D might do something relying on the output of one of the other chips. I made a mistake when I said 64k colors, it should have been 4096 like you pointed out and that's another point. Very few games use HAM 8 so you can not emulate ham 8 and still have a high percentage of compatability. Now, granted you could probably say the same thing for mode 7 on the snes. There has been a great deal of work done on both systems, lucky for us. I guess in the end they are both complicated to emulate and it's a tribute to the work of the programmers that we can enjoy emulation of both systems, although the Amiga emulation needs some more work. I personally don't think we will ever have full speed high compatability a500 emulation on the gp2x unless both chips are used.

Chris

 

[Exophase]

I was bringing in an example from the PC world. We have usable N64 emulation and still no Saturn emulation.

Check out the Saturn emulator called SSF. It's true that Saturn emulation requires a lot more out of a PC than N64 emulation - part of it is because of all the parallelism on Saturn like you said, but the other part is due to high level emulation of the N64. Note that a pure LLE N64 emulator is probably currently slower than Saturn emulation.

The sound chip and video system wouldn't be said to be running in parallel, that's what I mean. Chip A, B, C or D might do something relying on the output of one of the other chips.

This isn't how these chips run on consoles like SNES. The CPU merely sets up a few things (maps, sprites, voice pitches, what have you) and the video and sound chips go off and work on these things on their own. To add to that fact, the SPC700 on SNES has a full general purpose CPU of its own. While Amiga does have a sort of instruction processor for its blitter, it's very simple (and probably spends most of its time waiting for events)

I made a mistake when I said 64k colors, it should have been 4096 like you pointed out and that's another point. Very few games use HAM 8 so you can not emulate ham 8 and still have a high percentage of compatability.

You're probably right. And on average SNES games are probably more color dense than Amiga ones (actually, HAM doesn't change this much given the color tricks you can do on SNES).

Now, granted you could probably say the same thing for mode 7 on the snes.

I don't think so, mode 7 is very common. I would go so far as to say a majority (over 50%) of games use it somewhere, but that's very hard to back up. It's true that most games don't use it constantly (except say, racing games), but it's a pretty central part of SNES emulation.

There has been a great deal of work done on both systems, lucky for us. I guess in the end they are both complicated to emulate and it's a tribute to the work of the programmers that we can enjoy emulation of both systems, although the Amiga emulation needs some more work. I personally don't think we will ever have full speed high compatability a500 emulation on the gp2x unless both chips are used.

Chris

I have a feeling it's attainable in some regard, I just don't think Amiga emulation has exactly been what everyone's jumping to do (for some reason). The funny thing is that UAE started when computers were significantly weaker than GP2X is. As far as I know, it's practically the grandfather of enthusiast emulation on PC and probably predates most major SNES emulators (definitely SNES9x and ZSNES)

I don't know much about Amiga coding to be honest (I only have some idea of how the hardware works), but I have to assume that most apps played somewhat nice with the hardware in order for all of the fancy workbench tricks to go on. I'd say most games stuck to a single resolution for the whole screen and were otherwise pretty straightforward. What if a high level emulation was used that provided the OS services and simply booted games and various applications fullscreen? Think DOSBox or Wine.

 

[DaveC]

The sound chip and video system wouldn't be said to be running in parallel, that's what I mean. Chip A, B, C or D might do something relying on the output of one of the other chips. I made a mistake when I said 64k colors, it should have been 4096 like you pointed out and that's another point. Very few games use HAM 8 so you can not emulate ham 8 and still have a high percentage of compatability. Now, granted you could probably say the same thing for mode 7 on the snes. There has been a great deal of work done on both systems, lucky for us. I guess in the end they are both complicated to emulate and it's a tribute to the work of the programmers that we can enjoy emulation of both systems, although the Amiga emulation needs some more work. I personally don't think we will ever have full speed high compatability a500 emulation on the gp2x unless both chips are used.

Chris

I think the Amiga was closer in power to a Genesis than a SNES. The Amiga had no sound DSP, no alpha channel, and only a simple 8-bit 4 channel DAC for sound. It had very rudimentary sprite support and no "mode 7". It had a blitter, a big deal in it's day, but now the blitter seems rather simplistic compared to what is out there. The graphics in games were only 32 colors on-screen out of 4096 at a resolution of only 320x200 (NTSC). Even at that MOST Amiga games were Atari-ST ports that only used 16 colors on screen. It didn't even have any tile engine, it was just bitmap and blitter based. NeoGeo is a more complicated system than an Amiga and that runs great on the GP2X. I think the Amiga could be full-speed with sound on the GP2X if it was worked on as diligently as some of the other emus out there such as NES, Mega-CD, or SNES.

 

[Macguyver]

QUOTE
Chris


I think the Amiga could be full-speed with sound on the GP2X if it was worked on as diligently as some of the other emus out there such as NES, Mega-CD, or SNES.


I agree, it would be great to see new momentum on either one of the Amiga emulators. They both had such a promising start. B)

Mac

 

[christo930]

I was bringing in an example from the PC world. We have usable N64 emulation and still no Saturn emulation.

Check out the Saturn emulator called SSF. It's true that Saturn emulation requires a lot more out of a PC than N64 emulation - part of it is because of all the parallelism on Saturn like you said, but the other part is due to high level emulation of the N64. Note that a pure LLE N64 emulator is probably currently slower than Saturn emulation.

The sound chip and video system wouldn't be said to be running in parallel, that's what I mean. Chip A, B, C or D might do something relying on the output of one of the other chips.

This isn't how these chips run on consoles like SNES. The CPU merely sets up a few things (maps, sprites, voice pitches, what have you) and the video and sound chips go off and work on these things on their own. To add to that fact, the SPC700 on SNES has a full general purpose CPU of its own. While Amiga does have a sort of instruction processor for its blitter, it's very simple (and probably spends most of its time waiting for events)

I made a mistake when I said 64k colors, it should have been 4096 like you pointed out and that's another point. Very few games use HAM 8 so you can not emulate ham 8 and still have a high percentage of compatability.

You're probably right. And on average SNES games are probably more color dense than Amiga ones (actually, HAM doesn't change this much given the color tricks you can do on SNES).

Now, granted you could probably say the same thing for mode 7 on the snes.

I don't think so, mode 7 is very common. I would go so far as to say a majority (over 50%) of games use it somewhere, but that's very hard to back up. It's true that most games don't use it constantly (except say, racing games), but it's a pretty central part of SNES emulation.

There has been a great deal of work done on both systems, lucky for us. I guess in the end they are both complicated to emulate and it's a tribute to the work of the programmers that we can enjoy emulation of both systems, although the Amiga emulation needs some more work. I personally don't think we will ever have full speed high compatability a500 emulation on the gp2x unless both chips are used.

Chris

I have a feeling it's attainable in some regard, I just don't think Amiga emulation has exactly been what everyone's jumping to do (for some reason). The funny thing is that UAE started when computers were significantly weaker than GP2X is. As far as I know, it's practically the grandfather of enthusiast emulation on PC and probably predates most major SNES emulators (definitely SNES9x and ZSNES)

I don't know much about Amiga coding to be honest (I only have some idea of how the hardware works), but I have to assume that most apps played somewhat nice with the hardware in order for all of the fancy workbench tricks to go on. I'd say most games stuck to a single resolution for the whole screen and were otherwise pretty straightforward. What if a high level emulation was used that provided the OS services and simply booted games and various applications fullscreen? Think DOSBox or Wine.


Probably 95% of the Amiga games are boot disks and not workbench applications, so I would think that approach wouldn't work. Also, alot of games (certainly not all) didn't play nice and won't work on anything but an A500 (unless you use whdload). Even so, most Amiga games didn't push the machine to the limit, although some did. If I recall correctly you can get more than 32 colors on screen at once by switching the pallete on a scanline basis.

Chris

Chris

. The graphics in games were only 32 colors on-screen out of 4096 at a resolution of only 320x200 (NTSC). Even at that MOST Amiga games were Atari-ST ports that only used 16 colors on screen.


You are right there, the games were often designed for the lowest common denominator. In a way, the atari ST had a really negative effect on the Amiga gaming scene. But there are some games that are Amiga only that really show off what the machine can do.

Chris

 

[Exophase]

Probably 95% of the Amiga games are boot disks and not workbench applications, so I would think that approach wouldn't work.

All the more reason why it would work, since then there wouldn't even be an OS running in the background at all. You'd still want to HLE the firmware functions.

Also, alot of games (certainly not all) didn't play nice and won't work on anything but an A500 (unless you use whdload).

All the more preferable because A500 is quite a bit on the low end and probably easiest to emulate. The CPU is slow, the graphics are relatively limited, etc.

Even so, most Amiga games didn't push the machine to the limit, although some did. If I recall correctly you can get more than 32 colors on screen at once by switching the pallete on a scanline basis.

Almost every console I've ever heard of can do this. On SNES and GBA it's fairly common. However, these consoles can do 256 colors normally, not counting the blending and other modes..

 

[christo930]

Probably 95% of the Amiga games are boot disks and not workbench applications, so I would think that approach wouldn't work.

All the more reason why it would work, since then there wouldn't even be an OS running in the background at all. You'd still want to HLE the firmware functions.

WOuldn't that make it harder, since you can't just provide the api, but instead have to emulate the hardware?

Also, alot of games (certainly not all) didn't play nice and won't work on anything but an A500 (unless you use whdload).

All the more preferable because A500 is quite a bit on the low end and probably easiest to emulate. The CPU is slow, the graphics are relatively limited, etc.

Aren't dirty little tricks and undocumented calls etc etc make emulation have to be more and more accurate, thus slowing it down?

Even so, most Amiga games didn't push the machine to the limit, although some did. If I recall correctly you can get more than 32 colors on screen at once by switching the pallete on a scanline basis.

Almost every console I've ever heard of can do this. On SNES and GBA it's fairly common. However, these consoles can do 256 colors normally, not counting the blending and other modes..


Yes, even the atari 5200 can put over 256 colors on the screen at once with this trick.

 

[DaveC]

You are right there, the games were often designed for the lowest common denominator. In a way, the atari ST had a really negative effect on the Amiga gaming scene. But there are some games that are Amiga only that really show off what the machine can do.

Yes, even the atari 5200 can put over 256 colors on the screen at once with this trick.

Chris

They still are. The last good example was the fact that most Xbox games were lazy PS2 ports. They used the same low res textures, lacked the bump mapping effects, and used blocky PS2 models in Xbox games directly many times. Lazy bastards Now though since the PS3 and 360 are pretty much the same graphically it will be less evident. I seriously doubt they will port Wii graphics to those as it would look way too poor and stand out.

Atari 5200? They used that trick on the Atari *2600*. You will notice many 2600 games with rainbow skys etc. Many Imagic and Activision games used raster effects.