MiSTer FPGA Forum

I'm trying to get actual A1200 68EC020 performance, but it seems to be around ten times that LOL

Is there any way to clock the CPU at the actual 14MHz?

I don’t think there’s a way to lock the processor speed for the ’020 implementation of the core.

As far as I know, the ’020 in the Minimig core is not cycle accurate, so even if there was an option to lock it to 14MHz, it wouldn’t be entirely accurate there either. (Note that these are my own inferences that may be wrong, I haven’t actually looked into it beyond what I have read on the forums about the Minimig core and its 68000 and 68020 implementations)

What are you trying to accomplish?

There are some cache options you can disable, which will slow it down quite noticeably. I think it's still faster than a real 1200, but not as much.

@limi Something that feels more like an A1200 than a fantasy box. LOL

@Malor At least with SysInfo, I saw zero performance difference with DCache on or off - go figure.

rhester72 wrote: ↑Wed Jan 11, 2023 11:32 pm

@limi Something that feels more like an A1200 than a fantasy box. LOL

@Malor At least with SysInfo, I saw zero performance difference with DCache on or off - go figure.

The Minimig core on MiSTer is slower than other solutions around like vampire for example due to the TG68K CPU module.

@Armakuni I don't want Minimig faster, I want it slower! LOL It feels entirely unnatural as an A1200.

I agree, a speed limiter (in lieu of cycle accuracy) would be great. More authentic experience is one reason, but it also could possibly help with WHDL games which might be glitching due to the extra speed.

I’m not sure if it does anything but on an a1200 using commodore kickstart you can hold both mouse buttons on power up to get into a hardware menu to disable cache.

No idea if that will do anything to the emulated cpu but may be worth a shot.

rhester72 wrote: ↑Mon Jan 16, 2023 6:35 pm

@Armakuni I don't want Minimig faster, I want it slower! LOL It feels entirely unnatural as an A1200.

I only use the Minimig core with MegaAGS, so the it's not really noticeable. It was purely a game machine for me

akeley wrote: ↑Tue Jan 17, 2023 4:54 am

I agree, a speed limiter (in lieu of cycle accuracy) would be great. More authentic experience is one reason, but it also could possibly help with WHDL games which might be glitching due to the extra speed.

The TG-68k CPU module used for 020 AGA is not cycle accurate anyway. The glitches my be due to this no matter the speed

throAU wrote: ↑Tue Jan 17, 2023 8:36 am

I’m not sure if it does anything but on an a1200 using commodore kickstart you can hold both mouse buttons on power up to get into a hardware menu to disable cache.

No idea if that will do anything to the emulated cpu but may be worth a shot.

No...I tried. The CPU running at 12x intended clock is the issue. LOL

There are a lot of WHDLoad games glitches, sound hickups, games that starts and quit (games that runs fine on real hardware). I wonder why the 68020 CPU for the Minimig Core was designed that way. It there a reason for NOT implementing the accurate speed, i mean from "real world" Amiga CPUs? I guess bulding a 100% cycle accurate 68020 isn't that easy to do, but in combination with this speed it seems the problem here for timing critical stuff like WHDLoad patched games.

I also seemed to run into some timing problems when fixing the games that have Roland MT-32 support (used in MegaAGS, which uses the 68020).
With a few of the games, data sent to the mt32-pi got corrupted. Possibly because the code was relying on the slowness of the system. Though an actual 68020 might already be too fast in this particular case.

Retro-Nerd wrote: ↑Tue Jan 17, 2023 4:18 pm

There are a lot of WHDLoad games glitches, sound hickups, games that starts and quit (games that runs fine on real hardware). I wonder why the 68020 CPU for the Minimig Core was designed that way. It there a reason for NOT implementing the accurate speed, i mean from "real world" Amiga CPUs? I guess bulding a 100% cycle accurate 68020 isn't that easy to do, but in combination with this speed it seems the problem here for timing critical stuff like WHDLoad patched games.

Probably because doing a cycle-exact 68020 would be a massive undertaking.

Software emulators usually don't have much trouble with this kind of thing; they can compute the effective results of an instruction, and then simply delay implementing the resultant chip-level changes until the actual chip would be in that state. But when doing it with FPGA, it's just circuitry, and for cycle accuracy, it usually has to accomplish the task the same way the original CPU did. As far as I know, however, nobody has published schematics for the 68020. Possibly nobody left alive remembers the internal implementation details anymore.

Getting the circuitry to accomplish the same tasks as the original chip is already very difficult in FPGA; getting all the instructions running in synchrony with the original is goddamn rocket science. It's not like there's a magic chip fairy that makes this shit work, it takes extremely tedious, painstaking effort.

It's probably not going to make that much actual difference, however, as by the time the 020 was common in the Amiga world, very few programs depended on exact CPU timings anymore. They depended on CPU instructions, but if those instructions didn't operate at the precise expected speed, it was hardly ever a problem. Everyone knew about 030s and 040s and just stopped imposing hard timing expectations on the CPU.

The WHDLoad hiccups and bugs are probably because the CPU instructions are doing something wrong, not that they're at the incorrect speed. The bugs could also be in the AGA emulation. Apparently the A500/OCS emulation is pretty much perfect, so experimenting in that mode might help with figuring out where the bugs are. Things that still break in A500 mode probably break on real hardware, too.

Yeah, could be both CPU and AGA chip related. I've read about the missing schematics for the 68020 on EAB. Same goes for some AGA features iirc.Toni Wilen uses logic analyzer to investigate things that he can't understand in the original hardware (and then try to implement in software). But i guess this won't help here, after what you just wrote about FPGA stuff. A shame that we can't preserve the newer Amiga models with 100% acurracy.

I think Toni Wilen is a she.

It's likely possible to make a cycle-accurate 68020, it's just really hard, and nobody's done it yet in FPGA. AFAIK the cycle accuracy is perfect in WinUAE, and it's got a low-latency "beamracing" output to minimize lag, so that's probably the best spot for full accuracy of later models.

It would be nice if the Mister was that good, but that may be a long way off. We don't even have CD audio working yet.

LOL, no. Toni definitely isn't a woman. He's from Finland, probably not an unusual name there. But i would love to read his reply about your comment. He can be a bit "special" at times.

I checked a few problematic games with a 68020 and ECS chipset config. Works indeed a bit better. And yes, after real hardware WinUAE is the best option for the newer Amiga models.

edit: There is a trap though which can cause trouble in some games. Never thought of it. Don't use the quitkey=S11a (quit via CD32 controller buttons combination) option for specific WHDLoad patched games. Midnight Resistance crashes after the title screen, and Lionheart flickers like hell. Normal keyboard quitkeys are fine though. Caused me some headache the last 2 days.

WinUAE's 68020 is still not perfectly cycle-accurate and likely will never be. The latest release improved (pedantic) accuracy overall by leaps and bounds across the board (because it was Toni's singular focus for that release), but the proper cycle-level timings in edge cases just aren't known, and to the best of my knowledge can't even be derived from bench testing due to the hellish number of possible permutations.

That being said, I think we can surely do better (for those of us looking for a more period-correct experience) than a 110+ MHz implementation. laughs

Toni Willem himself has said several times that a cycle-exact/cycle-accurate 68020 can´t be done with nowadays information available.

The last time I was really using Minimig, the 68020 was pretty slow. It felt fairly accurate, much slower than WinUAE with an emulated 68040. I was playing XCom, and the globe rotation was quite sluggish, where it was pretty snappy under WinUAE.

That reference to 110MHz doesn't match my experience at all. Has something changed?

Yeah, pretty fast for a 68(EC)020 CPU.

It’s not really 68EC020 anymore when it handles hundreds of MB with RAM.

Retro-Nerd wrote: ↑Fri Jan 20, 2023 3:43 pm

Yeah, pretty fast for a 68(EC)020 CPU.

"MOTOROLLIN' "

kolla wrote: ↑Sat Jan 21, 2023 12:38 am

It’s not really 68EC020 anymore when it handles hundreds of MB with RAM.

32 bit processor = 4gb of memory... So, hundred of MB? Easy...

Hodor wrote: ↑Fri Jan 20, 2023 10:32 am

Toni Willem himself has said several times that a cycle-exact/cycle-accurate 68020 can´t be done with nowadays information available.

Cycle exact is rarely needed, very few of the CPU implementations used in MiSTer have that level of accuracy. We could definitely achieve something far closer than what we have now.

What is the actual problem that is causing a need for a slower 020 implementation? I have not noticed any issues with it, but I have not looked much for them either. If there are some examples it would make it easier to try to debug it and figure out what actually causes it and whether its the speed or the cycle accuracy. I doubt its the speed itself. If it is, then its badly made software I would argue, the same way old DOS software just did not try to take into account that future CPUs would be more than 10x faster.

Which is still a compatibility issue, but what A1200 software needed something the exact speed of the 020 rather and still leave the 68000 too slow? The 68000 option is there to have compatibility with the software that generally might have that kind of compatibility issue after all.

I don't know if the speed is actually the problem, could be part of it. There was never a real world Motorola 68020 CPU with 100MHz. Even on good turbocards the CPUs weren't that fast.

Retro-Nerd wrote: ↑Tue Jan 17, 2023 4:18 pm

There are a lot of WHDLoad games glitches, sound hickups, games that starts and quit (games that runs fine on real hardware). I wonder why the 68020 CPU for the Minimig Core was designed that way. It there a reason for NOT implementing the accurate speed, i mean from "real world" Amiga CPUs? I guess bulding a 100% cycle accurate 68020 isn't that easy to do, but in combination with this speed it seems the problem here for timing critical stuff like WHDLoad patched games.

TG-68K was the only open source of 020 option possibly ? And nobody has taken on the work to make a better CPU module

Caldor wrote: ↑Tue Jan 24, 2023 10:50 am

What is the actual problem that is causing a need for a slower 020 implementation? I have not noticed any issues with it, but I have not looked much for them either. If there are some examples it would make it easier to try to debug it and figure out what actually causes it and whether its the speed or the cycle accuracy. I doubt its the speed itself. If it is, then its badly made software I would argue, the same way old DOS software just did not try to take into account that future CPUs would be more than 10x faster.

Which is still a compatibility issue, but what A1200 software needed something the exact speed of the 020 rather and still leave the 68000 too slow? The 68000 option is there to have compatibility with the software that generally might have that kind of compatibility issue after all.

For the record, I asked for a 14MHz implementation for a truer feel to the Amiga 1200 - everything opening and running instantly like it's on a Pentium is just weird. LOL For myself, at least, it's not about compatibility...just feel.

rhester72 wrote: ↑Tue Jan 24, 2023 7:00 pm

For the record, I asked for a 14MHz implementation for a truer feel to the Amiga 1200 - everything opening and running instantly like it's on a Pentium is just weird. LOL For myself, at least, it's not about compatibility...just feel.

It’s not too far off an accelerated Amiga 1200 at the time. 25MHz ’030 or ’040 cards with some RAM were pretty common that late in the computer’s life. The MiSTer is equivalent to a 68030 running at 50MHz, those cards were available if you had the cash. Roughly twice as fast as the Amiga 3000/25 or A4000/EC030, but not as fast as the A4000/040. It does run my original A4000/040 setup pretty true to the original speed.

But yes, it’s more like an accelerated A1200 than the base level ’020 without any CPU/RAM upgrades.

It does saturate the IDE bus (…with an incredible 5 megabytes per second ;), which is probably a substantial part of the “feel” of it being fast/snappy when using it — maybe use ADFs exclusively and/or turn off the floppy turbo? 😊