23 April 2009, 08:28 | #1 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,545
|
ICD AdIDE "undocumented information"
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) |
23 April 2009, 15:55 | #2 |
Registered User
Join Date: Aug 2001
Location: Connecticut USA
Posts: 617
|
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. |
23 April 2009, 16:53 | #3 |
Registered User
Join Date: Jan 2002
Location: Germany
Posts: 7,021
|
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 |
23 April 2009, 17:16 | #4 |
Thalion Webshrine
Join Date: Jan 2004
Location: Oxford
Posts: 14,428
|
Is this not a speed up for endian issues of 68k?
|
23 April 2009, 20:06 | #5 |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,883
|
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. |
23 April 2009, 20:35 | #6 |
Registered User
Join Date: Aug 2001
Location: Connecticut USA
Posts: 617
|
Mystery solved
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 |
23 April 2009, 20:40 | #7 |
Needs a life
Join Date: Jan 2008
Location: England
Posts: 1,707
|
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..." |
23 April 2009, 20:48 | #8 |
Registered User
Join Date: Aug 2001
Location: Connecticut USA
Posts: 617
|
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.
|
23 April 2009, 21:05 | #9 |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,883
|
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. |
23 April 2009, 23:02 | #10 |
I hate potatos and shirts
|
Tell me about it! The Add_SCSI I have on mine A500 is only capable of 400kb/s.
|
24 April 2009, 10:48 | #11 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,545
|
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..)
|
24 April 2009, 16:45 | #12 |
Registered User
Join Date: Aug 2001
Location: Connecticut USA
Posts: 617
|
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.
|
24 April 2009, 19:13 | #13 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,545
|
Quote:
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) |
|
25 April 2009, 03:02 | #14 |
Registered User
Join Date: Sep 2005
Location: melbourne
Age: 55
Posts: 541
|
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) |
18 June 2018, 00:00 | #16 |
Registered User
Join Date: Jun 2018
Location: Gothenburg/Sweden
Posts: 30
|
Reading/writing AdIDE disk images (with UAE or other tools)
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. Code:
#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); } |
18 June 2018, 09:18 | #17 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,545
|
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? |
20 July 2018, 09:46 | #18 |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,883
|
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. |
12 August 2018, 18:13 | #19 |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,883
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
"Reminder "Lincs Amiga User Group aka "LAG" Meet Sat 5th of January 2013" | rockape | News | 4 | 30 January 2013 00:06 |
CD32 Image-Name-Bug: "...(bla)[!].zip" -> "...(bla)[" / "...[test].zip" -> "...[tes" | cfTrio | support.WinUAE | 8 | 18 December 2012 16:31 |
ICD AdIDE Manual | fc.studio | request.Other | 7 | 19 March 2008 07:26 |
Problems with "Thespywholovedme", "Flood", "Shinobi" | sareks | support.Games | 12 | 03 May 2006 14:52 |
ICD adIDE 2 Capabilities | Runey | support.Hardware | 2 | 22 April 2005 05:27 |
|
|