Posts by thebajaguy

My first few rounds with the Buddah didn't get me the results I expected. I put 3.5 years in at GVP Tech Support back in the day, working on SCSI and IDE devices as one of my main focuses, and the 'modern' process on Buddah left me scratching my head.

My eventual method was: Disconnect power or data cables from all other non-floppy devices so they are not 'present' in the system at boot time. Put the DOM in where it wants to be, connect your target IDE drive to the other connector. Follow the instructions again, and the drive could be found and partitioned. Once you have it set up, re-introduce the other drives.

You might want to provide the output of ShowConfig with the Debug option for the BigRAM - it might help ID what the OS is seeing.

First and fourth under the Sold Out group:

The following products are sold out:

ACA1233n (2016, 2019) - For the Amiga 1200. It is also compatible with the ACA500, ACA500plus and ACA2000.

ACA1230 (2010 - three models) - For the Amiga 1200

ACA630 (2010 - two models) - For the Amiga 600

ACA1231 (2011 - OEM product for Vesalia) - For the Amiga 1200

http://wiki.icomp.de/wiki/ACA1233n
http://wiki.icomp.de/wiki/ACA1231

The code underlying HDToolBox has been described by the devs to be somewhere between spaghetti code and a Pandora's box. I believe there is an effort to rewrite it from scratch for a future offering.

That being said, I've got my hands on the GVP-m Fast/ExpertPrep code. That kind of thing is not a problem there, although one does have to use Enter to effect a partition geometry recalculation in some cases. I am working on it, to make it large-media compatible, but I've been low on time to sit down and dig into the math and GUI updates needed.

My take on Classic Workbench is that it's what the maker considers the available/updated 3rd-party 'gotta have/wanna have' components, icons, and/or various tools that made or enhanced various parts of OS 3.1 back in the day, or the 3.5/3.9 from the 1999-2000 era - all in one place to install. Some like it applied over the more current OS 3.1.4/3.2.x releases to make up for many of the 3rd party components which are not included in the OS - as they are not licensed to be in the distribution as with the older 3.5/3.9 era.

I'm not an WHDLoad'er - I like all my stuff in hardware. I deal with the virtual compute world every day at my day job

HDToolBox will appear in the Tools folder on most newer official release Install media. Device driver name goes in the tooltype (Info on the Icon / Workbench menu) if not scsi.device (is case sensitive), or on the command line as the first parameter if via command line.

Quote from HorseDemon

I'll drop in here and give updates when I can. I just formatted and partitioned an 8GB Flash card. Trying to find info on whether or not the ACA1234 install tools automatically set the correct "maxtransfer" or not. (I can't find an HD Toolbox in the WB 3.1 that it installs.) I've REALLY been away from Amiga tinkering for very, very long and it's showing, so it's a re-learning process.

The updated OS 3.1.4 / 3.2.x HDToolBox on the Install disk has that detail on the Advanced page for each partition. It's generally safe to update Mask (on DMA controller systems) and MaxTransfer (on IDE or SCSI) from the C= safe/unsafe? values the past OS tools defaulted to. Remember to tab out of the edited field or it has a tendency to ignore the field edits.

Alternatively, the old GVP prep tool ExpertPrep on page 2 has the visible MaxTransfer value for each partition. (Don't use it to save any modern boot blocks - it's not safe to save changes over modern RDB tool's settings.)

Some common problems, as noted, include the DSL packet encapsulation problem, which reduced the common packet size down from 1500. It was seen frequently when it was a common ISP service offering, and Windows 3.x/95/98/2000/XP was popular with then-less dynamic TCP/IP protocol stacks.

Another problem I have encountered (in other circles) includes ISP's that convert to IPV6 and/or encapsulate traffic over an internal VPN from their router at your place to their regional border routers. This can further impact the packet size, and also hides what is really happening to the packet. If you can tracert (PC TCP/IP command line tool) to your target Internet host(s), and it seems abnormally close - with only 1-2 hops before you 'leave' your ISP-named router gear - you are likely getting encapsulated within your ISP's local/regional network, or they gate directly to a datacenter with additional internal hops that are masked by a proxy (that will not show with 'tracert').

This is a PRIME example of the latter:

Tracing route to http://www.icomp.de [81.95.0.34]

over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms Fios_Quantum_Gateway.fios-router.home [192.168.1.1]

2 7 ms 6 ms 7 ms icomp.de [81.95.0.34]

Trace complete.

And I'm in the USA...

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.

Pulling S.M.A.R.T. data from the 'pages' of the disk drive command and data environment are more an art than a science. It's about what was implemented (if at all) by the device manufacturer, and if they understood what they read into the specs, and how it may apply to their implementation (if they spent the R&D to do much at all). You can dig up a good amount of data on S.M.A.R.T. from the Linux SCSI implementations, but for the most part, you would be doing direct driver (HD_SCSI_CMD) type commands to the interface of the IDE device.

Quote from jbbolcato

(A3660 on the way, may misbehave again!!)

You will have to give up your SuperKickstart load system with anything higher than a 68030 CPU.

You will want 3.1.4 (at the lowest) for a 68060 compatibility with Kickstart. You may as well get the 3.2 or 3.2.1 ROM burned if you plan to run with the latest Amiga OS.

For a system comparison, I'm using an A3000D, 3.2 ROMs and OS, 16MB / 2MB, A3640 w/060 Rev 1, , and the 2x wait state removal GALs. It has Buster-11. Mulibs: MuLibs 68060.library 46.5, mmu.library 46.22, I do MuMove4K during S:StartupSequence, and in S:User-Startup I enable FastROM , MuFastZero with FastExec and MoveSSP, and MuFastChip. An AmigaNet (Z2) board is the normal networking interface in the system on the third slot down. No other cards normally. I put the X-Surf 100 in the top slot when I tested it.

In my mind, about the only thing that might be out of the ordinary is the SuperKickstart soft-load state of the machine. It adds a level of complexity as the Kickstart loads and is MMU-protected, then soft-reboots into that new code, re-performing AutoConfig but having an MMU state from the previous boot. As to why it set it like it did, I'm not the right person at this point. I wasn't aware of the X-Surf-100 driver being MuLibs aware, either, and supposedly updating it's cache status. I didn't load any driver for the X-Surf - I only used the ShowConfig and MuScan tools output. I defer to Thor and Jens at this point. That you have it working is good.

I would assume the SuperKickstart boot and MMU configuration is a corner case that is difficult to test without real hardware in hand.

If you notice the next address section, which covers the address space all the way to 0xFFFF.FFFF, know that the entire upper 2GB of address space (from 0x8000.0000) is 'off limits', or in other words, does not exist and cannot be used as far as the Amiga OS memory map is concerned. Hence, Blank is not a good sign.

I plugged my XSurf-100 into my A3000, and it places my board at the same address space as yours.

I am getting 0x40000000 - 0x4000FFFF CacheInhibit I/O Space

That is typical of an I/O board. I believe the command line you want to match that (for testing) is:

MuSetCacheMode from 0x40000000 size 0x10000 CacheInhibit Valid IO

If that works out, you can likely modify one of the video board entries like the first VA2000 line in ENVARC: MMU-Configuration to instead recognize product 4626 100. The parameters {base} and 0x10000 look like a match for this situation.

That's my guess - and if it works, the board can move to a new address with other expansion added, but not need any adjustments. I can't say the same for any additional boards in your case. Save a copy of the working config so that you have a reference if an updated MuLibs comes out.

The X-Surf area at $4000.0000 should be marked CacheInhibit, and not what is in there. That will be your issue as it needs to be a valid non-cached address space.

"I/O Space" is normally just a readability label. The swapped position with the word "Invalid" is interesting, but I think the latter is still the state of the address region.

SuperKickstart does add a layer of complexity. It has to use the MMU to load/enable and keep the soft Kickstart active during a reboot, but then apply your 'fresh' booted system's memory space needs each time.

MuScan just reports the state of the MMU's table. Modifications are made with the MuSetCacheMode. You also program the initial setup state of the MMU when SetPatch loads and enables the library/MMU configuration from the config file in EnvArc: That file also has some commented out sections and configuration option detail (if present). Otherwise it uses CPU library defaults.

I think getting the state of the MMU / cache settings against the I/O space may be helpful. Use MuScan (if not in the lite version with 3.2.1, get the full version of MuLibs from Aminet). The address space where the X-Surf is placed should be set in a non-cache mode address space. I'd put this in Thor's court if it's mis-set.

To modify the MMU settings for a specific address region or card, you will have to pull out the MuLibs manual to use the MuSetCacheMode command, or update the config file in the EnvArc: area.

Quote from ziggystar12

I replaced those with the same value like for like Tants because I didn't want them to leak again in the future.

True, they won't leak. The problem with tantalum caps is that when they go, well, they GO - as in short, burn up, and/or blow off the PCB. Modern high quality aluminum oxide electrolytic caps / hybrids are the ideal choice, as Jens has mentioned.

From my understanding, C= left the FPU off the motherboard because when an accelerator (alternate CPU) is placed in the trapdoor, the motherboard 68020 and any FPU with it are disabled. I think that will be the same in your case.

RAMSEY memory is still more efficient (MB/sec) than any Zorro III expansion bus memory. For that reason, Z3 memory is given a lower priority order than the motherboard 32-bit Fast memory.

Sorry for not being back quickly. Work/Travel, etc...

Mask values are defined on the Advanced tab in HDToolBox on each partition. A reminder to TAB out of the box to make the value stick and later save it. There is also a default that can be set (in at least OS 3.2 HDToolBox and later, not sure of 3.1.4, and probably not in the earlier 1990's version), the icon ToolTypes (Information menu item, after selecting the icon) where you can make any new partitions definitions a default mask. HDToolBox plays it safe and defaults to 0xFFFFFE.

The legacy GVP Fast/ExpertPrep tools already default to that proper value (0xFFFFFFFE). Page 2 has the values for each partition.

There are 2 ways to go about using 4K blocksize with flash media, or any media.

The first is to make the media report a blocksize of 4096 bytes. Back in the day, most disk drives always reported 512-byte sectoring. At GVP, we tinkered with some SCSI device internal pages (documented in the device's manual) to push the Quantum HD series into 1K and 2K modes for test purposes. That was how we verified the FastPrep/ExpertPrep tools could deal with different blocksizes. One interesting side note is the Bernouli removable drives used to use 256-byte sectors. It tended to hang most other Amiga controller drivers, but ours translates it (I'd have to ask Ralph Babel again what the trick was - my memory has lost the answer to time). With the SCSI2SD tool, you can tell the flash media device to report 4096 to the SCSI media query. This is assuming the 'drive' is connected via SCSI controller.

If you are using IDE Flash, you would have to go about mounting the 'media' manually with a mountlist that preserves the boot block area, but otherwise lets you write to the legitimate partition area. I don't use emulation, so my personal experience is theoretical. I am, however, drawing from the Kickstart 1.2-era when C= used Mountlists on the A2090/A2090a for FFS. You probably would have to do that geometry conversion math to keep things straight, though.

The next method is to just go into HDToolBox and make it ignore the 512-byte sectoring on the media detection read, and push in a 4096 value. It will adjust the head/sector/cylinder 'geometry' by the appropriate math to accommodate. Save it, and then go partition the media.

This blocksize setting / solution is missing from the released GVP FastPrep/ExpertPrep tools, so you can't do it with that tool. I legitimately have the source to the old GVP tools, but I haven't yet gotten it updated to the point where I'd let it out for public consumption. One thing I have yet to get working is large media (>4GB). I haven't had time to get my head around all the places that need the special math conversion (we are talking double-longword integers - add/subtract/multiply/divide, effectively). That, and also displaying it all correctly on the screen. Another thing is that the modern HDToolBox (since 3.1.4) has taken the liberty to 'expand' the space it reserves at the beginning of the 'media' for larger filesystem and partition data blobs. Back in the day, FFS was the only thing that went there. Now, it's technically possible to stuff several filesystems in the RDB that are not in the Kickstart ROM.

My suggestion on the SCSI2SD is to use the erase option on ExpertPrep (or just modify the 'disk' geometry in the SCSI2SD tool) - so as to negate any saved RDB info - blank out the initial sectors. Then experiment with the speed setting and other options in the general tab of the SCSI2SD tool. I don't have any gear with me on the trip, but I had to tame the v6 series this way on the latest firmware. I haven't updated my v5's firmware in several months.

One other suggestion, on any flash-media, is to base the Amiga filesystem block size on 4K (4096) instead of the formerly native 512-bytes. I'd actually set that value in the SCSI2SD tool so the Amiga prep tool will default to that. GVP's tool doesn't have that option (yet), but HDToolBox does. This block size / sector size is a general guide for any flash media 'disk' filesystem - it reduces flash media wear.