ICS Wizzo IDEFS for A5000/A4 (+A3020/A4000...) improves CF card support!

[IanB]

I wonder if this ICS Wizzo ROM may actually result in better compatibility with SD->IDE interfaces on the A5000/A4 - since IDEFS has no problems with newer SD->IDE interfaces, where ADFS fails.

I just programmed the Wizzo image into a 27512 EPROM and fitted it to the 5th column ROM socket on my A5000

I don't have any of the single chip SD to IDE boards but I do have SD to compact flash converters which I use with the RISC PC so I plugged one of those into a CF to IDE interface resulting in SD>CF>IDE. This converter doesn't work with ADFS on the A4000 & A5000, giving broken directory errors when trying to mount a drive (it does work on a RISC PC). The converter works on my A5000 with the IDEFS in the Wizzo ROM and it identfies itself as FC1307 in !Hform which I think is the same chip as the new single chip SD to IDE boards. (The old 2 chip solution used FC1306)

[Zarchos]

I wonder if this ICS Wizzo ROM may actually result in better compatibility with SD->IDE interfaces on the A5000/A4 - since IDEFS has no problems with newer SD->IDE interfaces, where ADFS fails.

I just programmed the Wizzo image into a 27512 EPROM and fitted it to the 5th column ROM socket on my A5000

I don't have any of the single chip SD to IDE boards but I do have SD to compact flash converters which I use with the RISC PC so I plugged one of those into a CF to IDE interface resulting in SD>CF>IDE. This converter doesn't work with ADFS on the A4000 & A5000, giving broken directory errors when trying to mount a drive (it does work on a RISC PC). The converter works on my A5000 with the IDEFS in the Wizzo ROM and it identfies itself as FC1307 in !Hform which I think is the same chip as the new single chip SD to IDE boards. (The old 2 chip solution used FC1306)

Any idea if the Wizzo code enhances (or even permits) the use of removable media like the Iomega zip drive ?
I've got some mags around and I could check the advertising blurb, but if you knew ...

EDIT : OK I've got a mag, and the advert says Wizzo supports 105 Mb Syquest, but it doesn't say anything about the Iomega zip drive.

[steve3000]

The converter works on my A5000 with the IDEFS in the Wizzo ROM and it identfies itself as FC1307 in !Hform which I think is the same chip as the new single chip SD to IDE boards. (The old 2 chip solution used FC1306)

Great to hear it's also been successful for you Ian!

From my experiments today (and from what Rob and Ian have reported) it looks like the Wizzo IDEFS definitely improves support for CF cards - allowing many more to work with the Acorn interface on the A5000/A4/etc. Also allowing partitioning of larger cards

Unfortunately however, the available Wizzo IDEFS versions (up to v3.15) don't seem to help with the single chip SD->IDE adaptors. I've tried a number of single-chip adaptors (with chips labelled "ST368" and "Sintechi"), but all still fail on ADFS and IDEFS*. So for the moment, this means the only common SD->IDE adaptors which seem to work through the Acorn interface are the two-chip "FC1306" labelled ones.

*I do plan to test these single-chip adaptors on a real ICS IDE interface to see if they function...possibly later versions of IDEFS (which were available on the ICS interface, but not as Wizzo ROMs) will help...

[steve3000]

Any idea if the Wizzo code enhances (or even permits) the use of removable media like the Iomega zip drive ?
I've got some mags around and I could check the advertising blurb, but if you knew ...

The later version of the Wizzo 4 ROM seems to have IDEFS v3.22 present and this version on the ICS IDE interface certainly supports CDFS - so it may well support CDFS on the Acorn interface? I'm not sure about other removable media though, and I don't recall having ever read about any ZIP support over IDE on RISC OS? (but I could be wrong...)

[steve3000]

The later version of the Wizzo 4 ROM seems to have IDEFS v3.22 present and this version on the ICS IDE interface certainly supports CDFS - so it may well support CDFS on the Acorn interface?

Unfortunately, having extracted IDEFS 3.22 from the Wizzo 4 ROM, it appears not to be a functioning version - and fails to work with my A4's HDD - reporting "Hard Drive Failure" upon accessing. So I think this may just be a test ROM, which was never finished

That means the latest functional Wizzo version we have from Dave's set of ROM images is Wizzo5 v3.15 (from which my boot disc is built). So if anyone comes across a functioning Wizzo 4 or Wizzo 5 ROM with version > 3.15, please let us know

[Zarchos]

The later version of the Wizzo 4 ROM seems to have IDEFS v3.22 present and this version on the ICS IDE interface certainly supports CDFS - so it may well support CDFS on the Acorn interface?

Unfortunately, having extracted IDEFS 3.22 from the Wizzo 4 ROM, it appears not to be a functioning version - and fails to work with my A4's HDD - reporting "Hard Drive Failure" upon accessing. So I think this may just be a test ROM, which was never finished

That means the latest functional Wizzo version we have from Dave's set of ROM images is Wizzo5 v3.15 (from which my boot disc is built). So if anyone comes across a functioning Wizzo 4 or Wizzo 5 ROM with version > 3.15, please let us know

It must be a Wizzo ROM or it can be the IDEFS from an ICS IdeA expansion board ? I'm a bit confused.

[RobC]

It must be a Wizzo ROM or it can be the IDEFS from an ICS IdeA expansion board ? I'm a bit confused.

Steve PM'd me the details earlier: the IDEFS module appears *after* the ROM header in the later Wizzo 4 image so that it isn't picked up by the machine. This explains why I couldn't get it to work when blown to a 64KB EPROM.

Steve originally thought that this was just an error but, having extracted the modules and soft-loaded them, Steve found that it didn't recognise his hard drive. So, it looks like its version of IDEFS is buggy and the ROM header was deliberately moved in front of it (possibly to allow testing).

[Zarchos]

It must be a Wizzo ROM or it can be the IDEFS from an ICS IdeA expansion board ? I'm a bit confused.

Steve PM'd me the details earlier: the IDEFS module appears *after* the ROM header in the later Wizzo 4 image so that it isn't picked up by the machine. This explains why I couldn't get it to work when blown to a 64KB EPROM.

Steve originally thought that this was just an error but, having extracted the modules and soft-loaded them, Steve found that it didn't recognise his hard drive. So, it looks like its version of IDEFS is buggy and the ROM header was deliberately moved in front of it (possibly to allow testing).

From this I'll assume if I upload a version of IDEFS > 3.15 it should help

idefs.txt

(17.42 KiB) Downloaded 152 times

[steve3000]

From this I'll assume if I upload a version of IDEFS > 3.15 it should help

Thanks, is that Wizzo IDEFS? (which is ICS IDEFS rewritten to use the Acorn interface?)

[Zarchos]

From this I'll assume if I upload a version of IDEFS > 3.15 it should help

Thanks, is that Wizzo IDEFS? (which is ICS IDEFS rewritten to use the Acorn interface?)

It's the dump of IDEFS from the ICS IdeA interface in this A3000 I found and had forgotten about, while looking for this ARM3 A3000 I haven't found.
It's why I asked if it could work to burn a Wizzo E(e)prom, and well since I didn't understand the answer given, I dump anyway.

Btw the machine has got a protected hard drive, and although I followed Jon's procedure in another thread (reading the workspace) I couldn't find the password ... so some help would be highly appreciated.

EDIT : OK I understand this dump is irrelevant.

[Paul]

Been absent from the forum for a little bit as I'd taken on a rather large project.

Is there anyone that could run off a 2-3 of these wizzo Roms, if I cross your palms with silver? It would be greatly appreciated!

[IanB]

Great to hear it's also been successful for you Ian!

It seems to work fine with apps but I'm having a wierd problem with changing folders from the command prompt.
e.g. if I hit f12 and type *dir $.modes.new (which is a valid path) and then *. the folder I get no files found and it looks like the path it is trying to cat is $.modes.n (there are actually about 20 files in the "new" folder)

see screen grab:

I tried all the versions of the wizzo rom with the same result but it doesn't happen if I revert to ADFS

Anyone know what the problem is?

[steve3000]

Anyone know what the problem is?

Humm I think that may be a 'feature' (bug) in IDEFS.

I recall issues with the CSD being 'forgotten' on my ICS IDEFS podule which could be resolved by using the full path including the filesystem (*Dir idefs::4.$.modes.new) so this may be related... and someone posted on here a while back about a similar issue with the ICS podule.

Also if you select the directory in steps (*idefs, *drive 4, *Dir $, *Dir modes, *dir new) does it work? Or if you set a variable (*Set new$dir idefs::4.$.modes.new) and the set the directory to that variable, does it work?

Several later versions of ICS IDEFS exist, and they may solve this issue, but 3.15 seems to be the latest version of 'Wizzo' IDEFS we have available here.

[IanB]

someone posted on here a while back about a similar issue with the ICS podule.

I found that thread:
http://www.stardot.org.uk/forums/viewto ... =16&t=8007
which leads here:
https://groups.google.com/forum/#!topic ... umceUFWkXY
And that indicates it can be caused by misalignment of the filesystem name.

Also if you select the directory in steps (*idefs, *drive 4, *Dir $, *Dir modes, *dir new) does it work?

No.

Or if you set a variable (*Set new$dir idefs::4.$.modes.new) and the set the directory to that variable, does it work?

Haven't tried that and I have reverted back to ADFS for the moment as it was interfering with development work on the adafruit driver.
I think it must work with a fully qualified path as that's what is usually used in the RISCOS desktop.

[sirbod]

someone posted on here a while back about a similar issue with the ICS podule.

I found that thread:
http://www.stardot.org.uk/forums/viewto ... =16&t=8007
which leads here:
https://groups.google.com/forum/#!topic ... umceUFWkXY
And that indicates it can be caused by misalignment of the filesystem name.

It's aligned in the A4 / A5000 Module @ &528 so the issue may not be alignment of the file system name or boot text.

[munchausen]

I tried this out with my A3010 hard disc mod and it doesn't find any drives. I think there is still an issue in my circuit somewhere...

[Paul]

Anyone going to the ROUGOL RISCOS LONDON show that could kindly blow a couple for me if u cross you palm with silver? it would be greatly appreciated!

Cheers, Paul.

[sirbod]

ICS Wizzo IDEFS for A5000/A4 (+A3020/A4000...) improves CF card support!

In case you missed the breakthrough this weekend, I believe I've found the issue in ADFS that's breaking compatibility with modern drives and have posted a BASIC program to save a patched ADFS Module. It's been tested on Iyonix and RiscPC and proven to resolve all the disc errors that occurred previously with SD cards. It's not been tested on any ARM2/3/250 based machines yet, but I'm quite confident it will resolve the incompatibility issue and remove the requirement for either specific IDE adapters, drives or Wizzo.

I'll make a ROM patcher available soon, in the meantime I would appreciate if folk could test the patch on kit that's previously not worked and report back.

[danielj]

John, this is really good news! The potential problem is, unfortunately, the chicken-and-egg of loading the patch when it can't talk to the drive - or is the entire thing an issue with writing to the drive?

d.

[sirbod]

John, this is really good news! The potential problem is, unfortunately, the chicken-and-egg of loading the patch when it can't talk to the drive - or is the entire thing an issue with writing to the drive?

It only affects sector writes, so can be loaded early in the boot sequence.

[danielj]

Excellent. And would it also explain the inability to format?

d.

[sirbod]

Excellent. And would it also explain the inability to format?

Format has to write sectors, so yes, it would definitely cause issues formatting a drive. The root cause of the issue is ADFS' adherence to the original ATA spec, which stipulated a 700uS timeout when waiting for a drive to respond to a request to send it data. This timeout was removed in later revisions of ATA, so any drive that doesn't strictly comply with ATA-1 spec will cause ADFS to timeout sector writes.

[danielj]

Fantastic... I shall give this a go with the 3010/3020. The nice thing about Wizzo on the A5000 is, however, that it lets you have 4 partitions on one drive.

All my CF/SD/IDE kit is currently compatible with everything so I shall seek out something incompatible

d.

[steve3000]

Brilliant work Jon!

I'm currently away from home, but have plenty of SD card adaptors and CF cards which fail with ADFS, so will happily spend some time testing later this week.

Wizzo solved CF cards, but not the SD adaptors that I have, so it will be intesting to see how these function with your fix.

How did you find the 'bug'? Systematic stepping through ADFS's IDE code?

[danielj]

Wizzo works perfectly with my CF-SD adaptor, which I believe is the same as the modern SD-IDE adaptors...

d.

[sirbod]

Wizzo solved CF cards, but not the SD adaptors that I have, so it will be intesting to see how these function with your fix.

I don't have any failing SD's to test, so that would be useful to know if it's the same issue. Bare in mind this only resolves write issues, so the device needs to be at least readable by ADFS.

How did you find the 'bug'? Systematic stepping through ADFS's IDE code?

Serendipity, I had a WTF moment when my Iyonix started reporting the error after updating to the 5.23 whilst getting the machines ready for the London Show. I reported the bug on ROOL as I thought it was new.

As Trapper was also seeing the error on a RiscPC I thought I'd take a quick look and did a grep for the error in the latest ADFS source. I noticed it was in a tight loop 700 times (~700uS) and only reported the error if it reached zero, so I increased the loop count not expecting anything and bugger me, no more errors.

On further reading that night of a lot of SD/HD/CF tech specs, some adhered to 700uS, but at least one specified up to 30 seconds to respond with a DRQ request. Further investigation by Jeffrey Lee determined that the DRQ timeout had been removed in the ATA-2 spec.

[steve3000]

Bad news Jon - I've tried tonight on my CF cards and 'new' SD->IDE adaptor under RISC OS 3.1 on my A4000 and A5000 - and both still fail to read under your modified ADFS.

See pics below from my A4000, fitted with a 2Gb CF card formatted to 500Mb and confirmed working fine with Wizzo IDEFS and also seems OK with ADFS under RISC OS 3.7. Note that the disc name and free space map are both read fine under RISC OS 3.1, but ADFS then freezes for about 60 seconds when you try to catalogue the drive, then pops up the Disc error 23, as shown.

Edit: I just repeated the above using the unmodified ROM version of ADFS from RISC OS 3.1, to confirm whether the error or free space map were any different, but both were identical.

So although your fix is solving a valid problem seen on later versions of ADFS (which do cope better with CF cards in my experience), unfortunately RISC OS 3.1 ADFS doesn't even get that far...

[Trapper]

Just wait I'm sure Jon has an idea. No pressure!

[sirbod]

Bad news Jon - I've tried tonight on my CF cards and 'new' SD->IDE adaptor under RISC OS 3.1 on my A4000 and A5000 - and both still fail to read under your modified ADFS.

The patch only affects writes (Disc Error 20). Reading is possibly also timing related, but not something I've seen.

Are you going to the London Show? If I had a non-working CF and adapter I can look into the read issue.

[sirbod]

Bad news Jon - I've tried tonight on my CF cards and 'new' SD->IDE adaptor under RISC OS 3.1 on my A4000 and A5000 - and both still fail to read under your modified ADFS.

The patch only affects writes (Disc Error 20). Reading is possibly also timing related, but not something I've seen.

Just had a quick look, Disc Error 23 is "controller did not respond within timeout" so this may also be fixable.

The source has a 30 sec timeout for reads, so is it actually waiting 30 seconds before reporting the error?