Posts by Timm

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

Quote from Jens

...which is why we're hosting a different version of CacheCDFS in our Wiki.

Not really. This sounds more like some mashup from different installations.

CacheCDFS 60.5 from our installation DOM should be the right one, together with the mountlist entries in Storage.

This was subject to some major cleanup in the latest software package. There should be no connection to buddha_atapi.device anymore in our software package, and I doubt we should have v42 around.

Quote from shan2752

The only other improvement I could wish for with the ACA 500 Plus is a more current file system with the included WB 3.1 install. Long filenames are a must with WHDLoad. It’s a pain to rename files to extract them on the A500.

The filesystem PFS3 is pretty modern, maybe the most modern available.

With the utility setfnsize you can increase the filename length to up to 107, I guess.

Please check out this thread: https://eab.abime.net/showthread.php?t=91088

Somebody says "Super long filenames create all sorts of trouble in many programs (like DirWork). Avoid.", but I haven't tried it myself yet. I have no opinion on that.

The choice of internet software for a plain Amiga 500 without acceleration is limited. By far the most important one for me would be a mounter for a network filesystem. We have included two mounters, for Samba and NFS, in the package. They are covered by the documentation and example configurations.

The problem with nfs and smbfs is just that they are increasingly going out of fashion because everybody else considers the protocols too old - which is actually not an issue inside a trusted home network. There is a new Samba mounter available which supports newer protocols, but it has got other problems.

We have identified this problem.

For downloading software I can now heartily recommend the program Lubricator 2.x from Aminet and the iComp share under X-Surf/Extras . You can even launch it from there.

With this program the whole software/demo archives of Aminet and Pouet are available to you with a graphical user interface, even on an unaccelerated Amiga 500 with at least OS 2.x.

But our support has to end at some point. There are innumerous ways and solutions for many protocols such as IRC, FTP, mail, I guess even on a plain 68000, many fairly outdated, others still totally recommendable. But it's difficult to keep track and to give recommendations. This is something more for Amiga user forums.

Also it shouln't be too easy on a 68000, we still want to sell some accelerator cards.

With a 68030 browsing the WWW is just barely possible. The only problem is, there are few websites which limit themselves to such old specifications that it's any fun. But there are some fringe solutions even to that, for example by setting up all kinds of funky proxies.

- What you describe as "software messy" could be a graphics refresh issue with OS3.2. Do you have the possibility to use ROM 3.1 during installation? This is what I'd suggest for various reasons, at least with our installer (see the README for a more lengthy explanation).

- That the CDROM is listed in the menu, but cannot be clicked, is as expected. This is just for information and for you to identify the devices. When installation with our installer is successful, the CDROM support should be installed in the system, and you can activate it with the device icons in SYS:Storage/DOSDrivers (and move the appropriate icon to SYS:Devs/DOSDrivers if everything works as expected.)

- This message "device needs updating" in itself is pretty harmless. This is equivalent to the update that HDToolbox complains about when a device has been added or removed, or the order changed. The idea behind this was that in times with slowly spinning up harddisks the time for searching bootable devices could be reduced. It's some kind of "software-side bus termination". Other tools like HDToolbox should be affected and complain in the same way.

The question remains why the update with our software didn't work.

Indeed, an installation is not needed for CDROM support. You can also activate a CDROM by clicking the appropriate device icon in Storage/DOSDrivers. (However, for this to work, the system must have access to BuddhaCDSupport/L/CacheCDFS. So if you haven't installed a system with our installer or didn't boot from the DOM, you need to copy CacheCDFS to SYS:L .)

In face of all this positive feedback, here some self-criticism:

The CF slots are delicate and prone to bent or broken pins. Please treat them very carefully. Do not change cards too frequently.

Changing the ACA500+ between A500s is also prone to failure. I've managed to misfit an ACA500+ so unluckily (don't know how) that it destroyed the ACA500+ and the Gary chip. Please be careful when changing the ACA500+ card and CF cards on it, so you can enjoy it for a long time.

The solution is, in my opinion, to order an X-Surf-500 to get rid of all the mechanical stress. I honestly believe it's worth the extra money.

I recommend that the mountlist entries go to Storage first. Then, when the right ones are working and do what you want, you _can_ move the respective entries to Devs for mounting them on system boot. As long as you're having problems, please park them in Storage, now, and also other devices in Devs/DOSDrivers that look like they might be CD-related.

Then, please perform a version check on CacheCDFS:

# version full file L:CacheCDFS

BuddhaCacheCDFS 60.5

It looks like something else is installed with regard to CDs. Please try to identify things in Devs/DOSDrivers, WBStartup and S:User-Startup that might interfere, and move them out of the way. There is no "3.9" related text supposed to appear with Buddha's basic CD support. The basic support requires only buddhascsi.device (in memory, from the controller itself), L:CacheCDFS and the right mountlist entries. The tools in BuddhaCDSupport are useful, but optional.

Basically just CacheCDFS from BuddhaCDSupport:L/ and mountlist entries in Storage/DOSDrivers.

The first goes to SYS:L, the second to SYS:Storage/DOSDrivers/ .

In addition to that, you can copy CDFSPrefs to SYS:Prefs/ .

There's not much magic in what the installer does.

Hm... no idea so far. Would we know anything else, something smaller, using IPX besides ADoom?

Our network drivers are SANA2, and in no way special.

When it just doesn't start, I'd suspect some setup problem.

On our driver's side you might want to try the options

DEBUGLEV 1

to see if the driver gets initialized and if there's some activtity, and

NOAMITCPOPT 1

- just to be sure, shouldn't matter if AmiTCP isn't used.

Yes, this could be consistent with the 'Failsafe'-jumper being set.

Please remove the jumper from the ACA1221lc, it's normally not needed, or not anymore.

I can't confirm this. This works as expected from commandline and GUI. I switched forth and back several times. With the 14MHz setting I have fastmem. Writing the config to flash was no problem.

It cannot be seen on the photo, which screenmode was that?