Motorola 68060 FPGA replacement module (idea)

[Mrs Beanbag]

the site seems to be back online now.

[Mrs Beanbag]

Doesn't movem.w (SP)+ add 4 to the stack pointer for each write? at least on some processors I'm sure the stack pointer gets 4 byte aligned.

The programmer's reference manual doesn't say so. It says "the address is incremented by the operand length (2 or 4)".

[Mrs Beanbag]

How about this for a crazy idea, an accelerator with an Arm CPU and an FPGA, the FPGA can function as a 68k CPU if set up as such, so it could run like the PPC accelerator boards. BUT you install AROS for ARM ROM chips and use the Arm as the main CPU, and allow the FPGA to be reconfigured by the Arm chip, so then you could develop your 68k core "live", and install updates through software.

[Mrs Beanbag]

There are several ways to handle this.  One requires that the FPGA follows the instruction stream, so as instructions are decoded the data bus can be swapped depending on the incoming instruction.  The other way is by having the x86 side (during the decoding) change the bus interface.

But then it goes in the cache, and there are any number of things that can go wrong. Such as if you read an address as a longword for some reason, and then go on to process it as part of a string, it will have been byte swapped into the cache. Either you turn the cache off and destroy any advantage of using such a fast CPU, or you have serious difficulties ensuring coherence.

[Mrs Beanbag]

i dont get it, but sounds like another hybrid idea, aros arm system with 68k apps. imho anything like warpos solution is a waste of time. we shouldnt create another split/branch with the need of dedicated binaries, and we shouldnt follow feature creap strategy. lets have simple 68k accel, as simple as it gets, no strange ideas. lets treat 68k as virtual common platform/denominator, then we will maybe have chance to actually achieve something one day.

lets start discussing wierd complicated ideas and we can have fun threadthat will follow in natami footsteps, to nowhere.

But we already have AROS for Arm. We could make an Arm board for A1200 and install AROS ROMs in it. The expertise exists for that, I believe. We wouldn't need an emulation layer or any fancy bus tricks. Dual CPU PPC accelerators already exist so we have experience from that.

What we DON'T have is a FPGA accelerator, because we don't have a 68k core. One reason why not is it means developing both hardware and software at once, while either on their own is a task in itself, so we get stuck at an impasse. No core? FPGA accelerator=useless. No FPGA accelerator? Core=useless.

Natami/FPGA arcade try to emulate a complete system, which is yet again a massive task that we don't need to do. We only need the 68k, and a convenient platform to develop it on would really make things easier.

[Mrs Beanbag]

Well I don't want to saw my case up for one thing... I'm not suggesting using PPC just pointing out that dual CPU has been made to work. I've never owned one, though, so I can't say how well it works.

Accelerators have an FPGA on board anyway to handle various bus signals, could just be a case of replacing it with a bigger one, and an interface to allow the firmware to be updated from software. FPGA accelerator basically works but there is a barrier to community development of the core(s). Plus people could create custom cores, which could produce some interesting projects. I'd like to develop my own core but I don't have the means to produce hardware.

Arm chip need not be expensive.

[Mrs Beanbag]

im sure its not just as simple as glueing another fpga to an existing design if there was one at disposal to start with.

Hardware would need a redesign but I'm sure it wouldn't be beyond anybody who has made an accelerator before.

look how much effort has been put into minimig, fpgaarcade or natami hardware. there are several fpga aware people around the scene yet except those little else is available to us.

But these all try to emulate a complete Amiga system.

With big FPGA+small Arm+Flash ROM (flashable in software) development could be done in the community rather than in isolated groups, that's essentially my "crazy idea" anyway. The hardware could be configured various ways, 68k core in the FPGA, software 68k emulation on the Arm, potentially PPC in the FPGA as well I guess, or anything else you could think of. But could run AROS "out of the box" with nothing in the FPGA but a bus interface.

[Mrs Beanbag]

let us stay realistic rather than pipe dreaming,

You're demanding a lot of me here, I don't know if I can manage it.

so we have well encapuslated non aga chipset core at disposal

I don't even need that, I have a real AGA Amiga.

I get your point. But we are already on the subject of making custom hardware CPU boards, which is the topic of the thread anyway. And people are suggesting even x86 accelerators.

[Mrs Beanbag]

Anything that isn't 68k will most probable require some FPGA glue.

Even a 68k needs an asynchronous bus interface to run at anything other than the motherboard clock speed. ACA1230 etc use an FPGA for this, as well as for the memory controller (I believe).

[Mrs Beanbag]

I think if we've got some fast CPU running 68k emulation or otherwise, it would be a shame not to make its raw power available to the user in some way.

I also had the idea a while back also to approach the problem from the opposite end... make an Amiga graphics card (preferably AGA, for me) for PCs. The PC would then only need to emulate the 68k.

[Mrs Beanbag]

Inside Out board made with Minimig-AGA, once Yaqube and friends have that finished up.

I never heard of Inside Out board, it seems to be a complete Amiga, CPU and all?

Don't really need the CPU on board. Just the graphics + sound.

[Mrs Beanbag]

Sure you can.  In fact, the FPGA would only swap certain instructions where this is required.

The swap is only required because the byte order is backwards (Endian issue).  So, if you fetch a long word from memory using something like mov.l $12345678,d0 that memory location will appear backwards to an x86 and would have to be swapped.  The swap occurs during the opcode emulation, and using some hardware means to perform the swap (like the bus wired backwards momentarily) would eliminate having to do it in software

I hope you mean move.l #$12345678,D0. But look at Psxphill's example. Supposing you do
move.l (A0),D0
move.b (A0),D1

which byte of (A0) ends up in D1? Given that (A0) is now cached.

Let A0 point to an address that contains $12345678. FPGA swaps it to $78563412. Second line then reads $78 instead of $12!

If this were such a trivial problem to solve, "endianness" wouldn't even be a thing.

[Mrs Beanbag]

PCI(e) could be very good, an adapter that essentially converts the Amiga 1200 chipset into a graphics/sound card, and an accelerator that is essentially a tiny motherboard.

Personally I don't see the motivation for trying to squeeze all the data down a serial interface of any kind, when we have naturally parallel devices at both ends.

[Mrs Beanbag]

Since it is A0 itself that is byte swapped, the correct value for the lower byte will be returned.

What do you mean, A0 is byte swapped? How do you byte swap an address register? What address does it point to, the most significant byte of our longword, or the least significant byte? It can't point to two different addresses.

No, because the BYTE value of $78563412 is $12 - just as it would be with a software only op-code interpreter.

But the number is not $78563412. The number is $12345678. The byte value of that is $78.
A byte access wouldn't know anything about the other three bytes. The $12 is stored at (A0). The $12345678 is stored at (A0). If you swap it in memory, the address register no longer points at the most significant byte.

If there is a string in memory, such as "abcdefgh" does it get swapped to "dcbahgfe"? But the pointer to the start of the string still points to "a"?

Supposing we have a longword access at 2(a0), then what?

[Mrs Beanbag]

I missed this post - That is correct.

But the CPU is not making any request on the bus if the data is in the cache.

Also how would you distinguish between the virtual machine memory, and the memory required for the emulator itself (including its program)? You would not want to swap the emulator's program code around.

[Mrs Beanbag]

2 is added to the value of A0 and swapped.  This is no different than how we do it with software emulation.  An FPGA can certainly do anything that can be done in software.  Instead of the FPGA handling the entire CPU core, it would be handling the memory bus accesses and off-loading the CPU emulation itself to the primary (x86) CPU.

But then instead of getting "cdef" as the data, it gets "bahg" interpreted as "ghab" - completely wrong!