Motorola 68060 FPGA replacement module (idea)

[JimDrew]

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.

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

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

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

Again, I think the FPGA would end up slowing down the process when you had a fast x86.  I am not sure where the break even point would be - that would depend on how fast you could clock the FPGA.

Endian is really not that big of a deal when doing a 68K emulation.  It's just an extra process.

I guess you guys have to decide if you want 100% compatibility or not.  If you do, you absolutely must have a cycle exact emulation.  There are quite a few programs that require it.  You could also deliberately set emulation thresholds.  For example, you could set the speed/emulation type to be Amiga 500 (68000), Amiga 3000 (16MHz or 25MHz 030), Amiga 4000 (25MHz 68040), etc.  This way you could run those euro demos in Amiga 500 mode that won't work on anything else.  

[JimDrew]

Emulators can "lay out" the emulated memory in whatever way they like as long as the emulation makes it look "normal" to the emulated machine.

Yep.  My first version of the Pentium emulation for the Amiga used the PC memory map backwards.  This was so no byte swaps were necessary for the opcode emulation.  However, when it came to disk, DMA, screen stuff, etc.  It was a nightmare having to swap everything.  After a lot of testing I went to a forward memory map and that ended up being faster in the long run because of the reduced swapping needed for the video alone.

[JimDrew]

I think Jim Drew is suggesting that the FPGA only swaps the bus when the CPU makes a request larger than a byte.

I missed this post - That is correct.

[JimDrew]

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

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.

[JimDrew]

If you really plan on using strictly a FPGA to emulate the CPU, I would suggest someone modifying WinUAE to make a histogram of instruction usage.  This would let someone focus on optimizing the 680x0 core by looking at instruction usage which could help determine things like what changes in the cache, pipelines, etc. will benefit the speed.

[JimDrew]

There is quite a bit of work going on understanding the basic architecture of the 68K

http://www.visual6502.org/images/pages/Motorola_68000.html

The micro and nano microcode instructions roms are being read out.
If this works, a table based FPGA will be much smaller and more accurate than the current code - and can be tweaked easier.
A lot of the cloaning complexity of the 68K is a fall out from the way it was efficiently implemented due to die area limitations at the time.
/MikeJ

Well Mike, that will definitely lead you in the direction of a perfect FPGA core emulation.  Table based should be much easier to implement pipelines and the correct size caches.

Motorola was working on a FPGA type chip between the 040 and PPC development with IBM.  Motorola in Phoenix, AZ asked me to visit and I got a chance to work with the microcode blocks for simulating the 68K CPU.  That chip was suppose to be able to become a x86 or 68K (or whatever) by uploading a new core.  It was abandoned because it was simply too slow.  I worked with other microcode projects as well, and I actually called my company Microcode Solutions.

[JimDrew]

The builtin CPU core in the FPGA Arcade is limited because of logic matrix constraints.

That's with the current core.  If Mike gets the microcode dump done and turns that into a table based core, that will shrink the size and make it very easy to change to higher speed FPGAs, not to mention tweaking the core for big caches, multiple pipelines, etc.

[JimDrew]

Has anyone worked with the MCC-216 hardware?  It uses an Altera Cyclone III in it.  I just received one with the developer package and wondered how this compares to what Mike is building.

[JimDrew]

Jim : "Has anyone worked with the MCC-216 "

Several of us have a real problem with this guy - he was on this forum for a while. He is using GPL code and not releasing the source, which is naughty. We will release the code for the Replay system as soon as we start shipping a stable core.
/MikeJ

Interesting.  I wonder what I have then.  I got a link to a complete dev kit but I have not looked to see what was in it.  It took a month to get it after I paid for it (eBay auction).  He did add the JTAG header and set it up for development work.  I chatted via email with him a few times before I found out about your project.  In fact, I got so frustrated at the delivery time that I started looking at other FPGA developer boards, which is how I found out about your project!

From a hardware standpoint, the MCC-216 is pretty simple - just the Cyclone III, some RAM, and some I/Os.  I am not sure how fast it is or what can be done with it.  I know that most of the projects I have seen for the Altera are all Verilog based, and even though I am a U.S. guy, I have only experience with VHDL so your projects appeals to me - that and you are a heck of a nice guy from everything I have seen so far.  

[JimDrew]

Thanks Robert, I will check that out.  I know some people are using OS2.04 on this device (well, at least they claim they are!)

[JimDrew]

I think the thing with TST being the #1 instruction in SEGA games is either:

A: All those games were compiled with either SASC or GCC which generates silly wasted TST instructions all the time.

B: The Sega Genesis uses PIO (Polled IO) for some things so it has to constantly TST a certain memory location all the time in a loop.

C: All of the above.

I agree... with the MacOS, TST is not even in the top 10 instructions used.

[JimDrew]

Use several BIG lookup tables if you can afford the memory.  I tried several smaller tables, but ended up using a couple of large tables.  I think the emulation (PC) ended up being around 1.25MB in total size because tables were imbedded in the executable (along with the instruction emulation), repeated over and over in most cases, instead of being built in memory.  But, the speed difference is dramatic.  You have to remember, if you can save just 4 cycles, benchmark programs and anything else sitting in loop is going to really benefit from it!

I think Mike's table based microcode lookup is going to the most efficient (and fastest) method of doing the microcode core emulation.

[JimDrew]

On another note... I just found a source in China with the Rev 006 MC68060RC50 chips.  They apparently have over 10,000 of them left over from a production run of call center boards.  I have a couple of samples coming.

[JimDrew]

it seems odd that such a large pile of them are sitting around somewhere when people are having such a terrible time getting them.

Ummm... I don't see that they are even remotely rare.  I found 15 different sources with varying amounts located in Malaysia, Taiwan, and mainland China.

As long as the part works, I would not care if they were knock-offs... but they would definitely have to pass a test rig setup and function well beyond the 50MHz rating.  I was told that these are all genuine parts, with the one supplier a bit desperate to unload all of them.  By the way, the going rate for all of the suppliers I found is about $50 per CPU.  I am not sure how that compares to the normal pricing.  I just so happened to ask one of my part suppliers in China for the latest micro pricing, and the 68060 appeared on the list.  I was kind of shocked to see that, so then I sent an inquiry to a bunch of chip wholesalers about the 68060.  There are a lot of them out their folks!

[JimDrew]

LOL!  Ok, Mike I will look into this a bit more.  If you like, I can give you the contacts to the companies that are in China.... Malaysia and Taiwan are probably a bit out of your way.

How goes the arcade boards?  Anything for developers yet?