FM77AV - learning how to program it (english thread)

[jimbobaby]

That's a good idea, this way you're reducing the wasted time waiting for the real retrace to happen and no drifting is going to mess with your synching!. Nice!
Also, the XM7 emulator seems impressive if these kind of details are supported with such level of detail, good for it!

That's the thing, when i tried the first, lame attempt, of syncing to vsync just on the initial timer start, i was REALLY surprised to see no drifting at all even if i let it sit for some minutes.
Of course, i tried with other timer values (i.e. $73 (16.523ms) or $71 (16.757ms)) and the drift is very clear and steady, so, again, i don't know .

I still don't believe this would work on real hw, not at all. But i'm prepared for the worst

[pser1]

(*) Anyway, if that doesn't work, i was thinking (and the code is ready) to program it with a little less than 16ms, and then re-sync on every timer IRQ to the real vsync. Obviously re-sync 60 times a second is slower than no-resync at all, but the time spent on re-synch could be calibrated to be the least possible. In fact even the re-sync code (realvsync) could be simplfied as it's a special case.

That's a good idea, this way you're reducing the wasted time waiting for the real retrace to happen and no drifting is going to mess with your synching!. Nice!
Also, the XM7 emulator seems impressive if these kind of details are supported with such level of detail, good for it!

I agree with that, sooner or later we will need some way to synchronize with the vertical retrace ...
Have a good weekend!

[pser1]

Honestly, i didn't want to interrupt your work on the engine. You are doing hard work the right way and, after all, it's better to optimize when you have all the pieces in place than in between. So, do not worry by now
And yes, screen change was, the last time i measured it, about 4-5 screen changes per second, that would be about 200ms give or take. I don't think it would be a problem given the amounts of time it gets called.
And again, i think optimizing should be done at the end, only where it's needed.
One step at a time
Edit: i have put the last changes on the 9E version.

Thanks a lot for that
Honestly, you have not interrupted our work on the engine. I, myself, do that most of the time
Right now I should be working on the C compiler to convert the AGD objects data into the structure we have agreed here, that's to say an image table with 128 bytes per entry (4 planes each 32 bytes) and a data table with only 7 bytes (image number, current screen, current posY, current posX, initial screen number, initial posY, initial posX). But I have not yet started that
This change will imply the engine DrawObj function to be rewritten to take into account the new data structure.
And important, I need to test your new IRQ interrupt Service Routine for the OPN. I am sure most of you have already noticed that when executing
the last version or any previous one, that pressing a key like 'O', 'P' is not always detected correctly by the engine. I found that the keys must be pressed for a longer period instead of just a touch, but not that much to avoid repetitions!
Maybe the long and convoluted subroutine to scan the keyboard that we have inherited from ShounenMike takes way too many cycles, I don't know.
I will try to compile on LWASM setting directives to count the cycles inside that SBR, but this depends on the friendshipness of LWASM with respect to the
syntax used and accepted by ASM6809. If problems do arise, I would extract the SBR and compile it alone.
cheers!

[jimbobaby]

I am sure most of you have already noticed that when executing
the last version or any previous one, that pressing a key like 'O', 'P' is not always detected correctly by the engine. I found that the keys must be pressed for a longer period instead of just a touch, but not that much to avoid repetitions!

I have not noticed that... . Will take a closer look...

Edit: i have been testing (with XM7 and mutsu) and i don't see any problem at all with keyboard response time, all key presses are done without miss.
Also, i don't have repetitions when i let one of these keys pressed.

Do you have on XM7->tools->settings->Keyboard some check activated? (i have both disabled)

[pser1]

I am sure most of you have already noticed that when executing
the last version or any previous one, that pressing a key like 'O', 'P' is not always detected correctly by the engine. I found that the keys must be pressed for a longer period instead of just a touch, but not that much to avoid repetitions!

I have not noticed that... . Will take a closer look...
Edit: i have been testing (with XM7 and mutsu) and i don't see any problem at all with keyboard response time, all key presses are done without miss.
Also, i don't have repetitions when i let one of these keys pressed.
Do you have on XM7->tools->settings->Keyboard some check activated? (i have both disabled)

Hi César,
I have been testing the sources you had uploaded here and with these versions I do not find any problem with the keyboard
Maybe old versions that where receiving a lot of interrupts from the Timer could be masking the keyboard (sometimes)
I would not bother more about that. I have commented out the upper red bar and a few extra lines that are no more needed.
TIMERL is not needed because it was a counter to increase TIMER when it arrived to value 20 (or 60), now it is enough to increment TIMER
In NewIRQ no need to check for timer IRQ because they are no more generated, so a few lines reduced ...
Yours is a great improvement!
cheers!

[jimbobaby]

I have been testing the sources you had uploaded here and with these versions I do not find any problem with the keyboard
Maybe old versions that where receiving a lot of interrupts from the Timer could be masking the keyboard (sometimes)
I would not bother more about that. I have commented out the upper red bar and a few extra lines that are no more needed.
TIMERL is not needed because it was a counter to increase TIMER when it arrived to value 20 (or 60), now it is enough to increment TIMER
In NewIRQ no need to check for timer IRQ because they are no more generated, so a few lines reduced ...

Great! I'm glad to be able to help somehow

[pser1]

Hola,
está claro que hay cosas que se me escapan con este FM77AV.
Estaba tratando de volver a aplicar el cambio de color 1 para manejar los márgenes aprovechando que los cambios de jimbobaby en los IRQ permiten trabajar mejor y me encuentro con la sorpresa de que todo funciona correctamente, pero al salir del programa mediante ESPACIO+CTRL IZDA, no retorna al prompt de Basic, se queda colgado
Y requiere un Reset para volver a él. Ha mantenido el programa Basic que lanza el juego, pero no ha sido capaz de volver ...
He ido tirando atrás versiones y he tenido que llegar a la v09E para que funcionara correctamente. Esto significa que en el cambio de versión a v09F
algo me cargué y lo sigo heredando en las posteriores.
Resumiendo las versiones v09F, v09G y v10 tienen este problema que hay que corregir
Por lo demás, las funcionalidades son correctas ...
saludos

[pser1]

tiene pinta de quedar 'colgado' en en área $D2FC que corresponde a una rutina de servicio de interrupciones ...
A ver si encuentro el motivo.
Lo cierto que hay bastantes diferencias entre los ficheros FM77CODE en versiones v09E y v09F
A ver si puedo dedicarme mas tarde a la búsqueda del error ...

[pser1]

@jimbobaby
no voy sobrado de tiempo, pero me da la impresión de que esto ha sucedido a partir del momento en que hemos empezado a utilizar el OPN
El teclado y el Timer se activan y desactivan sus interrupciones con una máscara, pero no he podido buscar como se activan las interrupciones
del timer A del OPN y probablemente lo que falta es código para deshabilitar dichas interrupciones que deben seguir generándose cuando acaba el programa y se queda en bucle en la rutina std de IRQ, supongo ...
saludos

[jimbobaby]

@jimbobaby
no voy sobrado de tiempo, pero me da la impresión de que esto ha sucedido a partir del momento en que hemos empezado a utilizar el OPN
El teclado y el Timer se activan y desactivan sus interrupciones con una máscara, pero no he podido buscar como se activan las interrupciones
del timer A del OPN y probablemente lo que falta es código para deshabilitar dichas interrupciones que deben seguir generándose cuando acaba el programa y se queda en bucle en la rutina std de IRQ, supongo ...
saludos

Hi Pere

Yes, it's patched now, it was my fault (not restoring the timer at the end ).

Attached src (with some minor things) from v10.

[pser1]

Hi Pere
Yes, it's patched now, it was my fault (not restoring the timer at the end ).
Attached src (with some minor things) from v10.

No problem at all ...
Sorry for having changed language to spanish in this thread, too fast, too bad
Going to correct that part only in v10
cheers!

[pser1]

I have modified v10 with the changes you'd made on the last uploaded file.
Now everything works fine.
Will upload updated version in Objects thread
thanks a lot
cheers!

[pser1]

@malikto999
Hi,
we are working in a new project that should end with the conversion of a Spectrum AGD game named "SPRINGBOT" for the FM77AV2 computer.
We are using some threads in spanish language to discuss about the problems that arise along that game conversion, with the extra difficulties you know we must face due to the lack of knowledge about the hardware of this incredible machine!
We just wanted to let you know that your pupils are working hard to get the max out of the FM77AV and would like to thank the unvaluable help you gave us in the beginning with docs and examples.
If you had any problem while having a peek to the project threads, just let us know ... don't hesitate to chime in any of them. Your hints/ideas will be highly appreciated
cheers!