Experimentation with Adafruit ItsyBitsy M4 board

Discuss anything not related to the current Uzebox design like successors and other open source gaming hardware
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by mast3rbug »

I understand the Global Idea, but you still have to construct all that on the top of a precise timed Audio/Video frame. This is exactly the same as my Videogame console on my atXmega and the one I'm building on the ARM. the two are "kind of" complatible by software source code. Only the speed and software lenght is different at some point. But I had to build the Audio and Video kernel and this is not an easy task if you want the final user to drive it in a transparent way from the top layer. My two videoconsoles use simple directives, draw line, draw Dot, putPicture to Screen, backup zone, restore zone, move sprite, start music, play Sample number X when button is pressed. So I'm not sure to understand the difference between the way you want to build a video frame buffer and the way used in all actual consoles. You will still have to build all that in synch with precise timing and the only way to do it is with imagination and the available ressource on the actual Chip you use.
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by Jubatian »

The Game Kernel in my case is not without well-defined constraints. One is the minimal ARM specs which I aim for (and eventually probably will get onto actual hardware, until then, the BitBox driven at an appropriate clock would suffice). This minimal spec is 12 * NTSC colorburst clock (~43MHz), 2730 cycles / scanline, and an ARM Cortex-M3 core. The video modes supported by the Game Kernel will be designed to take at most 2500 cycles assuming reasonable code generation from C (I will provide ASM samples for the critical parts as to what should be expected), with the video mode code placed in an appropriate cache or memory so it can run at full speed (no bus conflicts between code fetch and data operations). Of course these are only critical when you actually ran it on an ARM clocked at 43MHz.

The game is ran in VBlank (like Uzebox), for that, similarly in accordance with the minimal ARM specs, the upper bound of cycles will be defined (somewhere around 100000 clocks). This limit will be applied by the emulator which I will write for it, of course not totally exact, but a good baseline to see whether the game ran well on the low-end.

If you were clocking the ARM at a different frequency, you could still just run it, more time remaining for whatever you need to do to support your peripherals, such as USB host on the BitBox. The display update frequency is necessarily 60Hz, but the actual count of lines could vary (you could apply scandoubling, like necessary on the BitBox for VGA, which has it implemented proper), the audio is not bound to the line frequency (you can provide it the number of samples you consume during one video frame, and it will render accordingly, again the minimal spec is there, I aim for 31KHz on the 43MHz baseline).

So what sure this isn't is some system on which you could run beefy, very computationally intensive games. But I need that limitation for emulation, it is among the goals to have it preferably performing better than CUzeBox is capable to in browser.

(Emulation is actually a good point here: the emulator is an extreme example of not running the stuff at tight real-time at all, yet potentially providing an adequate game experience. The key is sequencing, that the sequence of events need to be maintained, the order of the video scanlines, the provision of the audio buffers, the user VBlank time, even on an actual ARM you may decide to do some more loose timing by providing for example 10 scanlines of DMA buffer for video, such as to allow for servicing demanding USB events in real-time without impacting video)
Post Reply