Welcome, Guest. Please login or register.

Author Topic: Motorola 68060 FPGA replacement module (idea)  (Read 53016 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline psxphill

Re: Motorola 68060 FPGA replacement module (idea)
« Reply #44 from previous page: February 11, 2013, 05:15:25 PM »
Quote from: bloodline;724860
I've actually spent a few days trying to design my own 68K emulator, to work out how to modify the MIPS ISA to make it super efficient at 68k emulation...

Going from a general purpose cpu would end up as an inefficient microcode based 68k.
 
It makes sense to dump the original 68000 & 68010 microcode to emulate those processors. Not all of it's done yet though, there is some work hopefully happening soon.
 
I don't know how much of the 68020 and later were microcoded.
 

Offline psxphill

Re: Motorola 68060 FPGA replacement module (idea)
« Reply #45 on: March 18, 2013, 03:10:37 PM »
Quote from: FrenchShark;729606
Since all the Kickstart ROMs contain 0018 0019 001A 001B 001C 001D 001E 001F at location FFFFF0 - FFFFFF, I am not using interrupt aknowledge cycles, just auto vector.
That's enough for running an Amiga.

All official kickstarts contain that & only 68000 based Amiga's use it.
 
However it can be changed to allow for WHDLoad quit key support on 68000 by pointing the vector back inside rom and only passing on to the actual vector if the quit key is not pressed (basically what the ACA500 will do ).
 
I don't know whether Datel Action Replay and the rommable hrtmon make use of this functionality also, but I can imagine it would be useful.
 
I think it's worth supporting the cycles if you're doing a pure 68000 core.
 
Quote from: freqmax;729576
Why is big endian resource hungry?
 
(perhaps why Intel x86 is little endian)

Big vs little endian is an arbitrary choice.
 
The name comes from Gulliver's travels.
 
http://en.wikipedia.org/wiki/Lilliput_and_Blefuscu
 
Accessing little endian data on a big endian processor (and vice versa) is an extra overhead. However when emulating a 68000 the overhead is very small because it can't access unaligned data & it just takes a well placed xor of the address lines. 68020 and later plus all x86 processors can do unaligned access, so you have to take those cases into account. I'm not sure there should be any overhead in an FPGA implementation.
 
Quote from: Mrs Beanbag;726087
68060 is definitely microcoded to some degree, move , is split into two "standard operations".

When you split instructions up then they are called micro-ops, but this is unrelated to micro-code. The micro-ops might be executed either using micro-code or they might be hard coded.
« Last Edit: March 18, 2013, 03:28:13 PM by psxphill »
 

Offline psxphill

Re: Motorola 68060 FPGA replacement module (idea)
« Reply #46 on: March 19, 2013, 11:30:55 PM »
Quote from: FrenchShark;729721
big endian is human's natural order. little endian is computer's natural order.
A xor on the address lines is just your view as a programmer. Where are address lines A0 and A1 when you are dealing with a 32-bit data bus ?

Little endian is no more natural for a computer as big endian. The only difference in hardware is how you calculate the strobes and shifts. 32 bit values on a 32 bit bus are the same whether it's big endian or little endian, it's only when you access bytes or words that anything changes.
 
xor'ing addresses with 3 for bytes and 2 for words just affects how the host CPU generates the strobes and shifts, as most CPUs use byte addresses for everything.
 
In hardware then you will always have to calculate the strobes and shifts from the low bits of the byte addresses and whether you calculate them for big endian or little endian makes no difference in terms of complexity. If you're doing anything extra for big endian then you're doing it wrong.
« Last Edit: March 19, 2013, 11:51:53 PM by psxphill »