Minimig (Amiga) core discussion

[MartinW]

...

[Sorgelig]

I personally think the existing memory is plenty.

Why don't try to understand my message before commenting? I didn't talk about expanding memory for Minimig.
It's for other cores.

[apolkosnik]

Currently, only Minimig core doesn't work with 64MB SDRAM module.
I'm not talking about supporting the whole 64MB RAM, but about the timings.

The problem is timings....

Everything in Minimig will work slower at the same amount, approximately 2.5%.
Wonder what ppl think about it.

While I'm a newbie here, I think that this might be the right thing to do until somebody comes up with a better fix. Thanks for your amazing work on this project!

[SuperBabyHix]

Everything in Minimig will work slower at the same amount, approximately 2.5%.
Wonder what ppl think about it.

I can't imagine that a 2.5% difference would even be noticeable. Isn't that how many software emulators and some other fpga clones maintain HDMI compatibility, by slightly speeding up or slowing down the emulation?

I assume this slightly slower version would still work on 32MB modules? Maybe you could put out a test version for people to see how noticeable it is and if it effects compatibility any?

Just my 2 cents.

[MartinW]

...

[R4MS]

Wasn't the main frequency somehow correlated to the frame rate? At least NTSC and PAL have different clock speeds. Could therefore lead to some glitches in the video output, in particular VGA.

I think it would not be hard to use the additional 32MB as fast RAM. But I doubt that there is any core right now, which could make good use of 64MB.

[Sorgelig]

For the project lead I can’t believe how damn rude you can be!

Sure! I can be rude if you think it is, especially if commenter ignore my words like empty place leading to completely other direction than what i've wrote. I wrote "it's not about adding 64MB memory to Minimig." - you completely ignore it. Can i treat you as rude then?

Wasn't the main frequency somehow correlated to the frame rate? At least NTSC and PAL have different clock speeds. Could therefore lead to some glitches in the video output, in particular VGA.

Yes, everything slower including frame rates. I'm still exploring other possibilities to shave the 114MHz clock without changing 28Mhz.
Current clocking is a mess in the core...

I think it would not be hard to use the additional 32MB as fast RAM.

Sure, adding the whole 64MB for Minimig is not a big problem. It's just a matter of adding another virtual RAM expansion board. It's just not important for Minimig.

But I doubt that there is any core right now, which could make good use of 64MB.

It's hard to make the cores for bigger memory without having this memory. NeoGeo for example is one of such core.

[THaase]

As far as I know the Amiga is less time critical as others, nevertheless I‘m not sure if this will not cause any side effects.

Maybe it’s possible to the the 64MB run at 114.75.
Can you share some Informationen what you‘ve tried?
4-layer or 2 times 256MBit or just a 512MBit on dual layer?

I (personally) would prefer 4 Layer Board over lowering the master clock.

[Sorgelig]

As far as I know the Amiga is less time critical as others, nevertheless I‘m not sure if this will not cause any side effects.

It's opposite. Minimig core is more time critical than many other cores. It uses 114MHz on TG68K core which never supposed to work on such clock. And in Minimig using 114MHz on CPU is quite useless and give very little advantage as almost any read/write operation is constrained in most cases by 7MHz, sometimes by 28MHz. TG68K is designed the way when most operations are done as quick as possible - sometimes in 1-2 CPU clocks. So it waits a lot wasting the 114MHz cycles.

But it seems i've succeeded to reduce amount of cycles in SDRAM controller, so it takes 4 less cycles than before. It allows to switch from 114MHz to 86MHz without touching the 28.6875MHz master clock.
In SysInfo the number is 12.70 instead of 12.93 which is not a big loss. 86MHz should give much more stability to the core. On 114MHz it suffers from instability and some builds are unstable.
It still needs more testing to make sure it works fine.

[Sorgelig]

Maybe it’s possible to the the 64MB run at 114.75.
Can you share some Informationen what you‘ve tried?
4-layer or 2 times 256MBit or just a 512MBit on dual layer?

I (personally) would prefer 4 Layer Board over lowering the master clock.

64MB board is the same as 32MB. Chips share the same pinout and even work the same from programmer's point of view (unless you use full page burst).
Some time ago i've experimented with 4-layer board and got no benefit from it. It only makes board more expensive - nothing else.

[THaase]

Sorry, with citical I meant in regard to SW running on the Core not the FPGA generation.
Will be more precise next time.

But as you‘ve been able to lower the clock I think this is the best solution.

[Sorgelig]

If i remember correct Fmax=30MHz for TG68K. So you can imagine how much it was "overclocked".

[onaryc29]

Very difficult question: on one hand i would love to have to neogeo core with maximum game working, but mister is the best amiga i have ever owned. If lowering clocks does not affect ecs/ocs/aga games i can live with it, but changing all the clocks will break things don't they?

[Sorgelig]

Very difficult question: on one hand i would love to have to neogeo core with maximum game working, but mister is the best amiga i have ever owned. If lowering clocks does not affect ecs/ocs/aga games i can live with it, but changing all the clocks will break things don't they?

My original question is not valid any more. I've fixed it already.

[BBond007]

My suspicion - the thing that will have the biggest impact is if the HDD access slows down any because it already feels slow (which is always a thing on Amiga’s not just MiSTer!)

Maybe budget Amigas with Gayle chip PIO IDE, but certainly not big box Amigas with SCSI...

[sawf01]

I think the trade off is worth it if compatibility is improved.

[onaryc29]

My original question is not valid any more. I've fixed it already.

ok, perfect Except for specific fix like yours, is there someone working on the minimig core? (It seems there is nobody)

[Sorgelig]

There is no dedicated developer for Minimig. Everyone in Amiga community who can do anything is doing commercial projects only.

[onaryc29]

yeah, i can understand that people want to compensate the hours spent on this kind of project (hardware and software) but it is too bad that this knowledge will be gone once there would not be any commercial interest.

[R4MS]

I think the main problem of minimig is that WinUAE is just too good. If you are only interested in running old software, that's your best (and cheapest) choice.
I plan to spend some more time on minimig in late fall (RTD...) . In the warmer months I use most of my spare time for outdoor activities.

[Sorgelig]

R4MS,
question to more knowledgeble in Amiga HW than me:
Is there any reason why cache is disabled for ChipRAM/ROM besides the bug in cache controller?
I think i've fixed the problem with cache and it should work fine with updates from chipset side.

[Sorgelig]

20190711_011532.jpg

[onaryc29]

i never really was able to have to result of minimig/mister :
* the winuae filter/video options are, imho, a mess
* it can be difficult to have 50hz refresh rate

Winuae is great, but minimig/mister is very simple to use and the output (with ascal) is perfect without much hassle.

[R4MS]

I haven't felt the need to upgrade from my A1000 back in the days, so I'm not at all an expert in A1200 hardware.

The obvious reason to disable the cache on chipram would be that there is no reliable way to mark it dirty. Also, chipram and kickram access can be routed through the chipset or directly from tg68k (turbochip, turbokick). Those will arrive at sdram_ctrl through different channels (chipX and cpuX). Maybe that caused a problem at some stage during the development of minimig. If you address both problems, I see no reason why there would be the need to turn of the cache.

[Sorgelig]

Original code haven't finished cache update from "other" side. So i've finished it. Now any update of RAM from chipset side will update the cache as well.
Because 64MB chip has 16MB per bank (unlike 32MB having 8MB per bank) there is a 8MB chunk in additional 32MB FastRAM laying in the same bank as ChipRAM so a bit slower. I think with cache enabled for ChipRAM the difference won't be noticeable for this 8MB chunk.