I'm using the Prodigy crack (probably a good idea to specify which crack when using ADFs so we can compare like-for-like) - and with Fast RAM enabled it won't boot beyond the cracktro. There's a quirk with the Minimig's Fast RAM in that it disappears immediately after a Guru, and comes back after a subsequent soft-reset - so with Aladdin, the sequence is:Boot with Fast RAM -> Cracktro -> crash -> Fast RAM disappears -> boot -> Cracktro -> gameThen the game runs OK.

Yes, Prodigy crack with +3 trainer in my case too.Configuration is 68020 CPU, 2MB chip, no slow and 2MB fast memory.In my case it loads fine, no crash after cracktro, runs one time through the demo and crash upon return to the menu.It might take a few more demo runs, but crashes shortly anyway.

Without fast memory demo could run much longer (and it runs noticeably slower), about an hour, but crashes all the same in the end.

Quote:

Again, the prodigy crack, and yes I can reproduce this. With Fast RAM enabled it boots, goes into attract mode, but seems to crash on returning to the menu.

Tried both prodigy +15 and melnok +3 variants, the same config (2 MB chip, no or 0.5MB slow and 2 MB fast), just the same as yours result.

Interesting that non-AGA design works just fine with the same options, so the memory problems is mostly related to latest AGA v1.2 release.

So my DE1-SoC port is works almost as the original Minimig-Mist AGA

Quote:

A tiny change in a completely unrelated part of the core can be the difference between Fast RAM working and not.

Yeah, changes in the working FPGA temperature is the cause also.This is a result of badly written hardware, multiclocked design without proper constraints.And I`am don`t know how to constraint it correctly either...

A tiny change in a completely unrelated part of the core can be the difference between Fast RAM working and not.Yeah, changes in the working FPGA temperature is the cause also.This is a result of badly written hardware, multiclocked design without proper constraints.And I`am don`t know how to constraint it correctly either...

Constraints are one way to do it right, better is to change the Instruction Decoder of the tg68K. To many logic levels and loops in there,which drive the synthesizer nuts. So the synthesizer tries to make it with the given clock, and fails

Tried to look into it a year ago, but had to stop, day job got in the way and to much traveling.

Now got myself an DE1-SOC and some Xilinx Artix boards, (BTW, Xilinx tools have the same problem with the tg68k core),and hopefully some time

Constraints are one way to do it right, better is to change the Instruction Decoder of the tg68K. To many logic levels and loops in there, which drive the synthesizer nuts. So the synthesizer tries to make it with the given clock, and fails

Yeah, the problem is that with the clkena signal asserted only one cycle in 4 or 5, it's fine for some of those combinational chains to take 4 or 5 clocks to propagate, but it's extremely difficult to tell the tools which ones, and which ones have to be fast.

I did get the TG68 to run at a lower clockspeed in another project (without having to slow down the SDRAM controller) and managed to achieve timing closure, and also had the Minimig core using a similar arrangement - but the latter was still not even close to meeting timing.

sonycman wrote:

So my DE1-SoC port is works almost as the original Minimig-Mist AGA

Yup - great work!

Quote:

Yeah, changes in the working FPGA temperature is the cause also.This is a result of badly written hardware, multiclocked design without proper constraints.And I`am don`t know how to constraint it correctly either...

Of course I do, without that even old non-AGA minimig did`nt work correctly on DE1-SoC.The latest AGA core also have very good constraints for sdram and some other clocks.But it seems that is not enough.

This is bad I don`t know how to debug amiga side software - if only we have some kind of debugger to see memory contents and disassembly from 68k side.That HRTmon - what is it, exactly?

Not really related, but I have noticed vast differences in behaviour of my MIST depending on what power supply I use.

The you have really bad power supplies lying around

Yes, it seems that most 5V USB chargers tend to have a quality drop after a while, still good enough for charging batteries (albeit slower), but not good enough to keep the MIST (or a Raspberry pi for that matter) running well.

Yes, it seems that most 5V USB chargers tend to have a quality drop after a while, still good enough for charging batteries (albeit slower), but not good enough to keep the MIST (or a Raspberry pi for that matter) running well.

I'm ****** for years now, that a 5V external power supply is not a wise thing to to, in powering a 5V board.And I'm glad, the newer eval boards are using 9v or 12V. It is few bucks more for the power supply,but it is really worth it. Less problems, less thing to explain.

And somehow the newer "5V" power supplies are getting towards 5.2V or 5.3V to charge faster, more reliable on USB.So they are getting dangerous for 5V boards ...

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum