




2.	Later I found it was a software problem in AHDI.PRG -- The timing problem 

	between the DMA controller and the drive when handshaking after the Command
	
	or Status or Data transfer. When this kind of DMA method transfer occur,
	
	first the controller send 6 bytes of the command blocks, then do some hand-

	shaking, one of the handshaking is get the status byte, but when reading

	the status byte, have to check and wait for the REQ to come, then read the

	status byte, and the rest DMA transfer can go on to finish. For the AHDI6.03

	and HDX5.01, they didn't check and waiting for the REQ to come, then they do

	the rest of DMA transfer, for some drives if their REQ come very quick, then

	AHDI6.03 and HDX5.01 won't have the timing problem, so they can work out

	fine with those kind of drives. But for some drives if their REQ come very

	slowly, like the Syquest 88MB and IBM OEM 0663E15 1.2GM drives, then the 

	AHDI6.03 and HDX5.01 will have the timing problem which makes the AHDI6.03

	can't recognize these kind of dirves, and can't read or write the drives.


3.	Now, the AHDI6.03a and HDX5.01a have fixed this kind of timing problem, I 

	wrote some codes to check the REQ before continueing to do the rest of DMA
	
	transfer in SPSCSI.S of AHDI6.03 and in HDX5.01 too. So they can work well 
	
	for Syquest 88MB and IBM OEM 0663E15 drive.


4.	Also the AHDI6.03 has another problem when it scans the drives in the train,

	it can't recognize those drive with a slow reset to the ready state inside 
	
	the drive, for example, the IBM OEM drive. After the AHDI6.03 makes the 
	
	'inquiry()' call to request the informations of this drive, AHDI right away
	
	to read the Root sector within 1 second, but IBM OEM drive is still not 
	
	read to be read after the 'inquiry()' call, it takes about 5 second to reset
	
	and get the drive ready to be read, so the 'hread()' get the non zero return 
	code which is the drive is still busy code, but the AHDI6.03 doesn't check

	this case, so AHDI treat non zero return will mean no drive in that slot, so

	the AHDI6.03 can't recognize this kind of drive. Now I add some codes in the

	'install.s' to check to see if the drive is busy, if so just loop to try to

	read it again, or time out. So the AHDI6.03a fixed this bug too.
	


6.	Fix another bug in the 'rescan()' of HDX5.01. If a floptical drive in the

	system, the HDX will think it is a removable drive, then ingnores to check 

	if it's also a SCSI drive, on the other words, forgets to set a bit in the

	'typedev' flag, which later will tell the HDX how to do the format and 

	partition. This bug exist because HDX5.01 thinks removable drive only in the
	
	ACSI train, which is not true in today. 
	

Aug - Oct 92


	Up date the HDX to 5.01 version so that can be used for the Falcon:


		a.	Changed the user interface to the scroll bar when selecting which

			unit is going to be done the partition or format operations.

		b.	Deleted the 'ship' operation from the HDX because the new hard

			disk will part the head automatically when turning off the power.



Oct - Nov 92


	Up date the other verson of HDX, which can preserve the date inside the 
	
partition when doing the repartition, to the 5.01 version level. 



Present


	Fixed a bug in the HDX5.01 so that now can be used for the SH204.

	Read AHDI source codes, and try to understand it. And try to find something 
	
	new to do.


1.	Killed a HDX 5.01 bug which gave some bombs when there was no wincap file

	next to the HDX.PRG. So now we can run the HDX 5.01 without the wincap file.

	Wincap file will be needed when those hard disks are not standard, for 
	
	example, HDX can't get the hard disk informations from those function call 
	
	'readcap()', 'inquiry()' and so on.

