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

[youki]

Oui, c'est vrai, avec l'Amiga  la boîte est bien plus utile que la machine .

[touko]

Peut être, mais tu imagines le choc pour le STiste qd il a jeté la boite et qu'il se rend compte qu'il a une machine à 15.000 balles à peine mieux qu'une TI-30 stats (sans les stats) ?

[youki]

C'est très bien une ti30 même sans les stats (d'ailleurs j'avais la version sans stats au collège).   Si le St est une ti30, l'Amiga est un boulier auquel il manquerait les boules...

[touko]

(d'ailleurs j'avais la version sans stats au collège).

Oui l'atari ST, ça on le savait déjà .

 l'Amiga est un boulier auquel il manquerait les boules...

On s'en fou, nous on en avait qu'une, mais au moins elle était grosse 

[Copper]

Finalement je me demande si je ne préférais pas le hors sujet sur la machine aux couleurs hideuses...

[touko]

Faut savoir !! vous arrêtez pas de râler en fait .

[touko]

ah non tu cherches très mal... mais c'est pas grave...répond à la question au lieu d'esquiver

Le problème c'est que si je réponds à ta question, je vais encore te foutre la honte, comme à chaque fois .
La leçon du S-SMP de la snes t'a donc pas suffit ?

[Alfaccc]

On s'en fou, nous on en avait qu'une, mais au moins elle était grosse 

Parle pour toi, j'ai peut être eu un Amiga mais je suis resté un entier, ça n'a pas fait de moi un semi hongre.

[rocky007]

ah non tu cherches très mal... mais c'est pas grave...répond à la question au lieu d'esquiver

Le problème c'est que si je réponds à ta question, je vais encore te foutre la honte, comme à chaque fois .
La leçon du S-SMP de la snes t'a donc pas suffit ?

Ah oui cette fameuse histoire où tu t’es encore chien dessus alors que je t’avais proposé d’en discuter ensemble avec de vrais experts et au lieu de cela tu m’as fait baniir du forum pour éviter le discussion . Oh oui je m’en souviens très bien….   Si tu veux on peut réouvrir cette discussion sur le forum snesdev , ce sera avec un grand plaisir

[touko]

Tiens, ça commence à se chier dessus, et on essaye de vite virer à autre chose pour faire oublier la déroute C64 ..

The C64 has a fixed resolution of 320x200, but it is able to display 16 colors on screen at the same time, in every mode.
The VIC-II has several modes, and all modes use a single "bit plane" (to use the terminology of bit planes.) 

Ca percute maintenant ? 1 seule rés. 1 seule profondeur de couleurs pour tous les modes, donc accès identiques .
Voilà c'est pas sorcier et tu comprends maintenant que malgré tes recherches, t'as rien trouvé pour contredire mes affirmations sur les cycles/frame .

T'as jamais sorti le moindre chiffrage, ni explication sur ton fameux mode bitmap, qui de plus n'a rien de bitmap puisque c'est un simple mode tile comme tous les modes du C64 .

C'est d'autant plus gênant pour toi que c'est n'est pas le 6502 qui fait l'affichage, mais le VIC II.  Même ça tu ne comprends pas  
et pas besoin d'être chien truffier puisque je t'ai expliqué précisément comment ça fonctionne, chiffres à l'appui.

Ca c'est l'apothéose du mec qui connait rien, là t'as fait fort,t'as même trouvé l'occasion de sortir une énième ânerie, où ais je parlé du 6502 pour l'affichage ? pourtant je t'ai plusieurs fois expliqué les 2 phases, même dans le lien sur le wiki C64 c'était expliqué .Vu que tu connais pas le 6502, c'est un CPU en 2 phases, et il accéde à la RAM juste avec 1 seule phase, soit 1/2 cycle(et oui le 6502 a besoin d'une RAM à x2 de la vitesse du CPU), et à ton avis qui utilise le second 1/2 cycles dispo pour son affichage ? bah le VIC .
Il ne vole aucun cycle au CPU pour afficher les données, sauf sur les badlines pour le fetch des couleurs, soit toutes les 8 scanlines .
Voilà, maintenant tu sais pk tu posais comme toujours tout un tas de questions ultras connes et sans intérêt .

Et t'as expliqué précisément ? 
Tellement précisément que t'as jamais pondu le moindre calcul pour nous expliquer d'où tu sortais qu'il restait la moitié des cycles au CPU.
J'imagine du même endroit que qd tu m'expliquais que le S-SMP était tanto un wave table synthétiser, tanto faisait du sample based synthétisis, c'était en fonction du temps, du vent ou que sais je . 

Je me doute que tu savais que j'avais raison, sinon comme à ton habitude, tu aurais sorti plein de lien vers des tocards sur des fofo, disant ce qui t'arrange, mais en fait tout te démontrait que comme d'hab, comme avec le S-SMP, tu sais pas de quoi tu parles, tu mélanges tout, et surtout t'as strictement aucune connaissances, même basique .

T'es juste bon à cacher tes énormes lacunes derrière tes insultes et tes smileys débiles .

Par contre là où tu m'a vraiment scotché, c'est sur la seule analyse valable que tu ais faite, courte, concise et bien argumentée :

tu sais bien moi je suis bête

Respect !! 


Sur ce bonne nuit la courgette . 

P.S: Tiens pour ton éducation, tu y trouveras tout ce qu'il faut pour que tu sois moins tarte la prochaine fois que tu parleras du C64  : 
https://www.c64os.com/post/flitiming1

[Copper]

Et sinon concernant la question du ralentissement du 68000 de l'Amiga en HR vous en êtes où ?

[youki]

T'as jamais sorti le moindre chiffrage, ni explication sur ton fameux mode bitmap, qui de plus n'a rien de bitmap puisque c'est un simple mode tile comme tous les modes du C64 .

Oui, mais  quand tu veux changer l'affichage complet d'une page texte ou d'un écran bitmap...  tu ne transfers pas du tout le meme quantité de donnée.   2000 bytes dans le cas d'un mode texte  ,    et 9000 bytes pour un bitmap en hires.

[Copper]

Finalement je me demande si je ne préférerais pas parler calculatrices graphiques avec ou sans stats...

[rocky007]

bravo Touko, je vois que tu as bien travaillé cette nuit   c'est bien 48h après ma question, tu viens enfin de trouver la réponse.  c'est une preuve supplémentaire qu'il y a 48h avant, tu n'y connaissais rien, passant tes journées et tes nuits sur Wiki ( tu sais,  cette action ce que tu critiquais  )

 

The C64 has a fixed resolution of 320x200
The VIC-II has several modes, and all modes use a single "bit plane" (to use the terminology of bit planes.)

rohlolalala quelle découverte   pourtant le calcul est simple à faire, même en mode texte, une font fait 8x8... 8x40 ça fait combien ?  320..et 8x25 ça fait combien ? 200...   ben oui, même en mode texte, l'affichage est en 320x200
mais là où on comprend que tu n'as pas lu encore assez, quand tu es en mode texte, le VIC il fait quoi ?  il lit sa ligne de 40 code caractères et va en ROM chercher la définition graphique de chaque code ( ou en RAM si le pointeur a été changé pour redéfinir les charactères ).

en mode bitmap, il n'utilise pas de code caractère pour retrouver ses pixels puisqu'il sont en série.

c'est pourquoi ta dernière réponse est complètement à côté de la plaque quand tu répondais cela :

Comme tu aimes les indices, je vais juste te donner une info, et ensuite je m'occupe plus de ton cas totalement désespéré :

The VIC scans out the video frame line-by-line. Each line takes exactly 63 clock cycles. On normal lines, all these 63 cycles are available to the CPU. However, on every 8th pixel row (=start of a new character row), the VIC needs an extra 40 cycles to fetch a line of character codes from memory. When these fetches start, the CPU is “stunned”, meaning it won’t execute for about 40-43 clock cycles. These lines are called Bad Lines. On these lines, you have only 20-23 clock cycles to spend on your raster magic.

Les 40 cycles utilisés sur la bad line ne sont plus du tout utilisée pour transférer un code character mais les couleurs.
retient bien ceci, car c'est important pour la suite

Pour l'affichage, c'est bien le VIC qui va charger ses données et les afficher, le CPU n'a strictement rien avoir là dedans.
Et en effet, il y a bien 2 phases, puisqu'un clock a un high et un low. Donc le contenu de la définition de char / bitmap se fait de façon transparente lors de la clock low.  C'est bien , après 50 fois t'avoir posé la question,  et des journées complètes sur wiki, tu as enfin répondu.

Je me doute que tu savais que j'avais raison, sinon comme à ton habitude, tu aurais sorti plein de lien vers des tocards sur des fofo, disant ce qui t'arrange

Je t'ai tendu bcp de perches qui ont bien prouvé que tu n'y connaissais rien, sinon tu aurais répondu bien plus vite.

Par contre ce que tu oublies, c'est qu'on peut avoir des bad lines sur chaque rasterline selon le nombre de couleur qu'on veut obtenir.
Et c'est là que tu peux sortir ta calculette : si on prend le maximum soit 200x 40 cycles volé au CPU, ça te fait combien ? 8000 cycles...19xxx - 8000 ça fait ? comme je le disais : un peu plus de la moitié de cycle dispo pour le CPU.

Donc résumons, il y a 4 jours, tu ne connaissais pas le VIC, tu ne savais pas qu'il prenais des cycles pour l'affichage texte/bitmap, tu ne savais pas qu'il prenait des cycles pour les sprites, ni pour les couleurs dans les bitmap 

il reste toujours à éclaircir :  comment fais-tu du multiplexing quand tu ne peux pas changer Y pendant l'affichage, l'extension de Vblank tout en gardant la même fenêtre écran, et le sprite rendering en hblank


Pour le S-SMP, tu as fermé la porte en me faisant bannir.  Là au moins tu aurais eu de vrai spécialiste qui t'aurais remis à ta place, mais clairement tu as eu peur et a totalement nié l'affaire.  Évidement sur un forum expert, tu n'as aucun soutien.

Je te propose donc, pour trancher ce sujet, d'ouvrir un nouveau sujet sur snesdev et d'en discuter avec les pros.  es-tu d'accord ?.

[Copper]

Je préférais que vous parliez de l'Amiga voir même de l'Atari ST (même si l'Atari ST c'est tout pourri)

[tapomag]

J'ai demandé à chatGPT pour la bande passante de l'Amiga et du ST, il m'a dit que l'Amiga se faisait bouffer le bus par ses copros et que le ST se faisait bouffer le bus parce qu'il n'avait pas de copro.

Il a quand même conclu que pour du graphisme et du son, l'Amiga était mieux équipé.
Brave petit. (tap tap!)

[youki]

Je préférais que vous parliez de l'Amiga voir même de l'Atari ST (même si  l'Atari ST c'est tout pourri)

Le pb , c'est qu'il n'y a plus rien à dire sur l'Amiga.   Tout a déjà été dit .  Console de jeu très correct pour 1985  mais complement nul pour un usage Micro.

Le St on pourrait encore en dire beaucoup , tellement la machine est merveilleuse ,  mais ca ne sert à rien de s'acharner , ca rendrait encore plus riducule l'Amiga...   nous les Ataristes nous avons encore un peu d'humanité.   

Le St a gagné la guerre.   

Maintenant un nouveau Fight s'engage :  Touko vs Rocky  ...       Je parie sur Rocky, car il a eu un ST , il est forcement pus intelligent et surtout il ne lit pas en diagonale lui.

[youki]

J'ai demandé à chatGPT pour la bande passante de l'Amiga et du ST, il m'a dit que l'Amiga se faisait bouffer le bus par ses copros et que le ST se faisait bouffer le bus parce qu'il n'avait pas de copro.

Il a quand même conclu que pour du graphisme et du son, l'Amiga était mieux équipé.
Brave petit. (tap tap!)

  Moi il me dit ca GPT :

Dans certains cas, notamment pour des applications non graphiques , mathématiques ou bureautiques, l'Atari ST peut se montrer plus performant que l'Amiga en termes de bande passante, grâce à une architecture plus simple et directe. Bien que l'Amiga soit excellent pour les tâches dites multimédias avec ses coprocesseurs dédiés, ceux-ci peuvent parfois surcharger le bus mémoire, réduisant ainsi l'efficacité globale. À l'inverse, l'Atari ST, sans composants matériels supplémentaires, permet au CPU de gérer plus efficacement la mémoire, offrant une bande passante plus constante et une meilleure performance dans la plupart des situations.

[Copper]

Le ST a encore perdu une bataille il me semble... Et ce malgré le handicap de période infligé à l'Amiga... Et je ne parle pas de tes 2 défaites dans les deux euro micro

Pour le reste je ne pense pas que rocky soit compétent quand il affirme qu'un ym2149 produit des sinusoïdes analogiques parfaites...

[tapomag]

L'Atari ST était plus facile à programmer, et représentait une bonne machine d'initiation pas trop chère.

Je le vois comme le sucesseur spirituel du ZX-81, à la fois pour l'esprit et les performances.

[Sub0]

Un peu comme la rotissoire qui serait l'evolution du grille-pain.

[Copper]

L'Amiga était plus intéressant à étudier à l'époque et je pense que c'est encore le cas aujourd'hui...

[Jacques Atari]

Ce topic...

[youki]

Le ST a encore perdu une bataille il me semble... Et ce malgré le handicap de période infligé à l'Amiga... Et je ne parle pas de tes 2 défaites dans les deux euro micro

Pour le reste je ne pense pas que rocky soit compétent quand il affirme qu'un ym2149 produit des sinusoïdes analogiques parfaites...

il n'y pas plus parfait comme Sinusoide qu'une onde carré.

[Copper]

En fait c'est le contraire c'est la plus imparfaite

[touko]

T'as jamais sorti le moindre chiffrage, ni explication sur ton fameux mode bitmap, qui de plus n'a rien de bitmap puisque c'est un simple mode tile comme tous les modes du C64 .

Oui, mais  quand tu veux changer l'affichage complet d'une page texte ou d'un écran bitmap...  tu ne transfers pas du tout le meme quantité de donnée.   2000 bytes dans le cas d'un mode texte  ,    et 9000 bytes pour un bitmap en hires.

Ca marche pas comme ça, c'est un affichage par tile, le VIC va lire les données d'une tilemap dont il stocke 1 ligne de tiles en interne .
Ensuite pendant l'affichage, chaque accès sur le PHI2 du CPU il fetche 1 octet, soit 8 pixels de 2 couleurs(le fameux mode "bitmap"), soit 1 ligne d'une tile 8x8 .
Toutes les 8 lignes par contre vu qu'il remet à jour la ligne de tiles pour les prochaine 8 lignes, là il prend 40 cycles sur les 63 dispos .
La gestion des modes se fait en interne par le VIC lors de la génération du signal vidéo, mais les accès sont constants pour une évidence, la synchro .

Oui, mais  quand tu veux changer l'affichage complet d'une page texte ou d'un écran bitmap..

Maintenant si tu parles des patterns des tiles en RAM, cela n'a rien à voir avec le VIC, ce que je te donne plus haut ce sont les accès à la RAM du proc vidéo, donc cela suggère que les données des tiles soient déjà en RAM et les registre du VIC paramétrer pour aller les chercher, c'est évident, et si tu dois les modifier, tu prends forcément sur ton budget des 18.x00 cycles dispos pour ça, c'est au codeur de le faire.

Merci @rocky pour ton gros pavé où une fois de plus tu n'expliques rien, rien de chiffré, que dalle .. 
L'argument "sur ma vie bro", excuses moi mais ça marche pas . 
Par contre bravo pour le contenu en max bullshit, j'adore 

[Copper]

Les pattern de tiles elles sont stockées où ? Elles sont lues (par le VIC) à quel moment ?

[rocky007]

Ben lis mon post et tu auras ta réponse

[Copper]

Je ne préfère pas

Je me demandais juste s'il y'avait de la mémoire dédiée pour les pattern mais bon au vu de ce je lis j'imagine que non

[youki]

Je ne préfère pas

Je me demandais juste s'il y'avait de la mémoire dédiée pour les pattern mais bon au vu de ce je lis j'imagine que non

Non, c'est la ram normal.   ou dans la rom , tu choisis.   Par contre, c'est un peu plus dur de modifier les patterns quand tu utilise celle de la ROM 

Par contre, tu les place plus ou moins tu veux.

[touko]

Elles sont lues (par le VIC) à quel moment ?

Tout le temps pendant l'affichage en fait (soit 200 lignes max de base sur les 312 possibles), il réactualise les nouvelles tiles toutes les 8 lignes .
Chaque accès sur le 1/2 cycles laissé par le 6502, le VIC lit les patterns, et comme le dotclock (fréquence du VIC) est constant,et donc démontre qu'il n'y a pas de changement de réso. donc de fréquence, bah les accès sont toujours identiques, même avec un mode différent, d'ailleurs appelé mode et pas résolution .

Les pattern de tiles elles sont stockées où ? 

En RAM, il n'y a pas de VRAM dédiée .

Sur les lignes où le VIC n'affiche rien, donc ne fait aucun rendering, le CPU a 100% des cycles, il a aussi 100% des cycles sur les lignes classiques (donc hors badlines et hors lignes où sont présents des sprites) .

J'avais trouvé ça :

The PAL C64 has 312 scanlines giving 63*312 = 19656 cycles. If the display is activated (without sprites), the VIC will steal 40 cycles for each badline which gives us 63*312 - (25*40) = 18656 cycles. Add some sprites and the free cycles will decrease even more.

Les sprites ne prennent pas bcp ,c'est 3+(2*nb_sprites) cycles, donc on perd aussi 19 cycles de plus si les 8 sprites sont sur la ligne, on doit être à 18300 par là .