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...
  

040/060 adapter [eng]

Well, I already talked about a possible 68040 version of some Warp3D libraries, but now it's clear that there will be no...

For those who were following my old and still closed blog, I finally found what was messing on my 040 => 060 adapter : It works now ! I've made two nice howlers, not proud  of this one Cosmos... Bouh...

Meanwhile, a friend of Mozart the original author, Matze has made available a new version with some changes and improvements like some thicker tracks (available here). So I ordered new PCBs which already arrived some time ago :

  
A small reminder of only 040 cards this adapter will allow to change :

• The A3640 from Commodore,
• The WarpEngine from MacroSystem US,
• The G-Force 040 Combo from GVP,
• The Apollo 1240 with Mach130 from ACT,
• The 040-500 from Progressive Peripherals and Software,
• The Fusion Forty from RCS Management.

    
Matze reversed the position of the small extension for the controller and a few components :

On the other side I have now other problems with my A4000T : my 68040 WarpEngine doesn't start with it... With this adapter and a 060, sometimes it boot, but not every time... Some people think this could be a conflict between IDE/SCSI...

I also burned my A4000D which doesn't want to hear anything : by testing my CyberStormPPC from DCE, the one with corroded holes which I was talking in a previous article... Even with the Logica diagnosis roms there is nothing on screen... this is not a goog sign... What a bad luck...

You have a cheap A4000D card to sell ? Thank you to contact me !

If you have an A3640 into an A3000D, it's fully possible to add a small fan like this without any desktop case modification :

SpeedGeek said to me : the 68060.library v46.7 (17/04/18) from Phase5 is fully working !

(translated by Squaley)

      

Adaptateur 040/060 [fr]

Alors, j'avais déjà évoqué une possible version 68040 de certaines librairies Warp3D, mais clair maintenant qu'il n'y en aura aucune...

J'ai finalement trouvé ce qui déconnait sur mon adaptateur 040 => 060 pour ceux qui suivait mon ancien blog toujours fermé : il marche désormais ! J'avais fait deux belles bourdes, pas fier le Cosmos là... Bouh...

Entre temps, un copain de Mozart l'auteur original, un certain Matze a rendu disponible une nouvelle version avec quelques changements et amélioration comme certaines pistes plus épaisses entre autre (disponible ici). J'ai donc commandé de nouvelles PCB qui sont bien arrivées il y a quelques temps déjà :

Petit rappel des cartes uniquement 040 que cet adaptateur va permettre de faire évoluer :

• la A3640 de Commodore,
• la WarpEngine de MacroSystem US,
• la G-Force 040 Combo de GVP,
• l'Apollo 1240 avec Mach130 de ACT,
• la 040-500 de Progressive Peripherals and Software,
• la Fusion Forty de RCS Management.

 
Matze a inversé la position de la petite extension servant au régulateur et à quelques composants :

J'ai par contre d'autres problèmes maintenant avec mon A4000T : ma WarpEngine en 68040 ne démarre pas dessus... Avec cet adaptateur et un 060, elle boot parfois, mais pas à tous les coups... Certaines personnes pensent que ça viendrait d'un conflit IDE/Scsi...

J'ai de plus grillé mon A4000D qui ne veut plus rien savoir : en testant ma CyberStormPPC de DCE avec les trous vermoulus dont je parlais dans un précédent article... Même avec les roms de diagnostic Logica, il n'y a plus rien à l'écran du tout... Pas bon signe ça... Quelle poisse alors...

Vous avez une carte A4000D pas trop chère à la vente ? Merci de me contacter !

Si vous avez une A3640 sur un A3000D, il est toujours possible de fixer un petit ventilo de cette façon sans avoir à découper quoique ce soit :

Pour finir, SpeedGeek me signale que la 68060.library v46.7 (17/04/18) de Phase5 marche très bien !
   

My New Blog

My new blog :
 

Become A Crack In Assembly 68k

    

P96 monitor settings [eng]

By getting back my Prometheus, the different screens with default parameters were not very clear, this is the less we can say :

It was needed that the good values be in the Picasso96Mode program.

For this, an amigaist John Mansfield had written a explanatory .pdf "Quick P96 new res guide" available now in the Dowloads section.

Everything is explained step by step, and the result is far better with the good parameters :

Well done John !

(translated by Squaley)

     

P96 réglages moniteur [fr]

En resortant mon Prometheus, les différents écrans avec les paramètres par défauts n'étaient pas très nets, c'est le moins que l'on puisse dire :

Il faut en effet entrer les bonnes valeurs dans le programme Picasso96Mode.

Pour cela, un amigaïste John Mansfield avait rédigé un .pdf explicatif "Quick P96 new res guide" disponible maintenant dans la section Downloads.

Tout est expliqué pas à pas, et le résultat est en effet bien meilleur avec les bons paramètres :

Bravo John !
 

A bug again [eng]

Again a strong bug which I had found since a long time before...

It is located in the calculation time of the trigonometric functions emulated by the 68060.library !

And the Warp3D programs use it massively. Indeed, with my little TrigoSpeedTest program, the results are alarming because they are very slow :

I get these snails with a Blizzard 1260 and also with a Apollo 1260 under Kickstart 3.1 and 3.9. And yes, I also tested older versions of the 68060.library...

For cons, the results are correct with a MK2 060 and a MK3 060 under a 4000D :

So, software or hardware bug ? Good question... I included in my Kickstart 3.9 the little IntAckFix patch (on Aminet) which I discovered some days ago, but still the same results for this problem of the day !

Yet, amusing fact : this bug disappeared when the Kickstart is mapped in fastram. With Blitzkick or remapollo, I get the waited results !

Nevertheless this annoying bug should be fixed... Do you have a idea from where it comes ? Go to my email of course...

(translated by Squaley)

     

Encore un bug [fr]

Encore un bug costaud que j'avais débusqué depuis longtemps déjà...

Il se trouve dans le temps de calcul des fonctions trigonométriques émulées par la 68060.library ! Et les programmes Warp3D les utilisent abondamment. En effet, avec mon petit programme trigoSpeedTest, les résultats sont alarmants car très lents :

J'obtiens ces escargots avec une Blizzard 1260 et aussi avec une Apollo 1260 sous Kickstart 3.1 comme 3.9. Et oui, j'ai aussi testé avec des versions plus anciennes des 68060.library...

Par contre, les résultats sont corrects avec une MK2 060 et une MK3 060 sous un 4000D :

Alors bug software ou hardware ? Bonne question... J'ai inclus dans mon Kickstart 3.9 le petit patch IntAckFix (sur Aminet) que j'ai découvert il y a quelques jours, mais mêmes résultats pour ce qui nous concerne aujourd'hui !

Alors, fait amusant : ce bug disparaît lorsque le Kickstart est mappé en fastram : avec Blizkick ou RemApollo, j'obtiens alors les résultats attendus !

N'empêche qu'il faudrait fixé tout de même ce bug quelque peu gênant... Vous avez une idée d'où il peut venir ? Goto mon email bien sûr...
  

MK1 040 in 060 [eng]

The CyberStorm MK1 require a different CPU module depending on the 040 or 060 installed on it... At last required !

I was thinking about making a special 68040 version of the W3D_AvengerLE.library without the fintrz emulation of the 040 (see the past article) but with this new hack, I hesitate... Maybe the users should upgrade their cards with 68060 which would bring a better confort...

Indeed, Musicman, has found the required modifications for the 040 modules to accept 060 ones !

First of all, weld the regulator, put the JMP on 3.3v, also the three diodes near the CPU support and install the 27C256 eprom like this :

Then, cut the trace here :

And scratch the PCB surface which gets to the hole :

Then, use a cable to link the hole with the second component from above :

To end, it's needed to lift the second pin of this 74F257A and connect it with the last one of his row :

Et voilà, it works very nicely : however the card refused to overclock at 60 Mhz or more but work perfectly at 50 Mhz.

 

(translated by Squaley)

     

MK1 040 en 060 [fr]

Les CyberStorm MK1 nécessitent un module CPU différent selon le 040 ou 060 installé dessus... Enfin nécessitaient !

Je pensais faire une version spéciale 68040 de la W3D_AvengerLE.library sans le fintrz émulé par les 040 (voir l'article d'il y a quelque temps) mais avec ce nouvel hack, j'hésite... Autant pour les utilisateurs d'upgrader leurs cartes en 68060 qui apportent un meilleur confort d'utilisation général...

Musicman a en effet trouvé les modifications requises pour que les modules 040 acceptent un 060 !
 

Il faut déjà souder le régulateur, positionner le JMP sur 3.3v, ainsi que les trois diodes près du support CPU et installer l'eprom 27C256 comme ceci :

Ensuite, il faut couper une piste ici :   
Et gratter le vernis de la piste menant au trou :

Ensuite, relier un câble du trou au deuxième composant du dessus :

Pour finir, il est nécessaire de soulever la seconde pinoche de ce 74F257A et la raccorder à sa dernière sur la même rangée :

Voilà, ça marche impec : petit bémol toutefois, la carte refusait l'overclocking 60 Mhz ou plus, mais fonctionne très bien à 50 Mhz.

 

New bug ! [eng]

A new bug found in GLBlitzQuake, with the original Warp3D v4.2 libraries and a 3dfx graphic card, in the same room and side by side :

White stripes appear... With the AGA version of Frank Wille and PXLComputer, no bug...

Right next :

Points appear here, then there should be an opening...

With the Permedia2 drivers, the opening is there :

On the other side, the other white stripes bug is there too...

It's seems that this or these bug(s) are in W3D_AvengerLEMU.library and W3D_Permedia2.library than in GLBLitzQuake itself...

 

(translated by Squaley)

     

Nouveau bug ! [fr]

Un nouveau bug trouvé dans GLBlitQuake, à deux endroits avec les libraries originales Warp3D v4.2 dans la même salle côté à côté avec une carte vidéo 3dfx :

Des barres blanches apparaissent... Avec les versions AGA de Frank Wille et de PXLComputer, aucun bug...

Juste à côté :

Des points apparaissent ici, alors qu'il devrait y avoir une ouverture...

Avec les drivers Permedia2, l'ouverture est bien présente :

Par contre, l'autre bug des barres blanches est bien là aussi...

Il semblerait que ce ou ces bug(s) soit dans les W3D_AvengerLEMU.library et W3D_Permedia2.library plutôt que dans GLBLitzQuake lui-même...