Quote:

Is it possible, that the sector and track registers of the WD2793 are not readable or that they return different values? Currently I am trying to test an autodetect routine on my real machine, which writes and reads sector/track and runs fine on the emulator.

the SECTOR register behave just like RAM (you can write any value and to read the same value then), because that i recommend not to use this one.

Other thing is the TRACK sector, than you can write ANY value. Like 00, and then to read 00, but if you then set a STEP TRACK UP command, then when you reads the TRACK sector it reads 01.

So there is 2 verifications of behave that only the WD can BE!. Because that I thinks it is SAFE, also LITTLE code.

Wouldn't that cause disk-access though?

only a minor head movement!

and works always on WD

no needs to have a disk or the door closed...

include you can go backward starting from zero

like to reach the track 0xFF with a STEP DOWN IIRC

but that is going over the head limits, not recommended. But anyway i never saw a broken drive by doing that .

other thinks, if you writes a value on the TRACK register, it only save the value on the register, but it doesn't do nothing in the drive.

then if you use the WD commands the track register will vary but according to the value that was wrote.

So, if you wrote the value 0x10 and the head is phisically in the track 5, and you do a STEP DOWN, the value of the track register will be 0x0F, not 4.

so, at initialization, for to syncronize the physical position and the register value, you can to command a "go to TRACK 0", to execute this command is recommended and the msxdiskbasic DOES, because after a reset the head can be anywhere, this command move the head to the track 0 position and writes the value 0 in the register. If you don't do that, you actualy will read the wrong TRACK data regardless of that the track register SAYS.

UP!! This thread must be always "on top"

In another words, it should be a sticky-thread

Yes

Sorry for beeing silent the whole day. Today I helped TrebMint with the floating point routines for SymBasic. We managed nearly the complete implementation, so maybe he has a preview at the weekend, but I don't want to put him under pressure
Regarding the FDC I already tried to write/read the track register for autodetection in a way Flyguille described, but this only worked in the emulator, not on the real machine. I think there is a bug in my routine somewhere. It's a pitty, that's it not possible to access FDC registers in Basic, is it? Because of stupid XP and the single side disc drive of my VG8235 it always takes minutes to write a new version of SymbOS to disc, as I always have to use my Amstrad CPC for an in-between step.

@Flyguille: Currently I decided only to use the recalibrate command (go to track 0). So first I write two different values into the track register and check, if I can read them again. Both are >0. Then I execute a recalibrate command and after it has been finished I check, if there is a 0 in the track register. I am afraid, that with step up/down I touch the limits, so I thought this methode could be a good one.
(On some Amstrad drives it was possible to de-adjust the head, if you move outside the 40 or 80 tracks, so I am a little afraid here)

Ok, ok, if you needs my help please sendme the test routine that you made, I will checks as soon as you sendsme it...

On other hand, and as I already did a FDC routine for WD, I will to aware you about some points.

First, the calibration to cero is needed ALWAYS that you get a I/O error, as at INITIALIZATION.

when you reads secuentialy IS faster to use STEP track UP/DOWN.

when you needs to jump to a given track, use the "GO TO TRACK # " command, that is realy more faster. BUT DONT USE IT FOR just jumping to the track number that is the next or previous of the current one, in this case is correct and faster to use STEP UP/DOWN.

The normal I/O routines is faster enought to handle 1:1 reading, but as the information obtained in multitask O.S. needs to be handled then it will reduce that capability, surely because the simplicity of symbios that makes it faster you can handle 1:2 perfectly, MNBIOS is good only starting in 1:3 .

You don't needs to read the boot sector always, indeed the DISKBASIC only do that when you do a reset, and for to check a possible disk change (as it is removable).

You only needs to read the ID MEDIA that is at the first register on the FAT. And using only that you can map the access to the rest of the disk. Is recommended only to update the backup FAT when you finishs a FILE WRITE operation and only in that moment, NOT BEFORE, has no sense to update when the file is still opened. For to do that is needed a flag in the file handle structure that you use to advice to the #CLOSE function that do the update of the backupFAT.


About the GHOSTING problem.

I do this in MNBIOS.

First, as IBM assure that the faster diskjokey only can to change a disk as fast as like 1.x second, so if the last use was before that that time, you can thinks that by SURE is the same disk SAVING a lot of READS for comprobation. NO NEEDS to read boot sector and FAT within that time. if the last access was BEFORE, you needs to do the check. That will avoid the GHOSTING problem. So, by that reason the drivers for mnbios has 2 flags for this purpose.

1. CHANGED.
2. POSSIBLE CHANGED.

and is the driver (the low I/O level one) that handle those flags and do the comprobation itself, so, the low level driver also knows which is the label of the disk that is at the CACHE. IF it is wrong, the driver returns an INCORRECT DISK error.... allowing to the user to insert the correct disk without losing data because all data to write is in the cache.

If the machine supports the 34th line, the "Possible changed" is unused.



In just a 3.57mhz machine, to use a CACHE makes slower ALL disk access because the cache is divided in sectors, you needs to copy from DISK to cache and then to the "destiny driver" that can be just RAM... that architecture that is great in faster machine makes all slower on MSX. Never mind that in mnbios I also implemented a ATD area (transfer data area) which any type of driver can use performing in that way data transferences between any type of device. ALL those features will be great with fasters msx boards. I all the time was thinking if worth to do all that, NOW I know that these extra feature don't worth, by now the simplicity of symbios just lighter everybody!!!!! and FAST!!!!!!!

UP!

Quote:

@Flyguille: Currently I decided only to use the recalibrate command (go to track 0). So first I write two different values into the track register and check, if I can read them again. Both are >0. Then I execute a recalibrate command and after it has been finished I check, if there is a 0 in the track register. I am afraid, that with step up/down I touch the limits, so I thought this methode could be a good one. (On some Amstrad drives it was possible to de-adjust the head, if you move outside the 40 or 80 tracks, so I am a little afraid here)

NO POSTS?

well, I just can thinks maybe you are using wrong the flags for that command, and the emulator just ignored the flags (bits3 to 0) of the command's number

3 long days since we have no news from Prodatron... I think we should start a - Symbos for MSX - revival plan. ;p

People, usually have also many others things to to in their life... not only SYmbOS, be patient...

Yes, also now Prodatron is helping Trebmint with new SymStudio release