Dev Développement Wonderswan (le retour) - Page 24

J'ai un sachet de Bonne maman...

Le M majuscule et le "s" absents c'est pour éviter de confondre les 2 ^^'

(j'ai mis les slides d'ailleurs sur mon blog)

Cool

J'avance lentement malheureusement depuis la RGC pour plusieurs raisons.. Budgetaires, un peu de motivations (pour plein de raisons) et aussi parce que j'ai trouzemilles projets en parallèle (OricMouse, Cumulus Rev2, et quelques autres bricoles) Enfin les choses avancent bien des deux coté, pour la Madeleine, il manque surtout le soft pour l'instant, et de faire une revision sur le hardware pour la connection avec le PC.

Mais tout avance en meme temps actuellement c'est une bonne chose, j'ai presque terminé le PCB du proto pour le Cumulus Rev2, j'ai un proto pour l'OricMouse qui m'a prouvé que j'ai fait une connerie, et maintenant je suis en train de la corriger (rien de trop grave heureusement) et mes autres projets avancent..
(Oh et je vais bientot pouvoir tenter de réparer mon Virtual Boy , j'ai acheté un V Tetris a pas cher, on verra ce que ca donne... )

On veut une madeleine!

Tiens tiens, mais qu'est-ce donc?

#XRay is #FUN! (sorry my phone had real difficulty to focus on the display :( (cc @f4grx @RDGhack) pic.twitter.com/vhtts7e6cM

— Manoel Trapier (@Gozilu) April 29, 2016

Et alors, est-ce qu'il y a des explosifs dedans ?

Ya un truc noir suspect sur le haut en effet

Tes allé faire chier ton dentiste?

Je mettrais pas ma mâchoire dans la machine en question

(ne serait-ce parce que c'est physiquement impossible )

Quelques découvertes cette nuit en désassemblant le jeu Tetris et en faisant des essais sur une vraie Wonderswan : y'a des erreurs dans wstech24.txt au sujet du port série.

0 - Recieve Complete

wstech24 dit ceci :  - $B3 - $00 - Communication direction
                  bit 7 - Recieve data interrupt generation
                  bit 6 - Connection Speed
                           0 - 9600  bps
                           1 - 38400 bps
                  bit 5 - Send data interrupt generation
                  bit 4 - ???
                  bit 3 - ???
                  bit 2 - Send Complete
                  bit 1 - Error
                  bit 

• Pour les bits 0, 2 et 6, ça semble correspondre.

• Le bit 7 semble être un on/off pour le module port série en entier. Si on le met à 0, l'émission et la réception ne fonctionnent plus, et le port $B3 renvoie toujours $00.

• Le bit 5 ne semble pas exister : le mettre à 1 n'a pas d'effet visible, et il reste toujours à 0 quand on le lit.

• Quand il y a une erreur de réception, le bit 1 passe bien à 1, mais on ne peut pas le remettre à 0 en écrivant dedans. Il faut mettre le bit 7 à 0 puis à 1 pour réinitialiser le port série. Attention à sauvegarder manuellement l'état du bit 6, il repasse à 0 quand on désactive le port série.

il a l'air un peu claqushooté le monsieur qui ressemble a Neo

bah désouder des composant des cartouches officielles a forcement un effet negatif

Cadeau pour Zerosquare:
E000:C103 _read_int_eeprom proc near ; CODE XREF: freyaWwcSysGetOwnerInfo:loc_EC078p E000:C103 push bx E000:C104 mov ax, 8000h E000:C107 cmp bx, 400h E000:C10B jnb short loc_EC132 E000:C10D mov ax, 180h E000:C110 shl ax, 4 E000:C113 add ax, bx E000:C115 out WS_IO_INT_EEP_ADDR_L, ax E000:C117 mov al, 10h E000:C119 out WS_IO_INT_EEP_STATUS, al E000:C11B xor dx, dx E000:C11D E000:C11D loc_EC11D: ; CODE XREF: _read_int_eeprom+27j E000:C11D inc dx E000:C11E mov ax, 8101h E000:C121 cmp dx, 20h ; ' ' E000:C124 jz short loc_EC132 E000:C126 in al, WS_IO_INT_EEP_STATUS E000:C128 and al, 1 E000:C12A jz short loc_EC11D E000:C12C in ax, WS_IO_INT_EEP_DATA_L E000:C12E mov dx, ax E000:C130 xor ax, ax E000:C132 E000:C132 loc_EC132: ; CODE XREF: _read_int_eeprom+8j E000:C132 ; _read_int_eeprom+21j E000:C132 pop bx E000:C133 retn E000:C133 _read_int_eeprom endp
Voila une fonction officielle pour lire l'EEPROM interne d'une wonderswan color/crystal en mode normal (pas en mode compatibilité WS)

(j'ai documenté plus de 370 fonctions dans le WonderWitch jusqu'a present et je suis loin du compte, le gros du BIOS est fait, la partie graphique je suis juste en train de documenter une lib, l'OS en lui meme est encore loin.. )

Pour l'histoire, le wonderwitch est composé de deux parties de 64K, le "BIOS" (FreyaBIOS) et Freya en lui meme (aussi nommé FreyaOS)

Le BIOS est a l'image des BIOS PC une couche d'abstraction au dessus du hardware et c'est lui qui fourni 99% des fonctions utilisé lors du développement avec le WonderWitch.
Le BIOS est probablement ecrit a 100% en ASM (je n'exclue pas qu'il y ai des bouts en C, mais vu la construction c'est peu probable, et je n'ai aucune preuve encore que ca soit le cas)

Freya est la partie OS (oui il y a bien un mini OS, avec gestion de fichiers, de process & co) qui lui est ecrit en C, avec quelques bricoles en ASM, enfin le code ASM que j'ai pu trouver jusqu'a present viens des libs utilisé.

Il est fort probable que le compilateur utilisé pour Freya soit Borland TCC 2.0.1 (je n'ai aucune preuve tangible, mais les libs ont été compilé avec TCC)
Qute (ceux qui on développé le WonderWitch) on (bien) fait ce qu'on appel "eat your own dog food", Freya est une application de 64K, compilé avec exactement la meme lib que celle qu'on utilise pour faire nos applications/jeux pour le WonderWitch a l'octet pret. En documentant Freya j'ai fini par tomber sur des fonction qui faisaient appel au Bios, et qui utilisaient la meme convention d'appel et prototypes que les fonctions officielles, j'ai continué par comparer avec les fichiers .lib fourni, et les fonctions sont identiques (au relogement pret, mais c'est normal)

Fait amusant, il s'avere qu'il a plein de fonction presente dans la lib qui ne sont pas documenté (ni dans les headers fournis, ni dans la doc officielle) ce qui est relativement amusant parce que par contre il y a des fonction interne qui sont dans les headers fournis, genre des fonctions comme ltpos2rtpos, as_segbase, as_farp ou meme des fonctions comme fs_getfs. L'utilisations de ses fonctions n'est pas documenté et ont une utilisation douteuse en dehors de Freya.

D'ailleurs, chose amusante (mais qui est en partie documenté par la doc du WonderWitch), toutes les fonctions qui touchent aux systeme de fichiers, libraries, et autres fonction de gestion de process, ne sont pas fournies par le BIOS, mais par Freya en lui meme, ou plutot, par la librairie fournie, je n'ai pas trouvé encore de fonction qui fassent appel via int ou pas a l'OS, juste des fonctions qui vont directement lire en mémoire les informations, voir directement jouer avec les IOs.

Je ne sais pas si cette approche est la meilleur a vrai dire, le soucis etant que freya est force d'etre compatible avec toutes les versions anterieure au niveau du stockage memoire du filesystem ou des process sous peine de casser les applications qui font appel a ce genre de fonctions. Il aurais été plus sage d'utiliser aussi le mechanisme des INTs pour faire appel a ce genre de fonctions.


Et derniere curiosité, j'ai deja trouvé 3 bugs grossiers et plutot génant, je n'avais pas fait gaffe, mais un d'entre eux est documenté dans les headers, une partie du BIOS est foireuse, et un certains type d'IRQ ne peux pas marcher du tout de par le code fait, l'IRQ est completement ignoré et est géré comme un autre type. Je n'ai pas trouvé encore dans Freya si ils patchent cette fonction, mais en tout cas, les headers affichent "fierement":
/* due to BIOS 1.0 bug, sys_interrupt_reset_hook doesn't allow inlining */
En gros, je n'ai pas encore regarder le code, mais la fonction doit parcher certaines choses pour que ca marche, et ne doit pas utiliser le BIOS pour ca.

C'est la ou j'arrive au dernier bug que j'ai trouvé. Quand on appele les fonctions du BIOS depuis notre application, il y a deux modes d'appels, le "FAST" (on inline directement et laisse le compilateur faire l'appel a l'interruption) ou au travers des fonctions fournis par Qute et qui sont dans les .lib fournis.

Comme dit plus haut certains fonction ne sont que dans les .lib car non fournis par le BIOS (principalement filesystem et process, mais aussi la lib couleur)
La ou est le probleme, c'est qu'une des fonctions est buggé, et ce de maniere idiote en plus..
La fonction est
void near bank_fill_block(int bank, unsigned offset, unsigned size, unsigned data);
La version inline fonctionne a merveille, la version de la lib par contre.. L'appel a l'interruption donne le mauvais numero pour la fonction de l'interruption: 7 a la place de 8 et appelle la fonction BANK_WRITE_BLOCK plutot que BANK_FILL_BLOCK.

La difference entre les deux c'est que BANK_FILL_BLOCK remplis le block avec une seule et unique valeur, BANK_WRITE_BLOCK lui utilise un buffer. Probleme, la le registre qui donne le buffer n'est pas initialisé, donc une zone mémoire indeterminé est utilisé pour remplir le block.
Rien de super mechant, mais quand meme ca ne fait pas ce qu'on veux, mais le pire, c'est que cette fonction est utilisé par Freya lors du test de la SRAM, ou de la Flash:

Depuis libww.lib:fill_blk.c_TEXT:0000 public _bank_fill_block _TEXT:0000 _bank_fill_block proc near _TEXT:0000 _TEXT:0000 arg_0 = word ptr 4 ; int bank _TEXT:0000 arg_2 = word ptr 6 ; unsigned offset _TEXT:0000 arg_4 = word ptr 8 ; unsigned size _TEXT:0000 arg_6 = byte ptr 0Ah ; unsigned data _TEXT:0000 _TEXT:0000 push bp _TEXT:0001 mov bp, sp _TEXT:0003 mov al, [bp+arg_6] _TEXT:0006 mov bx, [bp+arg_0] _TEXT:0009 mov cx, [bp+arg_4] _TEXT:000C mov dx, [bp+arg_2] _TEXT:000F mov ah, 7 ; BANK_WRITE_BLOCK _TEXT:0011 int 18h ; INT_BANK _TEXT:0013 pop bp _TEXT:0014 retn _TEXT:0014 _bank_fill_block endp
Depuis libww.lib:wrt_blk.c_TEXT:0000 _bank_write_block proc near _TEXT:0000 _TEXT:0000 var_2 = word ptr -2 ; backup of SI register _TEXT:0000 arg_0 = word ptr 4 ; int bank _TEXT:0000 arg_2 = word ptr 6 ; unsigned offset _TEXT:0000 arg_4 = word ptr 8 ; void far *buffer segment _TEXT:0000 arg_6 = word ptr 0Ah ; void far *buffer ofsset _TEXT:0000 arg_8 = word ptr 0Ch ; unsigned size _TEXT:0000 _TEXT:0000 push bp _TEXT:0001 mov bp, sp _TEXT:0003 sub sp, 2 _TEXT:0006 push si _TEXT:0007 push di _TEXT:0008 mov di, ds _TEXT:000A mov ax, si _TEXT:000C mov [bp+var_2], ax _TEXT:000F mov ax, [bp+arg_6] _TEXT:0012 mov ds, ax _TEXT:0014 mov si, [bp+arg_4] _TEXT:0017 mov dx, [bp+arg_2] _TEXT:001A mov cx, [bp+arg_8] _TEXT:001D mov bx, [bp+arg_0] _TEXT:0020 mov ah, 7 ; BANK_WRITE_BLOCK _TEXT:0022 int 18h ; INT_BANK _TEXT:0024 mov si, [bp+var_2] _TEXT:0027 mov ds, di _TEXT:0029 pop di _TEXT:002A pop si _TEXT:002B leave _TEXT:002C retn _TEXT:002C _bank_write_block endp
Dans freya: FreyaOSStart: [...] E000:008E push 0 ; data E000:0090 push 0FFE0h ; size E000:0092 push 0 ; offset E000:0094 push 3 ; bank E000:0096 call freyaBankFillBlock [...] E000:A6B6 ; void __cdecl __near freyaBankFillBlock(int bank, unsigned int offset, unsigned int size, unsigned int data) E000:A6B6 freyaBankFillBlock proc near ; CODE XREF: FreyaOSStart+96p E000:A6B6 E000:A6B6 bank = word ptr 4 E000:A6B6 offset = word ptr 6 E000:A6B6 size = word ptr 8 E000:A6B6 data = word ptr 0Ah E000:A6B6 E000:A6B6 push bp E000:A6B7 mov bp, sp E000:A6B9 mov al, byte ptr [bp+data] E000:A6BC mov bx, [bp+bank] E000:A6BF mov cx, [bp+size] E000:A6C2 mov dx, [bp+offset] E000:A6C5 mov ah, BANK_WRITE_BLOCK E000:A6C7 int INT_BANK ; "" E000:A6C9 pop bp E000:A6CA retn E000:A6CA freyaBankFillBlock endp

Oh du code x86, c'est exactement ce que je voulais pour Noël ! Merci Godzil !

Je peux te désassembler Windows si tu veux

Oui stp!

Ok, c'est parti !

Folco (./709) :
Je peux te désassembler Windows si tu veux

C'est gentil, mais tu vas être déçu, il n'y a pas de code 68k dedans ^^

Et puis y'a pas besoin de désassembler Windows, les sources sont dispos si tu payes suffisamment cher à MS

Sérieux ? Tiens, ça serait marrant à voir ^^

Oui. Tu peux avoir accès au code de Windows si tu veux faire ton propre audit (typiquement ça peut intéresser les militaires, les gouvernements...), ou si tu codes un truc très bas niveau qui nécessite d'avoir ce genre d'infos (antivirus, etc.). Mais évidemment c'est coûteux.

En gratos, il me semble qu'il y avait les sources de certains drivers dans le Driver Development Kit de Windows 98, c'est peut-être toujours le cas. Sinon, les sources de Windows 2000 ont fuité y'a pas mal d'années ; en cherchant un peu, tu dois pouvoir en trouver au moins des petits morceaux ^^

Je suis sur qu'on doit trouver sur le web des sources de windows meme sans payer tres cher oui ^^

Si tu veux du 68000 on pux trouver les source de Systeme pour Macintosh version 7, il y a du C et de l'ASM 68k

(et même du Pascal dans les versions précédentes)

En effet!
C'est meme d'ailleurs pour ca que les chaines sont stockée au format Pascal et non C (enfin elle sont réellement stocké dans un format hybride)

La qualité des compilateurs, c'est... moche :/
Freya:ABD7 ; _FsIl far *__cdecl __near get_il(fent_t *filesystem) Freya:ABD7 _get_il proc near ; CODE XREF: FreyaOSStart+ABp Freya:ABD7 ; FreyaOSStart+C8p ... Freya:ABD7 Freya:ABD7 pfsPath = dword ptr -8 Freya:ABD7 ptrFsIl = dword ptr -4 Freya:ABD7 filesystem = word ptr 4 Freya:ABD7 Freya:ABD7 push bp Freya:ABD8 mov bp, sp Freya:ABDA sub sp, 8 Freya:ABDD les bx, dword ptr [bp+filesystem] Freya:ABE0 les bx, es:[bx+fent_t.handler.il] Freya:ABE4 mov word ptr [bp+ptrFsIl+2], es Freya:ABE7 mov word ptr [bp+ptrFsIl], bx Freya:ABEA mov ax, word ptr [bp+ptrFsIl+2] Freya:ABED or ax, ax Freya:ABEF jz short loc_EABF4 Freya:ABF1 jmp loc_EAC1C Freya:ABF4 ; --------------------------------------------------------------------------- Freya:ABF4 Freya:ABF4 loc_EABF4: ; CODE XREF: _get_il+18j Freya:ABF4 jmp loc_EAC02 Freya:ABF4 ; --------------------------------------------------------------------------- Freya:ABF7 ; char path[] Freya:ABF7 path text "Shift-JIS", '/kern/@pfs',0 ; DATA XREF: _get_il:loc_EAC02o Freya:AC02 ; --------------------------------------------------------------------------- Freya:AC02 Freya:AC02 loc_EAC02: ; CODE XREF: _get_il:loc_EABF4j Freya:AC02 lea ax, path ; "/kern/@pfs" Freya:AC06 mov dx, cs Freya:AC08 mov word ptr [bp+pfsPath+2], dx Freya:AC0B mov word ptr [bp+pfsPath], ax Freya:AC0E push dx Freya:AC0F push ax ; path Freya:AC10 call _mmap Freya:AC13 add sp, 4 Freya:AC16 mov word ptr [bp+ptrFsIl+2], dx Freya:AC19 mov word ptr [bp+ptrFsIl], ax Freya:AC1C Freya:AC1C loc_EAC1C: ; CODE XREF: _get_il+1Aj Freya:AC1C mov dx, word ptr [bp+ptrFsIl+2] Freya:AC1F mov ax, word ptr [bp+ptrFsIl] Freya:AC22 leave Freya:AC23 retn Freya:AC23 _get_il endp
Edit: en fait je dit une connerie, le code est en ASM (le fichier d'origine est "get_il.asm"....) encore pire

Le code que me donne Borland C++ 3 est relativement proche (si ce n'est qu'il fait appel a une fonction que je vois pas pourquoi car c'est un appel automatique)

La qualité de certains codeurs, c'est... moche :/ ()