CPC Rulez :: Consulter le sujet - [EMU] ACE (OffseT)

Ah voila un sujet qui m'intéresse

En fait, j'ai eu la même démarche que toi (concernant le FDC) : Au début, j'ai juste codé un vague truc qui fonctionnait la plupart du temps. Puis, je suis tombé sur les protections, et j'avoue que le challenge m'a un peu titillé. Du coup, voila la doc, et plusieurs versions de FDC plus tard... J'aboutis à un code qui fait la même chose que toi : Gère le FDC d'après le flux MFM (au final, c'est beaucoup plus simple).

Donc, conversion des dsk en MFM, via des algos plus compliqués les uns que les autres... Et découverte du kryoflux et SCP (merci breiztiger !), qui me donne quasiment directement le flux en natif (à un petit algo de pll près pour gérer les vitesses fluctuantes de rotation du disque). Alleluia !

Dans l'idée, le CT-Raw serait le meilleurs format (plus compact, on stock juste les bits MFM), mais la lib ne m'a pas convaincue.... Je l'utilise cependant, mais globalement, je reste circonspect sur cette lib (une lib plutôt orienté ST, avec quelques bugs, et un fonctionnement interne un peu trop propriétaire pour notre bien).

L'immense avantage du SCP, c'est que, je crois, on peut réécrire des disques à partir de ce format (facile à générer, en plus). Mais ça reste gros, surtout pour les révolutions multiples (pour gérer les weaks sectors).

A mon avis le format parfait serait, en gros, un CT Raw avec compression, et, surtout, un petit travail pour reconstituer la piste au bit près (et non pas approximativement, ce qui pose parfois des problèmes sur certaines protections basé sur une taille de piste précise (et donc, a mon avis, assez compliquée a copier par un simple lecteur)).

Bref....

Sinon, je peux te poser des questions sur le CRTC ? Parce que le 0 me fais avoir des sueurs froides...

(Sinon, ACE propose tellement de truc en plus de sugarbox que je saurais prendre la responsabilité de son non-portage sur PC !)

Auteur :	Kukulcan [ 09 Avr 2013, 13:27 ]
Sujet du message :	Re: [EMU] ACE (OffseT)
OffseT a écrit : Megachur a écrit : c'est toujours aussi frustrant pour moi de ne pouvoir le voir fonctionner ! Mais non, ça n'est pas dramatique. Vous avez déjà de bons émulateurs CPC sous Windows, il n'y a pas d'urgence. Disons "pas mauvais", mais bons, ça c'est une autre histoire

Auteur :	OffseT [ 10 Avr 2013, 22:36 ]
Sujet du message :	Re: [EMU] ACE (OffseT)
Kris a écrit : Suis pressé de rentrer pour tester cette derniere mouture, surtout avec l'emulation CPC+ inside J'imagine que tu as testé pas mal de soft dedié "Plus" pour valider cette version ? Oui, j'ai testé un certain nombre de choses. Je sais que tout ne marchera pas encore, il faut garder à l'esprit qu'il s'agit de la toute première version avec le support CPC+. Enfin, tous les jeux marchent et la plupart des démos aussi, mais il me reste des choses à corriger (notamment dans l'émulation CRTC 3, pour le moment seul le CRTC 1 est à priori parfait). Côté CPC+, cette version met surtout l'accent sur l'émulation des DMA (les sid-voices sont nickels), sur les timings pour les splits rasters (sur CPC+ on peut les positionner au pixel mode 0 près selon l'instruction utilisée pour poker dans l'ASIC) et sur l'émulation des bugs de l'ASIC (une vraie plaie...). La prochaine version ajoutera moins de fonctionnalités mais corrigera les soucis restants (surtout concernant les CRTC autres que le type 1). Maintenant que tout est en place, ça devrait aller assez vite ; le plus gros du boulot est fait. Ensuite seulement viendra la phase des portages (pas avant la version 2.0, comme prévu depuis le début). Pour info, cette v1.5 est déjà en phase de portage sur Haiku qui a droit la primeur (également comme prévu depuis le début).

Auteur :	fano [ 11 Avr 2013, 08:42 ]
Sujet du message :	Re: [EMU] ACE (OffseT)
Vu ce que ça promet , vivement une version Windows !

Auteur :	Hicks [ 11 Avr 2013, 17:47 ]
Sujet du message :	Re: [EMU] ACE (OffseT)
Pour avoir vu tourner ACE à la Revision, je dois dire qu'il n'y a aucune comparaison possible avec les autres émulateurs existants... Je n'ai vu aucune démo se faire massacrer, même les parts délicates avec timings serrés. Ca redonnerait presque ses lettres de noblesse aux "émulateurs"... Au moins, les non-CPCistes qui disposent de l'équipement (C-64istes, Ataristes, Amigaistes, etc.) pourront voir avec ACE quelque chose qui ressemble à la production originale... ...bon j'ai dit un peu trop de bien là. J'ajoute donc que le CRTC 0 est vraiment mal émulé

Auteur :	OffseT [ 18 Avr 2013, 18:18 ]
Sujet du message :	Re: [EMU] ACE (OffseT)
Oulala, c'est quoi ces compliments ? Hicks ! Attention à ce que tu dis en public, ta réputation de petit dictateur acerbe pourrait en pâtir. Sinon, oui, le CRTC 0 est plutôt médiocre pour le moment. Je n'ai pas de CRTC 0, je l'ai donc fait en aveugle à partir de ce que je sais mais ça n'est clairement pas suffisant. Le CRTC 3 n'est pas terminé non plus, mais vu que j'en ai un ça sera plus simple. Idem pour le CRTC 2. Ceci étant, n'oublions pas que le CRTC 1 est peut-être simplement parfait (à ce jour tout ce que j'ai pu tester dessus réagit exactement comme sur un vrai CRTC 1, aussi pour ce qui marche que pour ce qui ne marche pas sur CRTC 1). ... et je vais tâcher de ramener tous les CRTC au même niveau que le 1 pour la v1.6 !

CPC Rulez https://cpcrulez.fr/forum/

[EMU] ACE (OffseT) https://cpcrulez.fr/forum/viewtopic.php?f=7&t=4598	Page 5 sur 14

Auteur :	Plissken [ 18 Avr 2013, 19:03 ]
Sujet du message :	Re: [EMU] ACE (OffseT)
Peu etre un compliment car ton emulateur est tres bien.

Auteur :	OffseT [ 24 Avr 2014, 13:32 ]
Sujet du message :	Re: [EMU] ACE (OffseT)
À l'occasion de la Revision 2014 une nouvelle version d'ACE est sortie. Cette version 1.6 apporte surtout des améliorations au niveau des outils de monitoring intégrés et diverses simplifications au niveau de l'interface graphique. Elle n'est pour le moment disponible que pour MorphOS mais PulkoMandy est en train de travailler au portage sur Haiku qui devrait être disponible dans les mois qui viennent. Un portage pour AmigaOS 4.1 est également prévu d'ici la fin de l'année. Pour rappel, ACE est disponible ici : http://ace.cpcscene.com

Auteur :	OffseT [ 17 Juin 2014, 20:03 ]
Sujet du message :	Re: [EMU] ACE (OffseT)
ACE est désormais disponible en version 1.7 ! Plein de petites nouveautés dans cette versions mais aucune grosse fonctionnalité en dehors de l'ajout du support de l'émulation cassette (pour laquelle je n'avais eu aucune motivation jusqu'à la sortie de la Breaking Bauds). Comme toujours cette version n'est disponible que pour MorphOS mais cela devrait bientôt changer puisque ACE 1.7 pour AmigaOS 4.1 en est déjà au stade de la version beta. Parallèlement Pulko travaille toujours au portage Haiku (sur la version 1.6 pour le moment). Voilà, c'était tout, je vous laisse tranquille maintenant.

Auteur :	OffseT [ 17 Juil 2014, 21:51 ]
Sujet du message :	Re: [EMU] ACE (OffseT)
Je profite de ce fil pour lancer une petite réflexion... Même si je n'ai pas pu le tester faute de PC, j'ai lu avec plaisir que Sugarbox est enfin un émulateur qui ne se contente pas des DSK. Depuis le début j'ai trouvé ce format abominable et d'ailleurs dans ACE je ne les gère pas directement (ils sont convertis à la volée en disque "physique" en RAM et inversement). Mais j'ai toujours vu ça comme une solution transitoire en attendant de passer sur un vrai format physique (le code de conversion à la volée est plus gros que le code d'émulation FDC...). Puisque Sugarbox a opté pour le format .SCP, je pense que je vais faire de même mais ça veut dire qu'il va falloir un gros travail de dump pour mettre toute la logithèque à jour. Concernant le CT-RAW, j'avais commencé à me pencher sur le portage de la lib CAPS, mais je vais laisser tomber à priori (créer une .library MorphOS avec du code C++ demande une expertise que je n'ai visiblement pas vu que le moindre "new" explose ). Or donc, le format SCP est un bon candidat mais voici quelques remarques : 1. les fichiers sont très gros, il sera sans doute intéressant de les compresser/décompresser à la volée... mais ça risque d'être un peu pénible car vu la taille ça ne sera pas instantané. 2. ils ne contiennent pas de champs pour les méta-données (éditeur, année, type, etc.) ; quitte à avoir un nouveau format ça serait bien d'y prévoir ces informations. 3. leur structure interne n'est pas très homogène (certaines données sont en little endian et d'autres en big endian). Dès lors, ne faudrait-il pas plutôt considérer le format .SCP comme le master permettant de créer un format enrichi plus complet et plus propre ? PS : puisque Sugarbox semble être prometteur je vais peut-être pouvoir m'enlever le poids de porter ACE sur PC ?

Auteur :	AsT [ 17 Juil 2014, 21:57 ]
Sujet du message :	Re: [EMU] ACE (OffseT)
OffseT a écrit : PS : puisque Sugarbox semble être prometteur je vais peut-être pouvoir m'enlever le poids de porter ACE sur PC ? Ah,ah, ah... Sacre philippe, tout pour eviter une version pc.... Non mais dis donc, on l'attends ta version de Ace sur pc windows.... Na ! Tu t en sortiras pas comme ca !

Auteur :	Lone [ 17 Juil 2014, 22:26 ]
Sujet du message :	Re: [EMU] ACE (OffseT)
Ah voila un sujet qui m'intéresse En fait, j'ai eu la même démarche que toi (concernant le FDC) : Au début, j'ai juste codé un vague truc qui fonctionnait la plupart du temps. Puis, je suis tombé sur les protections, et j'avoue que le challenge m'a un peu titillé. Du coup, voila la doc, et plusieurs versions de FDC plus tard... J'aboutis à un code qui fait la même chose que toi : Gère le FDC d'après le flux MFM (au final, c'est beaucoup plus simple). Donc, conversion des dsk en MFM, via des algos plus compliqués les uns que les autres... Et découverte du kryoflux et SCP (merci breiztiger !), qui me donne quasiment directement le flux en natif (à un petit algo de pll près pour gérer les vitesses fluctuantes de rotation du disque). Alleluia ! Dans l'idée, le CT-Raw serait le meilleurs format (plus compact, on stock juste les bits MFM), mais la lib ne m'a pas convaincue.... Je l'utilise cependant, mais globalement, je reste circonspect sur cette lib (une lib plutôt orienté ST, avec quelques bugs, et un fonctionnement interne un peu trop propriétaire pour notre bien). L'immense avantage du SCP, c'est que, je crois, on peut réécrire des disques à partir de ce format (facile à générer, en plus). Mais ça reste gros, surtout pour les révolutions multiples (pour gérer les weaks sectors). A mon avis le format parfait serait, en gros, un CT Raw avec compression, et, surtout, un petit travail pour reconstituer la piste au bit près (et non pas approximativement, ce qui pose parfois des problèmes sur certaines protections basé sur une taille de piste précise (et donc, a mon avis, assez compliquée a copier par un simple lecteur)). Bref.... Sinon, je peux te poser des questions sur le CRTC ? Parce que le 0 me fais avoir des sueurs froides... (Sinon, ACE propose tellement de truc en plus de sugarbox que je saurais prendre la responsabilité de son non-portage sur PC !)

Auteur :	breiztiger [ 17 Juil 2014, 22:34 ]
Sujet du message :	Re: [EMU] ACE (OffseT)
Aaaahhhhh nickel si thomas et philippe dialogue ... l'emulateur ultime ne devrait pas etre loin allez les gars, une release conjointe pour la prochaine reset merci d'avance pour votre travail breiztiger (emmerdeur de créateurs d'emulateurs ...)

Auteur :	Kris [ 18 Juil 2014, 08:12 ]
Sujet du message :	Re: [EMU] ACE (OffseT)
Content de lire tout ça, l'un va faire progresser l'autre et on peut s'attendre a qqchose de vraiment interessant niveau format image disks. Le plus long va etre le dump de milliers d' originaux en .SCP.... meme si le travail est deja en route

Auteur :	dlfrsilver [ 18 Juil 2014, 19:15 ]
Sujet du message :	Re: [EMU] ACE (OffseT)
Lone a écrit : Ah voila un sujet qui m'intéresse En fait, j'ai eu la même démarche que toi (concernant le FDC) : Au début, j'ai juste codé un vague truc qui fonctionnait la plupart du temps. Puis, je suis tombé sur les protections, et j'avoue que le challenge m'a un peu titillé. Du coup, voila la doc, et plusieurs versions de FDC plus tard... J'aboutis à un code qui fait la même chose que toi : Gère le FDC d'après le flux MFM (au final, c'est beaucoup plus simple). Donc, conversion des dsk en MFM, via des algos plus compliqués les uns que les autres... Et découverte du kryoflux et SCP (merci breiztiger !), qui me donne quasiment directement le flux en natif (à un petit algo de pll près pour gérer les vitesses fluctuantes de rotation du disque). Alleluia ! Dans l'idée, le CT-Raw serait le meilleurs format (plus compact, on stock juste les bits MFM), mais la lib ne m'a pas convaincue.... Je l'utilise cependant, mais globalement, je reste circonspect sur cette lib (une lib plutôt orienté ST, avec quelques bugs, et un fonctionnement interne un peu trop propriétaire pour notre bien). L'immense avantage du SCP, c'est que, je crois, on peut réécrire des disques à partir de ce format (facile à générer, en plus). Mais ça reste gros, surtout pour les révolutions multiples (pour gérer les weaks sectors). A mon avis le format parfait serait, en gros, un CT Raw avec compression, et, surtout, un petit travail pour reconstituer la piste au bit près (et non pas approximativement, ce qui pose parfois des problèmes sur certaines protections basé sur une taille de piste précise (et donc, a mon avis, assez compliquée a copier par un simple lecteur)). Bref.... Sinon, je peux te poser des questions sur le CRTC ? Parce que le 0 me fais avoir des sueurs froides... (Sinon, ACE propose tellement de truc en plus de sugarbox que je saurais prendre la responsabilité de son non-portage sur PC !) Le format CT-Raw incorpore une compression Delta

Page 5 sur 14	Le fuseau horaire est UTC+1 heure
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/

Auteur :	OffseT [ 19 Juil 2014, 09:53 ]
Sujet du message :	Re: [EMU] ACE (OffseT)
Lone a écrit : En fait, j'ai eu la même démarche que toi (concernant le FDC) [...] Oui, je pense que c'est indispensable pour avoir quelque chose qui ressemble à une émulation (sinon le FDC n'est qu'un lecteur de DSK avec des hacks plus ou moins tordus pour gérer les protections). En revanche je ne suis pas allé jusqu'à recomposer un flux MFM à partir du DSK ; j'ai clairement eu la flemme vu que dans mon esprit c'était une solution transitoire. Mais tout est déjà organisé pour gérer ça côté FDC et passer sur un format .SCP se fera sans douleur. Pour le reste, dans mon idée initiale j'imaginais plutôt les données MFM que directement le flux en entrée ; essentiellement dans un soucis de performance (et bien sûr de consommation mémoire). Lone a écrit : Dans l'idée, le CT-Raw serait le meilleurs format (plus compact, on stock juste les bits MFM), mais la lib ne m'a pas convaincue.... [...] Oui, c'est peut-être effectivement un bon compromis. Un format qui contiendrait directement les bits MFM et leur timing sur la piste. Ça serait clairement plus compact et plus facile à compresser. De plus l'émulation serait triviale. Pour le conteneur, je verrais bien un format basé sur des chunks comme l'IFF ou le PNG. De cette manière il serait facile d'ajouter des informations plus tard sans perturber la lecture/écriture des fichiers (chaque émulateur gérera les chunks qu'il connait et dont il a besoin et laissera les autres inchangés). Ça permettrait aussi l'ajout de chunks privés pour des fonctionnalités spécifiques de certains émulateurs. Lone a écrit : L'immense avantage du SCP, c'est que, je crois, on peut réécrire des disques à partir de ce format (facile à générer, en plus). En fait, le format SCP est très lié au hard l'ayant produit et on peut aisément imaginer que plus tard il y aura sans doute d'autres formats "raw" liés à d'autres cartes. Il vaut dès lors peut-être mieux éviter d'être trop intimement lié à un tel format. Peut-être faudrait-il le voir comme un format physique de base et faire un outil de packaging qui le prendait en entrée, ainsi que les informations de préservation pour sortir un "IPF-like". Ensuite, à partir de cet "IPF-like" on pourrait : - sortir des données physique en SCP ou dans n'importe quel format requis par une carte permettant de reproduire la disquette. - sortir notre nouveau format disque R/W "MFM bits" pour les émulateurs. - sortir les meta-données pour alimenter une base de données des softs CPC. - etc. Ceci pourrait d'ailleurs être pensé comme un service en ligne, le serveur de téléchargement stockerait uniquement les fichiers "preservation" et tous le reste pourrait être créé à la volée lors du téléchargement (comme ça pas besoin de faire des outils de conversion pour toutes les plateformes de la planète). Voilà l'était actuel de ma réflexion, mais je suis ouvert à toute alternative du moment qu'elle est raisonnable. Lone a écrit : Sinon, je peux te poser des questions sur le CRTC ? Parce que le 0 me fais avoir des sueurs froides... Oui bien sûr. Je n'ai pas encore terminé l'émulation CRTC 0 de ACE (toujours remise au lendemain par d'autres fonctionnalités...) mais elle commence à être "potable". Le plus simple est sans doute que tu m'écrives par email à ce sujet ou que tu passes sur #cpc.