New Buffee (ARM 68K Emulator) Accelerator In Development

[amiman99]

When the prototypes are done, let see some real world benchmarks/demonstrations. Vista, Cinema 4D,ECS Doom, Lightwave rendering, MP3 playback.

[ProfPlum]

Needless to say, I'm buying one once available

[rare_j]

It looks very clever.
If you were to install this in say, an A500+, what would the storage options be?
Are there any boards that would work with this to give you an SD card hard drive for example?

[Tigerskunk]

I'd love to buy one for my A1000.
Will be fun using that incredibly fucking fast WB...

[McTrinsic]

Originally Posted by rare_j

It looks very clever.
If you were to install this in say, an A500+, what would the storage options be?
Are there any boards that would work with this to give you an SD card hard drive for example?

Any IDE device for the 68k slot would do.

There are some homebrew options.

[eXeler0]

Love it, the name too, lolz ;-) Never mind the boring people on Reddit who think its a cheap potshot at the you know who.. Its all pretty harmless fun.
Anyhoo, real world benchmarks will be super interesting to see. Until then there will be a lot of speculation regarding how well this is going to work. If we see a 1000MIPS A500 that will be a crazy day in Amiga-land.

Now, hypothetically speaking... (In a distant future in a galaxy far away etc) a 32 bit version for the A1200.. Would that be in the physical form of a regular A1200 trapdoor accelerator card?

[Gorf]

Originally Posted by rare_j

It looks very clever.
If you were to install this in say, an A500+, what would the storage options be?
Are there any boards that would work with this to give you an SD card hard drive for example?

How about a A314?
(seems one can't have enough ARM CPUs in an Amiga ...)

[Gorf]

Originally Posted by eXeler0

Now, hypothetically speaking... (In a distant future in a galaxy far away etc) a 32 bit version for the A1200.. Would that be in the physical form of a regular A1200 trapdoor accelerator card?

Would love to see that too ... for my A3000.

But the used ARM CPU (OSD335x) is somewhat exotic as it connects even to its internal 512MB DDR3 RAM via 16bit .... and the GPMC managing the 68k bus ist limited to 16bit too. (You could go even down to 8bit according to the specs)

So we need to find some 32bit wide equivalent first...

[Promilus]

So we need to find some 32bit wide equivalent first

Good luck with that... Even Cortex A53 based texas chips with GPMC still use 16bit. And it would be extremely hard to find anything decent with external interface adjustable enough to handle amiga timings and signal.

[alexh]

The width of the external interface on the ARM SoC is somewhat irrelevant.

The emulated 680x0 bus will probably be many times slower than the I/O maximum switching rate. Meaning you could time-division multiplex the GPMC pins using an external CPLD

PiSTorm uses an external CPLD to multiplex the limited RPi GPIOs into a 68000 bus.

[Gorf]

Originally Posted by Promilus

Good luck with that... Even Cortex A53 based texas chips with GPMC still use 16bit. And it would be extremely hard to find anything decent with external interface adjustable enough to handle amiga timings and signal.

I noticed ...

I am now searching for some "level shifting multiplexers" or "multiplexing level shifters".

As we would need to shift voltage levels anyways, maybe there is an elegant way to combine this with some multiplexing - the GPMC is more than fast enough to deliver two reads or writes for anything on the old mobo...

The Altera Max CPLD could do that:
https://www.intel.com/content/dam/ww...e/an/an490.pdf

74LS156 in open collector configuration ... but you would need A LOT ...

the CPLD option seems more reasonable.

[Promilus]

PiSTorm uses an external CPLD to multiplex the limited RPi GPIOs into a 68000 bus

Yes it does but afaik RPI uses polling of it's GPIO pins and elaborate emulation to seek what it actually means and react. GPMC is hardware solution. It - essentially - is external memory interface (which RPi GPIOs are not!) with separate address space so typical mem operations applies directly. So basically you can move data to #adress and it goes directly there (pins are set). With RPi you move data to #address, it is translated to gpio pins config and only after that there are instructions settings I/O registers to simulate address/data lines and control signals. It surely does work but also costs some computing power and additional resources (cpld). Buffee is actually more elegant solution engineering-wise. If newer, more powerful Sitara line SoCs aren't "sell your kidney to get" I'd love to see Van Helsing (or buffee 2)

[alexh]

Maybe, I'd have to see the design but it is unlikely that a traditional SoC external memory interface (even a flexible one) can map 1:1 to the full 68000 bus. It is not just chip-select + address + data + direction. Sideband signalling will undoubtedly be done using GPIO.

I can't imagine newer SoC's offering wider parallel external interfaces in the future. Parallel has had it's day it's all about serial these days to get the speed without bit-skew.

[Promilus]

Some signals of 68k in amiga aren't used. Some aren't used unless you want to share the bus with original 68k or different turbo (which is unlikely). Those can be omitted. IIRC FC[0:2], BR, BG can be omitted, some of the rest (VPA, E, VMA, IPL, BGACK, DTACK, AS, UDS, LDS) can be handled by external logic or by GPIOs. What's most important is if you can use amiga as external memory then you can place it inside SoC memory map like
0x000000 + SoC MM offset = start of chip ram
0xFFFFFF + SoC MM offset = end of kickrom
and then just use that offset to move data in or out of amiga with GPMC address, data, r/w etc. signals being controlled by memory controller itself (no additional work for developer).
With RPI it's something like:
emulated 68k tries to get first chip ram cell - it sets amiga-style address, translates it to gpio pins required, writes those registers "by hand" (so controlled by software all the time) and then when some I/O interrupt occurs read out the result from GPIOs, then translates it back to emulated 68k style. With PCIe it's somewhat different. It surely has own address space so how transmission is realized doesn't really matter. You still can write off to certain address and it'll end up in pcie device - hardware decoded - the way it's supposed to do without constant software-decoding of i/o pins. But - again - to date nobody made such attempt to wrap up amiga with fpga as pcie device and hook it up to the host. I explored the idea and found latency quite disturbing.

[Jope]

No BR/BG? Sure, there aren't THAT many DMA expansions, but the few we have are super nice, and it's a shame they usually have to be shelved when you plug in a turbo. :-)

[Promilus]

Perhaps I wasn't clear in my post... can be omitted != must be omitted. BR and BG isn't particularly useful for A500 if you don't have side expansion attached, and most internal ide/cf solutions (which are way more popular) doesn't need those anyway. I find eMMC controller of AM335x superior to any dma solution you can hook up to side of A500 And I do not suggest to remove BG and BR from the design, only that those are not absolutely essential signals which are required for amiga to work.

[Jope]

Yeh, once there is a version of the Buffee that has some kind of mass storage option, I'm sure any AmigaBUS DMA controllers can sort of safely be shelved.

[Gorf]

Mass storage is not a goal. Full DMA support is.
(According to the blog)

Edit
I was wrong with "DMA support"

[Jope]

Originally Posted by Gorf

Mass storage is not a goal. Full DMA support is.
(According to the blog)

I wonder where I got the impression that this was step 1 of many. Ok, forget I said anything.

[Gorf]

Since it’s Open Source there is a good chance of someone modifying the specs later on..
But first we need to see Buffee kicking ass

From the blog:

The big reason I chose this processor is because it has the General Purpose Memory Controller (GPMC) which allows it to DIRECTLY interface with any asynchronous bus (like the 68000’s), and has dual realtime controllers which can offload the various additional bus control signals used by the 68000. This permits the CPU to focus on instruction execution alone.

But the AM335x has one more feature that makes that even more important – hardware memory access to the physical 68000 bus without any CPLD or FPGA performing “translation”. The AM335x has a special peripheral called the GPMC (General Purpose Memory Controller) able to connect with nearly any 8-bit or 16-bit, synchronous or asynchronous memory bus. This ultra-flexible peripheral puts the 68000’s 24-bit memory address right where it should be, so when we’re translating a MOVE operation from the 68000, no addresses need to be translated.

We don’t even need the MMU!

This memory can even be cached!

We can even DMA with this memory!

Of course, there’s one downside to this approach – that we can’t easily emulate any other hardware we like. For exmaple, there’s no opportunity here for IDE emulation to give us a massive HDD performance advantage over classic hardware. In my opinion that’s a small downside and a actually a big upside. PJIT is a CPU emulator. It cannot be a “machine” emulator and I have no desire to have Buffee “take over” your computer.