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

[mr-macrisc]

Gonna hope for loud noise

[paulv]

Not sure why the text is over the icon?

Quoting from the Read Me file in my archive of Baildon IDE stuff...

There is a small problem with RO4 in that the drive icons appear at the wrong height.

Until we get this fixed properly put this in the Choices.Tasks directory of your !Boot directory and it will make all the icons the right height.

I've attached the archive for you.

Paul

[myelin]

Building two prototypes at the moment - it's really difficult to do anything anymore - with all finger, arms, legs and toes crossed

If it all works then there'll be a loud noise on the Forum - if it doesn't work there'll be an equally loud silence

Exciting! Fingers crossed

[daveejhitchins]

Quoting from the Read Me file in my archive of Baildon IDE stuff...

There is a small problem with RO4 in that the drive icons appear at the wrong height.

Until we get this fixed properly put this in the Choices.Tasks directory of your !Boot directory and it will make all the icons the right height.

I've attached the archive for you.

Paul

Thanks, Paul . . . I 'll give this a try today.

Dave H

[paulv]

Quoting from the Read Me file in my archive of Baildon IDE stuff...

There is a small problem with RO4 in that the drive icons appear at the wrong height.

Until we get this fixed properly put this in the Choices.Tasks directory of your !Boot directory and it will make all the icons the right height.

I've attached the archive for you.

Paul

Thanks, Paul . . . I 'll give this a try today.

Dave H

No worries. Hopefully it'll sort it. I don't know if it was ever fixed properly though...

As an aside, I only know about this issue because I was digging around my RiscPC after fitting the ethernet card you sent me. Up until then that machine had been in storage since 2015

Coincidence our fate? Who knows?

Paul

[daveejhitchins]

A quick update of progress (or lack of it recently!)

I've confirmed today that the ABLE code (for the CPLD) and the copy of the firmware I took from the working Blitz is working e.g. I can program CPLDs and ROMs and they work! The bits that aren't working are the prototype PCBs. These are built to the schematics that were sent with the ABLE files. So, I need to do more work on this to try and find what missing from the schematics!

Dave H

[mr-macrisc]

How’s your blitz arcin coming along? Or stopped for a short while?

[daveejhitchins]

How’s your blitz arcin coming along? Or stopped for a short while?

Glad you asked . . . I can confirm that danielj has successfully compiled the ABEL file, for the CPLD, and that it works. I also have a copy of the firmware and that works - Note, however, that the address lines aren't linear so I would have to 'decode' according the the on-board addressing to obtain a readable version - later, for that one.

PCB - My first attempt didn't work - probably due to me making more that one error in transcribing the original schematic to my Altium set-up

So, I've been checking, checking and checking again. I even removed the CPLD to ensure that there weren't any connections underneath it that weren't shown on the original schematics - none found, so far. I still have to check all the unused pins - just in case!

The PCB is ready to go, again - this time, hopefully, with a little more confidence. I'm hoping to have a built board for the November ABUG meeting.

Dave H

[IanJeffray]

Did this get any further?

[daveejhitchins]

Did this get any further?

Yes/No . . . PM sent.

Dave - H.

[IanJeffray]

Did this get any further?

Yes/No . . . PM sent.

PM received, which quickly progressed to Dave kindly sending me a prototype board to examine and test, along with the design files. A few hours of poring over the design, comparing to the "original" schematic, comparing to real hardware - all seems good, with some nice updates including power to pin 20 to enable cable-less operation of DOMs and I also found that some (not all) CF cards require power here to enable DMA operation.

Before even trying the prototype card, I gave it a thorough inspection under the microscope for opens/shorts/etc. I've taken to doing this with all new boards and repairs because it's proven to me to be a worthwhile use of time and reduces risk of powering up a faulty board. And in this case, I found one pin on the FPGA that was floating (DMARQ1 from the IDE connector), even though it looked ok (I perform a "wiggle" test on each pin with a scalpel - the pin wiggled easily - this same technique has been how I've repaired three PC cards just recently too!). Solder down that pin, and 'touch up' a couple of others that didn't have good 'toe' solder. Now we'll power it up.

It appears as podule. Super first step.

Add a CF card. It appears as an IDE drive! Great!

Format the CF card. It goes through the motions but RISC OS doesn't see it as a valid drive. And I'll cut a long story short here - other Blitz/ARCIN32 cards also exhibited the same "problem" - but achingly it turned out that the specific RiscPC I was using for this test has a faulty DMA bit 31/30 which I'd never been aware of before, as so few podules use DMA!

So, pick another RiscPC, reformat the CF card - it works! Run through some big file copy and read tests, speed tests, and I've some confidence it's operating just as well as the original ARCIN32. Try half a dozen other sizes/brands of card - all ok. Marvellous work, Dave! I don't feel my tiny contribution justifies me being the bearer of such great news, but Dave suggested I should, so ... hurrah!

Working ARCIN32/Blitz with DMA

Dave also sent parts to build up a 2nd podule, which I'll undertake in the coming week, along with further stress testing and testing with various other media types.

I think this is really exciting as it's a very noticable performance upgrade for a RiscPC (when coupled with appropriate media).

The only tweak I'd like now is a 44pin connector on the board, like IanS's ZIDEFS podules (Though I first need to check if the cheap bare DOMs we've been using do support DMA!)

[IanS]

So, pick another RiscPC, reformat the CF card - it works! Run through some big file copy and read tests, speed tests, and I've some confidence it's operating just as well as the original ARCIN32. Try half a dozen other sizes/brands of card - all ok. Marvellous work, Dave! I don't feel my tiny contribution justifies me being the bearer of such great news, but Dave suggested I should, so ... hurrah!

Comgratulations, great to see this working.

[daveejhitchins]

Absolutely brilliant work, Ian . . . Let me know more about that connector you'd like and I'll see what can be done.

Looks like I'll be ordering more boards from JLCPCB in the near future.

I supplied the second board, that Ian is to build, with a CPLD sourced from China. So, depending on the results of that will depend on any future supplies of Blitz.

[IanJeffray]

Let me know more about that connector you'd like and I'll see what can be done.

Just a standard 44pin IDE, in parallel with the 40pin ones. The extra 4 pins are for 5V power. Orientation such that it suits a DOM overhanging the FPGA would be ideal. But I'll test a DOM with an adaper first - see if it even does DMA.

Standardising the rear connector as right-angled as you have done is ideal for 40pin DOMs and hard-mate CF adapters - I've changed my ArcIn V6Cs to be like that and will do Blitz's too.

I supplied the second board, that Ian is to build, with a CPLD sourced from China. So, depending on the results of that will depend on any future supplies of Blitz.

Or change to a more available part (which these days seems to mean more pins, alas).

[daveejhitchins]

Or change to a more available part (which these days seems to mean more pins, alas).

I've been looking at the XC9572, as I've a good supply of them, however, not enough pins (but that may be fixable by combining address lines externally) - so it my be the number of macrocells that determine this route. As for other CPLDs - availability and price!?

I've found a through-hole zif socket for the 144 pin TQFP CPLD - I could make a test board and use the Chinese source of the CPLD. Basically the same as I do now for all the parts I get from China.

Dave H.

[IanJeffray]

I built up the 2nd board ...

CPLD programmed fine. Just need the appropriate !ProgFlash for Blitz now...

Anyway. I also tried this hilarious Heath-Robinson method of attaching a 44pin DOM. There's a 40pin IDE cable, shredded and forced in to a 44pin IDE connector along with power sprouted from a power splitter cable from the CDROM, then finally a gender-changer board before the DOM plugs in. This is why it'd be "nice" to have a 44pin header right on the PCB...

And boy oh boy does it perform!...

8MB/sec reads! Let's go!

[IanJeffray]

Just need the appropriate !ProgFlash for Blitz now...

Dave pointed out the flash I'd been sent was actually pre-programmed. So I can test it and ... yes, the new board works fine too.

He's also unearthed the required !ProgFla32 that should suit Blitz, but the modules in the image aren't quite the latest, so I'll sort that out (and maybe try and fix the dropped-icon issue in IDEFSFiler) then post it here. [EDIT: Erk, the ruddy thing doesn't ask for any confirmation when run - just blatted my card with the old modules before I realised what was going on! Will need to rescue them from the other card now! At least I guess this proves the flasher code works ]

[IanJeffray]

the modules in the image aren't quite the latest

Well. Hmm. This is interesting... IDEFS 3.27 appears a bit quicker on several things than IDEFS 3.28 does... and there's notes in the (3.27) flasher about slowing things down a bit for greater compatibility with older spinning rust - I suspect there's been some tuning going on.

Test on exact same machine/card/DOM. Multiple runs.

Of the four podules here (new and 'original'), most had the same 'generic' modules, but the ATAPI and IDEFS were newer than those in the ProgFla32. VProtect in various podules was somewhat random, so I've put 5.00 there now.

[IanJeffray]

And boy oh boy does it perform!...

apdl_dom.png

I swapped the SA from 200MHz to 276MHz and the write speeds on large blocks noticably went up...

[baz4096]

I swapped the SA from 200MHz to 276MHz and the write speeds on large blocks noticably went up...

Do you have a Kinetic card you can try?

[IanJeffray]

I swapped the SA from 200MHz to 276MHz and the write speeds on large blocks noticably went up...

Do you have a Kinetic card you can try?

Nope, but @AndyMc1280 will be helping us there

[IanJeffray]

So I swapped from the usual 2GB DOMs I use with Wizzo, partitioned in to four 495MB partitions for use with RISC OS 3.1, to an 8GB DOM that looks visually very similar -- who wouldn't want that sort of space on a RiscPC? Well... mildly disappointed to find that the performance is down to 6.5MB/sec max for read, though the 4.4MB/sec write speeds remain. Didn't really expect that.

I then took a 2GB DOM and set it up as a single 2GB partition, and performance remained good. So it seems not all DOMs are equal.

[AndyMc1280]

I swapped the SA from 200MHz to 276MHz and the write speeds on large blocks noticably went up...

Do you have a Kinetic card you can try?

Nope, but @AndyMc1280 will be helping us there

He will? Oh yes.... he will

[daveejhitchins]

I now have two units working and one with a small problem that I'll look into (eventually).

I hope to take all the working ones I have to the WROCC show (Bradford) in April. So, looking for a nice demo ^^^ the one above looks good as I also have a Kinetic

Dave H.

[IanJeffray]

I also have a Kinetic

Aha! Lukcy you. I'll send you one of these apparently speedy DOMs then. Except for the heath-robinson-mess of connecting it up just now. So... that spurs me on to create the product I can't quite believe nobody else has created yet - a 44pin male to 40pin female IDE adapter. Should be trivial. And it'll be nice to have this for A5000s anyway.

I've been speed-testing some IDE to SATA converters, using 16GB SATA DOMs, and various 2.5" SATA SSDs. The results are all absolutely terrible - under 1.5MB/sec read and write - clearly the adapters I bought are garbage.

[baz4096]

I've been speed-testing some IDE to SATA converters, using 16GB SATA DOMs, and various 2.5" SATA SSDs. The results are all absolutely terrible - under 1.5MB/sec read and write - clearly the adapters I bought are garbage.

I've been recently trying to replace the HDD in my Iyonix with a more modern SSD. I went through my collection of IDE -> CF, IDE -> SATA adapters, none of which worked reliably, even after flashing to a newer version of RISC OS. The only adapter that worked perfectly for me was this one:

https://www.amazon.co.uk/dp/B00310MFPY

I copied over 13+ gigabytes of data from the old HDD without any problems. The only downside is how bulky it is. Something like this might perform better for you. I'd be happy to send you one to try out?

Also, if you do make a 44 pin male to 40 pin female adapter for general sale, I'd be interested in buying a few; I've been looking for a better solution for quite some time now.

[IanJeffray]

https://www.amazon.co.uk/dp/B00310MFPY

I copied over 13+ gigabytes of data from the old HDD without any problems. The only downside is how bulky it is. Something like this might perform better for you. I'd be happy to send you one to try out?

Hmm... that doesn't accept a DOM/SSD plugged directly in to it, which isn't so nice. You'd have to hang it on a SATA cable, and then supply power separately via some kind of molex splitter/converter (as I see in the "Frequently bought together" section!) - seems like a significant obvious oversight, but perhaps as this is the female IDE plug, hard-mated SATA maybe wouldn't make sense. This isn't so cool for situations where the IDE connector has restricted space, such as the RiscPC motherboard, which is where I was looking to use these sorts of adaptors initially.

Reliability's not an issue, just performance - using DMA.

For reference, this is the cheap junk I bought : https://www.ebay.co.uk/itm/303922513738

Also, if you do make a 44 pin male to 40 pin female adapter for general sale, I'd be interested in buying a few; I've been looking for a better solution for quite some time now.

It'll be opensource, as all my Acorn hardware projects. And I'll build some to sell. Hope to get it knocked up in the next few days. For use with Blitz, it will take power from IDE pin 20, so it'll literally just be a PCB and two connectors. For use on the A5000 it'll need to take external power, so an option to fit a Molex plug, probably. (Or simply hotwire the normally non-connected pin20 to 5V... superbly neat, then!)

Talking of pin 20 power, here's how Dave hacked the original Blitz card to provide power on pin 20 - I've done the same to my own original Blitz's now too - I was unaware that "power on pin 20" had become a (de-facto?) standard, but it seems it is, which is great!

[IanJeffray]

I swapped the SA from 200MHz to 276MHz and the write speeds on large blocks noticably went up...

SA276.png

Hmm. So. The RiscPC TRM says DEBI/EASI supports "up to 6MB/second transfer rate", which is in itself a bit pedestrian sounding, but also ... not true if I'm seeing almost 8MB/sec to ARCIN32. Does anyone know why Acorn specified 6MB/sec in the TRM or how that figure is derived? Or, conversely, how I'm seeing almost 8MB/sec here? I'm struggling to understand the timing charts in the TRM for EASI/DEBI DMA - naiive understanding is that CLK16 gives x2 performance over MEMC podule space, and the 32bit vs 16bit data allows for an effective further x2 data throughput, but I'm not clear on how back-to-back transfers are timed.

[SarahWalker]

I have a vague memory that 6MB/sec is the figure for DMA. PIO to EASI space should be 8MB/sec.

[IanJeffray]

I have a vague memory that 6MB/sec is the figure for DMA. PIO to EASI space should be 8MB/sec.

Sounds reasonable - though the TRM gives the 6MB/sec figure under the EASI heading. (p1-19).