A/NES PRO v1.14 released

[oRBIT]

The only NES emulator for Classic (high end) Amigas still in development is back with yet another new version.

http://www.anes.se

Here's what's new:
* CPU: cmp ($xx,x) bugfixed
* CPU: Stackhandler bugfixed (fixes "Slalom")
* Massive rewrite of CPU clockcycle timings (=better compability)
* Reading from CHRROM was broken. Fixed.
* Mapper 3 initcode was broken (fixes Dragon Quest(J).)
* Lots of PPU compability fixes
* Mappers that are not emulated now carries a "(!)" sign in the GUI.
* Added mapper 184 (95%)

[Xenon]

What are now the minimum requirements?

[mfletcher]

From the website:

Requirements
A/NES requires AGA chipset, a 68020 CPU and a few megabytes of FastRAM. However, to get the best experience, a 68040, or even better, a 68060 is recommended!
A CD32-joypad is also recommended for a better experience.

[Xenon]

Humm... ok. I remember the old emulator, although it was not so compatible, ran very well in my 68030 50 MHZ.

Regards,

[oRBIT]

A/NES PRO is an almost complete rewrite of the old A/NES and a really high end Amiga is recommended.

[dlfrsilver]

could it be possible to optimize it in order to get a decent speed on a A1230 ?

[oRBIT]

The graphicsengine is currently optimized for highend systems at the moment (targeted at Natami actually, if it ever gets released). I'm sure a more optimized engine can be written for lower end Amigas, but it's a tradeoff... Compability vs speed.

[Don_Adan]

Originally Posted by oRBIT

The graphicsengine is currently optimized for highend systems at the moment (targeted at Natami actually, if it ever gets released). I'm sure a more optimized engine can be written for lower end Amigas, but it's a tradeoff... Compability vs speed.

You can make optional JIT version for CPU emulation or put some routines online for later speed optimalisations. Simple CPU emulation of 8bit CPU uses too many CPU cycles (minimum one jump plus one table read is necessary or one jump and two commands for every 8bit command emulation).

[oRBIT]

I won't gain much on a JIT, I've done some experiments earlier. The "problem" is the graphicsengine.

[fitzsteve]

Hi!

Thanks for the updates. I'd tried ANes before and it wasn't very fast so I didn't use it.

The new version although much better still seems pretty slow, I've tried it on my A4000 with 50mhz 060 and CGX RTG (CV64/3D) and its not full speed. Should it be?

I also tested on 66mhz 060 in my A1200T + Voodoo 3 and it was about the same speed so not much gain for the extra mhz.

Maybe I'm doing something wrong?

The sound and graphics are very clear, it was Super Mario that I tested.

Steve.

[oRBIT]

@fitzsteve: Try changing driver to CGFX/P96 (check the preferences), that should be faster. Please let me know how it goes.

[fitzsteve]

Originally Posted by oRBIT

@fitzsteve: Try changing driver to CGFX/P96 (check the preferences), that should be faster. Please let me know how it goes.

Hi, thats what I am doing

[oRBIT]

Originally Posted by fitzsteve

Hi, thats what I am doing

How is it compared to ECS/AGA mode? Check the "FPS" in the GUI when quitting the game.

[dlfrsilver]

Just tried it, well it seems that *it* could be bettered on A1230. Anes 1.14 is quite evolved, and while it's slow, it's quite playable

I think you're going the right way !

[Galahad/FLT]

I remember CoolNES being quite a quite emulator back in the day.

[Don_Adan]

Originally Posted by oRBIT

I won't gain much on a JIT, I've done some experiments earlier. The "problem" is the graphicsengine.

Ok. Then tell me how many cycles for 68030 or 68060 used your current version of graphicsengine, and how many (average) cycles is necessary for emulation of one 8bit command in your current emulator, perhaps ~35c for 68030. Pure graphicsengine emulation of Atari ST needs ~50% of 68030 50MHz power.

[oRBIT]

I'm pretty confident the CPU-core runs realtime on a 68030/50. The graphicsengine works with chunkypixels at the moment and converting 256x240x5 at 50/60fps on AGA is obviously a challenge (however it was coded that way with Natami in mind).
I haven't measured any cycles.

[Don_Adan]

Originally Posted by oRBIT

I'm pretty confident the CPU-core runs realtime on a 68030/50. The graphicsengine works with chunkypixels at the moment and converting 256x240x5 at 50/60fps on AGA is obviously a challenge (however it was coded that way with Natami in mind).
I haven't measured any cycles.

Of course, 1.8MHz CPU can be emulated without problems by 68030 50MHz, but if 8bit CPU works at 100% of possible power, then simple code emulation for 68030 50 MHz needs about 80% of 68030 power = no enough CPU power for graphics engine emulation. Anyway if you want I can put online short (out of registers) routine before optimalisation and after optimalisation, speed differences is about 20%. Maybe you can see some useful ideas/tricks for your (out of registers) routines?

[NovaCoder]

Originally Posted by oRBIT

I'm pretty confident the CPU-core runs realtime on a 68030/50. The graphicsengine works with chunkypixels at the moment and converting 256x240x5 at 50/60fps on AGA is obviously a challenge (however it was coded that way with Natami in mind).
I haven't measured any cycles.

Hiya,

With my ScummVM port to AGA it seems the main speed limiting factor is memory copying, what are you using to copy memory? The C2P stuff is obviously another overhead but the 320x200 memory copying is slower for me.

How are you doing the graphics for AGA, double buffered or straight to the screen?

Also, have you tried using a frame skipping technique?

Thanks for all of your hard work with this

[oRBIT]

Frameskipping is implemented as an option in the GUI. The only memorycopying I'm doing is when I render the chunkyscreen (merging screens to a single screen). This with the C2P is probably the most CPU intensive part of my emulator.
I don't currently use a double buffer for the ECS/AGA but it'd be pretty easy to do.
Priority now is to speedup the gfxcode.