New Buffee (ARM 68K Emulator) Accelerator In Development

[utri007]

This has nothing to do with Vampire.

I'm interested to buy one or two

[amiwolf]

This is a novel and interesting project! Don't know much about the Octavo OSD335x-SM, or even ARM's ISA for that matter. Is it any better than x86/x64 at emulating 68K?

Just on Vampire, if the Apollo team had a little more nous they'd offer a version of the V2 core without RTG but with bigger caches or more precise FPU for those who want a pure CPU accelerator and nothing else.

[Gorf]

Originally Posted by amiwolf

This is a novel and interesting project! Don't know much about the Octavo OSD335x-SM, or even ARM's ISA for that matter. Is it any better than x86/x64 at emulating 68K?

It can talk naturally to asynchron 16bit busses and use memory directly over this bus. THAT is the feature, that singles this CPU out. It is ideal to read/write to ChipRAM and old hardware registers.

ARM in general has the advantage to be able run in Big Endian mode like 68k and ppc - that makes emulation easier.

In almost every other aspect x86/x64 are more powerful... so for running UAE they are still the better choice ... but Apples M1 is getting closer...

[IanP]

Originally Posted by amiwolf

Just on Vampire, if the Apollo team had a little more nous they'd offer a version of the V2 core without RTG but with bigger caches or more precise FPU for those who want a pure CPU accelerator and nothing else.

I suspect the number of people that would want that option are very small. The Vampire accelerators currently target the most common Amiga models (A500, A600 and A1200) that lack other RTG options. If you don't want what the Vampires currently offer you are probably better off with another option like Buffee or a 68060 card. I don't know if removing RTG would allow bigger caches as they are probably constrained by the available embedded memory on the FPGA. Is the Vampire FPU precision a problem for anybody?

[amiwolf]

Originally Posted by Gorf

It can talk naturally to asynchron 16bit busses and use memory directly over this bus. THAT is the feature, that singles this CPU out. It is ideal to read/write to ChipRAM and old hardware registers.

ARM in general has the advantage to be able run in Big Endian mode like 68k and ppc - that makes emulation easier. In almost every other aspect x86/x64 are more powerful... so for running UAE they are still the better choice ... but Apples M1 is getting closer...

Thanks for the info, Gorf. I'll probably stick with UAE then, for the time being.

Originally Posted by IanP

If you don't want what the Vampires currently offer you are probably better off with another option like Buffee or a 68060 card.

Nah, man - I'm saving for the V4. Different strokes for different folks, though.

Originally Posted by IanP

Is the Vampire FPU precision a problem for anybody?

Some won't settle for anything less than 80bit. Not me, I ain't so fussy!

[Bruce Abbott]

Originally Posted by nikosidis

We can see from all NG Amiga versions. OS4, MorphOS and AROS that none succeed.

True.

Legacy Amiga 68k is by far the most used and developed for.
Vampire is another project that is kind of a success but what exactly
is there for that system? I mean, is there a single, original program or game of any quality?
What is the point with RTG?

I had an A3000 with 50MHz 060 and RTG. I sold that machine 20 years ago, but the idea of having something similar in an A500 or A600 appealed to me. So I bought a bare bones A600 off eBay and put a Vampire 600 in it. Now I have the equivalent performance of my A3000 in a nicer package, for less than 1/10th the price!

What the Vampire mostly brings is much better performance than any contemporary Amiga had. A few games (eg. flight simulators) and many 'productivity' programs suffered from lack of CPU power on stock Amigas. Things like web browsing, 3d rendering, emulation, compiling code etc. were the main reason many people bought accelerator cards 'back in the day'. Many of those programs also benefit from RTG.

Buffee is reasonable priced and seams like a fun piece of hardware as long as there are not to many problems regarding compatibility...

I like that it is only a CPU with RAM.

I like it too, especially if an A1200 version is produced. AGA is good enough that RTG is not needed for most stuff. RTG makes more sense for older machines, but just having a blinding fast CPU with heaps of RAM would still be very useful (especially if it is cheap). I also like that it plugs directly into the 68k socket on an A500 without taking up any more room that the stock CPU.

[nikosidis]

Bruce Abbott: I think the problem with A1200 is 32-bit. It is no doubt that it is with A1200 it would be perfect! A600 is also a nice alternative. A500 is limited since it would require extra hardware, HDD and chip RAM is very limited apart from A500+

[eXeler0]

Originally Posted by Bruce Abbott

I like it too, especially if an A1200 version is produced. AGA is good enough that RTG is not needed for most stuff. RTG makes more sense for older machines, but just having a blinding fast CPU with heaps of RAM would still be very useful (especially if it is cheap). I also like that it plugs directly into the 68k socket on an A500 without taking up any more room that the stock CPU.

Some projects are significantly easier cheaper for the A500 due to the fact that A500 had so many socketed chips so its easy to to small cheap stuff like the RGB to HDMI for A500, and Buffee..
While I agree that it would be nice to have that speed together with AGA, it looks like it would be a completely different design compared to the current one.
Best we can do is to support the Canadian wizards with this one and hope that they can move on to a 1200 version in the future ;-)

[Gorf]

The problem is really that the used ARM CPU only supports 8 and 16bit asynchron buses, but not 32bit wide ... and I did not find a CPU that does yet :-/

But on the other hand:
Every turbo card with a 68020 or better for the 500/1000/2000 needs to do some bus translation from 32bit to 16bit ... and I guess some of them at least for the A2000 did that in a bidirectional way to support Zorro DMA.

So there must be a way to translate from the 68k bus Buffee is expecting to the 68030 bus the A3000/A4000 are designed around - or to the 68020 bus of the A1200.

In the ideal case is would just be an adapter card with a CPLD on it and a socked for the very same Buffee ...

[d4rk3lf]

Very interesting, can't wait to see youtube videos testing it.

[Promilus]

@Gorf - not really. 68000 does 16bit data transfer always while masking valid data bytes through uds and lds signals. If it needs 32bit data it has 2x 16bit reads of adjacent cells.
020 and higher has different signals to handle things which makes things easier. AFAIK CPLD only has to decode whether amiga peripherals are addressed and then handle #DSACK0 and #DSACK1 signals to provide info whether port has to be 8bit wide, 16 bit wide or can be 32bit wide. So using full 32bit 68k implementation on 16bit machine (OCS) is quite trivial. On the other hand using CPU with 16bit data bus on 32bit machine (AGA) isn't quite that trivial as you need to use latches and 2 cpu bus cycles for each 32bit operation. It shouldn't be that hard (gpmc has plenty of headroom) but, well, it's not that elegant and efficient as native interface width, right?

[Gorf]

maybe not that elegant, but it could be very efficient - and certainly better than no Buffee at all.

[Gorf]

Originally Posted by Gorf

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

Turns out I was wrong about the "DMA support" - there will be not support for external DMA controllers using the internal FastRAM of Buffee.

There are some technical reasons ... for one it would not be straight forward with the chosen CPU and very difficult to implement using only the 68000 socket..

(I have some ideas how it could be done with some extra logic on the board, but that is not the goal or focus of the Buffee project)

While I do understand the reasoning behind that decision, it is clearly a bummer:

From the operating system point of view Buffee provides hundreds of MB of FastRAM, but all of it is non-DMA-able. So the OS has to make sure that no DMA controller (like on the A590 or many ZorroII cards for the A2000) tries to DMA into the address range of Buffees FastRAM.
Since this project aims to be systems agnostic this is clearly a drawback.

But even if we avoid the internal RAM: in this case the DMA controller moves data into slow old RAM on the motherboard, where access rates are terrible slow ... so we would need to copy the data over to the internal RAM - but there is no easy way for the user to do so.

So most likely DMA mode needs to be switched off, if the controller allows for it... but again PIO mode leads to a substantial slowdown, since Buffee needs to use the old slow system bus for this ...

You could mitigate this problem by copying programs or games over to a RAM disk or better RAD, and start them from there, to avoid any slowdown during execution.

I suggested a method of dumping the entire content of such a RAD down to the internal flash ram and restoring it automatically at first boot.
There will probably room for 1-2 MB that could be used as user modifiable ROM.

Sadly the developers chose a very limited 16MB flash chip ... an option for a bigger size would certainly make sense. While SPI flash is not fast, it is also very inexpensive and a 265MB or 512MB big flash chip would probably not need much more area on the board and be barely noticeable in the BOM.

[kipper2k]

For the flash chip size, i am not even closr to knowing exactly how a increased flash image would work.

My questions are that if you create a big WB image that loads into RAD when you boot up is... how would the image load speed compare to that of loading from CF card etc, and how could you create the image to write to the flash so that it boots up, is this something an enduser could do ?

[Gorf]

Originally Posted by kipper2k

For the flash chip size, i am not even closr to knowing exactly how a increased flash image would work.

My questions are that if you create a big WB image that loads into RAD when you boot up is... how would the image load speed compare to that of loading from CF card etc, and how could you create the image to write to the flash so that it boots up, is this something an enduser could do ?

The first obvious point would be: it is much better than any CF card, a user does not have!
And it is of course much faster than Floppy/Gotek...

IF the user has already some controller / card reader / hd ... it does not need to use the SPI flash RAD option.
Depending on how fast/slow the PIO mode of legacy controllers will turn out...

the image would just be a memory dump of a defined region - nothing to create there. The OS can treat this region in RAM as RAD, RamDisk, ROM-Image or whatever ...
Some escape code initiates a new dump of that region, if the user wants to make changes persistent.

[alexh]

The PiSTorm team just demo'd their new "SCSI device" and driver. 24MB/s uncached (off USB media), 700+MB/s cached (from DRAM).

https://twitter.com/Claude1079/statu...51062357671940

[eXeler0]

Originally Posted by alexh

The PiSTorm team just demo'd their new "SCSI device" and driver. 24MB/s uncached (off USB media), 700+MB/s cached (from DRAM).

https://twitter.com/Claude1079/statu...51062357671940

Holy crap, impressive numbers AND autoboot.

[Tigerskunk]

So many interesting crazy new hardware things to try out lately...

[eXeler0]

How is the Vampire slayer doing?

[Methanoid]

Originally Posted by Akira

Also very interested in this, especially because it'd be a drop in, baremetal solution. That Raspberry Pi thing someone had made, beats all purpose, by having to wait for a system to boot up, SSHing into it, etc...

Originally Posted by alexh

The PiSTorm team just demo'd their new "SCSI device" and driver. 24MB/s uncached (off USB media), 700+MB/s cached (from DRAM).

https://twitter.com/Claude1079/statu...51062357671940

I think Akira might be surprised if/when the PiStorm team get around to using a BuildRoot build rather than a RaspPiOS Lite to start up. I've seen videos on YouTube with 2-3s boot times on older Pi models. I won't expect that but I suspect they will improve load times a LOT