Percom and mydos

[syscall]

Hey,

 

Until now, my understanding of the PERCOM block (and send percom command) was that this block configures the drive with selected parameters.

If any of the parameters is wrong, percom block is discarded. If parameters match one of the drive's densities, they are set hard, until next

put percom. So after setting the drive to FM with put_percom command, the drive sits there in FM until commanded otherwise by another PUT PERCOM.

Is that understanding OK?

 

Now, mydos.

If configuration is read by percom, and not by get status, Mydos does not see the difference between

SD and ED other way than by sectors per track number. FM/MFM flag is discarded.

 

So if you have ED disk, and boot mydos off it, the percom block that is sent to the drive is

for the FM/ED (which is wrong). So the dos cannot read DUP.SYS because the drive is already in FM and the disk is ED.

 

Perhaps FM/MFM flag ( Percom[5].bit2 ) in PERCOM should be discarded? I don't know, it's there for a reason.

How does the original PERCOM drive handle this?

 

Regards

[syscall]

Hey,

 

Until now, my understanding of the PERCOM block (and send percom command) was that this block configures the drive with selected parameters.

If any of the parameters is wrong, percom block is discarded. If parameters match one of the drive's densities, they are set hard, until next

put percom. So after setting the drive to FM with put_percom command, the drive sits there in FM until commanded otherwise by another PUT PERCOM.

Is that understanding OK?

 

Now, mydos.

If configuration is read by percom, and not by get status, Mydos does not see the difference between

SD and ED other way than by sectors per track number. FM/MFM flag is discarded.

 

So if you have ED disk, and boot mydos off it, the percom block that is sent to the drive is

for the FM/ED (which is wrong). So the dos cannot read DUP.SYS because the drive is already in FM and the disk is ED.

 

Perhaps FM/MFM flag ( Percom[5].bit2 ) in PERCOM should be discarded? I don't know, it's there for a reason.

How does the original PERCOM drive handle this?

 

Regards

 

OK, nevermind, seems that I was mistaken. Putting percom block to the drive seems not to mean reconfiguring it at once.

It's needed for other commands that will come later. Drive should not switch densities JUST after writing percom to it.

It's a parameter block for other commands, not a command itself. No?

[Mathy]

Hello syscall

 

It's been a while since I played around with the Percom commands and MyDOS (I'm not that active at the moment). But you have to first write the Percom block, then format a disk IIRC. However, MyDOS has some major bugs in this department. There is a beta-version of MyDOS that has this bug fixed, but it's not released yet. What MyDOS (not sure which versions, but I guess all 4.xx versions up till 4.53) does wrong is that it looks at the configuration that's stored in DUP.SYS before it does a format. So using the Percom command is useless with these versions. This bug has been fixed in the latest beta-version or the beta-version before that along with a lot of other bugs.

 

greetings

 

Mathy (not the one working on MyDOS)

[mikey]

Hey,

 

That's Mydos fault. Mydos source (mathy van nisselroy's page) MDOS.SYS, SETDRV procedure. It configures the drive as commanded by what's setup by the

user. So, if the dos thinks drive is SD, it will configure it to SD no matter what. Also it ignores the percom read from the drive. Sorry to say but this dos is a piece of crap I've even seen this bug 'overriden' in the drive (SN-360) by ignoring FM completely. Which is not too wise, since it's DOS's fault. Drive should reconfigure to whatever DOS says. In this case DOS says bullshit ;0

 

Drive should reconfigure when as soon as it gets a percom block and it's legal for its supported densities.

[Mathy]

Hello Mikey

 

As I said, it's a known bug and has been fixed in the not yet released beta version of MyDOS.

 

greetings

 

Mathy

[mikey]

Hey Mathy,

 

Yep, please fix'em bugs

 

On the side note, PERCOM was meant as the drive reconfiguration method, but most drives only accept 'known' sets of parameters.

I don't know the drive that would let me configure and format the disk in say 20 tracks, 3 sektors per track, 50 bytes per sector.

And by definition PERCOM was meant to do that

 

Another 'culprit' is that, PERCOM configures the drive's firmware, and Atari by GET STATUS ($53) should get

the medium (floppy disk) configuration.

 

To my knowledge that's a common misunderstanding to think that after writing 'DD' percom to the drive, it should reply with

256bytes/sector bit in the status, even if there's still SD disk in the drive.

In my opinion, after PUT PERCOM, drive should update it's internal variables to those from PERCOM,and that's all.

When PERCOM is read from the drive it should be exactly what you've written to it. But status is another story

It should report whats under the drive's head (physical medium) not what's in the drive's memory (drive configuration)

Maybe this will help someone, or provoke a discussion, cause I've seen so many cases of the abuse of percom and status, that

no one can be sure about it.

 

ps. anybody happens to know how xf551 or original percom drives behave?

M.