Peter wrote:My interest would be to see a new arcade game at all. As far I can remember, this has not happened for the QL in about 20 years.

The original QL was already fast enough for arcade games. So a machine which is roughly 20 times faster (Q-Top benchmark) does not technically need highly optimized sprites code for this. But working on such code could be a motivation, a starting point, to actually write a game.

As for the optimization itself: The Q68 "likes" loop unrolling. Branching is relatively slow.

The CPU cycle timer of the Q68 might help optimization. A simple way to measure delays in very high resolution. See User's Manual for details.

Well, Peter, I am not that sure the Q68 won't need highly optimized sprites code, from day one.Keep in mind with screen modes with a lot of colours, not only this stresses your CPU which has much more to move around in memory aq graphics are muxh more memory hungry , but the video DMA accesses to build your screen also reduces the overall memory bandwith available for your CPU per frame.

Furthermore, the 68000 has no facility like the ARM chip to 'fast blit' memory when memory is accessed by big chunks, linearly, where formula is number of cycles taken=4 cycles + (numbers of registers in the transfer list -1 ) cyclesConsidering what can be done on the Archie in 8 bit per pixel 320 x 256andconsidering the ARM2 delivers 4.6 MIPSandan MC68000 at 8 Mhz delivers 0.8 MIPSandin the Q68 we have the equivalent of an MC68000 at 40 Mhz, which should deliver 5 x 0.8 MIPS = 4 MIPSthen I believe yes, like for the 8 Mhz Archie, having some highly optmised code to plot (and unplot, I insist) sprites, might be really needed, from the start.The great thing is that the Q68 has this extra ultra fast RAM, of course.

I will add I have no good knowledge of VHDL, but I wonder if what Acorn implemented for fast blitting (that is, not looking for column and row when accessing chunks of memory, knowing of course next address to use is actual+4 bytes) couldn't be implemented in the MC68000 FPGA core, too ...

I think the 68K core in the FPGA also runs some instructions faster than it's silicon fabricated ancestor. I was looking at the T68K vhdl code and trying to compare timings with those published for the 68000 series...

I have only provided a few examples and basic infos. Maybe you can search the forum and save me from repeating.I have no comprehensive list of timings, and it depends on memory as well as on CPU. The QL doesn't have such info either.Unlike the QL, the Q68 has a good tool for measuring.

-> Zarchos: As I already pointed out, the CPU on the Q68 is much faster than 68000 at same clock. Also, in the relevant resolutions of 512x256 or 512x384, highcolor doesn't slow down the system significantly. The issue is getting an arcade game at all.

This is great Peter, in particular if the faster than expected opcodes are the ones accessing memory.I am really impatient to get the beasties and experiment.And yes you had already specified only high resolution screen modes slow down the Q68.Sorry for the waste of time.

Peter wrote:CPU access to the normal SDRAM memory is not particularly fast, as it is random access. You can expect about 100 ns per 16-bit word. (No CPU cache, therefore burst access only for video.)

When I read that I can tell you definitively we'll need fast plotting and unplotting routines for the Q68, to get great and fast arcade games.We are facing the same issue the Archie has to face, too. ( If you want to get 50 fps action games, and not 25 fps ).On the Archie where you do everything 100% software ( like on the Q68 ), using the CPU, at 8 Mhz CPU and bus, 1 cycle is 125 ns.But there is this 'fast blitting' when loading (LDM opcodes) or storing (STM opcodes) multiple registers, where each loading of 1 register (32 bits), or each storing to memory, takes only 1 cycle, after the initial manipulation of the 1st register in the transfer list (taking 4 cycles).You can see with this figure that the Q68 (when using normal SDRAM) will be faster in some cases, and slower in other cases, compared to the Archie.To access 32 bits the Q68 takes 2 x 100 ns = 200 ns ;and on the Archie it takes 125 ns ( but with a big penalty of 4 x 125 = 500 ns for the 1st 32 bits ) ...The Q68 has a neat advantage when handling a few pixels ('starfield' ?, who said 'starfield' ?), and then afterwards, no more.Still I strongly believe the Q68 has the ability to have great, fast, 50 fps arcade games.The fast RAM area can really bring a lot to boost critical algos, its best, optimal usage will be the key to get great results.The machine deserves better than Amstrad CPC games with more colours : that's the Amiga 1200 games the Q68 should be looking at.I have just checked the screen modes the Q68 offers.There are no 320 x 256, 8 bit per pixel colour screen modes, but either 8 colours, or hi res modes, so I believe having 50 fps action games with moving background will be difficult, but at 25 fps ok ; on the other hand a lot of great games, in hi res and hi colour modes, with static background, at 50 fps should be doable.Very exciting !