ICD AdIDE "undocumented information"

[Toni Wilen]

ICD AdIDE (68000 socket IDE controller) has interesting feature, data written to harddisk is "scrambled", each 16 bit word is bitswapped using following logic:

bit 00 -> bit 15
bit 01 -> bit 00
bit 02 -> bit 14
bit 03 -> bit 01
bit 04 -> bit 13
bit 05 -> bit 02

and so on..

It is also RDB-compatible, HDToolbox can be used for partitioning (only initial initialization requires AdIDE software), but disk won't work in other "normal" RDB controllers because of bitswapping.. (also it has issues with non-OFS/FFS filsystems, Jope can explain more )

Initialization writes some AdIDE specific data to drive's very first block (which begins with string "CPRM"), without this special data AdIDE won't even install its boot rom driver during boot.

"CPRM" block is completely hidden to AmigaOS, from AmigaOS point of view first block is drive's second block.

Any explanations for this "logic", please?

(originally from here: http://eab.abime.net/showthread.php?t=44209)

[Shadowfire]

Since there is no logical reason for the implementors to *want* to have scrambled the bits that way, it would seem to be some sort of schematic or layout error. Perhaps they sent the boards out and they found out the mistake afterwards? You would work around this by changing your code when you read/write ATA registers, but you wouldn't need to deal with it when reading or writing blocks as you would read in what you wrote out.

Edit: maybe it was even a decision to keep it a 2-layer board instead of going to 4-layers? Difficult to speculate without information.

[thomas]

The Buddha software comes with a program called DriveConvert and the docs talk about "IDE controllers that have the bytes swapped on the IDE bus". Perhaps that's something similar ? As an example the AT-Apollo 2000 controller is given.

http://siliconsonic.de/t/bin/buddha.lha

[alexh]

Is this not a speed up for endian issues of 68k?

[Jope]

But it's just tracks on the PCB, isn't it.. Why would endianness matter?

My guess is that it's somehow related to the PCB layout. The AdIDE is quite a small board, so maybe they saved space by making it like that.

[Shadowfire]

Just pulled up the pinout of the IDE connector, I should have seen this earlier. What they did, was route all the 68000 Data (d0-d15) bus lines out, in order, to the IDE connector (pins 18 thru 3). This was obviously done to make the board easier to route, as it definitely made writing the firmware a bit more complicated. So, they needed to fiddle the bits when doing register & command reads/writes to the hard drive, but they didn't bother fiddling the bits for actual block data (would have killed performance for sure or required a 64K look up table).

Table A.8 - Signal assignments for connectors grounding even conductors
Signal name/Connector Contact

RESET- 1
Ground 2
DD7 3
DD8 4
DD6 5
DD9 6
DD5 7
DD10 8
DD4 9
DD11 10
DD3 11
DD12 12
DD2 13
DD13 14
DD1 15
DD14 16
DD0 17
DD15 18
Ground 19
(keypin) 20
DMARQ 21
Ground 22
DIOW- 23
Ground 24
DIOR- 25
Ground 26
IORDY 27
CSEL 28
DMACK- 29
Ground 30
INTRQ 31
Reserved 32
DA1 33
PDIAG- 34
DA0 35
DA2 36
CS0- 37
CS1- 38
DASP- 39
Ground 40

[chiark]

That is simply nuts!

So all "non data" commands have the bits swapped but data blocks don't? Crazy

That unfortunately means we can't just shove an adaptor in and have it working without the bit fiddling - not without re-writing the driver. Damn!

Can you imagine the conversation at ICD after the hardware was finalised... Perhaps before the driver was finished...

"er, boss, I think I've found a problem with the way we're doing things..."

[Shadowfire]

Not really. If you think about it, this was made before the RDB standard was accepted, and engineers had no reason to make sure that drives formatted with their software were readable on another's controller. So yes, when they were sending commands to and from the drive, and doing things like finding out (from the drive itself) its parameters, the driver would need to fiddle bits about. As I said, you wouldn't want to do this to yourself without a good reason why, and being able to actually route the traces on your board is a pretty good reason to change something like this. They may have needed to move to a more expensive PCB (bigger or more layers) otherwise.

[Jope]

But it IS RDB compatible to a certain extent.. :-)

It is actually pretty nice for what it is. Over 700kB/s on an unexpanded A500 isn't all that bad.

[rkauer]

Tell me about it! The Add_SCSI I have on mine A500 is only capable of 400kb/s.

[Toni Wilen]

Originally Posted by Shadowfire

DD7 3
DD8 4
DD6 5
DD9 6
DD5 7
DD10 8
DD4 9
DD11 10
DD3 11
DD12 12
DD2 13
DD13 14
DD1 15
DD14 16
DD0 17
DD15 18

Thanks, "problem" is solved (I still think they could have done better routing, not necessarily 1:1 but at least something "easier" without making the PCB more expensive..)

[Shadowfire]

Hey... just take a look at the board. If it's a 2-layer board, it's almost a miracle that they were able to route it at all in that tiny amount of space.

[Toni Wilen]

Originally Posted by Shadowfire

Hey... just take a look at the board. If it's a 2-layer board, it's almost a miracle that they were able to route it at all in that tiny amount of space.

I don't have one (and images don't count!) but fine, you are right

I don't and can't normally implement anything hardware specific without having one for testing, fortunately Jope had one and he really knows what he is doing(tm)

[gizmomelb]

hmm wonder if it'd be possible to cheaply implement the functionality of an ADIDE (or similar) using a programmable FPGA, PIC or ARM? I know that'd make a hell of a lot of A500 owners happy.

Either have an IDE interface (so you can use 2.5" HDs or CF cards) or have the IDE 'emulated' and have the storage be on a SD card (or even use hardfiles)

[rkauer]

psst!

[MiaM]

Hi!

I hope it's okay to dig up an old thread.

I'm new to this forum but not to Amiga. This is the first thing I write on this forum.

I just aquired an A500 with an AdIDE.

I read out the disk using a more modern computer, and wrote a small program to swap the bit order and to cut the first bytes which according to this thread, or the thread linked in the start of this thread, is specific to the AdIDE controller. The result is an image file that starts with RDSK and obviously contain amiga data. The unix command "strings" shows text strings that's obviously english language, for example stuff that seems to belong in an adventure game, so it seems like the bit swapping itself is correct.

However the file won't mount as an image in UAE and I had no luck trying to read the partition table or mount it using Linux tools capable of understanding Amiga RDB disk forkat.

The disk itself is a bit flakey, when in use in the Amiga it sometimes spins down both when using the Amigas own PSU (it was hooked up that way when I bought it, it seems a bit excessive to power a 120MB IDE disk, complete A500, AdIDE controller, AdSPEED accelerator and A580 memory expansion, even with the more modern 4.5A A500 psu) and also when using a separate PC PSU, but it gave no errors when read sequentially in a modern box.

My main two interests is to preserve contents from the disk and to be able to write data to a replacement disk using a more modern computer. Of course I can use diskettes or transfer data using both an AdIDE and a SCSI controller on the same Amiga, but it would be far faster to just partition and format a new disk using AdIDE and then add files to it using a PC. Also I'm not sure that I have any SCSI disk left that haven't gone bad.

I'm not willing to upload the complete disk image somewhere until I have examined it. I always search for personal stuff and make sure that nothing too personal ends up on the net. (For example while preserving disks for another system I found a letter to an insurance compani with detailed claims for various problems related to a car crash, complete with personal details. That kind of stuff should never end up somewhere publically accessible).

Maybe I'll have to read out the rom contents (I assuem that the full rom is always mapped in Amigas adress space while the computer is booted and thus it's easy to just dump it) and disassemble it.

This is my source code. If you want to read a complete disk including the AdIDE specific header, you might want to remove the "512" thing in the code. Beware that it reads two bytes at a time, so 512 is actually 512 words, i.e. 1024 bytes.

#include <stdio.h>
#include <stdlib.h>

int main ()
{
    FILE *in,*out;
    unsigned char ina,inb,outa,outb;
    int i;
    in=fopen("amigaAdIDEdump","rb");
    if (in==NULL)
    {
        printf("error opening infile\n");
        exit(1);
    }
    out=fopen("amigaconverted","wb");
    if (out==NULL)
    {
        printf("error opening outfile\n");
        exit(1);
    }
    
    i=0;
    while (!feof(in))
    {
        ina = fgetc (in);
        if (feof(in))
        {
            fclose (in);
            fclose (out);
            printf ("\n");
            exit (0);
        }
        inb = fgetc (in);
        outa=0;outb=0; // A=15-8, B=7-0
        //printf("i %x %x ",ina,inb);
        if (ina&0x80) outb=outb|1;
        if (inb&0x01) outb=outb|2;
        if (ina&0x40) outb=outb|4;
        if (inb&0x02) outb=outb|8;
        if (ina&0x20) outb=outb|16;
        if (inb&0x04) outb=outb|32;
        if (ina&0x10) outb=outb|64;
        if (inb&0x08) outb=outb|128;
        if (ina&0x08) outa=outa|1;
        if (inb&0x10) outa=outa|2;
        if (ina&0x04) outa=outa|4;
        if (inb&0x20) outa=outa|8;
        if (ina&0x02) outa=outa|16;
        if (inb&0x40) outa=outa|32;
        if (ina&0x01) outa=outa|64;
        if (inb&0x80) outa=outa|128;
        //printf("%x %x ",outa,outb);
        if (i>=512)
        {
            fputc(outa,out);
            fputc(outb,out);       
        }
        i++;
    }    
    fclose (in);
    fclose(out);
    printf (" Error: odd length of infile\n");
    return (1);
}

[Toni Wilen]

Try only stripping first 512 bytes. (WinUAE only "hides" first 512 bytes when it detects AdIDE "scrambled" disk). RDSK block does not need to be in first block, it can be located in any block from 0 to 15.

ROM is located at $e98000 to $e9ffff. (Note that address will change if AdIDE isn't first autoconfig device but your Amiga config don't have other autoconfig devices)

What does "version full icddiskide.device" return?

[Jope]

I was just playing around with my AdIDE for the last time (it's going to a new home in the next weeks)..

Seems the max geometry I could get to work is 16/63/2920. More heads or cylinders in ICDPrepHD's IDE Config and formatting fails. I was using some previous Aminet release of PFS3AIO to format.. It always ended up with an unvalidated volume, even though the format didn't crash the system or anything.

The partition lowcyl is 2 and highcyl is 2919, couldn't go higher.

[Jope]

Originally Posted by Toni Wilen

(also it has issues with non-OFS/FFS filsystems, Jope can explain more )

This "feature" bit us again. :-)

It actually disregards the filesystem. If you have FFS as the dostype, you get FFS. If you have anything else, it is treated as OFS.