exxos's Atari, Amiga & retro forum

Icky wrote: 16 Oct 2022 08:31 @ijor was this core on real hardware or was it on something like the MiST / MiSTer etc?

That was running on MiSTer. I don't have adapters to run FPGA cores on original hardware. It still shows that the core is cycle exact.

exxos wrote: 16 Oct 2022 09:54 Was just wondering that as well. GB6 is showing as a STE , IIRC @ijor yours wasn't a STE chip set ? which is one reason I was using suska cores as well.

My main cores can do both ST and STE. The Blitter core is indistinct, can run on either system without modifications. The benchmark was performed on STE mode, only because I had not reference for ST that included Blitter. As far as I can see, Gembench distribution doesn't include any MegaST or ST reference with Blitter. The only reference tests with Blitter that I had were all STE.

I guess we could be running into a terminology issue here as well. As cycle accurate may well be true for mister etc but when I mention cycle accurate, it mimics a real chip, which to my knowleage nobody has tested the cores in a real machine @ijor ? ... Can your cores deal with wakeup states from a real chip set or are they all fixed for mister ?

I don't think there is a terminology issue here. Cores are cycle accurate or they are not. However, some cores are releases to interface with a whole SOC/FPGA system, like MIST or similar. If you want to use such a core as a replacement for a real individual chip, you need to add some logic, or depending on the hardware implement some modifications. If you don't implement this correctly, you might break the timing.

My main system core can be configured for any wakeup state, it is not fixed. The Blitter and the other cores support all wakeup states. Anyway, I doubt the problem here is about wake states. This might be a problem with full screen demos, not with the benchmark. Btw, I'm not sure your problem with the Suska cores is wake states either. The main problem with the Suska cores is that they are not cycle accurate, let alone wake states issues. They were never designed to be cycle accurate. As far as I know this was never Wolfgang's goal.

Possible we might have screwed up something, but what ?

I can only assume that when you adapted my core to your hardware, the core modifications you implemented messed with the timing and cycle accuracy got broken. From the timing difference sounds like an extra cycle was introduced at the DMA handshake.

Send me the Quartus project folder with my modified core, and I'll probably should be able to find the problem.

ijor wrote: 16 Oct 2022 17:45 I can only assume that when you adapted my core to your hardware, the core modifications you implemented messed with the timing and cycle accuracy got broken. From the timing difference sounds like an extra cycle was introduced at the DMA handshake.

Send me the Quartus project folder with my modified core, and I'll probably should be able to find the problem.

I'm not sure if I even looked at your core personally. @Icky may still have it, but assume not after all this time. IIRC @Icky has a few versions of the suska core as he was experimenting with a lot. I know I was looking at the code suggesting things, but don't remember much after all this time.

Probably best let him get a working setup first and let him get your core running again and take things from there.

exxos wrote: 16 Oct 2022 20:57 Probably best let him get a working setup first and let him get your core running again and take things from there.

Ok. Let me know.

Btw, just out of curiosity. What FPGA devices are you using?

ijor wrote: 17 Oct 2022 00:32 Btw, just out of curiosity. What FPGA devices are you using?

Image of the chip here https://www.exxosforum.co.uk/forum/view ... 320#p52684

OK, finally got my test rig up and running. Had a few issues with sorting out the connectors so I could test an original BLITTER and the FGPA ones.

So, the plan of action before we start to diagnose the issues is to run and post some tests and differences so we have references to start with.

• Run GEMBench on original stock machine with BLITTER as a benchmark
• Run GEMBench on the same machine each core in its current state to compare
• Run @Cyprian's test prgs on stock and FPGA cores to post differences

I should be able to get these done in the next day or so, then we can go from there.

exxos wrote: 17 Oct 2022 13:33 Image of the chip here https://www.exxosforum.co.uk/forum/view ... 320#p52684

Thanks. I'm not sure it is a good idea to use that particular part at this development stage. But now with the chip shortage it is difficult to find any FPGA at all :(

Icky wrote: 20 Oct 2022 12:37 OK, finally got my test rig up and running. Had a few issues with sorting out the connectors so I could test an original BLITTER and the FGPA ones.

You want to run an original Blitter in the very same machine? Do you suspect there are hardware issues?

ijor wrote: 21 Oct 2022 17:49

exxos wrote: 17 Oct 2022 13:33 Image of the chip here https://www.exxosforum.co.uk/forum/view ... 320#p52684

Thanks. I'm not sure it is a good idea to use that particular part at this development stage. But now with the chip shortage it is difficult to find any FPGA at all :(

We have been using these for other chip recreations just fine and have a small stock of these.

ijor wrote: 21 Oct 2022 17:49

Icky wrote: 20 Oct 2022 12:37 OK, finally got my test rig up and running. Had a few issues with sorting out the connectors so I could test an original BLITTER and the FGPA ones.

You want to run an original Blitter in the very same machine? Do you suspect there are hardware issues?

No hardware issues, however we are dealing with real hardware here and we need a bench mark to compare against. Definitively running real hardware test programs on both original blitter and a FPGA one will help to see if they are indeed matching or something is out. In fact as we progress having other test programs or suites would be good.

Icky wrote: 21 Oct 2022 18:26 We have been using these for other chip recreations just fine and have a small stock of these.

I meant mainly for developing purposes. I would probably use a much bigger FPGA. Might probably cost just around $20 more or so (at normal pre chip shortage prices).

No hardware issues, however we are dealing with real hardware here and we need a bench mark to compare against. Definitively running real hardware test programs on both original blitter and a FPGA one will help to see if they are indeed matching or something is out.

Yes, of course. I thought you wanted to run the original Blitter and the FPGA core in the very same computer. And you don't need that for this purpose, you can compare the tests results between one computer running original Blitter, and another (real hardware) one running the FPGA core. Or I miss something?

ijor wrote: 22 Oct 2022 00:45 Yes, of course. I thought you wanted to run the original Blitter and the FPGA core in the very same computer. And you don't need that for this purpose, you can compare the tests results between one computer running original Blitter, and another (real hardware) one running the FPGA core. Or I miss something?

Not sure I follow what you're saying.. The real blitter is tested and GB6 is calibrated for that system. Using a different machine is adding a bunch of unknowns. Different clock speeds across machines cause variations in tests. So the same machine has to be used for a original blitter, and then swapped for the FPGA blitter. If the scores are not 100% then something is wrong with the thing. This all has to be done in real original ST hardware otherwise it's not a fair comparison.

exxos wrote: 22 Oct 2022 18:11 Not sure I follow what you're saying.. The real blitter is tested and GB6 is calibrated for that system. Using a different machine is adding a bunch of unknowns. Different clock speeds across machines cause variations in tests. So the same machine has to be used for a original blitter, and then swapped for the FPGA blitter. If the scores are not 100% then something is wrong with the thing. This all has to be done in real original ST hardware otherwise it's not a fair comparison.

I beg to differ but I disagree … I was going to elaborate, but honestly, I'm not sure this is the right place for a debate about testing methodology. Probably not a very useful debate at this time, since testing in the very same machine can't hurt, and if I understand correctly, Icky is already ready to perform the tests. So, unless you insist I elaborate, I suggest we better see first the tests results.