Percom AT-88 Doubler - ROM?

[BillC]

1 minute ago, _The Doctor__ said:

nice observation, this bit of information should be propagated not only through this but similar threads. thanks for the heads up!

It only affects the 2716 or smaller, it wouldn't affect a 2732 since they do use A11.

[+Nezgar]

Good stuff. Interesting it actually supports DD. So it could be 1.0, or 1.1. ? It would make sense for Percom to build it with DD in mind from the start I guess, and simplify/cost reduce the hardware initially, with a later planned hardware upgrade path.

 

I've replaced the dump attached in the earlier post with the good one and removed the others to prevent confusion/spread of bad dumps.

[+Nezgar]

So I have learned from @Jeffrey Worley that back in the day be personally recalls receiving a V1.4 ROM for his AT88-S1, which formatted disks with zero filled sectors which is a feature he can attest to as it was a feature he specifically inquired with Percom about. As it stands, V1.2 formats disks with sectors filled with $1A1A for single density and $9249 for double (except for the last 4 bytes, which I believe the controller probably doesn't allow configuring during format) - This is as expected according to Phaeron's disassembly of AT88-S1 V1.2. So now we are in search of both a V1.3 and a V1.4!

 

In other news, Jeffrey also graciously provided me a ROM dump from his Percom AT88-SPD. This is from a 4K 2732 EPROM, of which the first 2K appears to be fully in use, the 2nd 2K mostly zero-filled, save for 16 bytes at the end. Programming the first 2K only to a 2716 EPROM results in a non-functional drive, so it seems it expects the whole 4K of ROM, unlike the non-SPD model which uses a 2716.

 

Supposed features:

- zero-fills formatted sectors in both SD and DD

- is "Density Smart" (??) according to percom

- Printer support?

 

AT88-SPD ROM Dump (unknown version) attached.

Percom AT88SPD 575C9833.BIN

[Jeffrey Worley]

2 hours ago, Nezgar said:

So I have learned from @Jeffrey Worley that back in the day be personally recalls receiving a V1.4 ROM for his AT88-S1, which formatted disks with zero filled sectors which is a feature he can attest to as it was a feature he specifically inquired with Percom about. As it stands, V1.2 formats disks with sectors filled with $1A1A for single density and $9249 for double (except for the last 4 bytes, which I believe the controller probably doesn't allow configuring during format) - This is as expected according to Phaeron's disassembly of AT88-S1 V1.2. So now we are in search of both a V1.3 and a V1.4!

 

In other news, Jeffrey also graciously provided me a ROM dump from his Percom AT88-SPD. This is from a 4K 2732 EPROM, of which the first 2K appears to be fully in use, the 2nd 2K mostly zero-filled, save for 16 bytes at the end. Programming the first 2K only to a 2716 EPROM results in a non-functional drive, so it seems it expects the whole 4K of ROM, unlike the non-SPD model which uses a 2716.

 

Supposed features:

- zero-fills formatted sectors in both SD and DD

- is "Density Smart" (??) according to percom

- Printer support?

 

AT88-SPD ROM Dump (unknown version) attached.

Percom AT88SPD 575C9833.BIN 4 kB · 3 downloads

I got the rom and a doubler board in 1987?  I'd noticed the drive I'd got was single-density only and that my discomm and scopy files were always 90k, even on empty disks done for testing.  I noticed that the sectors were all filled with 1A's, as you can see the data fly by with some copiers.  I managed to find Percom, I think the folks I spoke to were in Georgia, but my memory on that account is really fuzzy.  It might even have been 1988.  I knew the company was moribund and was surprised as heck to speak to a person.  The fellow knew my problem and sold me on a doubler.  I asked him if the new rom would fix the 1A problem and he said it would.  He also said that the new version of rom I was receiving would enhance the density-smartness of the drive.  I got the board and rom and fitted them and it did all he claimed it would.  The disks were zero-filled in both densities (it is only now that I know that there is a difference between the fill for the two densities, this message informed me, and clarified why I got different fills when I checked in concert with Nezgar this evening).  The drive I wound up with did not display that behavior because it zero filled when formatting in either.  I wasn't happy with the drive because it was flaky, as all percoms I found seemed to be.  I always suspected the electrolytics on them, as I did with the ATR8000, especially when fitted with a copower board, but didn't have the resources to find a matching set of capacitors to replace them just to try.  Nowadays that's a snap and cheap too.  I recently revived two junked and very non-working percoms by doing just that, and by, of course, replacing the broken-legged (a notorious problem with percoms) voltage regulators with non-broken-legged ones.  The drives are rock-solid, so that supports my electrolytics theory.   They are as good as any Atari drive out there and I've put the SPD through the wringer.

 

The SPD does in fact have a printer port on the back of it.  I have the manual for that one.  The printer port is a simple pin-header of 34 pins.  Pin 32 is deleted for keying.  The connector is vertically oriented, with pin 1 up, located on the tongue that extends out of the drive ending in a card-edge for slave drives to be installed.  The SPD also has a dip socket for a terminating resistor pack to be installed externally.  I suppose this is to make it unnecessary  to access the enclosure and yank a terminator from the factory-installed mech if you add slaves.  The SPD manual is not worth the paper is is printed on, except that it DOES provide pinout for the printer port:

 

Strobe               1

D0                     3

d1                      5

d2                      7

d3                      9

d4                     11

d5                    13

d6                    15

d7                    17Percom At-88SPD User Manual.pdf

Busy               21

ground            31

strobe return   2  (Must be grounded to work)

 

I suppose a scan of this manual would have some historical significance?  I was unaware, though I've never personally seen any other Percom than the Standard AT88 we all know (with a doubler board riding pickaback on the main board).  The SPD is a completely different drive.  The board is on the left-hand side of the enclosure is about the length of an entire standard AT88 drive.  The enclosure is commensurately longer, about two inches longer, and there are no daughter boards evident.  It uses the same hardware as the standard AT88.  Heck, I had better take some photos of this thing hadn't I?  The rom was naked on arrival, as the two drives I bought were in pieces and one was mechless.  One came with a Cannon MDD-210 mech, obviously not original equipment, but which works very well.  I disabled the annoying head-load solenoid.  This mech also has a switch-selectable solenoid which locks the door when the drive is being addressed.  That also clicked loudly, so I switched it off.  One thing I noticed immediately on getting the drive to work, was that it makes zero-sector fresh floppies.  The rom is not original perhaps, but I tend to think it is.  The missing label probably fell off a long time ago, and as the drive was not assembled, could have got anywhere.

 

I tested a mod Nezgar made this evening of the At88 (original) rom, a 2716, burnt it to a 2732, having copied the data to the region over 07ff to make it work, and it does work.  The drive zero fills on format in either density.  The mod to the step rate did not change the default from 02, so I wonder what it DID do?  Nezgar will probably address that at some later date.  So far though, the drive seems none the worse for the change, and a good deal better as far as the formatting goes.

 

I'll be happy to share whatever information I have or can get.  I don't have the Pervert utility any more.  All my data from 2004 to 1985 is gone, or at least not in my hands any longer.   The utility simply wrote zeros to all sectors on a disk, which ws tedious; wasn't a real fix, though it did perform it's intended function.  It was a freeware from a user, not a tool from Percom or anyone official.

 

Oh, heck, I forgot.  When I was thinking of scanning this manual just now, I remembered that I'd had to remove the plastic spiral binding to do it long ago and what a pain in the butt that was, so I looked in Documents and LO!  Here attached is said manual in glorious color.

  Oops.  I just looked through the manual and I think I missed the page with the pinout for the printer port.  Crap.  I'll re-scan it.

Best,

 

jeff

Edited April 6, 2020 by Jeffrey Worley
This editor doesn't support a TAB?! What?

[phaeron]

AT88-SPD firmware disassembly attached. Differences from AT-88 V1.2:

• PIA and interrupt usage adjusted for the SPD, which has an incompatible setup to the AT-88.
• Format sector fill is indeed $0000 instead of $E5E5 or $6DB6.
• 1771 FDC detection and switching code is absent, the code simply assumes 1791/1795.
• Read and write sector commands have a small delay added prior to ACK, probably a timing compatibility fix for some DOS.
• Fix for a bug where the retry count was corrupted during read/write sector.
• Fix for a bug where deleted or long sectors were treated as a retryable failure for some but not all retries; now they are consistently non-retryable.
• Read sector timeout shortened from 1 second to 0.32 seconds.
• Force Interrupt is issued to the FDC after a read or write timeout.
• Parallel printer is supported on ID $40. There is one quirk with it, which is that by default it will force blank lines to be output as a space + CR instead of just a CR unless the printing mode is set to 'P' ($50). Mode P bypasses EOL translation and just sends all 40 bytes out raw to the printer.

Sadly, while available schematics show that the SPD has high speed support by enabling an external clock from SIO CLOCK OUT, this isn't used by the firmware.

 

Thanks to Chilly Willy, we have almost a complete disassembly of another SPD ROM revision:

 

Sadly, there is no complete ROM image and the listing omits the interrupt vectors, but there is enough in the listing to reconstruct almost the whole ROM. It has all of the AT88/RFD V1.2 fixes, but lacks some of the changes in this ROM like the zero fill on format, so it is an older version. Given the apparently common code base and versioning that Percom seemed to use these two ROMs may very well be V1.3 and V1.4. The older firmware has a funny bug in the status routine that prevented it from returning printer status properly, lacks the space+CR workaround for empty lines, and lacks the pre-ACK delays.

 

percom-at88spd.s

[Jeffrey Worley]

45 minutes ago, phaeron said:

AT88-SPD firmware disassembly attached. Differences from AT-88 V1.2:

• PIA and interrupt usage adjusted for the SPD, which has an incompatible setup to the AT-88.
• Format sector fill is indeed $0000 instead of $E5E5 or $6DB6.
• 1771 FDC detection and switching code is absent, the code simply assumes 1791/1795.
• Read and write sector commands have a small delay added prior to ACK, probably a timing compatibility fix for some DOS.
• Fix for a bug where the retry count was corrupted during read/write sector.
• Fix for a bug where deleted or long sectors were treated as a retryable failure for some but not all retries; now they are consistently non-retryable.
• Read sector timeout shortened from 1 second to 0.32 seconds.
• Force Interrupt is issued to the FDC after a read or write timeout.
• Parallel printer is supported on ID $40. There is one quirk with it, which is that by default it will force blank lines to be output as a space + CR instead of just a CR unless the printing mode is set to 'P' ($50). Mode P bypasses EOL translation and just sends all 40 bytes out raw to the printer.

Sadly, while available schematics show that the SPD has high speed support by enabling an external clock from SIO CLOCK OUT, this isn't used by the firmware.

 

Thanks to Chilly Willy, we have almost a complete disassembly of another SPD ROM revision:

 

Sadly, there is no complete ROM image and the listing omits the interrupt vectors, but there is enough in the listing to reconstruct almost the whole ROM. It has all of the AT88/RFD V1.2 fixes, but lacks some of the changes in this ROM like the zero fill on format, so it is an older version. Given the apparently common code base and versioning that Percom seemed to use these two ROMs may very well be V1.3 and V1.4. The older firmware has a funny bug in the status routine that prevented it from returning printer status properly, lacks the space+CR workaround for empty lines, and lacks the pre-ACK delays.

 

percom-at88spd.s 70.88 kB · 2 downloads

There's a ton of space available in the rom.  I know I'm the only user, or maybe one of a handful, would it be worth it to you to implement Ultraspeed and to adjust the default step rate to zero?

 

Best,

 

Jeff

[Mathy]

Hello Jeff

 

16 hours ago, Jeffrey Worley said:

There's a ton of space available in the rom.  I know I'm the only user, or maybe one of a handful, would it be worth it to you to implement Ultraspeed and to adjust the default step rate to zero?

 

IIRC the Astra drives used a ROM that was based on the Percom drives ROM.  Maybe you can try out one of the Astra ROMs.

 

Sincerely

 

Mathy

[JR>]

Here's my 2 AT88-S1PD dumps. Hand written labels. labeled v1.11 1/9/84 and v1.21 5/4/84. Both also have 0073 written on the label.  Both are later DD models with just 1795-PL controllers and half height mechs.

 

PercomAT88-S1PDv1.11-1-9-84.ROMPercomAT88-S1PDv1.21-5-4-84.ROM

[+Nezgar]

Very nice, thanks @JR>.

 

PercomAT88-S1PDv1.11-1-9-84.ROM = CRC32 87A0D7E7

PercomAT88-S1PDv1.21-5-4-84.ROM = CRC32 FC6675F2

 

So both are different CRC32 than Jeffrey's, and visual hexeditor inspection shows substantial change/shift between all three - not just 1 byte different.

 

They all use just over 2K, with slightly different 16 byte sequences at the end. Ordering solely on the length of main data block from smallest to largest, they would go this order:

 

"PercomAT88-S1PDv1.11-1-9-84.ROM" = CRC32 87A0D7E7 - last byte: 8F0

"PercomAT88-S1PDv1.21-5-4-84.ROM" = CRC32 FC6675F2 - last byte: 8F3

"Percom AT88SPD 575C9833.BIN" - last byte: 8FE

 

Of course code enhancement can shrink code too. The string of 16 bytes at the end of the ROM changes slightly for each as well.

[+MrFish]

According to this (from the doubler installation manual), I guess a lot of single-density ROMs ended up in the trash. Amazing...

 

-------------------------------------

 

Replace the AT-88 ROM on the Controller Printed Circuit Board

 

In order for the Doubler to work, you must replace the old AT-88 ROM with the
new AT-88 ROM. (The new AT-88 ROM supports double density.)

 

Find the old AT-88 ROM on the Controller Printed Circuit Board; it is inserted
into the black plastic socket labeled U8. Gently remove the old AT-88 ROM and
throw it away. Insert the new AT-88 ROM into the black plastic socket labeled
U8.
 

Edited April 8, 2020 by MrFish

[+MrFish]

Apparently the data separator board has nothing valuable on it either...

 

-------------------------------------------

 

If you have Configuration A, throw the single-density data separator (small
square circuit board about 2 inches by 2 inches) away. The Doubler that you
purchased contains a single-density and double-density data separator;
therefore, no options are lost by throwing away the single-density separator.
Continue with the next section, Insert the Integrated circuit on the Doubler.
 

[phaeron]

How many firmware versions did Percom make? ? Good thing we have a disk drive historian here....

 

It looks like V1.11 and V1.21 slot in between the versions Chilly Willy had and Nezgar had. Pretty much blows the theory out of the water of versions being matched against the RFD series, as AT88-S1PD V1.11 has fixes that were in RFD V1.20. These appear to be the changes and the ordering:

 

• Chilly Willy -> JR> V1.11:
  • default step rate changed from 0 to 1
  • space+CR printed for blank lines
  • printer delay logic fixed and improved
• JR> V1.11 -> JR> V1.21:
  • printer timeout and delays increased
• JR> V1.21 -> Jeffrey Worley:
  • sector fill changed from $E5E5/$6DB6 -> $0000
  • delays added after ACK for read/write/put sector
  • read sector fixed to do density detection on track 1, sector 1 for all drives, not just D1:

Haven't finished the disassemblies for V1.11 and V1.21 yet, but they are booting in emulation.

 

As for the manual telling you to toss the old hardware, that seems in line with the whimsical yet mostly information-free writing style. It's interesting to contrast that with the support stories, where it sounds like they were almost burning the EPROMs while on the phone.

 

[+Nezgar]

On 4/6/2020 at 4:05 AM, Jeffrey Worley said:

I tested a mod Nezgar made this evening of the At88 (original) rom, a 2716, burnt it to a 2732, having copied the data to the region over 07ff to make it work, and it does work.  The drive zero fills on format in either density.  The mod to the step rate did not change the default from 02, so I wonder what it DID do?  Nezgar will probably address that at some later date.  So far though, the drive seems none the worse for the change, and a good deal better as far as the formatting goes.

 

On 4/6/2020 at 8:05 PM, Jeffrey Worley said:

I know I'm the only user, or maybe one of a handful, would it be worth it to you to implement Ultraspeed and to adjust the default step rate to zero?

 

At risk of polluting the pool of "genuine" ROM's out there, I went ahead and patched the AT88-S1 v1.20 ROM with the following "enhancements" for Jeffrey's, and my own satisfaction. It was a breeze thanks to Phaeron's dissassembly, and the fact there is no POST checksum. Maybe someone else out there will enjoy.

• Replaced 1A1A at offset $34-35 with 0000 (Single Density format fill bytes)

• Replaced 9249 at offset $44-45 with 0000 (Double Density format fill bytes)

• Replaced 02 at offset 0DD with 00 to set the default step rate to 0. In Double Density this results in a 6ms step rate on the 1791 controller, and in single density this results in 12ms step rate on the 1771 controller.

• Replaced 6270 at offset 763-764 with 20D0 in the 1 second delay subroutine to reduce the delay after "motor on" to 1/3 second instead of 1.0 second. I wasn't sure whether to be aggressive and set it at 1/4S, or less at 1/2s, so I settled on 0.33s. I'm happy to report this change resolves the problem I had using this drive with Hias' highspeed SIO patched OS. The MPI 51S Manual states "A minimum of 1.0 second is required before performing a read or write after a MOTOR ON command is transmitted to the device" - so that's probably where that value came from...

• The drive seems to occasionally blow revs when reading/writing sectors sequentially in DD, so I tried replacing the 15:1 double density format interleave with the 17:1 interleave sector order used by the US Doubler & Super Archiver... But I decided not to keep that change as it just seemed too much slower in practice. Maybe a 16:1 interleave would be a compromise, but no other drive uses that so I'd have to invent a new sector order.

• The single density sector interleave was already the same "Chicago" interleave used in the Archiver 810, Happy 810, 1050 US Doubler, etc, - which is already about 10% faster than the Atari's 9:1 810 Rev C interleave.  I did not alter it.

I also determined that the code only needs to be present in the "upper" 2KB if using a 2732, since pin 21 (2732 A11) is kept "high" by the drive. (Pin 21 is /CS3 on a 2716)

 

It's really nice to see my drive drive zipping along with the fastest step rate by default now.  Anyhow, maybe someone else will find value in this as well. Still hope to see aforementioned V1.3/V1.4 eventually with hopefully improved density detection routines...

AT88-S1 v1.2 Patched Step0-ZeroFill-0.3sDelay.bin

[+Nezgar]

11 hours ago, Mathy said:

IIRC the Astra drives used a ROM that was based on the Percom drives ROM.  Maybe you can try out one of the Astra ROMs.

They are here:

https://atariage.com/forums/topic/300650-anyone-have-percom-firmware-dumps/?do=findComment&comment=4431949

 

In the post right after, Phaeron confirmed the Astra 1620 and Astra 1001 ROMs are exactly the same as the Percom RFD40 (Ver 1.10) ROM, with a 1 byte difference for the default step rate - 2 in the Percom ROM, and 1 in the Astra ROM.

 

5 hours ago, MrFish said:

According to this (from the doubler installation manual), I guess a lot of single-density ROMs ended up in the trash. Amazing...

No ROM's on that board, only basic LS logic IC's and a clock crystal as seen in post #18.

 

There's a bit of history behind Percom's single density data separators... They were popular for TRS-80's, as their controller design had the same flaw as Atari's original 810's - they both failed to use an external data separator even though the WD1771 data sheet recommended it for reliability. http://www.trs-80.org/percom-separator/ Apparently, many "Percom separators" were being installed into 810's prior to Atari offering their own by late 81. I see there is mention in the A8 FAQ about it, so it must have been marketed at some point for older Atari 810's:

Separator, by Percom, 1982
 - Data/clock separator circuit for 1980-1981 810 drives without Atari's
   Data Separator Board

 

[+MrFish]

3 hours ago, phaeron said:

How many firmware versions did Percom make? ? Good thing we have a disk drive historian here....

Kind of bewildering; it seems like they were constantly working on the stuff -- compared to what other Atari drive manufacturers put out for firmware; of course they did have a variety of drives/configurations.

  

3 hours ago, phaeron said:

As for the manual telling you to toss the old hardware, that seems in line with the whimsical yet mostly information-free writing style. It's interesting to contrast that with the support stories, where it sounds like they were almost burning the EPROMs while on the phone.

In spite of how my posts about it sounded, I actually got a pretty good chuckle reading it. Who knows how serious they might have been. 

 

I also got a laugh out of this one. Maybe a joke too.

 

Gently remove the Controller Integrated Circuit (labeled 1771) from Configuration A or Configuration B with a flat-head screw driver or a nail file. Pry up one end of the chip a little bit using the screw driver or nail file, then pry up the other end of the chip. Repeat at both ends as necessary and then lift off the chip. Do not pry the black plastic socket from the circuit board. Put the Controller Integrated Circuit (labeled 1771) aside.

 

[+MrFish]

26 minutes ago, Nezgar said:

No ROM's on that board, only basic LS logic IC's and a clock crystal as seen in post #18.

I wasn't talking about the data separator board in the post you're answering of mine here.

 

[+Nezgar]

4 minutes ago, MrFish said:

I wasn't talking about the data separator board in the post you're answering of mine here.

It appears I completely invented in my head that you said data separator board... sorry, time for me to get some sleep I guess. ??

[+MrFish]

1 minute ago, Nezgar said:

It appears I completely invented that you said data separator board... sorry, time for me to get some sleep I guess. ??

Haha... maybe you mixed up my two posts. One was about replacing the ROM and the other about getting rid of the data separator board. I'm all over the place...

 

[Jeffrey Worley]

Here's the rom from my most  recent acquisition Percom-wise, a practically new AT88-S1PD drive.  Has a FLIPPY MPI belt-driven mech.  One of the voltage regulators was badly mounted, twisted and shorted.  I think replacing it alone will put the drive on the road.  It is alive as-is, but THe board is not getting enough 5volts to drive the floppy bus.  Oops.  Replacing just that regulator did not do the trick.  I still have to replace the electrolytics.  Percom used ones that ought to have been replaced at final inspection.

 

Best,

 

Jeff

At88S1PD rom from SN 3348064CU.BIN

Edited May 22, 2020 by Jeffrey Worley

[phaeron]

2 hours ago, Jeffrey Worley said:

Here's the rom from my most  recent acquisition Percom-wise, a practically new AT88-S1PD drive.  Has a FLIPPY MPI belt-driven mech.  One of the voltage regulators was badly mounted, twisted and shorted.  I think replacing it alone will put the drive on the road.  It is alive as-is, but THe board is not getting enough 5volts to drive the floppy bus.

 

Best,

 

Jeff

At88S1PD rom from SN 3348064CU.BIN 4 kB · 1 download

This ROM is nearly identical to v1.11, except that the default step rate has been changed from 1 to 0. Were there any label markings on the ROM chip itself, like a date or version number?

[Jeffrey Worley]

5 minutes ago, phaeron said:

This ROM is nearly identical to v1.11, except that the default step rate has been changed from 1 to 0. Were there any label markings on the ROM chip itself, like a date or version number?

No markings at all, just a strip of purple tape over the top, a strip about four inches long.  I think it is factory, based on the condition of the drive.  It was virgin til' I opened it, I am pretty sure.

 

[Jeffrey Worley]

Well, I replaced all the 33uf 16volt electrolytics as well as the shorted 7805, and the external slave (with its own P/S) will now format disks, but fails to write after a few sectors.  The onboard drive mech won't even format, well, goes through the first pass and fails to verify at all.  So I have ordered replacement power caps as well.  It won't be til the middle of the week that I have those but I'm confident they will solve the issue, guessing, that since a mech powered by the Percom's power board won't format and one on a separate supply will, that perhaps the power caps are bad as well.  It would be 100% then for every percom I've run across in the past forever.

 

As for ultraspeed, the MC6850P ACIA used in this model Percom has clock divisors of 1, 16, and 64.  I don't know which one is in use at present or if the other two in the range are of use in a high-speed/ultraspeed implementation, but thought I'd make the observation that the datasheet mentions these divisors and see if it rang any bells with Mr. Martian.  Since it uses a UART of a sort, I gather it is a serious complication, but these divisors are of use perhaps?  If one of the divisors was useful if the board had a different clock frequency base, then maybe we can swap crystals and create an ultraspeed rate with the combination of that, the divisor of choice, and a rom switch?

 

I don't really get the numbers.  The board has a 4mhz crystal.  I don't know what that may be divided to, but if 2mhz or 1mhz base clock, then the 16 and 64 divisors give numbers that don't make a lot of sense.  1mhz/64=15625, 2mhz=31250 ....   1/16=62500 and 2/16=125000.  Now that last number makes some sense as it is the bitrate for single density, but that would be the controller's deal, not the ACIA.  I don't know enough about this stuff to really begin.

 

Best,

 

Jeff

Edited May 22, 2020 by Jeffrey Worley

[Jeffrey Worley]

The percom is alive and well.  I replaced both 7805's.  The other one must have been damaged by the shorting of the first.  The missing door pin I found as the shaft of a freebie little screwdriver I'd gotten which plastic handle had broken but which I'd been unable to throw away.   The shaft was EXACTLY the length and diameter I needed to replace the door slide-pin on the mech.  I had forgotten I had to disable HSIO for the Percom in the U1MB menu or it would barf on writes, which confused me for longer than I care to admit.  Now the drive works like a champ. Woot!

 

Jeff

[Jeffrey Worley]

On 5/21/2020 at 11:47 PM, phaeron said:

This ROM is nearly identical to v1.11, except that the default step rate has been changed from 1 to 0. Were there any label markings on the ROM chip itself, like a date or version number?

I think you are mistaken about the step rate.  The default is 2.  I know this from reading the control block rather than the rom.  It also seems to differ in that the slave mech I usually use on my Percom is not density-smart when running on this controller.   I'm going to have to check the other one out, but the internal mech (d1:) is density-smart.  Go figure.

 

best,

 

Jeff

[phaeron]

On 5/22/2020 at 12:42 AM, Jeffrey Worley said:

As for ultraspeed, the MC6850P ACIA used in this model Percom has clock divisors of 1, 16, and 64.  I don't know which one is in use at present or if the other two in the range are of use in a high-speed/ultraspeed implementation, but thought I'd make the observation that the datasheet mentions these divisors and see if it rang any bells with Mr. Martian.  Since it uses a UART of a sort, I gather it is a serious complication, but these divisors are of use perhaps?  If one of the divisors was useful if the board had a different clock frequency base, then maybe we can swap crystals and create an ultraspeed rate with the combination of that, the divisor of choice, and a rom switch?

 

I don't really get the numbers.  The board has a 4mhz crystal.  I don't know what that may be divided to, but if 2mhz or 1mhz base clock, then the 16 and 64 divisors give numbers that don't make a lot of sense.  1mhz/64=15625, 2mhz=31250 ....   1/16=62500 and 2/16=125000.  Now that last number makes some sense as it is the bitrate for single density, but that would be the controller's deal, not the ACIA.  I don't know enough about this stuff to really begin.

There is a hardware divider that divides the 4MHz clock by 13 down to 308KHz, which is then divided by 16 in the UART to get 19.2KHz. The only faster divider available in the UART is /1, and that only works with synchronous clocks -- it won't work in a situation here where the drive's serial clock is skewed from the computer's serial clock.

 

The SPD hardware does supposedly have a high-speed option to use the Atari's serial clock instead of the internal serial clock. It requires a non-standard serial configuration on POKEY, though, so it isn't compatible with US Doubler or XF551 high speed and the firmware doesn't use it anyway. I'm assuming that the S1PD has the same option if it isn't just the same hardware, as firmware from drives labeled both SPD and S1PD seem to be compatible.

 

11 hours ago, Jeffrey Worley said:

I think you are mistaken about the step rate.  The default is 2.  I know this from reading the control block rather than the rom.  It also seems to differ in that the slave mech I usually use on my Percom is not density-smart when running on this controller.   I'm going to have to check the other one out, but the internal mech (d1:) is density-smart.  Go figure.

There's a default step rate code in a DCB init block at the top of the ROM that has either $00 or $01 that's then overridden by code later on to $02. Which makes it even more mysterious as to why different ROMs flipped back and forth between $00 and $01 in the init block.