mSATA to 44 pin IDE adapter?

[Liqourice]

Since the SD-card solution I ended up using on my A500 feels far from ideal and is quite slow I've started looking for alternatives.


Found this thing and wonder if this is a feasible way to go, paired with a decently sized mSATA SSD?


https://www.amazon.se/h%C3%A5rddisk-...07VG1X6L3?th=1

[FOL]

Originally Posted by Liqourice

Since the SD-card solution I ended up using on my A500 feels far from ideal and is quite slow I've started looking for alternatives.


Found this thing and wonder if this is a feasible way to go, paired with a decently sized mSATA SSD?


https://www.amazon.se/h%C3%A5rddisk-...07VG1X6L3?th=1

I have a few of these. They are hit and miss. You have to get right SSD that will work with Amiga. I bought 3 16GB SSD's before I got one that worked.

[alexh]

Originally Posted by Liqourice

Since the SD-card solution I ended up using on my A500 feels far from ideal and is quite slow I've started looking for alternatives.

The speed will be limited by your IDE controller implementation and your CPU power. 68000 @ 7MHz with PIO0 you will be limited to approx 500/600 Kbytes/sec which is very slow but there is nothing you can do about it other than to buy a CPU accelerator or SCSI DMA controller

[Liqourice]

Originally Posted by alexh

The speed will be limited by your IDE controller implementation and your CPU power. 68000 @ 7MHz with PIO0 you will be limited to approx 500/600 Kbytes/sec which is very slow but there is nothing you can do about it other than to buy a CPU accelerator or SCSI DMA controller

I have a TF536 with a 50 MHz 030 and using the built-in IDE on that.

The SD-card adapter I'm using now is very slow. According to Sysinfo a little under 700k/s but I really doubt that, it feels slower.

I don't expect to get the speed I had with the GVP SCSI but at least a bit better than this.

[FOL]

Originally Posted by Liqourice

I have a TF536 with a 50 MHz 030 and using the built-in IDE on that.

The SD-card adapter I'm using now is very slow. According to Sysinfo a little under 700k/s but I really doubt that, it feels slower.

I don't expect to get the speed I had with the GVP SCSI but at least a bit better than this.

That is slow, I would expect atleast 1.1 to 1.2mb/sec with acceleration.

[alexh]

Originally Posted by Liqourice

I have a TF536 with a 50 MHz 030 and using the built-in IDE on that. The SD-card adapter I'm using now is very slow. A little under 700k/s

I suspect this is not your SD-card adapter but your Amiga configuration. There are numerous discussions about TF536 IDE performance (4.4MB/s with 030@50MHz) being affected by ROM speed (that contains scsi.device). You should install the latest MMUlib and make sure that you have followed the instructions to enable MUFastROM and MUFastZero. You should see performance increase to between 2MB/s to 4MB/s

Consider using diskspeed and not sysinfo to get your figures.

[Liqourice]

Originally Posted by alexh

I suspect this is not your SD-card adapter but your Amiga configuration. There are numerous discussions about TF536 IDE performance (4.4MB/s with 030@50MHz) being affected by ROM speed (that contains scsi.device). You should install the latest MMUlib and make sure that you have followed the instructions to enable MUFastROM and MUFastZero. You should see performance increase to between 2MB/s to 4MB/s

Consider using diskspeed and not sysinfo to get your figures.

I'll try that and see what happens.

Well, this is odd. I ran Diskspeed before and after. According to the results Create file and Write to file actually got a lot slower while Read from file became a lot faster.

[alexh]

Interesting. How much slower and how much faster?

[Liqourice]

Originally Posted by alexh

Interesting. How much slower and how much faster?

Above is without, below is with. Sysspeed and Diskspeed shows pretty much the same figures.

[Liqourice]

How would this thing work considering there's no need for an adapter?

https://www.transcend-info.com/embed...lutions/psd330

[alexh]

I still think you've got a setup issue. Might be worth telling us what file system you have installed and what buffers the drive has. Maybe post your startup sequence too?

[Liqourice]

Originally Posted by alexh

I still think you've got a setup issue. Might be worth telling us what file system you have installed and what buffers the drive has. Maybe post your startup sequence too?

It's FFS Intl no directory cache 4k block size, 0xFE00 maxtransfer. 8GB SD-card but only using 4.

SS is an old mess, been hanging around since 1992 and Kick 2.04. Thinking I'm gonna try a fresh install but waiting until I can get my hands on 3.2.2. Running 3.1 now.

Might just leave it as it is for now until I can put 3.2 in. I guess there is some kind of misdirected pride in continuing to build on the same first install I had when I got my first harddrive.

[patrik]

0xFE00 MaxTransfer is unnecessary limiting, 0x1FE00 is enough to avoid the bug in 3.1 scsi.device.

Also verify that your Mask isn’t set to something really strange. It should be default 0x7FFFFFFE, but can even be completely unlimited at 0xFFFFFFFF with the C= IDE scsi.device, it has no memory region or alignment access bugs as it copies all the data using the CPU.

[alexh]

Originally Posted by patrik

0xFE00 MaxTransfer is unnecessary limiting, 0x1FE00 is enough to avoid the bug in 3.1 scsi.device.

Can you change MaxTransfer on an existing partition non-destructive? What tool? HD-Toolbox for WB3.1?

[patrik]

Originally Posted by alexh

Can you change MaxTransfer on an existing partition non-destructive? What tool? HD-Toolbox for WB3.1?

Yes, changing MaxTransfer and Mask does not change the on-disk-format, it only alters those partition parameters (each partition has those) in the RDB data. These parameters are used by the filesystem as a kludge to work around limitations/bugs in driver+hardware.

HDToolBox works, at least if you did the initial partitioning with it. I often use Thomas Rapp’s excellent ChangeBootPri to view and change these: https://thomas-rapp.hier-im-netz.de/download.html

[alexh]

I'd be curious to know if changing MaxTransfer affects the performance. I understand why it could but I'd like to know if it does in practice.

[patrik]

Originally Posted by alexh

I'd be curious to know if changing MaxTransfer affects the performance. I understand why it could but I'd like to know if it does in practice.

In this case, it should not make much difference as it is already 0xFE00 (filesystem has to split in ~64kB accesses) vs 0x1FE00 (filesystem has to split in ~128kB accesses), so you would only see difference with 64kB+ read/writes.

However, it is unnecessary to set a limit at about half what is needed to avoid the bug, thats why I recommended to fix it.

The Mask is "easier" to fudge the performance with - say the Mask is for unknown reason set to limit to Zorro2 address space of first 16MB - Mask = 0xFFFFFE or similar:

Then when running with the TF536, which has all memory above first 16MB, the filesystem will think it is unsafe to do direct transfers to/from that memory, as instructed by the Mask and will instead copy the data to chipmem and transfer it in small blocks in an attempt to make the transfer safe:
- chipmem as DMA controllers usually at least can access that
- small blocks as that with many controllers actually makes them avoid using DMA and revert to PIO

In this case that is a moot point as DMA does not exist as the C= IDE is a PIO controller, but the filesystem does not know and acts as instructed by the Mask and fudges the performance for no good reason.

[ShK]

Was it so that when using C as last letter with the Mask, it will be 32bit aligned?

E.g., Mask 7FFFFFFC (Any memory - 32 bit aligned).

[Jope]

Originally Posted by PFS2 FAQ

Values with no zero bits, end in 0xF, will have no alignment. Values with one zero bit, end in 0xE, will be word aligned. Values with two zero bits, end in 0xC, will be long word aligned.

The first number can be a 7 or an F, depends on where memory and whether it can be DMA'd to if it is a DMA situation.

[patrik]

Originally Posted by ShK

Was it so that when using C as last letter with the Mask, it will be 32bit aligned?

E.g., Mask 7FFFFFFC (Any memory - 32 bit aligned).

Originally Posted by Jope

The first number can be a 7 or an F, depends on where memory and whether it can be DMA'd to if it is a DMA situation.

It doesn't really matter if the first number of 7FFFFFFC is a 7 or F. The difference would be that 7 does not allow direct transfers above the lower 2GB of address space, but no Amiga has memory above that, so thats why it does not matter.

Also keep in mind that the Mask does not align anything, it is used to restrict direct transfers to/from memory to addresses not matching the mask. So "address AND Mask == address" must be true:

What I want to say by this is that nothing will get faster by say using Mask 7FFFFFFC instead of say 7FFFFFFF, only slower as it makes the filesystem to the safe and very slow transfers if the address of transfer does not match the Mask.

Only limit with the Mask if you need it to avoid a bug/limitation in the driver+hardware, else you will only end up with very slow transfers for no good reason.

This speed difference is only seen if tested through filesystem access. SysInfo, SCSISpeed, RSCP etc does direct device access. You need say DiskSpeed (found on aminet), which also can test speed at different alignment - watch speed of WORD and BYTE transfers in DiskSpeed decrease enormously if you change Mask 7FFFFFFF -> 7FFFFFFC for example.