MK2 68060@105 Mhz [fr]

Optimiser le software Warp3D : c'est bien... mais insuffisant ! Booster le hardware est aussi une excellente idée bien sûr ! Pour remettre nos Classics adorés à flots, tous les moyens sont bons...

Les CyberStorm MK2 ont une capacité d'overclocking assez limité : la mienne monte jusqu'à environ 72 Mhz... Certaines arrivent tout de même à 80 Mhz, mais hélas pas toutes ! Peut-être que les designers de cette carte ont volontairement bridé son potentiel d'overclocking tout comme la Blizzard 2060 pour Amiga 2000 qui monte peu en fréquence elle aussi hélas... Nous y reviendrons...

Sachant que les meilleurs 68060 rev6 peuvent atteindre 105-106 Mhz, beaucoup de mégahertz restent inutilisés, ce qui est bien dommage...

Faut pas gâcher, hein ?!

J'avais eu cette idée il y a déjà un an environ, mais mes bourdes idiotes sur mes trois adaptateurs de Mozart d'alors m'avaient empêché de la mettre en pratique. Enfin aujourd'hui l'expérience peut être tentée : utilisons même plutôt l'adaptateur de Matze bien plus pratique !

Reconfigurons déjà donc notre MK2 en mode 68040 en changeant de position deux résistances, en ôtant le régulateur +3.3v et en remettant le JMP du voltage sur +5v (mode 040), ainsi que les deux petites résistances comme ceci :

   

Nous revoilà donc avec une CyberStorm 68040 sur laquelle nous allons maintenant plugger notre fameux adaptateur magique. Le gros avantage de la version de Matze est sa nouvelle orientation. Ainsi le connecteur Scsi de la carte accélératrice n'est plus un problème :

 

En changeant le quartz par un 105 Mhz, le tout marche à merveille maintenant !

Le kit Scsi devrait en théorie fonctionner aussi puisque sa nouvelle fréquence est de 105 / 2 = 52.5 Mhz maintenant... Le maximum supporté étant tout comme pour les Blizzard 1260 aux alentours de 64-66 Mhz...

La dernière version de SysInfo est toujours dans les choux concernant la fréquence détectée :

J'ai envoyé un email à l'auteur et il me réponds qu'il connait bien ce bug et bosse dessus actuellement pour le fixer.

WhichAmiga marche lui très bien :

Attention, il est nécessaire d'ajouter un ventirad. Celui-ci est très bien, le rad n'est même pas tiède à l'utilisation et le ventilateur est silencieux :

 
Bref, nouvel hack très simple qui va ravire tous les utilisateurs de MK2, moi le premier bien sûr !!

 

Un grand bravo général à Mozart et Matze : vont finir ministres ces deux-là...

  

Compression (II) [eng]

Today, a quick article about the firmware composition :

1. fastram tester installed on card,
2. SCSI driver cybppc.device v44.71,
3. filesystem v3.20 for CD Roms drives (compressed)
4. Two VGA v44.1 drivers (compressed)
5. cybpci.library v2.2 (compressed)

There's also in the BlizzardPPC firmware, the ppc.library v46.35 (compressed) and the 68060.library v46.15 (uncompressed)...

The last four programms have been compressed with a Phase5 home made compressor which we'll call "crunchP5". In all the compression routines I have here, I didn't found the one which give the same final file.

Whatever, I started to optimise the uncompressing Shri routine  which has 3224 bytes for his original size. I've already won 600 bytes... It was so slow my friends, Oh la la... This xpkSHRI.library v2.2 dating from 1996 has, without a doubt, been compiled with a old version of SAS/C, it's a disaster...

The compressed programs have been uncompressed with the "decrunchP5" routine which is in the firmware and then compressed this time with our Shri. I've made some compression testing and Shri gives much better results, see for yourself :

1. CDFileSystem : 15 440 bytes => 10 332 bytes (crunchP5) => 8884 bytes (Shri.100),
2. VGAMonitor_1 : 19 072 bytes => 7984 bytes (crunchP5) => 7060 bytes (Shri.100),
3. VGAmonitor_2 : 4756 bytes => 3020 bytes (crunchP5) => 2588 bytes (Shri.100),
4. cybpci.library : 8856 bytes => 5456 bytes (crunchP5) => 4636 bytes (Shri.100),
5. 68060.library (BlizzardPPC) : 101 608 bytes => 36 724 bytes (Shri.100),
6. ppc.library (BlizzardPPC) : 160 532 bytes => 68 324 bytes (crunchP5) => 60 104 bytes (Shri.100).

No matter for the ppc.library (PowerUp), I let it outside, the fact is that Shri is a really powerfull compression routine for a lot of programs, this going to make us win some valuable space which is welcome in our famous firmware...

(translated by Squaley)

    

Compactage (II) [fr]

Un rapide article aujourd'hui sur la composition du firmware :

1. le testeur de fastram installée sur la carte,
2. le driver Scsi cybppc.device v44.71,
3. un système de fichiers v3.20 pour les lecteurs CDRoms (compacté),
4. deux drivers VGA v44.1 (compactés),
5. la cybpci.library v2.2 (compactée).

Il y a en plus dans celui des BlizzardPPC la ppc.library v46.35 (compactée) et la 68060.library v46.15 (non compactée)...

Les quatre derniers programmes ont été je suppose compacté avec un compacteur Phase5 fait maison que nous appellerons "crunchP5". Dans toutes les routines de compactages que j'ai ici, je n'ai pas trouvé celle qui donne le même fichier final.

Peu importe, j'ai commencé à optimiser la routine de décompactage Shri qui fait à l'origine 3224 octets en tout et pour tout. J'ai d'ores et déjà gagné environ 600 octets... C'était d'une lenteur les amis, oh là là... Cette xpkSHRI.library v2.2 datant de 1996 a sans doute été compilé avec une vieille version du SAS/C, c'est une catastrophe...

Les programmes compactés ont été décompacté avec leur routine "decrunchP5" présente dans le firmware et ensuite recompacté avec donc cette fois notre Shri. Je viens de faire quelques tests de compactage et la Shri donne de bien meilleurs résultats, constatez par vous-même :

1. CDFileSystem : 15 440 octets => 10 332 octets (crunchP5) => 8884 octets (Shri.100),
2. VGAMonitor_1 : 19 072 octets => 7984 octets (crunchP5) => 7060 octets (Shri.100),
3. VGAmonitor_2 : 4756 octets => 3020 octets (crunchP5) => 2588 octets (Shri.100),
4. cybpci.library : 8856 octets => 5456 octets (crunchP5) => 4636 octets (Shri.100),
5. 68060.library (BlizzardPPC) : 101 608 octets => 36 724 octets (Shri.100),
6. ppc.library (BlizzardPPC) : 160 532 octets => 68 324 octets (crunchP5) => 60 104 octets (Shri.100).

Peu importe pour la ppc.library (PowerUp), je la laisse dehors, c'est juste ici pour montrer que la Shri est vraiment une puissante routine de compactage pour beaucoup de programmes, ce qui va nous faire gagner encore un peu de précieuse place toujours bienvenue dans notre fameux firmware...

 

Compression (I) [eng]

So, the Warp3D libraries are quite large in size, we need to find a trick to fit in our future Kickstart or firmware... Of course, one of the solutions is to compress them.

I just realized some tests with the xPK libraries. I use the excellent xpackbest (on Aminet) which allows for a given file to quickly find its most powerful compression library :

Here's the rank of the best compression rates :

• W3D_Permedia2.library v4.3 beta 5 (561 364 bytes)

1. shr3.100 = 54 748 bytes (gain 91%)
2. bzp2.100 = 56 536 bytes (gain 90%)
3. lzcb.100 = 65 868 bytes (gain 89%)
4. shri.100 = 68 244 bytes (gain 88%)
5. tdcs.100 = 84 088 bytes (gain 86%)
6. gzip.100 = 87 788 bytes (gain 85%)
7. crm2.100 = 98 688 bytes (gain 83%)
8. mash.100 = 104 212 bytes (gain 82%)
9. lzw2.100 = 106 484 bytes (gain 82%)
10. ppmq.100 = 107 324 bytes (gain 81%)
11. lzw5.100 = 109 224 bytes (gain 81%)
12. lzw4.100 = 110 576 bytes (gain 81%)
13. lin4.100 = 110 012 bytes (gain 81%)
14. rake.100 = 111 192 bytes (gain 81%)
15. frht.100 = 111 200 bytes (gain 81%)
16. lzw3.100 = 111 200 bytes (gain 81%)
17. crms.100 = 113 036 bytes (gain 80%)
18. lin3.100 = 115 144 bytes (gain 80%)
19. impl.100 = 117 048 bytes (gain 80%)
20. sasc.100 = 123 908 bytes (gain 78%)
21. shid.100 = 124 748 bytes (gain 78%)
22. shsc.100 = 126 360 bytes (gain 78%)
23. lin2.100 = 127 300 bytes (gain78%)
24. lin1.100 = 136 368 bytes (gain 76%)
25. lzbs.100 = 143 896 bytes (gain 75%)
26. nuke.100 = 143 916 bytes (gain 75%)
27. duke.100 = 143 984 bytes (gain 75%)
28. sqsh.100 = 153 652 bytes (gain 73%)
29. pwpk.100 = 158 684 bytes (gain 72%)
30. sdhc.100 = 175 484 bytes (gain 69%)
31. ilzr.100 = 216 664 bytes (gain 62%)
32. lhlb.100 = 260 756 bytes (gain 54%)
33. fast.100 = 273 344 bytes (gain 52%)
34. dmcb.100 = 279 604 bytes (gain 51%)
35. slz3.100 = 280 212 bytes (gain 51%)
36. acca.100 = 299 920 bytes (gain 47%)
37. rdcn.100 = 301 648 bytes (gain 47%)
38. blzw.100 = 316 924 bytes (gain 44%)
39. zeno.100 = 386 256 bytes (gain 32%)
40. hfmn.100 = 530 028 bytes (gain 6%)
41. huff.100 = 532 916 bytes (gain 6%)
42. smpl.100 = 550 204 bytes (gain 2%)
43. cbr0.100 = 561 520 bytes (gain 0%)
44. frle.100 = 565 852 bytes (gain 0%)
45. fbr2.100 = 565 984 bytes (gain 0%)
46. rlen.100 = 566 108 bytes (gain 0%)

• W3D_AvengerLEMU.library v4.5 beta 2 (189 664 bytes)

1. gzip.100 = 25 916 bytes (gain 87%)
2. shr3.100 = 26 024 bytes (gain 87%)
3. shri.100 = 26 048 bytes (gain 87%)
4. lzcb.100 = 26 508 bytes (gain 87%)
5. mash.100 = 29 488 bytes (gain 85%)
6. crm2.100 = 29 648 bytes (gain 85%)
7. tdcs.100 = 29 792 bytes (gain 85%)
8. ppmq.100 = 30 040 bytes (gain 85%)
9. sasc.100 = 31 444 bytes (gain 84%)
10. rake.100 = 31 756 bytes (gain 84%)
11. frht.100 = 31 828 bytes (gain 84%)
12. impl.100 = 32 716 bytes (gain 83%)
13. shid.100 = 32 752 bytes (gain 83%)
14. bzp2.100 = 33 000 bytes (gain 83%)
15. shsc.100 = 33 436 bytes (gain 83%)
16. crms.100 = 35 244 bytes (gain 82%)
17. lzw2.100 = 35 368 bytes (gain 82%)
18. lin4.100 = 35 932 bytes (gain 82%)
19. lzw5.100 = 36 280 bytes (gain 81%)
20. lzw4.100 = 36 540 bytes (gain 81%)
21. lin3.100 = 37 128 bytes (gain  81%)
22. nuke.100 = 37 736 bytes (gain 81%)
23. lzw3.100 = 37 844 bytes (gain 81%)
24. sqsh.100 = 41 572 bytes (gain 79%)
25. lzbs.100 = 41 784 bytes (gain 78%)
26. lin2.100 = 42 256 bytes (gain 78%)
27. lhlb.100 = 43 044 bytes (gain 78%)
28. lin1.100 = 43 184 bytes (gain 78%)
29. duke.100 = 43 712 bytes (gain 77%)
30. pwpk.100 = 44 684 bytes (gain 77%)
31. sdhc.100 = 49 596 bytes (gain 74%)
32. fast.100 = 52 816 bytes (gain 73%)
33. slz3.100 = 55 320 bytes (gain 71%)
34. acca.100 = 55 540 bytes (gain 71%)
35. rdcn.100 = 56 052 bytes (gain 71%)
36. ilzr.100 = 56 644 bytes (gain 71%)
37. zeno.100 = 81 032 bytes (gain 58%)
38. dmcb.100 = 83 112 bytes (gain 57%)
39. blzw.100 = 88 028 bytes (gain 54%)
40. hfmn.100 = 141 416 bytes (gain 26%)
41. huff.100 = 142 516 bytes (gain 25%)
42. smpl.100 = 176 108 bytes (gain 8%)
43. frle.100 = 188 248 bytes (gain 1%)
44. fbr2.100 = 188 276 bytes (gain 1%)
45. rlen.100 = 188 324 bytes (gain 1%)
46. cbr0.100 = 188 368 bytes (gain 1%)

Excellent news : the libraries compress very well, the gain in size is huge, which suits us well because the space in our Kickstart is still limited !

Finally we need to choose the decompressing routine : ideally it is needed to be quite small... For example, the 'mash' is about 490 bytes while the 'shri' is still 3.2 Kb !

(translated by Squaley)

    

Compactage (I) [fr]

Alors, les librairies Warp3D étant assez volumineuses en poids, il faut trouver un truc pour qu'elles rentrent dans nos futurs Kickstart ou firmware... Une des solutions est bien sûr de les compacter.

Je viens de réaliser quelques tests avec les librairies xPK. J'utilise l'excellent xpackbest (sur Aminet) qui permet pour un même fichier donné de trouver rapidos sa plus puissante librairie compactrice :

Voici le classement des meilleurs taux de compression :

• W3D_Permedia2.library v4.3 beta 5 (561 364 octets)

1. shr3.100 = 54 748 octets (gain 91%)
2. bzp2.100 = 56 536 octets (gain 90%)
3. lzcb.100 = 65 868 octets (gain 89%)
4. shri.100 = 68 244 octets (gain 88%)
5. tdcs.100 = 84 088 octets (gain 86%)
6. gzip.100 = 87 788 octets (gain 85%)
7. crm2.100 = 98 688 octets (gain 83%)
8. mash.100 = 104 212 octets (gain 82%)
9. lzw2.100 = 106 484 octets (gain 82%)
10. ppmq.100 = 107 324 octets (gain 81%)
11. lzw5.100 = 109 224 octets (gain 81%)
12. lzw4.100 = 110 576 octets (gain 81%)
13. lin4.100 = 110 012 octets (gain 81%)
14. rake.100 = 111 192 octets (gain 81%)
15. frht.100 = 111 200 octets (gain 81%)
16. lzw3.100 = 111 200 octets (gain 81%)
17. crms.100 = 113 036 octets (gain 80%)
18. lin3.100 = 115 144 octets (gain 80%)
19. impl.100 = 117 048 octets (gain 80%)
20. sasc.100 = 123 908 octets (gain 78%)
21. shid.100 = 124 748 octets (gain 78%)
22. shsc.100 = 126 360 octets (gain 78%)
23. lin2.100 = 127 300 octets (gain78%)
24. lin1.100 = 136 368 octets (gain 76%)
25. lzbs.100 = 143 896 octets (gain 75%)
26. nuke.100 = 143 916 octets (gain 75%)
27. duke.100 = 143 984 octets (gain 75%)
28. sqsh.100 = 153 652 octets (gain 73%)
29. pwpk.100 = 158 684 octets (gain 72%)
30. sdhc.100 = 175 484 octets (gain 69%)
31. ilzr.100 = 216 664 octets (gain 62%)
32. lhlb.100 = 260 756 octets (gain 54%)
33. fast.100 = 273 344 octets (gain 52%)
34. dmcb.100 = 279 604 octets (gain 51%)
35. slz3.100 = 280 212 octets (gain 51%)
36. acca.100 = 299 920 octets (gain 47%)
37. rdcn.100 = 301 648 octets (gain 47%)
38. blzw.100 = 316 924 octets (gain 44%)
39. zeno.100 = 386 256 octets (gain 32%)
40. hfmn.100 = 530 028 octets (gain 6%)
41. huff.100 = 532 916 octets (gain 6%)
42. smpl.100 = 550 204 octets (gain 2%)
43. cbr0.100 = 561 520 octets (gain 0%)
44. frle.100 = 565 852 octets (gain 0%)
45. fbr2.100 = 565 984 octets (gain 0%)
46. rlen.100 = 566 108 octets (gain 0%)

• W3D_AvengerLEMU.library v4.5 beta 2 (189 664 octets)

1. gzip.100 = 25 916 octets (gain 87%)
2. shr3.100 = 26 024 octets (gain 87%)
3. shri.100 = 26 048 octets (gain 87%)
4. lzcb.100 = 26 508 octets (gain 87%)
5. mash.100 = 29 488 octets (gain 85%)
6. crm2.100 = 29 648 octets (gain 85%)
7. tdcs.100 = 29 792 octets (gain 85%)
8. ppmq.100 = 30 040 octets (gain 85%)
9. sasc.100 = 31 444 octets (gain 84%)
10. rake.100 = 31 756 octets (gain 84%)
11. frht.100 = 31 828 octets (gain 84%)
12. impl.100 = 32 716 octets (gain 83%)
13. shid.100 = 32 752 octets (gain 83%)
14. bzp2.100 = 33 000 octets (gain 83%)
15. shsc.100 = 33 436 octets (gain 83%)
16. crms.100 = 35 244 octets (gain 82%)
17. lzw2.100 = 35 368 octets (gain 82%)
18. lin4.100 = 35 932 octets (gain 82%)
19. lzw5.100 = 36 280 octets (gain 81%)
20. lzw4.100 = 36 540 octets (gain 81%)
21. lin3.100 = 37 128 octets (gain  81%)
22. nuke.100 = 37 736 octets (gain 81%)
23. lzw3.100 = 37 844 octets (gain 81%)
24. sqsh.100 = 41 572 octets (gain 79%)
25. lzbs.100 = 41 784 octets (gain 78%)
26. lin2.100 = 42 256 octets (gain 78%)
27. lhlb.100 = 43 044 octets (gain 78%)
28. lin1.100 = 43 184 octets (gain 78%) 
29. duke.100 = 43 712 octets (gain 77%)
30. pwpk.100 = 44 684 octets (gain 77%)
31. sdhc.100 = 49 596 octets (gain 74%)
32. fast.100 = 52 816 octets (gain 73%)
33. slz3.100 = 55 320 octets (gain 71%)
34. acca.100 = 55 540 octets (gain 71%)
35. rdcn.100 = 56 052 octets (gain 71%)
36. ilzr.100 = 56 644 octets (gain 71%)
37. zeno.100 = 81 032 octets (gain 58%)
38. dmcb.100 = 83 112 octets (gain 57%)
39. blzw.100 = 88 028 octets (gain 54%)
40. hfmn.100 = 141 416 octets (gain 26%)
41. huff.100 = 142 516 octets (gain 25%)
42. smpl.100 = 176 108 octets (gain 8%)
43. frle.100 = 188 248 octets (gain 1%)
44. fbr2.100 = 188 276 octets (gain 1%)
45. rlen.100 = 188 324 octets (gain 1%)
46. cbr0.100 = 188 368 octets (gain 1%)

Excellente nouvelle : les librairies se compactent très bien, le gain en terme de poids est énorme, ce qui nous arrange vraiment puisque la place dans nos Kickstart est tout de même assez limitée !

 

Reste enfin à choisir la routine de décompactage : dans l'idéal, il faut qu'elle soit assez petite... Par exemple, la mash fait environ 490 octets alors que la shri pèse tout de même 3,2 Ko...

 

CSPPC firmware (II) [eng]

Toni Wilen who update regulary WinUAE has published a new beta version which take charge of BlizzardPPC, CyberStormPPC and CyberStormMK3 cards and also, of course, their firmwares management.

A very interesting option, since this version allows me to test my different optimised firmwares before using them on our true hardware :

I already removed the ugly $VER: before W3D_CyberGfx4.library

It is here the small W3D_CyberGfx4.library 4.3 beta 4 (6,5 ko) which I integrated on the firmware. Grace to the previous work done on the betas which consisted, amongst other, to make this library PC relative, I only needed 19 extra lines of code to make it romable or rather firmwareable... It appears in the resident section, which means it's now in rom...

I look forward to test it on our hardware...

No need to install this library on hard drive or compact flash card now... There's only need to switch on the Amiga and it rulez...Users who wanted simplicity will be happy !

I also removed the ppc.library v46.35 (PowerUP system from Phase 5) from the firmware of the BlizzardPPC for the 1 MB kickstarts to work... Tested on WinUAE 2.9.0 béta 9 of course and it works !
  

(translated by Squaley)

    

CSPPC firmware (II) [fr]

Toni Wilen qui mets à jour régulièrement WinUAE vient de publier une nouvelle version béta qui prends en charge les cartes BlizzardPPC, CyberStormPPC et CyberStormMK3 ainsi que bien sûr la gestion de leurs firmwares.

Option très intéressante, puisque cette émulation me permet de tester mes différents firmwares améliorés avant de les essayer sur notre vrai hardware à nous :

J'ai d'ores et déjà ôté le $VER: disgracieux avant W3D_CyberGfx4.library

C'est donc ici la petite W3D_CyberGfx4.library 4.3 beta 4 (pesant 6,5 Ko) que j'ai intégré au firmware. Grâce au travail des précédentes bétas qui a consisté entre autre à rendre cette librairie PC relative, je n'ai eu besoin que de 19 lignes de code supplémentaires pour la rendre romable ou plutôt firmwareable... Elle apparaît bien dans la rubrique "Résidents", c'est à dire qu'elle réside en rom maintenant...

Me tarde de tester tout ça sur notre hardware...

Plus besoin d'installer cette librarie sur disque dur ou carte compactflash dorénavant... Y'a plus qu'à allumer l'Amiga et ça rulez... Les utilisateurs qui voulaient de la simplicité seront contents !

J'ai aussi ôté la ppc.library v46.35 (système PowerUP de Phase5) du firmware de la BlizzardPPC pour que les Kickstart de 1 Mo fonctionnent... Testé sous WinUAE 2.9.0 béta 9 bien sûr, et ça marche !

 

CSPPC firmware (I) [eng]

Whew, after many difficulties of all kind, here is finally a new article...

Thierry Phase5 CyberStormPPC wasn't working anymore... After the traditional 060 socket change, it starts again... But the PPC part doesn't...

Even after taking off the 604e@233 et soldered a @375 version, the whole PPC part still doesn't give any sign of life... Sniff

Well, I had also another CyberStormPPC from DCE which was sleeping in my cartons : I had discovered on it two wormy holes under one of the two Mach231SP ! Unbelievable but true, however there isn't any capacitor around... If somebody understand what happened here, hats off :

Even after a full cleaning, this DCE is out of service...

There is still an interesting thing on this broken card, it's the eeprom which contains the firmware. Indeed, the CyberstormPPC from DCE have a soldered AM29F040B which can hold 512 Ko. All of the MK3 and PPC from Phase5 are equiped with AM29F010B (only 126 Ko). So it is why, contrary to the BlizzardPPC, the ppc.library and the 68060.library aren't in the firmware : there is no more space...

 Here is the exact reference of this famous DCE eeprom freshly unsoldered...

I had already realised this hack on the MK3, it is back again with another method, a lot more safer and serene :

The very simple idea in front of this tiny pastilles (which are about 0.170 millimeters large) is to unsolder and solder only with hotair, without any physical contact.

Once the old AM29F010B removed, suffice to well positioned the new one, brush a little bit the eeprom pins with RMA223 paste, letting on the pastilles the old soldering as it :

Then heat at 310° celsius during some minutes and then the welds will be done by themself !

An apparently successful operation : no contact with the card, everything has been realised with hot air. Thereby there is no risk to damage the very fragile pastilles

Thus now, with 512 Ko, it become possible to put more programs than before...

(translated by Squaley)

    

CSPPC firmware (I) [fr]

Ouf, après bien des difficultés en tout genre, voici enfin un nouvel article...

La Phase5 CyberStormPPC de Thierry ne fonctionnait plus du tout... Après le traditionnel changement de support du 060, elle redémarre enfin... Mais la partie PPC ne veut rien savoir...

Même après avoir ôté le 604e@233 et soudé une version @375, toute la partie PPC ne donne toujours plus aucun signe de vie... Sniff !

Bref, j'avais aussi une autre CyberStormPPC de DCE qui dormait dans mes cartons : j'avais découvert sur celle-ci deux trous tout vermoulus sous un des deux Mach231SP ! Incroyable mais vrai, il n'y a pourtant aucun condensateur aux alentours... Si quelqu'un comprends ce qui est arrivé ici, alors là chapeau :

Même après avoir tout bien cleané, cette DCE est hors service...

Il y a tout de même encore un truc intéressant sur cette carte HS, c'est l'eeprom qui contient le firmware. En effet, les CyberStormPPC de DCE ont une AM29F040B soudée, qui peut contenir 512 Ko. Toutes les autres MK3 et PPC de Phase5 sont équipées de AM29F010B (128 Ko seulement). Voilà pourquoi contrairement à la BlizzardPPC, la ppc.library et la 68060.library ne sont pas dans le firmware : y'avait plus de place...

Voici la référence exacte de cette fameuse eeprom DCE fraîchement dessoudée...

J'avais déjà réalisée cette bidouille sur la MK3, la revoilà donc avec une autre méthode, bien plus sûre et sereine :

L'idée toute simple face aux minuscules pastilles (qui font environ 0.170 millimètres de large) est de dessouder et ressouder uniquement au hotair, sans plus aucun contact physique.

Une fois la vieille AM29F010B ôtée, il suffit déjà de très bien positionner la nouvelle en badigeonnant un peu les pinoches de l'eeprom avec un peu de pâte RMA223 tout en laissant sur les pastilles l'ancienne soudure telle quelle :

Ensuite chauffer à 310° pendant quelques minutes et les soudures se font toutes seules !

Opération visiblement réussie : aucun contact avec la carte, tout a été réalisé avec de l'air chaud. Zéro risque d'endommager les très fragiles pastilles ainsi.

Voilà, avec 512 Ko maintenant, il devient possible d'y mettre beaucoup plus de programmes qu'auparavant...