Page 1 of 10

Understanding and Optimization of OS 4.1 for Classics

Posted: Thu May 17, 2012 10:39 am
by danbeaver
Hi guys!

This is a new thread based on questions and answers from my prior thread, "AmigaOS Classic 4.1 Update 2 Fails to Install." Those issues had been resolved and the thread had changed content. It ended with my question, "Is there any experience or documentation about using the different memory masks when setting up a hard drive partition: the choice of 'Any Memory,' '32-bit Aligned,' or '24-bit DMA?' "

Calgor had responded: "Regarding the Mask, I do not know specifically if OS4 behaves differently to OS3.9, as I have not needed to change the Mask value for any hard disk partitions.

But if you set the Mask to 0x7FFFFFFF - then all of the first 2GB of memory can be used. The last character being F means the driver/controller is not fussy about memory alignment. The last letter could also be set to E or C for different alignments. For those drivers (e.g. in OS3.9) that may only operate in 24-bit memory space (i.e. first 16 MB) you can set the mask to 0xFFFFFF - I needed to do this once for a CD driver in OS3.9 that would have random errors otherwise.

There is an *excellent* explanation in the old SFS 1.58 guide (from original SFS author archive or SFS_OLD.guide in latest 68k full sfs1.277 archive) under the section "the Mask field":
http://www.amiga-stuff.com/text/filesys ... S158.guide

I do not know which one is ultimately preferred out of 0XFFFFFFFF (4GB) or 0x7FFFFFFF (2GB), both for current systems, and for future compatibility."

He was, of course, correct. In the SFS guide says of MaxTransfer Values: "In any case, if you have a SCSI drive, then a MaxTransfer value of 0x7FFFFFFF should be just fine. For IDE drives, you probably need to
set it to 0x1FFFE or to 0xFFFE. Those values represent 128 kB minus 2 bytes and 64 kB minus 2 bytes respectively."

And of Transfer Masks: "The Mask field can be used to tell a filesystem that the device which comes with your (harddisk) controller cannot directly access its data
in all regions of memory available on your system.

When a device has been properly written it should be able to cope with data located anywhere in memory. For those devices the Mask should be set to 0xFFFFFFFF. Only badly written or very old devices need a different Mask -- in other words, the Mask value is a compatibility kludge to fix broken devices.

For example, some devices can't access data starting at an uneven address in memory. Some even can only access data when it starts at an address which can be divided by four. In the first case you would set the Mask field to end in 'FFFE', and in the second case to 'FFFC'.
If your controller can handle addresses without alignment restrictions then you can set it to 'FFFF' (which is of course the preferred
value).

There are also devices which can only access memory in the 24-bit memory area (everything below the 16 MB boundary). Usually these are Zorro-II controllers which cannot directly access memory located on, for example, an accelerator card. For these devices you set the mask to 0x00FFFFFF, indicating that the device can only access data in the 24-bit address space.

Devices which can access data located anywhere in memory (a SCSI controller which is embedded on an accelerator card, or a Zorro-III IDE or SCSI controller) should have a mask of 0xFFFFFFFF.

Here is an overview to clarify the Mask setting:

xxxxxxxF - Use a Mask ending with a 'F' if you're device is written correctly and can handle transfers to and from memory with any alignment.

xxxxxxxE - Use this if you're device can only handle 16-bit or WORD aligned transfers.

xxxxxxxC - Use this if you're device can only handle 32-bit or LONG aligned transfers.

FFFFFFFx - Use this Mask if you're device is written correctly and can work with any memory in the system. The first 'F' may also be '7' since there are no Amiga's which can have more than 2 GB of memory.

00FFFFFx - This Mask restricts transfers to the 24-bit address space, meaning it can only access ChipRAM and FastRAM in the 24-bit area (The 24-bit area is 0x00000000 to 0x00FFFFFF).

001FFFFx - This Mask restricts transfers to ChipRAM only (the old trackdisk.device needed this for example).

Always use the least restrictive Mask possible. The ideal Mask is 0xFFFFFFFF."

So there is the answer!
==========================================================================================================

In another area Amiga Classic threads, I noticed that the A4000T I have (with the CSPPC filled with 128MB memory, the Mother Board full of 16MB RAM) will boot to a maximum free ram of 77MB (with only WorkBench started). As I use up this memory with programs such as, Jack, the OWB or NetSurf browser, the Poseidon USB stack etc., I end up with paged ram using, initially, my ZorRam (128MB) card and then to a 768MB HDD swap partition. Some programs "choke" and fail to load when using virtual memory, or just crash the system. My question what do you folks use to save precious CSPPC RAM? [See question of using "Timberwolf" on Classic Amigas]

This is what I've tried so far: Turn 3D Acceleration OFF in GUI Prefs, Poseidon OFF until needed, not load AmiDock (instead I use the OS 3.9 68K version of IconLauncher), try not to use DOpus4 (using ClickDosII instead), disable as much of WB start-up commodities as possible, do not automatically mount all my volumes (only when needed), Lessen the Disk Drive buffers to around 100 (not the 600 Media Toolbox brings up), and use the IBrowse browser (a very low overhead program).

The 68K versions seem to conserve RAM better than their OS 4.1 counter-parts. But what do other Classic owners use?

Dan

Re: Understanding and Optimization of OS 4.1 for Classics

Posted: Thu May 17, 2012 3:17 pm
by Calgor
In my comment referred in the above post, when I said I used a mask for 24 bit memory for a CD driver, I meant in the mountlist/DosDriver file (which from memory is an integer flag value, but same end result as if using the Mask).

To try to save memory, not sure how much, you might try reducing the bit depth for the workbench screenmode, as well as the resolution.

Some other users more familiar with the GUI may also suggest some other features that can be disabled.

Re: Understanding and Optimization of OS 4.1 for Classics

Posted: Sun May 20, 2012 7:44 am
by danbeaver
Hi again,

I just upgraded my backup A4000T to a CSPPC 200/50 604e/060 with Mediator, RTL8029, Radeon 9200 (from Elbox), spider II card, SB128, and sii3114ide and it only took 2days! Software install was easy for OS 4.1 thanks to prior help, although it ignores BootDevice module (?). One hardware issue with Elbox -- the Radeon card does not fit properly with the VGA port blocked leaving a S-video port and a DVI port. The DVI port does not work with any of my (3 different) DVI to VGA adapters and the only way I know it works at all is with a DVI to HDMI adapter to my TV.

Obviously not an OS 4.1 problem.

If no one is doing much to conserve ram, can I ask who votes that the next update to the Classic includes USB support for generic PCI cards? Maybe a "bounty" would help.

Dan

Re: Understanding and Optimization of OS 4.1 for Classics

Posted: Tue May 22, 2012 5:46 am
by danbeaver
Hey folks!

I found a Fujitsu 36GB 68-pin SCSI HDD that spins at 15,000 RPM and (for less that 15 cubic feet of wallet salad); I thought that if I used it for my main drive it would be a better (quicker) drive for my SWAP partition.

Any thoughts?

Dan

Re: Understanding and Optimization of OS 4.1 for Classics

Posted: Tue May 22, 2012 6:05 am
by Slayer
at a glance any benefit would be governed by whether a bottleneck exists in actual reading & writing to the harddrive swap space and how such is accomplished

Re: Understanding and Optimization of OS 4.1 for Classics

Posted: Tue May 22, 2012 7:22 am
by danbeaver
Hi Slayer,

The 15K hard drive came from a Unix server; my guess is that latency should be shortest with 15,000 rpm and would put the burden on the SCSI bus, the drive is listed by Fujitsi as 320 mb/s seek time: track to track: write- 0.5 ms / read- 0.3 ms average: write- 3.8 ms / re. For the CS-PPC hardware I don't think that I can achieve anything better -- there are no UW drives faster in rotation speed. One would have to change to a wider/faster bus. If I were designing a hard drive, I would have put in a larger buffer (it is only 8 MB) or hybridize the drive to contain a SSD buffer. The rotation speed insures that the data is not accessed sequentially and this ends up limiting storage on the platters. I believe the faster the rotation, the smaller the capacity.

I am open to your thoughts and experience.

Dan

Re: Understanding and Optimization of OS 4.1 for Classics

Posted: Tue May 22, 2012 7:32 am
by Calgor
Your radeon card may only have a DVI-D port, which is possibly why your DVI-I to VGA adapter does not work (It works on mine).

Not loading all modules from the Kickstart would also conserve a little memory, but you don't want to do the wrong thing and end up with a non-booting system.

Not sure how much your 15000rpm hard drive will help with the SWAP. I had my swap on a 5400rpm 320GB IDE drive (16MB cache) over Acard SCSI-IDE adapter and latency with ZorRAM was far superior for general OS usage (like the shell) when browsing the internet. I do have a 10000rpm 73GB SCSI hard drive (also with only 8MB cache) also fitted that I did not try which should be better than the other hard drive and I imagine would close the gap to the ZorRAM. I suggest you try for yourself, especially if you have an old IDE drive - and put the SWAP on a different drive to your OS.

Re: Understanding and Optimization of OS 4.1 for Classics

Posted: Tue May 22, 2012 7:57 am
by danbeaver
Thanks Calgor,

The DVI is indeed digital as the digital HDMI adapter works, but I would have to get a new monitor or watch on my TV; I also found out that the Radeon 9200 I ordered was replaced with a 9250 model (not what I ordered). This has a slower clock and is less in cost plus the problems with segmented memory. I explained this to Elbox and I'm awaiting their response.

I tried making a smaller kernel and saved less than 1 MB. I tried a fast SATA IDE drive on the SATA sii3114ide and got the same (poor) transfer rate. I tried a IDE hard drive on the A4000's IDE bus and got equally poor results when compared to the cybppc.device. I should get the 15k drive by 25-May-12 and will post numbers then.

Dan

Re: Understanding and Optimization of OS 4.1 for Classics

Posted: Tue May 22, 2012 10:42 am
by Calgor
Elbox changes their actual Radeon card from time to time. Mine has the DVI-I and VGA at the bottom of the card so both ports can be used (non-functional TV-Out is blocked) and is a Mobility Radeon. Elbox literature says both 9200 and 9250, and also SDRAM and SGRAM. I asked them the clock rate of core and memory before I purchased - it is lower than most 9200s, but my understanding is 9250 can be faster if it is clocked faster, but it is usually clocked slower. So you need to know the actual core clock speed and memory speed to determine if it really is slower (I have no idea how people on the amiga boards keep categorically stating one is faster than the other without actually knowing the clock speeds of their own cards given they vary on implementation!).

For reference my 256MB Mobility Radeon 9200 card (PCI Device ID 0x5C63, RV280 M9+) according to Elbox is clocked at: 200MHz core, 288MHz DDR SDRAM (memory rated as 400MHz). If yours is a standard Radeon 9250 I am guessing it may be clocked faster than mine (guessing 200-240MHz core, up to 400MHz DDR SDRAM)

Advantage of a lower clocked Mobility Radeon like I have is it generates virtually no heat, which is IMO important in a fully loaded CSPPC A4000T. Presumably it may also overclock well as the board runs very cool and the RAM is rated for much faster than it is being run. However, maybe a faster clocked Radeon will give some advantages in for example complex 3D, but I do not know this.

Re: Understanding and Optimization of OS 4.1 for Classics

Posted: Tue May 22, 2012 11:18 am
by danbeaver
Hi Calgor!

I didn't mean to discuss non-AmigaOS 4.1 issues; I was just peeved at the bait-and-switch scheme.

I meant to discuss OS 4.1's need for support of a generic USB pci card as they did for the RTL8029 NIC, the ESS Solo 1, the sii3114ide card, and various graphic cards. None of the USB options are available for sale.

I wanted to see what others are doing to conserve RAM and optimize swap partition use.

Dan

PS, Elbox offered to replace the card, so it is off to Poland.