Hiassoft Highspeed SIO patch: Can't boot from Real Percom drive

[+Nezgar]

In my recent adventures with my real Percom AT88-S1, I noticed when booting with an OS that has @HiassofT's Highspeed SIO patch, it will not boot if the drive is spun down. I believe this is because the PERCOM has a minimum 1 second delay to respond as part of it's motor settle wait after spinup. The drive does support querying percom block (obviously ) but no highspeed capability.

 

The drive does start spinning immediately when the OS starts to send the first commands on bootup, so if I then immediately reset it will boot on the next round. Brief testing shows this can be reproduced in Altirra with Percom RFD full drive emulation, and an OS with Hias' patch to aid troubleshooting. It would be interesting to see if maybe @Jeffrey Worley would be able to test with his ATR-8000 as well? Or someone familiar with emulating ATR-8000 in Altirra...

 

The log from RespeQt is the same as if no drive was attached at all.

Serial port speed set to 19200."
[Disk 1] command: $3f, aux: $0020 ignored." [x5]
[Disk 1] command: $53, aux: $8020 ignored." [x5]
[Disk 1] command: $d3, aux: $0020 ignored." [x5]
[Disk 1] command: $48, aux: $0020 ignored." [x5]
[Disk 1] command: $53, aux: $0000 ignored." [x16]
[Device $4f] command: $40, aux: $4f4f ignored." [x28]
[Device $4f] command: $40, aux: $0000 ignored." [x28]

I've determined that even a $53 "GET STATUS" command causes the drive to spin up, and takes 1 second to respond, presumably to check the density on the disk. Easily reproducible just by selecting the drive with the SDX formatter.

 

It's minor I know, but maybe something to consider for a future tweak for maximum compatibility with real hardware. Maybe adding one last get-status command at the end of the detection routine would be close to the 1 second mark where it would get a response immediately...

[Jeffrey Worley]

5 minutes ago, Nezgar said:

In my recent adventures with my real Percom AT88-S1, I noticed when booting with an OS that has @HiassofT's Highspeed SIO patch, it will not boot if the drive is spun down. I believe this is because the PERCOM has a minimum 1 second delay to respond as part of it's motor settle wait after spinup. The drive does support querying percom block (obviously ) but no highspeed capability.

 

The drive does start spinning immediately when the OS starts to send the first commands on bootup, so if I then immediately reset it will boot on the next round. Brief testing shows this can be reproduced in Altirra with Percom RFD full drive emulation, and an OS with Hias' patch to aid troubleshooting. It would be interesting to see if maybe @Jeffrey Worley would be able to test with his ATR-8000 as well? Or someone familiar with emulating ATR-8000 in Altirra...

 

The log from RespeQt is the same as if no drive was attached at all.

Serial port speed set to 19200."
[Disk 1] command: $3f, aux: $0020 ignored." [x5]
[Disk 1] command: $53, aux: $8020 ignored." [x5]
[Disk 1] command: $d3, aux: $0020 ignored." [x5]
[Disk 1] command: $48, aux: $0020 ignored." [x5]
[Disk 1] command: $53, aux: $0000 ignored." [x16]
[Device $4f] command: $40, aux: $4f4f ignored." [x28]
[Device $4f] command: $40, aux: $0000 ignored." [x28]

I've determined that even a $53 "GET STATUS" command causes the drive to spin up, and takes 1 second to respond, presumably to check the density on the disk. Easily reproducible just by selecting the drive with the SDX formatter.

 

It's minor I know, but maybe something to consider for a future tweak for maximum compatibility with real hardware. Maybe adding one last get-status command at the end of the detection routine would be close to the 1 second mark where it would get a response immediately...

I DO have recently restored AT88 with doubler and an AT88-SPD, so I can test on real hardware with those, but:

 

I unfortunately don't have an ATR right now or I'd be glad to oblige, but I have a lot of experience with  the ATR and think it is a wonderful disk interface, if flaky in actually keeping the data on the disk.  Ironically, the same controller that forgets Atari data so readily will not forget CP/M formatted data.  I always thought they used crappy capacitors, but it wouldn't be that if the CP/M-side were so much better, same controller after all.  At any rate, if I get an ATR I will happily beta anything you need.  Does anyone have an ATR they would be willing to let go of at a fair price?  I could spend 200.00 for one.

 

As for spin-up on the Percom, there are jumper-settings on drives that can affect this as well.  Motor-start on drive id select or motor start on motor start (line on 34pin cable).  Those are selectable and can make a difference as to how a given mech on the MUX responds.  The Percom controller pretty much starts the motors, I think, at least in practice, on select of any drive.  I've played with this at length, trying to set it so that it will only start on an ID select, leaving non-selected drives un-spin, but it won't do that.  My motive was to take the load off of the power supply internal to the Percom controller, thus making two mechs in a single enclosure a safer bet.  As it is, experience shows me that the power supplies in the Percom drives are only marginally able to handle two half-height 5.25" drives.  You CAN do a 5.26 and a 3.5 safely, but I've had flaky operation with two large mechs and that is pretty sure to be from pulling too much juice.  There are two 7805's and one 7812 on the controller, so I always suspected the 12volt side as being the fault there.

 

Best,

 

Jeff

 

 

Edited April 6, 2020 by Jeffrey Worley

[+Nezgar]

12 hours ago, Jeffrey Worley said:

I DO have recently restored AT88 with doubler and an AT88-SPD

Heyyy.... So that has printer port? If so, I would very much appreciate a ROM dump from it. We don't have a ROM dump from an AT88 with printer capabilities yet. (And because of this, no emulation of it in Altirra yet )

 

Edit: Percom AT88-SPD ROM Dump has now been posted here: https://atariage.com/forums/topic/304384-percom-at-88-doubler-rom/?do=findComment&comment=4502153

 

12 hours ago, Jeffrey Worley said:

As for spin-up on the Percom, there are jumper-settings on drives that can affect this as well. 

Hmm interesting, which jumpers specifically can I try messing with? On yours, do you also experience the drive spin up and a 1-second lag just by selecting the drive in the SDX formatter?

[BillC]

11 hours ago, Jeffrey Worley said:

You CAN do a 5.26 and a 3.5 safely, but I've had flaky operation with two large mechs and that is pretty sure to be from pulling too much juice.  There are two 7805's and one 7812 on the controller, so I always suspected the 12volt side as being the fault there.

You could try swapping the 7812 for a regulator capable of delivering more current, as long as the rest of the components can handle the extra load. The one linked below from DIGIKEY is $3.48, rated for 3A, and appears pin compatible.

https://www.digikey.com/product-detail/en/microchip-technology/MIC29300-12WT/576-1118-ND/771587

[Gunstar]

Couldn't this be tested as well with an Indus GT upgraded for CP/M or my CA-2001 Indus clone that has the CP/M memory, etc. upgrade already in it? I don't have time to test with my CA-2001 myself, just a thought for others, instead of trying to track down an ATR-8000.

[Jeffrey Worley]

4 hours ago, BillC said:

You could try swapping the 7812 for a regulator capable of delivering more current, as long as the rest of the components can handle the extra load. The one linked below from DIGIKEY is $3.48, rated for 3A, and appears pin compatible.

https://www.digikey.com/product-detail/en/microchip-technology/MIC29300-12WT/576-1118-ND/771587

I've got some really nice settable/variable switching regulators I bought for this purpose:  https://www.amazon.com/gp/product/B0758ZTS61/ref=ppx_yo_dt_b_search_asin_image?ie=UTF8&psc=1

 

But I have yet to fit them to anything, as I am lazy.  I've been planning to fit a second mech in the form of a Gotek, which would pull nothing to speak of.  A Gotek would run for quite a while on 3 AA batteries, I think.

 

Best,

 

Jeff

[BillC]

48 minutes ago, Jeffrey Worley said:

I've got some really nice settable/variable switching regulators I bought for this purpose:  https://www.amazon.com/gp/product/B0758ZTS61/ref=ppx_yo_dt_b_search_asin_image?ie=UTF8&psc=1

According to the description the current rating of those is only 1.5A without a heatsink/better cooling.

 

Output current is 3A max (please enhance cooling work when it is full load); when real tested input 12V and output is 1.5A, no need to add special system.:

 

 

[Jeffrey Worley]

5 hours ago, BillC said:

According to the description the current rating of those is only 1.5A without a heatsink/better cooling.

 

Output current is 3A max (please enhance cooling work when it is full load); when real tested input 12V and output is 1.5A, no need to add special system.:

 

 

That isn't really too big a deal.  You can just glue a heatsink to it, our double them up to keep heat down and current up.

 

Jeff

[Kyle22]

I wish some brilliant Z80 coders could take Indus SuperSynch FIX THE TIMING bug w/ SpartaDOS / SDX, and make a FAST [Track buffered] ATR-8000 EPROM. Is there enough free space?

 

[Jeffrey Worley]

1 minute ago, Kyle22 said:

I wish some brilliant Z80 coders could take Indus SuperSynch FIX THE TIMING bug w/ SpartaDOS / SDX, and make a FAST [Track buffered] ATR-8000 EPROM. Is there enough free space?

 

There's no reason the ATR8000 could not do this.  You could simply upload a replacement operating system to the memory onboard.  Even a poor ATR has 16k of ram. That's enough to do a WHOLE LOT.  Most all have 64k anyway, which is enough to rule the world.

 

Best,

 

Jeff

[Kyle22]

Yeah, it's a bit banger like Indus. It has been many years since I was fluent in Z80. These days, I am a partner in the store now, so i work 7 days a week. If I still had my fully loaded TeleVideo network system, I would give it a go, but, sadly, I lost it in a move.

 

The INDUS.SYS in the never released SDX v4.23 fixed the timing bug and supported Buffering. I am sad every day because I lost it. I had the ONLY cart. :(

 

 

[+Nezgar]

Well, I hacked the AT88-S1 ROM to reduce the wait after "motor on" to 1/3S instead 1S and it solved the issue with the Hias Highspeed patch not finding the drive on bootup. Maybe someday the routines could accommodate the delay in response in the original Percom firmware.

 

 

[Jeffrey Worley]

7 hours ago, Nezgar said:

Well, I hacked the AT88-S1 ROM to reduce the wait after "motor on" to 1/3S instead 1S and it solved the issue with the Hias Highspeed patch not finding the drive on bootup. Maybe someday the routines could accommodate the delay in response in the original Percom firmware.

 

 

This is a really nice feature and I'm glad to have it.  I prefer the original interleave after all.  It is faster.  I kept the original rom pristine.  If I sell the drive, I'll double-face-tape it inside the enclosure in case someone in the future wants to downgrade it.  I put a 360k mech in it, and a Gotek 3.5" with a 16gig USB stick.  Too bad the machine won't read enhanced density.  99% of the disks online that are in enhanced density ought NOT be.  They are single-density disks that someone copied to enhanced density destinations.  This works fine, but it makes it incompatible with drives like mine and it stotally unneccessary.  Lotharek's collection and that massive Polish collection are RIFE with morphodite disks like this.  ARGH!  The process is reversible, but requires re-copying to single-density destinations.  If anyone wants to automate that process, please do and tell me you did.  It would be easy to detect if the disk is in fact a single-density copied to enhanced density, as all the high-numbered sectors are blank.  This drive has the Gotek set for drive 0 and the 360k mech for DS1.  I replaced all electrolytics on the Percom, it desperately needed that, as well as the voltage regulators.  While I was at it I replaced the dip socket the doubler plugs into with a new machined socket.  The doubler has a second machined socket plugged into it.  This provides the clearance necessary to make room for it.

 

Best,

 

Jeff

Edited April 8, 2020 by Jeffrey Worley

[HiassofT]

@Nezgar could you give this version https://www.horus.com/~hias/tmp/hipatch-200411.zip a try?

 

I've added a normal "get status" call before the Turbo 1050 and XF551 get status checks and also increased the SIO command timeout from 1 to 2 seconds.

 

This should give the Percom drive enough time to spin up and properly respond to the get status command before the Turbo/XF551 get status checks are issued (which probably lead to the drive being busy spinning up while the other checks and the start of the boot process were progressing).

 

This version should also speed up highspeed sio checks of non-existent drives a bit, if the get status command fails the Turbo, XF551 and Happy Warp Speed checks are skipped.

 

so long,

 

Hias

[flashjazzcat]

14 hours ago, HiassofT said:

I've added a normal "get status" call before the Turbo 1050 and XF551 get status checks and also increased the SIO command timeout from 1 to 2 seconds.

Hi Hias

 

Have you had any further thoughts about divisor $06 support for INDUS drives? This has been requested elsewhere, but I found an old post in which you were previously asked about this, and you gave some good reasons for not supporting it at the time. I understand the protocol is basically the same as that of the XF-551, but with a different divisor. I attempted to implement this, but since I can only test in Altirra (and since the emulated INDUS appeared to acknowledge the XF-551 speed poll), a new arbitrary ID for the INDUS drive never finds its way into the high speed table. Obviously I am loathe to make any changes which might compromise existing reliability, too, and code space is rather tight.

 

[HiassofT]

54 minutes ago, flashjazzcat said:

Hi Hias

 

Have you had any further thoughts about divisor $06 support for INDUS drives? This has been requested elsewhere, but I found an old post in which you were previously asked about this, and you gave some good reasons for not supporting it at the time. I understand the protocol is basically the same as that of the XF-551, but with a different divisor. I attempted to implement this, but since I can only test in Altirra (and since the emulated INDUS appeared to acknowledge the XF-551 speed poll), a new arbitrary ID for the INDUS drive never finds its way into the high speed table. Obviously I am loathe to make any changes which might compromise existing reliability, too, and code space is rather tight.

 

Not much has changed on that matter, except I realized free space was a lot tighter than I thought. So even if the indus would work without having to upload code to the drive it might be very hard to squeeze it in.

 

IMO it's still best to use the indus drive firmware with ultraspeed support, that should work without hassle.

 

so long,

 

Hias

[flashjazzcat]

2 minutes ago, HiassofT said:

Not much has changed on that matter, except I realized free space was a lot tighter than I thought. So even if the indus would work without having to upload code to the drive it might be very hard to squeeze it in.

 

IMO it's still best to use the indus drive firmware with ultraspeed support, that should work without hassle.

Thanks Hias; that's good enough for me. I am pretty much in the same boat now regarding code space.

[_The Doctor__]

makes perfect sense,

To understand high speed for all drives now, except indus drives as they require uploaded code to perform their magic, once that code is uploaded... does it co exist with your driver...  I believe it's time to test... we all appear to have a little extra time these days

[Kyle22]

I would try Indus divisor first and fall back to XF divisor on failure to determine what drive it is. Has that been attempted?

 

[flashjazzcat]

3 minutes ago, Kyle22 said:

I would try Indus divisor first and fall back to XF divisor on failure to determine what drive it is. Has that been attempted?

It has. It didn't seem to make any difference whatsoever, in Altirra at least. Perhaps the implementation was to blame, but it's difficult to tell.

 

[HiassofT]

Keep in mind that the Indus protocol is NOT 100% compatible to the XF551 one. Read the remarks in the Altirra hardware reference manual:

Quote

The Indus GT and XF551 are incompatible with respect to the $A1 and $A2 format commands. The $A1
format command sends a low-speed data frame on the XF551, while on the Indus GT it sends a high-
speed data frame. The $A2 command has the same behavior on the stock firmware and is not supported
at all by the uploaded Synchromesh or SuperSynchromesh firmware.

I haven't checked yet but I would suspect the Indus (with stock ROM) shouldn't be detected as "XF551" by my highspeed SIO code as highspeed transfers seem to use synchronous mode (so the XF551 check should fail as it uses async mode).

 

so long,

 

Hias

[flashjazzcat]

11 minutes ago, HiassofT said:

Read the remarks in the Altirra hardware reference manual

Indeed I have: this complicates things a little further.

12 minutes ago, HiassofT said:

I haven't checked yet but I would suspect the Indus (with stock ROM) shouldn't be detected as "XF551" by my highspeed SIO code as highspeed transfers seem to use synchronous mode (so the XF551 check should fail as it uses async mode).

Basic INDUS emulation in Altirra results in a test positive for the XF-551 using your code (or my implementation thereof, which I trust to be functionally identical).

 

I wonder if full drive emulation would be different, although I didn't get any response from the drive when trying that with a real INDUS firmware ROM.

[Kyle22]

To be clear: I am referring to an Indus with 64K RAM that has already been programmed by SDX 4.49 INDUSX.SYS.

 

[flashjazzcat]

I've tried full drive emulation with a couple of ROMs and I can't get the drive to show up at all.

 

INDUSX.SYS is totally outside the scope of what is being attempted here. Neither the PBI BIOS not the high speed patched OS will be uploading code to the drive. If it can't work at divisor 6 with basic high speed commands, it's a waste of time.

[_The Doctor__]

I think kyle22 wants loading the code with a computer like the indus sys etc file does... or doing it with a disk only like with some previous folks have done(no computer).... and then booting /going about your business thereafter with hsio using the already programmed drive.

 

this might be possible but what happens to drive that don't have the code uploaded already... that could be sticky...

 

he wants hsio to be able to use it after code has been uploaded or pulled from disk.  Uploading the code is not what the driver should do... it would make it too big, and probably slower or who knows what... I will test on real hardware tonight and let you know what happens Hias.