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).
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é
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 !
À 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.
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.
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 ?
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 !
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 !)
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
Inscription : 29 Août 2007, 12:04 Message(s) : 1793 Localisation : seine et marne 77
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
_________________ SPS Community Expert (SPS CE) / SPS France
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.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 3 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum
Connexion
Inscription
FAQ
).
