Jump to content
IGNORED

SpartaDOS X 4.48


drac030

Recommended Posts

6 hours ago, drac030 said:

@Kyle22 It is a "Hias-like" code. The SIO drivers are a bit complicated matter, anyways.

 

@Jeffrey Worley

 

0) True. The formatter reads the PERCOM block from the drive, but does not remember the step rate parameter. I think it is easily fixable, I found 1 free byte where it can be remembered, so if nothing else prevents the fix...

 

1) - 3) As you notice yourself, these are rather reports about the bugs in the firmware of respective drives, as the CLX behaves so because  s o m e  drives are notoriously lying in the PERCOM block returned about the geometry of the inserted floppy. Especially the XF551 looks as if the author of the firmware thought that the PERCOM data is some kind of ornament, therefore the drive notoriously returns false data.

 

Now CLX is a program to verify if the file system on the disk is correct. So this information is actually crucial if the program has to correctly reconstruct a damaged file system and especially the boot sector.

 

The only thing I think I could do it is to make CLX display the parameters it read from the PERCOM block and ask the user if these are correct. But what if the user does not know what is correct?

Both fixes are a great idea!  A note to read man page regard PERCOM block should suffice if worried.

  • Like 1
Link to comment
Share on other sites

I've also noticed that my PERCOM AT88-S1 boots up with a step rate of $02 if PERCOM block is Queried, but after formatting with SDX, step rate is set to $01, and the drive seeks noticeably faster. :) Re-querying PERCOM block reports step rate of $01 afterwards as well. True PERCOMs are probably the only drives that this actually has an effect.

 

And side note... Since PERCOM firmware does not format disks with zero filled sectors, some feature to optionally 'zero fill' disks might be nice... Maybe too much for the built-in SDX formatter, so maybe a separate utility... Could be handy for cleaning hard disk partitions too.

Link to comment
Share on other sites

@Jeffrey Worley @_The Doctor__ I am looking at the source code of the CLX and can see what I did not remember: that this program allows to specify the "correct" sector count in the command line, like this:

 

CLX A: 1440

 

It is said when one invokes the program without parameters, and it is also mentioned in the doc file, under the section "Additional parameters".

 

Does not this fix most of the problems with the lying drives? Would adding an additional parameter specifying the sector size be enough?

 

Link to comment
Share on other sites

almost, but I'd still save the step rate for case 1

and then make the percom block/XF stuff an optional parameter... I should think specifying sector size would be enough... 128 256 512?

though it is way to easy to flatten a floppy... if making a bunch of changes to make it user friendly enlarges the program too much... maybe split it off into a separate floppy utility. it half a dozen of this 6 of another sort of thing.

Edited by _The Doctor__
Link to comment
Share on other sites

14 hours ago, drac030 said:

@Kyle22 It is a "Hias-like" code. The SIO drivers are a bit complicated matter, anyways.

 

@Jeffrey Worley

 

0) True. The formatter reads the PERCOM block from the drive, but does not remember the step rate parameter. I think it is easily fixable, I found 1 free byte where it can be remembered, so if nothing else prevents the fix...

 

1) - 3) As you notice yourself, these are rather reports about the bugs in the firmware of respective drives, as the CLX behaves so because  s o m e  drives are notoriously lying in the PERCOM block returned about the geometry of the inserted floppy. Especially the XF551 looks as if the author of the firmware thought that the PERCOM data is some kind of ornament, therefore the drive notoriously returns false data.

 

Now CLX is a program to verify if the file system on the disk is correct. So this information is actually crucial if the program has to correctly reconstruct a damaged file system and especially the boot sector.

 

The only thing I think I could do it is to make CLX display the parameters it read from the PERCOM block and ask the user if these are correct. But what if the user does not know what is correct?

Well, then the user should not be running CLX on double-sided media.  I'd appreciate some flexibility, maybe have CLX with an option to set the number of sides and sectors, step rate etc.  The 1050 with happy, speedy, and doubler, all display wierd behavior with regard to density changes.  They will work find in Spartados, but will barf with CLX.  That is not normal.  CLX should:

 

c:\CLX A:

 

read the configuration from the DISK, and display the information:

report:

 

"Disk says it is 256bytes per sector, 1440 sectors, 40 tracks.  Is this correct? y/n  "

 

Y

 

Disk is double-sided.  Setting control block.

 

Running checks.....

 

Disk vtoc and free sectors are OK.

 

C:\

 

---- OR ---

 

c:\CLX A:

 

read the configuration from the DISK, and display the information:

report:

 

"Disk says it is 256bytes per sector, 1440 sectors, 40 tracks.  Is this correct? y/n  "

 

N

 

which parameter is incorrect?  Please set parameters:

 

1)  Sectors per track  _____

2)  Number of tracks ____

3)  Step Rate  ____

4)  Number of heads ____

5)  Bytes per sector ____

 

Running checks.....

 

Disk vtoc and free sectors are OK.

 

C:\

 

The second example would account for a single-sided 1440 sector, double-sided 80-track disk that might escape the program otherwise?

 

--- OR ---

 

c:\CLX A:

 

read the configuration from the DISK, and display the information:

report:

 

"Disk says it is 256bytes per sector, 1440 sectors, 80 tracks.  Is this correct? y/n  "

 

Y

 

Disk is single-sided.  Setting control block....

 

Running checks.....

 

Disk vtoc and free sectors are OK.

 

C:\

 

With regard to the Percom control block being false as read from the drive, this is true enough with respect to the 1050 and the XF551 (even with the Hyper rom installed), but the Percom is telling the truth, at least as it knows it, and holds that truth onboard as long as it has not been unpowered or the block reset.  So it would be real nice to have an option in CLX to set the block before it gives you a bunch of spurious errors.  Say I insert a ds/dd 40 track disk in my newly powered AT88SPD.  The Drive will know it is DD, but not DS.  CLX should read the data, realize it is a 40 track drive from the control block, and that the sector count is exactly twice what it should be, and prompt if this is double-sided?  and set the block and check the disk.

 

It would be nice to have a utility from the Spartados command line that did not involve any menus, something that could be included in a batch file with parameters.  You could go:

 

(PERVERT) is already taken.  It is a utility to convert early Percom disks that wrote 1A to empty sectors instead of FF.  It wrote all sectors to FF and made it so that ordinary disk copy utilities could skip the empty sectors properly.

 

c:\PERSET disk 1, spt 18, hds 2, step 0, bytes 256, tracks 80

 

"Block set for Drive 1 to 80track, double-sided, double-density, fastest step"

 

c:\ 

 

I've noticed not all drives accept all parameters of a Percom control block set command.  Some ignore the step rate (1050 USD and others), some ignore other parameters, and some just refuse to accept any parameters.  This is the drive's fault and there is nothing to be done about that, but it is not harmful to TRY and set them, at least I've not run into any situations where a drive accepted parameters it could not handle (maybe step rate on a real percom with a really old mech - result is bad reads).

 

Yes, the default step rate for Percoms is pretty slow, which is why I like to change it.  Almost any mech will do better than 2, almost all will go at 0.  The ultimate timing is determined by the mechanism in a Percom's case, as the parameter is relative to the mech's internal construction.  A zero for one drive may be 3ms, and for another mech may be 6 or 12.  Some mechs will accept parameters they can't handle, but I think that is because the mechs are actually faulty, are not able to track as fast as they were designed to track, due to age or wear or gunk or whatever, not because they are being mis-programmed.

 

 

Link to comment
Share on other sites

7 hours ago, Nezgar said:

I've also noticed that my PERCOM AT88-S1 boots up with a step rate of $02 if PERCOM block is Queried, but after formatting with SDX, step rate is set to $01, and the drive seeks noticeably faster. :) Re-querying PERCOM block reports step rate of $01 afterwards as well. True PERCOMs are probably the only drives that this actually has an effect.

 

And side note... Since PERCOM firmware does not format disks with zero filled sectors, some feature to optionally 'zero fill' disks might be nice... Maybe too much for the built-in SDX formatter, so maybe a separate utility... Could be handy for cleaning hard disk partitions too.

The ATR8000 also acts in true Percom manner and obeys all parameters set by the control block, including step.  Just for the record.

 

Best,

 

Jeff

  • Like 1
Link to comment
Share on other sites

7 hours ago, Nezgar said:

I've also noticed that my PERCOM AT88-S1 boots up with a step rate of $02 if PERCOM block is Queried, but after formatting with SDX, step rate is set to $01, and the drive seeks noticeably faster. :) Re-querying PERCOM block reports step rate of $01 afterwards as well. True PERCOMs are probably the only drives that this actually has an effect.

 

And side note... Since PERCOM firmware does not format disks with zero filled sectors, some feature to optionally 'zero fill' disks might be nice... Maybe too much for the built-in SDX formatter, so maybe a separate utility... Could be handy for cleaning hard disk partitions too.

That is only for early Percoms.  Later percoms, nearly all of them, format with zeros.  I was sure of than, but just checked a freshly formatted disk with EDDY, to make sure.  I copied the disk with SCOPY, just to make sure.  The empty disk .scp file, a ds/dd/40trk disk, is only 2200bytes.

 

Way back when, I had an original AT88, single-density drive, and it did this, formatted with 1A's instead of zeros, and I noticed it because all my .dcm files were 90k even when they should be less.  I discovered a program on COmpuserve called PERVERT, that you could run on one of these disks to pervert it to a standard zero empty disk.  It worked, but it was slow, high-level wrote zeros to all 720 sectors.  I don't think any double-density percom formats with 1A's.  So, this is an ancient, nearly non-issue.

 

Best,

 

Jeff

Link to comment
Share on other sites

44 minutes ago, Jeffrey Worley said:

The ATR8000 also acts in true Percom manner and obeys all parameters set by the control block, including step.  Just for the record.

 

Best,

 

Jeff

 

7 hours ago, Nezgar said:

I've also noticed that my PERCOM AT88-S1 boots up with a step rate of $02 if PERCOM block is Queried, but after formatting with SDX, step rate is set to $01, and the drive seeks noticeably faster. :) Re-querying PERCOM block reports step rate of $01 afterwards as well. True PERCOMs are probably the only drives that this actually has an effect.

 

And side note... Since PERCOM firmware does not format disks with zero filled sectors, some feature to optionally 'zero fill' disks might be nice... Maybe too much for the built-in SDX formatter, so maybe a separate utility... Could be handy for cleaning hard disk partitions too.

The original AT88-S1 shipped with a mech quite like the one in the 1050, and that mech could not handle fast stepping, so the rom was nailed to 12ms, but you could change the rate in the block and take your chances.  Of course, other mechs were not so limited.  I'd like to find that spot in my rom and default it to zero.  Any help?  The roms are for the 6809cpu onboard, not 650x-based, so I wouldn't know where to look.

 

Best,

 

Jeff

Link to comment
Share on other sites

33 minutes ago, Jeffrey Worley said:

The original AT88-S1 shipped with a mech quite like the one in the 1050, and that mech could not handle fast stepping, so the rom was nailed to 12ms, but you could change the rate in the block and take your chances.  Of course, other mechs were not so limited.  I'd like to find that spot in my rom and default it to zero.  Any help?  The roms are for the 6809cpu onboard, not 650x-based, so I wouldn't know where to look.

 

My AT88-S1 has a full-height mech, visually from the front like a Tandon 810 with the 'flip door', but it's actually an MPI 51S. It has an interesting electromagnet contraption that lifts the pressure pad arm in conjunction with motor off. This mechanism is a little temperamental and fails to release or only partially releases... Seems to be improving a little with more use though.

 

Regarding patching the ROM, heheh I was thinking EXACTLY the same thing. After seeing my drive stepping faster after formatting a disk with SDX, I know my drive works perfectly fine with the "1" setting. According to the WD1791 controller datasheet, these are the stepping rates:

1791stepping.thumb.png.695814ccd762a2c1c85f8bc95cf18b58.png

 

We know now from phaeron's great dissassembly work on these Percom ROM's that they don't employ any checksum routine, so a 1 byte patch should be easy. I'll take a look! Maybe formatting with zero filled sectors too...

Link to comment
Share on other sites

4 minutes ago, Nezgar said:

 

My AT88-S1 has a full-height mech, visually from the front like a Tandon 810 with the 'flip door', but it's actually an MPI 51S. It has an interesting electromagnet contraption that lifts the pressure pad arm in conjunction with motor off. This mechanism is a little temperamental and fails to release or only partially releases... Seems to be improving a little with more use though.

 

Regarding patching the ROM, heheh I was thinking EXACTLY the same thing. After seeing my drive stepping faster after formatting a disk with SDX, I know my drive works perfectly fine with the "1" setting. According to the WD1791 controller datasheet, these are the stepping rates:

1791stepping.thumb.png.695814ccd762a2c1c85f8bc95cf18b58.png

 

We know now from phaeron's great dissassembly work on these Percom ROM's that they don't employ any checksum routine, so a 1 byte patch should be easy. I'll take a look!

You can simply disconnect the head load solenoid from the drive's controller board and it will work just fine.  In most cases, the solenoid is energized when the head is 'un-loaded' and de-energized when loaded, so disconnecting the solenoid will just leave the head loaded.  I have a mech that is the reverse of that, only one I can recall that is like that.  In it's case, I simply removed the arm the solenoid engages the head with and disconnected the solenoid too, so no clicking, no load on the power supply, and it is quieter by far.  Head load solenoids are par for the course for early-ish mechanisms.  I've been disabling them for decades.  You may do so with confidence.  Just find the wires, two, usually, leading from the solenoid, to the board, and disconnect them from where they plug in.  If they are housed in a connector with other wires, they are almost certainly of the dupont-type, which have little metal flanges that engage the plastic housing for the connector.  Insert a pointy object, like a dental pick or a tiny flathead, to disengage the flange, while pulling on the wire, and it will come free from the connector housing.  Wrap it in tape or shrink-wrap the bare end to prevent it from banging around in there and shorting something, and you are now solenoid-less, thank God.

 

best,

 

Jeff

 

Solenoids were common on drives of the era because many controllers had the disks spinning whenever the drive had a disk in it, thus the solenoid made sense, to save the media unnecessary wear,, also, most controllers, the Percom and the ATR8000, also engage all motors on the mux whenever ANY id is selected, thus, constant use of drive 0 would result in equal media wear to all other drives on the bus with media loaded in them.  This is not really a concern for us, so disable the thing with confidence.

 

 

Link to comment
Share on other sites

13 minutes ago, Nezgar said:

 

My AT88-S1 has a full-height mech, visually from the front like a Tandon 810 with the 'flip door', but it's actually an MPI 51S. It has an interesting electromagnet contraption that lifts the pressure pad arm in conjunction with motor off. This mechanism is a little temperamental and fails to release or only partially releases... Seems to be improving a little with more use though.

 

Regarding patching the ROM, heheh I was thinking EXACTLY the same thing. After seeing my drive stepping faster after formatting a disk with SDX, I know my drive works perfectly fine with the "1" setting. According to the WD1791 controller datasheet, these are the stepping rates:

1791stepping.thumb.png.695814ccd762a2c1c85f8bc95cf18b58.png

 

We know now from phaeron's great dissassembly work on these Percom ROM's that they don't employ any checksum routine, so a 1 byte patch should be easy. I'll take a look!

Oh, I noticed a mention in a past post about the doubler rom.  If you want a dump of the AT88 doubler rom, just let me know and I'll dump it for you.

Link to comment
Share on other sites

The head release was from the 8 inch days... it kept the heads and pads off the disk surface unless reading or writing, 8 inch drive and certain early 5.25 drive always spun the disk or could be set to do so. This kept the heads and disks from wearing out... Keeping the disk spinning made data access faster, but you could jumper or tell the controller to keep the heads engaged. fast access with the drive always at speed and the heads engaging, even faster when both spinning and the heads loaded. I set them back to flying though these days because the disks are old and will shed material...

Edited by _The Doctor__
Link to comment
Share on other sites

 

36 minutes ago, Jeffrey Worley said:

I discovered a program on Compuserve called PERVERT, that you could run on one of these disks to pervert it to a standard zero empty disk.

Do you have this program still? I've read about it, but have never laid hands on it. Of course, technically easy to re-create, but fun to have the original program.

 

1 minute ago, Jeffrey Worley said:

Oh, I noticed a mention in a past post about the doubler rom.  If you want a dump of the AT88 doubler rom, just let me know and I'll dump it for you.

Yes I would appreciate. PM me and I can compare with existing dumps to see if it is something we haven't seen yet!

Link to comment
Share on other sites

14 minutes ago, Nezgar said:

 

My AT88-S1 has a full-height mech, visually from the front like a Tandon 810 with the 'flip door', but it's actually an MPI 51S. It has an interesting electromagnet contraption that lifts the pressure pad arm in conjunction with motor off. This mechanism is a little temperamental and fails to release or only partially releases... Seems to be improving a little with more use though.

 

Regarding patching the ROM, heheh I was thinking EXACTLY the same thing. After seeing my drive stepping faster after formatting a disk with SDX, I know my drive works perfectly fine with the "1" setting. According to the WD1791 controller datasheet, these are the stepping rates:

1791stepping.thumb.png.695814ccd762a2c1c85f8bc95cf18b58.png

 

We know now from phaeron's great dissassembly work on these Percom ROM's that they don't employ any checksum routine, so a 1 byte patch should be easy. I'll take a look!

I would lubricate that mech.  It is obviously in need of it.  Throughout.  Rails/bands, pivots, any spindle or axel.  The mech may work, but long use has shown me that drives die because of this.  I think it is because of the effort required of the electronics to power the darlington driver that powers the motors and steppers.  Especially the steppers.  A stiff stepper will overload the darlington driver and blow it.  Symptoms will be from death, to flaky operation, like it formats fine, but won't do random tracking, tracks ok one moment and dragges and skips the next.  Lubricate the mech now.  WD40 is fine.  Use a cotton swab or a precision oiler to keep the lubricant from getting all over everywhere.

 

Best,

 

Jeff

 

Link to comment
Share on other sites

1 hour ago, Nezgar said:

 

Do you have this program still? I've read about it, but have never laid hands on it. Of course, technically easy to re-create, but fun to have the original program.

 

Yes I would appreciate. PM me and I can compare with existing dumps to see if it is something we haven't seen yet!

I looked and can't find it.  It may be in an archive of CIS somewhere.  IIRC I got it from there?  In 1986 or thereabouts I got an AT88-S1, which did this, and I found the fix somewhere.  Might have gotten it from a bbs too.  In my search I found this link:  http://www.verycomputer.com/10_62ab164454e9ee08_1.htm

 

We were discussing the percom in 1999 and I mentioned Pervert then too.  I WOULD have it, but DHS took EVERYTHING, including the disks that had Pervert on them, so, no data at all from 1984 to 2004.  No PAPER even.

 

At the time, 1986 or so, I called Percom, who were still in business, sort-of.  They shipped me a doubler with a 1.4 rom version.  Do you have that rom version?  It made a difference in the density-smartness of the drives, but did not support enhanced density, which would be nice about now, since there are a ton of .ATR files (relevant to running a GOTEK on the Percom) that are in this format, though they need not be.  Lots of stuff got enhancitized accidentally in scopies/discomms etc, disks which were originally single-density.  So those disks have 707 useful sectors and the rest of the enhanced density disk are blank now.  Enhanced density would make a GOTEK a really useful addition to a Percom, as it is, it is just a toy.  It WORKS, but single and double only.

 

As for the delay in Sparta format, yes and no.  The delay exists only if a disk is present in the mech you are addressing.  If the drive is empty (door open), the formatter selects the drive instantly.

 

Best,

 

Jeff

 

 

Link to comment
Share on other sites

9 hours ago, Jeffrey Worley said:

Well, then the user should not be running CLX on double-sided media

:)

 

For a program like this, or for the DOS and its utilities in general, it does not matter how many sides a medium has. The only parameters, which matter, are the total count of sectors and the sector size. This is enough to repair the file system. The number of tracks and sides are saved to the boot sector, that is true, but this only serves as two more factors which facilitate disk change detection, otherwise these are useless.

 

9 hours ago, Jeffrey Worley said:

They will work fine in Spartados, but will barf with CLX

 

This is so because SpartaDOS relies more on the values it finds in the bootsector. CLX is an utility which is supposed to reconstruct a completely ruined bootsector, so it has to rely on something else. The only "something else" it can rely on is status block and PERCOM block. If the drive lies about the media density when interrogated about status and PERCOM, then I am very sorry, but CLX cannot do much about it :)

 

9 hours ago, Jeffrey Worley said:

but the Percom is telling the truth, at least as it knows it, and holds that truth onboard as long as it has not been unpowered or the block reset

The PERCOM data are supposed to contain information about the number of tracks, number of sectors per track, number of sides and sector size, so that the host computer's OS might calculate the size of the available storage. If there is an SSDD floppy inserted into the drive, but the drive, when interrogated about the disk geometry, tells the inquirer that it is SSSD (just because this is the power-up default or just because there was such a disk inserted previously, 5 hours ago), then such a "truth" is something we describe with some other word, IMHO.

 

Now to cure the problem:

 

as I wrote previously, I was considering adding more command line options to override the defaults, but after some considerations it seems to me that CLX is not a tool to configure floppy disk drives. So what about adding some other tool, PERCONF be its name, which would allow to setup the correct parameters manually before running CLX?

 

  • Like 1
Link to comment
Share on other sites

10 hours ago, Jeffrey Worley said:

 

The original AT88-S1 shipped with a mech quite like the one in the 1050, and that mech could not handle fast stepping, so the rom was nailed to 12ms, but you could change the rate in the block and take your chances.  Of course, other mechs were not so limited.  I'd like to find that spot in my rom and default it to zero.  Any help?  The roms are for the 6809cpu onboard, not 650x-based, so I wouldn't know where to look.

 

Best,

 

Jeff

Omnivore is a hex editor/bitmap viewer/disassembler/etc., able to configure for multiple system/CPU types. I just found  out about this software.

http://playermissile.com/omnivore/

 

  • Thanks 1
Link to comment
Share on other sites

34 minutes ago, tschak909 said:

You guys just need a CLI tool for modifying a percom block? I can write one of those in about 5 seconds.

-Thom

I'd love one.  I could write it, but in Basic, then compile it, and that makes for bloated, ugly, well, you know.

 

There was an Antic or Analog or COmpute! type-in called "DriveZap!", or maybe I called it that.  At any rate, the program was for just such.  I compiled it too, and it worked as such, but was a menu, like the one upstairs.  The best one I've found yet, since my resurrection, is the one screenshotted a couple of messages up.  Unfortunately, it is not stable under SPartados X.  It crashes on first-use.  Still WORKS, but you get one shot and then you have to hit Reset to get out of it.  Locks tight as a drum.

 

Best,

 

Jeff

Link to comment
Share on other sites

1 minute ago, tschak909 said:

Sigh...

 

seriously, some of you guys are stuck in your ways of thinking.

 

I would write it in C (compiled with CC65), and the size would not be too large.

 

-Thom

I never learned to write in machine language.  Basic I know ridiculously well, wrote a ton for Carina II, but that's really my only language.

 

Best,

 

Jeff

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...