Blitz - Originally known, by the designer, as "Arcin32" - The 32Bit IDE Interface - NOW WORKING!

[SarahWalker]

Hmm, p1-24 has the answer. The fastest IO timing (4 cycle IO / 3 cycle DMA) is not available in the EASI space. Fastest EASI transfers are 5 cycle IO / 4 cycle DMA, which would give maximum speeds on the 8 MHz bus of 6.4 MB/sec for PIO and 8 MB/sec for DMA.

edit: or so I thought! TRM is being confusing over all right now.

[SarahWalker]

Think I might have it, reading through the timing diagram on 1-26. Critical path seems to be t2 + t12 + t3 (address/nBW setup to EAS low, EAS select width, address/nBW hold after EAS high), which minimum timing for "C" timing (the fast one) is 270ns + 185ns + 120ns = 575ns, giving a peak access rate of 1.739 MHz resulting in a ~7MB/sec peak bandwidth. Given "real world" timings I can see how that gets rounded down to 6MB/sec.

Similar maths on the DMA timing diagram on 1-28 suggests a peak bandwidth of 9.4MB/sec for "D" timing (available for DMA but not EASI).

[IanJeffray]

"The podule bus on the Risc PC can achieve a maximum data throughput of approximately 6100 KByte/s."
https://en.wikipedia.org/wiki/Risc_PC
Everything on the Internet is wrong.

[IanJeffray]

So it seems a 2GB (and no bigger) IDE DOM is the fastest thing I've found for use with ARCIN32. I get 7.9MB/sec reads which is prettymuch saturating the fairly pathetic 8MB/sec limit of the RiscPC DMA.

I then find some nice cheap mSATA modules on AliExpress, and cheap mSATA to IDE converters. Looks ideal. Grab some 32GB (smallest available) and 128G and a silly 256G just for amusement - to test some limits (256GB being the limit for Filecore).

128G, 32G mSATA vs original 2GB IDE

Well. That was a bloomin' mistake...

What the heck is going on here? Big transfers are miserably slow. Smaller transfers are faster? What?

And only the 128GB one seems to work at all with ARCIN32 - the 32GB and 256GB modules both cause "Bad drive" errors, or even cause RISC OS to lock up or data abort. What a mess!

To verify they weren't just total trash modules, I checked them with Unipod, which isn't a particularly good/fast interface, but on there they all worked and all achieved about 3.7MB/sec which shows that ARCIN32 has some serious questions to answer!

This is disappointing. Smart ideas?

[daveejhitchins]

This is probably a failure of the ARCIN32! APDL state, in the User Guide, that they had trouble with some existing drives - so expecting it to work with more modern units may be pushing it too far. Could really do with the Source

Dave H.

[IanJeffray]

FWIW, I get the same complete failures with these mSATA drives using APDL ArcIN v6c interfaces. But it's probable the IDEFS module is similar between such interfaces, suggesting that the issue could 'just be software'.

Offtopicish: For giggles, I tried ZIDEFS/IanS - it can't deal with a 256GB DOM, even partitioned - it can't agree an LFAU even on a 512MB partition of it. Bug! So I tried the 32GB mSATA... 1.7MB/sec max speed on a StrongARM (1.4MB/sec on a 25MHz A310) - hohum.

[sirbod]

Smart ideas?

Given the speed falloff, my first guess would be DMA is failing and it's falling back to PIO.

My second guess would be the DRQ response occurs quicker than its expecting.

And for my third guess, it doesn't understand the DRQ response.

From memory, the earlier ATA specs required you select the drive, read its status, wait up to 400nS, then check for a valid response. This was lowered in later ATA specs to avoid the long wait. If the DRQ wait is hard-coded to the earlier ATA spec, it will cause problems on some drives. Symptoms will be failed/corrupt writes and random read errors when addressing more than one LBA.

[IanJeffray]

Smart ideas?

Given the speed falloff, my first guess would be DMA is failing and it's falling back to PIO.

No DMA with ArcIn V6C though -- I might try an OG Blitz in a non-DMA slot tho.

My second guess would be the DRQ response occurs quicker than its expecting.

And for my third guess, it doesn't understand the DRQ response.

From memory, the earlier ATA specs required you select the drive, read its status, wait up to 400nS, then check for a valid response. This was lowered in later ATA specs to avoid the long wait. If the DRQ wait is hard-coded to the earlier ATA spec, it will cause problems on some drives. Symptoms will be failed/corrupt writes and random read errors when addressing more than one LBA.

400nS? That's just a double-read of IO space then?

I think it may be fruitful to compare Blitz's IDEFS 3.27 against 3.28 - the changes between them are supposedly purely to do with timing and drive compatibility - IIRC the docs said older/slower drives didn't work originally. We're seeing perhaps the opposite issue, but the analysis may help identify the parts of the code that deal with timings.

[IanJeffray]

Properly off topic - apologies - but this was so funny I just had to post - Arculator running on an nVME SSD...

~4GB/sec (Though those 512K writes are curiously 'slow')

[sirbod]

No DMA with ArcIn V6C though -- I might try an OG Blitz in a non-DMA slot tho.

Does it not? The IDEFS that I have ("v3.28 (30 Jan 2001) for IDE V6" is its title) that was supposedly from a v6c does issue DMA_RegisterChannel/DMA_QueueTransfer. Unless it's a generic IDEFS Module that covers several Podules, which might explain why its so large.

The issue with the DRQ wait is if you wait and miss the DRQ response, you end up waiting for the time-out period. Having just checked the ATA spec, the DRQ wait is up 3ms or 50uS for later ATA versions - its defined in the IDENTIFY response. The ATA-1 spec its up to 20mS for Write DMA or Write multiple (PIO) and 400nS for single sector transfers.

So a missed DRQ could result in single sector writes appearing to be a lot quicker - if the ATA spec is being followed.

EDIT: From a quick check of IDEFS 3.28 it has two code-paths. One for read/writes below 8192 bytes and another for everything above - it sounds like this might be the cut-over for the issue you're seeing.

[IanJeffray]

No DMA with ArcIn V6C though -- I might try an OG Blitz in a non-DMA slot tho.

Does it not? The IDEFS that I have ("v3.28 (30 Jan 2001) for IDE V6" is its title) that was supposedly from a v6c does issue DMA_RegisterChannel/DMA_QueueTransfer. Unless it's a generic IDEFS Module that covers several Podules, which might explain why its so large.

V6C has no middle row of pins on the connector, so if it somehow DMAs it's doing so in 16bits and not at the 'usual' addresses - AFAIUI.

I'm surprised if it's the same IDEFS module in Blitz because the Blitz code specifically says it's only suitable for ARCIN32/32bit - I've never compared them though.

[sirbod]

V6C has no middle row of pins on the connector

Quite, but its IDEFS does contain DMA Module SWI's. I'd have to add debugging to the Module to see if its actually getting to that DMA code. I suspect its a generic Module that covers various Podules, some of which do support DMA so it may check in the Init sequence for a DMA capable card and adjust itself accordingly.

When you have time, could you save the ARCIN32 IDEFS/ATAPI Modules for me and attach them to the IDE - request for information thread - or email them to me. I'll see if its a similar code-base to the v6c.

[daveejhitchins]

When you have time, could you save the ARCIN32 IDEFS/ATAPI Modules for me and attach them to the IDE - request for information thread - or email them to me. I'll see if its a similar code-base to the v6c.

As the source isn't available (working on it, but don't have high hopes) any reverse engineering you can do would be useful!

Dave H.

[IanJeffray]

V6C has no middle row of pins on the connector

Quite, but its IDEFS does contain DMA Module SWI's.

Having slightly improved my understanding of what podule DMA means on RiscPC, I believe it is actually possible to have 16bit DMA, so the middle row of pins (providing D16..D31) aren't required.

For ARCIN32, the hardware (HDL) does have PIO(16/32) and DMA modes, though presently it seems the 'new' ARCIN32 requires to be in a DMA slot, whereas the OG does not - I don't think we know why. There's also some 'worrying' commentary such as "Maxtor only works in 16bit mode: PIO32 looses data words; DMA32 sends NO data." and "extended read-dma delay at start of burst, to sixteen complete cycles,ie was 14clks (560ns) now 355clks (14.2us)" but I don't see where that delay is actually implemented.

[sirbod]

For ARCIN32, the hardware (HDL) does have PIO(16/32) and DMA modes, though presently it seems the 'new' ARCIN32 requires to be in a DMA slot, whereas the OG does not - I don't think we know why.

PATA only supports 8/16bit transfers. Any mention of 32-bit will be on the controller side.

32-bit Transfer Mode was a thing at one point (I can't see it in the ATA spec, so its probably controller specific), but its not strictly a 32-bit transfer and instead combines two 16-bit reads into one. There's also been Multiword DMA since ATA-1 although it only really became mainstream once 80pin cables/UDMA were introduced. Again it's still 16-bit, but increases the data rate so the naming is just PR spin.

ATA-3 dropped some of the earlier Multiword DMA modes around 1997, drives after that date will probably be either PIO (for compatibility) or UDMA.

Drives detail which transfer modes they support via IDENTIFY PACKET DEVICE words 62/63/64, so given the comment about the Maxtor I'd hazard a guess that the drive they used was misreporting its supported transfer modes.

[IanJeffray]

For ARCIN32, the hardware (HDL) does have PIO(16/32) and DMA modes, though presently it seems the 'new' ARCIN32 requires to be in a DMA slot, whereas the OG does not - I don't think we know why.

PATA only supports 8/16bit transfers. Any mention of 32-bit will be on the controller side.

Obviously. We were discussing the host DMA.

[IanJeffray]

When you have time, could you save the ARCIN32 IDEFS/ATAPI Modules for me and attach them to the IDE - request for information thread - or email them to me. I'll see if its a similar code-base to the v6c.

All the 3.28 IDEFS modules I have, from both V6C and ARCIN32 flashers are identical binaries.

[sirbod]

All the 3.28 IDEFS modules I have, from both V6C and ARCIN32 flashers are identical binaries.

Here's what I've gleaned so far from a quick look at the code in more detail.

The code performs seven checks before using DMA:

1. Is it DiscOp 1 or 2?
2. Is the transfer >8192 bytes?
3. Is the transfer a multiple of the LBA size (hard-coded to 512 bytes)?
4. Is the buffer address word aligned?
5. Does the private word @ +&398 have bits 14 or 15 set
6. Is the private byte @ +&2A3 non-zero
7. Is the private byte @ +&458 <>-1 (this check is bugged and can't fail as it's performing LDRB R14,[R12, #&458] / CMN R14, #1)

The private word @ +&398 has bit 3 set for 32bit DMA and unset for 16bit DMA and the DMA "capable" state of the card is determined by the private byte @ +&2A3 being 1,2,3 or 4.
The private byte @ +&2A3 is set following a Podule_ReadInfo and subsequently altered after it checks if the disc has "Maxtor" in an IDENTIFY string.

I suspect it's disabling DMA for all Maxtor drives and you can force a non-DMA transfer by either non-aligning the buffer address or transferring a non-LBA sized buffer - although the later would need a low-level SWI to achieve.

[sirbod]

I tried ZIDEFS/IanS - it can't deal with a 256GB DOM, even partitioned - it can't agree an LFAU even on a 512MB partition of it.

It’s relying on CHS addressing being valid. I had to switch ZIDEFS, HCCS and Simtec support in Partition Manager to force CHS addressing to get them working. If I remember correctly, Simtec internally uses LBA addressing but uses CHS to check if the partitions are valid FileCore; in other words, if the CHS geometry in the Boot Discrec doesn’t match what IDEFS thinks the geometry is, it invalidates the partition.

In the case of ZIDEFS, it aligns the partitions to cylinder boundaries so can only be partitioned if the drive provides a valid CHS geometry.

Can you partition the drive using the latest build of Partition Manager under ZIDEFS, and does ZIDEFS see the partitions and allow you to read/write on them? I think the Debug output details the CHS reported by the drive, if not I can add it along with notifications in Partition Manager if a drive isn’t supported by the hosting Filesystem.

[IanJeffray]

I tried ZIDEFS/IanS - it can't deal with a 256GB DOM, even partitioned - it can't agree an LFAU even on a 512MB partition of it.

It’s relying on CHS addressing being valid.

But only the 256GB? When does CHS space run out? 1024 x 255 x 63 ? That's not even 8GB. Can't be that then - the 32GB DOM did work.
I plan to give PM a good bash on various systems tomorrow anyway

[sirbod]

It’s relying on CHS addressing being valid.

But only the 256GB? When does CHS space run out? 1024 x 255 x 63 ? That's not even 8GB. Can't be that then - the 32GB DOM did work.
I plan to give PM a good bash on various systems tomorrow anyway

CHS might be unrelated to the drive size when a drive reports it's using LBA addressing, its just a compatibility placeholder. IDEFS/ZIDEFS should not be using or validating CHS if the drive reports its using LBA addressing.

I expect its a throwback to ST506 where HForm stores the drive geometry in the Boot DiscRec, but Simtec stores the drive's reported CHS into the Boot DiscRec and validates it matches the drive when validating the partitions. ZIDEFS uses cylinders for the partition start/end so uses the drive's reported CHS to align the partitions.

If you run Partition Manager in DEBUG mode and search debug/txt for "Drive using ... addressing" you'll see which address the drive is using (can pretty much guarantee it will be LBA). If you then look at the first 3 bytes of Boot DiscRec, byte 0 is the Log2 sector size, byte 1 is the Sectors/track and byte 2 is the Heads. Cylinders is calculated and not used from the IDENTIFY which trips up some IDEFS if they divide the drive size and get a result that's beyond their limit - Partition Manager will show that as "Unusable"

With Simtec, bytes 1 and 2 of the Boot DiscRec have to match what the drive returns via IDENTIFY, otherwise the partition is reported as invalid. ZIDEFS might do something similar - I've not checked.

Essentially Simtec and ZIDEFS both need modifying so they're not relying on CHS from IDENTIFY if the drive is using LBA addressing. If you stick to older drives, you should be okay; more modern drives might fail. ATA v4 states that CHS "may be" supported on drives >8GB - its not guaranteed.

I'll add some addition debug output to Partition Manager to show what LBA based drives return for their CHS geometry - the max supported values are C:65535 H:15 S:255 ... however, H:16 is also valid and when a drive has over 16,514,064 sectors, C should be fixed at 16384. The max C*H*S value allowed is 16,514,064 - or 8GB addressable via CHS.

[IanJeffray]

And boy oh boy does it perform!...

apdl_dom.png

8MB/sec reads! Let's go!

Hmm. Cool. New batch 2GB DOMs are a tiny bit faster it seems... breaking that magical '8'...

But even these new 1GB ones are equally fast

Now if only I could find some media with decent SIZE that's this fast.

[jyouens82]

I have been following this quite closely and quite literally on the edge of my seat to be able to get hold of one of these in the future.
Well done guys for all this amazing work

[daveejhitchins]

I have been following this quite closely and quite literally on the edge of my seat to be able to get hold of one of these in the future.
Well done guys for all this amazing work

If anyone does want an ARCIN32, please PM me for details. Or I'll PM you if you have less than 25 posts.

Dave H.

[jyouens82]

Thanks Dave

[daveejhitchins]

Thanks Dave

Hi . . . I'll pop you on the list and contact you when I have more information. In the meantime here's my eMail address:

retrohardware@daveejhitchins.plus.com

BRs - Dave H.

[IanJeffray]

I then find some nice cheap mSATA modules on AliExpress, and cheap mSATA to IDE converters. Looks ideal. Grab some 32GB (smallest available) and 128G and a silly 256G just for amusement - to test some limits (256GB being the limit for Filecore).

Well. That was a bloomin' mistake...

What the heck is going on here? Big transfers are miserably slow. Smaller transfers are faster? What?

I put one of these in an Simtec/STD A9 Home and here are the results...

Not exactly earth shattering, but I believe this Simtec IDEFS is only PIO anyway -- yet still manages to outperform the max theoretical possible DMA bandwidth on a RiscPC and prove that the performance issue really is ArcIn32, not the SSD. No surprise, but good to have it confirmed.

[rodders]

Just got myself one of these and have hooked it up to an SD card reader with an old 4GB card. I had a few problems so I have a few tips:

• Initially the icon on the toolbar was greyed out (unformatted) but when I tried to do anything with !IDEFormat I got Bad Drive errors. This was sorted by using option 5 - Clear Bad Blocks

• !IDEFormat reported the wrong size (c. 23GB) but using option 5 - Edit Drive Parameters and setting LBA to 1, leaving everything else as default fixed this. (I'm sure I read this somewhere but can't find it now)

• I copied the content of the supplied floppy disc to the hard drive but got errors when copying Chinese2GBCF and SandiskU2GBCF in HDSpeed.SpeedLogs.logs. It seems to be font related but haven't tracked down the cause

• If I try to run !HDSpeed I get an error: HDSpeed may have gone wrong. Click Continue to try to resume or Quit to stop HDSpeed. Error 579: Unable to bind font handle during initialisation.

• I'm running RiscOS 4.04 and the readme in the R04 folder says to install the R04_Icon file into !Boot.Choices.Tasks to fix the icon size problem. This didn't work, the location should be !Boot.Choices.Boot.Tasks

Hope this helps someone.

[rodders]

I was hoping to connect up a compact flash card but although they both have 44 pin connectors they are a different pitch. Does anyone know of a suitable adapter?

[IanJeffray]

I was hoping to connect up a compact flash card but although they both have 44 pin connectors they are a different pitch. Does anyone know of a suitable adapter?

Just search "ide cf" on Amazon. Hundreds of options, depending on what form factor you want.