MiniMig with AGA

[yaqube]

Is there any performance optimimum like for the instruction cache where 16-bytes gives a significant boost, but 256-bytes only gives 7% more performance increase.

It heavily depends on application. The 16-byte cache gives significant boost because it's one line of 16 bytes and actually acts as a prefetch buffer. Data from memory are always transferred as a burst of 4 32-bit words (which gives 16 bytes). After initial transfer latency the successive words can be accessed at no delay.

Maybe prefetch could be useful ? , because every RAM-fetch from memory require a significant setup time. So reading a few extra bytes in advance might be benefitial?

It's been already done. When I added the data cache I also implemented an extra instruction cache prefetch. The speed gain is 18%.

How is compatability?

The work is far from complete but there exist some programs which work.

[yaqube]

Is there a gain in speed for hdf read/write ?

The hdf read speed has increased by 5% to 2000 KB/s.

[vidarh]

Keep the benchmark p0rn coming... I can't wait to get hold of one of these..

[NovaCoder]

Very impressive Yaqube my good man, you just beat my Blizzard Mk4 1230!

How much further to you think this can go...we need more speed dammit!



Can the clock go any higher than 28Mhz?

As you well know the main performance inhibitor in a classic AGA machine is not actually the speed of the CPU but the slow CHIPRAM access.   Because this AGA implementation doesn't suffer from this hindrance, in real-world terms (eg WB usage) how much faster will this thing be at 10 MIPS than a real AGA machine also at 10 MIPS?

[kolla]

Because this AGA implementation doesn't suffer from this hindrance, in real-world terms (eg WB usage) how much faster will this thing be at 10 MIPS than a real AGA machine also at 10 MIPS?

I just hope to be able to animate with DPaintIV AGA in 256 colours and HAM8, in fast high resolution native screenmodes (like those on Indivision AGA with Ratte's super modes) with a seemingly endless supply of chip ram :lol:

[freqmax]

Just increasing the frequency is likely not as efficient as optimizing the data flows in the m68k/32 soft-core.

[Lizard]

Latest update, the boards have been shipped back to me so I hope to get them before the weekend

There is a video of the production as well, but I haven't got it yet.
/Mike

Did you get that video yet?
Very nice to see this progressing so nicely.

[Hattig]

Just a small update. The CPU core is still clocked at 28 MHz but this time with two separate 256-byte instruction and data caches.

Oh wow, that's awesome progress. Well done! How large is the 68k core now?

[bloodline]

Just a small update. The CPU core is still clocked at 28 MHz but this time with two separate 256-byte instruction and data caches.

Your work has piqued my interest with hardware description languages... Though I don't think I will be able to get my head around it, I'll stick with microcntrollers and software

[freqmax]

.

[mikej]

"Did you get that video yet?"
No, they haven't sent it to me yet, they wanted to do some editing. I'll ask again.
/Mike

[freqmax]

I hope the boards arrive

[mikej]

"I hope the boards arrive"
I have 10 boards already on test!

[freqmax]

What's the status on the tests so far?

[mikej]

All good so far. One minor issue with the perfomance of one of the linear power regulators (LDO) is not as good as the prototype part (a different one). The reverse leakage is too high and the board will not always turn off. I have modded one board and have some different LDOs on order which should fix it.

Main power is fine, FPGA is booted and running ok so beer all round really.
/Mike

[freqmax]

What do you mean with reverse leakage ..?
Is that the only issue? ie the LDO has too much reverese leakage wich prevent the board from turning power off?