Asteroids (from Arctic Computing) bug

Want to talks about games you like, would like to see developed on the Oric, it's here.
Post Reply
User avatar
Symoon
Archivist
Posts: 1169
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Asteroids (from Arctic Computing) bug

Post by Symoon » Sun Sep 13, 2015 8:35 pm

Ibisum, I saw your message on Oric.org about Asteroids bug. Here is the bug explanation Fabrice sent me in October 2008 (my English translation, then the original French text):

So here is the result of my investigations, there is indeed a problem with the keyboard routines. Five similar routines , located at address $5922 (test Space key), $94EA (test ->), $9522 (test <-), $9561 (test down arrow) et $9700 (test up arrow).
Each time, the sequence used to program the column bytes is:
LDA #0E (to adress registrer #14)
STA 0301
LDA #ED
STA 030C
LDA #DD
STA 030C
LDA #COLONNES
STA 0301
LDA #ED
STA 030C
LDA #DD
STA 030C

... which is incorrect. It looks like the author didn't have any documentation on the VIA and PSG, as he uses twice the same sequence to select the PSG register *and* to write a value. The result is that he actually never selects a register, but he always writes in the currently selected register. This works by chance at the beginning, because the latest selected register is still the IO port of the PSG, and it starts to go wrong as soon as a sound is produced, because the ROM routines have changed the selected register...

One can fix the game by doing:
POKE#5928,255:POKE#94FD,255:POKE#9528,255:POKE#9567,255:POKE#9710,255
before Cloading the Basic part.

Now of course remains the question: why do we have a different behaviour according to Orics... I seem to recall Jonathan (Bristow), as a great PSG specialist, told me once that some PSG didn't like his samples programming techniques, more precisely some PSG don't like the constant writing of values in a selected register. Maybe on those PSG, one constantly has to write the register number, then the register value, so the BC1 and BDIR address lines status are not the same?

--

Alors voilà le résultat de mes premières investigations, il y a effectivement un problème dans les routines de lecture clavier. Cinq routines sur le même schéma qui se trouvent aux adresses $5922 (test touche Espace), $94EA (test ->), $9522 (test <-), $9561 (test flèche bas) et $9700 (test flèche haut).

A chaque fois, la séquence utilisée pour programmer l'octet des colonnes est
LDA #0E (pour adresser le registre n°14)
STA 0301
LDA #ED
STA 030C
LDA #DD
STA 030C
LDA #COLONNES
STA 0301
LDA #ED
STA 030C
LDA #DD
STA 030C

... ce qui est incorrect. On voit bien que l'auteur n'avait pas les informations sur le VIA et le PSG, et qu'il utilise deux fois la même séquence pour sélectionner un registre du PSG *et* pour y écrire une valeur. Le résultat est qu'en fait il ne sélectionne jamais de registre, mais qu'il écrit toujours dans le registre couramment sélectionné.
Ca marche donc par chance au début, parce que le dernier registre sélectionné reste toujours le port IO du PSG, et ça commence à déconner dès qu'on fait un son, parce que les routines en rom qui jouent un son changent le registre couramment sélectionné...

On peut corriger le jeu en faisant des
POKE#5928,255:POKE#94FD,255:POKE#9528,255:POKE#9567,255:POKE#9710,255
avant de faire le CLOAD de la partie BASIC...

Maintenant reste bien sûr la question pourquoi est-ce qu'on a un comportement différent sur certains Orics...
Je crois me rappeler que Jonathan, en grand spécialiste du PSG, m'a dit une fois que certains PSG ne supportaient pas toutes ses techniques de programmation de samples, plus précisément certains PSG ne supportent pas l'écriture continue de valeurs dans un registre sélectionné. Peut-être que sur ces PSG, on est obligé d'écrire systématique en alternance le numéro de registre puis le contenu du registre, et que du coup les états associés aux lignes d'adressage BC1 et BDIR ne sont pas les mêmes ?
Last edited by Symoon on Mon Sep 14, 2015 5:44 am, edited 1 time in total.

User avatar
iss
Squad Leader
Posts: 515
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Asteroids (from Arctic Computing) bug

Post by iss » Sun Sep 13, 2015 11:49 pm

Actually IBISUM wants more info about the bug, but it's interesting reading for me too.
Here some comments about the routine:
- use $30F instead of $301
- write to $30C: $FF + $DD to select PSG register
- wtite to $30C: $FD + $DD to set value to selected register

User avatar
Symoon
Archivist
Posts: 1169
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Asteroids (from Arctic Computing) bug

Post by Symoon » Mon Sep 14, 2015 5:43 am

iss wrote:Actually IBISUM wants more info about the bug
Oooops sorry for mixing names. I really need to rest!

User avatar
ibisum
Squad Leader
Posts: 878
Joined: Fri Apr 03, 2009 8:56 am

Re: Asteroids (from Arctic Computing) bug

Post by ibisum » Mon Sep 14, 2015 9:53 pm

Symoon - thanks for pointing this out and for engaging in a neat investigation of this issue .. do you think its worth trying to release a 'fixed' version of this ASTEROIDS game now that you know whats up, or is it just a curiosity at the moment .. ?

User avatar
Symoon
Archivist
Posts: 1169
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Asteroids (from Arctic Computing) bug

Post by Symoon » Tue Sep 15, 2015 4:57 am

ibisum wrote:Symoon - thanks for pointing this out and for engaging in a neat investigation of this issue .. do you think its worth trying to release a 'fixed' version of this ASTEROIDS game now that you know whats up, or is it just a curiosity at the moment .. ?
I was just victim of the bug, apart from asking here or there and checking the original code was correctly transfered, Fabrice deserves all the credit as he did all the research work! ;)
A fixed version is already available on Oric.org ;)

Post Reply

Who is online

Users browsing this forum: No registered users and 7 guests