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 
Courrier Oricien   Page 
Petites Annonces   Page 
Bonnes Adresses   Page 
Atelier : Micro 2065   Page 
Brève : Bug Sedoric   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 
René Magritte (2/4)   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



Hosted By oric.org server www.oric.org V 2.6 CNIL ID : 872370 Write to Webmaster © 2000-2024 Built in 0.16 Seconds