description: fixing some bugs

The screenshots-in-time of the problem is here.

HDDRIVER (or any other XHDI driver, like AHDI, ICD driver, and so on) after its start finds any available drives and stays resident for any other higher-level software as SCSI driver.

There are two ways of how programs use it:

1. programs like TOS, MagiC or MiNT use it for accessing the media by sectors
2. programs like HDDRUTIL or any other SW for listening to audio-CDs or burning CDs use it like some low-level SCSI driver.

For the second group of SW it does the dirty work of accessing the Atari HW and getting the data into it and out of it. The Atari HW (DMA chip) is used in 3 steps:

1. sending out the command from ST to device in PIO mode (PIO mode == every byte that is to be put out or in has to be written or read from DMA chip DATA-register)
2. output or input of the data in DMA mode (DMA mode: you set the address in memory where the transfered data is or should be put, then you say how many data should be transfered and then you just wait for the end-of-transfer of the DMA chip)
3. receiving one status byte in PIO mode

The data in 2nd step is ALWAYS transfered in DMA mode, even if the data is 4 bytes long - this is how it goes on ACSI port. And because the DMA chip has a internal 16-byte, the data transfered in DMA mode must have length divisible by 16 (so this means the length should be 16, 32, 48, ..., 512 bytes long), i.e. If you would send in DMA mode 45 bytes from the device to the Atari, then the first 32 bytes will get to memory, but the rest (13 bytes) will be stuck in internal buffer of DMA chip.

So when any SW from the second group sends a SCSI command to HDDRIVER and the SCSI command needs to transfer data with length other then a multiply of 16, the HDDRIVER will send another few commands just to make the length to be exactly multiply of 16.

This means: HDDRUTIL or any other high-level SW sends one SCSI command through HDDRIVER and gets the data from the HDDRIVER. BUT the HDDRIVER may send any SCSI commands to the device just to align the data length to the multiply of 16. It will send mostly GET_DRIVE_STATUS (4 bytes of returned data) and INQUIRY (the length of data that is to be returned can be set to almost any values).

[you may wonder why I wrote this here, but this is some useful information for anyone who wants to do anything with ACSI, or want to contribute to this or similar project.]

ACSI COMMUNICATION LAYER is used for transfering the data from and to the IDE DEVIL device. Receiving of the command bytes is done in interrupt, because the data is valid only when CS is LOW. So the interrupt is controlled by CS line of ACSI port. I think that somewhere here could be the problem described in 'Functionality' section.

SCSI EMULATION is used for understanding the SCSI commands and replying with correct values on any SCSI command that is supported, also for returning the correct 'Sense-Code', 'Additional Sense-Code' and 'Additional Sense-Code qualifier'.

And yes, what we should emulate, is SCSI. This means that any command sent to the device will be SCSI command. Forget about the commands that are used in MegaFile drives - Atari HD command set. These 10 commands are just SCSI commands which has been slightly adjusted by Atari corporation.

So forget about Atari HD command set (AHDCS) and start emulating SCSI because:

• AHDCS has a limit of 1 GB data space addressable (uses 21 bits for sector addressing, this means 2097152 sectors max., and this is 1 GB of data)
• HDDRIVER will expect that the device is a normal SCSI device and will send any SCSI-II (SCSI, level 2) commands
• because HDDRIVER thinks that the device is a normal SCSI device, he will be sometimes confused by the values that AHDCS may return instead of standard SCSI values (errors, etc.)
• AHDCS doesn't support some commands which HDDRIVER and HDDRUTIL needs for the right functioning
• Atari will work just fine with this emulated SCSI device - the first command from the Atari on boot is "read sector 0" which loads the HDDRIVER and that one then handles the device as SCSI, not as an AHDCS device

The first byte sent to the device is composed of:

• device ID to which the Atari is talking (bits 7,6,5)
• SCSI command (bits 4 to 0)

But this works only for SCSI commands which are 6 bytes long. The SCSI command may be long 6,8,10 or 12 bytes (depending on the command), so SCSI commands with length other than 6 bytes has this first byte:

• device ID to which the Atari is talking (bits 7,6,5)
• all ones (bits 4 to 0), this means value 0x1f

This is the way of letting the device to know that this wont be a 6-byte long command. It is called 'ICD communication protocol' and it is so only through ACSI port. On any other port (standard SCSI port of Falcon, TT or PC) the first byte will be normal first byte of command as described in SCSI-II technical manual.

According to Uwe Seimet (author of HDDRIVER) these SCSI commands should be supported:

• TEST UNIT READY
• REQUEST SENSE
• FORMAT
• READ
• WRITE
• INQUIRY
• START/STOP UNIT
• LOCK/UNLOCK
• READ CAPACITY
• READ LONG
• WRITE LONG

What these commands mean, what should be replied to them and so on you can read in SCSI-II specification, which is freely available over the internet in .PDF version. Not supported commands should be replied with 'Invalid command' Sense-code.

IDE COMMUNICATION LAYER is layer used for communication with the IDE drive on a HW level using LBA mode (when supported) or CHS mode when LBA is not supported (this layer also does the LBA-to-CHS translation).

 Description of this layer (what to do on HW level, what commands are to be used, and so on) wont be documented here, because there are many good documents on the internet about IDE, also there is IDE (ATA-2) specification on the internet for free, and there are many successful IDE-to-MCU projects on the internet that are well described. Please refer to them for more info or read the source code of this project.

• its good features
• is widely used within Atari users so the compatibility with it is a MUST
• it is still supported and developed by original author (Uwe Seimet) so there was a good chance that he could probably help me with development

But Uwe Seimet was not that excited about my project and questions:

• he didn't want to help me with making a small program like "read boot-sector when key 'B' is pressed" which would help me a lot and I could then focus only on the HW and the firmware. But he didn't had time, nerves, willingness, and luckily I succeeded to make my own utilities... He could save me lots of time, but he didn't.
• getting any information from his is a problem - he tries to answer as much as globaly as he can (I was not asking for anything special that he does in HDDRIVER, I'm not trying to steal his know-how or to make a new HDDRIVER that is better or cheaper than his. I.e. I was asking if he checks the level of INT wire after the 6th command byte, or if he always uses DMA mode for the second phase of ACSI transfer. This would help me a lot because it would tell me a lot about signal levels, but he didn't want to answer with straight answers and just said something like "DMA is used only for larger blocks, you should not rely on using PIO or DMA in the 2nd phase of transfer because it may change in the future". This is a pure bull-shit, because if he would try to use the PIO mode in the 2nd phase of the ACSI transfer, he would not get anything, and even small amount of data (even 4 bytes) in 2nd phase is transfered using DMA mode. In my eyes this guy sucks...
• because I had to try the partitioning and formating of the drive and these functions are not functional in demo version of HDDRIVER, I had to use my friends full version of HDDRIVER to test this. I don't really need the full version now for my daily use because I don't have now any HD connected to my Atari. So I told him that I'm using copy of my friends HDDRIVER for testing the device and that was the end of our communication - in his eyes I'm now just a SW pirate. But I won't buy SW for 35 Euro when I don't use it normally and the average payment in our country (Slovakia) is 300 Euro per month (and I dont even got that, because I'm just an student with a part time job). He says that 35 Euro is not much (not much for him, but pretty much for me).

Even thought he helped me a bit by letting me know what commands of SCSI-II should I support and that it should be only SCSI-II commands and not any AHDCS I should support. That is probably all the useful information I could get from about 20 e-mails between him and me.

I think that in these times of Atari community getting smaller every day people should be more good-willing to contribute to the community to keep it going...

DOWNLOAD SOURCE-CODE