stabylo :
Dans la norme SCSI, les périphériques (même les plus récents) sont faits pour accepter d'être pilotés par ces commandes SCSI 1. Donc tous fonctionnent. Il reste cependant que si les accès CD-ROM en lecture sont normalisés dans le SCSI, les commande de gravure ne le sont pas, et elles dépendent donc toutes de l'imagination fertile des fabricants, qu'il mettent plutôt largement en exergue quand ils inventent leur propres jeux de commandes de gravure.
Pas vraiment vrai. Les normes SCSI ont évoluées, comme les normes ATA. Pour l'ATA, y'a eu l'ATA-1, puis l'ATA-2, etc, on doit être à ATA-8, avec prise en compte à chaque fois de nouvelles dispositions pour repousser les limites des périphériques (l'adoption du LBA en fait partit).
Pareil pour le SCSI (dont l'ATA dérive), y'a des commandes supplémentaires qui sont apparues au fil du temps, dont celles qui correspondent à la gravure de CD, puis de DVD, qui sont regroupées sous la dénomination de MMC-3 (Multi Media Command 3) ou aussi connues sous RMC (pas la radio, Recording Media Command).
Par contre, les technologies BurnProof (tm), JustLink (tm) ou toutes autres conneries du genre sont bel et bien une 'invention' de chaque fabriquant. En fait, c'est 'juste' l'adaptation du buffer d'écriture qui est en standart en SCSI (commandé par le jeu d'instruction SCSI) à l'ATA qu'il faut 'émuler' avec le CPU et quelques interruptions à gèrer pour remplir le buffer.
Parce que l'ATA, c'est JUSTE du SCSI, mais simplement pas autonome (sans microcontrolleur et gestion automatique des connexions/déconnexions du bus). En ATA, c'est pas cher parce que c'est le CPU qui fait tout et est toujours maitre du bus (il gagne d'office l'arbitration). En SCSI, y'a plus de logique qui fait qu'on peut faire 'grosso-modo' dialoguer le scanner directement avec le disque-dur (en mode RAW) et qu'on peut les laisser se débrouiller tout seuls comme des grands sans plus d'intervention (ils se déconnectent d'eux même du bus à la fin de la transaction, voire même l'interrompre momentanément en cours et la reprendre ensuite, comme le blitter en mode 'shared bus')...
Mais en dehors des disques dur, les commandes 'packet' du SCSI sont les mêmes que pour l'ATA, dont le jeu de commande MMC-3 aka RMC.
Kochise
PS : Pour rappel, pour ceux qui comme moi écrivent leurs propres drivers...
T10.ORG (SCSI) :
http://www.t10.org/ -> Cliquez sur 'Architecture' à gauche
T13.ORG (ATA) :
http://www.t13.org/ -> Cliquez sur 'Standards'
Dans les deux cas, une fois que vous aurez compris l'architechture et que vous aurez localisez la documentation dont vous avez besoin, allez les retrouver sur leurs sites FTP respectifs, elles y sont toutes !
)
HDdriver permet d'accéder aux données du disque, mais pour que l'Atari comprennent leur organisation (iso9660), MetaDOS est ton ami, du moins sous TOS (et sous MagiC aussi je crois). Mint a ses propres pilotes iso9660. MetaDOS a effectivement des clônes (BetaDOS et ExtenDOS), va voir sur WikiPendium pour plus d'info.
Donc si on a un soft sur Atari qui sait utiliser les commandes MMC-3, pratiquement tous les graveurs les plus récents seront acceptés, c'est ça?
Mais attention, pour en avoir commencer un, je peut vous assurez que c'est loin d'être particulièrement insurmontable, c'est 'juste' de la manipulation de données, gestion d'un protocole, et dialogue avec le périphérique. En conparaison, ça n'a rien de plus difficile qu'une pile TCP/IP et un dialogue à traver un modem. La constitution des trames TCP cède la place aux paquets ISO, et les commandes Hayes cèdent la place aux commandes MMC3. Franchement, rien de méchant, faut juste respecter quelques règles élémentaires et surtout avoir un bon timing (essentiellement sur Atari).
