Bare 68000 only. You probably need almost completely separated cores for the other processors, if you want cycle accuracy. There is probably not much in common between the 68030 (or even the 68020 for that matter) and the 68000 at the gate level. The 68010 is very close to the 68000, but I guess there is not as much interest in the 68010.
Yeah, no much interest in exactly 68010, as it's a 68000 with couple new instruction.
Amiga AGA core suffers from not 100% compatible 68020. It's not about cycle accuracy but about instructions implementation.
Besides that, your 68000 cycle accurate core will be helpful for other cores.
Bare 68000 only. You probably need almost completely separated cores for the other processors, if you want cycle accuracy. There is probably not much in common between the 68030 (or even the 68020 for that matter) and the 68000 at the gate level. The 68010 is very close to the 68000, but I guess there is not as much interest in the 68010.
Yeah, no much interest in exactly 68010, as it's a 68000 with couple new instruction.
Amiga AGA core suffers from not 100% compatible 68020. It's not about cycle accuracy but about instructions implementation.
Besides that, your 68000 cycle accurate core will be helpful for other cores.
I've finished adding the missing instructions to my m68k (tg68k) variant. It's still undergoing testing but meetings timing and runs. I'm trying to fix some of the stack frames then I'm done and will switch efforts to the new core. This will go on git shortly.
fpgaarcade wrote:I've finished adding the missing instructions to my m68k (tg68k) variant. It's still undergoing testing but meetings timing and runs. I'm trying to fix some of the stack frames then I'm done and will switch efforts to the new core. This will go on git shortly.
fpgaarcade wrote:I've finished adding the missing instructions to my m68k (tg68k) variant. It's still undergoing testing but meetings timing and runs. I'm trying to fix some of the stack frames then I'm done and will switch efforts to the new core. This will go on git shortly.
fpgaarcade wrote:I've finished adding the missing instructions to my m68k (tg68k) variant.
What's the max speed of tg68K? The ideal combination would be to include two cores, one plain 68000 cycle accurate. And a non cycle accurate faster core. I was (still am) considering the idea for my ST core. You obviously don't need cycle accuracy for "turbo mode", and you pay a performance price on a core for being cycle accurate.
For the MiSTer FPGA (and probably also for your reply board?), including two 68K cores is no big deal.
fpgaarcade wrote:I've finished adding the missing instructions to my m68k (tg68k) variant.
What's the max speed of tg68K? The ideal combination would be to include two cores, one plain 68000 cycle accurate. And a non cycle accurate faster core. I was (still am) considering the idea for my ST core. You obviously don't need cycle accuracy for "turbo mode", and you pay a performance price on a core for being cycle accurate.
For the MiSTer FPGA (and probably also for your reply board?), including two 68K cores is no big deal.
So, I've "tidied" up the tg68k a lot, mainly in an attempt to understand it, and renamed it m68k. I've managed to get rid of most of the loops, and unrolled the decode pipeline. I'm in discussions with Sorgelig to use a common CPU repos to avoid the fragmentation and maintenance hell we have at the moment.
It runs at 28MHz in my old spartan3e no problem. I have a wrapper for it I can also move in to the same dir which has separate I and D caches and prefetch. The next step is to make it true 32 bit IO - currently the cache is 32 bit but the CPU core has a 16 bit datapath.
I was also planning to use two CPU cores
I'm working on a new clean-room core now I understand what is involved based on some of the RISC-V codebase.
/Mike
Igor,
Not sure if you seen but I also have a daughterboard with an 060 attached. I can use this, as well as the 68000 db for verification. I'm also in the process of attaching an 020 with some of the Amiga chips for corner case verification.
Replay1 is EOL now, the DB has been shipped to current users but full focus is on Replay2 now, wherever that takes us. If you have any ideas for board features let me now and I'll ping you the current spec.
replay_060_floppy.jpg
/Mike
You do not have the required permissions to view the files attached to this post.
fpgaarcade wrote:It runs at 28MHz in my old spartan3e no problem.
Doesn't seem too much. My own cycle accurate core can reach close to 40MHz, and I didn't try too much optimization because that's much more than what I need for the ST core. I also expect it could get much higher if I would be ready to sacrifice some cycle accuracy
But of course, a 020 core should be slower (lower fmax) than a 16-bits core. Is it possible to remove the 020 functionality and get a bar fast 68000?
ijor wrote:But of course, a 020 core should be slower (lower fmax) than a 16-bits core. Is it possible to remove the 020 functionality and get a bar fast 68000?
since m68k is based on tg68k, it uses 16bit bus and overall is 68000 with additional 020 instructions. So, it should be already what you need.
ijor wrote:But of course, a 020 core should be slower (lower fmax) than a 16-bits core. Is it possible to remove the 020 functionality and get a bar fast 68000?
since m68k is based on tg68k, it uses 16bit bus and overall is 68000 with additional 020 instructions. So, it should be already what you need.
Maybe we should do this in a different thread.
It's 28MHz with the combinatorial paths through the cache controller (which has a x4 clock). It executes many instructions in a single cycle.
I haven't tweaked it for a modern FPGA yet, but it should go considerably faster.
I'm aiming for 100MHz with the rewrite.
fpgaarcade wrote:I'm aiming for 100MHz with the rewrite.
Sweet
Maybe we should do this in a different thread.
We are already. I splitted the thread. But the previous posts retain the title of the original thread.
I haven't tweaked it for a modern FPGA yet, but it should go considerably faster.
Really? I know you work with Xilinx devices. I am more familiar with Intel/Altera stuff and they don't go any faster for the low cost families. Later families are cheaper (for the same density) and consume less power, but they are not any faster and sometimes they are even slightly slower. The Cyclone V family (MiSTer) has a much slower I/O interface (higher delay to and from the main core) than the Cyclone III (MIST). You do might sometimes get a faster compilation because the newer versions of the tools don't support older families.
Of course, the high performance and extremely expensive families go faster on any new generation.
Of course, the high performance and extremely expensive families go faster on any new generation.
I use Altera/Intel a bit as well, but it's mainly Xilinx ultrascale now for ASIC prototyping etc.
The spartan3e is a 4 input lut, the spartan7 is a 6 input and that alone makes a big difference.
I'm also looking at the fast (-2) spartan7 to get decent HDMI speeds out of it, and there is quite a jump between the -1 and -2 speed grades.
/Mike
fpgaarcade wrote:
I'm also looking at the fast (-2) spartan7 to get decent HDMI speeds out of it, and there is quite a jump between the -1 and -2 speed grades.
/Mike
fpgaarcade wrote:
I've finished adding the missing instructions to my m68k (tg68k) variant. It's still undergoing testing but meetings timing and runs. I'm trying to fix some of the stack frames then I'm done and will switch efforts to the new core. This will go on git shortly.
Intersting! Any Idea, when you will put it up on GIT?
This week I hope. I've been running comparisons with the fx68k design when the core is in 68000 mode. There are some minor differences in stackframes I would like to fix, but I think it's good enough.
fpgaarcade wrote:This week I hope. I've been running comparisons with the fx68k design when the core is in 68000 mode. There are some minor differences in stackframes I would like to fix, but I think it's good enough.
Still fighting the stackframes? Or did real live get in the way?
fpgaarcade wrote:
I'm in discussions with Sorgelig to use a common CPU repos to avoid the fragmentation and maintenance hell we have at the moment.
Great idea! I saw that a lot of common CPU and SPU core are more or less replicated across the various ports, having a library of "validated" cores would be nice and as you wrote, for maintenance, just necessary.
If there is a 68000 or 68010 core which is faster than 68080 then I'll be happy to try it. But of course unless you have a Vampire you can't try the 68080 any way, and so we are left with the question of what is the next fastest? Or what is the fastest which is AVAILABLE?
PurpleMelbourne wrote:If there is a 68000 or 68010 core which is faster than 68080 then I'll be happy to try it. But of course unless you have a Vampire you can't try the 68080 any way, and so we are left with the question of what is the next fastest? Or what is the fastest which is AVAILABLE?
I think we care here more for accuracy than for speed. They are almost mutually exclusive attributes.
Accuracy is the main concern.
But some cores like Minimig depend on accuracy of instruction implementation but almost completely don't care of cycle accuracy.
I didn't see sources of 68080 yet. I believe it's some misunderstanding as i don't remember any announcements of it's source release. I've saw that SAGA sources may be will be release in castrated form, nothing more.
