Posts by Timm

I don't remember the situation with OS3.1.4, I have seen it only shortly and then OS3.2 came out. OS3.1.4 caused a lot of trouble with our products and we're glad it's history.

OS3.1 ROMs are most likely the best option for compatibility in all directions, especially if you include things like demos and games - we in individual Computers certainly do.

We have several software updates and new products in the pipeline to aid with switching ROMs and help with compatiblity, and with special regard to OS3.2.

As in OS3.5, neither ROM files nor physical ROMs are needed. OS3.2 ROMs can pose some nasty trouble and catch-22 situations in the real world, and this includes a variety of our own products. I consider installing (and operating) OS3.2 on OS3.1 ROMs more reliable and generic, because OS3.2 removed some important libraries from the ROM. This was a really bad idea in my opinion.

/N is numerical modifier, /S is a switch, /K requires the keyword. Please consult your operating system manuals for more details.

Assuming we are talking about acatool 3.0.1, and applying only to the ACA1234, as stated in the documentation:

Use the GUI to save settings. [...] It is now possible to map a ROM file once, without saving it to flash and making it a permanent change (see ROMFILE option, only via command line).

In other words: The ROMFILE option maps the ROM file only once on the ACA1234 - so you can check if a ROM file is functional and behaves properly. It's not getting saved via command line, the setting is made permanent only if saved via GUI.

This of course doesn't explain checksum errors.

The recommendation for OS3.2 is: Use your OS3.0 or OS3.1 ROM during installation of OS3.2. Later check if you can map the OS3.2 ROM successfully - and in the case of the ACA1234 this can be done with the command line and the ROMFILE option.

I can reproduce the problem under both OS3.1 and OS3.2 with ACA500, X-Surf-500, ACA1233n, and MMULibs. The driver fix above should have fixed the issue, but didn't. We might further investigate the issue, but cannot promise a fix as of yet.

MMULibs are not required in this combination - I'd suggest to not install them, and remove CPU CHECKINSTALL from OS3.2's S:Startup-Sequence.

I've tried it again and written the demo to another disk, and this time it works on my OCS A500 512k+512k, Kick1.2.

And I can confirm that it doesn't work with the ACA500+, Standard A500 Profile menu, neither F1 nor F4 Standard A500 KS1.x + 0.5/0.5M. The demo freezes when setting up the logo on the fake DOS screen.

Resetting the computer then freezes in the ACA500+'s dark blue screen. Nice find!

The demo as it can be downloaded from Pouet seems broken, it doesn't work on a plain OCS A500 with 1mb either.

Just for the record, the A3000 I am testing with are not with SuperKickstart, but with 3.1 ROMs.

I just tested an A3000/030 with a X-Surf-100 and OS3.2 (v47.7) installed.

I installed mmu.library from Aminet (v47.4).

I'm using our AmiTCP package and x-surf-100.device v1.16.

Network works like a charm.

The only possible differences would be the exact versions of OS3.2 and mmu.library.

Or have I missed something?

Quote from Jens

If mmu lib is present, it's instructed to switch off data cache in the IO area of the X-Surf-100. At least that's what I remember; Timm will be able to confirm, he did the last changes to the driver. TBH, I'm not 100% sure about the MMU stuff.

No, we employ a different solution - data caches are freezed on affected machines for short sections if and when needed. Indeed, this works fine with A3000/030, it doesn't require mmu.library, and was faster IIRC.

Maybe we should ask Hyperion if they provide a couple of ROMs for compatibility testing. OTOH, if they didn't care in the first place...

Quote from A3000T

At this time the Buddha IDE can only work with the new OS3.2 OS with the 3.2 ROMS. It won't work with my old OS3.1 40.68 ROMs or any other because it needs the 3.1 OS files it will come to a shell screen as WB is not loaded.

That's not correct, I have a working OS3.2 installation in an Amiga 3000 with Buddha controller and OS3.1 ROMs.

Quote from A3000T

I installed the latest buddharestore.lha transferred it to the DOM and did the "update" and "restore" as directed. Rebooted to BuddhaInstall: and did the install process, rebooted to BDH0: and I got the same message still need the files in the Libs directory which is the workbench.library.

So the issue is now that you installed OS3.1 with our installer with OS3.2 ROMs installed to your computer, and now you're stuck without the libraries, because they're neither in ROM nor in the resulting installation. In that case simply do not use our installer, but OS3.2's tools for HD setup, partitioning, and installation. The device is buddhascsi.device.

Normally there's no other config needed. It's really just copying the device driver to AmiTCP:Devs/ and adding an appropriate line to AmiTCP:db/interfaces. All other AmITCP config files are managed by the Network tool automatically.

If settings were not saved before, there's even a chance that the Network tool probes the known interfaces until it finds one that works. In the Advanced Settings window (or in the Network icon tooltype INTERFACE=...) the interface can be specified.

ROMs which lack important parts of the system software were a very unfortunate design decision, to put this politely. You cannot blame the Buddha product for later OS developments going haywire.

With 3.1 ROMs you wouldn't run into this issue, even with OS 3.2 installed.

Regarding the Installation DOM: You can revert the BuddhaInstall volume (not the entire DOM, just the install partition) to the state of its delivery, if you are using the BuddhaRestore package in the intended way. DO NOT unpack the contents of the BuddhaRestore package to the DOM. Unpack buddharestore.lha (see attachment) to RAM:, SYS:T:, a floppy disk, or some other directory. Open the directory on the Workbench, read the README, follow the instructions. This procedure has been tested with OS 3.2, just not with 3.2 ROMs.

Edit: I mention the above just for completeness, because you insist on getting back the Installation DOM's factory contents. It appears doubtful to me that you really need to run the BuddhaRestore package yet again.

We do not ship OS 3.2's workbench.library - it didn't exist when we packaged the Installation DOM.

If you insist on using 3.2 ROMs, just do what the requester in your screen photo is asking for: Insert a volume containing LIBS/workbench.library in any drive.

Quote from Tobias

You could just flash a blank file of course :=)

What gives you the idea that the config tool would let an empty file pass as a ROM? =)

It's not recommendable to really erase a slot, but the next version could allow to erase out the name.

The DOM with the install partition shows up in your system and you can start the InstallBuddha program, so that's great.

The contents of the BuddhaRestore package were not supposed to be copied over to the BuddhaInstall volume. Now we have to repair the contents of the BuddhaInstall volume from our attempts to repair it. Let's forget the BuddhaRestore package, which was meant to restore the installation DOM on a much deeper, on device level.

I have attached a lha archive that contains everything that is important on the BuddhaInstall volume. Please copy over the contents of the archive to the BuddhaInstall volume, or unarchive it right there:

cd BuddhaInstall:

lha x buddhainstall.lha

Then the Buddha installer should come up if you boot from the BUDDHA_INST device in the boot menu, or if no other devices are connected. There might be some unneeded garbage on your BuddhaInstall volume now, but this shouldn't matter.

From this point, we can work through other issues.

It's not supposed to be copied to the DOM.

However it seems you don't need it - if you have the BuddhaInstall partition mounted on your Workbench, all is good.

You can split files for transfer, but after transfer and unpacking you'd still have to transfer the ADF file to an Amiga floppy disk.

If you don't have a floppy disk drive, there are various ways to mount a disk image on the Workbench.

The intended use of the package is to make sure that one can get the BuddhaInstall partition back after it became invisible (from rearranging, adding/removing devices), or if it was rendered unusable (e.g. from overwriting the rigid disk block). If that's not the case, then there's no need to use it.

If you see the BuddhaInstall icon on your Workbench, then all is fine, at least with regard to the restoration package.

(Not sure if I can follow what took 6 hours. The lha is supposed to be decompressed on Amiga, Mac, PC, or whatever. It then produces an ADF file, an Amiga (floppy) disk image. Booting from this disk, you can perform repair operations, 'update' the drives (only needed if it says to do so), or 'restore' the Buddha install DOM to make it visible again if it was destroyed/overwritten.)

Sorry, but here's another update. This disk allows you to not only restore the install partition on the DOM, but also to perform the changes hdtoolbox would do when devices have been added or removed on a given bus/controller.

As it turned out, it can happen to everybody (regardless of cultural background or temper) to connect a device which has a termination mark, while there are devices with higher unit numbers on the same controller - which in the case of the Buddha controller can make the installation DOM invisible.

The disk can be booted from, in this case you just have to follow the instructions. Invoke 'update' if an update is necessary, then retry. If the installation DOM is still not available, do a 'restore'.

Alternatively you can enter a shell and change to the disk, then you have the same commands 'scan', 'update', and 'restore'.

We're also working on the CDRom issue, but this may take a little longer.

Edit: The BuddhaRestore package has been supplied with a README and updated to work with OS3.2, from Workbench, shell, and from booting the disk, just in case someone else finds it useful.