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

[Kyle22]

31 minutes ago, _The Doctor__ said:

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.

Yes. like this:

 

Patch high speed BIOS for Indus divisor, set up SDX to use OS SIO routines. Once INDUSX.SYS is loaded, drive will remain programmed for high speed.

 

I'm going to try this with a hex editor if I can locate the correct byte to patch.

 

[HiassofT]

35 minutes ago, Kyle22 said:

I'm going to try this with a hex editor if I can locate the correct byte to patch.

In the 1.31 200411 version linked above the location in the ROM is CDCB:

CDCA  A9 10     LDA #$10
CDCC  8D 04 D2  STA $D204

so long,

 

Hias

[Kyle22]

Thanks, I found the sequence in IPBI.ROM with the speed byte $10 being at offset $19EE. I'll give it a try when I get home and report back.

 

[flashjazzcat]

1 hour ago, _The Doctor__ said:

he wants hsio to be able to use it after code has been uploaded or pulled from disk. 

Yes: as I explained to him via PM, the HSIO driver (at least in my PBI BIOS) is supposed to be a completely DOS-independent solution (which is to say, it initialises the disk drives without relying on any external services). It seems to me, therefore, that the best possible solution at this point would be to turn off PBI HSIO acceleration on the drive of interest. This will cause the SDX SIO driver to be used for the INDUS drive, and the PBI HSIO driver to be used for everything else. That's about the best thing I can suggest for now, unless Hias suddenly comes out with fully tested INDUS high speed support in the next day or so.

[HiassofT]

28 minutes ago, flashjazzcat said:

unless Hias suddenly comes out with fully tested INDUS high speed support in the next day or so.

This was a good one ? I don't have an Indus drive and testing without real hardware is tricky (yeah, I could check if Altirra could help here, but that's still not quite the same as real HW where I could hook up a scope).

 

I also think a different approach to the Indus issue might be better: if people don't want to install the ultraspeed firmware ROM then it may be beneficial to alter the code uploaded by indus.sys to make the drive fully XF551 compatible (or - if possible - US or 1050 Turbo compatible). This would result in instant compatibility with all existing highspeed solutions/codes without having to alter each one of them to the almost-but-actually-not-quite-xf551-compatible (super) synchromesh protocol.

 

so long,

 

Hias

[flashjazzcat]

3 minutes ago, HiassofT said:

I don't have an Indus drive and testing without real hardware is tricky

I feel the same way; I basically implemented something here, but without real hardware (nor the space to accommodate the code without temporarily commenting out other stuff), I do not trust it.

 

Good idea regarding XF compatibility, especially since there are no code size restrictions on disk-loaded initialisation tools.

[flashjazzcat]

54 minutes ago, Kyle22 said:

Thanks, I found the sequence in IPBI.ROM with the speed byte $10 being at offset $19EE.

Caveat: XF-551 high speed SIO (which was broken thanks to a clumsy typo when I was transcribing Hias' code) didn't get fixed until v.3.03, which is to say the fixed release version (3.10) isn't out yet. But I'm sure this simple patch will work in the latest version.

[Kyle22]

Edit: Nevermind. FJC answered my question via PM. I'm going to wait for v3.10 and patch that one.

 

 

Edited April 12, 2020 by Kyle22

[flashjazzcat]

3 minutes ago, Kyle22 said:

So I should wait until 3.03 then?

3.10 is the release version. I will PM you the firmware now and you can try it.

[Kyle22]

Thanks!

 

[_The Doctor__]

you can put the indus in usdoubler mode already, but it is slower

[HiassofT]

1 minute ago, _The Doctor__ said:

you can put the indus in usdoubler mode already, but it is slower

Can this be done via one of the indus.sys / loader programs or does it require a ROM upgrade?

 

If it's via loader program than it shouldn't be too hard for one of the Z80 programmers to change that to return $06 on the get speed byte $3f command and change the IO code to use the same timing as super synchromesh.

 

so long,

 

Hias

[_The Doctor__]

@rcgldr, can you take a look into this?

33 minutes ago, HiassofT said:

Can this be done via one of the indus.sys / loader programs or does it require a ROM upgrade?

 

If it's via loader program than it shouldn't be too hard for one of the Z80 programmers to change that to return $06 on the get speed byte $3f command and change the IO code to use the same timing as super synchromesh.

 

so long,

 

Hias

as an upload disk?... even if you don't want to get into making an 8 bit proggy, as once you make the upload data, certainly the upload data could be injected in place of the old code in indus.sys file on the old Atari...

[Kyle22]

I just tried it and it works. I have SDX set to DEVICE SIO /A to use the patched BIOS high speed code. The SDX formatter seems to get confused about it and its interleave doesn't sound right, but the high speed I/O seems to work fine.

So, now I have reliable divisor zero (with RespeQt) and high speed track buffered Indus working with SDX.

@drac030, why can't I find INDUS.SYS in the ROM using the imaging tool? I wanted to replace it with INDUSX.SYS and there's not enough space left to just add INDUSX.SYS.

 

Edited April 12, 2020 by Kyle22
clarity

[flashjazzcat]

3 minutes ago, Kyle22 said:

I just tried it and it works. I have SDX set to DEVICE SIO /A to use the patched BIOS high speed code.

As mentioned in PM, the /A switch is not needed to get the PBI driver to handle SIO transfers (the PBI driver has precedence over the SDX SIO driver, which calls the PBI driver first anyway). The switch is needed with the patched high speed OS, however, since the SDX SIO driver otherwise replaces the OS SIO handler.

[Kyle22]

Also, I forgot to mention: Do not load INDUSX.SYS more than once or it causes problems.  I think INDUSX.SYS needs to be modified to check the drive and see if it has already been programmed and abort if that's the case.

 

[drac030]

@Kyle22 INDUS.SYS is located in the CAR: area which is not accessible with the SDX Imager. I am sure, though, that INDUS.SYS will eventually get replaced with INDUSX.SYS once the latter gets sufficiently tested (it is rather fresh, as you can see by its datestamp :))

3 hours ago, Kyle22 said:

Do not load INDUSX.SYS more than once or it causes problems.

@trub

[+Nezgar]

On 4/11/2020 at 3:41 PM, HiassofT said:

@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.

Thanks @HiassofT - I tested it with the original Percom AT88 v1.2 firmware, and it appears to work!

 

You can see the difference comparing the old/new versions on real (NTSC) hardware here:

 

I have not regression tested it with any other types of drives yet though.

[HiassofT]

Thanks a lot for testing, good to know it's working fine on real hardware!

 

I haven't done much regression testing either yet, that's tedious work as I also need to verify that all projects where I embed the highspeed code work fine (I need to make sure the receive loop doesn't cross a page boundary as that'd screw up divisor 0 timing).

 

I had a go at testing indus super synchromesh with Altirra and it seems the $58 (upload/execute) command needs blacklisting from highspeed ($22 probably too), otherwise GTSYNC won't properly execute if it was run before (eg boot DOS XL, on initial drive+computer cold start the highspeed code won't detect super synchromesh and use standard SIO, then reboot the Atari after DOSXL executed GTSYNC ON, highspeed code now uses synchromesh but GTSYNC ON doesn't work).

 

Unfortunately I'm out of code space to add the blacklisting - and as half-broken drive support is a lot worse than no support it means I probably won't add the indus mode.

 

so long,

 

Hias