Posts by Timm

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.

    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.

    Could you please test the attached version by copying it to AmiTCP:Devs/Networks, and report back if it fixes the problem for you? It's for the ACA500 (non-plus) only. It contains a mmu.library workaround.


    Sometimes mmu.library solves problems that you wouldn't have without mmu.library.

    Therefore my general recommendation would be to not install it unless you know why and have a compelling reason to.

    There will be a meaningful speed increase (roughly double) compared to 1.15mb/sec, but no speed increase compared to the A3000's internal SCSI controller.

    In DiskSpeed 4.2 I see 2,89mb/s reading from my A3000's internal SCSI with a SCSI-to-IDE adapter, but only under optimum conditions (huge reads into a huge buffer). I do not currently have a very useful IDE device on the Buddha, testing against a DOM yields 1,9mb/s under optimum conditions.

    xsurftest is somewhat adapted to the X-Surf-500, but not all outputs make totally sense. Attached. The output I get here:


    nic=ee0000

    Searching for RTL8019 at 0x0...not found! (ID0=255, ID1=255)

    Testing 16bit memory...ok!

    Ethernet address = 28:cd:4c:ff:f4:9d

    Chip is in PnP mode

    Chip is using half-duplex mode

    Chip is using IOBase 0x300 and IRQ 2/9

    Board address = 0xee0000


    IRQ / Loopback / cable connection test in progress:

    IRQ received ok.

    Packet send......via 100Mbit/s full duplex!

    Attached you find our internal 'devicetool', which allows for a device-level test. You can invoke it with e.g.


    # devicetool -d acf0: test

    This will perform a read, write back, read back, and compare cycle on the first (WB) partition that our installer creates.


    A stricter test mode:

    # devicetool -d acf0: test -t 1

    This will perform an additional write, read, compare cycle with random data.


    This might help to narrow down issues to device or filesystem level. But it will take a very long time with a 32GB medium.

    If this test shows an error, the next step would be to try another medium and see if it it is reproducible with that.


    The test is supposed to be non-destructive on good media, but you shouldn't entrust it really important data.

    We're not doing support for emulators. :-)

    Just kidding, and since you already bought an x-surf-500, here it goes:

    For *UAE incarnations, enable bsdsocket.library emulation. Then you don't need a TCP/IP stack installation or network configuation anymore. The emulated Amiga then simply participates in its host computer's network configuration. You can of course use all services then, including mounting the iComp share. Try using our 'Network' configuration tool (without starting TCP/IP another time), or fiddle the smbfs command line from the 'Mount iComp' icon and excute it manually.

    OK, if the emulator locks up, we can definitely exclude a hardware fault and must look for a reliable tool to test memory. Suggestions?

    There is no reliable tool without the source code. MBRTest-2 is fishy, let's move it to the trashcan. I cannot reproduce MBRTest-2 crashing under fs-uae, while It failed to list all memory that is shown in showconfig. I could reproduce MBRTest-2 freezing on the ACA1234 with mmu.library in place, while http://aminet.net/util/misc/pmemtest.lha works in this configuration. MBRTest-2 works with the ACA1234 without mmu.library. So far, the picture isn't conclusive.

    Oh wait - this may be unrelated, as you wrote you were using Roadshow. The iComp share mount script and icon is intended for use with our 'Network' config tool. The 'Network' tool can work with Roadshow, too. In any case, you may be able to extract the command line for mounting the share from the script behind the icon, regardless of TCP/IP stack and config tool.

    The firmware upgrade procedure is now painless, quick and not very dangerous, and if it says "No errors occured." you can be sure that at least no additional harm is done. :-) I cannot totally rule out (I'm confused too) that perhaps more than just one issue is at play here. But the general answer is: Yes, the CPLD update is supposed to sort out the rest. The hotfix blocks the offending 1mb of memory, that's all. We have tested this against MBRTest-2, but I did this only on an ACA1234 in an A1200.

    I have observed the same behaviour once or twice during development of acatool for the ACA1234, but it happened only with a OS3.2 ROM file, if I remember correctly. I did the same - reset the configuation, and tried again (not from floppy), then it worked. I'll try to reproduce this once again.

    I can confirm that both X-Surf-500 and FAT formatted CF media work when the system was booted from the ACA500+ with an ACA1234.

    Did you boot the system from the ACA500+ or from the ACA1234's internal CF? Both is supposed to work. Perhaps this makes a difference.

    • The internal CF is bootable, a CF on PCMCIA is bootable only if it's Amiga-formatted. FAT-formatted CFs on PCMCIA are swappable, but not bootable.
    • There are four 512k ROM slots, of which one is occupied with Kick 3.1. The option to compress kickstart images didn't make it into acatool yet.
    • You plug in the card, and if you have an IDE drive already, you see our install disk (mounted right off flash memory) on your Workbench and can run our OS installer there, copy acatool (with CPU, IDE and a some other options) over to your existing system, or mount a network installer.
    • If you do not have any mass storage yet, just insert an empty CF card in the internal CF slot, turn on the computer, wait up to 30 seconds, and our OS installer should boot up automatically.
    • If you happen to have a PCMCIA network card (and if you're lucky), you can possibly get your Amiga into your home network right off the ACA1234 and install more software via network. This has been added as a bonus in a last-minute decision.
    • On an ACA500+ most functionality in acatool is disabled, as the ACA500+ covers most of it.
    • Please do not exchange CF cards on the ACA1234's internal slot too often, it's not meant for swapping. Consider it as a stationary mass storage. (I've bent pins from very frequent exchanging cards during development.)

    Hi, without having looked into all details of the conversation yet, we have the known issue on OS>3.1 that SYS:WBStartup is no longer in the path. You can either specify the absolute path to the 'Network' command, add SYS:WBStartup to the path, or as a dirty workaround, make a copy of 'Network' in C: or somewhere else in the path. This should make the iComp share appear on double-clicking its icon. Other networking functionality is not affected to my knowledge.