Acorn AKA20 We32206 Floating Point Co-Processor

[egel]

What can you do with a Acorn AKA20 We32206 Floating Point Co-Processor? I know it is a FPU. Is it usable with RISC OS or only with RISC iX? In which machines would it work?

[danielj]

That's rather unusual!

http://chrisacorns.computinghistory.org ... CoPro.html

Looks like it came in with the R140 - I'm personally not aware of any software that used it specifically (but that doesn't mean too much!)

d.

[IanS]

... In which machines would it work?

Officially R140 A400 only. It relies on the middle row of pins on the backplane connector for the full 32-bit data bus, which was only on the A4xx backplanes.
Middle row of pins on the motherboard were used for power on the A540/A5000, so won't work on them.
With the right backplane it should work on A3xx machines.

[Boydie]

RiscIx detects and uses it automatically (at least 1.21c does). There’s a special version of the FPE module for RiscOS - I’ll dig it out if it’s not available.
It only works on ARM2 A400 series machines AFAIK. Don’t think the 300 motherboard had the copro lines fitted, regardless of what backplane is installed.
It won’t work with an ARM3 because Acorn changed the copro lines.

Beware when installing it - it only works in one podule slot. And it’s not the one you instinctively assume (or at least not for me). The Acorn software disc has a test program on it, to check it out.

[egel]

It relies on the middle row of pins on the backplane connector for the full 32-bit data bus, which was only on the A4xx backplanes.
With the right backplane it should work on A3xx machines.

Don’t think the 300 motherboard had the copro lines fitted, regardless of what backplane is installed.

I had once seen that the backplane connector on an A3xx motherboard only has the outer rows connected, so more is needed than just an A4xx backplane.

[IanS]

I had once seen that the backplane connector on an A3xx motherboard only has the outer rows connected, so more is needed than just an A4xx backplane.

The middle row are shown on the circuit diagram - http://chrisacorns.computinghistory.org ... 300_SM.pdf. Maybe they didn't fit a 3 row connector, but the pcb looks capable. I'll check my A3xx later.

[Boydie]

Looking at the respective service manuals, the A300 specifies a 64-way connector in its parts list, the A400 a 96-way.
I thought it’d been officially nobbled in some way, if for no other reason than to polarise the budget and high-end models.

[Richard Russell]

What can you do with a Acorn AKA20 We32206 Floating Point Co-Processor?

Ah, the nostalgia of an ARM FPU that supports extended precision (64-bit mantissa). Sadly all modern ARM CPUs with integrated FPUs can manage nothing better than double-precision (53-bit mantissa).

[Boydie]

Looks like the support disc may be MIA. I’ll upload when I get chance.

As for what can be done with it, disappointingly little in practical terms. Given that it’s a choice between the copro (and faster FP) or ARM3 (and faster everything), it’s usually a no-brainer. The only advantage is faster FP in a machine you otherwise want to keep as original as possible (mine’s in an R140 that I don’t want to upgrade).

Edit: Alarmingly, that R140 is either the 3rd or 4th best Acorn machine I have for FP (behind A540 and A5000 with FPA10, and possibly RPC-SA). More alarmingly, the next fastest may be the ACW with 10MHz 32081!

[waldorfmuppet]

Can the FPU podule not co-exist with the ARM3? I do remember with the RiscPC some software that allowed the x86 cards (assuming not the SX versions) to be used as a pseudo-FPA, but that became obsolete with the StrongARM as the overhead of getting it across the DPOB made the latency greater than just using the FPE.

[davidb]

Edit: Alarmingly, that R140 is either the 3rd or 4th best Acorn machine I have for FP (behind A540 and A5000 with FPA10, and possibly RPC-SA). More alarmingly, the next fastest may be the ACW with 10MHz 32081!

You don't own an A7000+?

I found that for some tasks - OK, FP-heavy tasks - the A7000+ was at least as good as a StrongARM RPC of the period.

[Boydie]

You don't own an A7000+?

I found that for some tasks - OK, FP-heavy tasks - the A7000+ was at least as good as a StrongARM RPC of the period.

Nope. The plus model never came down into what I considered an acceptable price range. The bulk of my collecting was done when the stuff was worth bog-all, which the A7000+ never really dropped to.

[dp11]

On the RIscPC I did write the software to using the x86 card as the FPU. So if you have an 586-133MHz card that is probably the fastest FP Acorn machine.

[Boydie]

Can the FPU podule not co-exist with the ARM3? I do remember with the RiscPC some software that allowed the x86 cards (assuming not the SX versions) to be used as a pseudo-FPA, but that became obsolete with the StrongARM as the overhead of getting it across the DPOB made the latency greater than just using the FPE.

Back in the day, it was asserted that it wouldn’t work in ARM3 machines. What wasn’t stated was why or in what circumstances. ie Does this only apply to native ARM3 machines due to copro bus differences on the backplane, or is there something about the ARM3 itself?
Since the FP podule essentially just has a version of FPEmulator which traps FP code and sends it to the podule rather than the ARM, it *may* play nicely in a machine which has an ARM3 wired to sit in place of an ARM2.
Alternatively, the designers of the ARM3 board may not have bothered to implement the relevant lines for a copro, given that almost nobody owned one.
Or the FPEmulator module itself may break on an ARM3.

Only one way to find out if it works. When I get chance, I’ll try it in my ARM3-equipped A400-series and feed back.

[egel]

Only one way to find out if it works. When I get chance, I’ll try it in my ARM3-equipped A400-series and feed back.

And I have to try to get an A400-series. ARM3 is not the problem to get.

[SarahWalker]

The backplane copro bus relies on the copro instruction being present on the main data bus. This will be the case on arm2 as it would have just been fetched, but won't be the case on the arm3 due to the cache. Arm3 has a separate copro bus to work around this, but this extra bus isn't connected to the backplane.

[Boydie]

Thanks for the explanation. You’ve just saved me from a couple of hours of futility.

[RobC]

On the RIscPC I did write the software to using the x86 card as the FPU. So if you have an 586-133MHz card that is probably the fastest FP Acorn machine.

Was this the one marketed by Warm Silence Software? I've looked around for it for years but it seems to be MIA.

[dp11]

Yes WSS sold it. I have the builds and source code in the loft. I'll dig it out if you are interested.

[hubersn]

On the RIscPC I did write the software to using the x86 card as the FPU. So if you have an 586-133MHz card that is probably the fastest FP Acorn machine.

Was this the one marketed by Warm Silence Software? I've looked around for it for years but it seems to be MIA.

WSS' website is still (a)live, although Robin Watts does interesting things working for Artifex Software (Ghostscript, MuPDF...) nowadays.

Here's the link to FPEPC: http://www.wss.co.uk/products.html#FPEPC

Have fun
hubersn

[CJE-4D]

On the RIscPC I did write the software to using the x86 card as the FPU. So if you have an 586-133MHz card that is probably the fastest FP Acorn machine.

What about the FP speed of an Aleph1 486Podule with CX83S87 fitted?

[mr-macrisc]

I imagine the best cpu for the x86 card for FPU in RISC pc would be the Cyrix 5x86 (if you can find a Cyrix or ibm version capable of running at 133Mhx) the FPU should be noticeably faster than 160Mhz AMD

[CJE-4D]

Is the FPU built into a 5x86 then?

I sold hundreds of our 5x86 133MHz 512k cache RISC PC cards at about £500 each so I probably did know the answer!

[SarahWalker]

Both AMD and Cyrix/IBM 5x86s have FPUs built in. The NexGen 5x86 doesn't but as that chip doesn't fit a 486 socket and bus you won't see it in a RiscPC PC card.

The Cyrix FPU will be faster per clock than the AMD one, but AMD clocks faster. In any case the difference will probably be unnoticeable once you consider the overhead of bouncing FP instructions from the ARM to PC side and the results back again!

[dp11]

FPEPC only moves results across domains with LD ST instructions so if you do lots of trig one after another you can get a good speed increase.

I don't think I ever tested the AMD so it may not even boot.

[TimoHartong]

It would fit nicely in my R140 . But indeed it is true because a real floating chip was ( horribly ) expensive and the emulation software was relatively slow in comparison with the real thing not much floating-point intensive software was written.