Re: GUERRE ST-AMIGA, FIGHT ! (Mauvaise foi assurée)

[rocky007]

L'histoire de ce topic

rocky dit n'importe quoi
Steph le corrige
rocky le traite de pas drôle sans humour
Monsieur Atari arrive en répétant les mots de rocky dans le désordre

et on boucle

moi j'ai un autre version :

copper et dlfrsilver racontent n'importe quoi
rocky les corrige
stapha débarque après avoir réfléchit 6 mois sur comment répondre à un de mes messages, toujours aigri
epc35 ne servant à rien, fait un peu de vent en applaudissant des deux mains, ne comprenant de toute façon strictement rien à ce qui se dit ici
Monsieur Atari recouvre tout cela de chaux vive pour laisser la place propre et mets un peu d'humour car apparemment tous les amigols se prennent au sérieux dans un topic troll.

[Copper]

Ta Ta Ta.

Ce qui manque ( OCS/ECS ) ne devrait avoir aucune incidence sur le résultat de ton code.  La toute prochaine version 5 le confirmera probablement.

Qui plus est, en AGA c'est déjà en place.

Cela ne change rien au résultat visuel. Sur une config " Bâtarde " 68000 + AGA.

Peut-être mais ça ne veut pas dire que tout fonctionne correctement non plus... Et un changement de couleur qui prend 10 au lieu de 8 ça me semble étrange (surtout sans bitplanes)

Moi ça me parait normal : tu décales ton bitplan de 15 pixel vers la droite. Donc tes MOV ne peuvent plus être alignés. Et comme tu t'arretes au 40eme, le dernier changement dure jusqu'à la fin de l'affichage.
Supprime le scroll horizontal et repositionne ton WAIT et ça devrait aller. Et ça recentrera ton affichage ;-)

C'est quand je met le scrolling à 15 pixels que c'est aligné avec la bitplane de plus après le 40ème j'ajoute bien un $180 à $000 et c'est celui d'avant qui est à 10 pixels mais seulement si je commence à $3F si je met $3D plus de rectangle à 10 pixels (normal)

Et j'ai bien le problème sans bitplane d'ailleurs...

Pour le reste c'est plus le SKIP sur la ligne 255 qui m'embête...

[stapha92]

C'est quand je met le scrolling à 15 pixels que c'est aligné avec la bitplane de plus après le 40ème j'ajoute bien un $180 à $000 et c'est celui d'avant qui est à 10 pixels mais seulement si je commence à $3F si je met $3D plus de rectangle à 10 pixels (normal)

Et j'ai bien le problème sans bitplane d'ailleurs...

Pour le reste c'est plus le SKIP sur la ligne 255 qui m'embête...

Le seul skip que je vois c'est :
move.l #$3401FF01,(a6)+

Mais ce n'est pas la ligne 255 (le FF est le masque pour comparer tous les Y et attendre le blitter). J'ai du le rater (pas facile de le reconnaitre...). Tu peux le donner ?.

[Copper]

En fait c'est dans une version améliorée avec une double boucle que j'en obtiens un qui semble ne jamais SKIP

[Gilles_fx]

T'as pas des mp à répondre ou des colis à envoyer Gillou au lieu de venir perdre ton précieux temps ici?

N'hésites pas à sortir ta même blague pourrie dans 8 ans, histoire de faire le malin.
Tu me diras avec un pseudo comme le tien qui correspond à 8 ans de retard hors taxes sur le prototype de l'Amiga 1000 il serait difficile de faire mieux 

[Copper]

Le seul skip que je vois c'est :
move.l #$3401FF01,(a6)+

Mais ce n'est pas la ligne 255 (le FF est le masque pour comparer tous les Y et attendre le blitter). J'ai du le rater (pas facile de le reconnaitre...). Tu peux le donner ?.

J'ai refait un test plus simple et visiblement le SKIP $FF0DFFFF ne semble pas fonctionner alors qu'il est testé en vpos $FF et hpos $90 (environ)

Peut-être est-ce du à la façon dont est fait la comparaison (même si c'est indiqué Skip if vpos >= 0xff and hpos >= 0x0c dans le debugger de WinUAE et qu'il devrait donc SKIP)

[Jacques Atari]

N'hésites pas à sortir ta même blague pourrie dans 8 ans, histoire de faire le malin.
Tu me diras avec un pseudo comme le tien qui correspond à 8 ans de retard hors taxes sur le prototype de l'Amiga 1000 il serait difficile de faire mieux 

"Il suffit de 15 jours et quelques centièmes de secondes pour que Gillou réponde aux MP ou envoie ses colis, mais revoyons la même scène au ralenti..."

[stapha92]

Le seul skip que je vois c'est :
move.l #$3401FF01,(a6)+

Mais ce n'est pas la ligne 255 (le FF est le masque pour comparer tous les Y et attendre le blitter). J'ai du le rater (pas facile de le reconnaitre...). Tu peux le donner ?.

J'ai refait un test plus simple et visiblement le SKIP $FF0DFFFF ne semble pas fonctionner alors qu'il est testé en vpos $FF et hpos $90 (environ)

Peut-être est-ce du à la façon dont est fait la comparaison (même si c'est indiqué Skip if vpos >= 0xff and hpos >= 0x0c dans le debugger de WinUAE et qu'il devrait donc SKIP)

Ton SKIP attend également la fin du blitter. Si ce dernier tourne, le skip ne sautera donc pas l'instruction suivante. Pour s'en protéger, il faut mettre SKIP $7F0DFFFF (bit de gauche à 0).
Autre point : l'instruction qui suit un skip doit être un MOV. Je ne sais pas ce que cela donne si tu fais autre chose.

[Copper]

En fait c'est le contraire il faut mettre le bit BFD à 1 pour ne pas attendre le Blitter... J'ai tendance à le mettre à 0 quand je ne veut pas tenir compte de la position verticale mais là c'est bon... Dans tous les cas ça ne change rien ici car je n'utilise pas le Blitter dans ce simple test...

Pour le reste le SKIP est bien suivi d'un MOV COPJMP 0 pour boucler et malheureusement il semble faire une boucle infinie car le SKIP ne SKIP pas sur cette maudite ligne 255... Après c'est sur que si le test est vpos + 1 > 0xff ca serait normal...

[stapha92]

Mon souvenir était mauvais : je pensais que le BFD devait être à 0...
Il y a autre chose : en pal tu as plus de 256 lignes. Donc le compteur revient à 0... Il faut ruser un peu car c'est prévu pour du ntsc à la base...

[Copper]

Oui tout à fait c'est pour ça qu'il faut insérer une instruction du genre $FFDF FFFE (ou équivalent) à un moment donné afin d'attendre la dernière position accessible avant le rebouclage... Mais là le problème ce situe juste avant je pense

[rocky007]

allez un petit jeu :

citez 7 différences entre ces deux photos :

Spoiler:

[tapomag]

Rocky qui essaie vaillament de reprendre le troll, mais se trompe de machine.

Le C128 ne m'a jamais intéressé, c'était typique de ces années là que de ressortir le même engin, avec plus de mémoire. Je me souviens du Dragon32 et du Dragon64, mais il y en a eu plein d'autres. Le ST 520 et 1040, au hasard.

[dav1974]

Oui faut pas confondre "bas de gamme" avec l'Amiga et "les bas fonds" avec le c128.

[rocky007]

je voulais simplement souligner que le design de l'Amiga 1000 n'est qu'un C128D avec un 3"1/2 à la place du 5"1/4, je trouve cela très triste pour une machine à 15000 FF.

[epc35]

"Late in 1985, Commodore released to the European market a new version of the C128 with a redesigned chassis resembling the Amiga 1000."


Donc, c'est le C128 qui a repris le design de l'amiga et pas le contraire.


Encore un troll failed.

[rhod-atari]

C'est un 128D au passage...

C128 - janvier 1985
Amiga 1000 - juillet 1985
C128D - Dec85/Jan 86

[rocky007]

"Late in 1985, Commodore released to the European market a new version of the C128 with a redesigned chassis resembling the Amiga 1000."


Donc, c'est le C128 qui a repris le design de l'amiga et pas le contraire.


Encore un troll failed.

intervention très maladroite et malheureuse puisque je n'ai jamais prétendu le contraire.

je soulignais simplement le malaise pour un revendeur de proposer une machine "pro" à 15000 FF qui est identique à un C128D.

c'est comme si Atari sortait son Atari 7800 dans un caisse d'Atari TT.

[drfloyd]

Le membre 'rocky007' a effectué l'action suivante : Lancer de dés !

---

'CONCOURS 10 DES' : 4

[epc35]

intervention très maladroite et malheureuse puisque je n'ai jamais prétendu le contraire.

je soulignais simplement le malaise pour un revendeur de proposer une machine "pro" à 15000 FF qui est identique à un C128D.

c'est comme si Atari sortait son Atari 7800 dans un caisse d'Atari TT.

Mais non, te caches pas, tu voulais rabaisser l'amiga 1000, point.

le C128D est sorti en Europe avec une coque similaire a l'Amiga 1000 pour faire plus sérieux, c'est tout. Quand au prix, tu suggères que le prix de la machine est directement lié au prix de la carrosserie, belle vision. Mais tu as raison, c'est peut être le cas sur ST.

[rocky007]

moi rabaisser l'A1000 ?  il le fait très bien tout seul, il n'a pas besoin de moi pour ça

tu suggères que le prix de la machine est directement lié au prix de la carrosserie

je sais pas, tu sais combien coûte la coque de l'amiga 1000 ?
t'es bien informé en tous cas

[Copper]

De toute façon c'est presque hors sujet l'Amiga 1000 la guerre ne concerne que le 520 STF vs l'Amiga 500 (et il n'y a pas de match l'Atari 520 STF est une machine tout pourrie alors que l'Amiga 500 est une machine géniale)

Même si l'on peut regretter certaines difficulté pour exploiter l'instruction SKIP sur la ligne 255 (même si j'ai réussi en commençant mes changement en $35 au lieu de $3F pour pas que le compteur ait déjà rebouclé au moment de la dernière instruction SKIP)

[rocky007]

Si, au contraire c'est pertinent de savoir que Commodore positionnait le C64 au même niveau qu'un A1000.

Retraçons l'historique :

Amiga promet une révolution à Commodore avec un A1000
Il sort en 85 et quelques mois plus tard en constatant le mensogne éhonté d'Amiga et le désastre la machine, ils re-cabosse en urgence un C64 sous la forme d'un Amiga 1000 pour éviter la faillite et présenter un véritable ordinateur "pro" dans la gamme Commodore.

Malheureusement, le ST ravage déjà tout sur son passage, le A1000 est enterré, C128D ne décolle pas face à Atari ST, donc quelle solution restait-il à Commodore?.  Copier le ST, et sortir en urgence l'Amiga 500.

Il aura fallu que Commodore soit sous perfusion des ingénieurs, logiciels et du marketing Atari pour reculer de qq années sa faillite et de permette au A500 de briller à partir de 1993.



c'est un sacré aveux d'échec

[Copper]

Le ST n'a rien ravagé du tout sauf le cerveau de certains de ses utilisateurs visiblement (qui sont complètement à coté de la plaque)

Quand au C128 c'était clairement du grand n'importe quoi tout comme la palette fixe toute moche du C64 qui elle pour le coup aurait du être modifiée en urgence et remplacée par une palette variable d'au moins 4096 couleurs

[Jacques Atari]

Sois un peu plus modeste Coppy. Sans le ST, ton Amiga n'aurait jamais existé. Et tu aurais fait semblant de coder comment en 1989?

[Copper]

Non c'est le contraire sans l'Amiga le ST n'aurait pas existé en fait... La seule bonne raison de détester l'Amiga finalement...

[rocky007]

Quand au C128 c'était clairement du grand n'importe quoi tout comme la palette fixe toute moche du C64 qui elle pour le coup aurait du être modifiée en urgence et remplacée par une palette variable d'au moins 4096 couleurs

le C64 a été vendu à 20.000.000 avec une palette fixe... les amigols pensent toujours que plus c'est mieux... ça sert à rien d'avoir 4096 couleurs si la machine plante une fois sur deux en tentant de les afficher...

[Copper]

Sauf que ne plante pas autant que tu aimerais le faire croire alors que les couleurs du C64 sont vraiment horribles (et c'est dommage)

[tapomag]

Les conditions de plantage d'un Amiga et d'un ST étaient les mêmes, aucun des deux n'avait la protection mémoire dans le CPU. En soft, c'est impossible d'implémenter ça efficacement, puisque ça repose sur l'utilisation de l'allocateur de l'OS, qui n'est jamais utilisé par les gorets. Le débat peut à la rigueur porter sur la répartition des gorets par plateforme.

[rocky007]

même ChatGPT le sait... et pas vous, preuve encore de votre ignorance crasse...

[tapomag]

Penses-tu, il ne se mouille pas le gros.