exxos's Atari, Amiga & retro forum

exxos wrote: 06 Aug 2019 11:11 ... we are not stupid!

Apologise if I appeared wanting to imply that and assure you: I didn't!

The problem (and advantage) of FPGAs is that you do not have access to raw silicon as the original blitter designers had. On raw silicon, there are possibilities you do not have on FPGAs (or you are at least not supposed to do unless you are asking for a lot of trouble), you are basically restricted to clean, synchronous design (you can't reliably design a delay based on gate propagation delays, for example).
Besides that you are restricted to the properties of the 'ingredients' the FPGA designers decided to put into your specific chip. You simply can't use any logic they didn't put on the chip upfront.

Bottom line is: you can't implement everything on FPGAs that you can on raw silicon.

But there is a workaround. You usually can implement a logically equivalent circuit with a clean synchronous design.

What we are doing as a next test is to run the core on 32Mhz and clock the state machine from the ST's 8MHz clock. Likely the 32MHz clock can be even 50MHz and it probably won't matter. It probably doesn't matter to much how fast the core runs internally as long as its external timings to the ST's clock remains in sync at 8MHz. The suska code seems to have a pretty good state machine coded in, so it shouldn't matter if the 2 clocks are out of sync to eachother.

Icky has the only board at the moment. So hopefully he will have time later tonight to try it out :)

Amazed at how much work has gone into this so far! Also super impressive to see the new STF boards too. Didn't realise how much I had missed!

GadgetUK164 wrote: 23 Aug 2019 17:33 Amazed at how much work has gone into this so far! Also super impressive to see the new STF boards too. Didn't realise how much I had missed!

Yes lots of awesomeness being created by our great community :)

We haven't forgotten about this project. There have been many other projects getting in the way.

Recently we have managed to get the Blitter speed up to 71% by modifying wait states but we are encountering some screen corruption and are still trying to figure the whole thing out.

When its running the test the corruption looks like this

Icky wrote: 11 Oct 2019 20:29 Recently we have managed to get the Blitter speed up to 71% by modifying wait states but we are encountering some screen corruption and are still trying to figure the whole thing out.

Did we get it higher at some point (aside form the corruption ? )

It seems to be a double-edged sword, make it run faster to get the proper speed there and get corruption, or run it at half speed and don't get corruption... Cannot seem to win :roll:

exxos wrote: 11 Oct 2019 21:07 Did we get it higher at some point (aside form the corruption ? )

The fastest we got it to was 86% but that was when we clocked the Blitter at 16MHz.

This is the fastest we have got it running on stock (8MHz).

Icky wrote: 11 Oct 2019 21:10 The fastest we got it to was 86% but that was when we clocked the Blitter at 16MHz.

This is the fastest we have got it running on stock (8MHz).

What happened when you clocked it at 32Mhz ?

exxos wrote: 11 Oct 2019 21:17 What happened when you clocked it at 32Mhz ?

Didn't work. As soon as you turned on the Blitter it froze.