ACE CPC Emulator, only Amiga makes it possible?

[OffseT]

Say hello to the updated ACEpansion for the Albireo!

This new version fixes a few issues but also adds new features such as proper files date and time emulation as well as the ability to connect two Albireos at the same time.

As always, in addition to the ACEpansion SDK, source code of all ACEpansions is available (and it is for years!). Don't be afraid and feel free to use it to make other emulators as versatile as ACE CPC Emulator!

[Longshot]

Hello

The minor correction on CRTCs 0 and 2 that is indicated in the detail of the update notes of ACE 1.25 caught my attention.

Indeed, you write there that this correction makes it possible to "authorize the deactivation of the border byte between the vertical rupture".

ACE therefore now allows hiding the border byte displayed by default between 2 line segments on CRTC 0 and 2.

Can you specify the method used to hide the border byte on these CRTCs?
If you have code that demontrates this, can you share it?

This will allow me to document the method in the Compendium and to create the associated test in SHAKER.

[OffseT]

Can you specify the method used to hide the border byte on these CRTCs?
If you have code that demontrates this, can you share it?

This will allow me to document the method in the Compendium and to create the associated test in SHAKER.

I didn't have time to dig into the Shaker yet, but I guess it is something you should already cover. IIRC, it was just about emulating extra bits controlling border in R8.

[OffseT]

By the way, Nova ACEpansion was upgraded to v1.2 which fixes issues with clock emulation.

[Longshot]

I didn't have time to dig into the Shaker yet, but I guess it is something you should already cover. IIRC, it was just about emulating extra bits controlling border in R8.

It's a good thing if ACE now supports the R8 Skew Bits feature on CRTC 0.

Border management via R8 is not at all intended to cancel the border byte between 2 vertical rupture.
This is a trick using this function in a very specific context.
And to my knowledge never demonstrated elsewhere than in Shaker & Compendium.
Yet this is how you presented these corrections.

CRTC 2 does not control the BORDER, so emulating this function on this CRTC is a mistake.
If you hide the border byte on this CRTC, it cannot be with R8.

Could you share the code that allowed you to verify that ACE is able to handle this trick?
You may have done things differently from me, and that could enrich the Compendium.

[OffseT]

Nope, it was not a full R8 skew bits support. That's the reason of this description.
Full R8 skew support may or may not come. 

About the check code, I could get it when I'm back home.

[Longshot]

So you integrated a kludge in ACE to manage an effect that is only mentioned in the compendium...
And this effect does not exist in any official production other than in Shaker (2nd test).

If you made a risky emulation of R8, I advise you to remove it from your CRTC 2 code.
To my knowledge, this function does not exist on this circuit.

[OffseT]

So you integrated a kludge in ACE to manage an effect that is only mentioned in the compendium... And this effect does not exist in any official production other than in Shaker (2nd test).

I don't remember exactly when I was told about this feature, I guess it was Roudoudou about one year ago (or maybe is was Hicks?) which pointed me some preliminary documentation from you.

Just to give the full picture, some years ago, we created "Back to Futurs'", a demo which was using RVMB (a technic which is known to only work on CRTC 1). So, this R8 trick sounded as an interesting feature since it might have made it possible to adapt (at least partially) this demo for CRTC 0... and my test code was actually an abstract of this demo... and I expected ACE to make it run. 

[OffseT]

X-Mass ACEpansion was updated!

In addition to the legacy hard disc image support, this release adds a new mode where a directory can be used to directly share files between the emulated CPC and the host machine (this new mode is enabled by default), making X-Mass ACEpansion almost as helpful as Albireo one.

This nice feature was achieved thanks to an optimized Virtual VFAT implementation based on the code from QEmu (and Bochs) to simulate a VFAT32 structure on-the-fly over a directory contents.

Pick it here: http://ace.cpcscene.net

Enjoy!

[roudoudou]

You may stop buying PowerBook G4

http://www.roudoudou.com/AceHacked/

[Targhan]

You may stop buying PowerBook G4

WOW! This is GREAT! I hope you'll find the motivation to finish at least a version for developers to forget about Winape once and for all!!

[lordheavy]

You may stop buying PowerBook G4

http://www.roudoudou.com/AceHacked/

Wow, without source code ? you are really impressive !

[roudoudou]

Ace wasn't supposed to have a port because it's very close to the morphOS architecture


Offset gaves me the source code access and i bypassed most of the engine, doing an hybrid  version of his emulator whith the one i was working on the side

There is still some internal behaviour to fix, Ace engine is highly sensitive but all the human machine interface is already ok

Ace is "hacked" because i rewrote many things from scratch to facilitate porting between Linux/MacOS and Windows

Dont know if it will be the definitive name

note: i benefited part of the work of Pulkomandy for little endian adaptation, the first one to succeed to port Ace on another architecture

[OffseT]

Just to summarize, ACE is written in plain C and has no clumsy libraries dependencies.
It makes it potentially portable to anything.

That said, the code is composed of three parts:

• The emulation core, which is 99% portable on anything (including PC world).
• The application layer, which is portable with some additional effort.
• The GUI, which is not portable at all unless you can deal with Magic User Interface GUI toolkit (only available on MorphOS, AmigaOS, AROS).

Over the time, many people got access to ACE source code, and there were many (unsuccessful) attempts to port it to the PC world.

@PulkoMandy did an exceptional job in that regard. He fixed the emulation core to work on little endian and 64-bits CPUs, and he created an os-wrapper so that main Amiga libraries could be emulated thru POSIX calls. He also reimplemented all the GUI and the application layer for Haiku, in a 1:1 feature compliance with the original version.

Roudoudou can benefit from all the work on the emulation core, but he obviously has to rebuild from scratch an application and GUI around it. And even if the goal here is not a 1:1 feature compliance, it is still a lot of work!

So, don't expect this port to be as complete and polished than MorphOS and Haiku versions yet, but at least it will work on MacOS, Linux and Windows; which is, I guess, the main point.

As a consequence, ACE emulation core will also benefit from Roudoudou's work on the FDC which will provide a more precise emulation and support for HFE file.

[roudoudou]

MacOS version is alive!



This week, i had some time to finish a new configuration menu,Read/Write/Execution breakpoints, memory dump, some drag'n'drop, rom pack (Mister) support, DMA debug ...

The goal is to achieve a first public version for BND meeting at the end of october

[OffseT]

Play2CPC ACEpansion was finally released!

Well, this is a new old release.

This plugin was actually created over a year ago, but for some reason the release was postponed and then... forgotten in the darkness of a hard drive.

Now it's time to unleash it!

Pick it here: http://ace.cpcscene.net

Enjoy!

[Redbug]

Need !

[roudoudou]

Little update for ACE-DL (Windows/Mac/Linux)
http://www.roudoudou.com/ACE-DL/

new downloads for ACE and RASM 

[roudoudou]

oups, trace badly working cause of flags permutation, new upload right now available  

why did I volunteer for this?