Math FPU

[thorfdbg]

7 hours ago, Spotted Lady said:

But if making a custom P2 math coprocessor core, I wouldn't know what would be the best way it could communicate with the CPU core. Obviously, using a P2 would mean you have the hub memory, plus cog and LUT RAM. So I don't don't how one might use the COP instruction (if emulating '816), the custom instruction that has Bill Mensch's initials (WDM? Apparently meant to control a coprocessor of some sort), or where to put a place or means to pass operands to a custom FPU.

The same way how you integrate a 68881/882 into a system without a 68020 coprocessor interface: By memory mapped I/O. That's how it was done for some Amiga expansion cards that hosted a 68881 FPU and used memory mapped I/O to access it. An operating system hook allowed to offload the math libraries to the FPU. The whole construction, however, was not very fast, and the software implementation of the math functions was about the same speed as getting opcodes into the FPU, so was not very successful and the whole interface was canceled later on.

[Irgendwer]

12 hours ago, thorfdbg said:

That's how it was done for some Amiga expansion cards that hosted a 68881 FPU and used memory mapped I/O to access it.

For the Atari-(Mega)-ST line there was also an official co-processor card, the "SFP-004" featuring a 68881. Some programming languages came with libraries to access directly the memory mapped FPU for their floating point calculations.

The "Mega-STE" featured a technically identical solution on-board, offering a socket for the 68881.
You could also load a "Line-F"-emulator, catching the "std-calls" of the 68020-6888x processor interface and redirecting them to the memory mapped processor.

[_The Doctor__]

Falcon030 also had the co processor, as an option... cheaper to buy without and pop the FPU in yourself though

[candle]

i've added some math function to sb core if i remember to aid with vector manipulation (rotation, etc), but speed increase was marginal due to cost of storing parameters and retriving results

in my opinion having this done, at least from 3d graphics perspective is quite pointless - what i do think would be beneficial, is to have bus-master capable coprocesor that could preform on vertex array and would do matrix multiplication - antic intererring is not an issue at all, since that other bus-master could also be sensitive for halt line

another bottleneck is to have all these pixels rendered

side3 does dma when phi2 is low, incognito3 has snyc input to decode instructions for internal freezer/debugger purposes and it could be reused to extend cpu instruction set as Rybags suggested

Things to consider would be support for 816cpu at start, so it won't be an issue later on

as a side note i find it fascinating that xxl suggests using stm32f4 series of mcu, where he has objections to 65816

 

65816 is especially interesing since it has signals like VPA, VMA for bus control and opcodes like COP to make this as seamless as possible