HIgh Speed SIO on IDE+ v2

[MrFSL]

Wrapping my head around the internal high-speed SIO routines on the IDE+ v2 as explained in "IDE Plus 2.0 Configuration Screen Guide" (http://drac030.krap.pl/ide-plus-config-screen-reference-1.7.pdf) 

 

I have two SIO devices which allow me to set the pokey divisor and monitor the IO for errors; the first is the SDrive-Max and the second is a Fujinet. To start - if I run either of these two devices by themselves with a Hias HSIO patched ROM I get fantastic reliable IO speeds: SDrive-Max pokey divisor 3, Fujinet pokey divisor 0.

 

When I run the non-patched ROM with the IDE+ v2 with internal high-speed SIO enabled I reliably can use: SDrive-Max pokey divisor 5, Fuginet pokey divisor 7.

 

However, when I disable the internal high-speed SIO then i reliably can only use: SDrive-Max pokey 5, Fuginet pokey divisor 5.

 

It seems the IDE+ v2 actually has faster SIO with the internal high-speed SIO disabled. Perhaps @drac030 or @Simius  can explain what I am doing that would cause this behavior. Its more than likely my not understanding the IDE+ well enough. I have the IDE+ v2 (f) running the BIOS 1.7b-test.

 

 

 

 

[drac030]

6 hours ago, MrFSL said:

When I run the non-patched ROM with the IDE+ v2 with internal high-speed SIO enabled I reliably can use: SDrive-Max pokey divisor 5, Fuginet pokey divisor 7.

 

However, when I disable the internal high-speed SIO then i reliably can only use: SDrive-Max pokey 5, Fuginet pokey divisor 5.

 

It seems the IDE+ v2 actually has faster SIO with the internal high-speed SIO disabled.

You are saying that when you use the stock OS and disable the HS SIO in IDE+, you are still able to get serial transfers with Pokey index other than $28?

 

This sounds like an obscure bug in the IDE+ SIO routines. Could you please provide steps to reproduce that behaviour?

[MrFSL]

Sure, let's start with the Fujinet example. (We can also do the SDrive-Max or SIO2PC cable example later if you wish but they are a bit less verbose.)

 

When running SDX - the Fujinet provides D1. The method is to boot to IDE+ SDX and monitor access to this D1.

 

800XL (NTSF) with a stock ROM (no HSIO patches) and 512 RAM upgrade, Sophia rev C DVI video..

 

The Fuginet provides an interface to adjust HSIO setting and a serial output for debugging.

 

(1) we set the HSIO index on the Fujinet

(2) power off Atari

(3) boot into IDE+ SDX

(4) try: DIR D1:

(5) increment the index on Fuginet

(6) Goto (2)

 

At Index #7 (63Kb) - No issues.

 

Above Index #7 - DIR freezes, and Fujinet serial demonstrates the issue.

 

When I change the IDE+ Config to disable "Speed SIO"

 

Incrementing all the way to #5 without issues. --- At #4 repeating DIR multiple times will eventually cause a lock up.

[drac030]

Ok, I understand more now When you switch the IDE+ SIO off, the computer uses SDX SIO, for which the index 4-5 is the maximum. This is a known issue with the SDX SIO driver.

 

As for the setup with IDE+ SIO on - I can see that it has a problem at index 7: Atari seems to send STATUS twice in a row, evidently does not get the responses, and then goes astray (BTW. why 3 bytes only of the STATUS block are displayed in the log?).

 

Could you nevertheless try higher baudrates and see if it also misbehaves? I mean, indices 6, 5, 4 etc.

[ivop]

Didn't know the Fugees were also working with Atari 8-bits!
 

 

Fujinet, Fuginet

 

[MrFSL]

7 hours ago, ivop said:

Didn't know the Fugees were also working with Atari 8-bits!
 

 

Fujinet, Fuginet

 

Haha --- do i have a typo back there somewhere?

[MrFSL]

8 hours ago, drac030 said:

Ok, I understand more now When you switch the IDE+ SIO off, the computer uses SDX SIO, for which the index 4-5 is the maximum. This is a known issue with the SDX SIO driver.

 

As for the setup with IDE+ SIO on - I can see that it has a problem at index 7: Atari seems to send STATUS twice in a row, evidently does not get the responses, and then goes astray (BTW. why 3 bytes only of the STATUS block are displayed in the log?).

 

Could you nevertheless try higher baudrates and see if it also misbehaves? I mean, indices 6, 5, 4 etc.

Yes - I could have (should have) attached all the log information and will in the future. I just grabbed a section that either showed a problem or otherwise showed that the speed was set and I reported there was no problem.

 

I will go the other way round. I will start at the top and work my way backwards and report back.

[MrFSL]

Here are debug captures at all indexes with the IDE+ Speed SIO enabled.

 

0 through 5 there is no difference that I detected. The cursor is frozen on the screen.

 

At 6 eventually it goes through in small bursts on the screen.

 

7 through 9 seem to have no difference that I detected. The command executes as you would expect on screen.

IDE_SIO_OFF.zip

Edited November 3, 2020 by MrFSL

[drac030]

11 hours ago, MrFSL said:

0 through 5 there is no difference that I detected. The cursor is frozen on the screen.

 

At 6 eventually it goes through in small bursts on the screen.

One question (I always forget to ask first when it comes to high-speed SIO problems): does your Atari have these below?

 

 

Because if so, then to my knowledge, nothing faster than index 8 will ever work reliably otherwise than by an accident.

 

[MrFSL]

[BillC]

6 hours ago, MrFSL said:

While they may look like resistors those are capacitors below the SIO port, I believe the capacitors to remove on the 800XL for better high speed IO are:

C77 - DATA IN
C78 - DATA OUT
C84 - COMMAND

[fenrock]

Regarding the removal of the capacitors, do you have to then connect across the gap made by removing the capacitor?

 

[flashjazzcat]

29 minutes ago, fenrock said:

Regarding the removal of the capacitors, do you have to then connect across the gap made by removing the capacitor?

Absolutely not; this would short all the signal lines direct to ground.

[fenrock]

2 minutes ago, flashjazzcat said:

Absolutely not; this would short all the signal lines direct to ground.

Thanks Jon. I don't mind doing the work, but like to understand it too. Electronics is not one of my strong skills so like to hoover up as much information as possible before hacking my lovely 800XL.

[flashjazzcat]

Agreed: I prefer to know why I'm doing something, as well as how to do it.

[fenrock]

14 minutes ago, flashjazzcat said:

Agreed: I prefer to know why I'm doing something, as well as how to do it.

I recall having that internal monologue when i was getting married

[drac030]

In mean time I got a mail from someone who apparently does not want to write here, who says that (from his experience) the capacitors themselves are not a problem. So before killing them it would be worth waiting for second opinion, what they really do to SIO signals, and if the visible problems (on some computers like mine) are not rather due to the worse quality or advanced age of the capacitors than to the capacitors themselves.

 

I admit that I just checked my other 65XE (which has the capacitors too, which I saw after opening it) and on that computer index 4 is not a problem. Whereas on my main Atari, as I said above, nothing below 8 works stable. I also had a 130XE (which currently I have no access to to see if there are capacitors or not, but the computer was completely unmodded when I bought it, thus I would guess that the capacitors are there), which happily ran SIO transfers at index 1.

 

Unfortunately, the "index 4" 65XE is the one which hardly works otherwise, so I cannot make any further tests on it.

 

 

[flashjazzcat]

I have some recollection of Hias saying that the caps only became a real impediment at divisor 0 (which is surely where we want to be), but I may misremember.

 

[fenrock]

Fair enough, just planning ahead myself. I was looking at http://sio2sd.gucio.pl/wiki/HighSpeed_en for a comparison of before/after capacitor removal, showing the rise time significantly being reduced.

 

[MrFSL]

Well I can test. I have a Sys-check card and can change the ROM to use the Hias patches. The difficulty is doing this while still using SDX. Enabling the ROM feature on the Sys-check knocks out the IDE+. I can use the Maxflash1 ROM image on a cart - but I am not sure if that would be helpful

 

If I don't use any flavor of SDX and I just use the Hias ROM patches to load files from the Fujinet or SDrive-Max it seems that Hi Speed IO works immensely better than anything under SDX. I can adjust the index on Fujinet (including index 0) and roughly time the loading screen of yoomp for instance to see that their is a capability of high speed IO. This fact alone leads me to believe that there are many more places to look before I chop out capacitors.

 

More important then whether I achieve reliable 0 index verses 1 or 2 or 3 really doesn't matter. What this thread is really about is the IDE+ and its High Speed IO functionality. Currently when enabled we are seeing less reliable / slower IO then when disabled. That appears to be an interesting bug indeed. If drac030 wants to get to the bottom of it that would be cool and I am enjoying assisting and testing and learning.

 

One thing that would be useful (if it existed) is a DOS independent SIO meter application or method - perhaps something akin to dd in Unix. This would help standardize testing. So far I am either listing a directory or loading a larger binary; in Fujinet I get better debug logs; in SDrive-Max not so much (seems the SDrive-Max is making adjustments on its own when it sees errors.) 

 

What do you guys think? Is there a good program or method to achieve SIO testing more robust?

 

Oh and thanks for the additional input on this thread. @fenrock I too would not have known the proper way to remove the caps and then what to do after. Like you, my strengths are not in hardware. @flashjazzcat and @drac030 and @BillC just taking the time to educate us is appreciated. I'm sure you all know that or why else would you keep doing it? Riches and fame, eh? LOL.

 

 

[drac030]

1 hour ago, MrFSL said:

Hi Speed IO works immensely better than anything under SDX

SDX and its SIO drivers is a separate question. SIO.SYS is slow and it has been known for ages. Worse, I am not sure if this is fully fixable, but the current betas (which some have) do contain a SIO.SYS driver which should be faster.

 

As for IDE+, the thing I could do is to shorten the intervals the procedure is spending in setting up the consecutive phases of the transfer. I can already see under the emulator that if the data block is sent by the external device immediately after the 'C' acknowledge (at divisor 0), the receiver may have a problem with catching up. I will see what can be done, unfortunately the only means of testing this for me is Altirra.

 

Edited November 4, 2020 by drac030

[ivop]

I know of two solutions that work at div 0 with all the caps in place. The first was a prototype by @mr-atari and somebody else. They used Schottky diodes on all the relevant lines. The other one is @lotharek's SIO hub. His buffering cleans up the signal at both sides.

 

[drac030]

7 hours ago, MrFSL said:

If drac030 wants to get to the bottom of it that would be cool and I am enjoying assisting and testing and learning.

If you are so kind, please see if this version makes things any better.

bios17c-test.arc

[MrFSL]

Attached are the debug logs from the Fujinet.

 

I started at the last known working Index for either IDE+ HSIO ON/OFF (Index 7 for IDE+ SIO ON, Index 5 for IDE+ SIO OFF.)

 

Amazing results! HSIO Off does not seem to have changed (I don't think.) HSIO ON now works as I would expect. Things seem stable up to Index 3 (before Index 7 was the best.) Directory listings and binary execution still work at Index 2 and 1 but there are significant delays or hangs. Index 0 fails unsurprisingly. 

 

I swapped over to the SDrive-Max which admittedly I do not know how to get good debugging logs. I can watch the screen and count the time it takes binaries to load. As best as I can determine, whatever changes you have made seem to have positively effected HSIO there as well. 

 

Congratulations!

 

IDE_HSIO_OFF.zip IDE_HSIO_ON.zip

[drac030]

Thanks. So it was what I was suspecting, shortening the intervals helped. There is yet some room there to shorten them further, but... the SIO documentation, IIRC (and if I am not mistaken), stipulates that the external device has to make some delays between sending acknowledges and data blocks. Normally (at 19200) such delays are rarely necessary, because transferring a byte over the cable occupies about 940 clock cycles, so the computer has plenty of time to setup before the first byte of the data block arrives. But at divisor 8 it is only 300 cycles, and at divisor 0 - 140 cycles, if I calculate correctly. Now 140 cycles, assuming that a VBL may kick in or Antic may issue a HALT to fetch display data, is not much at all. So the devices should somewhat compensate for the fact that the data transfer does not occupy 900-odd cycles per byte anymore but much less, and insert delays between the consecutive stages of the transfer (this is why, I guess, Turbo 1050 works with divisor 6 on standard SIO routines - the drive must send bytes at certain intervals, otherwise it would not work, I suppose).

Edited November 5, 2020 by drac030