Motorola 68060 FPGA replacement module (idea)

[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.

[matthey]

Ok. It's bytes that affect a7 by 2, but everything else by 1.

No. The stack is "affected" by the number of bytes pushed or popped from or to it as follows.

68k:
byte = 2 bytes (with 1 byte of padding to maintain word alignment)
word = 2 bytes
longword = 4 bytes

ColdFire:
byte = 4 bytes (with 3 bytes of padding to maintain longword alignment)
word = 4 bytes (with 2 bytes of padding to maintain longword alignment)
longword = 4 bytes

This is one of the main incompatibilities between 68k and CF as I mentioned earlier.
Note that movem.w (sp)+, sign extends as it restores registers and is missing on the CF.

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.

That hardware sounds pretty close to what the fpga Arcade is already.

[freqmax]

68k is quite neat to program for

[bloodline]

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.

+1

Probably the most sensible comment in the whole thread

[JimDrew]

How do you know if you need to swap or not ? For example a memory copy function that uses 32bit transfers but may be copying strings that may not be byte swapped ?

greets,
Staf.

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.  As I stated before, this will limit the speed of the emulation to how fast the FPGA can respond, which could be much slower than a fast x86 chip.  So, with a fast x86 chip, it would probably be faster to do the byte swaps manually (through shifts/ORs/ANDs/XORs/etc) or though a lookup table if you have enough memory for that.

As far a copying strings, well the x86 is always backwards Endian from the 68K, so you always have to swap words and long words when fetching/storing data.

[wawrzon]

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.

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.

[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.

[wawrzon]

But we already have AROS for Arm.

sort of. actually hosted. its being worked on native version especially for pi.

Dual CPU PPC accelerators already exist so we have experience from that.

we, means who? the documantation of ppc boards is closed source owned by dce germany, its outdated and it is not going to be given to us except for multiple ten thousands of euro as it has been revealed. also there is none who would realistically build such a ppc board. jens schoenfeld outright refuses to have anything to do with unreliable ppc architecture as he considers it. such an hybrid board is very complicated and expensive in fabrication, Many layers, bga, and requires special softwware (warpos like) which is even more complicated. besides an approach like that already exists with ultimateppc. lets see what will come out of it.

the hybrid ppc boards were a sick stunt to start with. overpriced, overcomplicated, creating a split in community as they need own binaries, non reliable enough, with os4 its even crippier, when you have an ecpensive 68k cpu onboard surrounded by support chips not even being used. i see no advantage of such design even with an arm in place of ppc. please dont repeat past failures.

as for the rest, we actually have the software in question whether its the 68k emu or 68k fpga core already, or what do you mean. what we need it hardware to interface it to amiga, be it fpga or an asic cpu interface. im not an expert but i think this is much easier to achieve. since it has been now proven multiple times that fpga accelerator basically works. it can be improved on that.

and also if you want just an arm system with hosted 68k emu why not just hack an x86 or an arm board directly into amiga housing. with janusuae you will have semi transparent 68k emulation i guess. if this is what satisfies you, i dont see what might stop you, everything is at hand, no need to develop anything, you can start sawing your case right away.

[wawrzon]

@jimdrew:
i thought there is separate data and instruction bus, that can be handled separately. data will always need to be swapped i guess, where is the problem?

also, what does your 040 emu actually provides? does it support fpu and mmu? i guess it would be quite important and at the same time pretty complicated and expensive to have in a pure fpga. this is another argument in favour of x86. winuae contains cpu + fpu emulation with partial mmu emulation, the complete mmu support being merged in by toni right now.

[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.

[wawrzon]

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.

i have one. i always refused one but got it beginning of this millenium, and can confirm that its nothing great. the best part is fast scsi controller. i can dispose of ppc, that can only be taken advantage of the specially precompiled code. all the usual (68k) stuff runs as usual on the 68k processor with its usual speed. so its just okay for what it should be.

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.

im sure its not just as simple as glueing another fpga to an existing design if there was one at disposal to start with. 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. lets do not underestimate the hardware development effort and try to keep it as simple as possible on this side. a hybrid board is under these circuumstanced surely not the best approach, except there is one already in development:
http://ultimateppc.nl/

[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.

[wawrzon]

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

but who do you know who has made an accelerator board before. to my knowledge there is only one (very professional) person yet in the community. jens schoenfeld of individual computers. and he refuses any complicated design and tries to keep things reasonably down to the earth. he didnt even made any 060 design up till now. let us stay realistic rather than pipe dreaming, especially if neither you nor me can contribute to the hardware development. to demand of others is easy.

But these all try to emulate a complete Amiga system.

im not sure if that is actually such a big difference. minimig can run with an associated asic 68k processor and with a softcore like tg68 withing fpga arcade and chameleon. so we have well encapuslated non aga chipset core at disposal and we can associate it with what we like to have for a 68k cpu solution. natami board was made much too complicated i think, just because there was so much features thomas or the followers wahted to implement. thinking of an accel we do not need chipset emu at all of course.

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.

but this is completely another subject. the software side can be thone by the comunity anyway. but it is difficult to expect that hardware can be developed like that. therefore i think it is important to keep hardware side simple.

[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.

[wawrzon]

it was me who proposed x86 accel i admit, in order to simplify the design using widely awailable prefabricated components. if you look at jens schoenfeld x-surf, apparently one of the best zorro network cards, its an pc low profile isa card assembled with a simple zoro adapter board and a little logic. jens must have done the simplest and most reasonable thing there was.

also i did not propose to run native code on that accelerator, whatever cpu it would carry, except for 68k emu. everything else would run 68k native without any modifications. at least at the beginning. the rest could stay open. but lets leave this topic to better informed.