Salut,
Cela faisait des années, que je voulais tester le code, et je pense qu'on ne peut pas faire plus vite en scroll sur oric.
Donc en entrée :
* Oric avec un 65C816 à 1 mhz
* lecture sur sdcard de 8ko puis scroll de la ram video avec l'instruction mvn.
En gros, on définit l'adresse source, l'adresse destination, on dit combien de bytes on bouge, et on scrolle (ici je scrolle en banque 00 : dans les 1ers 64KB de la RAM).
et je le fais 200 fois pour scroller à chaque fois 8000 bytes. L'instruction mvn déclenche donc la copie des 8000 bytes à coup de 3 cycles par byte copié, si j'ai bien lu (modulo le cycle sur le changement de page).
rep #$30 ; Make Accumulator and index 16-bit @loopme: ldx #$A028 ldy #$A000 lda #8000 mvn $00,$00 dec iter bne @loopme
Waou ..
Scrolling en mode hires .. carrément 🙂
Avec un opcode qui humilie le memcpy.
C'est du propre.
C'est super de fluidité.
Dommage qu'ils n'aient jamais sorti l'Oric 1GS
@jibe Si tu regardes les opcodes du 65C816, il est fortement possible que des routines de gloric ou du raycasting puissent être écrites en version 16 bits pour accélérer le traitement.
Quel est l'intéret de le faire en 16 bits ? ben au moins moi, je peux le voir tourner en 16 bits 🙂
Plus sérieusement, je fais les modules 65C816, mais on va dire que j'ai des gros pbs de stabilité entre les Oric et donc, c'est de l'expérimental, mais cela marche bien chez moi ici sur un oric.
Je me suis tellement acharné à faire rentrer de la 3D dans 8 bits que je suis vraiment ressorti avec une solution ultra dédiée 8 bits et dont la plupart des algos ne tirerait que peu profit du 16 bits.
Si je devais faire de la 3D en 16 bits, je pense que je repartirais dans une direction vraiment différente.
Cela dit, dans les opérations manipulant des textures, il y a pas d'arithmétique de pointeur (pour aller taper aux bons endroit dans les textures) et ces opérations impliquent pas mal d'addition 16 bits d'adresse qui gagneraient à être exécutée sur un 65C816.
😀
