It's a bit tricky with performance. Cyclone V has way more logic elements and static RAM blocks than Cyclone III in MiSt, also it has dual-core ARM processor on the same die and fast interconnects.But as for raw performance of FPGA fabric - it's the same, moreover Cyclone V has lower max operational frequencies than Cyclone III.So Minimig core in current state will be almost the same or slightly slower in performance (slightly above stock A1200 in my case).

Will that last forever and there is no ways to optimize? Surely no. MiSTer has huge potential and it's just very beginning to discover all capabilities of SoC chip and start utilizing them efficiently. Not a trivial thing and requires significant engineering efforts and time for experiments and tests.

At the same time, significant part of codebase that was derived from MiSt is obsolete, requires rework and modernization to enable new capabilities and simplify development for cores and their support from ARM code. It's in progress.

Do you know guys, with custom Monitor driver for Workbench it's possible to make a higher resolution in Workbench Scaler used in Minimig core doesn't care about refresh rate, so it can be slower. Probably that 720HD resolution can be reprogrammed to progressive since we don't need to follow any standard. Upcoming Minimig release will have upscaling support up to 1920x1080, so Amiga resolution can be also 1920x1080 with proper monitor driver.Can anyone create such driver?

alfishe wrote:But as for raw performance of FPGA fabric - it's the same, moreover Cyclone V has lower max operational frequencies than Cyclone III.So Minimig core in current state will be almost the same or slightly slower in performance (slightly above stock A1200 in my case).

I don't know what you are talking about. Performance of Minimig on MiSTer is exactly the same as on MiST. It has nothing to do with particular FPGA chip. FPGA is not CPU - it cannot be faster or slower on particular core. This is one of fundamental difference between FPGA and CPU. As long as core compiled successfully - it works exactly the same on Cyclone II, Cyclone III, Cyclone V.

I didn't do any performance tweaks for Minimig. It's complex core and requires a lot of work and deep knowledge of Amiga HW to optimize it. ARM part is faster than MCU on MiST and work with files are faster although it's limited in core to match Amiga hardware.

There is a great improvement in video output part. MiSTer allows output high resolutions on traditional TVs. So you can use 1280x720 Monitor driver in WB and get HD resolution. MiST requires special Amiga monitor for such resolution.

Performance of core highly depends on the quality of code. FPGA is a simple sets of triggers and combinational logic. Performance depend on how it will be connected inside.Speed of FPGA cells aren't the same for different FPGA. Even the same model has different speed grades. As long as speed of FPGA is enough for particular core - it will work more or less the same. It also depends on technology thickness. Thinner technology allows to fit more cells inside FPGA but developing the cores is more complicated due to higher delays - compilation for Cyclone V is significantly longer than for Cyclone III.Well, you can find a lot of info in Internet if you would like.

alfishe wrote:But as for raw performance of FPGA fabric - it's the same, moreover Cyclone V has lower max operational frequencies than Cyclone III.So Minimig core in current state will be almost the same or slightly slower in performance (slightly above stock A1200 in my case).

I don't think the MiST has a faster FPGA than the MiSTer. It is true that the Cyclone V generation is slightly slower than the Cyclone III one. But the FPGA on the MiST is speedgrade -8 (the slowest), and on the MiSTer is -7 (faster). The speedgrade difference is more significant than the generation performance in most cases.

Sorgelig wrote:... Performance of Minimig on MiSTer is exactly the same as on MiST. It has nothing to do with particular FPGA chip. FPGA is not CPU - it cannot be faster or slower on particular core. This is one of fundamental difference between FPGA and CPU. As long as core compiled successfully - it works exactly the same on Cyclone II, Cyclone III, Cyclone V.

That's not always true. It is when the clock frequency is fixed at compilation time, the typical case in this type of cores. But it is not always like this. A core might be fed by an external clock, or the frequency of the clock might change at runtime. In those cases a faster FPGA would have a higher max frequency for a given compilation and would allow connecting a clock at a higher frequency.

ijor wrote:That's not always true. It is when the clock frequency is fixed at compilation time, the typical case in this type of cores. But it is not always like this. A core might be fed by an external clock, or the frequency of the clock might change at runtime. In those cases a faster FPGA would have a higher max frequency for a given compilation and would allow connecting a clock at a higher frequency.

There is no point to talk about FPGA usage in other area. Different tasks have different limitations. We are talking about retro emulation. I just tell that clock propagation in FPGA is not like a single wire through whole core. Fitter inserts many fixes of clock propagation delay. Sometimes it adds a delay to skip a whole cycle to meet constraints. If you supply the external clock with different frequency, it will destroy the timings and core will misbehave. While some designs may accept variable clock, it's not a general case. Core is usually compiled for specific clocks.

ijor wrote:I don't think the MiST has a faster FPGA than the MiSTer. It is true that the Cyclone V generation is slightly slower than the Cyclone III one. But the FPGA on the MiST is speedgrade -8 (the slowest), and on the MiSTer is -7 (faster). The speedgrade difference is more significant than the generation performance in most cases.

It's not correct to compare Cyclone III and Cyclone V by just speed grade. Cyclone V has finer process and cell speed is faster, but it also has higher delays in clock propagation. On Cyclone III you seldom touch any constraints and many bad programming styles are forgivable. Compilation is very fast - often around 1 minute, may be up to 5 for large projects. On Cyclone V you have to think about timings and at least basic constraints are required. Compilation is 5-10 times longer because Quartus has hard time to workaround clock delays.

Sorgelig wrote:There is no point to talk about FPGA usage in other area. Different tasks have different limitations. We are talking about retro emulation. I just tell that clock propagation in FPGA is not like a single wire through whole core. Fitter inserts many fixes of clock propagation delay. Sometimes it adds a delay to skip a whole cycle to meet constraints. If you supply the external clock with different frequency, it will destroy the timings and core will misbehave. While some designs may accept variable clock, it's not a general case. Core is usually compiled for specific clocks.

That's not correct. Most cores would happily accept any clock frequency from zero up to the maximum frequency reported by the timing analysis. Of course that the relation with external devices might be wrong (such as sound or video generation), but the core certainly won't misbehave. You can check any core. Run Timequest analysis with a different clock frequency without a recompile, and you would see timing would still be ok in most cases.

The added delays you are talking about are usually bad constrains (as it happened with the ao486 core), or issues with PLL clock delays driving an external device with a non dedicated clock output pin. Internally the clock propagation delay doesn't matter, all it matters is the skew, not the delay.

Yes, it is not very common to use an external or variable clock on retro emulation cores. But it might be possible to design a core where, say, the CPU runs at a variable frequency that the user can set at runtime. Some retro platforms have even a clock synthesizer. Anyway, it was just a generic comment on the meaning of FPGA performance.

It's not correct to compare Cyclone III and Cyclone V by just speed grade. Cyclone V has finer process and cell speed is faster, ...

I don't think it's faster. It is about the same. A smaller CMOS process doesn't necessarily means a faster device. That depends on the design of the chip. It is usually a trade off between speed an power consumption. In these cases, low cost FPGA devices, manufactures usually choose better power efficiency and not higher speed. They are not interested in faster devices that could compete with older generations of their high end devices.

But I/O cell on the Cyclone V is much slower. That's one the problems for the DRAM interface on the MiSTer. All things equal, a Cyclone III would be able to run DRAM at higher frequency.

Cyclone V is known to have high delays in clock networks. On high clocks like 50MHz and more it's common thing for compiler to insert delays skipping the whole cycle. Has nothing to do with bad design. Lower clocks usually have no problem but it has no relation to FPGA speed and Fmax.

P.S. Would be better if you would put part of your argue effort to core developing. That would be more helpful.

There is a place and time for everything and core developing is as important as these discussions because they may trigger interest in core development from new users.

At the very least, they educate people (myself included) and that is by itself a very noble purpose.

From your explanations, I understand that using the current (low cost) FPGAs, we'll never be able to attain Amiga 4000 speeds, right?

My guess it that this limitation will also apply to other cores, so expecting the MiSTer to handle newer complex cores will be unrealistic, as it will never be powerful enough to simulate machines like, for instance, the Neo Geo. We may get benefits for a Genesys/Megadrive and/or SNES core, but not much else. Would this assumption be correct?

Please excuse if some of my questions seem a little basic, but I am trying to learn more about FPGAs and their limitations for retro platforms simulation.

nightshadowpt wrote:From your explanations, I understand that using the current (low cost) FPGAs, we'll never be able to attain Amiga 4000 speeds, right?

Not 100% right. 68040/68060 speeds are achievable. At least around 30/40MHz is possible. My ZX core can run at 56MHz. The problem in Amiga is absence of 68040/68060 models. Another way to get 68040/68060 is through Hybrid emulation where CPU will be emulated on ARM side using some subset of UAE emulation while chipset of Amiga will be emulated by Minimig.We just need a capable developer to accomplish this.

FPGA on MiSTer is very under-used. It's still a long way to grow before hit the limits.

Sorgelig wrote:On high clocks like 50MHz and more it's common thing for compiler to insert delays skipping the whole cycle. Has nothing to do with bad design. Lower clocks usually have no problem but it has no relation to FPGA speed and Fmax.

(bolding is mine)

That's precisely my point. The delay added by the fitter is to meet hold time. Hold time, contrary to setup time, doesn't depend on the clock frequency. So the delay is required and will work for any clock, it is not fixed for a specific frequency.

But if the fitter is adding heavier delays on many wires, then probably there is a design or constraining problem.

P.S. Would be better if you would put part of your argue effort to core developing. That would be more helpful.

Well, to be honest, I considered porting the ST core, and time permitting, I might still eventually do it. But I am a fan of cycle accuracy.

but my meaning was different. I meant designs originally targeted for low clocks. Not for designs with high clock targets.

ijor wrote:Well, to be honest, I considered porting the ST core, and time permitting, I might still eventually do it. But I am a fan of cycle accuracy.

good intention! Start from bare porting then you will be able to tweak/redesign some parts if you know precise timings of original chips. Though current TG68K model is far from cycle perfect. But CPU can be left alone. I don't know about Atari, but Amiga had different CPUs so only few apps expected exact CPU behavior.

I find the Mister very confusing and non-obvious to setup and get working. I am trying to run the Amiga configuration. How do I setup the Amiga OS to work on the sd card? I managed to get the kickstart rom 1.3 going, but how do I install Workbench 1.3?

Obviously you need to be familiar with Amiga and Amiga OS, as it's out of topic scope.

If you want to use exactly KS 1.3 + WB 1.3, then simply load the Workbench ADF image in Minimig. KS 1.3 doesn't support HDD.For HDD usage KS 3.1 + WB 3.1+ are recommended.I forgot if Minimig supports RDB HDD initialization or not. Basically you just create a blank file with size up to 8GB and place it into SD card, then try to load it in Minimig. Load WB 3.1 install ADF disk and see if HDD Install toll sees the HDD and with correct size.

Faster (may be) way to prepare HDD is to use WinUAE.But everything (may be except initial blank RDB image) can be done on Minimig. You just need set of WB3.1 disks.

hansencj wrote:I find the Mister very confusing and non-obvious to setup and get working. I am trying to run the Amiga configuration. How do I setup the Amiga OS to work on the sd card? I managed to get the kickstart rom 1.3 going, but how do I install Workbench 1.3?

Thanks for your help.

If you are not familiar with Amiga OS here's a step-by-step tutorial about creating a minimig (and MiST/MiSTer) compatible .HDF file:

Here, the process discribes the initialization of your new virtual harddisk in order toinstall the Workbench 3.1 on it.For that, please insert your ‘Install’ adf filedisk from Workbench 3.1 as it is shown inthe following picture :

I can't find the Install.adf file anywhere.

Can someone just put a complete sd card image up on github? It would seem a lot easier for people trying to get started.

You don't need to use WinUAE to prep.You can save a lot of time by using one of the ClassicWB HDF images provided here:http://classicwb.abime.net/

Note that you will still need to provide the Workbench 3.1 disks, but the ClassicWB installer will prompt you during boot.Make sure you have the Kickstart 3.1 and all six disks of Workbench 3.1.The WB 3.1 disks are as follows:1) Install2) Workbench3) Extras4) Storage5) Locale6) Fonts

Download one of the ClassicWB files (I used the "Lite" version)Extract the system.hdf and place it in your SD card (I put it in folder Amiga).Start up the minimig core and configure it with 68020, Turbo both, 2MB Chip, 24MB Fast, AGA chipset (PAL or NTSC, your choice)-. Select the proper kickstart 3.1. Enable A600/A1200 IDE and use the system.hdf provided as Master.Make sure you have the six Workbench 3.1 files on your Mister SD card as you will need them.Once you start the minimig core it should boot right into the HDF file and just follow the instructions as to order of Workbench 3.1 disks you need.(don't forget to save your minimig config so you don't have to repeat the hardware configs again).

You can find the Workbench disks by:1) Converting the real disks to ADF2) Using them from Amiga Forever commercial distribution3) Look on the internet, they are archived by some orgs

Good luck and thanks to Sorgelig for doing all this work on the Mister project!

minimig_1.jpg

You do not have the required permissions to view the files attached to this post.

I couldn't get that to work, but I was able to purchase the Workbench files from AmigaForever. I'm starting with 1.3 and that works. This is pretty awesome. Feels like 1988, the last time I had a working Amiga.