L'aventure racontée par
8-bit show and tell est presque surréaliste: un dévelopeur de jeu qui vous envoie un morceau de son code source comme ça, juste sur demande. Et pas n'importe quel développeur: le créateur de
Pitfall!Pitfall, pour ceux qui n'ont pas vécu ça, c'est ce qui se rapproche le plus du phénomène Super Mario Bros pour les possesseurs de micro-ordinateurs jusqu'à ce que Great Giana Sisters ne devienne facile à trouver.
Je m'attendais à un bouquin/carnet déjà costaud, du coup, en fait, la chose tient sur l'espace de menu de mariage. juste une page US letter pliée en deux, l'extérieur contenant un petit mot du créateur et des illustrations.
C'est un programme a priori typique de la "programmation système" en BASIC C64, avec plein de POKEs pour modifier des registres du contrôleur vidéo et des DATA avec les trucs à y mettre. Le machin bien opaque pour qui n'a pas un bon manuel pour décrypter ce qui se passe. En plus des DATA avec des sprites convertis en décimal, il y a un autre jeu avec du code machine pré-assemblé qu'on va aller POKEr dans un coin de mémoire pour pouvoir l'exécuter. (Là aussi, il y a un bouquin, mais c'est plus chaud).
if you speak English, you're lucky. Because that means you can enjoy the full 8-bit show'n'tell where the story of that 'Programming Pitfall! Harry' leaflet that invited kids of the eighties to type from scratch something that would make the most iconic video game adventurer of the time do a footing on their screen. I mean it. That dude was the early eighties' Lara Croft.
If you've done some C64 programming, the content of the leaflet will be obscure but somewhat familiar. It's a loop POKEing things in memory so that the video chip (VIC-II) can render sprites and some obscure DATA that contain what it takes to get pixels the expected shape. There's something alike in the C64 manual to make your first sprite and I had tweaked a lunar lander BASIC game to feature Calimero instead of the LM back in my 10s.
Au final, on aura 'juste' le personnage Harry qui se promène à l'écran. Ouaip, je vois déjà les blasés du Scratch qui rigolent au fond, mais eh. 1) il est multi-colore. 2) il court (animation) et bouge tout à la fois. 3) il est grand. Rien à voir avec la démo-ballon du manuel C64, hein!
Et surtout, tu fais RUN STOP pour revenir à l'interpréteur BASIC, et le mec, il continue son footing. C'est le Mario-de-l'éditeur-de-Bisquit avec 25 ans d'avance!
En fait, on a pas ici une boucle BASIC qui anime et déplace: c'est un morceau de code machine installé juste avant le code qui fait clignoter le curseur texte qui s'occupe de faire bouger le personnage. Tout ça tenant dans le tampon mémoire prévu pour la lecture des cassette.
Pour se situer,
le tape buffer utilisé dans le programme présenté dispose d'à peu près 200 bytes. A côté de ça, l'autre zone mémoire qui est disponible sans toucher au setup habituel pour faire du BASIC fait 4K et se trouve en 0xc000, juste avant les ROMS CHR et KERNEL.
But there's actually more here. You don't have to interrupt the program to return to BASIC interpreter: it does it by itself. And yet, Harry keeps footing on your screen while you can tweak the program or scratch it and run another one. That's because you haven't only POKEd some sprites data: you've also POKEd a small assembler routine that will be invoked ahead of the cursor blinking logic that will move and animate Harry's sprite.
I can only dream of what I'd have done with this if I had been exposed to such a sample when I was a C64 teenager. Think of it: tweak a few locations in memory and you could switch the character's behaviour between jump, idle, run, fall ... Chain a few other routines in a BASIC room-loader with POKEs and you could have a monster patrolling on line 42 while your character is running on another location. And you're free to run your loop checking their positions, computing whether collisions occured and adjust their behaviour if it did.
With some extra LDA and CMP opcodes, maybe the characters under the sprite could be checked and a flag could be set so that the BASIC code would know we've entered a 'FAIL' condition ...
Je ne peux m'empêcher de penser ... et si ... Et si au moment de commencer à travailler sur Logic Labyrinth j'avais eu accès à un petit programme de ce genre qui puisse déplacer un objet de manière quasi-autonome.
On aurait gardé un programme BASIC qui dessinerait la bonne salle et ajouterait quelques POKE pour chainer les uns derrière les autres character_interrupt, puis hshot_interrupt et walking_monster1_interrupt pour que les différents "personnages" de l'écran soient présents.
Ensuite, on aurait eu une boucle qui faisait de son mieux pour tester la position du personnage par rapport aux triggers du niveau et qui aurait fait apparaître ou disparaître certains éléments...
Mais bon, mon seul contact avec le code machine du C64, c'était en 1997, 10 ans trop tard, et tout ce que mon bouquin proposait, c'était de charger un bout de code pour remplacer les caractères ROM par des caractères RAM histoire de pouvoir remplacer le T par un smiley.
Par contre, il faudra que je tire au clair cette histoire de 'VIC bank'. Quand j'ai commencé à écrire des programmes plus grands (pour Space Mission) mélangeant des tableaux de grande DIM(ension) et plus de sprites, je finissais par avoir mon programme qui provoquait des "erreurs systèmes", au point que le listing lui-même n'était plus garanti. Et si c'était simplement parce que j'écrasais des morceaux de listing avec mes POKEs ?
.png){kind=tracking}
- + 
Vote for your favourite post
