Buddha Performance in Stock A2000

I have never benchmarked this combination, but would expect that it's between 1MB/s and 1.5MB/s.

It is correct that A2091 and GVP-SCSI controllers will get more performance due to their DMA insterface. However, this turns around when you're installing an accelerator: That's when the SCSI controllers usually can't use DMA any more (because accelerator memory is not available to DMA cards in the A2000), and performance of SCSI drops really low, while Buddha IDE shines with 2.6MB/s real-world performance (not quoting 3.5MB/s raw data transfer performance, which is sometimes done with DMA controllers).

THere are more factors, such as "do I want lots of noise in the computer, or is a silent CF card the better choice"? The cost factor or a SCSI drive is surely not small, and with those 50-pin SCSI drives not being made any more, you will most likely have to go with something used, which may not be really reliable.

Yes, there are products for CF or SD cards on SCSI, but those adapters are usually more expensive than a Buddha controller. All that for a performance number that you will hardly feel in real life? Always remember that search times are mostly mechanical, and load times on an un-accelerated machine with 4M can never be longer than a few seconds.

While the SCSI controller is still waiting for all devices to respond on the bus, the Buddha controller may have already finished booting, despite it's lower performance. You know what they say about arriving quickly: It's not only about how fast you go, but how early you start.

Quote from chrisfi

I could even fit the LS-120 drive I have sitting in a drawer which I see is compatible using the Elaborate bytes firmware.

I would not go with the old EB firmware, as the new (current) firmware is more compatible with CF cards, which is probably your choice of mass-storage. The LS120 used to give real utility for exchanging data with a nearby PC, but today, not a single PC even has a floppy drive, let alone an LS120. The 120MB media is traded at prices somewhere between "virgin" and "soul", and the one true drawback of the drive only becomes appearent after a bit of usage: It won't ever read an Amiga disk, not even with a special controller, because it only knows PC-formatted media (720k and 1.44M, but not 880k).

For exchanging data with a PC, you might want to look at network. We have the AmiTCP installation disk, which lets you connect to a local network using DHCP (supported by any home router these days), and mount CIFS drives, such as USB sticks that are connected to (more sophisticated) routers, NAS products or shared drives of modern computers (not sure about MacOS, but Windows and Linux do work with CIFS). This will all work with a plain 68000 CPU on the Amiga side.

Quote from chrisfi

Would that be using the atapi.device driver from the idefix97 package?

The old EB drivers for the Buddha had their own atapi device called "buddhaatapi.device", which was built from the same source code as the IDE-fix 97 package. If you really want to try them for nostalgic reasons, there is no need to mess with yet another software package.

Just got answer from a friend who works with MacOS on a regular basis: CIFS is no problem there as well.

Quote from chrisfi

Thanks for the information Jens. Some very interesting and compelling points.

My A2000 has a GVP hardcard with 4MB RAM, HDD and CD ROM, but I want to migrate to SD/CF as my main storage. My choice is an expensive SCSI SD card or the Buddha which opens up lots of options for cheap IDE stuff.

However, after reading your points I’m now leaning towards the Buddha and keeping the GVP card just for the RAM.

Being someone that worked for GVP back in the day (Tech Support), I can give you some info on the GVP HC8.

DMA transfers to/from that on-card HC8 memory in a stock 68K system are hidden from the CPU. Technically, the memory is 14MHz interleaved, like just like ChipRAM is (when Agnus isn't being a thief for higher display resolutions). The DMA controller and CPU effectively alternate access and never compete. I/O happens while the CPU is free to do other things.

The net of this is that, aside from common FS and driver overhead, the OS and programs will have the CPU available to run, sometimes in excess of 75% depending on other activities you may have it doing. The CPU doesn't have to transfer I/O data between the controller and memory as (currently) all IDE interfaces on the Amiga must do. On stock 68K systems this translates to a more responsive system. If you have accelerator products in your system with higher performance memory on them, then the abundance of CPU power they can provide can shift the higher-end performance I/O values and response feel in favor of the IDE products. Also, the Zorro II DMA transfer crossing the expansion bus to other memory expansion loses the on-card hidden-transfer functionality (or must use the CPU to transfer between a Z2 memory buffer and high-mapped 32-bit memory, in some cases).

I have a Buddha (works well), many GVP cards, and many accelerators. Truth be told, I prefer adding a network interface. I have several for my various systems, including the X-Surf 100 (also works well). I use my home NAS (an older Netgear unit, but plenty of others are out there) for anything beyond Amiga boot and it's common OS/Application install points. I call a script (MountNAS) to activate the network and mount an SMB/CIFS shares on it. Saves Amiga memory until I need it, but gives me access to a common point storage where modern computers can also save to. FTP transfers are also an option on most NAS unit. The NAS is a great solution for full-system Amiga backups, too.

I do this as I am no fan of legacy magnetic media that is 20-30 years old, and that particularly of the removable media type, which will age out on us all sooner rather than later.