Posts by Timm

The list of devices and assignment of ports and device numbering is clearly documented in in the README on the DOM.

With some ASCII diagram and table.

The changes were also in response to customer feedback, including yours.

I don't quite understand what you are talking about here.

"CD drive gets uninstalled after a reboot".

What?

"Do not use the DOM or it will corrupt your WB OS3.2."

This is wrong, or a bug of such grave consequence that it's hard to imagine how it would have escaped our attention in innumerous tests.

The complete procedure of installing OS3.2 from CDROM with or without 3.2 ROMs is described in great detail in the README.

You do NOT have to remove the DOM. And certainly the presence of the DOM should not corrupt anything.

This is purely anecdotal: I had a Yamaha SCSI-to-IDE and a CF adapter in my A3000. Because the SCSI cable is very old and brittle, it repeatedly gave me errors on even minor concussions of the A3000. So I took the CF card into the Buddha+1, disabled the Onboard HD, and never looked back since.

Edit:

Yes, I understand that this wasn't the question. But you should perhaps first try and make sure that the CF works from the CF slot.

But we do have this particular information in our package:

AmiTCP:doc/Interfaces.txt

Add network interfaces in AmiTCP:db/interfaces. Nothing should limit our network setup from using Plipbox or other interfaces. If it doesn't show up automatically in the Advanced Settings, INTERFACE can also be specified in the icon tooltypes.

We have streamlined and stripped down the AmiTCPv4 package to ethernet use, and enhanced it with DHCP support and GUI instead.

SLIP, dialing, and PPP have been removed from the tools and documentation. But it's still the original AmiTCPv4. You could perhaps acquire an AmiTCPv4 license key with our package, and complement it with or use the AmiTCPv4 demo from Aminet, and use it according to the documentation provided with the demo. I'm not sure if this is a sound idea, and we certainly can't provide support for the parts which are not included.

Quote from Jens

You are not paying for any drivers - they are included for convenience. We're including drivers for the old 10MBit X-Surf card, the new S-Surf-100 and X-Surf-500 cards, and in addition, the archive contains the cnet driver for A1200 PCMCIA networking cards, which is freely available on Aminet.

Minor correction: We are including the drivers for all X-Surf products in our "default" network package. On the ACA1234, the PCMCIA drivers cnet, cnet16 and 3c589 are included for convenience.

Quote from A3000T

have a set of 3.1 ROMs for my A3000D and I will install them and load OS3.2.2 and see how that works.

- You will find OS3.2 not working on OS3.1 ROMs if it was installed on OS3.2 ROMs.

- You will find OS3.2 working on OS3.1 ROMs if it was installed on OS3.1 ROMs (obviously) and you will find it working on OS3.2 ROMs.

Hence the recommendation: Install OS3.2 on OS3.1 ROMs. You can take the installed system to other machines with OS3.1 ROMs.

Already explained here

Quote from A3000T

I don't need 1.3. I may have selected 1.3 from the buddha install in stead of 3.1. I corrected it. The OS3.2 manual states if I have 1.3 on my HD I can install 3.2 on the HD and any incompatible files will be removed and OS3.2 will be installed, which works great. Thats how I been installing my O3.2 and NOT mixing any OS's. The only problem was due to the first buddha IDE as I explained on previous posts.

Why is 3.2 ROMs a bad choice? This right from Hyperion who owns the Commodore / Amiga rights. I have been using OS3.2 and it is very stable. Please explain why it's a bad choice.?

OS 3.2 ROMs are a bad choice with regard to compatibility with other OS versions. That's not to say that OS 3.2 Workbench is a bad choice in general.

We went to great lengths to extend the compatibility of the Buddha product to OS 3.2 - also due to your and other valued customers' feedback. That was challenging when the user has OS 3.2 ROMs installed, because 3.2 has moved several system components from ROM to disk, and this becomes a problem if the user is not installing a 3.2 WB, but some other version.

The Buddha product comes with licenses for WB 1.3, 2.1 and 3.1 - OS 3.2 is a separate product. What's important in this context is that our installer is an option that solves many problems that users often struggle with if they install WB versions up to 3.1 for the first time, especially on big media.

If you are entirely happy with just OS 3.2, you can install 3.2 with the 3.2 installation procedure, and leave the Buddha's installer alone. But then you are on your own with regard to CDROM/DVD support. Of course there is a licensed CDROM filesystem handler and CDROM mountlist examples in Storage/DOSDrivers on the Buddha's install DOM. Installing these, if you are not using our installer, is a manual procedure - albeit harmless, for Amiga experts.

Since the Buddha's installer update to version 1.4, it is possible to install WB 3.1 on OS 3.2 ROMs, and you get CDROM/DVD support provided by our installer. It is then possible for the user to keep the WB 3.1 installation - or to update it to 3.2.

It's about options. My personal recommendation is to keep OS 3.1 ROMs, even if you intend to install 3.2, because this results in a more compatible setup. It results in an installation of WB 3.2 (and 3.1, if you are using our installer) that can work on both OS 3.1 and 3.2 ROMs.

See also the README on the Buddha DOM for some more of the peculiar details.

I just tested booting WB 1.3 on OS 3.2 ROM.

This looks exactly like in your screenshots. Unfortunately, WB 1.3 does NOT work properly on OS 3.2 ROM.

If you need WB 1.3, you must remove the OS3.2 ROM chips and replace them with OS3.1 ROMs.

For compatibility, OS3.2 ROM chips are a very bad choice.

With OS3.1 ROMs everything works - WB 1.3, 2.1, 3.1, 3.2.

This is a very unexpected situation: WB 1.3.3 on OS3.2, and Device pipe: already mounted.

The Pipe handler happens to be used in the Buddha Update/Restore procedure. To me it looks like you might have copied the Update/Restore package - partially or in its entirety - over a former installation, on SYS: level. The Buddha Update/Restore package comes in a directory/folder of its own, and it needs to be invoked from this directory, No manual copying is involved.

I'm not sure if that can fully explain it, but if that was the case, this cannot be corrected. A new OS installation would be required.

Our OS installer shows the right version (1.4), so at some point the Restore/Update procedure went through, or was not needed.

Edit: Or maybe it's much simpler than that, and these screenshots are simply showing a WB 1.3 installation on OS3.2 ROMs. WB 1.3 installations (probably) would not work with OS3.2 ROMs. Sorry for speculations. We just need to understand what was going on here.

When does it show up what's shown in pictures P1010200.JPG and P1010203.JPG?

Do you initiate something manually or where/when does this appear?

What's confusing in the pictures is that it reads 3.2 ROM, 1.3 Workbench, and it looks like you are repeatedly trying to install the Buddha Update/Restore package in this setup. (This makes no sense. It would be wrong to copy things from the Buddha Update/Restore package to the DOM - see Buddha Update/Restore documentation.)

Quote from Jens

The choice of FFS or PFS is only for harddrives, not the CD drives. The installer should actually prefer PFS - I wouldn't know why it may grey out the option.

PFS is absolutely preferred, and the button is greyed out if according to the automatic partitioning scheme a partition is created which I considered too big for FFS. In that case, it reads PFS, and FFS can't be selected. For this I have set an arbitrary limit of 2GB.

There is indeed a limit to the maximum number of screenmodes in the list.

There is certainly a limit in the hardware, and the software limit is not taking into account that there are preset modes in the list that cannot be removed. Also it doesn't take into account that some modes might not be enabled.

What sailor said - that should be it.

The 'Network' tool does no major magic besides managing the configuration files in AmiTCP4:db/ .

We have just added our own network drivers and a few other popular ones to the db/interfaces file as presets.

I can totally understand the desire to tinker with this kind of stuff. I did this myself at some point, and it was AmiTCPv4 if I remember correctly. I made a disk that was able to boot an Amiga from floppy disk, and then continued booting a fully featured Workbench via NFS from a fileserver. That gave me an Amiga "thin client", and all I needed was some network adapter and a boot disk. Quite some fun.

I am fairly confident that both AmiTCPv3 would work with our drivers, and also that AmiTCPv4 can be made to fit on a disk. There should be no substantial hurdles. It's just that you are on your own support-wise. I found AmiTCPv3 annoying to configure and work with. And putting a TCP/IP stack on a disk isn't the most common use-case. Use a working installation of AmiTCPv4 from our network package. Start by cleaning up a Workbench disk, copy the contents of the AmiTCP directory on this disk, place an assign on it, remove all unneeded drivers and documentation, etc. But you will likely need to pull some more tricks to save diskspace.

TCP is a rather high-level protocol, and with a HW interface as fast as the X-Surf-500, performance is very CPU bound.

True (not artificial, not hypothetical) network speed can be measured for example with the program ttcp. Of course you would run the other end on a very fast computer such as a Linux PC.

68000, 7MHz: 139,53 KB/sec

68030, 50MHz: 1770,66 KB/sec

In my opinion that's pretty cool, and our adaptations to AmITCP make it not only fast, but also very user-friendly. So there's probably no need to change to Roadshow, since our solution is at least as good. But Roadshow is also a very decent product, and if you want to support the Roadshow author, you can do this, and even continue to use our Network GUI with Roadshow.

Also a very useful test is to measure the time needed to copy for example a huge file over NFS or SMB from/to a Linux server.

Edit: For comparison, and to show how well our hw/driver/TCP stack combo performs:

68060, 50MHz: 1561,78 KB/sec

That was on an Amiga 3000 with Cyberstorm MK-II 68060, X.Surf-100, and Roadshow. IIRC with AmiTCP that should be somewhere between 1900 and 2000KB/sec.

No