Preos 0.72 - Page 1

Bon je resume ce qu'il faut que je fasse:
+ (FAIT) Mettre a jour KPack.
+ (FAIT) Mettre a jour shrnklib
+ (FAIT) Mettre a jour makeprgm pour qu'il supporte le dernier a68k.
+ (FAIT) Flag NoRestoreScreen ne fonctionne plus.
+ (FAIT) Mettre a jour kernel.h pour SetIntVec
+ (FAIT) En cas d'erreur d'execution des Packs Archives, l'erreur n'est pas affichee.
+ (FAIT) Bug de LibsCall (Popping arg + wrong offset ret)

Problemes et bugs verifies:
+ Aucun a part les classiques de Preos (Cf BUGS dans preos.txt).

Problemes et bugs a verifier:
+ Pb avec VTI + TIGCC: Si on essaye d'executer un programme sans librarie avec la touche envoie de l'IDE, VTi balance une exception que Preos intercepte.

Aussi:
+ Pourquoi graphlib-iceberg ne marche-t'il pas avec MrNutz? (Je vais essayer de me plonger dessus aussi.)
+ Régression de PreOs 0.70: Le flag #2 ne marche plus.

Pour l'histoire de MrNutz, j'ai pris:
* MrNutz 2.0 sur http://jcpti89.free.fr/jeuxasm.php (trouvé avec Google)
* PreOs 0.70, parce que c'était ce que j'avais sous la main
* la graphlib que je t'ai envoyée
et j'ai essayé de reproduire le problème sous VTI avec AMS 3.00:
* J'ai pris la version VTI de ma graphlib, qui a le test de synchro HW2 (qui ne marche pas sous VTI) désactivé.
* J'ai édité la table de RAM_CALLs de PreOs pour que ce soit la routine HW2 qui soit appelée (et les clignotements confirment que c'est bien le cas ).

Observations:
* J'ai la barre de vie de MrNutz en bas, pas en haut comme tu avais dit. Le problème, c'était avec quelle version de MrNutz?
* Aucun bogue observable.

Je sais plus quelle version de Mr Nutz. Je te l'envoies des que j'y pense.

Tiens, voilà une version avec la barre de vie en haut: http://zemok89.free.fr/jeuxnew.htm. C'est la 0.2.

Et tu observes le bug ?

Oui. Reste à savoir d'où ça vient. En tout cas, ça n'apparaît plus avec la version la plus récente de Mr. Nutz, donc je dirais qu'à la limite, on s'en fout... Mais j'aimerais bien savoir le pourquoi du comment...

Pas moi

En quittant, je me retrouve avec des EXPR de 1 octet. (Tous les fichiers sont des EXPR de 1 octet!)
Je pense qu'il y a un buffer overflow quelque part...

Oui, mais ou et pourquoi ?

Bonne question. J'aimerais bien le savoir.

Pour déboguer ça sous VTI, cherche "Panick" en RAM et remonte un peu pour avoir tes valeurs de CALCULATOR et HW_VERSION, puis remplace 01 par 02. Et il faut utiliser la version VTI de ma graphlib (frame sync désactivé).

Avec la graphlib-vti de Iceberg 1.00, j'ai une Protected Memory Violation à la place du bogue graphique...

C'est un appel 0xfa3f (ROM_THROW HS_freeAll) qui plante. Le heap de AMS est corrompu. Donc là aussi, il y a buffer overflow quelque part, mais le vrai bogue reste un mystère.

Et on est apparemment déjà dans le crash handler au moment du Protected Memory Violation. Il doit y avoir un autre plantage avant.

Ca m'a clairement l'air d'etre la faute de MrNutz, mais j'aimerais vraiment savoir ce qu'il fait de mal.

Hmmm, non, c'est plutôt un jsr tios::HeapFree...
Contexte:

move.l (a0),(a1)+
move.l (a0),(a1)+
move.l (a0),(a1)+
jsr tios::HeapFree
jsr tios::PortRestore

Voilà le contexte du plantage:

graphlib@000E
gray2:
	movem.l d1-d7/a0-a6,-(a7)
        move.w  handle(pc),-(a7)
	beq.s	\fail
		bclr.b	#2,$600001
		move.l	oldint1(pc),$64
		bset.b	#2,$600001
		lea	LCD_MEM,a0		; Load LCD_MEM
		move.l	a0,d0
		lsr.l	#3,d0
		move.w	d0,$600010		
		lea	plane0(Pc),a1
		move.l	a0,(a1)+
		move.l	a0,(a1)+
		move.l	a0,(a1)+
	        jsr	doorsos::HeapFree
		jsr	doorsos::PortRestore        ;tells AMS to draw to LCD_MEM
		move.b	#2,phase
\fail:

Je pense que c'est le hack pour changer les plans de graphlib avant les exports officiels pour les plans. Il attend un certain ordre pour les variables. On peut le lui donner, ce n'est que pour TitaniK que mon réordonnement est nécessaire (oldint1 doit être copié avec l'interruption).

Bah, j'ai essayé de mettre les variables dans l'ordre de ta graphlib, et ça n'a rien changé...

Mr Nutz hacke graphlib, genre pour faire du double buffering? Peut être que l'ordre des variable n'est pas la seule chose importante, ça dépend à partir d'où il prend son offset de référence aussi nan ?

En tout cas, ce hack est corrigé dans MrNutz 2.0.

Il est dispo preos 0.72?

Il y a une RC sur le site.

Depuis quand ?

Oups, j'ai confondu avec stdlib.

Toujours pas regle le probleme de args.h... a faire

Le kernel.h que je t'ai envoyé n'est pas correct ?

J'ai regardé tous les imports de graphlib dans MrNutz 0.2 et ils ont tous offset 0, donc ce n'est apparemment pas un hack du type graphlib::foo+offset.

PpHd> Quel est le pb avec args ?

Je ne sais pas pourquoi ça bogue avec la graphlib livrée avec Iceberg 1.00, mais ce n'est pas étonnant que la nouvelle bogue, j'ai mis des tst.w CALCULATOR à la place de tst.b CALCULATOR. Ça ne doit pas être le seul problème (parce que ce code n'est pas dans la graphlib de Iceberg 1.00 qui bogue aussi), mais ça en est un.

EDIT: Même avec ce bogue-là corrigé, il y a toujours exactement le même bogue dans MrNutz.

Bon, j'ai trouvé le problème! Pour l'initialisation des plans, j'avais changé:

	move.w	#3840/4-1,d0
\loop:		clr.l	(a1)+
		dbra	d0,\loop

en:

	move.w	#LCD_SIZE_div_4_minus_1,d0
\loop:		clr.l	(a1)+
		dbra	d0,\loop

Or, a1 est réutilisé plus tard (même pas dans le code d'en dessous, mais dans la sous-routine SetUpFirstPlane! PpHd, il faudrait peut-être mettre des commentaires si une routine attend certaines valeurs dans les registres, parce que là, ce n'est pas évident du tout! J'ai rajouté "; WARNING: This routine takes a1 as an input (HW2 plane0 address)!".) pour initialiser le prochain plan, donc le premier plan n'a que 3000 octets d'alloués! Or, MrNutz 0.2 utilise la partie non-visible des plans pour y stocker des données (beurk!), donc bogue.

Je t'envoie une version corrigée de graphlib.

Oui mais ce bug, je l'avais deja corrige.