Nº185 (9/2005)
Download :
|
 
| Comme vous pourrez le constater, ce mag est bien plus un mag d'été qu'un mag de rentrée. En effet, il a été rédigé en août et ça se sent. Vous y trouverez aussi la suite des photos de la Visu du 4 juin (j'écris ‘suite', car il y aura encore une ‘fin' dans le prochain mag). Même s'il contient encore des scories assez anciennes, notamment dans le Courrier Oricien (le rédac-chef n'est pas toujours à la hauteur), ce mag témoigne que tous les Oriciens n'ont pas sombré dans les torpeurs de l'été. Et ceux qui sont restés à l'oeuvre n'ont pas chaumé et nous gratifient de bien belles réalisations. A vous de découvrir ces merveilles. Bien oricalement. André.
|
|
 Un Bug Sedoric découvert par Fabrice !
Micro 2065 ! Fabrice a encore sévit en construisant lui-même un Super-Microtan à 20 MHz ! (non ce n’est pas le 1er Avril)
Des Trucs pour Tricher : Gastronon !
L’adaptation Sedoric de FG-SUP !
|
|
|
 |
|
 |
sommaire
|
| Adresses CEO / Sommaire / Editorial |
|
Page |
| Atelier : Micro 2065 |
|
Page |
| Modification de FG-SUP pour Sedoric |
|
Page |
| Les Calembours de Schizo Dino |
|
Page |
| L’Oric Maestro revisité : Trois petits fils et puis ça va |
|
Page |
| Initiation Assembleur (5) |
|
Page |
| Quelques Photos de la Visu du 4 Juin |
|
Page |
| Divertissements Mathématiques & Logiques |
|
Page |
| Réponses (54) : Sujets n°158 Ã 161 |
|
Page |
| Nostalgie (61) : Publicité Oric-1 |
|
Page |
| Des Trucs pour Tricher (20) : Gastronon |
|
Page |
| Librairie Oric (56) : Atmos à la Conquète des Jeux |
|
Page |
| 2005 CEO Subscription Form / Back Issue Order Form |
|
Page |
|
Bug Sedoric
par Fabrice Francès
En testant mes disquettes de karaoké pour la visu, je suis tombé sur un bug de Sedoric...
Lorsque la taille d'un fichier est comprise entre 30977 et 31232 octets, c'est à dire lorsque le nombre de secteurs occupés par les données du fichier (sans compter le descripteur) est de 122, (autrement dit le descripteur de fichier est plein à ras bord), alors la routine de chargement de fichier cherche à charger un deuxième descripteur, échoue, et saute alors les instructions E211 à E225 (notamment deux instructions qui mettent à jour l'indicateur de type du fichier chargé). Résultat, le type de fichier chargé (et le fait qu'il faille l'exécuter ou non) est celui du dernier fichier qui avait été chargé avant lui...
Parmi les seize combinaisons possibles (4 pour le fichier de taille 122 secteurs qu'on essaie de charger, 4 pour le fichier précédemment chargé), on peut avoir les comportements erronés suivants:
Cas 1 - on cherche à exécuter un programme en LM et soit il ne démarre pas, soit c'est le programme BASIC présent en mémoire qui démarre à la place...
Cas 2 - on cherche à charger un bloc binaire non exécutable, et soit le programme BASIC présent en mémoire démarre à sa place, soit on se met à exécuter les instructions à l'adresse 0 (!), ce qui se traduit généralement par le message BREAK ON BYTE #0000
Cas 3 - on cherche à charger un programme BASIC non-AUTO, et il démarre quand même, ou alors on exécute les instructions à l'adresse 0 (message BREAK ON BYTE #0000)
Cas 4 - on cherche à charger un programme BASIC AUTO, et il ne démarre pas ou on exécute les instructions à l'adresse 0 (message BREAK...)
Pour visualiser ça, je vous propose les petites manips suivantes: Sur une disquette quelconque, faites :
POKE #600,#60:'un petit programme LM
SAVE“TITIâ€,A#600,E#600,AUTO
SAVE“TUTUâ€,A#600,E#600
SAVE“TESTâ€,A#600,E#7F80
Tapez aussi un petit programme BASIC :
10 PRINT“HELLOâ€
Que vous sauvez par SAVE“HIâ€,AUTO
Commencez alors les tests :
HI (le programme s'exécute et affiche HELLO, normal) puis TEST (après chargement, le programme BASIC en mémoire s'exécute à nouveau, aïe).
Ou encore :
TITI (le programme exécute un RTS, normal) TEST (message BREAK ON BYTE #0000, parce que l'adresse d'exécution de TEST est 0000, même si il n'est pas AUTO).
Voilà , donc Simon si tu rencontres des problèmes avec tes fichiers MIDI (on tombe de temps en temps sur des fichiers de taille comprise entre 30977 et 31232 octets...), ce n'est pas tap2dsk qu'il faut incriminer...
Toutefois, en attendant de corriger ce bug de Sedoric, je peux vous proposer deux «work-around»...
- Soit sauver un fichier un peu plus gros que nécessaire, ce qui créera un deuxième descripteur de fichier référençant le dernier secteur de données...
- J'ai intégré un contournement du bug dans une nouvelle version de tap2dsk: lorsque le fichier fait la taille problématique, un deuxième descripteur de secteurs est alloué, bien qu'il ne contienne rien...
Réponse de Simon Guyart : Impressionnant, bien vu Fabrice ! Coup de chance, je n'ai pour le moment aucun fichier MIDI de cette taille - mais je serai prudent tout de même à l'avenir en n'oubliant pas que Sedoric n'est pas parfait ;-) Tu bosses déjà à la correction du bug, ou veux-tu que l'un de nous essaie de regarder ça à l'occasion ?
Et de Fabrice : Non, je n'ai pas cherché à corriger encore, j'avais d'autres problèmes... Il faut faire attention à ne pas corriger le bug trop rapidement (réfléchir avant d'agir...) parce que ce test de présence d'un deuxième secteur descripteur est utile lorsqu'on a des fichiers mergés...
Fabrice (qui a la phobie des bugs en ce moment, et a passé le week-end à traquer un bug fantôme (je croyais que writedsk mangeait des octets, alors que les octets dis-paraissaient lors du téléchargement sur un site web...)) :-(
|
|
|
|
|
BROWSE
NUMEROS
 [188] - [187] - [186] - [185] - [183] - [182] - [181] - [180] - [179] - [178] - [177] 
YEAR
 2013 - 2012 - 2011 - 2010 - 2009 - 2008 - 2007 - 2006 - 2005 - 2004 - 2003 - 2002 - 2001 - 2000 - 1999 - 1998 - 1997 - 1996 - 1995 - 1994 - 1993 - 1992 - 1991 - 1990
|
Built in 0.04 Seconds