Hardware of the Q68 and programming examples
Posted: Sun Dec 10, 2017 9:25 am
Hi all.
I have a series of questions about the Q68, so I thought it could be a good idea to put them under this thread.
Let's go !
1/ Q68 uses an FPGA.
What is necessary to reprogram it ?
I am asking that for various reasons, in particular implementing 8 bit per pixel screen modes, like 384 x 288 (overscan) or 768 x 288 (full pal, maximum a TV can take).
Also to add a few hardware registers maybe not available in what I describe hereafter.
2/ Bank switching / video DMA ?
How is bank switching achieved (in ASM, directly accessing the hardware please, not with OS call).
I ask that to be able to get vertical hardware scrolling (great for a game like Battle Squadron).
What is the maximal precision of DMA video in bytes ?
Having a whole line is good (and necessary to get hardware vertical scrolling) but the less we can get, the more opportunities it offers.
3/ Is it possible to get all addresses of hardware registers for the definition of screen modes and all DMAs ?
That will determine what we can do, hardware accelerated.
4/ There is a 25 ns high speed timer.
That is a really great feature.
How to program it ?
Is it a countdown model, where you write a value in a specific memory location, and it decreases to 0 at the frequency of 40 Mhz once you have issued a 'Go !' command ; and then intereupts the CPU to execute some code, including yours ?
Is it ultra precise (or the code to execute linked to it will execute only after the current opcode execution is complete.
Does it make the CPU enter privileged/supervisor mode or fast privileged/supervisor if it exists on the MC68000. It does on the ARM : IRQ mode vs FIQ mode ).
Having this very precise and the existence of 2/ opens the possibility of easy DMA video redirection on each scanline. (and thus effects à la Shadow Of The Beast for example, where layers of graphics are moved by DMA video redirection on each scanline, using the hardware resources, and not the CPU's).
In 50 Hz TV mode where a frame has 288 lines, to get the equivalent of an h-sync with a timer, you need it to have at least a granularity of 1/50/288=6,944.10 -5 s and here we have a granularity of 25.10-9 so it is perfect.
Is the memory address the 25 ns timer can jump to selectable ? (or is that a fixed location, where a handler will deal with a list of routines to call ?)
If yes and the code to execute can lay in the area of memory at very high speed, it means there could be enough time to reprogram the DMA video while there is flyback from the extreme right of the screen, to extreme left of the screen, to keep on drawing the current bank of memory selected as the screen to display.
Of course having a toggable on/off hardware h sync interrupt would be the best solution (no need of using the 40 Mhz timer), hence my question about reprogramming the FPGA to slightly amend the VHDL code implemented in the Q68.
Disclaimer : as I know forums can tend to be read various ways, in no way I am judging negatively the work done by the author of the Q68. I'd be happy if I could be able to do even as low as 5% of what he managed to achieve.
I 'simply' consider there could be not much to add / modify to the VHDL code to have the Q68 more games oriented, and nothing more. Believe me, as an Archie coder, I know very well what the lack of a few so easy to implement hardware features change negatively a lot of things, for games or demos ;-(
I have a series of questions about the Q68, so I thought it could be a good idea to put them under this thread.
Let's go !
1/ Q68 uses an FPGA.
What is necessary to reprogram it ?
I am asking that for various reasons, in particular implementing 8 bit per pixel screen modes, like 384 x 288 (overscan) or 768 x 288 (full pal, maximum a TV can take).
Also to add a few hardware registers maybe not available in what I describe hereafter.
2/ Bank switching / video DMA ?
How is bank switching achieved (in ASM, directly accessing the hardware please, not with OS call).
I ask that to be able to get vertical hardware scrolling (great for a game like Battle Squadron).
What is the maximal precision of DMA video in bytes ?
Having a whole line is good (and necessary to get hardware vertical scrolling) but the less we can get, the more opportunities it offers.
3/ Is it possible to get all addresses of hardware registers for the definition of screen modes and all DMAs ?
That will determine what we can do, hardware accelerated.
4/ There is a 25 ns high speed timer.
That is a really great feature.
How to program it ?
Is it a countdown model, where you write a value in a specific memory location, and it decreases to 0 at the frequency of 40 Mhz once you have issued a 'Go !' command ; and then intereupts the CPU to execute some code, including yours ?
Is it ultra precise (or the code to execute linked to it will execute only after the current opcode execution is complete.
Does it make the CPU enter privileged/supervisor mode or fast privileged/supervisor if it exists on the MC68000. It does on the ARM : IRQ mode vs FIQ mode ).
Having this very precise and the existence of 2/ opens the possibility of easy DMA video redirection on each scanline. (and thus effects à la Shadow Of The Beast for example, where layers of graphics are moved by DMA video redirection on each scanline, using the hardware resources, and not the CPU's).
In 50 Hz TV mode where a frame has 288 lines, to get the equivalent of an h-sync with a timer, you need it to have at least a granularity of 1/50/288=6,944.10 -5 s and here we have a granularity of 25.10-9 so it is perfect.
Is the memory address the 25 ns timer can jump to selectable ? (or is that a fixed location, where a handler will deal with a list of routines to call ?)
If yes and the code to execute can lay in the area of memory at very high speed, it means there could be enough time to reprogram the DMA video while there is flyback from the extreme right of the screen, to extreme left of the screen, to keep on drawing the current bank of memory selected as the screen to display.
Of course having a toggable on/off hardware h sync interrupt would be the best solution (no need of using the 40 Mhz timer), hence my question about reprogramming the FPGA to slightly amend the VHDL code implemented in the Q68.
Disclaimer : as I know forums can tend to be read various ways, in no way I am judging negatively the work done by the author of the Q68. I'd be happy if I could be able to do even as low as 5% of what he managed to achieve.
I 'simply' consider there could be not much to add / modify to the VHDL code to have the Q68 more games oriented, and nothing more. Believe me, as an Archie coder, I know very well what the lack of a few so easy to implement hardware features change negatively a lot of things, for games or demos ;-(