Ecrire directement dans la mémoire écran - Page 1

Salut !

Bon je pose ma question ici pour commencer, ça m'évitera surement une réponse WTF chez AA

Donc voilà mon problème :
Je dispose de 2 buffers de 8160 octets, que je définis comme screen buffer et render buffer. avec SetBuffers.
Ces deux buffers ont les adresses suivantes (que j'ai du pomper quelque part).

#define LYNKS_SCREEN_ADDRESS 0xe010 /* MEMTOP - 8160 */ #define LYNKS_RENDER_ADDRESS 0xc030 /* MEMTOP - 8160 * 2 */
Tout cela fonctionne très bien, et depuis des années.

Oui sauf qu'aujourd'hui en voulant expérimenter un peu, je me suis rendu compte que je faisais planter la console si j'écrivais à la main dans les 1000 derniers octets du screen buffer (plus ou moins). En y réfléchissant un peu, je me dis "mais oui c'est normal", vu qu'il y a des adresses spéciales par là sauf que, sauf que... quand je fais un "SwapBuffers", cette partie de la mémoire est pourtant bien utilisée pour copier la totalité du render buffer et tout se passe bien.

Donc j'avoues que je sèche là pour le coup... Une idée ?

Merci

ps : Je copie les données par bloc avec bcopy.

Je pense (à vérifier) que l'écriture/lecture que tu fais toi même est déclenchée par Mickey (CPU) donc va taper dans les registres système alors que l'affichage/l'écriture/le swap est géré par Suzy (GPU) et que les lectures/écritures de Suzy vont taper directement dans la RAM en ignorant les adresses dédiées à des registres système...

C'était mon intuition aussi et la doc le confirme :

The video and refresh generators in Mikey and the sprite engine in Suzy see the entire 64K byte range as RAM.

Note que tu peux accéder à cette zone de la RAM (sauf les adresses 0xFFF8 et 0xFFF9) via le CPU, en mettant à 1 des bits dans le registre MAPCTL :

FFF9 = MAPCTL. Memory Map Control
(R/W)Mikey reset = 0,0,0,0,0,0,0,0
(W) Suzy reset x,x,x,x,x,x,x,0
(0nly bit 0 is implemented)
B7 = sequential disable. If set, the CPU will always use full cycles (5 ticks min), never a sequential cycle (4 ticks).
B6, B5, B4 = reserved for future use
B3 = FFFA -> FFFF, Vector Space
B2 = FE00 -> FFF7, ROM Space
B1 = FD00 -> FDFF, Mikey Space
B0 = FC00 -> FCFF, Suzy Space

All 8 bits are set to 0 at reset. Any address space bit that is set to a 1 will cause its related address space to access RAM instead of the hardware or R0M normally accessed.

Au passage, SwapBuffers ne fait pas de copie, il ne fait que permuter les adresses des deux buffers : ; ; C: SwapBuffers() ; ; Swap Render and ScreenBuffer ; xrefzp _RenderBuffer,_ScreenBuffer xrefzp __viddma global _SwapBuffers _SwapBuffers: ldy _RenderBuffer ldx _RenderBuffer+1 lda _ScreenBuffer sty _ScreenBuffer sta _RenderBuffer lda _ScreenBuffer+1 stx _ScreenBuffer+1 sta _RenderBuffer+1 lda __viddma and #2 beq _SwapBuffer1 clc tya adc #<8159 tay txa adc #>8159 tax _SwapBuffer1: sty $fd94 stx $fd95 rts

Je pensais effectivement à quelque chose de ce genre mais n'étant pas trop au fait de l'architecture de la machine, et surtout de la facon dont les différents processeurs fonctionnent, je n'en étais pas sûr.

J'ai résolu partiellement mon problème en gardant un flag sur le render buffer actuel (je suis quand même au courant que SwapBuffers ne fait que switcher 2 pointeurs ) ce qui me permet de n'écrire que dans celui-ci.
Ce qui est intéressant en revanche, c'est que lorsque le render buffer est "swappé" sur ces adresses réservées, je peux copier mon image avec bcopy, et sans planter, donc il semblerait que la console ignore les adresses dédiées aux registres système, ou bien j'ai juste de la chance...??

ps : notez que MEMTOP est défini à 0xFFF0 donc les buffers "n'overlappent" pas la zone "critique"

J'ai pas trouvé les sources de bcopy, mais peut-être que cette fonction change simplement MAPCTL pour rendre la RAM accessible avant de faire la copie ?

Je vais tester sur une vraie console ce soir quand meme histoire de pas avoir de faux espoir